Module owner and peerage refresh?
kent at caspia.com
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
> 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