Open Stack

John Griffith wrote:
>
>
> On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon <joe.gordon0 at gmail.com
> <mailto:joe.gordon0 at gmail.com>> wrote:
>
>     I am starting this thread based on Thierry's feedback on [0].
>     Instead of writing the same thing twice, you can look at the
>     rendered html from that patch [1]. Neutron tried to go from core to
>     maintainer but after input from the TC and others, they are keeping
>     the term 'core' but are clarifying what it means to be a neutron
>     core [2]. [2] does a very good job of showing how what it means to
>     be core is evolving.  From
>
>         "everyone is a dev and everyone is a reviewer. No committers or
>         repo owners, no aristocracy. Some people just commit to do a lot
>         of reviewing and keep current with the code, and have votes that
>         matter more (+2)." (Theirry)
>
>     To a system where cores are more then people who have votes that
>     matter more. Neutron's proposal tries to align that document with
>     what is already happening.
>
>         1. They share responsibility in the project's success.
>         2. They have made a long-term, recurring time investment to
>         improve the project.
>         3. They spend their time doing what needs to be done to ensure
>         the projects success, not necessarily what is the most
>         interesting or fun.
>
>
>     I think there are a few issues at the heart of this debate:
>
>     1. Our current concept of a core team has never been able to grow
>     past 20 or so people, even for really big projects like nova and
>     cinder. Why is that?  How do we delegate responsibility for
>     subsystems? How do we keep growing?
>     2. If everyone is just developers and reviewers who is actually
>     responsible for the projects success? How does that mesh with the
>     ideal of no 'aristocracy'? Do are early goals still make sense today?
>
>
>
>
>     Do you feel like a core deveper/reviewer (we initially called them
>     core developers) [1]:
>
>         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.
>
>     Or a maintainer [1]:
>
>         1. They share responsibility in the project’s success.
>         2. They have made a long-term, recurring time investment to
>         improve the project.
>         3. They spend that time doing whatever needs to be done, not
>         necessarily what is the most interesting or fun.
>
>         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.
>
>
>
>
>     [0] https://review.openstack.org/#/c/163660/
>     [1]
>     http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html
>     [2] https://review.openstack.org/#/c/164208/
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> Hey Joe,
>
> I mentioned in last weeks TC meeting that I didn't really see a burning
> need to change or create new "labels"; but that's probably beside the
> point.  So if I read this it really comes down to a number of people in
> the community want "core" to mean something more than "special reviewer"
> is that right?  I mean regardless of whether you change the name from
> "core" to "maintainer" I really don't care.  If it makes some folks feel
> better to have that title/label associated with themselves that's cool
> by me (yes I get the *extra* responsibilities part you lined out).

+1 to this. I feel we have much much much bigger things to be thinking 
about than just labels. Maybe this was a misunderstanding of this mail 
thread but in all honesty who cares...

>
> What is missing for me here however is "who picks these special
> people".  I'm convinced that this does more to promote the idea of
> "special" contributors than anything else.  Maybe that's actually what
> you want, but it seemed based on your message that wasn't the case.
>
> Anyway, core nominations are fairly objective in my opinion and is
> *mostly* based on number of reviews and perceived quality of those
> reviews (measured somewhat by disagreement rates etc).  What are the
> metrics for this special group of folks that you're proposing we empower
> and title as maintainers?  Do I get to be a "maintainer", is it reserved
> for a special group of people, a specific company?  What's the criteria?
> Do *you* get to be a "maintainer"?
>
> What standards are *Maintainers* held to?  Who/How do we decide he/she
> is doing their job?  Are there any rules about representation and
> interests (keeping the team of people balanced).  What about the work by
> those "maintainers" that introduces more/new bugs?
>
> My feeling on this is that yes a lot of this sort of thing is happening
> naturally on its own and that's a pretty cool thing IMO.  What you're
> saying though is you want to formalize it?  Is the problem that people
> don't feel like they're getting recognition or credit that they
> deserve?  The "nobody wants to work on the not fun stuff" I kinda get,
> and yeah.. that happens.  I'd argue though there are a good number of
> people that are however jumping in on things outside of features.

+1 to this. There will always be people who will want to work on fun 
stuff and those who don't; it's the job of leadership in the community 
to direct people if they can (but also the same job of that leadership 
to understand that they can't direct everyone; it is open-source after 
all and saying 'no' to people just makes them run to some other project 
that doesn't do this...).

IMHO (and a rant probably better for another thread) but I've seen to 
many projects/specs/split-outs (ie, scheduler tweaks, constraint solving 
scheduler...) get abandoned because of cores saying this or that is the 
priority right now (and this in all honesty pisses me off); I don't feel 
this is right (cores should be leaders and guides, not dictators); if a 
core is going to tell anyone that then they better act as a guide to the 
person they are telling that to and make sure they lead that person they 
just told "no"; after all any child can say "no" but it takes a real 
man/woman to go the extra distance...

>
> It's sort of funny looking back over the years.  We used to complain
> over and over that "we don't have enough reviewers", and that "reviewing
> is crucial but under appreciated work".  Since then there's all sorts of
> people striving to spend time doing reviews and provide in some cases
> real constructive feedback.
>
> Now we seem to be saying "reviewing isn't where it's at, anybody can do
> that; bug fixes is the new coolness".  I think there are others way to
> address this by the way, possibly more effective ways.  Heck, you could
> even do commit credits; it costs five bug fixes to the overall project
> before you can commit a feature (ok, don't take me seriously there).
>
> Maybe I'm misinterpreting some of this, maybe there's something in
> between.  Regardless I personally need a good deal more detail before I
> form my opinion.

+1 I should probably not write emails this late, ha.

>
> Thanks,
> John
>
>
> ​
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev