Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8C232D609 for ; Fri, 28 Sep 2012 19:10:44 +0000 (UTC) Received: (qmail 14343 invoked by uid 500); 28 Sep 2012 19:10:44 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 14305 invoked by uid 500); 28 Sep 2012 19:10:44 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 14293 invoked by uid 99); 28 Sep 2012 19:10:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Sep 2012 19:10:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of nslater@tumbolia.org designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Sep 2012 19:10:36 +0000 Received: by ieje10 with SMTP id e10so7713546iej.11 for ; Fri, 28 Sep 2012 12:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tumbolia.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=QHxc8y0dpsvo6wtBxRk6pCoSRwOFXQjgw0nDr5ZEEBA=; b=I86tQWeRGflK2Ac+vcIMaTKNhaq5MGol5h8jdob7HvGN9yddqZWFpSBtiEzZrMFjSj LW+YxUfsflq+Mv4HPUdEVJCd2WF2Bi9SjBKROCUsVBSHH0k7siSHIhEWoxfR4RvT87s6 jlcgNvokInNWbu+2lO3yssRg5bl7LhZ05fuUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=QHxc8y0dpsvo6wtBxRk6pCoSRwOFXQjgw0nDr5ZEEBA=; b=WhLbWyslfnre5Xs+SrmM8dwuHJEfupu3CL+CQDeyVtgFs9wTvAZ6yk9+9rl9sfq36Y yvhSatf1okrloEq1IWRVo/+WZUy8G7PQ8e/8dhmSWyW1JxOXjAcOWnQnSmIzCPKSqieL KOcl1+Z7/5QpabkTGeFxsq/KXG7YOASfPMN2OKhfDzdgkD6tUaD3bh5AdyZykpolpKN7 8/zJXglysUXeeeVAtW/4NAlB3Uqyb6E+3s5GkVEStUg6iSeQilrE3txsxFZ1RWxEHsBU qt9eHN1bsSx9HkVkbOj57OyKb4K7WO9pZwOQHIzLUg76tgauI7VKmL6TiEWYi09IMWZb a09A== MIME-Version: 1.0 Received: by 10.50.47.201 with SMTP id f9mr2531053ign.44.1348859415055; Fri, 28 Sep 2012 12:10:15 -0700 (PDT) Received: by 10.64.63.19 with HTTP; Fri, 28 Sep 2012 12:10:15 -0700 (PDT) X-Originating-IP: [79.97.124.139] In-Reply-To: References: Date: Fri, 28 Sep 2012 20:10:15 +0100 Message-ID: Subject: Re: Part1: What's up dev? About energy. From: Noah Slater To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=14dae9340e17494b9204cac7cefd X-Gm-Message-State: ALoCoQmgeAWp6lmLdD2apQQVa9kQ5giG5ZDihTJHxJ3oUwFJBFWaBtJ/8m35O1LjxWdb48aG9NFS --14dae9340e17494b9204cac7cefd Content-Type: text/plain; charset=ISO-8859-1 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 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 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 > > wrote: > > > > > On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber > > > wrote: > > > > > > > On 26 September 2012 13:03, Bryan Green > > 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 --14dae9340e17494b9204cac7cefd--