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

[Amye Scavarda]

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

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
governance document.
 -amye

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 [0] 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 [1] 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.
>
> Thanks,
> Niels
>
>
> 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...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170417/d86512dc/attachment-0001.html>