Thunderbird Architecture of Participation Doc v.06

Dan Mosedale dmose at
Wed Jul 14 19:46:54 UTC 2010

  A current version of this document can be found at 
<>.  Feel free to 
comment in this tb-planning thread or on the wiki comment 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.


    * 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.


    * Our criteria for making decisions are, in order:
          o values & goals
          o data
          o 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.


    * 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list