<div dir="ltr">Hi Sandro,<div><br></div><div>Thanks for raising this discussion. I'll add my knowledge inline below.</div><div><br></div><div>But please keep in mind that all this stuff has just been set over time in a reactionary/evolutionary process to keep things running smoothly, rather than something which was designed and formalised by a committee in advance. There's always room for improvement and revision to match current needs! 👍<br><br>On Sat, 14 Oct 2023 at 05:43, Sandro Santilli via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> wrote:<br>><br>> It's not just me, I think, but I cannot tell for sure because the configuration<br>> of the infrastructure currently in use (github) is not available for me to see<br>> and the governance page on the official QGIS website does not contain this<br>> information [2]. This being blind of course adds up to my frustration.<div><br></div><div>This page **definetly** needs an update. There's information on that page which is ~decades out of date (eg Larry Shaffer hasn't been involved in the project for around 10 years, the OSX packaging team is incorrect, and the whole "testing" team is non-existent, etc). </div><div><br></div><div>I'm happy to help out here with removing old content. My gut feeling is that a more exhaustive rework is needed and repository / process related information doesn't belong on this page, and the page should be left to the "organisation" level governance information alone.</div><div><br>> From experience, I know that the reason why I cannot write to the QGIS<br>> repository is because "branch protection" is active (for the master branch<br>> at least) and a set of conditions are required to merge a PR, namely:<br>><br>>   - All CI tests need to pass.<br>><br>>   - Someone else (I don't know from which group of people) needs to<br>>     approve the proposed change.</div><div><br></div><div>Correct. And I would argue that both of these requirements are a valid **MINIMUM** protection choice for introducing code into a project which has real world cost impacts for users exceeding millions and potentially impacting the lives and safety of others. </div><div><br>> 1. CI is often broken for reasons that are independent from the proposed<br>>    change.</div><div><br></div><div>Definitely a valid issue, and a real PITA. I'm probably restarting that mingw workflow ~20x a day for everyone's(!) PRs to keep it limping along.</div><div><br></div><div>That said, I'd still rather limp this workflow along vs removing it, because I do believe that it adds value to our tests and gives end users an easy way to test PRs prior to merge. I feel the same about the noisy clang-tidy check: it has a LOT of false positives, but around 1 in 10 failures in that workflow is a valid bug which has been flagged prior to introducing the code. That's still a net win in my view.</div><div><br>> 2. An aberration of the "review" condition is that a change proposed by a<br>>    contributor and approved by me can be merged but a change proposed by<br>>    me and approved by the same contributor can not be merged, effectively<br>>    giving me ("core QGIS committer") less power than the power of a random<br>>    contributor.</div><div><br></div><div>Maybe -- but I would argue that you're looking at the "core contributor" privilege incorrectly. It's no longer a "you are trusted to put whatever code you want into the project" vs a "you are trusted to peer review and approve code proposed for introduction into the project".</div><div><br></div><div>Ie **everyone** is on the same level wrt to submitting code for review, but only the trusted group of core committers are permitted to approve this code for introduction to QGIS. </div><div><br></div><div>>   1. Clearly document the roles and rules on the website</div><div><br></div><div>+1</div><div><br>>   2. Allow those with "write access" to self-approve PRs</div><div><br></div><div>-1. What's the real motivation here? Why the urgency to get unreviewed code into QGIS? Again, I am strongly of the opinion that more exhaustive code merging policies protects our users and their trust in QGIS. </div><div><br></div><div>>   3. Define rules by which "write access" privileges to the repository<br>>      are revoked</div><div><br></div><div>+1</div><div><br></div><div>Nyall</div><div> </div></div></div>