couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Part1: What's up dev? About energy.
Date Fri, 28 Sep 2012 19:10:15 GMT
Bryan, I preferred your original framing! (i.e. I can help you, as you seem
to know what you're doing! Not the other way around.) Like I said, I'm
still learning this PM business. I have a bunch of thoughts about what we
need to do, scattered about the place.

A wiki page would be a good place to collect our ideas.

Give me your wiki username and I will add you to the contributors group.

On Fri, Sep 28, 2012 at 7:59 PM, Bryan Green <dbryan.green@gmail.com> wrote:

> 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
> >
>



-- 
NS

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