For completeness: > - an approved member CANNOT approve their own changes > - an approved member CAN approve a complete stranger's changes > - an approved member CAN approve a another approved member's changes
A potential issue which has popped up a couple of times is whether it's acceptable for another staff member from the same organisation to approve their colleague's PRs. Is this acceptable or not? Is it a conflict of interest? Does it lean toward lenient reviews and getting a speedy merge? Or is it good practice because the organisation isn't placing any burden on others outside of their organization? 🤷 Who knows! But definitely work discussing if we are writing up formal policies... Nyall > > I think the misunderstanding is all about naming. If we drop the > confusing "core committer" label and change it to "approved reviewer", > then everything becomes clear. > > (and then we have a separate "super user" group with repo admin level > privileges, which should be kept as SMALL as possibly needed to keep > the repository and CI working, and is unrelated to > code/trust/experience/etc...) > > > Another policy I believe in is that whoever is allowed to apply > > changes to the repository should take on the responsibility of > > fixing bugs introduced by those changes. > > I'm a hesitant +0 to this. I do think we've all got a good track > record of fixing our own mistakes within reasonable expectations. I'd > be concerned that formalising this would put a lot of unreasonable > expectations on developers (where's the limit? If it's found that I > broke some esoteric workflow not covered by unit tests 3 years later, > am I still responsible for fixing that? I'd argue not). > > Nyall > > > > --strk; _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
