Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of mkimber@kana.com designates
 64.95.72.241 as permitted sender)
From: Mike Kimber <mkimber@kana.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>,
	"dev@couchdb.apache.org" <dev@couchdb.apache.org>
Date: Mon, 16 Apr 2012 03:07:46 -0400
Subject: RE: Help shape the future of CouchDB: your voice needed!
Thread-Topic: Help shape the future of CouchDB: your voice needed!
Thread-Index: Ac0aZETXI4VD6JY9SRKYCoYOW5WuugBOuoMw
Message-ID: <A7D50E04F38FD44D9D914F2ABCA592BF2DE339CF05@BE259.mail.lan>
References: <20120414002434.GA22219@atypical.net>
	<1334416226.2951.1.camel@devil>
	<91DAAC41-2AE8-44F0-88A4-FFFDC927E277@dionne-associates.com>
 <CABvT1DGksHPbr2YDiBUksZEUkcHSJBbfBSdGoh4hrisTN7gJWQ@mail.gmail.com>
In-Reply-To: 
 <CABvT1DGksHPbr2YDiBUksZEUkcHSJBbfBSdGoh4hrisTN7gJWQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Good on you for trying something different. I cast 100 votes and then figur=
ed that was enough. If you want my top 5 then they are:

1. Chained Views
2. Richer Map Reduce
3. Simpler Query=20
4. Performance (high update low query/read) i.e. incremental map reduce
5. Documentation

We use CouchDB fro analytic, hence the bias above :-)

Keep up the good work

Thanks=20

Mike=20

-----Original Message-----
From: Robert Newson [mailto:rnewson@apache.org]=20
Sent: 14 April 2012 18:30
To: dev@couchdb.apache.org
Cc: user@couchdb.apache.org
Subject: Re: Help shape the future of CouchDB: your voice needed!

The feedback on the mailing lists, IRC and twitter has been very
helpful, thanks everyone for the responses!

I'm going to take this feedback and provide a condensed list of
features. I will write up each item on our wiki, then we'll reset the
poll so that more folks can vote knowledgeably on the features. I
suspect it'll be a couple of hours, so I'll post here when it's up.

Thanks!
B.

On 14 April 2012 17:30, Bob Dionne <dionne@dionne-associates.com> wrote:
> 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 int=
ernal 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/catego=
rize them first before attaching priorities.
>
> 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, summ=
arize 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 details.
>
> It was great to meet everyone finally, I think we accomplished a whole lo=
t. Thanks to Cloudant, Bocoup, and others for hosting, beers, etc.. and a b=
ig thanks to Sam Bisbee and Joan Touzet for detailed notes and general cat =
herding.
>
> Bob
>
> [1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summ=
it.md
>
>
> On Apr 14, 2012, at 11:10 AM, Klaus Trainer wrote:
>
>> <DISCLAIMER>
>> 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.
>> </DISCLAIMER>
>>
>>
>> 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 (http://www.allourideas.org/couchdb2012/results?more=3Dtrue), we wi=
ll
>> 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?
>> =A0 =A0- For me as a CouchDB user, how will that feature affect me when =
I'm
>> using CouchDB?
>> =A0 =A0- For me as a third-party developer, how will that feature affect=
 my
>> work on CouchDB modules/plugins/tools?
>> =A0 =A0- For me as a CouchDB core developer, how will that feature affec=
t
>> my work on CouchDB?
>> =A0 =A0- For me as as CouchDB package maintainer, how will that feature
>> affect my work on packaging/maintaining CouchDB?
>> =A0 =A0- 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 thi=
s
>>> week! In case you didn't know, the (25 pages!) of meeting minutes are
>>> available for review at http://s.apache.org/ndI .
>>>
>>> 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:
>>>
>>> =A0 http://www.allourideas.org/couchdb2012/
>>>
>>> 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!
>>>
>>
>