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

[Raghavendra Gowdappa]

----- Original Message -----
> From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> To: "Michael Scherer" <mscherer at redhat.com>
> Cc: "Amar Tumballi" <atumball at redhat.com>, "GlusterFS Maintainers" <maintainers at gluster.org>, "Gluster Devel"
> <gluster-devel at gluster.org>
> Sent: Friday, March 24, 2017 7:12:32 PM
> Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal
> 
> Do we also plan to publish similar guidelines for deciding on Project
> maintainer?

+1 for defining roles, responsibilities and qualifications of a Project manager.

> 
> On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer < mscherer at redhat.com >
> wrote:
> 
> 
> Le samedi 18 mars 2017 à 16:47 +0530, Pranith Kumar Karampuri a écrit :
> > On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi < atumball at redhat.com >
> > wrote:
> > 
> > > I don't want to take the discussions in another direction, but want
> > > clarity on few things:
> > > 
> > > 1. Does maintainers means they are only reviewing/ merging patches?
> > > 2. Should maintainers be responsible for answering ML / IRC questions
> > > (well, they should focus more on documentation IMO).
> > > 3. Who's responsibility is it to keep the gluster.org webpage? I
> > > personally feel the responsibility should be well defined.
> 
> Theses point seems to have been overlooked (as no one answered), yet I
> think they do matter if we want to expand the community besides coders.
> 
> And since one of the goal is to "Welcome more contibutors(sic) at a
> project impacting level", I think we should be also speaking of
> contributions besides code (ie, website, for example, documentation for
> another).
> 
> While on it, I would like to see some points about:
> 
> - ensure that someone is responsible for having the design discussion in
> the open
> - ensure that each feature get proper testing when committed, and the
> maintainers is responsible for making sure this happen
> - ensure that each feature get documented when committed.
> 
> If we think of contribution as a pipeline (kinda like the sales funnel),
> making sure there is documentation also mean people can use the
> software, thus increasing the community, and so helping to recruit
> people in a contributor pipeline.
> 
> Proper testing means that it make refactoring easier, thus easing
> contributions (ie, people can submit patches and see nothing break, even
> for new features), thus also making people likely more at ease to submit
> patches later.
> 
> And making sure the design discussion occurs in the open is also more
> welcoming to contributors, since they can see how we discuss, and learn
> from it.
> 
> And while on it, is there a similar document being prepared about
> Community Lead and Project Lead (especially for transition, etc) ?
> --
> Michael Scherer
> Sysadmin, Community Infrastructure and Platform, OSAS
> 
> 
> 
> 
> 
> --
> Pranith
> 
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>