On 17.01.2024 18:10, Kelly Choi wrote: > Hi everyone, > > I've spent a bit of time talking to various individuals and the advisory > board about setting up a new Community Process Group. > > A survey was recently conducted to identify how the community as a whole > feels about a certain situation. It was not intended to ban specific > wording or create a policy to do so, but more to give context that the > community has a wide range of ideas, and individuals may agree and disagree > a lot more frequently than we as individuals might think. It helps us > understand that as a community there are many situations where it is not > clear. As such, the results indicated a very even split among the > community, which indicates a larger problem as we may not always come to > agreement. > > There is obvious frustration with how certain matters are handled, as some > members may want the project to move faster, whereas others like to take a > cautious approach. Given we are an open source project, differences in > opinion are likely to happen and what we don’t want to do is cause further > frustration. > > *This is where I would like to propose the idea of a ‘Community Process > Group’.* > > A CPG can help as they will be able to advise members on similar issues > regarding community processes or appeals and decide on the best way > forward. To help with this process, I have consulted with various > individuals including some committers and conduct team members. > > *What is a CPG’s purpose?* > In the first instance, we would expect an informal vote resolves most > disagreements. However, there will be certain circumstances where the > outcome is not always agreed on. > > A CPG will be your second point of call, where you can escalate matters > quickly for a democratic solution.
Between informal voting and this "second point of call", where does formal voting go? > Their purpose is to resolve process issues and informal vote appeals to > avoid matters going to a formal vote, but also act as a representative on > behalf of others in the community on future matters. > > For example: > > - Naming conventions > - Whether feedback requesting changes on a patch series is acceptable > - How to move forward in case of non-actionable feedback to a patch > series > - How to move forward when a contributor or reviewer has not been > responsive > - Policy questions not related to the code of conduct > > *What is their role and responsibility?* > > The CPG has the authority to propose a resolution to situations where there > are disagreements, that don’t involve large technical decisions. Their > decision proposed should be accepted as final since members will have > discussed the best steps and come to a consensus vote. > > The CPG does not aim to replace the committers' authority or the advisory > board but instead holds the authority to make decisions that are in the > best interest of the community in relation to processes. Committers still > hold the power should there be a formal escalation regarding technical > decisions, but this would be extremely rare. Advisory Board members hold > the final power regarding project and business-wide decisions. Nevertheless it doesn't become clear to me how adding yet another authority besides the committers will actually help. > *How are members selected?* > The CPG will be composed of 5 randomly selected members in total. > An odd number has been purposely selected to avoid an impasse during > decisions. > > The criteria: > Individual members must be active contributors and are willing to help the > community succeed. As such they must be a part of the following groups: > > - Committers > - Active Maintainers: maintainers with >= 20 reviews in the last 2 > releases > - Active Contributors: contributors with >= 10 commits in the last 2 > releases I'm afraid I can't leave this uncommented, as matching a common pattern I'm generally unhappy with. Whatever the numbers you select in such criteria, they'll open up an easy road for faking. At the same time it of course is difficult to come up with any non-numeric or not-only- numeric criteria. For example, I'd be heavily inclined to ask that "non-trivial" be added to both of the numbers. Yet then there arises a judgement issue: What's non-trivial can be entirely different depending on who you ask. What definitely needs clarifying is what "review" is: Are R-b tags counted, or is it the number of replies sent commenting on patches? > Future rotations of CPG members: > New members will be selected randomly for each new release to ensure > fairness. > > *Expectations* > CPG members are expected to use their best judgement of what is best for > the community in terms of conflict resolution and process improvements. > They can propose an outcome that progresses the project forward. > The CPG is also expected to address wider concerns, feedback, and ideas > during a monthly meeting with all community members. > > For example: > > - If someone is displaying repeated concerning behaviour that disrupts > the community, members can ask the CPG for help on a solution. (This is > different from a code of conduct violation which would be for serious > offences only.) > - Help drive discussions on how much we deviate from technical > specifications > > *Next steps* > Given this suggestion is a big change in what I hope is a positive > direction, we will require your feedback and a final formal vote on the > process, before it is implemented into the governance policies. The > specific wording can be decided after this proposal. > > This will hopefully help us overcome some of the frustrations and issues we > have seen in the community from a difference in opinion as a collective > discussion will now be made. Should we need to, the process can be reviewed > to improve at later stages. Related to what I said earlier: Should it turn out that disagreement within the CPG is difficult to deal with, will we then gain yet another authority? Imo before adding such a new instance, it wants properly sorting - why with what we already have we can't deal with the (supposedly few) situations, and - in how far introducing a new instance will (likely) once and for all avoid similar situations arising again, just one layer up (i.e. to make sure there's no scalability issue, due to proliferation of instances). Jan
