couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [DISCUSS] The Apache CouchDB Project
Date Wed, 22 May 2013 12:15:58 GMT

On May 22, 2013, at 11:32 , Dirkjan Ochtman <> wrote:

> On Tue, May 21, 2013 at 10:26 PM, Jan Lehnardt <> wrote:
>> So far.
> There are some things here I like, and some I don't like that much.
> I like the emphasis on do-ocracy, and the encouragement for
> non-committers to just do stuff (and get elected as a committer soon
> thereafter). Or, rather more general, I like all the stuff where you
> describe opportunities and encouragements and welcoming and shit that
> can be done.
> <ranting> (with a little hyperbole, maybe)
> Then, the document goes off and just undoes all of that by boxing
> everything into tags and teams. Those bits make me just want to revert
> to my grumpy rant from March's Goals for 2013 thread. This project has
> way too few active people working to require this much process (most
> of the tags and the teams); it's just process that maybe makes us feel
> good, but doesn't actually seem accomplish anything.
> Yes, having a short list of people who are interested in specific
> areas of the project would be good. But is "[PROPOSAL] Pulling
> INSTALL.* into the docs" really a better subject than just "Pulling
> INSTALL.* into the docs"? Do we need to carefully delineate every
> mailing list thread into something that has a specific timeout rules?
> I'll posit that if we were a do-ocracy, if we do apply EAFP (which I'm
> all for!), we don't need all of that stuff. We push stuff forward when
> we have the chance. When we go a little too far in our enthousiasm, we
> generally have ways of reverting without much effort. And it would
> still be useful for new contributors to know that, if the docs suck in
> some specific area, or if they have an event they want to organize,
> there are a few people they should talk to who generally know what's
> going on in that area. And we might call those teams. But I don't
> think we should get mired too much in delineating Boundaries and
> Processes.
> And that concludes yet another Grumpy Rant,
> Dirkjan

I don’t think this is a grumpy rant, but rather valuable feedback! :)

My original intention with this was to set up something lightweight
that gets out of our way most of the time, but provides just enough
structure to make us a little more productive as the team grows and
we have people specialising on a few sub-areas rather than general

With tags I am trying to solve two things:

1. Make it easier to participate in a particular topic without defining
   any formal sub-group with a chairperson and reports and whatnot.

2. Make it easy to ignore a certain topic. Maybe I am neck deep in
   fixing a particular bug, or writing a feature or writing docs. I
   can just ignore everything that is tagged, say [PKG] and [MARKETING].

This whole thing started from a much larger document and I thought
this was distilled down enough to go out, but now I think we can do a
little better.

The whole swash about what tag/team does what can be its own page, all
we keep for this one is the list of suggested tags.

The use of DISCUSS/PROPOSAL/VOTE is meant to allow people moving faster
and without much blocking on topics that need some discussion. But I’d
like to see the do-ocracy be the default. If you want to do a thing, do
it, you got the commit bit, we trust you to do the right thing. If we
later decide it wasn’t the right thing, we can course correct at any

If you don’t feel confident doing something right away and ask for some
feedback (like I now, e.g.), you can use the DISCUSS/PROPOSAL tags and
if you want to call a formal vote on something, it’s a VOTE.

I think I agree with not over-doing tags, and that no-tag means GENERAL
or SOFTWARE DEVELOPMENT, but generally I am less interested in making
this very precise and much more in giving devs (committers and not) a 
set of tiny tools to get things done here.

I’ll cut things down a little and repost in a bit.

And again, I think this is very good feedback, keep it coming :)


View raw message