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 <dio...@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! >>> >> >
