<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">+1 from me<br>
<br>
<br>
<br>
R Kent James wrote on 18.07.2017 20:17:<br>
</div>
<blockquote type="cite"
cite="mid:c3c6a518-a5d5-8470-8cee-2eb60fd1366a@caspia.com">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
<p> </p>
<div class="moz-text-flowed" lang="x-unicode">I've mentioned a few
times here my perception that we need some reorganization of
project leadership, and mentioned an Engineering Council as part
of that. We've had discussions with the Thunderbird Council
about that, and are ready to proceed.<br>
<h2>A. Why do we need an Engineering Council?</h2>
Generally, there are several problems we are trying to address.
<br>
<h3>A.1: Lack of a single focus point for technical decisions</h3>
Mozilla has used a module system for many years as a way to
manage technical issues. But there are some issues with that
system, both within Firefox (see <a
href="https://www.oxymoronical.com/blog/2017/07/Thoughts-on-the-module-system"
moz-do-not-send="true">https://www.oxymoronical.com/blog/2017/07/Thoughts-on-the-module-system</a>)
as well as how that has functioned within Thunderbird.<br>
<br>
Within Thunderbird, we've found it difficult to make technical
decisions, particularly if they are larger than the scope of an
individual bug. Existing forums such as tb-planning or
m.d.a.thunderbird are not really designed to reach a concrete
decision.<br>
<br>
The module system more or less assumes an individual will be the
owner/dictator for the technical decisions, but there really is
no one individual with the experience and trust of the community
who could own the technical direction of the project. To some
extent this role has then fallen to the Thunderbird Council, but
for reasons to be discussed below that is not really
appropriate.<br>
<br>
So an Engineering Council will be tasked with setting the
technical direction of Thunderbird.<br>
<h3> A.2: Need to involve people outside of the Thunderbird
Council in key decision discussions.</h3>
<p> There are two classes of people whose input is sorely needed
who are left out if a closed Thunderbird Council tries to set
technical direction.</p>
<p> </p>
<h4> - Thunderbird staff.</h4>
<p>As we move toward having around 6 full-time equivalent staff
people for Thunderbird, those individuals will be carrying a
lot of the load of moving the project forward technically, and
are in a good position to give input toward issues. For a
variety of reasons not all staff will be or should be on an
elected Thunderbird Council. This is particularly important
since the Thunderbird Council has fiduciary responsibility for
managing donations, including hiring and managing staff, so a
staff-dominated and closed Thunderbird Council would create
many difficult-to-resolve conflict of interest problems and
perceptions of insider dealings.</p>
<p> </p>
<h4> - Key volunteers.</h4>
<p> There are a number of individuals who as volunteers put a
tremendous about of technical effort into Thunderbird, and who
should also be involved in setting technical direction.</p>
<h3>A.3: Need for more open discussions</h3>
<p>The Thunderbird Council has some issues that need to be
discussed privately, and for that reason their main discussion
list is a closed list. But we should strive to be as open as
possible, and that means that we need a publicly accessible
place where decisions are discussed and reached.</p>
<h2>B. How will the Engineering Council function?</h2>
<h3>B.1 Location of Engineering Council discussions</h3>
<p>We have setup a Mailman list <a
class="moz-txt-link-abbreviated"
href="mailto:maildev@lists.thunderbird.net"
moz-do-not-send="true">maildev@lists.thunderbird.net</a> for
Engineering Council discussions. The information page for
this, where people may subscribe or view the archives, is at <a
href="http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net"
moz-do-not-send="true">http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net</a><br>
</p>
<h3> </h3>
<h3> </h3>
<p>Anyone may subscribe to the list to receive postings, or view
the <a
href="http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/"
moz-do-not-send="true">archives</a> (which at the moment
only contain test messages). However, we want to make sure
that the discussions themselves are dominated by people who
are actively contributing as Thunderbird or Mozilla
developers, or who are key Thunderbird leaders, to keep the
signal/noise ratio high. To accomplish this, individuals who
are active developers or leaders will post unmoderated, while
others will be moderated.<br>
</p>
<p>As the list is primarily intended as being a discussion forum
for active developers, posts by others will in most cases not
be accepted, but this decision will be on a post-by-post
basis. Also, moderation requests may not be processed daily,
so it may take a few days to review any moderated postings.</p>
<h3>B.2 Scope of Engineering Council discussions and
decisions<br>
</h3>
<p>Within Thunderbird and the comm-central code, the core email
functionality is the dominant feature, but there are other
subgroups that may have their own issues or positions,
including chat, calendar, contacts, and SeaMonkey. We
discussed how to include these subgroups, and whether to have
some complex system of dividing up discussions or decisions by
affected subgroups. Ultimately what we decided is, rather than
introduce additional organizational complexity, we would let
the core email functionality dominate, and trust email leaders
to include the interests of subgroups in any decisions that
are reached. Developers in those subgroups are welcome to join
the list and participate in technical discussions. Likewise,
other technical work within the Thunderbird project, including
work on infrastructure and build processes, should be subject
to Engineering Council discussions and decision.<br>
</p>
<p>The Engineering Council will not have any fiduciary
responsibility or approval authority over spending, but will
be expected to make major recommendations to the Thunderbird
Council for financial decisions and appropriations. (This is
partially modeled after the organization structure of TDF
which has separate engineering and board groups).</p>
<p>On tb-planning and elsewhere there has been discussions of a
possible major project to completely rewrite Thunderbird
(TB:NG). The proponents of that have expressed a desire for
such a project to be as independent as possible from existing
management oversight, following a so-called <a
href="https://en.wikipedia.org/wiki/Skunk_Works"
moz-do-not-send="true">Skunk Works</a> model. Nothing in
this proposal for an Engineering Council is intended to
dictate the management structure for the TB:NG project, which
will need to be established if and when that project is
approved and funded.</p>
<h3>B.3 Engineering Council decision process</h3>
<p>When a concrete decision in a technical area is needed, a key
leadership group will make that decision by voting. We'll call
that group the Engineering Directors. Initially, the
Engineering Directors are rkent, BenB, Jörg, and Magnus.</p>
<p>In general, the Engineering Group is intended to be
self-managing. So criteria for inclusion in discussions and
other organizational issues will be managed by the group
itself, after an initial seeding of the group based on
criteria setup by the Thunderbird Council.</p>
<p>The Engineering Council is not intended to replace the
existing technical module owners and peers, or play a direct
role in approving patches. The intent is to deal with issues
that are larger than an individual patch. These are the types
of issues that would normally be dealt with by a product
management group, or by an engineering manager.</p>
<p>Within the overall management hierarchy of Thunderbird, the
Engineering Council sits between the Thunderbird Council and
the modules owners and peers. So an overall authority
structure for Thunderbird will be:</p>
<p>Mozilla Foundation<br>
⇓<br>
Thunderbird Council<br>
⇓<br>
Engineering Council<br>
⇓<br>
Module Owners and Peers<br>
</p>
<p> </p>
<h2>C. Next Steps</h2>
<p>If you are interested in following these discussions, please
subscribe to the Maildev list at <a
class="moz-txt-link-freetext"
href="http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net"
moz-do-not-send="true">http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net</a></p>
<p>I will be subscribing a few key people whose participation is
critical for success of the process directly.</p>
<p><i>R Kent James (:rkent)</i><i><br>
</i><i>Thunderbird Council Treasurer</i></p>
<p><br>
</p>
<p> </p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>