Awesome! Thanks, Jan! How should we go about suggesting edits?
On Tue, May 21, 2013 at 1:26 PM, Jan Lehnardt <[email protected]> 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 > http://issues.apache.org/jira/COUCHDB and code can be submitted via email to > [email protected], 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 [email protected] > 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 ([email protected]) > * 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 [email protected] 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 > -- > >
