<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<p><a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/User:Dmose/Making_Tb_Rewarding">https://wiki.mozilla.org/User:Dmose/Making_Tb_Rewarding</a> has a web
copy of this posting.<br>
</p>
<p>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. </p>
<p>In general, our current model makes it: </p>
<ul>
<li> too hard for contributors and community members to tell where
the product is going. </li>
<li> too hard for would-be contributors to understand how to
effectively propose and/or make changes to the core code. </li>
<li> 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. </li>
<li> too easy for UX-related change proposals to result in endless
flames rather than the product moving forward.
</li>
</ul>
<p>These are the problems I'd like to attack.
</p>
<p>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. </p>
<p>Here's how I propose to achieve this:
</p>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> 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. </li>
</ul>
<p>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 <<a
href="https://wiki.mozilla.org/User:Dmose/Arch_of_Participation_todos"
class="external free"
title="https://wiki.mozilla.org/User:Dmose/Arch_of_Participation_todos"
rel="nofollow">https://wiki.mozilla.org/User:Dmose/Arch_of_Participation_todos</a>>.
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.
</p>
<p>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.</p>
<p>Dan<br>
<br>
</p>
</body>
</html>