[Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal
amye at redhat.com
Mon Apr 17 23:56:07 UTC 2017
Following up on this, this revision cycle is meant to be more clear about
owners + peers, and less focused on the Red Hat shorthand for levels of
As far as further goals, I think we can outline Architects and Leads
responsibility in a further cycle. I'll let Vijay respond to a further
On Fri, Apr 14, 2017 at 3:51 AM, Niels de Vos <ndevos at redhat.com> wrote:
> On Fri, Apr 14, 2017 at 11:40:35AM +0200, Michael Scherer wrote:
> > Le jeudi 13 avril 2017 à 18:01 -0700, Amye Scavarda a écrit :
> > > In light of community conversations, I've put some revisions on the
> > > Maintainers changes, outlined in the hackmd pad:
> > > https://hackmd.io/s/SkwiZd4qe
> > >
> > > Feedback welcomed!
> > >
> > > Note that the goals of this are to expand out our reach as a project
> > > (Gluster.org) and make it easy to define who's a maintainer for what
> > > feature.
> > > I'll highlight the goals in the document here:
> > >
> > > * 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
> > >
> > > We've clarified what the levels of 'owners' and 'peers' are in terms of
> > > responsibility, and we'll look to implement this in the 3.12 cycle.
> > > Thanks!
> > So, I realize that the concept of component is not defined in the
> > document. I assume everybody have a shared understanding about what it
> > is, but maybe not, so wouldn't it make sense to define it more clearly ?
> > Is this planned to be done later as part of "We will be working on
> > carving out new components for things that make logical sense." ?
> > As for example, with regard to my previous comment, would
> > "infrastructure" be a component, would "documentation" be a component ?
> Indeed, that is one of the things that I mentioned in a similar way on
> the previous version of the document. Because the document is aimed at
> the Gluster Community, it should address not only the main GlusterFS
> project, but also other "components maintained by the community". There
> are many different projects in the Gluster Community, of which the
> GlusterFS project is one, infrastructure, documentation and probably all
> repositories under https://github.com/gluster are others. Modules for
> Samba, NFS-Ganesha and other "external" projects probably do not count
> towards "Gluster proper" and are not included in the "Maintainers 2.0"
> approach (mentioning the excluded kinds of projects would be a good
> thing too).
> Also, the other relevant "roles" like "Project Lead", "Community Lead"
> and "Project Architect" need to be explained with their
> responsibilities. A paragraph of their description should probably be
> added to the MAINTAINERS  file when that gets updated too. A single
> naming for the roles would be best (no more "maintainers" anywhere?).
> Where would it be listed who has which role in the Gluster Community?
> When I click through the previous conversation, much of the feedback
> that was given on an earlier version  has not been included or
> addressed it seems. In one of the emails Vijay mentioned a "project
> governance document" is being written, and that should probably give
> more clarity when reading the Maintainers 2.0 proposal. A link to that
> document would be helpful.
> 0. https://github.com/gluster/glusterfs/blob/master/MAINTAINERS
> 1. http://lists.gluster.org/pipermail/maintainers/2017-March/002368.html
Amye Scavarda | amye at redhat.com | Gluster Community Lead
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the maintainers