<div dir="ltr">Posting in line, but it may be pretty hard to follow. <div>Apologies if I miss something. <br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 17, 2017 at 11:06 AM, Niels de Vos <span dir="ltr">&lt;<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@redhat.com</a>&gt;</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-">On Wed, Mar 15, 2017 at 10:12:18PM -0400, Vijay Bellur wrote:<br>
&gt; Hi All,<br>
&gt;<br>
&gt; We have been working on a proposal [1] to make the lifecycle management of<br>
&gt; Gluster maintainers more structured. We intend to make the proposal<br>
&gt; effective around 3.11 (May 2016).<br>
&gt;<br>
&gt; Please review the proposal and let us know your feedback. If you need<br>
&gt; clarity on any existing aspect or feel the need for something additional in<br>
&gt; the proposal, please feel free to let us know.<br>
<br>
</span>I&#39;ll just include the proposal here and add inline comments. I&#39;m not<br>
sure if this is the best way, or if you would like anyone edit the<br>
document directly...<br>
<span class="gmail-"><br>
&gt; Thanks!<br>
&gt; Amye &amp; Vijay<br>
&gt;<br>
&gt; [1]  <a href="https://hackmd.io/s/SkwiZd4qe" rel="noreferrer" target="_blank">https://hackmd.io/s/SkwiZd4qe</a><br>
<br>
<br>
<br>
</span>&gt; # Revised Maintainers for 3.11<br>
&gt;<br>
&gt; AI from Community Meeting, March 1:<br>
&gt; amye to work on revised maintainers draft with vbellur to get out for<br>
&gt; next maintainer&#39;s meeting. We&#39;ll approve it &#39;formally&#39; there, see how it<br>
&gt; works for 3.11.<br>
<br>
The next maintainers meeting happens when many maintainers are at VAULT.<br>
I would not expect a large attendance at that time. Also, Amye sent an<br>
email with a different target date?<br></blockquote><div><br></div><div>Feedback target date of 30 days, that&#39;s what I was indicating. This was reviewed in the maintainers&#39; meeting on March 8 and we&#39;re now expanding out to the larger group.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; ## Goals:<br>
&gt; * Refine how we declare component owners in Gluster<br>
&gt; * Create a deeper sense of ownership throughout the open source project<br>
&gt; * Welcome more contibutors at a project impacting level<br>
<br>
It would be good to make a distinction between the Gluster Community and<br>
the GlusterFS Project. &quot;Gluster&quot; refers in my understanding to all the<br>
projects of the Gluster Community. This document looks most aimed at the<br>
GlusterFS project, with some Gluster Community references. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><div>Is this distinction relevant? We&#39;re talking about how we define a maintainer for contributing to the Gluster community overall. As I work through this, I see your confusion. I don&#39;t think that we&#39;d be able to make this call for &#39;all related projects&#39;, but for committing back into Gluster proper, yes.</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"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; ## Definition of Owners + Peers<br>
&gt; * Commit access to the project is not dependent on being a maintainer. A<br>
&gt;   maintainer is a leadership role within the project to help drive the<br>
&gt;   project forward.<br>
<br>
&quot;the project&quot;, is that the glusterfs git repository, or any repository<br>
that we maintain? How would we see this for projects that contain<br>
Gluster modules like NFS-Ganesha and Samba? Or are those not considered<br>
as &quot;our&quot; components?</blockquote><div><br></div><div>I think initially, we&#39;d want to limit this to just the Gluster project. Too much expansion and we&#39;ll have too much change too quickly. </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"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; * Owner - Subject matter expert, help design large feature changes and<br>
&gt;   decide overall goal of the component. Reviews patches, approves<br>
&gt;   changes. Responsible for recruiting assisting peers. Owner of<br>
&gt;   component. (Principle Software Engineer - unconnected to actual role<br>
&gt;   in Red Hat organization)<br>
<br>
I would say a &quot;subject matter expert&quot; can give a +2 code-review in<br>
Gerrit, and the &quot;owner&quot; of the component would honour that opinion. I<br>
fail to see what &quot;Principle Software Engineer&quot; has to do with this if it<br>
is not connected to a role at Red Hat (hmm, I need to talk to my boss?).<br>
<br></blockquote><div><br></div><div>I&#39;ve gotten feedback that we should revisit the &#39;Principal&#39; vs &#39;Senior&#39; framing - apologies. It was not the intention to make it Red Hat centric in this way, but it was shorthand for responsibility areas. I&#39;m happy to revisit. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; * Peer - assists with design, reviews. Growing into subject matter<br>
&gt;   expert, but not required to be engaged in the overall design of the<br>
&gt;   component. Able to work largely without day-to-day supervision.<br>
&gt;   (Senior Software Engineer -  unconnected to actual role in Red Hat<br>
&gt;   organization)<br>
<br>
A &quot;peer&quot; would do code-review +1 on the proposed design and/or change.<br>
That means it still needs a &quot;subject matter expert&quot; to really approve<br>
the change. Hopefully all the straight forward points have been checked<br>
by peers for changes (coding style, basic error checking and resource<br>
allocation/freeing, test-case, ...).<br>
<br></blockquote><div>Correct. This person could also be your backup for making sure the feature moves forward! </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; ## Additional changes:<br>
&gt; * Carving out new components needs Project Lead + Community lead<br>
&gt;   approval  - we can expand this as needed.<br>
<br>
Yes, please expand. Are new projects (like the recent gluster-block) new<br>
components? Who is/are Project Lead and Community Lead, are these the<br>
same people for all projects in the Gluster Community?<br></blockquote><div><br></div><div>Expand meaning - as we adopt this for Gluster project. Not including &#39;all the various connected projects&#39;. Too far for this particular rollout.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; * Project Lead and Community Lead should watch out for people owning<br>
&gt;   lots of components with no peers. This may lead to burn out. Identify<br>
&gt;   these owners and assist them in getting new peers.<br>
<br>
This means that for the GlusterFS project the MAINTAINERS file needs to<br>
be maintained very well. How do you plan to keep track of all the other<br>
related projects? </blockquote><div> </div><div>The maintainers file does need to be regularly reviewed and updated. Think of it like the &#39;phone tree&#39; for the project. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; * Owners can pick peers for their components with just an announcement.<br>
<br>
I do not think &quot;peers&quot; should need approval. Is not everyone allowed to<br>
review designs and patches? Sending an announcement for new contributors<br>
that just reviewed their first patch does not sound scalable. New<br>
&quot;peers&quot; can review proposals for any component. I must be missing<br>
something here, a better explanation would be most welcome.<br>
<br></blockquote><div>We&#39;ll need to know who we&#39;d go to for a backup. A peer would be someone you&#39;d trust to be able to maintain a feature in your absence. Better clarification? </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">
&gt; ## Transition<br>
&gt; * Current maintainers get to choose between ownership/peer of components<br>
&gt;   they&#39;re listed as owners.<br>
<br>
Well, yes, hopefully everyone being an &quot;owner&quot; or &quot;peer&quot; does so<br>
voluntary. Obviously certain companies have an interest in getting their<br>
employees to volunteer to do the work (and hopefully the tasks are part<br>
of their official job).  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; * Have people focus on maximum of two components as an owner. If they<br>
&gt;   have more, they should be strongly suggested to invite new people as<br>
&gt;   peers to be trained as future owners. If current owners consider<br>
&gt;   somebody as being ready to take over as owner of a component that they<br>
&gt;   are managing, please announce new owners with appropriate<br>
&gt;   justification on maintainers ML.<br>
<br>
Why two components? The majority of people listed in the glusterfs<br>
MAINTAINERS file already have more. And that is only for the glusterfs<br>
project, many will  have additional projects they are responsible for.<br>
<br></blockquote><div>We started with two to see how many people will be affected by this - just limiting to Gluster. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; * It&#39;s okay to drop a component if they are not able to find<br>
&gt;   time/energy. Owners are requested to minimize disruption to the<br>
&gt;   project by helping with transitions and announcing their intentions.<br>
<br>
Yes, of course :)<br>
<br>
&gt; * Project Lead and Community Lead are responsible for maintaining the<br>
&gt;   health of the community. This includes balancing work for component<br>
&gt;   owners or choosing which components aren&#39;t included in the cycle in a<br>
&gt;   way that minimizes disruption to the project.<br>
<br>
What &quot;cycle&quot; is meant here?<br></blockquote><div><br></div><div>Release cycle. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; References:<br>
&gt; <a href="https://www.mozilla.org/en-US/about/governance/policies/module-ownership/" rel="noreferrer" target="_blank">https://www.mozilla.org/en-US/<wbr>about/governance/policies/<wbr>module-ownership/</a><br>
&gt; <a href="https://www.drupal.org/dcoc" rel="noreferrer" target="_blank">https://www.drupal.org/dcoc</a><br>
<br>
Maybe also see how QEMU and the Linux kernel handle this? I&#39;m definitely<br>
more familiar with those projects than Mozilla or Drupal.</blockquote><div><br></div><div>Want to add in more detail from those? These were the initial references from where I&#39;d started, happy to see if there are features from other communities.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks!<br>
<span class="gmail-HOEnZb"><font color="#888888">Niels<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Amye Scavarda | <a href="mailto:amye@redhat.com" target="_blank">amye@redhat.com</a> | Gluster Community Lead</div></div>
</div></div></div>