[Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal

[Amye Scavarda]

Posting in line, but it may be pretty hard to follow.
Apologies if I miss something.

On Fri, Mar 17, 2017 at 11:06 AM, Niels de Vos <ndevos at redhat.com> 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?
>

Feedback target date of 30 days, that's what I was indicating. This was
reviewed in the maintainers' meeting on March 8 and we're now expanding out
to the larger group.

>
> > ## 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.



Is this distinction relevant? We're talking about how we define a
maintainer for contributing to the Gluster community overall. As I work
through this, I see your confusion. I don't think that we'd be able to make
this call for 'all related projects', but for committing back into Gluster
proper, yes.


>
> ## 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?


I think initially, we'd want to limit this to just the Gluster project. Too
much expansion and we'll have too much change too quickly.


>
> * 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?).
>
>
I've gotten feedback that we should revisit the 'Principal' vs 'Senior'
framing - apologies. It was not the intention to make it Red Hat centric in
this way, but it was shorthand for responsibility areas. I'm happy to
revisit.


> > * 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, ...).
>
> Correct. This person could also be your backup for making sure the feature
moves forward!


> > ## 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?
>

Expand meaning - as we adopt this for Gluster project. Not including 'all
the various connected projects'. Too far for this particular rollout.

>
> > * 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?


The maintainers file does need to be regularly reviewed and updated. Think
of it like the 'phone tree' for the project.

> > * 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.
>
> We'll need to know who we'd go to for a backup. A peer would be someone
you'd trust to be able to maintain a feature in your absence. Better
clarification?

> ## 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.
>
> We started with two to see how many people will be affected by this - just
limiting to Gluster.


> > * 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?
>

Release cycle.


>
> > 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.


Want to add in more detail from those? These were the initial references
from where I'd started, happy to see if there are features from other
communities.

>
>
Thanks!
> Niels
>



-- 
Amye Scavarda | amye at redhat.com | Gluster Community Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170317/be51d482/attachment.html>