In light of community conversations, I've put some revisions on the Maintainers changes, outlined in the hackmd pad:
* 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
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:
* 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!
-- amye
On Sat, Mar 25, 2017 at 2:50 PM, Vijay Bellur <vbellur@xxxxxxxxxx> wrote:
On Sat, Mar 25, 2017 at 8:01 AM, Raghavendra Gowdappa <rgowdapp@xxxxxxxxxx> wrote:
----- Original Message -----
> From: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>
> To: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx>
> Cc: "Amar Tumballi" <atumball@xxxxxxxxxx>, "GlusterFS Maintainers" <maintainers@xxxxxxxxxxx>, "Gluster Devel"
> <gluster-devel@xxxxxxxxxxx>, "Michael Scherer" <mscherer@xxxxxxxxxx>
> Sent: Saturday, March 25, 2017 5:22:44 PM
> Subject: Re: [Gluster-Maintainers] Maintainers 2.0 Proposal
>
>
>
> ----- Original Message -----
> > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx>
> > To: "Michael Scherer" <mscherer@xxxxxxxxxx>
> > Cc: "Amar Tumballi" <atumball@xxxxxxxxxx>, "GlusterFS Maintainers"
> > <maintainers@xxxxxxxxxxx>, "Gluster Devel"
> > <gluster-devel@xxxxxxxxxxx>
> > Sent: Friday, March 24, 2017 7:12:32 PM
> > Subject: Re: [Gluster-Maintainers] 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.
s/manager/maintainer/ :)Agreed. There is a need to define the responsibilities of various roles - architects, project maintainers, project and community leads. We have used some of these terms interchangeably in the past. Will add more details on these roles and provide more clarity.
>
> >
> > On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer < mscherer@xxxxxxxxxx >
> > 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@xxxxxxxxxx >
> > > 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.Agree to all of these. The current guidelines for maintainers / owners lists most of these points as core responsibilities [1].Thanks,Vijay
_______________________________________________
maintainers mailing list
maintainers@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/maintainers
Amye Scavarda | amye@xxxxxxxxxx | Gluster Community Lead
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
