couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] The Apache CouchDB Project
Date Wed, 22 May 2013 02:54:22 GMT
Just reply here! :)

On Wednesday, 22 May 2013, Randall Leeds wrote:

> Awesome! Thanks, Jan!
> How should we go about suggesting edits?
> On Tue, May 21, 2013 at 1:26 PM, Jan Lehnardt <> wrote:
> > Hi all,
> >
> > I was thinking about how to explain to someone how the CouchDB project
> works. I tried to not only describe the status-quo, but what we all roughly
> put forward in the Boston meeting a year ago and what we gathered in
> subsequent discussions. I think it is time to gather consensus around how
> we describe we operate and here is my take.
> >
> > The document is prescriptive, and an invitation to change just about
> anything in it. It is just my first stab at a document that describes how
> we work and we’ll need all your input to make it ours. thanks to Noah for
> his helping compiling this. I’ll put this on the wiki after a first round
> of your feedback.
> >
> >
> > * * *
> >
> > # Preface
> >
> > This document tries to describe on a high level what the Apache CouchDB
> Project looks like. This is, for the most part, a living, descriptive
> document. It shall describe what the community does, not prescribe what the
> community should do. For the things that are described here that aren’t in
> place yet, this document sets out the vision for these things, final
> details may vary.
> >
> > # How We Work
> >
> > Apache CouchDB is a project of the Apache Software Foundation (ASF), a
> US non-profit corporation. We value community over code and use
> consensus-based decision-making throughout the project. Apache CouchDB is
> released under the Apache 2.0 License, which is similar to the BSD and MIT
> licenses.
> >
> > All decisions are made on the mailing lists, and we do as much of our
> work in the open as we can. Issues are managed using JIRA at
> and code can be submitted via email
> to, JIRA or as a GitHub Pull Request at
> >
> > Apache CouchDB is a "do-ocracy". The direction of the project, and the
> decisions that we take are *in your hands*. Committer, developer, whatever.
> If you're on the mailing list, and you're participating in the discussion,
> then you've earned the right to make decisions for the project. We have no
> concept of "lead developer", and there are no "project elders" running
> things from behind the scenes. If you're on dev@, you're on the team.
> >
> > Apache CouchDB development is done by a number of loosely defined
> “teams”. Anyone can be a member of any team, just by participating in the
> discussions and contributions on dev@ (with exception of the security
> team and PMC, which make use of private lists).
> >
> > A “Team” is group of people working on a particular topic. There is no
> membership or elections. If you partake in a discussion of the
> documentation team, you are part of the documentation team. If you stop
> partaking in any discussions in the documentation team, you are no longer
> in the documentation team. Easy as that.
> >
> > At the moment, most of the activity happens on the
> mailing list, using a [PREFIX] in the subject
> line. Messages without a prefix are assumed to be related to general
> development work (the default team). Anyone can create a new team by
> inventing a new prefix. But please do so conscientiously! (Please also note
> that we use several pre-defined category prefixes for particular types of
> message. More details below.)
> >
> > A team can request resources as needed for their work, like mailing
> lists, git repositories, other bits of infrastructure, etc. Anyone on a
> team can request these things.
> >
> > If the activities of a team become too much for the dev@ list to
> handle, that's a good reason for us to create a new mailing list for that
> team. It is expected that a summary of the activity on this separate
> mailing list makes its way back to the dev@ list on a regular basis, but
> we will need to experiment with this to figure out what works best.
> >
> > The project has several "roles". Everyone starts out as a "user". Users
> who contribute back to the project are called "developers". When a
> developer earns sufficient merit, they are elected as a "committer". Merit
> can be earned in a number of ways, though typically it involves
> contribution to the community, documentation, project, or code. A committer
> is given write access to the project, both literally, in the form of a
> commit bit across the repositories, and figuratively, in the form of a
> binding vote. Committers who show sustained involvement in project-level
> decision making are elected to th


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