We could institute a "SOS" type thing where people can request a timeout on a change to properly review or discuss it. And we can put a time limit on it. So you'd say "I'd like to request we back out X changeset and discuss it." And then you have like Y days to get consensus on what to do about it. But it's still a consensus based thing.
That gives you your emergency brake power, but without allowing PMC consensus to be unilaterally overridden by an individual. On 20 July 2014 00:17, Robert Samuel Newson <rnew...@apache.org> wrote: > On vetos, I’d approve of restricting them to release branches (of any > repository) but I’m wary of wording it that finely (that is, leaving us > unable to veto something objectionable that falls outside of that description > when regular ASF rules would otherwise have permitted one). > > To the notion that we have no vetos at all. I do understand the appeal and I > will give it some more thought but I’m currently unconvinced. I’m unsure on > which side the burden of proof lies here, but I tend to agree with Noah that > it’s on the side of those that wish to preserve the power of veto (like > myself). > > I hope we’d all agree that there are hypothetical cases where a code change > can be damaging without being obviously broken. It might be that just one > person is able to see that damage and the appropriate response is a veto (a > -1 vote on the code change while it’s in review). It would obviously come > with a description of the problem, but it might take some time to explain and > unpack that explanation. The veto prevents it hitting master (where it is > theoretically releasable). > > I don’t think that’s too contrived (I can think of a few code changes that > needed this response) and I don’t think it will happen often, but I think it > *will* happen. Without vetos, perhaps things are no worse in practice? The > main difference would be that the brokenness would appear in otherwise > releasable branches (and be reverted and then redone differently). We do > strive to make master always releasable but we only ever assert that property > for release artifacts themselves in practice to date. > > I’d like to hear other people’s positions on the 'no vetos' position. I think > the topic might even be moot if we formally adopt the RTC policy I sketched > earlier. Requiring assent for merges to master covers my basic fear of > unreviewed nonsense entering the product unseen. > > B. > > On 19 Jul 2014, at 23:01, Joan Touzet <woh...@apache.org> wrote: > >> Hi Noah, >> >> I'm making most of the minor tweaks below directly now, except for the >> copyrighted one - asked 2 grammarians and they agreed on leaving the "by" >> in. As Jan also agreed I'm not going to bikeshed this one ;) >> >> The one section is repeated because it's bold - some people are only going >> to read the bold and I wanted continuity. I shortened it a little bit for >> clarity. >> >> Onto the vetos: >> >> I do not want to restrict vetos *just* to code changes. It should be >> possible to veto anything that is versioned - docs and design included - >> but again, this power should be exercised extremely rarely. For instance, >> if a committer decided to redo the main CouchDB logo without warning >> the list first, we'd want to veto that. >> >> I do agree that the text is a bit off here; "master branch" is insufficient, >> as commits to e.g. the "1.6.x" branch should be vetoable as well. Thus I >> am changing this to read "...release branches (master, 1.6.x, etc.)" >> >> From discussion, it sounds like you want to eliminate vetos entirely. I am >> undecided as to whether or not I am comfortable with this change. I'd like to >> hear others' viewpoints before deciding for myself. Either way, the bylaws >> represent the current policy, and I think this captures that adequately. >> >> -Joan >> >> >> ----- Original Message ----- >> From: "Noah Slater" <nsla...@apache.org> >> To: "Noah Slater" <nsla...@apache.org> >> Cc: dev@couchdb.apache.org, "Joan Touzet" <woh...@apache.org> >> Sent: Saturday, July 19, 2014 4:12:07 PM >> Subject: Re: [NOTICE] Updated Bylaws - final readthrough before vote >> >> Here goes, via email: >> >> "bolded text for" (formatting error?) >> >> "copyrighted by" (the original "copyright" here is more correct I believe) >> >> "will be supported by a healthy community over time" -- was originally >> "seen to by", meaning, code will be produced by the community. I >> believe this edit changes the meaning >> >> "taken on those mailing lists" -> "taken on the mailing lists" >> >> "A contributor is someone who adds value, content or supports the >> project in some way." -- was originally "is contributing to". I don't >> understand why this has changed. There's no need to clarify, perfectly >> fine to just say a contributor is someone who contributes. It's a >> simple definition because it's a simple concept. No need to complicate >> it. >> >> "Community" -- would add "(community management, marketing, etc.)" >> >> "(which includes management, design, UX, branding, marketing...)" -> " >> (blogging, design, UX, branding, etc.)" >> >> "(includes globalisation/internationalisation and examples)" -> >> "(docs, examples, l10n/i18n, etc.)" >> >> "Managing confidentially-reported security issues" -> "Managing security >> issues" >> >> Cut " to drive most of these tasks as they arise." >> >> "uses the Apache STeVe approach" -> "uses Apache STeVe" >> >> "are made on our mailing lists via" -- cut "on our mailing lists", >> redundant info >> >> "If lazy consensus cannot be reached and discussion does not result in >> general agreement on a course of action, move to a vote." -- seems to >> be a repetition of the preceding para? Would also replace "general >> agreement" with "consensus" so we're using the same term throughout >> >> "If a change is made to project assets that a committer determines >> will adversely impact the integrity of the project, committers can >> exercise veto power." -- disagree with this sentence. Too broad. We >> need to very carefully think about what we are going to allow vetoes >> on. When we discussed this on IRC, I suggested it was any code changes >> to a shippable branch of a source tree. I stand by that. But think we >> should have this discussion on the ML and agree on it before moving a >> summary to the bylaws. >> >> Most of the above is minor. The last point is a major issue though. >> >> Thanks again for picking this up and driving it Joan! >> >> On 19 July 2014 21:58, Noah Slater <nsla...@apache.org> wrote: >>> Joan, how would you prefer my feedback? Edits made directly to the >>> doc, or via email? There are some things I'd like to change. >>> >>> On 17 July 2014 06:23, Joan Touzet <woh...@apache.org> wrote: >>>> After discussion with Noah Slater today, and as discussed in the CouchDB >>>> IRC meeting today, I will be driving the bylaws and CoC through to votes >>>> and formal adoption. >>>> >>>> Based on unaddressed comments in the previous mailing list discussion, I >>>> have updated the proposed bylaws text. Those updates are here: >>>> >>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017 >>>> >>>> Changes made since the last version can be viewed here: >>>> >>>> >>>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=40511017&selectedPageVersions=70&selectedPageVersions=69 >>>> >>>> The primary changes were: >>>> >>>> 1. Bolded text now serves as a intro guide for new participants and >>>> highlights the important points of which they should be aware. >>>> This should make absorbing the long document easier for newcomers. >>>> >>>> 2. Reworked text in the veto section to clarify misinterpretations. >>>> There *are* some semantic changes here, so please re-read this >>>> section carefully. >>>> >>>> 3. Compromise on the COPDOC section: acronym removed, concept remains. >>>> >>>> 4. Various grammar edits for clarity. >>>> >>>> At this point, the bylaws are mostly stable, but there may remain some >>>> tweaks to the text necessary to ensure they match how we have been >>>> running the project for some time now. We (the PMC) acknowledge that >>>> they are not perfect, but we do not want to let the perfect to be the >>>> enemy of the good (thanks to Voltaire), so we're moving ahead with them >>>> in the state they're in. >>>> >>>> Further, use of these bylaws, or especially any loopholes or imprecise >>>> language therein, as a weapon against others acting in good faith is >>>> neither within the spirit of the bylaws themselves nor considered >>>> acceptable behaviour - and will be dealt with accordingly by the PMC. >>>> >>>> It is my intent to call a formal vote on these bylaws as of Monday, June >>>> 21. PLEASE take the time to make a final read-through and get any >>>> corrections to me before then. >>>> >>>> Per the proposed terms in the bylaws, this non-technical vote will >>>> be by majority approval with no vetos allowed. Further, ALL ACTIVE >>>> COMMITTERS are respectfully asked to cast their vote at that time. >>>> >>>> -Joan Touzet >>> >>> >>> >>> -- >>> Noah Slater >>> https://twitter.com/nslater >> >> >> >> -- >> Noah Slater >> https://twitter.com/nslater > -- Noah Slater https://twitter.com/nslater
