Now that cabal is being used more often, what is the line between 'release and fix ux issues later' and 'dont release until users cant possibly mess it up' ? I think this goes in line (although perhaps isn't exactly the same) with what others have been talking about in regards to feature creep; if we add features and 'clean them up later' or 'fix soonish', when does that happen? what if it doesnt happen soonish (often the case across the unpaid open source ecosystem, sadly) and there are implemented features with poor/confusing ux that stay in there for a long time?
I'm happy to be accused of 'over-designing things' but I do think the details of onboarding are important for accessibility beyond our small crew of the typical euro-centric technical users at this point. Any thoughts on what you think the contribution policy should be for integrating new features into clients? Accept all PRs despite hanging 'todo' items? Implement low-hanging fruit with big gains; open issues for tasks that require lots of refactoring/input? Never accept any PRs unless on the roadmap? There are various extremes in potential ways of approaching this problem.. not any one way is the 'right' way but there can be ways that feel more stable, or exciting, to particular people in the community. So it's an open question for all maintainers..
I also feel like these conversations get pushed to the edge and disappeared in favor of 'new' and 'shiny' features and '10x engineering' that goes fast but introduces long-term maintenance issues and ux bugs.
Happy to talk more about this over a/v if that's more amenable; just want to be frank and honest about the direction of these apps and introduce some (hopeful) long-term stability into the clients.
Now that cabal is being used more often, what is the line between 'release and fix ux issues later' and 'dont release until users cant possibly mess it up' ? I think this goes in line (although perhaps isn't exactly the same) with what others have been talking about in regards to feature creep; if we add features and 'clean them up later' or 'fix soonish', when does that happen? what if it doesnt happen soonish (often the case across the unpaid open source ecosystem, sadly) and there are implemented features with poor/confusing ux that stay in there for a long time?
I'm happy to be accused of 'over-designing things' but I do think the details of onboarding are important for accessibility beyond our small crew of the typical euro-centric technical users at this point. Any thoughts on what you think the contribution policy should be for integrating new features into clients? Accept all PRs despite hanging 'todo' items? Implement low-hanging fruit with big gains; open issues for tasks that require lots of refactoring/input? Never accept any PRs unless on the roadmap? There are various extremes in potential ways of approaching this problem.. not any one way is the 'right' way but there can be ways that feel more stable, or exciting, to particular people in the community. So it's an open question for all maintainers..
I also feel like these conversations get pushed to the edge and disappeared in favor of 'new' and 'shiny' features and '10x engineering' that goes fast but introduces long-term maintenance issues and ux bugs.
Happy to talk more about this over a/v if that's more amenable; just want to be frank and honest about the direction of these apps and introduce some (hopeful) long-term stability into the clients.