Module owner and peerage refresh?

Joshua Cranmer pidgeot18 at gmail.com
Mon Jul 14 21:59:08 UTC 2014


On 7/14/2014 11:27 AM, Kent James wrote:
> 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.

There are, I think, more fine-grained rules for review, but those tend 
to be "if you have to ask, they don't apply" (modules are rather 
coarse-grained).

>> 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 think, on reflection, one of the biggest reasons for failure here is 
that, while it is possible to build consensus, it's unclear when that 
consensus equals community agreement or even whose assent or dissent 
"matters more."

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

It's been a perennial observation of yours that modules tend to be 
focused on coding, and on reflection, I am guilty as charged. :-(

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

Overall, this suggests that Gerv's continual attempts to get us to use 
the set of module owners to define the body of people who can act in 
these roles is a failure.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor




More information about the tb-planning mailing list