couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mutton, James" <jmut...@akamai.com>
Subject Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Date Mon, 19 May 2014 21:19:24 GMT
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 <nslater@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 <nslater@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 <nslater@apache.org> wrote:
>>> On 5 May 2014 10:54, Benoit Chesneau <bchesneau@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


Mime
View raw message