Open Stack

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

A bit of history is useful here.

We used[1] to have 4 groups for each project, mostly driven by the need
to put people in ACL groups. The PTL (which has ultimate control), the
Drivers (the trusted group around the PTL which had control over
blueprint targeting in Launchpad), the Core reviewers (which have +2 on
the repos in Gerrit), and the bug team (which had special Launchpad bugs
rights like the ability to confirm stuff).

[1] https://wiki.openstack.org/wiki/Launchpad_Teams_and_Gerrit_Groups

In that model, "drivers" is closer to what you describe for
"maintainers" -- people invested 100% in the project success, and able
to spend 95% of the work time to ensure it.

My main objection to the model you propose is its binary nature. You
bundle "core reviewing" duties with "drivers" duties into a single
group. That simplification means that drivers have to be core reviewers,
and that core reviewers have to be drivers. Sure, a lot of core
reviewers are good candidates to become drivers. But I think bundling
the two concepts excludes a lot of interesting people from being a "driver".

If someone steps up and owns bug triaging in a project, that is very
interesting and I'd like that person to be part of the "drivers" group.
That said, bug triaging (like core reviewing) is a full time job. You
can't expect the person who owns bug triaging to commit to the level of
reviewing that core reviewers commit to. It's also a different skillset.

Saying core reviewers and maintainers are the same thing, you basically
exclude people from stepping up to the project leadership unless they
are code reviewers. I think that's a bad thing. We need more people
volunteering to own bug triaging and liaison work, not less.

So, in summary:

* I'm not against reviving the concept of drivers
* I'm against making core reviewing a requirement for drivers
* I'm for recognizing other duties (like bug triaging or liaison work)
as being key project leadership positions

Hope this clarifies,

-- 
Thierry Carrez (ttx)