Hi, I read the bylaws again.
3. Roles and Responsibilities -> last paragraph "Committers and PMC members are never removed": this content feels a bit out of context. Maybe move it to 3.3 and 3.5 3.3 Committers -> third paragraph "... it means you are committed to the project ..." is double because it was already stated at the beginning of the section. The rest looks very good:) Cheers Andy 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 > -- Andy Wenk Hamburg - Germany RockIt! http://www.couchdb-buch.de http://www.pg-praxisbuch.de GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 https://people.apache.org/keys/committer/andywenk.asc
