<div dir="ltr">Do we also plan to publish similar guidelines for deciding on Project maintainer?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 24, 2017 at 2:24 AM, Michael Scherer <span dir="ltr"><<a href="mailto:mscherer@redhat.com" target="_blank">mscherer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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>> 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>
</span>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>
<br>
And while on it, is there a similar document being prepared about<br>
Community Lead and Project Lead (especially for transition, etc) ?<br>
<span class="HOEnZb"><font color="#888888">--<br>
Michael Scherer<br>
Sysadmin, Community Infrastructure and Platform, OSAS<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div>