On 20 July 2014 00:01, Joan Touzet <woh...@apache.org> wrote: > 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.
That there is disagreement is a sign that we never had a shared understanding of what could be vetoed in the first place. :) I see zero reasons for vetos to exist, and I think it is reasonable for me to require a justification for their inclusion. Whether or not we're allowed to remove vetos is up to the Board. And we can ask them for permission if we decide we want to remove them from our project. Again, I ask: in what scenario is a veto useful? Every situation I can imagine can be solved by calling a PMC vote and going with the consensus. Vetos carry a very real risk: individuals blocking group consensus. What we're saying by allowing them is that in situations where the PMC can demonstrate consensus on a topic, we'd like to hand power to individuals to block action on that consensus. I'd like to know under what circumstances this PMC feels that individuals ought to have the right to block PMC consensus. -- Noah Slater https://twitter.com/nslater
