couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Date Wed, 07 May 2014 19:07:57 GMT
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

Mime
View raw message