Hi Yann, See my reply below
On Thu, Jan 18, 2024 at 10:09 AM Yann Dirson <[email protected]> wrote: > Hi all, > > On 1/17/24 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’.* > > That made me look for a list of official roles in the project, which I > found at [0]. How up-to-date is this list? The Release Manager role is > mentioned there but not described, the Community Manager role is not > mentioned at all, and the only link to get project leadership info [1] > redirects to unrelated information. > > [0] https://xenproject.org/developers/governance/#roles-local > [1] https://xenproject.org/developers/teams/hypervisor > > I feel it would be necessary to have a clear view on the current > situation, before adding more structures. > Aspects of the information on the website are outdated and do require reviewing as part of a wider governance update. However, the majority of the information such as the roles of committers is still accurate. In this specific instance, the CPG would act fairly similar to a project lead in terms of progressing the project forward. Rather than it being one person, it will be a collective group of elected members. From my understanding, we haven't had a project lead for a very long time within the project and this was before the governance was formalized. If the community is happy, we can replace the project lead role with the CPG. For clarification, this is the current governance policy in relation to the project lead/leadership team: *"Sub-projects and teams hosted on Xenproject.org are not democracies but meritocracies. In situations where there is disagreement on issues related to the day-to-day running of the project, the project leadership team is expected to act as referee and make a decision on behalf of the community. Projects leadership teams can choose to delegate entire classes of conflict resolution issues to community members and/or the project lead (e.g. the project can choose to delegate refereeing on committer disagreements to the project lead; or it could choose a specific committer to always act as referee amongst a group of committers). Any such delegation needs to be approved as normal and has to be documented.* *Should a project leadership team become dysfunctional or paralysed, the project leadership team or project lead should work with the community manager or advisory board to find a way forward.In situations where the entire Xen Project community becomes paralysed the impacted project leadership teams or project leads should work with the community manager or advisory board to find a way forward.* I will take your feedback on board to add descriptions to the release manager role and propose this to the mailing list. You will find the description of the community manager role on the page under 'Xen Project wide roles'. > > > > > 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. > > > > 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. > > > > *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. > > Do you have any specific idea of how "randomly selected" would work? > I mean, having a die rolled behind closed doors is not going to help > building trust. Now there are rather-simple algorithms for Distributed > Dice Rolling, like [2], but there would be a few practical details to > make explicit. > > [2] > > https://stackoverflow.com/questions/224058/distributed-random-number-generation > > I'd propose using a live random name selector on the community call, to ensure transparency. We would, of course, have the full names of people who fit the criteria below before we can do this. > > > 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 > > > > 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. > > > > I welcome your feedback as a community on this proposal. > > > > Many thanks, > > Kelly Choi > > > > Community Manager > > Xen Project > > > Yann Dirson | Vates Platform Developer > > XCP-ng & Xen Orchestra - Vates solutions > > web: https://vates.tech > >
