Piling on, it could even be with an incremental approach, assuming it's not too much of a technical undertaking to implement in gerrit.

Contributor == "Mentored developer contributor who's active on OFTC IRC" :)

A contributor can contribute code and reviews, but since there's a limit to how much end-to-end testing they can do on their local machine, on a feature. They have +1 review vote.

Contributor gets a good-enough knowledge of troubleshooting the Zuul CI logs or their own personal hardward/compute access and can now do some poking around and testing beyond local-dev and unit tests. Even though they do not have all the context, ideas, decisions, governance and direction for the project, but are now getting a hang of things, they have a +2 reviewer vote permission.

Contributor demonstrates consistent quality reviews and understanding of testing practices through regular engagement. They've contributed multiple merged patches and shown good judgment in distinguishing critical issues from routine changes and already have +2 reviewer vote permission. They may now get limited merge rights (W+1) for urgent CI fixes, trivial changes, and documentation.

Contributor has demonstrated deep expertise through substantial contributions and reviews in a specific domain (API, Agent, Metrics, Conductor, RPC, Data Model/Object, Networking, etc.) They've shown understanding of the architectural implications and backwards compatibility concerns in their area, they consistently provide insightful feedback and have established trust through sustained, high-quality contributions... and now they may be granted merge rights (W+1) for changes within their area of expertise.

With time and similar progression (like cross-domain "expertise"), eventually achieve core approver status, plus a likely automatic inactivity timeline trigger that revokes all or specific voting permissions.

This may be completely automated with human oversight (if possible) or managed entirely through periodic community reviews like during the PTG.

Which makes me think an approach like this will not or only fuzzily apply for folks with just a lot of years of experience in other OpenStack projects.

--
Afonne-Cid


On Mon, Nov 3, 2025 at 5:35 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
Greetings Jay,

Thank you for starting this discussion. I've put some thoughts in-line.

On Fri, Oct 31, 2025 at 12:48 PM Jay Faulkner <jay@gr-oss.io> wrote:
>
> I'm going to preface this with a comment that I'm not completely sold on
> this idea yet, but I think it's worth a larger discussion and might be a
> seed to help with discussion. I've tagged Ironic as this proposal is for
> Ironic specifically, but I'm very, very interested in the larger
> community opinion for this kind of approach so I also tagged all.
>
>
> One of the toughest parts about walking the path to becoming core is how
> fuzzy the targets are. With Ironic recently having added a two-tier
> review system, with reviewers and approvers separate, we have an
> opportunity to allow a much, much bigger tent for the ironic-reviewers
> group without risking code getting merged without approval by one of our
> folks with more experience and context in OpenStack and Ironic as a whole.

I concur with this statement. That being said, I think there is a
challenge some other projects might push up against, which is a
perception that they need to tightly control aspects related to review
and approval as one combined activity to guide forward a project.  I
think time has largely tempered this from the early days of Ironic,
and out of practical necessity we have started to shift to a more
inclusive model because placing the entire burden on a small group
obviously doesn't scale nor really provides a mechanism to grow new
contributors or even provide the ability to move things forward in a
quick but orderly fashion.

A positive side effect of the newer model with Ironic is that it has
grown trust through engagement. It allows someone who is focused on
reviewing and approving to recognize "others have looked at this and
they believe it is good enough to merge". At which point, it makes no
sense to obstruct, but delivers value to do the needful. I guess at
some point it all boils down to perceptions on how one should
lead/manage projects, and I feel strongly that consensus building in
the moment delivers value over static plans. Plans can and should
change as new data comes in, and that is okay. Messaging outward
becomes a powerful tool afterall.

>
> So here's the suggestion -- we come up with a static criteria and period
> with a clear bar to "if you do this, you are an ironic-reviewer". For
> instance, we could say (I'm not sure about these numbers): if you do an
> average of Y (5?) reviews/week and have merged a major Ironic feature or
> multiple bugfix patches, you would automatically be a reviewer.
>

I'm not really a fan of numbers based modeling, but it is a
demonstration of interest/commitment. That *is* easiest through
numbers, yet numbers also only relate in high activity areas and
sometimes there is value in extending trust beyond just sheer
activity. For example, expertise can be siloed but also bring
extremely valuable feedback in a review process. If that is siloed
into the existing review structures, then we actually devalue the
expertise by giving it the same weight as any random gerrit user. In a
sense, we're talking about how we build trust as well, and one
critical aspect we need to be mindful of is how to build trust at the
human level.

I think the best path is almost like a "pick 2" approach coupled with
"Are you interested" and "are you willing"?

"Are you doing backporting work?"
"Are you doing reviews on some sort of regular basis?"
"Did you do some major piece of work in an area?"
"Are you attempting to help others understand?"
"Are you a subject matter expert and have touched this area?"

I think this matrix gets harder to handle as you deal with
drivers/sub-components, but taking a model of extending trust can
definitely pay dividends, that is if a project wants them.

> Obviously, we'd have to keep safeguards to prevent abuse; in our
> community in the past we had a rule that changes required review from
> two separate corporate entities -- in this case, I'd suggest a waiting
> period to prevent quick-merging by someone with a single perspective.
> Exceptions would be, as in the current system, for emergency CI fixes
> and documentation improvements.
>
> To be clear: the safeguards shouldn't be seen as a lack of trust, but
> maybe instead as an acknowledgement that structural controls hold value
> even if there's no reason to assume mistrust.
>
>
> Full proposal:
>
> * ironic-approvers (+2 and Workflow +1) continues to operate as usual,
> with admission being based on technical merit, trust, and review frequency.
>
> * ironic-reviewers (+2 only) becomes a data-driven group, where
> reviewers are added/removed based on individual performance metrics TBD
> (likely reviews/commits/bugs fixed). -- I'll note that today, there's
> not really any set of reasonable metrics that would add additional
> reviewers to this group.

I would be willing to consider contributors who ask as well. It
demonstrates they have interest.

>
> * Code changes would either need a review from two separate
> company-representatives, or to have sat for a short waiting period to
> ensure other folks had a chance to look at it.
>
> * Urgent CI fixes, trivial changes, and documentation updates would
> still only need one review to land.
>
>
> What do folks think? Would this be a good carrot for existing non-cores
> to up their review and upstream contribution commitments?
>
>
> -
>
> Jay Faulkner
>
> G-Research OSS
>