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:50:02 GMT
The tags were clarified in a recent mailing list post. People were getting
confused about what they all meant, and it turned out we all had slightly
different expectations. So this is an attempt to clarify that so we're all
on the same page.

Funny, I actually think [GENERAL] is going to be one of the more useful
ones. But perhaps that's because I plan to use it a lot. ;) For me,
[GENERAL] is anything project-level that isn't to do with the code.
Community, branding, organisation, etc.


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