Making Tb participation more rewarding & fun
dmose at mozillamessaging.com
Wed Jul 14 19:46:43 UTC 2010
https://wiki.mozilla.org/User:Dmose/Making_Tb_Rewarding 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
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...
More information about the tb-planning