[ironic][all] Making core teams more accessible
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
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
On 2025-10-31 12:48:13 -0700 (-0700), Jay Faulkner wrote: [...]
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. [...]
One way to approach this is as a safety net for the benefit of these new additions. People who are just starting out as core reviewers can easily be intimidated by the fear of approving something that causes a problem, and then being the one who's blamed for that decision. The new model you've chosen for Ironic gives them room to voice their opinions without feeling like they're at risk of letting you down for doing so. -- Jeremy Stanley
On 31/10/2025 21:59, Jeremy Stanley wrote:
On 2025-10-31 12:48:13 -0700 (-0700), Jay Faulkner wrote: [...]
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. [...]
One way to approach this is as a safety net for the benefit of these new additions. People who are just starting out as core reviewers can easily be intimidated by the fear of approving something that causes a problem, and then being the one who's blamed for that decision. The new model you've chosen for Ironic gives them room to voice their opinions without feeling like they're at risk of letting you down for doing so.
honestly my approach to that when ever i have given someone sudo rights or admin on something has been very simple. i am trusting you with the power to improve things and break things, if you break things we will fix it together and learn form the experience. In otherword if you do end up approving something that breaks something i would hope that you will help us fix it when we realsise a mistake happened. Out side of the final FF/RC period its unlikely that a merge patch is going ot break production. yes we try to keep master shipable to production but we can generally revert such a change quickly before it impact ops. the other things to note is that most project expect 2 reviewers for most things and in the proposed model the approves group is still the group with the +w rights so there is still a mentoring/oversight group that will hopefully catch any problematic patch before it get that far. im not going to comment on any of the specific number of review per week as that really depend on the review and velocity of the project but i don't think the idea is bad overall. the other thing i wanted to mention is there is another path to core that is less commonly taken, become a stable core first. that allows the person to demonstrate there good judgement by applying the stable policy and learn the code-base while also doing valuable work by maintaining the stable branches. for operators in particular that allows them to help shepherd the bug-fixes that will impact there production deployments into release closer to what they run. its also a little less daunting as there isn't the same pressure to know how all the code base should work, the design and direction has been already been assessed by the core team and as a stable core your focused more on the correctness of the backport and that it follow stable policy. so the pressure associated with the fear of approving something that causes a problem should be lessened as a result. regards sean
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
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
On Tue, Nov 4, 2025 at 10:05 AM CID Onyedikachi <cid@gr-oss.io> wrote:
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.
This is exactly the level I'm trying to codify. Knowing enough to know what you don't know :)
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.
These are the same level for me. Being granted access to approve is more of a statement of trust -- trust in a person not to maliciously abuse the power, but also trust in their ability to know when they should use that power or not. At that point, we give the permissions at the first state described here, and trust the persons' bravery using that +A to increase as they continue to learn. -JayF
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
participants (6)
-
Artem Goncharov
-
CID Onyedikachi
-
Jay Faulkner
-
Jeremy Stanley
-
Julia Kreger
-
Sean Mooney