couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: [REQUES] Review proposed bylaws (Was: Re: [DISCUSS] Project bylaws)
Date Tue, 20 May 2014 22:06:01 GMT
Hi,

I finally reviewed this. It’s very good, congrats! My comments are principally about grammar;

"The foundation holds the trademark on the name CouchDB" — is this true?

"will be sorted out by a" — avoid idioms.

"people what hat you are wearing" — s/what/which/

"chair" — should be capitalised throughout when it refers to the Chair of the PMC.

ditto for "board".

"A contributor is someone who is contributing to the project in some way." — self-referential

"We prefer that decisions are made via:" is followed by three different decision forms that
are incompatible with each other. We should clarify that they are listed here in preference
order.

"Any consensus that is achieved away from the lists" — No such thing can occur, by definition
(the preceding sentence even says so). Change "consensus" here for something more appropriate.

Lazy consensus, as defined in 3.1, is too loose. The 3 day waiting period should be required,
the exceptions to that rule would need to be explicit to gain my vote.

"It is a very powerful tool that should be used to terminate a seemingly interminable discussion."
— Reword this. The intention of falling back to a formal vote is to make progress. It doesn’t
matter why progress had not been made before, and this sentence names only one example of
that.

"All formal voting must be done in an email thread the appropriate subject tag." — is missing
a "with".


On 20 May 2014, at 22:43, Jan Lehnardt <jan@apache.org> wrote:

> 
> On 15 May 2014, at 17:49 , Noah Slater <nslater@apache.org> wrote:
> 
>> Jan/Bob, can I get your review of this too please?
> 
> Sorry for the delay.
> 
> 
> 1. last paragraph: “If you are participating on the mailing list you have the right
to make decisions.” — *The* mailing list is undefined as of this part of the document.
We should make that more clear.
> 
> 2.3. would specifically invite designers, both visual and user interface designers. Not
sure we need a name like COPDOC.
> 
> 2.4. I’d say handling security issues are the responsibility of the committers in a
private forum. That bit should be moved to 2.3. At least that’s what we’ve been doing
in the past, would be good to reflect that.
> 
> Same for release management.
> 
> What are litigation protection mechanisms and why do we need them? (i.e. explain this
a little, or link to a resource that does).
> 
> “The PMC operates at the discretion of the project chair.” I don’t understand what
that means.
> 
> 2.5. could include a pointer to PMC chair election process.
> 
> 3. “Our goal is to eschew permission culture” could be rephrased to be simpler for
non-native speakers.
> 
> 4.1. bikeshed: would prefer tags to be lowercase.
> 
> 
> 
>> 
>> On 13 May 2014 23:23, Sebastian Rothbucher
>> <sebastianrothbucher@googlemail.com> wrote:
>>> +1
>>> As it is
>>> 
>>> Von meinem iPhone gesendet
>>> 
>>>> Am 11.05.2014 um 17:35 schrieb Noah Slater <nslater@apache.org>:
>>>> 
>>>> 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
>> 
>> 
>> 
>> -- 
>> Noah Slater
>> https://twitter.com/nslater
> 


Mime
View raw message