incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Green <dbryan.gr...@gmail.com>
Subject Re: Part1: What's up dev? About energy.
Date Fri, 28 Sep 2012 19:20:09 GMT
Actually my user name is Bryan Green

On Fri, Sep 28, 2012 at 2:10 PM, Noah Slater <nslater@tumbolia.org> wrote:

> 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