couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: [DISCUSS] The Apache CouchDB Project
Date Wed, 22 May 2013 00:37:24 GMT

It's heavy on the taxonomy of tags for my tastes, but that's ok.  I definitely like the walkthrough
of user -> developer -> committer and beyond, and the list of teams is a good nudge
to encourage contributions.

I'm not sure there's much of a point to a [GENERAL] team/tag, and the description "This is
private@ for everything that doesn't have to be private" probably only makes sense for folk
who have been on an ASF PMC.

Thanks for taking the time to draft this.


On May 21, 2013, at 4: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 the Project Management Committee, or PMC.
The PMC's primary duty is to recognise merit, and elect new committers.
> (There's a bit more to it than this, but we'll elide the details...)
> There is *no* requirement for you to be a committer before you start contributing to
a team. In fact, we expect teams to be a mix of developers and committers.
> If you are contributing to a team as a developer then you may have to go through the
additional step of getting a committer to apply your changes. This will be the case if you
are contributing patches. But it should not be the case if you are helping out with tickets,
or the wiki, or testing, etc.
> For code changes, you are welcome to contribute however you like. Fork us on Github,
and submit pull requests. Attach patches to tickets in JIRA, or send them to the mailing list.
Whatever works! You're only going to be doing this for a short amount of time anyway. The
PMC wants to remove obstacles and so sending us lots of patches is usually a fast-track to
a commit bit.
> Decision making is done according to our by-laws, which specify what sort of decision-making
must be used in different contexts. Our default is model is "lazy consensus", which is the
principal that if you think something is good for the project, you can go right ahead and
do it. i.e. "It's easier to ask forgiveness than it is to seek permission." When we need to
give things a little more consideration, we rely heavily on consensus-building through discussion
and formal voting.
> Here's a set of category tags:
>  * This is an open discussion with no time limit
>  * This is a request for some action to be taken (prepare release notes, testing, merge,
>  * This is a concrete proposal with consensus in effect and a 72 hour time limit
> * [VOTE]
>  * This is a formal vote with a 72 hour time limit
> * [NOTICE]
>  * This is a notice of action taken, or action about to be taken (i.e. no discussion
or consensus needed)
>  * This is a project level announcement
> ## Teams
> Here's a set of initial teams to get us going:
> * Software Development no prefix, or [CORE]-prefix
>  * Anything development related.
>  * Writing bugs, fixing bugs.
>  * git, branches, merges.
>  * JIRA / Pull Requests.
>  * [FAUXTON]-prefix/team.
> * Releases [RELEASE]-prefix
>  * Cuts software releases.
>  * Defines release engineering, merge policies.
>  * Builds tools that help the release process.
> * Documentation [DOCS]
>  * Is in charge of all CouchDB documentation.
>  * Expands on what feature devs provide minimally with merges to “release branches”.
>  * Manages
> * Security (
>  * The security team differs from other teams in that only committers have access to
a private mailing list that deals with security incidents.
>  * Handles security issues, privately.
>  * Responsible disclosure, publish CVE after release is made available.
>  * Security releases happen out of band, when they are ready.
> * Packaging [PKG]
>  * Handles CouchDB Packaging.
>  * Works with distributions to build & update CouchDB packages in a timely manner.
>  * Builds tools to make building and packaging easier for everyone.
> * QA [QA]
>  * Tests CouchDB in development and release candidates.
>  * Builds tools to test CouchDB.
>  * Maintains the test suite(s).
>  * Maintains a CI server that allows CouchDB release branches to be in a shippable state
at all times.
> * Issue Triage [ISSUES]
>  * Manages the CouchDB JIRA issue tracker at and GitHub
Pull Requests at
>  * Works with committers and contributors to get patches in to shape to be merged into
a release branch.
>  * Clears out inactive tickets.
>  * Tries to keep the open issue count low.
> * Marketing [MARKETING]
>  * Defines and communicates the project vision.
>  * Manages the website / / / etc.
(take a hint or three from
>  * Prepares materials like slide decks for people who want to present about CouchDB or
some technical detail of it.
>  * Works with all teams to communicate project news.
>  * Collects video / audio / slides from past CouchDB-related presentation.
>  * Prepares and releases case-studies of CouchDB users for the website.
>  * Works with Events to publicise events that have CouchDB-content.
> * Design [DESIGN]
>  * Defines the project design.
>  * Works with Publicity on the information architecture and style of the website(s) &
>  * Works with Publicity on providing good looking resources for developers and advocates.
(slides/videos/images/animations etc).
>  * Works with Packaging and Software Development to create image assets.
>  * Works with Documentation on the information architecture and style of the documentation.
> * Events [EVENTS]
>  * Manages resources for CouchDB events.
>  * Events include user groups, developer meetups, conferences about CouchDB or conferences
where there are talks about CouchDB.
>  * Keeps track of events that should have a CouchDB presence and recruits volunteers
to present at these conferences.
>  * Works with the Publicity team on slide decks and other support material for event
>  * Helps Publicity to collect information about events after they happened into an archive.
> * User Support
>  * <3
>  * Monitors user@couchdb.apache for support questions and replies.
>  * Monitors Google Alerts for CouchDB support questions.
>  * Monitors StackOverflow for CouchDB support questions.
>  * etc.
>  * Works with Documentation to improve docs to minimise support questions.
> * General [GENERAL]
>  * Whatever.
>  * This is private@ for everything that doesn't have to be private.
>  * For project-level discussion/decision making.
>  * Can be for marketing, events, branding approval, community dev, etc, etc.
> * * *
> So far.
> My goal is to prominently link to a final document like this from our website, the manual,
the wiki, anywhere it makes sense.
> Best
> Jan
> -- 

View raw message