[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Community Process Group - Proposal
- AB
Hi Jan, Please see my reply to the points below Many thanks, Kelly Choi
Community Manager Xen Project
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
|
