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

[Niels de Vos]

On Mon, Apr 17, 2017 at 04:53:55PM -0700, Amye Scavarda wrote:
> On Fri, Apr 14, 2017 at 2:40 AM, Michael Scherer <mscherer at redhat.com>
> 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 ?
> >
> > My understanding is that there's a working spreadsheet being refined to
> sort out what's an area that needs a maintainer defined, and what's
> something that maybe doesn't need a named maintainer. Documentation is a
> tricky place to get to, because that's something that you do just naturally
> so that future-you doesn't hate current-you.

I agree that documentation should be part of the standard development
workflow. Unfortunately, this is not something that gets done without
reminding everyone about it. We still need maintainers/owners to bug
developers for documentation of new features, monitor the pull-request
queue and decide if the documentation is written in an acceptible way.
The maintenance of the gluster.readthedocs.io site might be a
infrastructure task?

At least for every component/task, we should have an 'owner' that can
be reached when someone has questions or problems are reported.

Thanks,
Niels


> However, I'll see if I can't find that spreadsheet because the above
> document is more guidelines than practical reality.
> Anything else?
>  - amye
> 
> 
> > --
> > Michael Scherer
> > Sysadmin, Community Infrastructure and Platform, OSAS
> >
> >
> >
> > _______________________________________________
> > maintainers mailing list
> > maintainers at gluster.org
> > http://lists.gluster.org/mailman/listinfo/maintainers
> >
> >
> 
> 
> -- 
> Amye Scavarda | amye at redhat.com | Gluster Community Lead

> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers

-------------- 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/20170418/0e0c1c3c/attachment.sig>