Looks good to me.
On 05/07/2014 09:07 PM, Noah Slater 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 > > >
signature.asc
Description: OpenPGP digital signature
