Confirm
2,615
edits
Changes
Created page with '{{Draft}} (please do not yet share outside of the summit; I'd like to incorporate key summit feedback before asking for broader feedback, which I'll do next week) == Making Thu…'
{{Draft}}
(please do not yet share outside of the summit; I'd like to incorporate key summit feedback before asking for broader feedback, which I'll do next week)
== 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 last week, 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.
* 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. There are a number of ways to attack this, and I'd be interested in other ideas as well. 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 interested in digging into over time are at https://wiki.mozilla.org/User:Dmose/Arch_of_Participation_todos
I'm going to start by posting the two drafts I've got for broader feedback.
(please do not yet share outside of the summit; I'd like to incorporate key summit feedback before asking for broader feedback, which I'll do next week)
== 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 last week, 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.
* 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. There are a number of ways to attack this, and I'd be interested in other ideas as well. 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 interested in digging into over time are at https://wiki.mozilla.org/User:Dmose/Arch_of_Participation_todos
I'm going to start by posting the two drafts I've got for broader feedback.
