Hey Jay,

Sounds interesting.

However, not as a critics at all, I do not think any "rule" can be applied to every project. For me a process to become a core in sdk is definitely not as strict as it is in Keystone or Barbican. I like the idea of trying to express what a contributor need to achieve to become a core, it's just going to be definitely different from project to project.

Sadly in my area of reach I do not see people really willing to get core permissions, and rather focused on sporadic or one time contributions. So for me the problem itself is a bit different to yours.

But as said, it's good to be thinking about making ourselves more open to those who come from outside.

Regards,

Artem

----
typed from mobile, auto-correct typos assumed
----

On Fri, 31 Oct 2025, 20:48 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.

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.

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.

* 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