Noah, shevek if it is not taken. On Fri, Sep 28, 2012 at 2:10 PM, Noah Slater <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > > > wrote: > > > > > > > On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <[email protected] > > > > > > wrote: > > > > > > > > > On 26 September 2012 13:03, Bryan Green <[email protected]> > > > 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 >
