<!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>