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
