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 <nsla...@apache.org> wrote: > On 5 May 2014 10:54, Benoit Chesneau <bchesn...@gmail.com> 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
