Hi Guix, I read about the Cooperative Development Guidelines[1] and it's much better that what I could ever think, so I won't continue that topic now.
Another topic is the review process, this was highlighted in the 2024 survey[2]. After the Codeberg migration there's a speedup, but I can see some other issues remaining. One of them is that, guidelines in the manual don't cover sufficient information and many reviews are based on experience. This makes it difficult to contribute as a reviewer. Andreas also mentioned (<aGqJb4FVeE1l14Ft@jurong>) the need to review reviewed changes: --8<---------------cut here---------------start------------->8--- When I recently came across such a PR, I ended up spending time looking at it again - having someone else approve it gave me confidence and I was probably a bit faster, but since I was taking responsibility by being the one signing the commit, I also did not want to push it blindly. So instead of just one committer spending time on this PR, we ended up being two. --8<---------------cut here---------------end--------------->8--- Since we're mainly dealing with packages changes, which are generally easier to contribute and review, I think we can try to answer the following questions: --8<---------------cut here---------------start------------->8--- - How do you review a package change? - If others have reviewed the change, what information do you need to accept it directly (or with minimum check)? --8<---------------cut here---------------end--------------->8--- Additionally, we can record or write down the process when reviewing and see which parts take more time, what are actually unnecessary, and what are not clear enough. I think this can give us more insights on streamlining it. There's also a direction for bulk updates, which will reduce the need for processing contributions. However I can see there's also a review issue, as replied in <y76wm8d5vr7.fsf@ultrarare.space>. I'm repeating it here again: --8<---------------cut here---------------start------------->8--- I can see an issue with bulk updates is that, while it's easy to prepare the patch series, every requirement added into the review process will be multiplied. It's still fine for a dozen of patches, but beyond that there will be much more stress. Is it possible to divide the changes into chunks that can be reviewed independently? So that the workload at one time can be more reasonable, and this leaves room for others to join in. --8<---------------cut here---------------end--------------->8--- Thanks [1]: https://codeberg.org/msavoritias/Cooperative_Development_Guidelines [2]: https://guix.gnu.org/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/
