couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject [DISCUSS] The Apache CouchDB Project
Date Tue, 21 May 2013 20:26:14 GMT
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 http://issues.apache.org/jira/COUCHDB and code can
be submitted via email to dev@couchdb.apache.org, JIRA or as a GitHub Pull Request at https://github.com/apache/couchdb

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 dev@couchdb.apache.org 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:

* [DISCUSS]
  * This is an open discussion with no time limit
* [REQUEST]
  * This is a request for some action to be taken (prepare release notes, testing, merge,
etc)
* [PROPOSAL]
  * 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)
* [ANNOUNCE]
  * 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 wiki.apache.org/couchdb.

* Security (security@couchdb.apache.org)
  * 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 issues.apache.org/jira/COUCHDB and GitHub Pull
Requests at https://github.com/apache/couchdb.
  * 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 couchdb.apache.org / blogs.apache.org/couchdb / relaxed.tv / etc.
(take a hint or three from http://nathanbarry.com/step-by-step-landing-page-copywriting/).
  * 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) &
wiki.
  * 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 participants.
  * 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
-- 



Mime
View raw message