Cool! 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. Adam On May 21, 2013, at 4: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 > -- > >
