couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <>
Subject Re: Help shape the future of CouchDB: your voice needed!
Date Sat, 14 Apr 2012 16:30:48 GMT
I kind of agree, though I think voting is neat. I'd like to think most of these features are
influenced by experiences with users in addition to internal refactoring concerns and so forth.

It might help for everyone to see the list of features (here's a cleaned up version I got
from BobN) [1]. As Benoit suggests, we need to sort/categorize them first before attaching

One thing we might think of is the areas they might be grouped in, along the line of teams
as Jan suggested at the summit. 

I'm happy to maintain this list as we drill down into the specifics, summarize email threads,
and IRC chats. Some of these, .eg. moving metadata out of the docs, could easily require a
lot of detailed discussion as they hit many areas of the code, so we should flesh out the

It was great to meet everyone finally, I think we accomplished a whole lot. Thanks to Cloudant,
Bocoup, and others for hosting, beers, etc.. and a big thanks to Sam Bisbee and Joan Touzet
for detailed notes and general cat herding.



On Apr 14, 2012, at 11:10 AM, Klaus Trainer wrote:

> I know CouchDB's internals to some degree and even contributed a few
> bits to its codebase a while ago (and still follow its development to
> some degree). However, I see myself primarily as a CouchDB user. I've
> been using it successfully not only in my own pet projects, but also
> together with a small team in a consulting project for a client. I do
> have experience when it comes to explaining CouchDB's ideas, concepts,
> and how it can be used in practice to both technical and non-technical
> people.
> My initial reaction to this web page was very positive (hey, great to
> have a collection of great new features that we can vote upon and
> implement!). After voting and having had some sleep on it, I'm pretty
> sure that it's not suitable, at least not in this way, though. The main
> problem that I have with it is that I'm quite convinced that if we try
> to implement the features corresponding to their score on the results
> page (, we will
> either fail executing for some reason, or (the worse case), succeed and
> have given CouchDB a more catchy list of features instead of having it
> made a better piece of software. Please let me explain the issues that
> seem important to me.
> The main problem with that survey is that it does neither ask nor answer
> the questions that are actually important if we want to make CouchDB an
> even better piece of software. I collected three main questions:
> 1. What problem, or rather what type of problems does that feature
> solve?
> 2. What are the implications and tradeoffs for the different types of
> stakeholders that the feature brings with it?
>    - For me as a CouchDB user, how will that feature affect me when I'm
> using CouchDB?
>    - For me as a third-party developer, how will that feature affect my
> work on CouchDB modules/plugins/tools?
>    - For me as a CouchDB core developer, how will that feature affect
> my work on CouchDB?
>    - For me as as CouchDB package maintainer, how will that feature
> affect my work on packaging/maintaining CouchDB?
>    - For me as as Sysadmin / CouchDB operator, how will that feature
> affect me on operating CouchDB?
> 3. How is or how can an existing problem be solved without having the
> feature implemented in CouchDB directly? (That is, are there
> modules/plugins/tools available that help me solve that problem. If not,
> how difficult would it be to create one?)
> Furthermore, I've got one additional question that, although it likely
> helps understanding a feature, however is not as important as the three
> above:
> -> What are the reasons that the feature has not already been
> implemented?
> This question is probably easier to answer when having a list of
> potential answers, for instance:
> * Only very few users have that issue, and most users will likely never
> have to deal with it.
> * Most users are confronted with that issue at some time, but it's so
> trivial to solve it without having the feature in CouchDB anyway.
> * It's hard to implement because (although feasible) it's just so much
> work.
> * It's hard to implement because its highly complex and very uncertain
> if it can be brought into CouchDB anyway.
> * Although easy to implement or already implemented, it hasn't been
> and/or won't be accepted by the CouchDB core developers for some reason.
> On Fri, 2012-04-13 at 20:24 -0400, Joan Touzet wrote:
>> Thanks to everyone who participated in the CouchDB summit in Boston this
>> week! In case you didn't know, the (25 pages!) of meeting minutes are
>> available for review at .
>> Here's where we need YOUR HELP. During the summit, the participants
>> identified 38 key features we think are important for CouchDB's future.
>> Please help us RANK these ideas by visiting our All Our Ideas page:
>> All Our Ideas is a free/open source solution for voting based on
>> pairwise comparison - think Kittenwar - and is super easy to use.
>> Please complete as many comparisons as you can; we'd like all the
>> feedback we can get. We'd be thrilled if each of you did at least 100
>> comparisons.
>> Thanks again for your help in determining the future of Apache CouchDB!

View raw message