Module owner and peerage refresh?

Kent James kent at
Mon Jul 14 16:27:43 UTC 2014

On 7/11/2014 11:41 AM, Joshua Cranmer 🐧 wrote:
> On 7/11/2014 11:59 AM, Mike Conley wrote:
>> Basically, there was the notion that it's possible our list of module
>> owners and peers is slightly out of date.
>> ....
> After thinking about it for a bit, there are roughly three distinct 
> categories of ownership:
> 1. Technical, people who can r+/r- patches. A good example here, I 
> think, is my relationship to MFBT: because of my knowledge of C++11, I 
> can definitely ascertain the correctness of C++11 polyfills, and thus 
> I get asked to review a few patches in MFBT in that regard. That 
> doesn't really mean I'm qualified to make decisions about design or 
> direction in MFBT.
This is the area that the module system is primarily designed to 
address, and where it generally works well.

One rule I have adopted for myself though might be best to clarify, with 
your MFBT being a good example. If someone who is an owner or peer of a 
module asks you for a review, then your review is sufficient even if you 
are not a module owner or peer. That would be the operating rule in your 
MFBT work.

> 2. Design. This is a bit difficult for me to define [you'll know it 
> when you see it!]. I suppose a working definition is people who are 
> qualified to make comments on something like "I have a crazy idea, 
> what do you think?"

Within the existing module system, I've always assumed that design 
approval is something that only the module owner can supply, but I don't 
believe that is explicit. There's no specific process to get that 
approval, nor do I believe it would be practical to try to formalize it. 
I don't believe that you need to be a module owner or peer to do design.

> 3. Vision. To a degree, this is larger than just modules (although I 
> suppose the "modules" I'm thinking about are actually submodules...), 
> and this is certainly an area that we've failed to had any leadership 
> people take up as a community.
Yep I'd agree. There have been individual attempts to develop overall 
vision, but we have failed to communicate vision or agree as a community 
on a vision that we can all get behind. I hope that we will have an 
opportunity at the summit to have specific discussions about alternate 
visions for Thunderbird, and ideally reach some sort of community consensus.

I would add a few more items to your list of ownership.

4. Empowering efforts with the official approval of the community.

If somebody wants to pursue a Thunderbird-related project that goes 
beyond writing a patch for a specific, existing piece of code, sometimes 
they need official backing to proceed. A specific current example is 
Jayakumar Sadhasivam's offer to organize the design of some Thunderbird 
logos. Another current example would be my effort to organize a 
Thunderbird summit. I've been around enough that I can sometimes make 
things happen without ever getting a formal "OK", by building consensus 
with a wide group of people. It is harder for people who are newer to 
the community, or who culturally feel the need to ask permission before 
starting consensus building.

5. Identifying and filling missing pieces.

Module ownership (defined here as overall project management) needs to 
see where the project has holes, and try to fill them.

6. Formal fiduciary responsibility

If we are going earn income or to accept donations and then spend that 
money, there needs to be a formal method whereby accounting knows that 
money can be spent. Currently that signoff authority sits with the 
existing staff member who is a module owner (Mark Banner). With a more 
communal group, signoff authority would rest in a treasurer who would 
follow instructions from a governing board.


More information about the tb-planning mailing list