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 Mon, 05 May 2014 08:54:25 GMT
On Sat, May 3, 2014 at 4:31 PM, Noah Slater <> wrote:

> Modified the bit in the committer section to read:
> "Committers are expected to work cooperatively and to have good people
> skills. This is more important that any other sort of skill."
> Reminder to folks: please review this. It is an exceptionally
> important document, and I'd rather have commentary on it now, than
> after we vote it in.
> (And yep: I am aware of the irony of pressuring people to comment on a
> document that says don't pressure people to comment. But it's
> important that we bootstrap these expectations properly.)
> If nobody comments in another three days, I will move this to a vote.
> I have also decided that unless someone speaks up about it before
> then, I'll start a thread after we vote this in asking what to do
> about the chair. (i.e. Should we hold our first election, or do we
> wait a year?)
I am not sure to see the interest of these by-laws. They look redundant
to the the *practices* documented inside the apache foundation

Why not simply link to them? Anyway I am not against repeating them in
another place. However the current form looks a little too much
procedural and complicated (looks like the by-laws inside some
administrative places there), something can be done with it.

I have a couple of observations and questions on these by-laws that
hopefully can be addressed before any vote:

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

I can see the intent here: having long discussion that goes nowhere or
are blocking the project. In some others organisations, there are some
practice that could limit the effects of profound disagreements (which
are quite normal and expected): The place to discussion happen in a
very limited time and have a deadline. If at the end of the deadline no
consensus emerge, someone (generally a person chosen at the beginning of
the discussion) decide to either:

- propose a vote
- continue the discussion on some points where some consensus can be
- postpone the idea for later
- ...

I think it would be good to add such procedure to the discussion
handling, so any conflict can be handled gracefully with little place to
the frustration.

Of course we shouldn't have always a discussion,especially when the lazy
consensus is needed for code. I think we should distinct some cases. Or
describe how/when a lazy consensus should be the default, and other
cases where the discussion should happen before anything else so the the
conflict could be handled gracefully.

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

Rather what is a bad opinion for the project (i.e. an expression of an
idea) there? How do you put the limit?

I think we should remove that part is can trigger to more conflict that
it try to solves or make it more specific.

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

Also If we are going to the path of defining by-laws, I think we should
take this opportunity to innovate a little and make the project reflects
more the community:

- 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

- The same for a chair. We could make it renewable more often. For
  example each 3 or 5 years.

What people think about it?

- benoit

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