couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] The Apache CouchDB Project
Date Wed, 22 May 2013 00:58:14 GMT
(In fact, this thread could easily have used a [GENERAL] tag. Hehe.)


On 22 May 2013 01:37, Adam Kocoloski <kocolosk@apache.org> 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 <jan@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 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
> > --
> >
> >
>
>


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message