Discussion: Threshold for use cases to support
bmulholland opened this issue · comments
@afonsojramos @setchy and anyone else contributing...
We already have received, and will continue to receive, requests to support all sort of extra options and features. How will we decide which to include?
If we add too many options, then we end up with a high maintenance cost, often for features that are used by only a handful of people. If we add too few, then we may not be that valuable, and may stagnate.
The best option, in my opinion, is to be somewhere in the middle. Provide options that make sense, based on understanding themes in workflows. That's product management, I suppose. One way of doing this will be to document the high-level use cases we're supporting, and consider whether features fit into that. I can move us forward with this, if there's consent that this is the way forward.
Before going too far with that, I wanted to open it up for discussion. What are your thoughts? What have you seen be successful for this on other open source projects?
👋, here is my point of view as a recent user of Gitify, and now contributor:
First, I totally get your point; more settings means more maintenance, and it costs a lot of free time from maintainers like you. People often don't realize how much time and energy it can take to maintain such a project.
But since Gitify is free and open-source, my take is that if any features were to break, users should start contributing to help and fix things. I know that it's not what happens 99% of the time, but it still happens; I'm an example of that 😁 (+ Gitify users are pretty much all developers...)
About the different workflows and preferences on how to manage Github notifications; I agree that there are many ways to handle things. My take is that Gitify should try and support as much as it can (while remaining reasonable of course), and by trying to not be too much opinionated.
The reason that this project was made an open-sourced was (I guess), so others can benefit from it, so it would be sad to prevent some people from using the app just because of the maintainers personal preferences/workflows.
I really enjoy Gitify, but it still doesn't exactly fit my workflow (that's why I'm trying to actively contribute); I thank every contributor/maintainer for their time spent on this, but if some features that I really need in my workflow were to not be implemented, I would probably think about running my own fork; but that's such a waste of time and energy!
So let's join forces and make Gitify a powerful app that fits lots of different workflows! 😛
Yeah, I think the struggle is how to deliver good UX for all that, you know? Fundamentally that's my question: how can we avoid becoming Jira? :) Jira is how it is because it ways to fit all the workflows, so we probably don't want to do everything.
@adufr so what you are saying is that the best move forward is to essentially not do anything and just keep existing as a project and have active discussions on a per feature basis? That's fine with me to be honest, less preemptive product thinking needed!
Although, we might need to truly rethink the settings then.... Maybe we can move it into a non-menubar window? There's a ton of menubar products that do this.
Great discussion @bmulholland @afonsojramos @adufr - I agree with the consensus we're reached, and the product has come a fair way in the last few months. Let's continue to raise new enhancement suggestions as we identify them 🙏