Again, no one on an Apache project has any authority over anyone else. Obviously a member with GIT write access has more power than one that is not, but we cannot compel anyone to do anything and we cannot punish anyone for not following rules.
If a committed PR is harmful it can be reverted whole or in part through another PR. We govern with guidelines and "peer pressure" to follow those guidelines. There is no power hierarchy. I am a little confused by a change request. Is that just a problem report via an Issue? Or are you talking about a code change. A person without GIT write access can do whatever they choose to the change request. So can others. There can be no punishment other than "public shaming." For PRs that change code, the "guideline" has always been the opposite: The person that created the PR cannot commit the without review and concurrence from at least one other person. We have had the problem that this other person is a submitter's friend and the PR is closed before world-wide community has had time to review the change. Being world-wide, several days should elapse before resolved the Issue or committing the PR. ________________________________ From: Matteo Golin <[email protected]> Sent: Tuesday, November 11, 2025 7:41 PM To: [email protected] <[email protected]> Subject: Re: [DISCUSS] Dismissing PR reviews - rules Huh, I suppose I missed this in the guidelines! I suppose the wording with the new proposed rule is more direct that the only person who can decide if a change request is resolved is the person who created it. Although that would have always been my understanding. Thank you for pointing this out! You're right, then at this point we should figure out what to do when someone violates the rule. We should probably revert the PR that was merged, as a first step. But if someone has repeatedly broken the rule, I'm not sure what a "punishment" would be. I don't think there's many configuration options around these change requests on GitHub unfortunately. I am pretty sure they stay on the PR even after changes are pushed, I think only approvals get dismissed as stale? I'm not certain. Matteo On Tue, Nov 11, 2025, 9:45 PM Tomek CEDRO <[email protected]> wrote: > On Wed, Nov 12, 2025 at 12:15 AM Alan C. Assis <[email protected]> wrote: > > I think it is always better to just add a comment instead of a Change > > Request, but sometimes I put the a comment asking the change, but then > two > > people approve the PR, in this case I have no other option than add a > > Change Request. > > > > I think this proposal is good to avoid ignoring the CR. Currently to > merge > > a PR all comments need to be resolved. But just like Change Request > anyone > > with write access can mark comments as Resolved. So Change Request is the > > last barrier. > > Yes, some changes may be even harmful, CR in that case blocks them, > this is good behavior, and if the CR comes from a "binding" PMC member > with a detailed explanation then it must not be canceled even after > 72h period because this will result in vote that will be blocked by > the "binding" vote anyway. > > I guess this discussion is about what to do with people who break CG > rules right? > > I tired to implement github rules that would block merging with > unresolved discussions, but when someone pushes an update the > discussion is auto-dismissed, maybe there is a way to improve / fix > this? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
