3 ms·

There is a secondary issue: Even on projects where someone is interested in doing polish work, since it usually takes longer to polish than to write a new featu

There is a secondary issue: Even on projects where someone is interested in doing polish work, since it usually takes longer to polish than to write a new feature, those who only care about writing features cause the backlog of things that need polish to grow infinitely. I don’t really know of a good strategy for dealing with this in FOSS. If a feature contributor doesn’t care about polish, and you say to them ‘please fix the UX’, they can just either ignore the feedback (‘perfect is the enemy of good! move fast and break things!’), or if they don’t have direct commit access, create a fork that they can then advertise as having lots of cool new features. I would love to know some strategies that work to strike a balance between not demanding perfection and not allowing garbage to be mainlined.

jwells89 3y ago
This is why I mentioned keeping a smaller, more focused feature set in several of my comments. Polish is much more attainable when features aren't being added as frequently. That has to come from the top of the project's management though, since they're ultimately the ones responsible for policy and enforcement. My approach would be as I mentioned elsewhere: allow those wanting to contribute new features to do so, but make it clear that these features will be present in prerelease builds only until their quality meets the project's standards.