<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"><<a href="mailto:ndevos@redhat.com" target="_blank">ndevos@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-">On Wed, Mar 15, 2017 at 10:12:18PM -0400, Vijay Bellur wrote:<br>
> Hi All,<br>
><br>
> We have been working on a proposal [1] to make the lifecycle management of<br>
> Gluster maintainers more structured. We intend to make the proposal<br>
> effective around 3.11 (May 2016).<br>
><br>
> Please review the proposal and let us know your feedback. If you need<br>
> clarity on any existing aspect or feel the need for something additional in<br>
> the proposal, please feel free to let us know.<br>
<br>
</span>I'll just include the proposal here and add inline comments. I'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>
> Thanks!<br>
> Amye & Vijay<br>
><br>
> [1] <a href="https://hackmd.io/s/SkwiZd4qe" rel="noreferrer" target="_blank">https://hackmd.io/s/SkwiZd4qe</a><br>
<br>
<br>
<br>
</span>> # Revised Maintainers for 3.11<br>
><br>
> AI from Community Meeting, March 1:<br>
> amye to work on revised maintainers draft with vbellur to get out for<br>
> next maintainer's meeting. We'll approve it 'formally' there, see how it<br>
> 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's what I was indicating. This was reviewed in the maintainers' meeting on March 8 and we'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>
> ## Goals:<br>
> * Refine how we declare component owners in Gluster<br>
> * Create a deeper sense of ownership throughout the open source project<br>
> * 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. "Gluster" 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'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't think that we'd be able to make this call for 'all related projects', 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">
> ## Definition of Owners + Peers<br>
> * Commit access to the project is not dependent on being a maintainer. A<br>
> maintainer is a leadership role within the project to help drive the<br>
> project forward.<br>
<br>
"the project", 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 "our" components?</blockquote><div><br></div><div>I think initially, we'd want to limit this to just the Gluster project. Too much expansion and we'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">
> * Owner - Subject matter expert, help design large feature changes and<br>
> decide overall goal of the component. Reviews patches, approves<br>
> changes. Responsible for recruiting assisting peers. Owner of<br>
> component. (Principle Software Engineer - unconnected to actual role<br>
> in Red Hat organization)<br>
<br>
I would say a "subject matter expert" can give a +2 code-review in<br>
Gerrit, and the "owner" of the component would honour that opinion. I<br>
fail to see what "Principle Software Engineer" 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've gotten feedback that we should revisit the 'Principal' vs 'Senior' framing - apologies. It was not the intention to make it Red Hat centric in this way, but it was shorthand for responsibility areas. I'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">
> * Peer - assists with design, reviews. Growing into subject matter<br>
> expert, but not required to be engaged in the overall design of the<br>
> component. Able to work largely without day-to-day supervision.<br>
> (Senior Software Engineer - unconnected to actual role in Red Hat<br>
> organization)<br>
<br>
A "peer" would do code-review +1 on the proposed design and/or change.<br>
That means it still needs a "subject matter expert" 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">
> ## Additional changes:<br>
> * Carving out new components needs Project Lead + Community lead<br>
> 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 'all the various connected projects'. 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>
> * Project Lead and Community Lead should watch out for people owning<br>
> lots of components with no peers. This may lead to burn out. Identify<br>
> 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 'phone tree' 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">
> * Owners can pick peers for their components with just an announcement.<br>
<br>
I do not think "peers" 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>
"peers" 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'll need to know who we'd go to for a backup. A peer would be someone you'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">
> ## Transition<br>
> * Current maintainers get to choose between ownership/peer of components<br>
> they're listed as owners.<br>
<br>
Well, yes, hopefully everyone being an "owner" or "peer" 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>
> * Have people focus on maximum of two components as an owner. If they<br>
> have more, they should be strongly suggested to invite new people as<br>
> peers to be trained as future owners. If current owners consider<br>
> somebody as being ready to take over as owner of a component that they<br>
> are managing, please announce new owners with appropriate<br>
> 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">
> * It's okay to drop a component if they are not able to find<br>
> time/energy. Owners are requested to minimize disruption to the<br>
> project by helping with transitions and announcing their intentions.<br>
<br>
Yes, of course :)<br>
<br>
> * Project Lead and Community Lead are responsible for maintaining the<br>
> health of the community. This includes balancing work for component<br>
> owners or choosing which components aren't included in the cycle in a<br>
> way that minimizes disruption to the project.<br>
<br>
What "cycle" 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>
> References:<br>
> <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>
> <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'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'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>