Confirm
2,615
edits
Changes
Rearranged a bit for clarity.
* 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 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.
