On 04/01/2015 05:41 AM, Thierry Carrez wrote: > 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
++ __________________________________________________________________________ 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