couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Part1: What's up dev? About energy.
Date Fri, 28 Sep 2012 18:42:32 GMT
P.S. Don't let me block you though, if you want to forge ahead, I will help
you out. For deffo!

On Fri, Sep 28, 2012 at 7:41 PM, Noah Slater <> wrote:

> Brian, wow! It's great to see you so excited about this.
> For what it's worth, I had expected that I would be doing the PM stuff. I
> am a PM in my day job, though I am still learning. I think we should form
> an informal (heh!) PM team and take things from there. Perhaps a wiki page
> would be a good start.
> Anyone else interested in joining this PM team? I'm looking at you, PMC
> members.
> Your action items sound great. I would just caution though that we have a
> lot of stuff to catch up on at the moment. And I think we should focus our
> efforts on the big items in our pipeline before we start introducing PM
> activities. (I only have so many hours per week to devote to CouchDB, and I
> need to make sure I'm spending them wisely.)
> Let's focus on getting the docs integrated, and then chasing up BigCouch.
> And then I think we should focus on the stuff you mention. Though, my next
> biggest priority is actually implementing a release cadence.
> Also, I think we should be doing content marketing. Getting people to
> contribute to our blog. Establish ourselves as thought leaders in this
> space. J. Chris used to do a lot of this, but he doesn't blog about CouchDB
> so much any more.
> And FWIW, we're not just a scratch our itch project. ;)
> On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <>wrote:
>> On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <>
>> wrote:
>> > On 26 September 2012 13:03, Bryan Green <> wrote:
>> > > Hello everyone,
>> > >     I would be more than happy to help with the product management
>> area.
>> > >  Just let me know who else is really interested in helping in that
>> area
>> > and
>> > > we can start talking.  I have extensive experience in product
>> > management--
>> > > doing and mentoring.
>> > >
>> > > - bryan
>> >
>> > Given I have no experience in that I'll put my hand up. Here's a good
>> > place to start on that. With whatever product mgmt is. I assume it
>> > involves copious quantities of beer.
>> >
>> > A+
>> > Dave
>> >
>> *Product management is focused on finding, documenting, and prioritizing
>> what users of the product need and/or want the product to accomplish for
>> them.*
>> All of us have our own reasons to work on and use couchdb, and we probably
>> know what couchdb does, but what is our goal as a product team?  What is
>> the mission of the Couchdb project?  Is it only a "scratch an itch"
>> project
>> for the developers who donate their time to it, or is it a project that,
>> also, actively listens to non-contributor users.  There is no right or
>> wrong answer in my opinion, but we do need to establish the expectations
>> of
>> the user before they download couchdb.  If we are mainly a "scratch an
>> itch" project it will make some of what follows in this e-mail moot.  Our
>> marketing on the web-site needs to make it explicit that we are not overly
>> interested in supporting non-contributing users and their problems, if
>> that
>> is our position.  This will save a bitter taste in the mouth of the user
>> when they don't get the support they think they should.
>> It would also help if we could be more proactive in communicating the
>> status of known bugs, and their impact, in existing releases and planned
>> new features.  We could accomplish this by sending an alert e-mail sent to
>> the users mailing list, or on a page of the web-site. I think once a month
>> would be acceptable.  The key would be that it would be a summary of the
>> bug, or feature, and it's impact.
>> When it comes to identifying what we should be working on next, I think it
>> is great that we have really good minds within the project that are
>> capable
>> of idea generation for the product, but we need to expand this out more to
>> the community.  We need to develop user personas, use cases, and what the
>> "competition" is doing.
>> A starting point for all of this could be to catalog the branches of
>> couchdb and analyze why the branch was created and how successful it has
>> been.  We need to get feedback from our users about what they are using
>> couchdb for, and what work-arounds they feel like they had to do to use
>> it-- especially work-arounds that they feel like should not have been
>> needed.
>> We should brainstorm what user classes/roles we have.  This can be done
>> through irc or e-mail.  Basically, you just free flow all the different
>> types of users that you can think of that use couchdb, or should be using
>> it.  Then after we have that big list, we will collapse some down (there
>> will be duplicates), and finally we will have a smaller list of user
>> classes.  We can build personas for each user class.  This eventually
>> helps
>> you understand and identify with your user base.  It also helps develop
>> use
>> cases.
>> We should keep up to date on the main NoSQL products out there and know
>> how
>> we are different.  We should publicize this information on our web-site.
>>  I
>> think transparency is desirable in all relationships, but especially with
>> a
>> user-base.  It would be excellent for users to be able to look at a chart
>> that compares features across the main NoSQL products before they download
>> couchdb.  I don't think it should be explicit marketing, but just as fair
>> and objective as we can be.  If there is a better fit for a user, I think
>> it is in our best interest to help them find the other product.
>> In short, if we are not a project just for a small set of people to work
>> on
>> to "scratch an itch" we need to collect into a usable document what are
>> our
>> product challenges right now, what features are really needed and wanted
>> by
>> the user-base, and set expectations appropriately as early in the
>> relationship as possible.
>> Proposed action items:
>>    1. Decide what kind of open source project we are.  Hopefully this
>>    e-mail will get this resolved.  Explicitly set expectations about
>> support
>>    and priority of non-contributing user requested features/bugs.
>>    2. Start brainstorming session on IRC about user
>> classes/roles/personas.
>>    3. Capture what are the other nosql solutions and the feature
>>    differences.
>>    4. Identify  the innovation branches of couchdb (example is RCouch),
>> and
>>    why it was branched, as well as how successful was it?
>>    5. Analyze the mailing lists to build a list of common complaints and
>>    requests.
>>    6. Communicate new features status monthly in user mailing list.
>>    7. Communicate top bug status and impact monthly in the user mailing
>>    list.
>>    8. Go out of our way to solicit feed-back on a regular basis from
>>    people/companies we know are using couchdb.  Do not wait for them to
>> tell
>>    you something is wrong.  They may abandon the product without ever
>> saying
>>    anything.
>> I list these as things that I am willing to start doing or help with if
>> the
>> community decides we should do any of them.
> --
> NS


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message