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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
