BrainstormReview

Process

  1. Review the top 15 to 20 entries in http://brainstorm.ubuntu.com/most_popular_6_months/# and pick out 11 or 12 which haven't already been handled in the previous cycles and which seem most appropriate. Picking 11 or 12 will allow you to drop one or two if people don't respond to a particular one, etc.

  2. Determine (ask Ubuntu developers, tech leads, etc.) the most appropriate persons to respond to each of those
  3. Send inquiry/invitation to these developers, CC'ing the Tech board. Template:
    Hello <NAME>,
    
    Once you've read the details below, please respond with an
    acknowledgement and let me know if you can participate.  The expected
    time investment should be about an hour over the next two weeks.
    
    The Ubuntu Technical Board has a regular program to respond to top voted
    topics on Ubuntu Brainstorm:
    
      https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview
    
    The current review cycle is being tracked at
    
      https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview/Dec2012
    
    Our goal is to improve our responsiveness to the questions, concerns
    and suggestions we receive from the user community.  Note that this
    does NOT mean that we will commit to following the suggestions, but we
    will evaluate and respond to them.  By explaining what we will (or
    won't) do and why, we will show that we are paying attention and
    trying to make good decisions on behalf of our users.
    
    The way the program works is that the Technical Board identifies
    people within the Ubuntu project who are knowledgeable in the specific
    topics proposed in Brainstorm, and asks each of them to write a short
    response to one topic.
    
    One of the most popular topics in brainstorm at present is [...]
    
      http://brainstorm.ubuntu.com/idea/XXXXXXX
    
    Since you are well versed in this area, we would appreciate if you could
    spend a short time reading the Brainstorm content about it and writing a
    few paragraphs.  You don't need to have all the answers, and I encourage
    you to ask for input from others who might have a view on the issue.
    This can be in the form of a detailed upstream bug report, a blog post,
    an email, or any other suitable format.  It shouldn't take more than an
    hour or two to complete.
    
    Our goal is to have everything ready for publication by the <DEADLINE>
     Can you confirm that you're willing and able to help with this?
    
    You can formulate your response as you see fit, but make sure that the
    tone is sympathetic.  Many of the comments in Brainstorm take the form
    of demands or complaints: just treat these as if they were questions,
    and answer them politely.  Try to listen to the *need* behind the
    suggestion, not just the suggestion itself, and connect with your
    audience by telling a story about it.
    
    Here are some example formulas which might be helpful to you:
    
     * "It sounds like the problem described here is X.  We address that in
       Ubuntu today by doing A, B and C.  Maybe that's not working for
       everyone because of Y.  We could improve this by doing Z."
    
     * "I would love to see a new feature like that in Ubuntu.  It's
       consistent with the way other parts of Ubuntu work, and seems
       genuinely useful.  We're busy with some higher priority projects at
       the moment like X, but if someone is interested in writing a patch
       for this, I will help them get it into Ubuntu and upstream."
    
     * "This is a really hard problem without an easy solution.  It's
       complex because of X, Y and Z.  It will take some time for this to be
       completely solved, but here are a few projects we're working on which
       will make things better, bit by bit."
    
     * "That's an easy fix.  I've written a patch and uploaded it to
       Oneiric.  It will be in the 11.10 release!"
    
     * "That's a great idea, and we already thought of it!  Here's the
       blueprint, and here's how you can follow along as this gets
       implemented in Natty."
    
     * "I passed on your suggestion to the upstream developer of the
       software, and we had a conversation about it.  Here's what we
       decided."
    
     * "This seems like a genuine problem, but I'm not sure that's the right
       solution, because of X and Y.  I asked our usability expert Jill
       about this, and here's what she suggested."
    
     * "I didn't understand what the problem was here, so I had a
       conversation on IRC with Jamie, who submitted this topic to
       Brainstorm to understand better.  Here's how it went:
    
       [...]
    
       In the end, we both decided that the best course of action is X."
    
    If you have any further questions about what is expected here, please
    let me know.
    
    Thank you in advance!
    
    <SENDER>
    pp. Ubuntu Technical Board
  4. Keep track of confirmations and responses, and follow up with people. It's best to keep a table for this which tracks the brainstorm URLs, the designated developer, the dates of "confirmed" and "replied", and the URL of the response.
  5. At the deadline, do a blog post and/or ubuntu-devel-announce@ summary with a summary of each brainstorm idea and the response, linking to the idea and response. See the three previous rounds in above email template for examples.

Previous reviews

TechnicalBoard/BrainstormReview (last edited 2012-12-11 07:20:32 by pitti)