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

[Amar Tumballi]

All,

Thanks for participating actively in the discussions. With all your
co-operation we now have a update on maintainers 2.0 proposal. Vijay Bellur
sent a patch last week [1] capturing all the discussions.

Please go through the patch and see if you have any more concerns. There
are many new names in there, so just review it so you can Ack it. Niels
(ndevos) added all the people with their name on maintainers file as
reviewers for the patch. Please take some time today and give +1 to it to
acknowledge you are aware of the responsibilities. After 20 or more +1 on
the patch, we will merge the patch, and accordingly raise a ticket to
update the access to merge rights etc.

Also, if your name is added in maintainers list (even as peer for
component), please become member of Maintainers mailing list [2] This list
is an open list (all archives available for anyone to read) so make sure
you subscribe and become members.  Make sure you update your calendars with
maintainer meeting timings, so you can attend it.

[1] - https://review.gluster.org/17583
[2] - http://lists.gluster.org/mailman/listinfo/maintainers

Main maintainers 2.0 proposal link: https://hackmd.io/s/SkwiZd4qe

Write back if you have any more concerns.

Regards,
Amar



On Tue, Apr 18, 2017 at 2:27 PM, Michael Scherer <mscherer at redhat.com>
wrote:

> Le mardi 18 avril 2017 à 10:25 +0200, Niels de Vos a écrit :
> > 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.
>
> There is also the overall issue iof documentation consistency. For
> example, style, glossary, etc, all kind of stuff that shouldn't be per
> component but aligned overall.
>
> > The maintenance of the gluster.readthedocs.io site might be a
> > infrastructure task?
>
> Wouldn't it be more logical to have it managed by the people that did
> champion RTD ? I am unable to find the discussions about it, but I am
> quite sure I had some concerns regarding RTD and wouldn't volunteer to
> maintain something where I had objections (such as "being unable to fix
> anything" is quite high on my usual objection list for taking
> responsibility of a piece of infra)
> --
> Michael Scherer
> Sysadmin, Community Infrastructure and Platform, OSAS
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170629/c97aa976/attachment.html>