Joe Gordon wrote: > On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez <thie...@openstack.org > <mailto:thie...@openstack.org>> wrote: > >> Joe Gordon wrote: >> > I cannot speak for all projects, but at least in Nova you have to be a >> > nova-core to be part of nova-drivers. >> >> And would you describe that as a good thing ? If John Garbutt is so deep >> into release liaison work that he can't sustain a review rate suitable >> to remain a core reviewer, would you have him removed from the >> "maintainers" group ? If someone steps up and works full-time on >> triaging bugs in Nova (and can't commit to do enough reviews as a >> result), would you exclude that person from your "maintainers" group ? > > I want to empower that person and recognize them in some semi formal > capacity and make sure they have all the correct permissions. > > I do not want a single flat 'maintainers' group, I think we need a > hierarchical notion of maintainers, where different people can end up > with very different responsibilities (and ACLs -- but that is a > implementation detail).
OK, so I probably misread your proposal[1]. My understanding was you wanted a single flat "maintainers" group that would purely replace "core reviewers", keep the same rights and just add duties to the already-existing reviewing duties. [1] https://review.openstack.org/#/c/163660/ Since I thought project leadership needs to be expressed in a much more diverse and inclusive way (and explicitly not tied to +2 rights), I opposed such simple renaming. >From what you're saying now your objective is the same as mine. I'm not sure the maintainers group needs to be purely hierarchical (I think I'd prefer it to be a set of duties with no hierarchy between them), but I agree that: - today core reviewers are the only visible project duty, and we need to expose and reward all the others, as separate attributes - we could use a blanket term ("maintainers" ?) to describe the people holding one or more of those attributes. >> OpenStack governance mandates that core developers are ultimately the >> PTL's choice. Since the PTL is regularly elected by all contributors, >> that prevents aristocracy. > > Can you site your source for this? Because the earliest reference to > 'Core Developer' (what you are calling core reviewer -- even though that > is not the original name) that I could find says nothing about it > ultimately being the PTLs choice. PTLs have (and always had) ultimate say over their project matters. That includes how to select core reviewers (or how reviews should be performed). A lot of projects let their PTL directly determine who should (and should no longer) be on the core list. > https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Now it's true that very early on, a lot of PTLs adopted a more "open" process to help in that selection. That doesn't mean they can't bypass the process. Personally I think that the apparently "open" process for core selection just resulted in reinforcing the aristocracy. This is why I encourage PTLs to own the content of core reviewing teams more directly. >> However in some projects, core reviewers have to be approved by existing >> core reviewers. That is an aristocracy. In those projects, if you > > Which projects do it differently? The Swift PTL always just announced additions. I seem to remember TripleO under Robert Collins directly adding members. Also Nova under Russell Bryant removed inactive members without asking for an existing core members poll. (and that is all good). That said, I agree with you that most projects copied the "existing cores must agree" rule. > So this is where you loose me. Has there ever been a case of a project's > PTL adding/removing people from the core team where the PTL goes against > the majority of the core developers? You say that an early (unwritten?) > goal of the system we have is to prevent 'aristocracy,' but all I see is > 'aristocracy'. Obviously the PTL would only overrule the majority of his core reviewers in extreme cases. Imagine this extreme case: core reviewers in a project have become a pure aristocracy, nobody can get in anymore, fresh ideas and code are systematically rejected. There is a divide between contributors to the project (doing the work) and core reviewers. Project is completely blocked. At the next election, a PTL candidate campaigns on fixing this by dramatically changing the core team. Contributors rally to that candidacy, candidate is elected. Once elected, the PTL can fix the core team without asking the existing aristocracy blessing. Now I agree that it's a governance safety valve, designed to solve a mostly theoretical case. But sometimes having a "bucket stops here" rule is sufficient to prevent conflict. For example conflicts between two projects can be escalated to the TC for final resolution. In effect, that never happens: said projects usually solve the issue between themselves rather than ask the TC to arbitrate. The same effect applies here: saying "the PTL has ultimate say anyway" usually prevents a total disconnect between the contributors and the core reviewers, because everyone knows there is a safety valve. > [...] > So, let me take a step back here. I would like to see at least 2 to 3x > more people in a given project to feel empowered and have badges, and > make it possible for part time upstream developers to hold some of said > badges. It sounds like you more or less agree with that goal. So how do > you propose we get there? Define roles (separate from "core reviewing") that are useful tasks, and let people hold those roles. For example we introduced this cycle the concept of liaisons -- this is incredibly important work, and I'd like the people who hold those roles to be more widely recognized. Now the problem is how we give more recognition to those people. I've been trying to popularize the use of the "CPL" acronym (cross-project liaisons) as a key part of the project leadership (just below the PTL). Maybe we need a blanket term ("maintainers" ?) to regroup all those roles ? > Because having 15 core reviewers for all of nova is just not cutting it. So I think that's a separate issue. Lack of core reviewers in Nova is because the domain you have to have expertise on is just too big. That means it is very hard to maintain the expertise and activity level to remain a core reviewer, and even harder to learn enough to become one. I fear the only solution there is to have separate core review teams responsible for smaller areas of code. But that is a separate thread imho. -- 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
