You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Joan Touzet <jo...@atypical.net> on 2012/04/14 02:24:34 UTC
Help shape the future of CouchDB: your voice needed!
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 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:
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!
--
Joan Touzet | joant@atypical.net | wohali everywhere else
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Apr 14, 2012 at 6:48 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>
> On Saturday, April 14, 2012, 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 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:
>>
>> 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!
>>
>> --
>> Joan Touzet | joant@atypical.net | wohali everywhere else
>
>
> also not saying that thie kind of ranking proposed by this service is odd to
> sy the less,
>
> benoît
To be more constructive, we should rather first put all the lines that
were on the dashboard, describe them and sort them by their
dependancies (some line depends on another). I can start doing that on
the wiki, but I need an access I guess.
Then eventually ask for votes, those i don't see how votes are relaled
to developer interest. Never forget that at the end we are an
opensource project depending on the developer will. Interest from
other is still interesting but we should distinct backend needed
changes from end user features.
- benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Saturday, April 14, 2012, 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 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:
>
> 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!
>
> --
> Joan Touzet | joant@atypical.net <javascript:;> | wohali everywhere else
>
also not saying that thie kind of ranking proposed by this service is odd
to sy the less,
benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
For the record, the vast majority of my responses were "I don't know A
or B or Both". I think that's expected, since there are a number of
internal refactoring items, and end users won't typically have an
opinion.
Eli
On Fri, Apr 13, 2012 at 6:36 PM, Robert Newson <rn...@apache.org> wrote:
> Mark,
>
> The "I can't decide" option allows you to tell us that you "don't
> understand either option" which is valuable input in its own right.
>
> B.
>
> On 14 April 2012 02:20, Mark Hahn <ma...@hahnca.com> wrote:
>> I went through them for a while and gave up because there were many
>> internal ones I didn't understand. Then I looked at results and saw a
>> number of ideas I would really like to vote for.
>>
>> In other words this site's methodology didn't work for me.
>>
>> On Fri, Apr 13, 2012 at 5:24 PM, Joan Touzet <jo...@atypical.net> 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 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:
>>>
>>> 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!
>>>
>>> --
>>> Joan Touzet | joant@atypical.net | wohali everywhere else
>>>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
Mark,
The "I can't decide" option allows you to tell us that you "don't
understand either option" which is valuable input in its own right.
B.
On 14 April 2012 02:20, Mark Hahn <ma...@hahnca.com> wrote:
> I went through them for a while and gave up because there were many
> internal ones I didn't understand. Then I looked at results and saw a
> number of ideas I would really like to vote for.
>
> In other words this site's methodology didn't work for me.
>
> On Fri, Apr 13, 2012 at 5:24 PM, Joan Touzet <jo...@atypical.net> 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 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:
>>
>> 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!
>>
>> --
>> Joan Touzet | joant@atypical.net | wohali everywhere else
>>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Mark Hahn <ma...@hahnca.com>.
I went through them for a while and gave up because there were many
internal ones I didn't understand. Then I looked at results and saw a
number of ideas I would really like to vote for.
In other words this site's methodology didn't work for me.
On Fri, Apr 13, 2012 at 5:24 PM, Joan Touzet <jo...@atypical.net> 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 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:
>
> 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!
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
On Apr 19, 2012, at 8:11 AM, Miles Fidelman wrote:
> Bob Dionne wrote:
>> Mike,
>>
>> I'd be interested in your thoughts on this. Damien presented the UnQL stuff to us, some time ago before he left the CouchDB project, and I thought then it was overly ambitious.
>>
>> I agree that SQL is awesome and hard to get away from after thinking in terms of relations for years. I'd love to see an alternative to SQL that was a better fit for document stores, that takes into account that document are sorts of like objects with attributes. There was considerable work done in this area years ago by folks working in functional dbs.
>>
> Umm.... CQL (Contextual Query Language, formerly known as Common Query Language). Developed by the library community for querying metadata.
>
> SRU (Search/Retrieve via URL) embeds CQL in a RESTful API. Sort of OpenSearch on steroids. Some mature implementations floating around.
>
> Working example of a search string:
> http://alcme.oclc.org/srw/search/SiteSearchDocumentation?query=dc.title= pears&version=1.1&maximumRecords=10 <http://alcme.oclc.org/srw/search/SiteSearchDocumentation?query=dc.title=%20pears&version=1.1&maximumRecords=10>
>
> Now an SRU interface to CouchDB would be interesting.
>
> (Amazing how people always want to re-invent things rather than do a little research.)
It is amazing, there's also the original UnQL by Peter Buneman and his students at Penn (Hasan Ait-KAci, et. al.), FQL, etc.. What I was referring to in wondering about alternatives was a revisiting of the foundations, research in the capital R sense, rather than just googling about for artifacts, though clearly literature surveys are also important.
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is. .... Yogi Berra
>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Miles Fidelman <mf...@meetinghouse.net>.
Bob Dionne wrote:
> Mike,
>
> I'd be interested in your thoughts on this. Damien presented the UnQL stuff to us, some time ago before he left the CouchDB project, and I thought then it was overly ambitious.
>
> I agree that SQL is awesome and hard to get away from after thinking in terms of relations for years. I'd love to see an alternative to SQL that was a better fit for document stores, that takes into account that document are sorts of like objects with attributes. There was considerable work done in this area years ago by folks working in functional dbs.
>
Umm.... CQL (Contextual Query Language, formerly known as Common Query
Language). Developed by the library community for querying metadata.
SRU (Search/Retrieve via URL) embeds CQL in a RESTful API. Sort of
OpenSearch on steroids. Some mature implementations floating around.
Working example of a search string:
http://alcme.oclc.org/srw/search/SiteSearchDocumentation?query=dc.title=
pears&version=1.1&maximumRecords=10
<http://alcme.oclc.org/srw/search/SiteSearchDocumentation?query=dc.title=%20pears&version=1.1&maximumRecords=10>
Now an SRU interface to CouchDB would be interesting.
(Amazing how people always want to re-invent things rather than do a
little research.)
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
Mike,
I'd be interested in your thoughts on this. Damien presented the UnQL stuff to us, some time ago before he left the CouchDB project, and I thought then it was overly ambitious.
I agree that SQL is awesome and hard to get away from after thinking in terms of relations for years. I'd love to see an alternative to SQL that was a better fit for document stores, that takes into account that document are sorts of like objects with attributes. There was considerable work done in this area years ago by folks working in functional dbs.
Let us know what you think after you've played around with MR.
Bob
On Apr 19, 2012, at 6:51 AM, Mike Kimber wrote:
> Robert,
>
> I might just do that :-). To be honest I've just inherited a our couchdb project and have little experience with it at the moment (just been trying to get it upgraded etc to-date), So once I've actually written a few MR I'll be in e better place to provide some sensible comment.
>
> However one generic NoSQL observation i.e. no just Couchdb is that despite NoSQL being well "No SQL", Google with Dremel ( http://research.google.com/pubs/pub36632.html ) and Facebook with Hive have actually put a SQL like interface on top of their Big data platforms, so like it or not that SQL syntax is proving hard to kick.
>
> Mike
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 18 April 2012 14:11
> To: user@couchdb.apache.org
> Subject: Re: Help shape the future of CouchDB: your voice needed!
>
> Not as yet, it's more a recognition that we should work on it than a
> full-fledged solution. Why not start a thread with some ideas?
>
> B.
>
> On 18 April 2012 14:06, Mike Kimber <mk...@kana.com> wrote:
>> Ok thanks. Is there any details on what "Simpler Querying" on the roadmap list might mean?
>>
>> Mike
>>
>> -----Original Message-----
>> From: Robert Newson [mailto:rnewson@apache.org]
>> Sent: 18 April 2012 14:02
>> To: user@couchdb.apache.org
>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>
>> I don't see UNQL appearing on CouchDB's roadmap.
>>
>> B.
>>
>> On 18 April 2012 13:44, Mike Kimber <mk...@kana.com> wrote:
>>> One thing I did not see on the roadmap was UNQL:
>>>
>>> Is this covered by Simpler Querying?
>>> Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>>
>>> -----Original Message-----
>>> From: Alon Keren [mailto:alon.keren@gmail.com]
>>> Sent: 16 April 2012 21:28
>>> To: user@couchdb.apache.org
>>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>>
>>> Thank you guys for making this poll, and for publishing the minutes and
>>> audio.
>>>
>>> I've voted, and it would be really nice to have this (or other) list as a
>>> wish-list that couchdb users could continuously update.
>>>
>>> Alon
>>>
>>> On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
>>>
>>>> Good on you for trying something different. I cast 100 votes and then
>>>> figured that was enough. If you want my top 5 then they are:
>>>>
>>>> 1. Chained Views
>>>> 2. Richer Map Reduce
>>>> 3. Simpler Query
>>>> 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
>>>>
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>> From: Robert Newson [mailto:rnewson@apache.org]
>>>> 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 <di...@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
>>>> 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 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,
>>>> 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 details.
>>>>>
>>>>> 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.
>>>>>
>>>>> Bob
>>>>>
>>>>> [1]
>>>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>>>>>>
>>>>>>> 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!
>>>>>>>
>>>>>>
>>>>>
>>>>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
I can speak only for myself but I've been SQL syntax free for years. I
even got my sense of smell back.
B.
On 19 April 2012 11:51, Mike Kimber <mk...@kana.com> wrote:
> Robert,
>
> I might just do that :-). To be honest I've just inherited a our couchdb project and have little experience with it at the moment (just been trying to get it upgraded etc to-date), So once I've actually written a few MR I'll be in e better place to provide some sensible comment.
>
> However one generic NoSQL observation i.e. no just Couchdb is that despite NoSQL being well "No SQL", Google with Dremel ( http://research.google.com/pubs/pub36632.html ) and Facebook with Hive have actually put a SQL like interface on top of their Big data platforms, so like it or not that SQL syntax is proving hard to kick.
>
> Mike
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 18 April 2012 14:11
> To: user@couchdb.apache.org
> Subject: Re: Help shape the future of CouchDB: your voice needed!
>
> Not as yet, it's more a recognition that we should work on it than a
> full-fledged solution. Why not start a thread with some ideas?
>
> B.
>
> On 18 April 2012 14:06, Mike Kimber <mk...@kana.com> wrote:
>> Ok thanks. Is there any details on what "Simpler Querying" on the roadmap list might mean?
>>
>> Mike
>>
>> -----Original Message-----
>> From: Robert Newson [mailto:rnewson@apache.org]
>> Sent: 18 April 2012 14:02
>> To: user@couchdb.apache.org
>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>
>> I don't see UNQL appearing on CouchDB's roadmap.
>>
>> B.
>>
>> On 18 April 2012 13:44, Mike Kimber <mk...@kana.com> wrote:
>>> One thing I did not see on the roadmap was UNQL:
>>>
>>> Is this covered by Simpler Querying?
>>> Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
>>>
>>> Thanks
>>>
>>> Mike
>>>
>>>
>>> -----Original Message-----
>>> From: Alon Keren [mailto:alon.keren@gmail.com]
>>> Sent: 16 April 2012 21:28
>>> To: user@couchdb.apache.org
>>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>>
>>> Thank you guys for making this poll, and for publishing the minutes and
>>> audio.
>>>
>>> I've voted, and it would be really nice to have this (or other) list as a
>>> wish-list that couchdb users could continuously update.
>>>
>>> Alon
>>>
>>> On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
>>>
>>>> Good on you for trying something different. I cast 100 votes and then
>>>> figured that was enough. If you want my top 5 then they are:
>>>>
>>>> 1. Chained Views
>>>> 2. Richer Map Reduce
>>>> 3. Simpler Query
>>>> 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
>>>>
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>> From: Robert Newson [mailto:rnewson@apache.org]
>>>> 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 <di...@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
>>>> 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 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,
>>>> 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 details.
>>>> >
>>>> > 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.
>>>> >
>>>> > Bob
>>>> >
>>>> > [1]
>>>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>>> >>>
>>>> >>> 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!
>>>> >>>
>>>> >>
>>>> >
>>>>
RE: Help shape the future of CouchDB: your voice needed!
Posted by Mike Kimber <mk...@kana.com>.
Robert,
I might just do that :-). To be honest I've just inherited a our couchdb project and have little experience with it at the moment (just been trying to get it upgraded etc to-date), So once I've actually written a few MR I'll be in e better place to provide some sensible comment.
However one generic NoSQL observation i.e. no just Couchdb is that despite NoSQL being well "No SQL", Google with Dremel ( http://research.google.com/pubs/pub36632.html ) and Facebook with Hive have actually put a SQL like interface on top of their Big data platforms, so like it or not that SQL syntax is proving hard to kick.
Mike
-----Original Message-----
From: Robert Newson [mailto:rnewson@apache.org]
Sent: 18 April 2012 14:11
To: user@couchdb.apache.org
Subject: Re: Help shape the future of CouchDB: your voice needed!
Not as yet, it's more a recognition that we should work on it than a
full-fledged solution. Why not start a thread with some ideas?
B.
On 18 April 2012 14:06, Mike Kimber <mk...@kana.com> wrote:
> Ok thanks. Is there any details on what "Simpler Querying" on the roadmap list might mean?
>
> Mike
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 18 April 2012 14:02
> To: user@couchdb.apache.org
> Subject: Re: Help shape the future of CouchDB: your voice needed!
>
> I don't see UNQL appearing on CouchDB's roadmap.
>
> B.
>
> On 18 April 2012 13:44, Mike Kimber <mk...@kana.com> wrote:
>> One thing I did not see on the roadmap was UNQL:
>>
>> Is this covered by Simpler Querying?
>> Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
>>
>> Thanks
>>
>> Mike
>>
>>
>> -----Original Message-----
>> From: Alon Keren [mailto:alon.keren@gmail.com]
>> Sent: 16 April 2012 21:28
>> To: user@couchdb.apache.org
>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>
>> Thank you guys for making this poll, and for publishing the minutes and
>> audio.
>>
>> I've voted, and it would be really nice to have this (or other) list as a
>> wish-list that couchdb users could continuously update.
>>
>> Alon
>>
>> On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
>>
>>> Good on you for trying something different. I cast 100 votes and then
>>> figured that was enough. If you want my top 5 then they are:
>>>
>>> 1. Chained Views
>>> 2. Richer Map Reduce
>>> 3. Simpler Query
>>> 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
>>>
>>> Mike
>>>
>>> -----Original Message-----
>>> From: Robert Newson [mailto:rnewson@apache.org]
>>> 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 <di...@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
>>> 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 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,
>>> 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 details.
>>> >
>>> > 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.
>>> >
>>> > Bob
>>> >
>>> > [1]
>>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>> >>>
>>> >>> 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!
>>> >>>
>>> >>
>>> >
>>>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
Not as yet, it's more a recognition that we should work on it than a
full-fledged solution. Why not start a thread with some ideas?
B.
On 18 April 2012 14:06, Mike Kimber <mk...@kana.com> wrote:
> Ok thanks. Is there any details on what "Simpler Querying" on the roadmap list might mean?
>
> Mike
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 18 April 2012 14:02
> To: user@couchdb.apache.org
> Subject: Re: Help shape the future of CouchDB: your voice needed!
>
> I don't see UNQL appearing on CouchDB's roadmap.
>
> B.
>
> On 18 April 2012 13:44, Mike Kimber <mk...@kana.com> wrote:
>> One thing I did not see on the roadmap was UNQL:
>>
>> Is this covered by Simpler Querying?
>> Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
>>
>> Thanks
>>
>> Mike
>>
>>
>> -----Original Message-----
>> From: Alon Keren [mailto:alon.keren@gmail.com]
>> Sent: 16 April 2012 21:28
>> To: user@couchdb.apache.org
>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>
>> Thank you guys for making this poll, and for publishing the minutes and
>> audio.
>>
>> I've voted, and it would be really nice to have this (or other) list as a
>> wish-list that couchdb users could continuously update.
>>
>> Alon
>>
>> On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
>>
>>> Good on you for trying something different. I cast 100 votes and then
>>> figured that was enough. If you want my top 5 then they are:
>>>
>>> 1. Chained Views
>>> 2. Richer Map Reduce
>>> 3. Simpler Query
>>> 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
>>>
>>> Mike
>>>
>>> -----Original Message-----
>>> From: Robert Newson [mailto:rnewson@apache.org]
>>> 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 <di...@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
>>> 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 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,
>>> 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 details.
>>> >
>>> > 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.
>>> >
>>> > Bob
>>> >
>>> > [1]
>>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>> >>>
>>> >>> 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!
>>> >>>
>>> >>
>>> >
>>>
RE: Help shape the future of CouchDB: your voice needed!
Posted by Mike Kimber <mk...@kana.com>.
Ok thanks. Is there any details on what "Simpler Querying" on the roadmap list might mean?
Mike
-----Original Message-----
From: Robert Newson [mailto:rnewson@apache.org]
Sent: 18 April 2012 14:02
To: user@couchdb.apache.org
Subject: Re: Help shape the future of CouchDB: your voice needed!
I don't see UNQL appearing on CouchDB's roadmap.
B.
On 18 April 2012 13:44, Mike Kimber <mk...@kana.com> wrote:
> One thing I did not see on the roadmap was UNQL:
>
> Is this covered by Simpler Querying?
> Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
>
> Thanks
>
> Mike
>
>
> -----Original Message-----
> From: Alon Keren [mailto:alon.keren@gmail.com]
> Sent: 16 April 2012 21:28
> To: user@couchdb.apache.org
> Subject: Re: Help shape the future of CouchDB: your voice needed!
>
> Thank you guys for making this poll, and for publishing the minutes and
> audio.
>
> I've voted, and it would be really nice to have this (or other) list as a
> wish-list that couchdb users could continuously update.
>
> Alon
>
> On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
>
>> Good on you for trying something different. I cast 100 votes and then
>> figured that was enough. If you want my top 5 then they are:
>>
>> 1. Chained Views
>> 2. Richer Map Reduce
>> 3. Simpler Query
>> 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
>>
>> Mike
>>
>> -----Original Message-----
>> From: Robert Newson [mailto:rnewson@apache.org]
>> 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 <di...@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
>> 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 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,
>> 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 details.
>> >
>> > 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.
>> >
>> > Bob
>> >
>> > [1]
>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>> >>>
>> >>> 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!
>> >>>
>> >>
>> >
>>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
I don't see UNQL appearing on CouchDB's roadmap.
B.
On 18 April 2012 13:44, Mike Kimber <mk...@kana.com> wrote:
> One thing I did not see on the roadmap was UNQL:
>
> Is this covered by Simpler Querying?
> Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
>
> Thanks
>
> Mike
>
>
> -----Original Message-----
> From: Alon Keren [mailto:alon.keren@gmail.com]
> Sent: 16 April 2012 21:28
> To: user@couchdb.apache.org
> Subject: Re: Help shape the future of CouchDB: your voice needed!
>
> Thank you guys for making this poll, and for publishing the minutes and
> audio.
>
> I've voted, and it would be really nice to have this (or other) list as a
> wish-list that couchdb users could continuously update.
>
> Alon
>
> On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
>
>> Good on you for trying something different. I cast 100 votes and then
>> figured that was enough. If you want my top 5 then they are:
>>
>> 1. Chained Views
>> 2. Richer Map Reduce
>> 3. Simpler Query
>> 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
>>
>> Mike
>>
>> -----Original Message-----
>> From: Robert Newson [mailto:rnewson@apache.org]
>> 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 <di...@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
>> 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 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,
>> 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 details.
>> >
>> > 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.
>> >
>> > Bob
>> >
>> > [1]
>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>> >>>
>> >>> 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!
>> >>>
>> >>
>> >
>>
RE: Help shape the future of CouchDB: your voice needed!
Posted by Mike Kimber <mk...@kana.com>.
One thing I did not see on the roadmap was UNQL:
Is this covered by Simpler Querying?
Is UNQL still something that interests Couchdb and if so what sort time frame are we talking?
Thanks
Mike
-----Original Message-----
From: Alon Keren [mailto:alon.keren@gmail.com]
Sent: 16 April 2012 21:28
To: user@couchdb.apache.org
Subject: Re: Help shape the future of CouchDB: your voice needed!
Thank you guys for making this poll, and for publishing the minutes and
audio.
I've voted, and it would be really nice to have this (or other) list as a
wish-list that couchdb users could continuously update.
Alon
On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
> Good on you for trying something different. I cast 100 votes and then
> figured that was enough. If you want my top 5 then they are:
>
> 1. Chained Views
> 2. Richer Map Reduce
> 3. Simpler Query
> 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
>
> Mike
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> 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 <di...@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
> 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 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,
> 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 details.
> >
> > 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.
> >
> > Bob
> >
> > [1]
> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
> >>>
> >>> 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!
> >>>
> >>
> >
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Alon Keren <al...@gmail.com>.
Thank you guys for making this poll, and for publishing the minutes and
audio.
I've voted, and it would be really nice to have this (or other) list as a
wish-list that couchdb users could continuously update.
Alon
On 16 April 2012 10:07, Mike Kimber <mk...@kana.com> wrote:
> Good on you for trying something different. I cast 100 votes and then
> figured that was enough. If you want my top 5 then they are:
>
> 1. Chained Views
> 2. Richer Map Reduce
> 3. Simpler Query
> 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
>
> Mike
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> 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 <di...@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
> 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 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,
> 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 details.
> >
> > 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.
> >
> > Bob
> >
> > [1]
> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
> >>>
> >>> 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!
> >>>
> >>
> >
>
RE: Help shape the future of CouchDB: your voice needed!
Posted by Mike Kimber <mk...@kana.com>.
Good on you for trying something different. I cast 100 votes and then figured that was enough. If you want my top 5 then they are:
1. Chained Views
2. Richer Map Reduce
3. Simpler Query
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
Mike
-----Original Message-----
From: Robert Newson [mailto:rnewson@apache.org]
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 <di...@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 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 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, 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 details.
>
> 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.
>
> Bob
>
> [1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>>
>>> 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!
>>>
>>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
This is great, a little more descriptive putting them into two categories. I'm not sure why we'd exclude the programmer items from the voting
On Apr 15, 2012, at 6:02 AM, Robert Newson wrote:
> He's what I have so far: https://gist.github.com/2387973
>
> I think it's pretty close. Only the User-Facing section should be in
> the next vote.
>
> B.
>
> On 15 April 2012 10:51, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Sat, Apr 14, 2012 at 7:30 PM, Robert Newson <rn...@apache.org> wrote:
>>> 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.
>>>
>> Sound good. Thanks for that!
>>
>> - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Sun, Apr 15, 2012 at 12:02, Robert Newson <rn...@apache.org> wrote:
> He's what I have so far: https://gist.github.com/2387973
Looks nice. I think it might make sense to fold WebSockets and
EventSource into a single item, i.e. AFAICT the main point is to allow
non-polling forms of consuming _changes from
JavaScript-in-the-browser.
Cheers,
Dirkjan
Re: Help shape the future of CouchDB: your voice needed!
Posted by Klaus Trainer <kl...@posteo.de>.
That's great! Even just a short sentence makes it way easier to get an
idea about the particular feature.
> I think it's pretty close. Only the User-Facing section should be in
> the next vote.
For some features it might me not so clear if they really belong to the
"Developer Facing Features" section. If unsure, I'd make sure to include
a feature in the vote, while ensuring to provide an explanation that the
average CouchDB user can understand.
For example, the points five ("Move attachments out of database files")
and six ("Plugin/addon/module interface") both have definitively a high
priority for me as CouchDB user, as I'd really like to see a larger
ecosystem of third-party extensions/plugins/addons/modules/tools (yay!).
One concrete scenario for instance:
As soon as attachments don't have to be written to the database file
anymore and there's something like an attachment writer plugin module
interface, it'll be a no-brainer to use a cloud storage provider for
attachments. As a result, for me as a CouchDB user, chances will be high
that somebody has already written an accordant plugin when I have that
particular use case (like e.g. putting attachments on Amazon S3).
On Sun, 2012-04-15 at 11:02 +0100, Robert Newson wrote:
> He's what I have so far: https://gist.github.com/2387973
>
> I think it's pretty close. Only the User-Facing section should be in
> the next vote.
>
> B.
>
> On 15 April 2012 10:51, Benoit Chesneau <bc...@gmail.com> wrote:
> > On Sat, Apr 14, 2012 at 7:30 PM, Robert Newson <rn...@apache.org> wrote:
> >> 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.
> >>
> > Sound good. Thanks for that!
> >
> > - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <ro...@gmail.com>.
Consider _mvcc as a suggestion to help educate. Other proposals are welcome.
Sent from my iPhone
On 15 Apr 2012, at 13:16, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sun, Apr 15, 2012 at 2:10 PM, Robert Newson <rn...@apache.org> wrote:
>> A bit busy right now but _history seems the exact opposite of the _rev
>> -> _mvcc name change. We want to clarify that CouchDB does *not*
>> provide history.
>>
> imo changing the name doesn't really fix the problem. We keep saying
> it's mvc, the doc says it but still people want to try it because it's
> similar to what they want. I bet that changing the name to _mvcc won't
> change anything (also I'm thinking to the nightmare of migration,
> havig old nodes talking with new...).
>
> Imo we can have a more positive answer to the users. They want to have
> a revision history they can use. They why not building one. If we
> present one that they can use then they won't use _rev for that.
>
> - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Apr 15, 2012 at 2:10 PM, Robert Newson <rn...@apache.org> wrote:
> A bit busy right now but _history seems the exact opposite of the _rev
> -> _mvcc name change. We want to clarify that CouchDB does *not*
> provide history.
>
imo changing the name doesn't really fix the problem. We keep saying
it's mvc, the doc says it but still people want to try it because it's
similar to what they want. I bet that changing the name to _mvcc won't
change anything (also I'm thinking to the nightmare of migration,
havig old nodes talking with new...).
Imo we can have a more positive answer to the users. They want to have
a revision history they can use. They why not building one. If we
present one that they can use then they won't use _rev for that.
- benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
A bit busy right now but _history seems the exact opposite of the _rev
-> _mvcc name change. We want to clarify that CouchDB does *not*
provide history.
B.
On 15 April 2012 12:56, Robert Newson <rn...@apache.org> wrote:
> Including comments from the gist;
>
> from mcoolin;
>
> I'd add a definitions section for the following:
> CORS - Cross-origin resource sharing (CORS) is a web browser
> technology specification, which defines ways for a web server to allow
> its resources to be accessed by a web page from a different domain.
> http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
>
> EventSource - Server-sent events is a technology for providing push
> notifications from a server to a browser client in the form of DOM
> events. The Server-Sent Events EventSource API is now being
> standardized as part of HTML5[1] by the W3C.
> http://en.wikipedia.org/wiki/Server-sent_events
>
> SPDY - SPDY (pronounced speedy)[1] is an experimental networking
> protocol developed primarily at Google for transporting web
> content.[1] Although not currently a standard protocol, the group
> developing SPDY has stated publicly that it is working toward
> standardization (available now as an Internet Draft[2]), and has
> reference implementations available in both Google Chrome [3] and
> Mozilla Firefox.[4] SPDY is similar to HTTP, with particular goals to
> reduce web page load latency and improve web security. SPDY achieves
> reduced latency through compression, multiplexing, and
> prioritization.[1] The name is not an acronym, but is a shortened
> version of the word "speedy".[5] SPDY is a trademark of Google.[6]
> http://en.wikipedia.org/wiki/SPDY
>
> I would include the two lists in any upcoming vote, perhaps as separate votes.
>
> A few other comments:
> On Number 4 in the first list: Seems to be only a partial description,
> remove data from record and do what with it? How would it be accessed
> and used. especially _id, likely to have a major impact on any project
> using couchdb.
>
> On number 3: Hard dependencies on SpiderMonkey, Should this not be
> discussed more? Performance being a big issue, V8 may be a better
> choice or a set of native erlang routines or some other derivative.
>
> and my reply;
>
> I deliberately left out definitions for those on the basis that if you
> don't know what they are, you have no business asserting its a high
> priority for our project.
>
> For item 4, the description does state that a question remains on
> where they go and suggests custom HTTP headers, so I don't follow your
> point. _id in particular would still be in the URL.
>
> For the spidermonkey issue, it is not at all clear that switching to
> V8 will improve performance (it's largely a myth that V8 is faster
> than spidermonkey anyway). The main feature for improving performance
> is identified as "View server protocol enhancements/refactoring".
>
> On 15 April 2012 12:25, Bob Dionne <di...@dionne-associates.com> wrote:
>> Benoit,
>>
>> Thanks for mentioning the "links" item, that should definitely be in the list. I'd be curious to know what kind if usage the Basho folks have seen with that one.
>>
>> I think it's a good feature but I also think it kind of runs against the grain architecturally in couchdb. Documents now are completely independent of one another which is simple. This forces use cases that need "links" to do so in the application layer. There are many reasons I think of that folks would want this, building trees, graphs, SQL-like queries, navigation, etc. so I think it's a nice feature to add, *but* I would do so in a way that doesn't change the independence of documents, .ie. make it orthogonal, a plugin to core.
>>
>> Bob
>>
>> On Apr 15, 2012, at 6:17 AM, Benoit Chesneau wrote:
>>
>>> On Sun, Apr 15, 2012 at 12:02 PM, Robert Newson <rn...@apache.org> wrote:
>>>> He's what I have so far: https://gist.github.com/2387973
>>>>
>>>> I think it's pretty close. Only the User-Facing section should be in
>>>> the next vote.
>>>>
>>>> B.
>>>>
>>> Most is OK for me. A couple of remarks on user facing though:
>>>
>>> 1.3 : _rev renaming should be placed in another part, and maybe a
>>> developper facing thing . Also other way to embrace it is proposing an
>>> _history member.
>>>
>>> 3. we shouldn't talk about a specific tech. As far as I rememebr we
>>> only talk on a distributed PKI wich openid isn't. OpenID is fine but
>>> maybe we can put the choice of supported implementations for a next
>>> vote?
>>>
>>> 4. maybe can be summarized as "metadata won't be exposed in the Json
>>> Document" ? Or at least the raw document won't be edited by couch.
>>> Some on irc for example was proposing for example to have {"_id": ...,
>>> "_raw": ...}
>>>
>>> links/nested doc feature is missing .
>>>
>>>
>>> I will do another round on dev facing features later.
>>>
>>> - benoît
>>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
Including comments from the gist;
from mcoolin;
I'd add a definitions section for the following:
CORS - Cross-origin resource sharing (CORS) is a web browser
technology specification, which defines ways for a web server to allow
its resources to be accessed by a web page from a different domain.
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
EventSource - Server-sent events is a technology for providing push
notifications from a server to a browser client in the form of DOM
events. The Server-Sent Events EventSource API is now being
standardized as part of HTML5[1] by the W3C.
http://en.wikipedia.org/wiki/Server-sent_events
SPDY - SPDY (pronounced speedy)[1] is an experimental networking
protocol developed primarily at Google for transporting web
content.[1] Although not currently a standard protocol, the group
developing SPDY has stated publicly that it is working toward
standardization (available now as an Internet Draft[2]), and has
reference implementations available in both Google Chrome [3] and
Mozilla Firefox.[4] SPDY is similar to HTTP, with particular goals to
reduce web page load latency and improve web security. SPDY achieves
reduced latency through compression, multiplexing, and
prioritization.[1] The name is not an acronym, but is a shortened
version of the word "speedy".[5] SPDY is a trademark of Google.[6]
http://en.wikipedia.org/wiki/SPDY
I would include the two lists in any upcoming vote, perhaps as separate votes.
A few other comments:
On Number 4 in the first list: Seems to be only a partial description,
remove data from record and do what with it? How would it be accessed
and used. especially _id, likely to have a major impact on any project
using couchdb.
On number 3: Hard dependencies on SpiderMonkey, Should this not be
discussed more? Performance being a big issue, V8 may be a better
choice or a set of native erlang routines or some other derivative.
and my reply;
I deliberately left out definitions for those on the basis that if you
don't know what they are, you have no business asserting its a high
priority for our project.
For item 4, the description does state that a question remains on
where they go and suggests custom HTTP headers, so I don't follow your
point. _id in particular would still be in the URL.
For the spidermonkey issue, it is not at all clear that switching to
V8 will improve performance (it's largely a myth that V8 is faster
than spidermonkey anyway). The main feature for improving performance
is identified as "View server protocol enhancements/refactoring".
On 15 April 2012 12:25, Bob Dionne <di...@dionne-associates.com> wrote:
> Benoit,
>
> Thanks for mentioning the "links" item, that should definitely be in the list. I'd be curious to know what kind if usage the Basho folks have seen with that one.
>
> I think it's a good feature but I also think it kind of runs against the grain architecturally in couchdb. Documents now are completely independent of one another which is simple. This forces use cases that need "links" to do so in the application layer. There are many reasons I think of that folks would want this, building trees, graphs, SQL-like queries, navigation, etc. so I think it's a nice feature to add, *but* I would do so in a way that doesn't change the independence of documents, .ie. make it orthogonal, a plugin to core.
>
> Bob
>
> On Apr 15, 2012, at 6:17 AM, Benoit Chesneau wrote:
>
>> On Sun, Apr 15, 2012 at 12:02 PM, Robert Newson <rn...@apache.org> wrote:
>>> He's what I have so far: https://gist.github.com/2387973
>>>
>>> I think it's pretty close. Only the User-Facing section should be in
>>> the next vote.
>>>
>>> B.
>>>
>> Most is OK for me. A couple of remarks on user facing though:
>>
>> 1.3 : _rev renaming should be placed in another part, and maybe a
>> developper facing thing . Also other way to embrace it is proposing an
>> _history member.
>>
>> 3. we shouldn't talk about a specific tech. As far as I rememebr we
>> only talk on a distributed PKI wich openid isn't. OpenID is fine but
>> maybe we can put the choice of supported implementations for a next
>> vote?
>>
>> 4. maybe can be summarized as "metadata won't be exposed in the Json
>> Document" ? Or at least the raw document won't be edited by couch.
>> Some on irc for example was proposing for example to have {"_id": ...,
>> "_raw": ...}
>>
>> links/nested doc feature is missing .
>>
>>
>> I will do another round on dev facing features later.
>>
>> - benoît
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Apr 15, 2012 at 1:25 PM, Bob Dionne
<di...@dionne-associates.com> wrote:
> Benoit,
>
> Thanks for mentioning the "links" item, that should definitely be in the list. I'd be curious to know what kind if usage the Basho folks have seen with that one.
>
> I think it's a good feature but I also think it kind of runs against the grain architecturally in couchdb. Documents now are completely independent of one another which is simple. This forces use cases that need "links" to do so in the application layer. There are many reasons I think of that folks would want this, building trees, graphs, SQL-like queries, navigation, etc. so I think it's a nice feature to add, *but* I would do so in a way that doesn't change the independence of documents, .ie. make it orthogonal, a plugin to core.
>
> Bob
>
Agree. As an implementation detail I wish we could follow a
specification to do that. Maybe HAL fits our needs instead HTTP Link
headers:
- http://stateless.co/hal_specification.html
- http://blog.stateless.co/post/13296666138/json-linking-with-hal
- benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
Benoit,
Thanks for mentioning the "links" item, that should definitely be in the list. I'd be curious to know what kind if usage the Basho folks have seen with that one.
I think it's a good feature but I also think it kind of runs against the grain architecturally in couchdb. Documents now are completely independent of one another which is simple. This forces use cases that need "links" to do so in the application layer. There are many reasons I think of that folks would want this, building trees, graphs, SQL-like queries, navigation, etc. so I think it's a nice feature to add, *but* I would do so in a way that doesn't change the independence of documents, .ie. make it orthogonal, a plugin to core.
Bob
On Apr 15, 2012, at 6:17 AM, Benoit Chesneau wrote:
> On Sun, Apr 15, 2012 at 12:02 PM, Robert Newson <rn...@apache.org> wrote:
>> He's what I have so far: https://gist.github.com/2387973
>>
>> I think it's pretty close. Only the User-Facing section should be in
>> the next vote.
>>
>> B.
>>
> Most is OK for me. A couple of remarks on user facing though:
>
> 1.3 : _rev renaming should be placed in another part, and maybe a
> developper facing thing . Also other way to embrace it is proposing an
> _history member.
>
> 3. we shouldn't talk about a specific tech. As far as I rememebr we
> only talk on a distributed PKI wich openid isn't. OpenID is fine but
> maybe we can put the choice of supported implementations for a next
> vote?
>
> 4. maybe can be summarized as "metadata won't be exposed in the Json
> Document" ? Or at least the raw document won't be edited by couch.
> Some on irc for example was proposing for example to have {"_id": ...,
> "_raw": ...}
>
> links/nested doc feature is missing .
>
>
> I will do another round on dev facing features later.
>
> - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Apr 15, 2012 at 12:02 PM, Robert Newson <rn...@apache.org> wrote:
> He's what I have so far: https://gist.github.com/2387973
>
> I think it's pretty close. Only the User-Facing section should be in
> the next vote.
>
> B.
>
Most is OK for me. A couple of remarks on user facing though:
1.3 : _rev renaming should be placed in another part, and maybe a
developper facing thing . Also other way to embrace it is proposing an
_history member.
3. we shouldn't talk about a specific tech. As far as I rememebr we
only talk on a distributed PKI wich openid isn't. OpenID is fine but
maybe we can put the choice of supported implementations for a next
vote?
4. maybe can be summarized as "metadata won't be exposed in the Json
Document" ? Or at least the raw document won't be edited by couch.
Some on irc for example was proposing for example to have {"_id": ...,
"_raw": ...}
links/nested doc feature is missing .
I will do another round on dev facing features later.
- benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
He's what I have so far: https://gist.github.com/2387973
I think it's pretty close. Only the User-Facing section should be in
the next vote.
B.
On 15 April 2012 10:51, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sat, Apr 14, 2012 at 7:30 PM, Robert Newson <rn...@apache.org> wrote:
>> 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.
>>
> Sound good. Thanks for that!
>
> - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Apr 14, 2012 at 7:30 PM, Robert Newson <rn...@apache.org> wrote:
> 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.
>
Sound good. Thanks for that!
- benoît
RE: Help shape the future of CouchDB: your voice needed!
Posted by Mike Kimber <mk...@kana.com>.
Good on you for trying something different. I cast 100 votes and then figured that was enough. If you want my top 5 then they are:
1. Chained Views
2. Richer Map Reduce
3. Simpler Query
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
Mike
-----Original Message-----
From: Robert Newson [mailto:rnewson@apache.org]
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 <di...@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 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 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, 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 details.
>
> 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.
>
> Bob
>
> [1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>>
>>> 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!
>>>
>>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
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 <di...@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 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 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, 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 details.
>
> 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.
>
> Bob
>
> [1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>>
>>> 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!
>>>
>>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
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 <di...@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 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 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, 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 details.
>
> 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.
>
> Bob
>
> [1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>>
>>> 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!
>>>
>>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Robert Newson <rn...@apache.org>.
Yes, perhaps the next move is a wiki page for these items
(deduplicated and with better names and descriptions).
B.
On 14 April 2012 18:11, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sat, Apr 14, 2012 at 6:30 PM, Bob Dionne
> <di...@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 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 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.
>
> We are actually all agree on the need to have focus points. I still
> strongly disagree with this idea of team. But yes we should organize
> the things in different topics.
>
>>
>> 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 details.
>>
>
> I was thinking we could start a wiki and organize things in a table or
> so . Thoughts?
>
> - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Wendall Cada <we...@83864.com>.
On 04/15/2012 02:51 AM, Benoit Chesneau wrote:
> On Sun, Apr 15, 2012 at 8:01 AM, Tim McNamara
> <pa...@timmcnamara.co.nz> wrote:
>> One of the good reasons for this format (although I have no idea if it
>> is why it's why it was chosen) is that there are some good statistics
>> behind pairwise comparison.
>
> The main problem with that format is comparing apples with oranges.
> features should be compared at the same level of usage and eventually
> complexity not just because B come after A or a random has been
> applied.
>
> - benoît
I agree with Benoit here. Most of these comparisons had me scratching my
head. These are largely not even apple/orange comparison, more like
apple/rock comparisons. They have nothing whatsoever to do with each
other. Also, lumping new feature X in with items that are really just
broken and need fixed (re-factored) isn't really useful. All of the
re-factoring needs done, and likely some of the new features. Many of
the new features are likely trigger some of the other work identified
anyhow. -1 on this as a useful voting format.
Wendall
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Apr 15, 2012 at 8:01 AM, Tim McNamara
<pa...@timmcnamara.co.nz> wrote:
> One of the good reasons for this format (although I have no idea if it
> is why it's why it was chosen) is that there are some good statistics
> behind pairwise comparison.
The main problem with that format is comparing apples with oranges.
features should be compared at the same level of usage and eventually
complexity not just because B come after A or a random has been
applied.
- benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Tim McNamara <pa...@timmcnamara.co.nz>.
One of the good reasons for this format (although I have no idea if it
is why it's why it was chosen) is that there are some good statistics
behind pairwise comparison.
On 15 April 2012 05:25, Bob Dionne <di...@dionne-associates.com> wrote:
>
> On Apr 14, 2012, at 1:11 PM, Benoit Chesneau wrote:
>
>> On Sat, Apr 14, 2012 at 6:30 PM, Bob Dionne
>> <di...@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 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 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.
>>
>> We are actually all agree on the need to have focus points. I still
>> strongly disagree with this idea of team.
>
> I'm not a big fan of teams either, but willing to go along if enough folks think it can help make for more progress.
>
>
>> But yes we should organize
>> the things in different topics.
>>
>>>
>>> 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 details.
>>>
>>
>> I was thinking we could start a wiki and organize things in a table or
>> so . Thoughts?
>>
>> - benoît
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
On Apr 14, 2012, at 1:11 PM, Benoit Chesneau wrote:
> On Sat, Apr 14, 2012 at 6:30 PM, Bob Dionne
> <di...@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 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 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.
>
> We are actually all agree on the need to have focus points. I still
> strongly disagree with this idea of team.
I'm not a big fan of teams either, but willing to go along if enough folks think it can help make for more progress.
> But yes we should organize
> the things in different topics.
>
>>
>> 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 details.
>>
>
> I was thinking we could start a wiki and organize things in a table or
> so . Thoughts?
>
> - benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Apr 14, 2012 at 6:30 PM, Bob Dionne
<di...@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 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 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.
We are actually all agree on the need to have focus points. I still
strongly disagree with this idea of team. But yes we should organize
the things in different topics.
>
> 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 details.
>
I was thinking we could start a wiki and organize things in a table or
so . Thoughts?
- benoît
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
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 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, 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 details.
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.
Bob
[1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>
>> 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!
>>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Bob Dionne <di...@dionne-associates.com>.
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 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, 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 details.
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.
Bob
[1] https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.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=true), 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 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:
>>
>> 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!
>>
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Klaus Trainer <kl...@posteo.de>.
<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=true), 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 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:
>
> 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!
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by CGS <cg...@gmail.com>.
Hi Joan,
Very interesting voting system, but there are few questions I would like to
address:
1. The vote is about comparing the priorities/importance which means (from
what I noticed the one time comparison is a randomly chosen cell in the
38x38 matrix less the main diagonal) 1406 answers. Even at half (say,
taking the upper part of the matrix) it means 703 answers. Isn't it a bit
too much? Wouldn't it be simpler to cast a mark for each key feature?
2. Let's say one wants to exhaust all the possibilities (that would be
really something!!!). No one can stay to answer 703 slides in one session
(that's for sure). But here comes another inconvenient I consider: your
votes are vanishing (reduced to 0) after a period of inactivity. Am I wrong
or one needs to cast her/his votes in one session (as many as she/he can)
and after that to stop?
Wouldn't it be easier a system soccer betting system: 1x2 (where "x" means
"I can't decide")? E.g., a form with tabulated data like this (with
pagination, of course):
1. "Partial updates of documents" vs. "Hide the _users database behind an
API" <input type="radio" name="c1" value="1" /> <input type="radio"
name="c1" value="x" /> <input type="radio" name="c1" value="2" />
Just a 2c opinion.
CGS
On Sat, Apr 14, 2012 at 2:24 AM, Joan Touzet <jo...@atypical.net> 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 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:
>
> 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!
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Benoit Chesneau <bc...@gmail.com>.
did we talk about ranking rhem? What about the developer interest too? Also
it may be interresting to order them by the technical needs to develop them
(ie. A depends on B).
benoît
On Saturday, April 14, 2012, 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 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:
>
> 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!
>
> --
> Joan Touzet | joant@atypical.net <javascript:;> | wohali everywhere else
>
Re: Help shape the future of CouchDB: your voice needed!
Posted by Mark Hahn <ma...@hahnca.com>.
I went through them for a while and gave up because there were many
internal ones I didn't understand. Then I looked at results and saw a
number of ideas I would really like to vote for.
In other words this site's methodology didn't work for me.
On Fri, Apr 13, 2012 at 5:24 PM, Joan Touzet <jo...@atypical.net> 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 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:
>
> 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!
>
> --
> Joan Touzet | joant@atypical.net | wohali everywhere else
>