Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of nslater@tumbolia.org
 designates 209.85.223.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAF+pBj9JaMQV55aDKq4UHGCJtFSH3C1QL=wA9M+cgSESE_8SPw@mail.gmail.com>
References: 
 <CAJNb-9o+A7GMXGe3FdBkmX6zb2miRvScX91qcDnosD1JRTrzxw@mail.gmail.com>
	<CA+Y+447jjS5tr9JPhTTAQb1u+Ugi_cLeuvASN3hLfgDhyiE+eg@mail.gmail.com>
	<CAF+pBj-kbt-F37KABsw=yQHrRkN5OXmMLdH=Puf9UG4=SbLMDw@mail.gmail.com>
	<CAL+Y1ns9+PwtAcDJKOpa89cjqK+UB6gUZ1UKZa=a=irzFkC87Q@mail.gmail.com>
	<CAF+pBj9JaMQV55aDKq4UHGCJtFSH3C1QL=wA9M+cgSESE_8SPw@mail.gmail.com>
Date: Fri, 28 Sep 2012 19:41:06 +0100
Message-ID: 
 <CA+Y+447bO7mNrBC9crpznNY7RZRqejU1FKE3bJuxwEG3XEkaxA@mail.gmail.com>
Subject: Re: Part1: What's up dev? About energy.
From: Noah Slater <nslater@tumbolia.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=e89a8f646b071825e704cac7669f

--e89a8f646b071825e704cac7669f
Content-Type: text/plain; charset=ISO-8859-1

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 <dbryan.green@gmail.com> wrote:

> On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dch@jsonified.com>
> wrote:
>
> > On 26 September 2012 13:03, Bryan Green <dbryan.green@gmail.com> 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

--e89a8f646b071825e704cac7669f--