Making Tb participation more rewarding & fun

Dan Mosedale dmose at
Wed Jul 14 19:46:43 UTC 2010 has a web copy 
of this posting.

As some folks are likely aware, I've recently been heavily focussed on 
our architecture of participation (i.e. the systems and processes that 
we use to work together). This is a big topic, and I'm starting by 
looking most closely at our engineering and development model.

In general, our current model makes it:

    * too hard for contributors and community members to tell where the
      product is going.
    * too hard for would-be contributors to understand how to
      effectively propose and/or make changes to the core code.
    * too easy for patches to be written that would never be accepted,
      or structured in a way that doesn't work for the core, or fall off
      the radar, or hit process roadblocks.
    * too easy for UX-related change proposals to result in endless
      flames rather than the product moving forward.

These are the problems I'd like to attack.

What I'm hoping that we can do, as a group, is implement some changes 
that address these problems and make Thunderbird a more fun, rewarding, 
and efficient place for people to work and contribute.

Here's how I propose to achieve this:

    * better communication: Up until very recently, I'd been talking
      about writing a product charter. After some iteration and
      feedback, it became clear that while having a charter will be
      tremendously useful, our product thinking isn't far enough along
      to draft that just yet and we need to start a bit smaller. So,
      what I've got now are a couple of drafts which are not high-level
      pronouncements, but are rather starting points for feedback and
      iteration, which is why I've chosen pre-1.0 version numbers. One
      is a draft of high-level notes about the product, and the other
      tries to describe key work processes.

    * better efficiency: In general, we spend far too much time
      unnecessarily re-deriving and explaining product and process
      thinking from first principles. A secondary goal of both the above
      documents is that, as artifacts, they can serve as shortcuts for
      project, UX, and module owners to decide how to move forward. The
      docs are likely to need some level of annotation about the "whys"
      of what they say in order to serve that function, I expect.

    * better feedback loops: As we've said before we need to make it
      easy to reward contributors quickly when they spend time
      contributing to Thunderbird. The first thing I have in mind is to
      set up metrics for tracking important stuff on an ongoing basis
      (such as review response time, frequency of contributions, areas
      of contributions, etc.), and commit to driving those in the right
      direction. The second is to regularly and intentionally solicit
      input from our everyone in our development community (probably
      initially with surveys) and then make changes based on that input.

A larger list of the things that I'm planning to dig into over time 
(along with a schedule for the first few) is at 
<>. I'm 
sure there are plenty of other things we can do; feel free to add 
comments to this thread or to the talk page there with suggestions.

I'm going to start with the two drafts I've got for broader feedback. 
Please don't be shy about commenting (either publicly or privately). Now 
is the time when feedback can have the most effect.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list