Open Stack

On Tue, Mar 31, 2015 at 5:24 PM, John Griffith <john.griffith8 at gmail.com>
wrote:

>
>
> On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon <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://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).
>

As Doug said in his response, for many projects this is about trying to
make the definition of what is expected from a core reflect reality.


>
> 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.
>

correct, I would like to see the opposite. I think we need to empower and
trust more people with more then just the standard +1 vote.


>
> 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"?
>

Long term I see two levels of maintainers. General maintainers and
subsystem maintainers.   Both would more or less have the same process as
core does today.


>
> 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
>

Do I want to formalize it? Maybe? Right now I want to discuss the idea, so
that more people can form an opinion on what the core (get it?) issue is
here and how we can address it.


> 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.
>
>

Yes, there are a good number of people who are working on things besides
sexy features, but IMHO not enough.  I want to empower/trust more
developers, but we have not been able to get passed 15/20 core reviewers
per repo.


>
> 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
>

I wouldn't say that. I think trust empowerment of more developers is the
new coolness. I want more developers to be able to specialize more and feel
they are responsible for the success of some piece of code.


> 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.
>

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150331/ca3a6082/attachment.html>