- AB Hi Jan, Please see my reply to the points below
Many thanks, Kelly Choi Community Manager Xen Project On Mon, Jan 22, 2024 at 10:32 AM Jan Beulich <jbeul...@suse.com> wrote: > 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? > Formal voting among committers will still exist in matters related to technical decisions. The CPG handles disputes around processes and areas where there are disagreements that can cause frustration around the community, but don't necessarily break the code of conduct. For example, naming conventions or how to move forward in cases of non-actionable feedback. > > > 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. > We've seen cases where committers can disagree, and rather than calling a formal vote each time among those that disagree, the wider community can help provide clarity on the best steps forward. The individuals in this CPG aim to help represent wider collective feedback and prevent disagreements from coming to a standstill, which we have seen in the past. > > > *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? > Please see Stefano's reply > > > 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). > If we are looking at the current landscape, open-source projects tend to have disagreements as individuals will have varying opinions. When committers are at a standstill, it tends to be because we cannot agree on an outcome. As we have seen in the past, there are situations where members have disagreed even during an informal vote. Those matters wouldn't be appropriate for a formal vote either, and we previously didn't have anything in between to move those disputes forward. I appreciate it adds another layer of complexity but given that the CPG is representative of the community, their decision should be the one that stands to help the project progress. This also helps give a voice to the many members in our community, who are passionate about improving Xen. Until we try something new, there is no guarantee that staying stagnant will improve existing conflict. > Jan >
