On Fri, Mar 17, 2017 at 07:06:53PM +0100, Niels de Vos wrote: > 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 Also, what about the "Architects" we have in the GlusterFS project? Should those not be mentioned in some way or form as well? Niels > > * 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
