(In fact, this thread could easily have used a [GENERAL] tag. Hehe.)
On 22 May 2013 01:37, Adam Kocoloski <[email protected]> wrote: > 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 > > -- > > > > > > -- NS
