<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p> </p>
    <div class="moz-text-flowed" style="font-size: 14px;"
      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 moz-do-not-send="true"
href="https://www.oxymoronical.com/blog/2017/07/Thoughts-on-the-module-system">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">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
          moz-do-not-send="true"
href="http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net">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 moz-do-not-send="true"
href="http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/">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
          moz-do-not-send="true"
          href="https://en.wikipedia.org/wiki/Skunk_Works">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">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>
  </body>
</html>