User:Dmose/Making Tb Rewarding

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Making Thunderbird Participation More Fun, Rewarding, and Efficient

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 address.

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 <https://wiki.mozilla.org/User:Dmose/Arch_of_Participation_todos>. I'm sure there are plenty of other things we can do; feel free to add comments to the talk page either here or there with suggestions.

I'm going to start by posting 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!