)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f33619c136086cb82509f19938d610609af9ff7d","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This is option 1 of the 4 potential changes proposed during the 2026.2"},{"line_number":10,"context_line":"(Hibiscus) PTG [1]. This proposal captures the creation of a new"},{"line_number":11,"context_line":"nova-approvers group which includes the core groups of all relevant"},{"line_number":12,"context_line":"services with hook points in nova (neutron, cinder, ironic, cyborg)."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"NOTE: These patches *should not* be merged yet. Cores are asked to +1"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"9bec9ab5_e57e0941","line":11,"updated":"2026-09-11 12:31:02.000000000","message":"```suggestion\nnova-reviewers group which includes the core groups of all relevant\n```","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"23b7b47a6db3d25dce05cc9b5e8c197037b9ef80","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b134fa4c_b018ad26","updated":"2026-04-24 19:13:15.000000000","message":"As someone who might be a candidate for \"external expert\" in these proposals, I\u0027ll note I strongly prefer those where the +A would be held by Nova-specific experts, even if a +2 is permitted from external experts.\n\nEven if not enforced by Gerrit, I doubt I\u0027d feel comfortable being the final approver for patches in Nova. Just my $0.02 if you care for them :). \n\nBTW -- I really like the way you all have structured this. Thanks!","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"c9562dca6e9280034d46debd80e469505f592c74","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d3bea628_0c600339","updated":"2026-05-11 13:01:16.000000000","message":"Can we somehow select a deadline when we close the voting and evaluate the result?","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"136a8bdb8b01e3c8a410dc7239cf215e19586e2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a6f20bf7_a8fc2472","updated":"2026-04-24 16:47:29.000000000","message":"I am in favor of this option","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"c41427c960a45037dd444c4d8af431a8cbe3a544","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ab845666_44f3e200","updated":"2026-04-24 22:32:36.000000000","message":"I like this too, and thanks for pioneering this change; i\u0027m hoping this helps as a pattern to other teams. We\u0027ve seen success with this elsewhere, and I would love to see this in Nova.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"88c8583fd874f6508698e1d0b7e988f5909634ca","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d2e7230f_ee9e76c1","updated":"2026-05-12 20:11:52.000000000","message":"I think this is not easy to implement, and I am not even sure if it will solve the current issue. I see many challenges in that, and a few of those or more of the open questions are:\n\n* If we add anyone in nova-reviewer, it means considering their +2 as a \u0027one\u0027 out of \u0027two\u0027 required +2, then how is it different from considering their +1 as +2 (option 3). We are not such a big community anymore, so knowing people/SME and counting their +1 as +2 is not so challenging.\n\n* If our current criteria is little high for adding members in nova-core, then how it is going to change to add members from nova-reviewer to nova-approver? If it is going to be the same (as we are not discussing or changing it), then how does it solve the review bandwidth from the merging code perspective? \n\n* Most of the time, nova-reviewers (as mentioned inline in policies.rst) might not be able to apply the +2 as the code change might be changing more code than their service-related code. IN that case, considering the expert advice requirement (nova-approver), I am afraid that many times we might end up needing two +2 from the nova-approver group.\n\n* It does not solve the problem (change anything from the current situation) when changes are proposed by a member of the nova-approvers group.\n\nIn summary, it sounds like we are kind of applying the single core approval policy with SME +1 (option3), but in a complicated way of different groups.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9f6d8c6c0dac7cd5314a13d1fe5c4951a49b543f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a4832894_826da49a","updated":"2026-04-29 17:16:49.000000000","message":"I wish we could have had -1 for preference -2 for \"I\u0027m not okay with this\" more in line with how these typically go. So count me as -0.9 here.. I don\u0027t want to do this, but I certainly don\u0027t want to block the team from doing it if that\u0027s the consensus (like the -1s on the higher proposals appear to be doing).\n\nI think this adds complexity and mechanics (i.e. new group, new rules, new membership discussions) for the sake of showing a +2 and that seems like a lot of overhead to me. It also seems to me like in two years if this doesn\u0027t pan out, we\u0027ll look back at a patch and be confused why some (seemingly random) people were +2 on a thing here. It\u0027s a common thing to do when trying to figure out why we made a change, to go look at who proposed and reviewed it.\n\nIn reading the four of these options, I wondered if another option might be worth considering. That would be to just relax the \"two cores\" requirement for some situations. Basically, if a single core felt like a change was trivial or straightforward enough to just fast approve, we\u0027d allow for more of that. That could mean that if a single core feels like an Ironic driver change is contained enough to not impact the other drivers (so like the metadata change would not qualify) and it\u0027s reviewed by an ironic person, then ... +2+W. Cinder stuff that brings API changes would be above the bar, but smaller changes to interact with brick or cinderclient might be under it. I feel like it would be a thing we could document by example fairly easy.\n\nAnd that leads right into what my question was going to be (which is also gibi\u0027s question): how are we going to decide who is in the other group? Even if we agree to do that, if we can\u0027t agree on anyone that goes in that group then nothing has changed. I can certainly imagine that being even more contentious than agreeing on the general principle. Leaving it up to cores in the moment with judgment and examples might include a wider swath of people actually being able to inform the merge of a patch. It also could decrease some of the pressure we have where one of the cores that would be working to approve a piece of code is also the author and thus requires a third core to take time to review it.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2709ce2a66adf7a903ca2304624d4c8b00380e9a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"70ef2907_67b7321e","updated":"2026-04-28 14:41:44.000000000","message":"Works for me. I guess if we go with this we need a way to recruit / select folks for the new group from the adjacent services.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"afb175f7e75763b0e3b8844d2e41b4398b544d02","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a6183435_b8296420","updated":"2026-09-10 13:01:52.000000000","message":"dropping back to +1 as there is discrepancy about naming in the doc compared to the landed ACL","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"cc816969d420ba0bdc5b90d568dea1e552b234f8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0691f51f_36846e98","updated":"2026-09-10 12:41:31.000000000","message":"folks the ACL change landed (see https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/VDH5NVO6S4XDZDYEK32GZPT2444U2OJD/) so we should start focus finalizing this patch and maybe creating subsequent patches to start agreeing on:\n\n\u003e the initial membership of nova-reviewers;\n\u003e ownership and administration of the group;\n\u003e the process for adding and removing members;\n\u003e the criteria and timeframe we will use to evaluate whether the model is working.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ff92c7b1d93c17c4d756cb83ac7ae51da213f70c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f73ffe08_23b9e5de","updated":"2026-04-26 17:37:44.000000000","message":"this is my prefered option","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a1ecdf0c6aa6342982ad39f85c25b52e9ebe58c2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a65707c5_c4bcb8a0","in_reply_to":"02af24bb_c1d02fe1","updated":"2026-09-10 18:53:58.000000000","message":"it is not going to volenteer and get keys to the kingdom\nbut i think we shoudl solicte intersted parties adn dicuss that as a team.\n\nany member of nova-reivewer are expected to follow nova\u0027s review practices with regardes to testing requriement and convetnion in the nova repo.\n\nthat is part of our documented review expections https://docs.openstack.org/nova/latest/contributor/code-review.html\n\nnothign about being a service core in a service that does not use or requrie fucntional tests changes that for the nova repo.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"2c866b011fa59613c7f22fdd32c096ea970fbd20","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"82451da7_bf55cbb7","in_reply_to":"05735b0f_53b13b15","updated":"2026-09-10 15:46:07.000000000","message":"I\u0027ve noted this in [my email to openstack-discuss](https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/5O7WAVZ5K35XIHXLZPMNMAIL2RFOYAAN/), but at least one of these points is already covered here, in the proposal:\n\n\u003e Would it make sense to add nova-core to nova-reviewers? This way nova-core could administer the new group.\n\nYes, this is explicitly covered here. [Line 74](https://review.opendev.org/c/openstack/nova/+/986141/1/doc/source/contributor/policies.rst#74).\n\nAdditionally, the reason this hasn\u0027t merged yet is because we agreed we would not merge it until after one cycle (dansmith\u0027s suggestion).\n\nRegarding the other points, the process for how one becomes a member of nova-core is not vague, so I had to be similarly vague in describing how one becomes a member of nova-reviewer. I\u0027ll be completely onboard with firming both up if possible, similarly to cardoe\u0027s [recent proposal on openstack-discuss](https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/KPLX44YX6VEAJT4SZ3T7CJ3K2U6HJUTZ/). If we\u0027re looking for a starting point, then I agree with pretty much everything Sean said above.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"5a0ee3957b8ceee9159d63d617d95a034bbcef10","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6ba54239_c02e1417","in_reply_to":"0691f51f_36846e98","updated":"2026-09-10 12:50:26.000000000","message":"\u003e folks the ACL change landed (see https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/VDH5NVO6S4XDZDYEK32GZPT2444U2OJD/) so we should start focus finalizing this patch and maybe creating subsequent patches to start agreeing on:\n\u003e \n\u003e \u003e the initial membership of nova-reviewers;\n\u003e \u003e ownership and administration of the group;\n\nWould it make sense to add nova-core to nova-reviewers? This way nova-core could administer the new group.\n\n\u003e \u003e the process for adding and removing members;\n\nI guess this is a hardest piece ahead of us. So sub questions:\n\n1) (I\u0027m a bit afraid of asking this but it is basically a necessary information) Do we have volunteers from adjacent services to join to this group?\n\n2) Rene (as PTL),and nova-core do we have criteria who can join? Couple of straw mans:\n* the person needs to be core in an adjacent service already\n* the person accepted by the nova-core + nova-reviewer team with consensus (similarly how nova-core is managed)\n\n3) What are the expectations from a nova-review member? Like nova-core has unwritten(?) expectations about:\n* Review bandwidth spent on nova. \n* Caring about the health of the nova CI. \n* Showing up on the PTG to help discussing topics. etc.\n\n\u003e \u003e the criteria and timeframe we will use to evaluate whether the model is working.\n\nI suggest that we simply ask the question at every PTG: \"is this working?\" and listen to the community and the various group memebers.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"c41427c960a45037dd444c4d8af431a8cbe3a544","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a9c84dbd_6296a95c","in_reply_to":"352a22ff_2a291e73","updated":"2026-04-24 22:32:36.000000000","message":"+1","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"b2a0f552a38c06ad19799195e760fa42ecf9fcda","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f8156ee8_658f2904","in_reply_to":"6ba54239_c02e1417","updated":"2026-09-10 13:51:27.000000000","message":"\u003e Would it make sense to add nova-core to nova-reviewers? This way nova-core could administer the new group.\n\nYes, that would be my preferred outcome: I would like nova-core to own and administer the nova-reviewers group, and I would then remove myself from it. I believe I already have the necessary permissions to make these changes, but I would prefer to wait until the situation and the team’s intended setup are a little clearer before doing so.\n\n\n\n\n\u003e Do we have volunteers from adjacent services to join to this group?\n\nI do not know whether we already have any volunteers. From my perspective, there are two possible ways for someone to become a candidate:\nThey can volunteer or nominate themselves.\nThe team can identify someone who would be a good fit and invite them to join, provided that person is interested and agrees.\n\n\u003e Rene (as PTL),and nova-core do we have criteria who can join? Couple of straw mans.\n\nI think the criteria are something we need to discuss and define together. Your suggestions are a good starting point.\n\nI can create a PTG topic and include these ideas as an initial draft for discussion:\n\n- whether being a core reviewer in an adjacent project should be a requirement or simply a strong indication of trust and expertise.\n- how the initial members should be selected.\n- how subsequent additions and removals should be decided.\n- whether existing nova-reviewers should formally participate in those decisions.\n\nFor this particular process, my current preference would be for a majority-based decision rather than requiring consensus. We currently have seven Nova cores, so a simple majority provides a clear and practical outcome: at least four approvals would be required. It also avoids allowing a single objection to block a nomination indefinitely, while still ensuring broad support within the team. Any concerns raised should, of course, still be discussed and addressed.\n\nI also want to make it clear that I will not put myself forward for membership in either nova-reviewers or nova-core/nova-approvers, at least during this cycle. My current membership in nova-reviewers is solely for the initial administrative setup, and I intend to remove myself once nova-core can manage the group. I do not want the introduction of this process to be perceived as a plan or strategy for me to obtain either status.\n\nThe expected outcome of the PTG topic would be to reach an agreement and produce a document clearly describing the nomination, addition and removal process.\n\n\u003e What are the expectations from a nova-review member? Like nova-core has unwritten(?) expectations about\n\nI am not sure this fully answers the question about individual expectations, but the main objective of the group, as I see it, is to improve Nova’s review bandwidth by bringing in additional expertise.\n\nThis would be particularly useful for areas where the current Nova cores may not feel sufficiently comfortable or knowledgeable to provide a Code-Review +2. The integration with Ironic is one example that comes to mind. Members of nova-reviewers could provide trusted, domain-specific reviews in such areas, while the Nova approvers would retain responsibility for the final approval and merge.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1fbba5d2a964e6af6251f36c3dd18a8169b50a6f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"05735b0f_53b13b15","in_reply_to":"6ba54239_c02e1417","updated":"2026-09-10 14:12:57.000000000","message":"Would it make sense to add nova-core to nova-reviewers?\nYes, although while nova-core can administer the group, the membership\nwould still be under the ownership of the TC and delegated to the PTL/TaCT\nliaison from a governance perspective.\n\nSo practically speaking, I think for that to be our path forward, it would be\ngood for one of the TaCT liaisons or PTL to eventually be in nova-reviewers or\nnova-core. I\u0027m making that as a blanket statement, not specifically in relation\nto Rene\u0027s membership in either.\n\nWe actually have written down our project conventions for how to maintian\nnova-core: https://wiki.openstack.org/wiki/Nova/CoreTeam\nWhere there is any disagreement between that project convention and the\ngovernance rules as written, the governance rules obviously win. \n\nI don\u0027t think that should be the criteria for the new nova-reviewers group, however.\n\nSo on point 2:\n\nI think there are two categories of candidates for the new nova-reviewers group:\n\n1. The simplest (and the one I would prefer to focus on) is cores from other\n   projects.\n2. Individuals who are not already a service core.\n\nWe used to have the idea of inter-project liaisons:\nhttps://wiki.openstack.org/wiki/CrossProjectLiaisons#Inter-project_Liaisons\n\nThis has not been actively maintained on the Nova side for some time, but I\nwould like to suggest that we invite the core teams of Cinder, Neutron, and Ironic (perhaps Manila, glance or Oslo), or any other team that has a direct integration with\nNova, to have an internal discussion and propose a new inter-project liaison,\nwhom we would add to nova-reviewers. (im not listing cyborg since i already am\nprovidign that touch point)\n\nAs an inter-project liaison and/or positional new nova-reviewers member,\nthey would be expected to represent important changes for their project in\nthe Nova IRC meeting when they arise, and be a contact for us to reach out\nto that project when needed.\n\nAs a member of nova-reviewers, they would be expected to actively review\npatches related to their project. As an example, we are currently looking to\nswap the Neutron client to the SDK; if Neutron selected a liaison to add to\nthe nova-reviewers group, then there should be an expectation that they help\nreview the Neutron SDK migration or whatever else.\n\nSo for group 1, I would hope this is a self-selected representative of a given\nproject who is willing to commit some time to maintaining the integration of\ntheir service within Nova.\n\nFor group 2 (a contributor who is not a core of a service project), we would\nhave nova-reviewers as a way to grant full approval rights (+2) and eventually\nprogress to nova-core (which provides rights on the spec repo and other\ncompute team deliverables).\n\nNote: nova-reviewers is currently not proposed to grant stable rights,\nso nova-stable-maint membership is still required for that, which is out of\nscope for right now.\n\nHowever, we may choose to change that and add nova-reviewers to nova-stable-maint separately.\n\nGroup 2 is important to ease the path to core and to extend some trust when\nwe believe someone has demonstrated an understanding of the core mechanics of\nNova, but has not yet demonstrated that with a prolonged track record.\n\nOn point 3:\n\nI would expect service cores to look at a substantial portion of non-trivial patches related to their service integration, but not expect them to review\nall such patches or require them to vote on merging any of them.\n\nNova gate health is, I guess, tricky. I don\u0027t think there is ever anything\nwrong with asking an SME (regardless of their review rights) to help.\nI wouldn\u0027t want to set the duties so high as to deter folks from volunteering\nto help review their integration, but I think ensuring there is enough test\ncoverage and that the CI is happy with the change partly falls to the nova-core\nmember who is applying the +2 to ensure that it is correct.\n\nI think the PTG topic is interesting. When personal circumstances allow,\nI would expect that they attend at least the cross-project session, and ideally,\nif there is a standalone topic related to their service, it would be nice\nif they could attend that as well. However, I would not set the expectation\nbeyond that.\n\nSo, there needs to be some balance between continuing to focus on their day\njob (the other service) and supporting the maintenance of that integration\nin Nova (the reason they were added to nova-reviewers in the first place).\n\nFor individuals who are not a core/approver in another service, I guess I\nwould expect them to be treated like any other core/contributor to Nova.\nGate health is a shared responsibility, and actively trying to fix/improve\nit is one of the things I would look for in a future core, so that is one of\nthe things I would look for in general from them.\n\nAnd yes, I think reflecting on this in the PTGs and our other processes is\nhealthy and something we should do, but we should also try this for at least\none cycle (2027.1) before fundamentally changing it, so that we actually have\nexperience on which to base any refinements.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"79e1b8bc65e57da59f7a54a7e56803c80fb75a01","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"81aed975_1477358b","in_reply_to":"770bddfc_1986bc42","updated":"2026-09-15 10:38:50.000000000","message":"as agreed on the IRC meeting yesterday I started adding a PTG topic to https://etherpad.opendev.org/p/nova-2027.1-ptg and I will add my braindump there.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"579f315f2cd1d0c790d7499c8a902928dcef55a3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4244edd2_22d30010","in_reply_to":"7e829627_fb26afc5","updated":"2026-08-28 19:56:47.000000000","message":"\u003e \u003e I think this is not easy to implement, and I am not even sure if it will solve the current issue. I see many challenges in that, and a few of those or more of the open questions are:\n\u003e \u003e \n\u003e \u003e * If we add anyone in nova-reviewer, it means considering their +2 as a \u0027one\u0027 out of \u0027two\u0027 required +2, then how is it different from considering their +1 as +2 (option 3). We are not such a big community anymore, so knowing people/SME and counting their +1 as +2 is not so challenging.\n\u003e \n\u003e Yes, they\u0027re very similar. The difference with this approach is that we make the tooling work for us and make our definitions of who we consider an SME explicit and shared. A distributed team shouldn\u0027t have to carry this knowledge in individual\u0027s heads, and you and I (for example) should have a mutual understanding and agreement on who e.g. the Ironic SMEs are.\n\nYeah, that is valid point and keeping SME/cross liaison somewhere on wiki or other place have been stale in past and did not work as expected so I can consider this a valid tooling to implement it (option 3 which i am in favor).\n\n\u003e \n\u003e \u003e * It does not solve the problem (change anything from the current situation) when changes are proposed by a member of the nova-approvers group.\n\u003e \n\u003e I don\u0027t understand this point. What\u0027s specific to changes from a member of `nova-approvers`? Is it the fact that you can\u0027t approve your own patch?\n\nI meant to say if author is nova-approvers then it still need one more approver but leave it as it is same today and in any solution.\n\nThe another concern/question: how will we differentiate the cross services SME and the potential nova-approver candidates who are added as nova-reviewer first. But that is more of implementation details and we will see how it goes. As this proposal is to solve rhe cross-service SME issue, I will not block it for this question.\n\nFor me option 3 and option 1 (this one) is fine. if this option help and provide better tooling, I am +1 on this too.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"a311f9ba55d0ae17006361c5a933bceb94a3250c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"02af24bb_c1d02fe1","in_reply_to":"82451da7_bf55cbb7","updated":"2026-09-10 18:35:48.000000000","message":"This is going a long thread which seems hard to read and can we discuss this in PTG? but anyways adding my opinion (in summarixed way) here too:\n\n\u003e 1) (I\u0027m a bit afraid of asking this but it is basically a necessary information) Do we have volunteers from adjacent services to join to this group?\n\nWait, is it going to be on a \u0027volunteers \u0027 basis? If yes, then I have big concern. My expectation is that any member in nova-reviewers goes through the general expectations we follow in the team to give +2 permission. Basically, a member from an adjacent service (core or reviewer) needs to:\n  a) have a good understanding of service-specific Nova code\n  b) also understand and agree on Nova reviewer guidelines/policies. What if they say we don\u0027t follow unit/functional testing requirement in our project so we want to do the same in my service specific code in Nova; are we OK to allow +2 with that?\n\n\u003e 2) Rene (as PTL),and nova-core do we have criteria who can join? Couple of straw mans:\n\n\u003e the person needs to be core in an adjacent service already\n\u003e the person accepted by the nova-core + nova-reviewer team with consensus (similarly how nova-core is managed)\n\nIMO, adding any member (service liaison or a new potential member of nova-core) should go through the expectations we have currently for nova-core but with little less strictness because they cannot merge the code (at least the ones I listed above)\n\n\u003e 3) What are the expectations from a nova-review member? Like nova-core has unwritten(?) expectations about:\n\u003e Review bandwidth spent on nova.\n\u003e Caring about the health of the nova CI.\n\u003e Showing up on the PTG to help discussing topics. etc.\n\u003e the criteria and timeframe we will use to evaluate whether the model is working.\n\nIMO, yes, the only difference here is +w permission and anything applies to nova-approvers for +2 permission applies to nova-reviewers also.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"00541867388d3cf7da56136e00d3f2ce15983c6a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"770bddfc_1986bc42","in_reply_to":"864f9a07_56c2ef9c","updated":"2026-09-14 16:22:23.000000000","message":"thanka gibi","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"2ca430677300f33b7141ad2f378a588e689c988a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"864f9a07_56c2ef9c","in_reply_to":"a65707c5_c4bcb8a0","updated":"2026-09-14 15:55:04.000000000","message":"I will bring this up today on the IRC meeting to focus on \"how to prepare this topic for the ptg\"","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"5ca1b18f259a15910acacaf68afd050e6d441305","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"352a22ff_2a291e73","in_reply_to":"b134fa4c_b018ad26","updated":"2026-04-24 19:51:34.000000000","message":"Thanks, Jay. In my mind there\u0027s an implicit assumption here that a nova-specific expert would be the second reviewer (or would spin back around to +W later on) but I didn\u0027t vocalise that today, so I\u0027d be disinclined to update this for now. It might be something to encode later on though.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"4b01e033befe9fa8a8c771572b92358e9bb2db2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7e829627_fb26afc5","in_reply_to":"d2e7230f_ee9e76c1","updated":"2026-08-19 13:28:56.000000000","message":"\u003e I think this is not easy to implement, and I am not even sure if it will solve the current issue. I see many challenges in that, and a few of those or more of the open questions are:\n\u003e \n\u003e * If we add anyone in nova-reviewer, it means considering their +2 as a \u0027one\u0027 out of \u0027two\u0027 required +2, then how is it different from considering their +1 as +2 (option 3). We are not such a big community anymore, so knowing people/SME and counting their +1 as +2 is not so challenging.\n\nYes, they\u0027re very similar. The difference with this approach is that we make the tooling work for us and make our definitions of who we consider an SME explicit and shared. A distributed team shouldn\u0027t have to carry this knowledge in individual\u0027s heads, and you and I (for example) should have a mutual understanding and agreement on who e.g. the Ironic SMEs are.\n\n\u003e * If our current criteria is little high for adding members in nova-core, then how it is going to change to add members from nova-reviewer to nova-approver? If it is going to be the same (as we are not discussing or changing it), then how does it solve the review bandwidth from the merging code perspective?\n\nNothing in this proposal (or any other) prevents us making other changes to the process. However, trying to capture all those changes here make this effectively an unbounded problem. I agree that we should examine our current criteria for becoming a core (or, after this proposal, moving from nova-reivewer to nova-approver) but we can/should do that in parallel.\n\n\u003e * Most of the time, nova-reviewers (as mentioned inline in policies.rst) might not be able to apply the +2 as the code change might be changing more code than their service-related code. IN that case, considering the expert advice requirement (nova-approver), I am afraid that many times we might end up needing two +2 from the nova-approver group.\n\nI need to clarify this language. The intention here was not to prevent e.g. a neutron SME from +2ing a patch that touched networking code but also add a new config option or database migration, once they understood this code. Rather, it was to indicate that they might need to seek input if the patch also added a new scheduler or if they did not understand how our database migrations worked.\n\nTo be clear, this is already true for existing cores. I suspect if I was reviewing something to do with policy, for example, I would likely ask for your input even if the code already had a +2 from someone else and I was the second reviewer.\n\n\u003e * It does not solve the problem (change anything from the current situation) when changes are proposed by a member of the nova-approvers group.\n\nI don\u0027t understand this point. What\u0027s specific to changes from a member of `nova-approvers`? Is it the fact that you can\u0027t approve your own patch?\n\n\u003e In summary, it sounds like we are kind of applying the single core approval policy with SME +1 (option3), but in a complicated way of different groups.\n\nThe proposals are very similar, but I don\u0027t think this is more complicate. If anything, it\u0027s the opposite. Doing things this way means we use the tools we have and write down knowledge that currently only exists in people\u0027s heads. This makes our process more obvious both to nova cores (you and I now have the exact same list of \"ironic SMEs\", rather than relying on our own mental model) and to other contributors. The actual change itself is also trivial: it\u0027s just a case of creating a new group and changing ACLs. We\u0027ve already already done this in SDK, Ironic and (I am told) Kolla. If your primary objection to this is technical then don\u0027t worry: I\u0027ll do all the necessary work (along with fungi and clarkb) to make this happen.\n\nOne last point on this also. While SMEs from other projects will form the initial basis for `nova-reviewers`, it doesn\u0027t mean it can\u0027t expand. The existence of this group gives us the tooling necessary to adopt a process like Ironic\u0027s, where promising core candidates are initially added to the reviewers group and eventually bumped to `nova-approvers`. This change is explicitly out-of-scope for this proposal, but it\u0027s worth noting as something else we get that the \"special +1\" proposal doesn\u0027t give us.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"4b01e033befe9fa8a8c771572b92358e9bb2db2c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"1db1b084_8cff8817","in_reply_to":"d3bea628_0c600339","updated":"2026-08-19 13:28:56.000000000","message":"Life (👶) got in the way, unfortunately. I\u0027m picking this up again ahead of the Indri cycle.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"}],"doc/source/contributor/policies.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"afb175f7e75763b0e3b8844d2e41b4398b544d02","unresolved":true,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"All non-trivial [#f1]_ patches require two +2s and a +W (workflow) before they"},{"line_number":63,"context_line":"can be merged to Nova. +2 votes can be added by any member of the nova-reviewer"},{"line_number":64,"context_line":"group while +W votes can be added by any member of the nova-approver group."},{"line_number":65,"context_line":"Collectively we refer to people in these groups as core reviewers (commonly"},{"line_number":66,"context_line":"referred to as a \"maintainer\" in other communities)."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"d728ca7d_17d2a222","line":64,"range":{"start_line":64,"start_character":55,"end_line":64,"end_character":68},"updated":"2026-09-10 13:01:52.000000000","message":"Will we sync the doc to the landed ACL or will there be additional ACL changes to rename nova-core to nova-approver?","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"79e1b8bc65e57da59f7a54a7e56803c80fb75a01","unresolved":true,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"All non-trivial [#f1]_ patches require two +2s and a +W (workflow) before they"},{"line_number":63,"context_line":"can be merged to Nova. +2 votes can be added by any member of the nova-reviewer"},{"line_number":64,"context_line":"group while +W votes can be added by any member of the nova-approver group."},{"line_number":65,"context_line":"Collectively we refer to people in these groups as core reviewers (commonly"},{"line_number":66,"context_line":"referred to as a \"maintainer\" in other communities)."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"319ed409_2d2d9949","line":64,"range":{"start_line":64,"start_character":55,"end_line":64,"end_character":68},"in_reply_to":"184d51c3_3c2082e4","updated":"2026-09-15 10:38:50.000000000","message":"OK. I\u0027m not sure whats the benefit of having a name change if it means the old group remains as well. But I will not pick on this. My point here is just to keep the doc an the world in sync.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"2c866b011fa59613c7f22fdd32c096ea970fbd20","unresolved":true,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"All non-trivial [#f1]_ patches require two +2s and a +W (workflow) before they"},{"line_number":63,"context_line":"can be merged to Nova. +2 votes can be added by any member of the nova-reviewer"},{"line_number":64,"context_line":"group while +W votes can be added by any member of the nova-approver group."},{"line_number":65,"context_line":"Collectively we refer to people in these groups as core reviewers (commonly"},{"line_number":66,"context_line":"referred to as a \"maintainer\" in other communities)."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"184d51c3_3c2082e4","line":64,"range":{"start_line":64,"start_character":55,"end_line":64,"end_character":68},"in_reply_to":"d7141fba_c454e84e","updated":"2026-09-10 15:46:07.000000000","message":"Yes, I think we should still rename `nova-core` to `nova-approvers`, like Ironic has done. The only reason I didn\u0027t do that in the same patch is that I wasn\u0027t sure at the time what the impact of this on the existing `nova-core` group would be. I\u0027ve since found out that can\u0027t rename a group and while you can delete one we\u0027ve never actually done this. This means nova-core would hang around as a useless appendage forever which seems fine but is something we probably want to document here.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"db709051a8549cf236f591ff0dae38c995ee1ca7","unresolved":true,"context_lines":[{"line_number":61,"context_line":""},{"line_number":62,"context_line":"All non-trivial [#f1]_ patches require two +2s and a +W (workflow) before they"},{"line_number":63,"context_line":"can be merged to Nova. +2 votes can be added by any member of the nova-reviewer"},{"line_number":64,"context_line":"group while +W votes can be added by any member of the nova-approver group."},{"line_number":65,"context_line":"Collectively we refer to people in these groups as core reviewers (commonly"},{"line_number":66,"context_line":"referred to as a \"maintainer\" in other communities)."},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"d7141fba_c454e84e","line":64,"range":{"start_line":64,"start_character":55,"end_line":64,"end_character":68},"in_reply_to":"d728ca7d_17d2a222","updated":"2026-09-10 14:58:35.000000000","message":"no there was orgianlly 2 groups propose\n\nnova-reviewr and nova-approvers we have only merge teh patch for the first group the second is still open so i was expecting use to create both add nova-core to both and to then decied if/when to add others after all this was merged","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"79e1b8bc65e57da59f7a54a7e56803c80fb75a01","unresolved":true,"context_lines":[{"line_number":77,"context_line":"services. It is expected that users in the latter may be added to the former"},{"line_number":78,"context_line":"over time, based on their contributions."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":".. note: The above description of nova-reviewer may be expanded in the future"},{"line_number":81,"context_line":"   to include folks who are working primarily on nova and may be on track to be"},{"line_number":82,"context_line":"   added to nova-approver in the future but are still building experience. This"},{"line_number":83,"context_line":"   is intentionally **out-of-scope** for this change to allow proposals to be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"eb1991be_4034c370","line":80,"range":{"start_line":80,"start_character":9,"end_line":80,"end_character":47},"updated":"2026-09-15 10:38:50.000000000","message":"the above description is about nova-approvers (nova-cores).","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"c41427c960a45037dd444c4d8af431a8cbe3a544","unresolved":true,"context_lines":[{"line_number":105,"context_line":"too thin and the core team shrinks."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":".. [#f1] What constitutes \"non-trivial\" is of course subjective, but it"},{"line_number":108,"context_line":"         includes things like obvious typo fixes or small, provably correct bug"},{"line_number":109,"context_line":"         fixes."},{"line_number":110,"context_line":".. [#f2] By way of a concrete example, it is desirable that patches that add a"},{"line_number":111,"context_line":"         new feature that depends on neutron would be reviewed by neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7f0753b3_96c64018","line":108,"range":{"start_line":108,"start_character":59,"end_line":108,"end_character":67},"updated":"2026-04-24 22:32:36.000000000","message":"sorry, hate nit picking, but get this typo when/if you make another update","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2f0393e8f2aaa8a8a602b31408ae188cc563a46c","unresolved":true,"context_lines":[{"line_number":105,"context_line":"too thin and the core team shrinks."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":".. [#f1] What constitutes \"non-trivial\" is of course subjective, but it"},{"line_number":108,"context_line":"         includes things like obvious typo fixes or small, provably correct bug"},{"line_number":109,"context_line":"         fixes."},{"line_number":110,"context_line":".. [#f2] By way of a concrete example, it is desirable that patches that add a"},{"line_number":111,"context_line":"         new feature that depends on neutron would be reviewed by neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d888643b_ed2d38f0","line":108,"range":{"start_line":108,"start_character":59,"end_line":108,"end_character":67},"in_reply_to":"7f0753b3_96c64018","updated":"2026-04-26 17:37:34.000000000","message":"this is correctly spelled\n`provably`  as in something that is provabvle or demonstratable.","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"20134131a65ddbae99f3e30cad9a154e2e8357ce","unresolved":false,"context_lines":[{"line_number":105,"context_line":"too thin and the core team shrinks."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":".. [#f1] What constitutes \"non-trivial\" is of course subjective, but it"},{"line_number":108,"context_line":"         includes things like obvious typo fixes or small, provably correct bug"},{"line_number":109,"context_line":"         fixes."},{"line_number":110,"context_line":".. [#f2] By way of a concrete example, it is desirable that patches that add a"},{"line_number":111,"context_line":"         new feature that depends on neutron would be reviewed by neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"35ba863f_4ff0c105","line":108,"range":{"start_line":108,"start_character":59,"end_line":108,"end_character":67},"in_reply_to":"c32f61e5_db79c476","updated":"2026-04-27 18:41:11.000000000","message":"Done","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"c45c9798588d04a61758387bb4fd666809584fd6","unresolved":true,"context_lines":[{"line_number":105,"context_line":"too thin and the core team shrinks."},{"line_number":106,"context_line":""},{"line_number":107,"context_line":".. [#f1] What constitutes \"non-trivial\" is of course subjective, but it"},{"line_number":108,"context_line":"         includes things like obvious typo fixes or small, provably correct bug"},{"line_number":109,"context_line":"         fixes."},{"line_number":110,"context_line":".. [#f2] By way of a concrete example, it is desirable that patches that add a"},{"line_number":111,"context_line":"         new feature that depends on neutron would be reviewed by neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c32f61e5_db79c476","line":108,"range":{"start_line":108,"start_character":59,"end_line":108,"end_character":67},"in_reply_to":"d888643b_ed2d38f0","updated":"2026-04-27 18:41:02.000000000","message":"AH, my bad then. Sorry about the noise","commit_id":"fa388a8200493b039c0f7e9e136e7b31403d2be6"}]}