User:Dmose/Tb Participation

	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.

Architecture of Participation v0.6

As with the 0.6 product notes, this is a starting point for discussion, none of it is set in stone. Some of it codifies existing practice, some of it is a change.

Goals For This Document

1. Help contributors understand how to make things happen in the Thunderbird projects in ways that are both enjoyable and rewarding, and not be surprised and frustrated by unforeseen roadblocks.

2. Act as a reference/short-cut for decision-makers, lessening the need to constantly reason and discuss from first principles.

Community

• Mozilla strives to build and strengthen a healthy community of participation around Thunderbird, based on mutual respect, positive contribution, and recognition of differences in experience and interests.

• With input from the community (and inspired in part by the tb-planning rules), we intend to draw up an explicit social contract focused on making and keeping Thunderbird an enjoyable and productive project in which to participate.

• Understanding that conversations can be very hard to scale (discussions around user-experience and features suffer especially in this regard), we intend to continue to experiment with various structures for development discussions and decisions. We will strive to be as transparent as possible, and we will continue to provide venues for all users and community members to offer feedback. However, not everyone will have the opportunity to take part directly in every discussion.

Decisions

• Our criteria for making decisions are, in order:
  • values & goals
  • data
  • conjecture

• When we have sufficient relevant and clear data, we will make decisions based on that. When we don't, we will bias towards implementations that allow us to gather data about the functionality (e.g. add-ons).

• It is the responsibility of the decision maker to gather feedback from the community, balance conflicting interests, and render a decision. If, after a decision has been made, people continue to inappropriately advocate for their positions in community areas (such as the bug or thread where the decision was rendered), they will be asked to take that advocacy elsewhere.

• Decisions regarding which contributions are ultimately accepted in the core product will be made by the project, UI, and module owners. Contributors who wish to do significant work with a goal of getting changes in core are welcome but are heavily encouraged to contact a project, UI, or module owner before beginning, to see if, how, and when that work is likely to be accepted.

Development Process

• We expect to do initial iterations of much of our development work in add-ons first and land things in the core after we have significant useful feedback on those add-ons. Almost all user-facing changes will happen this way, as will non-trivial backend changes. We heavily encourage developers who wish to contribute significant changes to the core to do the same.

• Developers are heavily encouraged to structure contributions to core in small, discrete pieces, with automated tests for easy reviewing. Large, monolithic patches are only rarely accepted, and when they are, it's almost always in cases where the project, UI, and module owners have been involved in the development process from the beginning of those changes.

• We will prioritize implementing hooks that allow developers to do more and better experimentation in add-ons.

• We will regularly solicit feedback from the larger development community and work to continue to improve our processes based on that feedback.

Design

• Attempting to drive non-trivial user-experience core changes through the UI-review process has proven to be very difficult. This is in very large part because textual and even graphical descriptions of specific changes tend be extremely low-fidelity ways to capture how the actual change will feel. As a result, we ask that developers or designers who wish to propose non-trivial UX changes do so by prototyping them in an add-on, and then requesting ui-review of that user-experience before attempting to write a patch for the core.

• We intend to explore structures to make it easier for designers to work in this manner.