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 dbryan.green@gmail.com
 designates 209.85.219.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+Y+447bO7mNrBC9crpznNY7RZRqejU1FKE3bJuxwEG3XEkaxA@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>
	<CA+Y+447bO7mNrBC9crpznNY7RZRqejU1FKE3bJuxwEG3XEkaxA@mail.gmail.com>
Date: Fri, 28 Sep 2012 13:59:03 -0500
Message-ID: 
 <CAF+pBj-RdHiz9iSqcvYWkCxkJ151z9+FuoCkAAVKpcjw_aTB_A@mail.gmail.com>
Subject: Re: Part1: What's up dev? About energy.
From: Bryan Green <dbryan.green@gmail.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=e89a8f838db144cc1104cac7a6bc

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

Noah,
   I would be more than happy to help you out in anyway I can.  I am new to
this project,
so just let me know how I can help you in your PM role.  I would love to
have access
to the wiki to start a page.

- bryan

On Fri, Sep 28, 2012 at 1:41 PM, Noah Slater <nslater@tumbolia.org> 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 <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
>

--e89a8f838db144cc1104cac7a6bc--