[Gluster-devel] Maintainers 2.0 Proposal

Sat Mar 18 13:20:16 UTC 2017

On Sat, Mar 18, 2017 at 01:20:31AM +0530, Amar Tumballi wrote:
> I don't want to take the discussions in another direction, but want clarity
> on few things:
> 
> 1. Does maintainers means they are only reviewing/ merging patches?
> 2. Should maintainers be responsible for answering ML / IRC questions
> (well, they should focus more on documentation IMO).

IMHO maintainers should be *very* responsive to threads about
development and feature topics. Less for users. The majority of the
users topics should be addressed by non-maintainers that (hopefully)
have a little more time than most of the maintainers. The document
speaks about Owners+Peers though, so the intention may be a little
different.

> 3. Who's responsibility is it to keep the gluster.org webpage? I personally
> feel the responsibility should be well defined.

This is a different project in the Gluster Community... Just like other
projects there need to be someone (or a group) that is responsible for
keeping the different projcets in sync.

> 4. Can a component have more than 1 owner ? 1 maintainers etc?

In addition to that, it would be good to have a further explanation of
how the current structure fits in the new proposal.

Currently we have something like component maintainers, and feature
owners (often across components). I see the architects as the project
leads for the GlusterFS project who keep an eye on everything across the
Gluster Community and make sure things for users and related projects
match or/and are being worked on in the GlusterFS project.

> Some of these questions should be clearly answered in document IMO.

Yes, definitely!

Cheers,
Niels

> 
> Regards,
> Amar
> 
> 
> On Fri, Mar 17, 2017 at 11:55 PM, Amye Scavarda <amye at redhat.com> wrote:
> 
> > 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/modu
> >> le-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
> >
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://lists.gluster.org/mailman/listinfo/gluster-devel
> >
> 
> 
> 
> -- 
> Amar Tumballi (amarts)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170318/a36bf4be/attachment.sig>