Shane, Rich, I think we are agreed on the points that I raised. The documentation in the advice/templates did conflict with policy on a number of issues.
My concern was the comments scattered through the PR blizzard that made it seem that some folks did not understand the precedent and that Rich was correcting wrong information. I appreciate the work that Rich is putting in here to make the advice consistent with policy. Warm regards, Craig > On Oct 30, 2024, at 05:52, Rich Bowen <rbo...@rcbowen.com> wrote: > > > >> On Oct 29, 2024, at 10:25 PM, Craig Russell <apache....@gmail.com> wrote: >> >> I find it very difficult to deal with policy issues via GitHub PR comments. >> >> Could we please have a separate thread on the dev list where we discuss >> issues like: >> >> What does consensus mean? (I think elsewhere it is lazy approval) >> >> Can PMC votes be vetoed (by a single -1 vote)? >> >> Can committer votes be vetoed (by a single -1 vote)? >> >> If needed, I will volunteer to start such discussion… > > > > Since Shane has already responded in this thread … > > This is very clear to me, on three points - documentation, precedent, and > intent. From where I sit, the doc I was editing was simply wrong. > > The doc - https://apache.org/foundation/voting.html > <https://apache.org/foundation/voting.html> - says simple majority for > procedural votes. And while the doc can certainly be clarified, and > “procedural” is not defined, PMC/Committer election clearly does not fit into > the other categories in that doc. > > The precedent - since the beginning, and in every project I’ve observed or > been part of, PMC and Committer elections are not veto-able. Only code > changes are veto-able. This has been seen both in practice, and in the many > threads about this on members@ over the years. Only code changes can be > vetoed, and even then, only with a technical reason. There can be not > technical reason for a PMC/Committer election veto. > > The intent - this is more subjective, but from where I sit, allowing a single > PMC member to veto the election of a new Committer/PMC member would (could) > lead directly to a BDFL situation, which is antithetical to our ethos and > tradition. It would (could) result in a single PMC member exerting “founder” > status and having complete control over who joined the project. We already > see projects where one voice is “more equal than others”, and codifying this > in the ability to override a majority of the PMC would be chilling to > community voice and growth. > > So, to me, this is not a question of me challenging or changing policy. I was > correcting a factual error in a document that was supplementary to the > official doc. This doc is only intended to augment the official policy doc - > https://apache.org/foundation/voting.html > <https://apache.org/foundation/voting.html> - with best practice advice, not > alter or modify that official doc. > > If we want to start a new thread on this, it probably goes on members@ or > board@, and I’d be glad to reiterate the above there. > > —Rich Craig L Russell c...@apache.org
