Engineering Council plans

[R Kent James]

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.


    A. Why do we need an Engineering Council?

Generally, there are several problems we are trying to address.


      A.1: Lack of a single focus point for technical decisions

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 
https://www.oxymoronical.com/blog/2017/07/Thoughts-on-the-module-system) 
as well as how that has functioned within Thunderbird.

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.

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.

So an Engineering Council will be tasked with setting the technical 
direction of Thunderbird.


      A.2:  Need to involve people outside of the Thunderbird Council in
      key decision discussions.

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.


        - Thunderbird staff.

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.


        - Key volunteers.

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.


      A.3:    Need for more open discussions

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.


    B.    How will the Engineering Council function?


      B.1    Location of Engineering Council discussions

We have setup a Mailman list maildev at lists.thunderbird.net for 
Engineering Council discussions. The information page for this, where 
people may subscribe or view the archives, is at 
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net


Anyone may subscribe to the list to receive postings, or view the 
archives 
<http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/> 
(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.

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.


      B.2    Scope of Engineering Council discussions and decisions

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.

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

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 
Skunk Works <https://en.wikipedia.org/wiki/Skunk_Works> 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.


      B.3    Engineering Council decision process

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.

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.

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.

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:

Mozilla Foundation
     ⇓
Thunderbird Council
     ⇓
Engineering Council
     ⇓
Module Owners and Peers


    C.    Next Steps

If you are interested in following these discussions, please subscribe 
to the Maildev list at 
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I will be subscribing a few key people whose participation is critical 
for success of the process directly.

/R Kent James (:rkent)//
//Thunderbird Council Treasurer/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20170718/e89fa039/attachment.html>