Engineering Council plans

Ben Bucksch ben.bucksch at
Tue Aug 15 22:54:45 UTC 2017

+1 from me

R Kent James wrote on 18.07.2017 20:17:
> 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.
>   0.1. A. Why do we need an Engineering Council?
> Generally, there are several problems we are trying to address.
>   0.1.1. 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 
> 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.
>   0.1.2. 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.
>   0.1.3. 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.
>   0.2. B.    How will the Engineering Council function?
>   0.2.1. B.1    Location of Engineering Council discussions
> We have setup a Mailman list maildev at for 
> Engineering Council discussions. The information page for this, where 
> people may subscribe or view the archives, is at 
>   0.2.2.
>   0.2.3.
> Anyone may subscribe to the list to receive postings, or view the 
> archives 
> <> 
> (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.
>   0.2.4. 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 <> 
> 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.
>   0.2.5. 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
>   0.3. C.    Next Steps
> If you are interested in following these discussions, please subscribe 
> to the Maildev list at 
> 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/
> _______________________________________________
> tb-planning mailing list
> tb-planning at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list