On Wed, Mar 15, 2017 at 10:12:18PM -0400, Vijay Bellur wrote: > Hi All, > > We have been working on a proposal [1] to make the lifecycle management of > Gluster maintainers more structured. We intend to make the proposal > effective around 3.11 (May 2016). > > Please review the proposal and let us know your feedback. If you need > clarity on any existing aspect or feel the need for something additional in > the proposal, please feel free to let us know. I'll just include the proposal here and add inline comments. I'm not sure if this is the best way, or if you would like anyone edit the document directly... > Thanks! > Amye & Vijay > > [1] https://hackmd.io/s/SkwiZd4qe > # Revised Maintainers for 3.11 > > AI from Community Meeting, March 1: > amye to work on revised maintainers draft with vbellur to get out for > next maintainer's meeting. We'll approve it 'formally' there, see how it > works for 3.11. The next maintainers meeting happens when many maintainers are at VAULT. I would not expect a large attendance at that time. Also, Amye sent an email with a different target date? > ## Goals: > * Refine how we declare component owners in Gluster > * Create a deeper sense of ownership throughout the open source project > * Welcome more contibutors at a project impacting level It would be good to make a distinction between the Gluster Community and the GlusterFS Project. "Gluster" refers in my understanding to all the projects of the Gluster Community. This document looks most aimed at the GlusterFS project, with some Gluster Community references. > ## Definition of Owners + Peers > * Commit access to the project is not dependent on being a maintainer. A > maintainer is a leadership role within the project to help drive the > project forward. "the project", is that the glusterfs git repository, or any repository that we maintain? How would we see this for projects that contain Gluster modules like NFS-Ganesha and Samba? Or are those not considered as "our" components? > * Owner - Subject matter expert, help design large feature changes and > decide overall goal of the component. Reviews patches, approves > changes. Responsible for recruiting assisting peers. Owner of > component. (Principle Software Engineer - unconnected to actual role > in Red Hat organization) I would say a "subject matter expert" can give a +2 code-review in Gerrit, and the "owner" of the component would honour that opinion. I fail to see what "Principle Software Engineer" has to do with this if it is not connected to a role at Red Hat (hmm, I need to talk to my boss?). > * Peer - assists with design, reviews. Growing into subject matter > expert, but not required to be engaged in the overall design of the > component. Able to work largely without day-to-day supervision. > (Senior Software Engineer - unconnected to actual role in Red Hat > organization) A "peer" would do code-review +1 on the proposed design and/or change. That means it still needs a "subject matter expert" to really approve the change. Hopefully all the straight forward points have been checked by peers for changes (coding style, basic error checking and resource allocation/freeing, test-case, ...). > ## Additional changes: > * Carving out new components needs Project Lead + Community lead > approval - we can expand this as needed. Yes, please expand. Are new projects (like the recent gluster-block) new components? Who is/are Project Lead and Community Lead, are these the same people for all projects in the Gluster Community? > * Project Lead and Community Lead should watch out for people owning > lots of components with no peers. This may lead to burn out. Identify > these owners and assist them in getting new peers. This means that for the GlusterFS project the MAINTAINERS file needs to be maintained very well. How do you plan to keep track of all the other related projects? > * Owners can pick peers for their components with just an announcement. I do not think "peers" should need approval. Is not everyone allowed to review designs and patches? Sending an announcement for new contributors that just reviewed their first patch does not sound scalable. New "peers" can review proposals for any component. I must be missing something here, a better explanation would be most welcome. > ## Transition > * Current maintainers get to choose between ownership/peer of components > they're listed as owners. Well, yes, hopefully everyone being an "owner" or "peer" does so voluntary. Obviously certain companies have an interest in getting their employees to volunteer to do the work (and hopefully the tasks are part of their official job). > * Have people focus on maximum of two components as an owner. If they > have more, they should be strongly suggested to invite new people as > peers to be trained as future owners. If current owners consider > somebody as being ready to take over as owner of a component that they > are managing, please announce new owners with appropriate > justification on maintainers ML. Why two components? The majority of people listed in the glusterfs MAINTAINERS file already have more. And that is only for the glusterfs project, many will have additional projects they are responsible for. > * It's okay to drop a component if they are not able to find > time/energy. Owners are requested to minimize disruption to the > project by helping with transitions and announcing their intentions. Yes, of course :) > * Project Lead and Community Lead are responsible for maintaining the > health of the community. This includes balancing work for component > owners or choosing which components aren't included in the cycle in a > way that minimizes disruption to the project. What "cycle" is meant here? > References: > https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ > https://www.drupal.org/dcoc Maybe also see how QEMU and the Linux kernel handle this? I'm definitely more familiar with those projects than Mozilla or Drupal. Thanks! Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
