Just reply here! :) On Wednesday, 22 May 2013, Randall Leeds wrote:
> Awesome! Thanks, Jan! > > How should we go about suggesting edits? > > On Tue, May 21, 2013 at 1:26 PM, Jan Lehnardt <j...@apache.org> 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 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 th -- NS
