[Gluster-devel] Maintainers 2.0 Proposal

[Niels de Vos]

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
-------------- 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/20170317/ca606b06/attachment.sig>