<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 5:46 PM, Dean Troyer <span dir="ltr"><<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Do you feel like a core deveper/reviewer (we initially called them core developers) [1]:<br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div>In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team.</div></div></div></div></blockquote><div><div><div>Or a maintainer [1]:</div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><div><div>1. They share responsibility in the project’s success.</div></div></div></div><div><div><div><div>2. They have made a long-term, recurring time investment to improve the project.</div></div></div></div><div><div><div><div>3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun.</div></div></div></div></blockquote></div></blockquote><div><br></div></span><div><div>First, I don't think these two things are mutually exclusive, that's a false dichotomy.  They sound like two groups of attributes (or roles), both of which must be earned in the eyes of the rest of the project team.  Frankly, being a PTL is your maintainer list on steroids for some projects, except that the PTL is directly elected.</div></div></div></div></div></blockquote><div><br></div><div>Yes, these are not orthogonal ideas. The question should be rephrased to 'which description do you identify the most with: core developer/reviewer or maintainer?'</div><div><br></div><div>P.S. if you read the linked spec, you will see the maintainer definition is straight from docker.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one.</div></div></blockquote></div></blockquote><div><br></div></span><div>The best maintainers appear to be invisible because stuff Just Works(TM).</div><div><br></div><div>It feels to me like a couple of things are being conflated here and need to be explicitly stated to break the conversation down into meaningful parts that can be discussed without getting side-tracked:</div><div><br></div><div>a) How do we scale?  How do we spread the project management load?  How do we maintain consistency in subteams/subsystems?</div><div><br></div><div>b) How do we avoid the 'aristoctacy'? </div></div><div><br></div><div>c) what did I miss?</div><div><br></div></div></div></blockquote><div><br></div><div>Well said.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div></div><div>Taking b) first, the problem being solved needs to be stated.  Is it to avoid 'cliques'?  Are feelings being hurt because some are 'more-core' than others?  Is it to remove being a core team member as a job-review checkbox for some companies?  This seems to be bigger than just increasing core reviewer numbers, and tied to some developers being slighted in some way.</div></div></div></blockquote><div><br></div><div>I am honestly not actually clear on what this one really means. I think this originates from some of the oral history of OpenStack. As <span style="font-size:12.8000001907349px">Thierry's</span> said "<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px">No committers or repo owners, no aristocracy,"  I think this is related to OpenStack's notion of a flat core team where members of the core team was supposed to be fungible, and all trust each other.</span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.8000001907349px">I don't think this is about removing being a core from a job review checkbox, this may be about inter company/team politics? Not really sure though.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div></div><div>A) is an organization structure problem.  We're seeing the boundaries of startup-style flat organization, and I think we all know we don't want  traditional enterprise layers of managers.</div></div></div></blockquote><div><br></div><div>Yes, well said we are seeing the boundaries of the flat style origination in many of the larger projects.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>It seems like there is a progression of advancement for team members:  prove yourself and become a core team member/reviewer/whatever.  The next step is what I think you want to formalize Joe, and that is those who again prove themselves in some manner to unlock the 'maintainer' achievements.</div></div></div></blockquote><div><br></div><div>Two comments</div><div><br></div><div>1. Yes, I think we need to clarify the next step once you prove yourself. This is exactly what neutron is doing in there patch.</div><div>2. There is a really big second part to this, which is figure a way  to scale the 'core teams' beyond that magical size of 20 people. See more below.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>The idea of taking the current becoming-core-team process and repeating it based on existing cores and PTL recommendations doesn't seem like too far of a stretch.  I mean really, is any project holding back people who want to do the maintainer role on more than just one pet part of a project? (I know those exist)<br></div><div><br></div></div></div></blockquote><div><br></div><div>I am more concerned about empowering people with the inverse desire. Empower people who are interested in one subsection of a project to be empowered to help maintain that piece and share some of the review/maintenance burden. Take the nova db for example. Pulling the nova db out into its own repo is a lot more pain then its worth, but there are definitely people who are just interested in making sure nova's DB calls are performant. Today these people can review the code, but ultimately two cores are needed to review the code, making it hard for people to feel empowered to own/maintain that code.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div></div><div>FWIW, I have not been deeply involved in any of the highly political/vendor-driven projects so this may appear totally ignorant to those realities, but I think that is a clue that those projects are drifting away from the ideals that OpenStack was started with.</div><span class=""><font color="#888888"><div><br></div><div>dt</div><div><br></div>-- <br><div><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</font></span></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>