Just read the current version, some small suggestions. Section 2 (recommend add word identified by *) "We expect you to know when to wear the appropriate hat, and when interacting with the project, to do so in *the* best interests of the…"
Section 3 Decisions should be made on the mailing list associated with the decision. e.g. Marketing decisions happen on the marketing list. * i.e. is read as "that is” and used as a restatement. e.g. (read as "for example”) is probably more appropriate here. Section 3.3 (recommend add word identified by *) "All formal voting must be done in an email thread *with* the appropriate subject tag. “ Overall +1. The above are only minor, the content is great. </JamesM> On May 11, 2014, at 8:35, Noah Slater <nsla...@apache.org> wrote: > 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 <nsla...@apache.org> 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 <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 > > > > -- > Noah Slater > https://twitter.com/nslater
