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 <[email protected]> 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" <[email protected]> > To: "Noah Slater" <[email protected]> > Cc: [email protected], "Joan Touzet" <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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
