<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 25, 2017 at 8:01 AM, Raghavendra Gowdappa <span dir="ltr"><<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
----- Original Message -----<br>
> From: "Raghavendra Gowdappa" <<a href="mailto:rgowdapp@redhat.com">rgowdapp@redhat.com</a>><br>
> To: "Pranith Kumar Karampuri" <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>><br>
> Cc: "Amar Tumballi" <<a href="mailto:atumball@redhat.com">atumball@redhat.com</a>>, "GlusterFS Maintainers" <<a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a>>, "Gluster Devel"<br>
</span><span class="gmail-">> <<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>>, "Michael Scherer" <<a href="mailto:mscherer@redhat.com">mscherer@redhat.com</a>><br>
> Sent: Saturday, March 25, 2017 5:22:44 PM<br>
> Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Pranith Kumar Karampuri" <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>><br>
> > To: "Michael Scherer" <<a href="mailto:mscherer@redhat.com">mscherer@redhat.com</a>><br>
> > Cc: "Amar Tumballi" <<a href="mailto:atumball@redhat.com">atumball@redhat.com</a>>, "GlusterFS Maintainers"<br>
> > <<a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a>>, "Gluster Devel"<br>
> > <<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>><br>
> > Sent: Friday, March 24, 2017 7:12:32 PM<br>
> > Subject: Re: [Gluster-Maintainers] [Gluster-devel] Maintainers 2.0 Proposal<br>
> ><br>
> > Do we also plan to publish similar guidelines for deciding on Project<br>
> > maintainer?<br>
><br>
> +1 for defining roles, responsibilities and qualifications of a Project<br>
> manager.<br>
<br>
</span>s/manager/maintainer/ :)<br></blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> ><br>
> > On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer < <a href="mailto:mscherer@redhat.com">mscherer@redhat.com</a> ><br>
> > wrote:<br>
> ><br>
> ><br>
> > Le samedi 18 mars 2017 à 16:47 +0530, Pranith Kumar Karampuri a écrit :<br>
> > > On Sat, Mar 18, 2017 at 1:20 AM, Amar Tumballi < <a href="mailto:atumball@redhat.com">atumball@redhat.com</a> ><br>
> > > wrote:<br>
> > ><br>
> > > > I don't want to take the discussions in another direction, but want<br>
> > > > clarity on few things:<br>
> > > ><br>
> > > > 1. Does maintainers means they are only reviewing/ merging patches?<br>
> > > > 2. Should maintainers be responsible for answering ML / IRC questions<br>
> > > > (well, they should focus more on documentation IMO).<br>
> > > > 3. Who's responsibility is it to keep the <a href="http://gluster.org" rel="noreferrer" target="_blank">gluster.org</a> webpage? I<br>
> > > > personally feel the responsibility should be well defined.<br>
> ><br>
> > Theses point seems to have been overlooked (as no one answered), yet I<br>
> > think they do matter if we want to expand the community besides coders.<br>
> ><br>
> > And since one of the goal is to "Welcome more contibutors(sic) at a<br>
> > project impacting level", I think we should be also speaking of<br>
> > contributions besides code (ie, website, for example, documentation for<br>
> > another).<br>
> ><br>
> > While on it, I would like to see some points about:<br>
> ><br>
> > - ensure that someone is responsible for having the design discussion in<br>
> > the open<br>
> > - ensure that each feature get proper testing when committed, and the<br>
> > maintainers is responsible for making sure this happen<br>
> > - ensure that each feature get documented when committed.<br>
> ><br>
> > If we think of contribution as a pipeline (kinda like the sales funnel),<br>
> > making sure there is documentation also mean people can use the<br>
> > software, thus increasing the community, and so helping to recruit<br>
> > people in a contributor pipeline.<br>
> ><br>
> > Proper testing means that it make refactoring easier, thus easing<br>
> > contributions (ie, people can submit patches and see nothing break, even<br>
> > for new features), thus also making people likely more at ease to submit<br>
> > patches later.<br>
> ><br>
> > And making sure the design discussion occurs in the open is also more<br>
> > welcoming to contributors, since they can see how we discuss, and learn<br>
> > from it.<br></div></div></blockquote><div><br></div><div><br></div><div>Agree to all of these. The current guidelines for maintainers / owners lists most of these points as core responsibilities [1].</div><div><br></div><div>Thanks,</div><div>Vijay</div><div><br></div><div> [1] <a href="https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/">https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/</a></div></div></div></div>