Hilton Chain <hako@ultrarare.space> writes: > Hi Guix, > > [...] > 1. Setting a minimum requirement for committing changes > > - Require all changes to be submitted first. This is actually enforcing the > commit policy[2]. > > - Add more pull request templates[3], gradually improve them + > documentations > they link to, and consider the pull request ready when suitable template > for > the change is finished. Codeberg doesn't support multiple templates but > we > can have our own rule ;) > > 2. Explicitly turn privileges into responsibilities and encourage the whole > community to join in the development. > > - Users are encouraged to review pull requests they are interested in, they > can comment and provide information to finish the template, with the help > of > the checklist and linked documentations. (comments that are out of the > documented scopes don't have to be addressed, as an approach to improve > the > documentation and avoid receiving conflict reviews while not knowing which > one to follow) > > - Team members are users, additionally since they choose to gain more > permissions, they are committed to reviewing team-specific patches, > editing > pull request descriptions, filling in the right template, and setting > labels > (we can add more labels[4] to help the process). > > - Committers are users and likely team members, additionally since they > choose > to gain more permissions, they are committed to applying pull requests > that > are ready. > > > This might be a GCD topic, but I may not have writing energy to finish one. > Since this also mainly depends on the expectation on Guix, I'm sending the > email > out to see how it goes.
These thoughts began as an attempt to think if there's a possibility to develop Guix without committers[1]. Let's say, we have a program that does the following things[2]: 1. Apply finished contributions. 2. Check the changes don't break ‘guix pull’. 3. Commit the changes. Then we need to define what is a finished contribution. The "Contributing" chapter in the manual seems to be a good fit. With such information, reviews can be carried out only in the documented scopes and key points can be summarized as checklists, saved as pull request templates, and maybe automated with ‘guix lint’. Since the documentation can't be bypassed then, there will be direct motivation to improve it. I also find "team members" and "committers" may contain unnecessary implications, maybe we could define them as: Community members that commit to dedicate part of their time in a given period, to help other community members in the contribution process. With such a definition we can have a better overview of the project, and the information below will be more useful: --8<---------------cut here---------------start------------->8--- For each team: How many team members are there? How many team members are dedicated to this team? How many packages are taken care of by this team? How many packages are not in the scope of any team? --8<---------------cut here---------------end--------------->8--- And we can know which part of the project needs more help. But if we want to ask for help, we need contributors to know how the community is structured and let them feel empowered and accepted. This is my reason to propose documenting review scopes and limiting privileges. Thanks [1]: Of course there must be committers writing to the repository. But since we want to build consensus, we should probably not rely on committers to make too many decisions in the contribution process. This was a thought on continuing the development with formally limited privileges. [2]: What the program does is what the extra things committers do compared to other community members.
