Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distinguishable AppIcon #215

Open
edwardgalligan opened this issue Jul 28, 2018 · 10 comments
Open

Distinguishable AppIcon #215

edwardgalligan opened this issue Jul 28, 2018 · 10 comments

Comments

@edwardgalligan
Copy link

I currently have both Patchwork and Patchbay installed (interested in testing out both), but they're impossible to distinguish since they both have the same icon.

I'm not sure if Patchwork, Patchbay or both clients should change their icons but certainly they should be distinguishable from eachother.

@christianbundy
Copy link
Contributor

Maybe we could just do a simple hue rotation to match the Patchbay UI colors? Here's a quick render, because we have to start somewhere:

patchbay

@edwardgalligan
Copy link
Author

Maybe we could just do a simple hue rotation to match the Patchbay UI colors? Here's a quick render, because we have to start somewhere:

This is a great idea in theory, but looking at the output, I think the change is still too subtle.

match the Patchbay UI colors

I wasn't really aware Patchbay had UI colours to speak of... With that in mind, I threw together:

patchbay-icon

or

patchbay-icon-blue

Alternatively, some take on the original greens: https://github.com/ssbc/patchwork-icons/blob/master/hermies/icon.svg

@stale
Copy link

stale bot commented Nov 1, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 1, 2018
@edwardgalligan
Copy link
Author

Apologies if this comment is off-topic, but I've never understood how stalebot as a concept benefits projects. Why close valid tasks, regardless of levels of activity?

If it's only tagging issues for manual inspection (as it's done sofar), that does seem useful.

@stale stale bot removed the stale label Nov 1, 2018
@christianbundy
Copy link
Contributor

If you're on SSB, I'd love to discuss this on %jn8ZQC3f6gCyuZFpA3uBNF5Nw6/LtXVYwpzV1sko6OA=.sha256, but I can summarize my [personal] thoughts here as well.

From the Stale readme:

Is closing stale issues really a good idea?

In an ideal world with infinite resources, there would be no need for this app.

But in any successful software project, there's always more work to do than people to do it. As more and more work piles up, it becomes paralyzing. Just making decisions about what work should and shouldn't get done can exhaust all available resources. In the experience of the maintainers of this app—and the hundreds of other projects and organizations that use it—focusing on issues that are actively affecting humans is an effective method for prioritizing work.

To some, a robot trying to close stale issues may seem inhospitable or offensive to contributors. But the alternative is to disrespect them by setting false expectations and implicitly ignoring their work. This app makes it explicit: if work is not progressing, then it's stale. A comment is all it takes to keep the conversation alive.

We currently have about 600 open issues, almost all of which haven't seen activity in months and many of which haven't seen activity in years. There's a large asymmetry in the amount of effort required to open an issue versus the amount of effort to confidently close an issue as resolved, which means that we'll continue to accumulate a backlog of inactive (and often already-resolved) issues that developers will learn to ignore.

There are so many issues under the SSBC org that I personally don't even check our backlog, so the only issues that get noticed are new issues, because we get notifications for them. Personally, that seems like a bad plan. Developers become stressed by the backlog, users with goals and needs can't get our attention, and the backlog ends up looking more like a graveyard than a todo list.

With that said, I'd love to see this issue resolved. Would you be comfortable posting about this on SSB and asking for feedback? I might tag the #patchbay and #patchbay-dev channels to make sure all of the relevant folks can see it.

@edwardgalligan
Copy link
Author

edwardgalligan commented Nov 1, 2018

Thanks for the full and detailed @christianbundy. I'll be honest, I strongly and fundamentally disagree with the logic posed in the Stale readme, but—as I alluded to already above—this probably isn't the best place to chat about that, so I'll check out that SSB thread.

I'll also throw something about this issue up on SSB separately.

@edwardgalligan
Copy link
Author

For posterity, further discussion on this here

@stale
Copy link

stale bot commented Jan 6, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 6, 2019
@stale stale bot removed the stale label Jan 6, 2019
@aadilayub
Copy link

I'd like to contribute to this (I could mock something up in Figma). Does anyone have suggestions for what concept/object could be used to represent patchbay as an icon? A boat? A web?

Maybe knowing a bit about the etymology of patchbay could help here.

@aadilayub
Copy link

Linking this relevant ssb thread

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants