couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] Project by-laws
Date Wed, 30 Apr 2014 16:34:02 GMT
If you have not read my draft yet, just ignore this email and read it
from the start.

If you have, this email summarises my changes.

On 29 April 2014 23:28, Andy Wenk <> wrote:

> -> why not explicitly writing "... can contribute to the Apache CouchDB
> project ..." ?


> -> there is a word missing I think: " by being involved IN the community"?


> "Users can also participate in the project by being involved the community,
> either at the ASF or elsewhere."
> -> the intention of this sentence is not completely clear to me ... can you
> explain it?
> "Users who participate in the project through any mechanism are
> contributors."
> -> this sounds like there is no difference between Users and Contributors
> ... what is fine for me but is this what it should say here? Maybe it
> should read:
> "Users who participate in the project through any mechanism are ALSO
> contributors."

I have reworded this whole bit to:

"Users can participate in the project by talking about it, providing
feedback, and helping others.  This can be done at the ASF or
elsewhere, and includes being active on the user mailing list,
third-party support forms, blogs, and social media. Users who
participate in this way automatically become contributors."

Does this capture it better?

> First paragraph: in the first sentence singular is used and in the
> following sentence plural for committer. This is a bit confusing. But maybe
> this is correct and my lack of knowledge of the English language.


> "... to all of public project infrastructure ..."
> should read:
> "... to all of public THE project infrastructure ..."


> 3.4. Project Management Committee
> -> maybe write "3.4. Project Management Committee (PMC)"


> "This includes:"
> -> maybe add responsible to take action, if CoC violations are coming to
> the PMC's attention

This is included under "community management" for now. My intention
here is that with the CoC we will make a patch to our bylaws to
include specific rules about how infractions are handled.

> " must be brought for the lists for the decision making process to take
> place in the open. "
> -> I don't understand this completely ... can you explain this? Or should
> it read:

Changed to:

"Any consensus that is achieved away from the lists (for example on
IRC or in person) must be brought to the lists before anything is
decided. We have a saying: if it's not on the lists, it didn't happen.
We take this approach so that the most amount of people have a chance
to participate."

> "As long as you do your work in the open the community has plenty of
> opportunity to object."
> comma after "open" and I think it should read "plenty of opportunities"?


> 4.2. Discussion
> "Voting is to be considered a failure mode of discussion."
> -> hm - are there really no situations where a vote is sth. someone wants
> to have? As far as I understood, voting is the main way to get a clear
> consensus.

Yeah, I'm trying to get away from that. Voting is permission culture.
JFDI should be our default mode. Having to take a vote is an
indication that either this is either a) important, or b)

Changed to:

"Voting is a failure mode of discussion. That doesn't mean you should
avoid it. It is a very powerful tool that should be used to terminate
a seemingly interminable discussion. Knowing when to end a discussion
and call a vote is one of the most useful skills a contributor can

Also adjusted this text:

"Occasionally people choose to vote with larger amounts to indicate
extreme feelings, or in fractional amounts to convey strong reluctance
without the full weight of -1 vote. For the purpose of tallying votes,
values must be counted as one of the four values above."

> 4.5. Approval Models
> "The ASF has a voting tool specifically designed to enable this process."
> -> we should link to a resource here


> 5.1. Subject Tags
> -> should we add the tag [NEWS] into the list?

Nah, I don't think so. I am not even sure what we use that for yet.
But we can always patch the doc later.

I have also made the following changes:

To the PMC section, I added:

"From a foundation perspective, the role of the PMC is oversight. The
PMC must ensure that all legal issues are addressed, that procedure is
followed, and that each and every release is the product of the
community as a whole. That is key to our litigation protection

"Secondly, the role of the PMC is to further the long term development
and health of the community as a whole, and to ensure that balanced
and diverse peer review and collaboration does happen. For this
reason, one of the most basic tasks of the PMC is the recruitment and
retainment of project contributors. As a volunteer organisation,
volunteer time is our most precious resource. And we believe that the
size, diversity, and health of the community is essential for the
quality, stability, and robustness of both code and long term social

Also changed this bit:

"PMC members are held to a much higher standard than regular community
members. This includes strict hat wearing, equitable decision making,
and exemplary conduct."

Added these bits to the chair section:

"It is not a technical leadership position, meaning the chair has no
special say in ordinary project decisions. But we do think of it as a
cultural leadership position. Accordingly, position on cultural issues
is something to consider when electing a chair."

"The chair is the eyes and ears of the board, and reports quarterly on
developments within the project."

"As an officer of the foundation, the chair has extraordinary powers,
up-to and including the disbandment of the entire PMC. While the use
of such powers if obviously not expected, if it could be justified to
the board, the Chair has the power to enact any sort of change."

Added this to the start of the roles and responsibilities section:

"Your role at the ASF is one assigned to you personally, and is
bestowed on you by your peers. It is not tied to your job or your
current employer."

"Hats are key concept at the ASF. You might have your employee hat and
your personal hat, for instance. We expect committers (and PMC members
especially) to know when to wear the appropriate hat. Failure to do so
is a serious dereliction of duty."

"Sometimes it is a good idea to tell people what hat you are wearing.
For instance, the chair might start an informal email by stating they
they are not wearing the chair hat, just to be clear about how the
statements ought to be interpreted."

"Committers and PMC members are never removed because of inactivity.
Because of the way our decision making works, inactive committers and
PMC members pose no problem to the project as long as we have enough
active people for votes to pass. Committers and PMC members will only
be removed if the position they hold is actively causing problems for
the project. The chair is one exception to this. An inactive chair can
be replaced by the PMC, as the chair has certain responsibilities that
cannot be fulfilled by anyone else."

In the contributor section, I shortened the description to:

"A contributor is someone who is contributing to the project in some
way. Contributions are not limited to code. Anything that helps to
promote and improve the project or community counts."

In favour of beefing out the committer section with some additional
stuff about COPDOC (which I've borrowed from Apache Forrest). And I've
created a stub contributor guide, as all the details I found myself
adding about how to contribute started to feel like it should be
something fluid and not encoded in our bylaws.

(Big WIP right now. But let's flesh this out as we go.)

I also added:

"Committers are expected to work cooperatively with other
contributors, and to mentor new contributors if possible. Our
committers make up the bulk of our active community, and as such, we
rely on them to help us build and maintain that community."

To lazy consensus, I added:

"It also means that if you make a proposal to the list and nobody
responds, that should be interpreted as implicit support for your
idea, and not a lack of interest. This can be hard to get used to but
is an important part of how we do things."

Under approval models, I added this:

"However, it is important to remember that all participants on a list
get a vote. And you are encouraged to to vote, even if your vote is
not binding. This is a good way to get involved in the project and
helps to inform the decision-making process."

Noah Slater

View raw message