-
Hi, we've recently noticed a huge problem in our development process that ultimately hampers our productivity and our ability to make a first release. It's also a thing that generally exists in free and open source software development and constitutes it as very hostile towards beginners that are just starting out. Proposed changes to our code. Also known as "pull requests" on GitHub, or "patches" elsewhere. There are many times where a contributor may devote hours, days, or even weeks to a specific change, only to have these shot down by another contributor because of a fundamental disagreement with the change that should have been probably brought up earlier before all of that time was devoted. We want to figure out a way that we'll be able to debate and agree on preliminary changes (e.g. changing the order of some icons), and then only evaluate the implementation that was used for that said change (did it work?) afterwards. It's important that the developers/contributors will also remain engaged later on, just so that we won't have any unpleasant surprises. What do you think? (Please consider that recommendations made by existing contributors/maintainers may have more gravity. Nevertheless, we strive to be community-led, which also means allowing the community to help us, so we are open to all feedback.) Summarized list of ideas (I'll keep this updated):
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 6 replies
-
I don't think there's much of a difference between mailing lists and GitHub Discussions, apart from Markdown, and the need for a GitHub account. I think the mailing list is more appropriate. |
Beta Was this translation helpful? Give feedback.
I don't think there's much of a difference between mailing lists and GitHub Discussions, apart from Markdown, and the need for a GitHub account. I think the mailing list is more appropriate.