Noah, in section 3.4, Vetos: > Any change to the source code that we distribute in our official releases may be vetoed by casting a -1 vote on it.
Is that a -1 *binding* vote? Only committers can veto commits, right? > The validity of a veto can be put to a vote. Which kind of vote is this? It can't be majority. Majority must have no binding -1 votes (thus a majority vote is in a sense something that can be easily vetoed, like a release candidate). So the veto's validity itself can be easily vetoed. In other words, any individual can veto a veto. I don't see how it can be lazy majority or even lazy 2/3. That means that a sizeable group of people can invalidate a veto. So...that's not exactly a veto. The only vetos I can imagine happening are for trivial stuff where the committer cannot even muster 3 binding +1 votes. For anything major though, wouldn't a "veto" quickly become a vote for a popularity contest? Given the history of this project, I am actually comfortable with vetos being rare and difficult. However my point today is: I'm not clear what laws this section is actually making. Thanks! P.S. This is my first new wiki experience, and it is fantastic! On Thu, May 15, 2014 at 10:49 PM, Noah Slater <[email protected]> wrote: > Jan/Bob, can I get your review of this too please? > > On 13 May 2014 23:23, Sebastian Rothbucher > <[email protected]> wrote: > > +1 > > As it is > > > > Von meinem iPhone gesendet > > > >> Am 11.05.2014 um 17:35 schrieb Noah Slater <[email protected]>: > >> > >> Community, > >> > >> Please do take the time to review this document. It's not that long, > >> or that complex. An online reading time calculator said it's about 14 > >> minutes long. Your input at this stage would be very beneficial for > >> the project. (Anyone!) > >> > >> > >> > >>> On 7 May 2014 21:07, Noah Slater <[email protected]> wrote: > >>> Hello folks, > >>> > >>> Please review our propose bylaws: > >>> > >>> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=40511017 > >>> > >>> I'd like a few more eyeballs on this before I move to a vote. > >>> > >>> Thanks, > >>> > >>> > >>>> On 5 May 2014 18:35, Noah Slater <[email protected]> wrote: > >>>>> On 5 May 2014 10:54, Benoit Chesneau <[email protected]> wrote: > >>>>> > >>>>> I am not sure to see the interest of these by-laws. They look > redundant > >>>>> to the the *practices* documented inside the apache foundation > >>>>> documentation: > >>>> > >>>> The bylaws of the foundation are here: > >>>> > >>>> http://apache.org/foundation/bylaws.html > >>>> > >>>> They cover a completely different set of things at the foundation > >>>> level. And say very little about how projects must function. > >>>> > >>>> The resources you linked to are, at best, recommendations. They are > >>>> not binding. And in some cases they are contradictory. These represent > >>>> past efforts to distil common practice across many different projects. > >>>> > >>>> What our bylaws are doing is saying that we have specifically chosen > >>>> these interpretations, and that as a community we consider them > >>>> binding. > >>>> > >>>>> - In 4.1 : the sentence "Objecting too far down the road will cause > >>>>> problems.", and in 4.2 "If lazy consensus is not possible, you can > >>>>> move to a discussion" . > >>>>> > >>>>> The passage from a lazy consensus to a discussion is not clear. How > it > >>>>> is decided? Who is deciding it? > >>>> > >>>> Good catch. > >>>> > >>>> I have updated the wording to: > >>>> > >>>> "If lazy consensus fails (i.e. someone objects) you can start a > >>>> discussion or you can abandon the proposal." > >>>> > >>>> Does this address your concerns? > >>>> > >>>>> - In 4.2, there is "Proposals should be explained clearly and come > with > >>>>> adequate justification. Disagreements should be constructive and > >>>>> ideally come with alternative proposals. The goal is to reach a > positive > >>>>> outcome for the project, not convince others of your opinion." . > >>>>> > >>>>> Sorry but I don't understand that part. How can you expect that > people > >>>>> deeply attached to a project can't have an opinion on how it should > >>>>> works or be seen by the others? Also what is the point of a > discussion > >>>>> if it's not to convince others that your idea is OK? > >>>> > >>>> Interesting comment. > >>>> > >>>> If you enter into a discussion with the objective of trying to > >>>> convince the other person, and they do the same, all that will happen > >>>> is that you argue with each other until one person runs out of energy. > >>>> > >>>> I am more interested in the sort of discussion where both people put > >>>> aside preconceived notions, swap facts, debate points, and > >>>> cooperatively work towards a greater shared understanding of what is > >>>> being discussed. > >>>> > >>>> The goal then is not "winning" (i.e. convincing the other) but > >>>> expanding knowledge. Even if that means that you have been convinced > >>>> by the other person. > >>>> > >>>> Two people spend an hour arguing, and person A convinces person B of > >>>> their opinion. Typically, we would say that person A has won. > >>>> > >>>> Try modelling that discussion so that knowledge and time spent are > >>>> considered valuable, instead of pride. Both A and B spend time, but > >>>> only B receives new knowledge. So who is the real winner? > >>>> > >>>> This is important for the project because the first type of discussion > >>>> is not very valuable for us. The second is. That's why I put that the > >>>> end goal should be to reach a positive outcome for the project. > >>>> > >>>>> Rather what is a bad opinion for the project (i.e. an expression of > an > >>>>> idea) there? How do you put the limit? > >>>> > >>>> It's not opinions that are bad. Instead: modes of discussion. > >>>> > >>>>> - In 3.3 you added the notion of having "good people skills" for > >>>>> commiters. How do you define "having good people skills"? This > notion > >>>>> completely depends on the culture of the people interacting in the > >>>>> project. I propose to remove that sentence. It suffices to say that > >>>>> all contributors of the projects obey to the Code Of Conduct and make > >>>>> the Code Of Conduct enough generic. > >>>> > >>>> How do you define good technical skills? This stuff is always > >>>> dependant on individual interpretation. My goal here is to make it > >>>> explicit that as a project we value people skills over technical > >>>> skills. > >>>> > >>>> I would rather have someone who is helpful and cooperative on our > >>>> lists and who is only an average programmer, than someone who is > >>>> unhelpful and uncooperative who is an excellent programmer. > >>>> > >>>> This is not usually the case for OSS projects. But I believe it is > >>>> important. Which is why I want to bake it inout our bylaws. > >>>> > >>>>> - What about having the PMC members renewed each years by a vote of > the > >>>>> community? So they will be the choice of the community? PMC members > >>>>> could be proposed during a period by the community and then a vote > will > >>>>> happen. > >>>> > >>>> What benefits would this bring? > >>>> > >>>>> - The same for a chair. We could make it renewable more often. For > >>>>> example each 3 or 5 years. > >>>> > >>>> I've included this in the draft already. I am proposing that the chair > >>>> is reelected every year. > >>>> > >>>> Thanks, > >>>> > >>>> -- > >>>> Noah Slater > >>>> https://twitter.com/nslater > >>> > >>> > >>> > >>> -- > >>> Noah Slater > >>> https://twitter.com/nslater > >> > >> > >> > >> -- > >> Noah Slater > >> https://twitter.com/nslater > > > > -- > Noah Slater > https://twitter.com/nslater >
