<!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">
A current version of this document can be found at <<a
href="https://wiki.mozilla.org/User:Dmose/Tb_Participation">https://wiki.mozilla.org/User:Dmose/Tb_Participation</a>>.
Feel free to comment in this tb-planning thread or on the wiki
comment page.<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<h2><span class="mw-headline">Architecture of Participation v0.6 </span></h2>
<p>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.
</p>
<a name="Goals_For_This_Document" id="Goals_For_This_Document"></a>
<h2><span class="editsection"></span><span class="mw-headline">
Goals For This Document </span></h2>
<p>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.
</p>
<p>2. Act as a reference/short-cut for decision-makers, lessening
the need to constantly reason and discuss from first principles.
</p>
<a name="Community" id="Community"></a>
<h2><span class="editsection"></span><span class="mw-headline">Community
</span></h2>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> 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.
</li>
</ul>
<a name="Decisions" id="Decisions"></a>
<h2><span class="editsection"></span><span class="mw-headline">Decisions
</span></h2>
<ul>
<li> Our criteria for making decisions are, in order:
<ul>
<li> values & goals
</li>
<li> data
</li>
<li> conjecture
</li>
</ul>
</li>
</ul>
<ul>
<li> 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).
</li>
</ul>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> 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.
</li>
</ul>
<a name="Development_Process" id="Development_Process"></a>
<h2><span class="editsection"></span><span class="mw-headline">
Development Process </span></h2>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> 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. </li>
</ul>
<ul>
<li> We will prioritize implementing hooks that allow developers
to do more and better experimentation in add-ons.
</li>
</ul>
<ul>
<li> We will regularly solicit feedback from the larger
development community and work to continue to improve our
processes based on that feedback.
</li>
</ul>
<a name="Design" id="Design"></a>
<h2><span class="editsection"></span><span class="mw-headline">
Design </span></h2>
<ul>
<li> 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.
</li>
</ul>
<ul>
<li> We intend to explore structures to make it easier for
designers to work in this manner.
</li>
</ul>
<br>
</body>
</html>