Thunderbird Architecture of Participation Doc v.06
dmose at mozillamessaging.com
Wed Jul 14 19:46:54 UTC 2010
A current version of this document can be found at
<https://wiki.mozilla.org/User:Dmose/Tb_Participation>. 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
* 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.
* 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
* 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...
More information about the tb-planning