Engineering Council plans
ovari123 at zoho.com
Tue Aug 15 23:20:02 UTC 2017
Why not call the Thunderbird "Engineering Council" an "Engineering
Steering Committee" (ESC) like LibreOffice?
Using the same terminology will help once Thunderbird joins The Document
On 16/08/17 08:54, Ben Bucksch wrote:
> +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.
>> 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
>> 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
>> - 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
>> Anyone may subscribe to the list to receive postings, or view the
>> (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
>> 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
>> 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 mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning