couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [DISCUSS] Project by-laws
Date Fri, 16 May 2014 08:02:58 GMT
I saw the review thread, but inline answer look more appropriate. Anyway,
feel free to forward to it if needed.

On Mon, May 5, 2014 at 6:35 PM, Noah Slater <> wrote:

> On 5 May 2014 10:54, Benoit Chesneau <> 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:
> They cover a completely different set of things at the foundation
> level. And say very little about how projects must function.

This is why I didn't link this one. I was specifically referring to the
by-laws defined on the wiki which are based on all the links I provided.

> 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.

I understood that. Linking for me is like binding, but like I said I have
no objections to another doc.

> > - 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?

We should grade the level of the proposal. Or at least give some examples.
There are case where discussing first is more appropriate and maybe we they
should be highlighted. While the default stay the lazy consensus.

> > - 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.
I didn't speak about winning a discussion. A discussion is in my opinion
the way to find the point where people agree or disagree and took
appropriate actions based on it. This is not a question of energy.
Disagreement is part of a discussion and people should be ready to accept
it. I don't see any negativity in convincing someone. Conviction shows that
how deep the other is invested in the project. If all of the discussion
follow a gentlemen's agreement or CoC everything is fine.

But I agree that a discussion should not continue indefinitely and this is
why I proposed a solution commonly used in such case. I think it worth to
work on such solution, so a discussion can end gracefully.

> > 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.

Maybe that could be made more clear?

> > - 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.

My point is not technical skills vs people skills, but about using a notion
vaguely defined and not present in most parts of the world and
dictionaries. However nothing in the by-laws refer to the CoC. I think that
the CoC + Diversity texts suffice to cover this concept and rather than
using a vague notion, we should link to them.

> > - 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?

By doing it the community control the board and you don't let members using
a private ml co-opting themselves. It doesn't have to be each years though.

> > - 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message