<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Why not call the Thunderbird "Engineering Council" an
"Engineering Steering Committee" (ESC) like LibreOffice?
<br>
<br>
<a class="moz-txt-link-freetext"
href="https://wiki.documentfoundation.org/Development/ESC">https://wiki.documentfoundation.org/Development/ESC</a>
<br>
<br>
Using the same terminology will help once Thunderbird joins The
Document Foundation...
</p>
<br>
<div class="moz-cite-prefix">On 16/08/17 08:54, Ben Bucksch wrote:<br>
</div>
<blockquote type="cite"
cite="mid:91a64364-709f-a750-c3bf-fc70ed7a4674@beonex.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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" moz-do-not-send="true">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning" moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<p><br>
</p>
<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>
<br>
</body>
</html>