Open Stack

On Tue, Mar 31, 2015 at 5:46 PM, Dean Troyer <dtroyer at gmail.com> wrote:

> On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>> 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.
>>
>>
> 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.
>

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

P.S. if you read the linked spec, you will see the maintainer definition is
straight from docker.


>
>
>> 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.
>>
>>
> The best maintainers appear to be invisible because stuff Just Works(TM).
>
> 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:
>
> a) How do we scale?  How do we spread the project management load?  How do
> we maintain consistency in subteams/subsystems?
>
> b) How do we avoid the 'aristoctacy'?
>
> c) what did I miss?
>
>
Well said.


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

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 Thierry's said
"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.

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.


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

Yes, well said we are seeing the boundaries of the flat style origination
in many of the larger projects.

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

Two comments

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


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


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.
>
> dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com
>
> __________________________________________________________________________
> 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/b752adcf/attachment.html>