Change of release and governance model for Thunderbird

Wayne Mery (d531) vseerror at Lehigh.EDU
Wed Jul 11 12:25:08 UTC 2012

On 7/11/2012 6:36 AM, Ludovic Hirlimann wrote:
> On 7/11/12 5:40 AM, Joshua Cranmer wrote:
>> On 7/10/2012 8:34 PM, Axel wrote:
>>> For an outsider it is sometimes hard to determine who works on what,
>>> and it might help if there was some feature/module-centric
>>> (team)focus... what do you think?
>> As Kent mentioned, I decided to put up a tb-roadmap etherpad detailing
>> the kinds of major projects that I think would be useful for
>> Thunderbird, and am happy to solicit feedback from anyone else. I'm
>> also currently preparing a proposal-via-blog-post about the missing
>> parts of our automated testing regime.
> Can you share the etherpad ?

kent mentioned it earlier :)

> I believe we can build a community nowish as we are having momentum - we
> probably need to communicate things we decide and do a bit more widely
> to this mailing list - because not everyone is reading it.
> Now let's see if I was currently 'just' a Thunderbird user and figured
> out that I need to do something to make sure that my favorite email
> client is going to have a viable future what would I be faced with.
> I would need to find a clear and easily findable entry point - a place
> where I can come quickly read some text or watch a quick video, which
> would let me then decide how I can help. As a user I can decide where to
> help based on two major point and on a minor one :
>  1. How much time can I invest every week for the project
>  2. What are my technical skills
>  3. and the minor one is more around how much do I want to learn so I
>     can do 'more'
> I've tried but I'm not sure I succeeded when I changed the way
> read and look.

perhaps a "community" page?  (novel idea) isn't a bad start. 
Unfortunately some links will sort of dead end for a thunderbird user. 
For example the "get involved" link leads to a great video on but then most of the links 
there move on to firefox bits

and in general pretty much everything in is firefox-centric, 
or feeds to firefox information. Understandably so I suppose.


> I think starting with a roadmap is a very good idea and that will let us
> figure out where do we go from here. Having documents like the state of
> unit and automated testing is really helpful even for me to understand
> what's missing and where should work be allocated if anybody showed up
> with time to add more tests. So I think rkent's idea of building a list
> of bugs and saying these are the ones we would like to fix is a great
> idea to start a good roadmap.

I have some methodology to propose in a few days about "lists".

>>> If we had small teams of people who could cluster around certain
>>> areas of expertise and we had some known leaders for these who can
>>> make the final decisions or are the go-to guys for asking before
>>> somebody attempts to patch something it also might make work more
>>> efficient. (this might already be organized this way, I do not know
>>> the process well enough at the moment, but some transparency would
>>> sure be nice).

small teams could be good.  "small" cuts down on communications issues 
and time investment. And permits strong focus within expertise and 
interest. And can spread the workload beyond module owner.

More information about the tb-planning mailing list