First of all, let me assure you one thing your various blog postings provoked: An outcry by many Thunderbird users, about a program they love and use! When subtracting the "Google Factor" in all the comments posted I could clearly see the level of surprise (including me) and the question about "what's wrong with Thunderbird"? Maybe that adoption is slow, even so it works so well for me? Or that the community surrounding it is small? Or that online web apps are the future? The majority went to look for reasons elsewhere (Google), since....well, Thunderbird does what it's supposed to do!?
Mitchell's and Scott's postings were perhaps misunderstood, but it was clear that nobody wants to miss Thunderbird! Most wanted the current commitment to Thunderbird remain as it is. I suspect this reflects about a certain level of satisfaction about this application and what it offers for most current users! This is certainly how I feel about it and my personal wish list is small! Take this as a compliment for your work!
Looking for clues, I found the road map (http://www.mozilla.org/projects/thunderbird/roadmap.html) pretty outdated, lacking vision...The same is true about the postings on the blogs. No real plan, no vision and no defined goals, but the need to make changes. This was also reflected in Mitchell's reply titled "Thunderbird and the Mozilla Mission" somewhat. Questions like on what to focus, how to gain a bigger community, creating excitement...and so I'm asking, what is that Mozilla (the organization), Mitchell, Scott, David and most important the many users want?
What made Scott and David propose organizational changes? Do you have a vision and goals which you can't achieve in its current form? What is your agenda? What is the goal of Mozilla? Reduce costs, create revenue, create a higher market share? None of your posts really explain that, except that there seems to be a problem and you want Thunderbird to grow and flourish...(in contradiction to Mitchell's statement "We are convinced that our current focus - delivering the web, mostly through browsing and related services - is the correct priority.")
If there is a plan, then perhaps explain it to us. If there isn't one, than I'll be glad to help and work on one, being it by analyzing, researching and discussing current problems, suggestions and by finding ideas and new focus. I'd be able to help create the recommendations and reports needed to move forward. I apologize upfront if this is the field of somebody else or isn't welcome, but judging from the lack of (published) goals and clear road map, this is perhaps what's needed now! So even my field of interest is usually elsewhere, I'll be glad to contribute some of my time for this. Please advice...
> If there is a plan, then perhaps explain it to us. If there isn't one, > than I'll be glad to help and work on one, being it by analyzing, > researching and discussing current problems, suggestions and by finding > ideas and new focus. I'd be able to help create the recommendations and > reports needed to move forward.
This is almost exactly my own position on the topic. I'd be glad to join! So far there have been many ideas/suggestions regarding the new vision.
- Integrating multiple forms of online & offline communication, including IM, retroshare and others. Making Thunderbird the interface to disparate services.
- Adding more improved addresses and calendering.
- Better support for corporate needs to compete with the Outlook +Exchange duo.
I think these could be fine starting points for a new plan. And I'd like to add my own suggestion of integrating knowledge management features (ex: automatic message filtering using Baysean classification, better search and tagging...etc)
Also, I'd like to ask if this is the final place for discussing the roadmap or if we should move to the dev@openoffice list as schmidtm524 suggested :)
Mohamed Samy wrote: > I think these could be fine starting points for a new plan. And I'd > like to add my own suggestion of integrating knowledge management > features (ex: automatic message filtering using Baysean > classification, better search and tagging...etc)
I think that interesting information was posted on the various blogs, wikis etc. My position is, that in my opinion TB lacks a clear vision, road map and plan. How can one know what would be good for TB (generally) if one doesn't know in which direction it should go? At least it's been very unclear for me. Therefore decisions have to be made, in which direction TB should go. Once this is clear, a decision about which organizational changes should be performed will be much easier...Currently it's more like shooting from the hip...
> Also, I'd like to ask if this is the final place for discussing the > roadmap or if we should move to the dev@openoffice list as schmidtm524 > suggested :)
Anybody is free to fork Thunderbird or other Mozilla code. However I'm here as a part of the Mozilla community and I guess that will stay that way ;-)
> I think that interesting information was posted on the various blogs, > wikis etc. My position is, that in my opinion TB lacks a clear vision, > road map and plan. How can one know what would be good for TB > (generally) if one doesn't know in which direction it should go? At > least it's been very unclear for me. Therefore decisions have to be > made, in which direction TB should go
I agree. Part of the criteria for picking direction is the type of user thunderbird should best target. Is it the corporate user or individual ? casual user or the mega communicator? Blackberry addicts? A usage model that spans more than one of those?
I believe thinking about this could be useful when selecting a direction for the project. My own needs are inclined towards the "professional communicator" persona..the developer/manager/writer who uses mail to organize his/ her work and life. Of course, I don't insist on specifically targeting that model, but it tends to influence my goals for TB.
> Anybody is free to fork Thunderbird or other Mozilla code. However I'm > here as a part of the Mozilla community and I guess that will stay that > way ;-)
This is what I think too, however at some time in the future I'd like to have integration with lots of major software and tools, including OOO & others.
Mohamed Samy wrote: >> Therefore decisions have to be >> made, in which direction TB should go
> I agree. Part of the criteria for picking direction is the type of > user thunderbird should best target. > Is it the corporate user or individual ? casual user or the mega > communicator? Blackberry addicts? A usage model that spans more than > one of those?
Most likely...TB for mobiles aka minimo is just another one perhaps, support for SMS including. But from judging from the many posts I read, the corporate enterprise is on target...
> I believe thinking about this could be useful when selecting a > direction for the project. > My own needs are inclined towards the "professional communicator" > persona..the developer/manager/writer who uses mail to organize his/ > her work and life.
Right! It's less the "Flock for Flickr" type and hype what we need perhaps, but solid support to get some work done efficiently. That's also where a market exists...
>> Anybody is free to fork Thunderbird or other Mozilla code. However I'm >> here as a part of the Mozilla community and I guess that will stay that >> way ;-)
> This is what I think too, however at some time in the future I'd like > to have integration with lots of major software and tools, including > OOO & others.
When thinking about it, I guess that's just by executing another application. Personally I don't think it has to be tied into openoffice.org but obviously if one uses openoffice than they just might complete each other. That's about the only connection I see between the two...
Mohamed Samy wrote: > Given such a situation, Mozilla could either: > 1- Give small resources to TB since it's a superb product but not > really influential. Hence the various options.
> 2- Try to make it more than it currently is. Not just in terms of > features but in terms of influence and perhaps "platformness". Hence > the call to action and all the discussion :)
Right! Therefore I suggest we start working on the various information and ideas posted to the various blogs, wikis and here. Perhaps each of us take a segment, for example the blog of Mitchell, the blog of Scott, the Wiki etc...and compile a list of feature requests, ideas, possible targets and revenue models.
Afterwards I'll compile a report based on your and my findings which can help all of Mozilla to come to a decision. I'd suggest to deliver this report to the management of MoCo and MoFo. The report shouldn't be biased and currently I want to see the actual results of such a report before even thinking about any recommendation. Who knows, if in the end we don't come to similar conclusions as Mitchell?
>> Given such a situation, Mozilla could either: >> 1- Give small resources to TB since it's a superb product but not >> really influential. Hence the various options.
>> 2- Try to make it more than it currently is. Not just in terms of >> features but in terms of influence and perhaps "platformness". Hence >> the call to action and all the discussion :)
> Right! Therefore I suggest we start working on the various information > and ideas posted to the various blogs, wikis and here. Perhaps each of > us take a segment, for example the blog of Mitchell, the blog of Scott, > the Wiki etc...and compile a list of feature requests, ideas, possible > targets and revenue models.
> Afterwards I'll compile a report based on your and my findings which can > help all of Mozilla to come to a decision. I'd suggest to deliver this > report to the management of MoCo and MoFo. The report shouldn't be > biased and currently I want to see the actual results of such a report > before even thinking about any recommendation. Who knows, if in the end > we don't come to similar conclusions as Mitchell?
> Anyone willing to help - step forward ;-)
I am going to jump in here with some comments from my perspective as a "Personal User" who has been a volunteer tester and doing User-2-User support for years. At the beginning of the Tb project it already was a solid POP3 mail and basic NNTP reader application. We were told it was an experiment to test development of an application with the new XUL language. In that respect I think Tb is very successful. When Tb began development it inherited a lot of bugs from the suite, some that continue to plague user acceptance. To get some of the old problems cleared up, Tb is going to need more freedom to declare its needs. The seven year old simple composer has got to be modernized to be a CSS and XML compliant "HTML" markup generator. This is very important if the target market is determined to be Commercial users. At the same time it will draw a lot of "Personal Users" who are firmly seated in the OE camp because of it simple ease of generating stationary.
I believe Tb does have "Platform" potential drawn from the same source as Fx. That is the Gecko backend which has shown great flexibility to power applications. Currently there are two projects related to Tb that need support because they fit with a Tb Platform model. The Sunbird Calendar and the Tb/Lightning calendar integration projects have a better fit with Tb than Fx as a platform. Calendar support would improve usability for corporate environments.
However, Tb needs more to fulfill it's platform potential. While Tb has an address book, it falls short of it's "Platform" potential by not being integrated with Sunbird, or capable of being launched independently from the desktop. Currently I use the CardFile applet from Windows 3.1 as a free standing address book because of it's high level of security. I have rejected the Windows Address Book application that is inter operable with OE, Office, etc. because it has been exploited too often in the past.
Some responders have declared that addition of server less messaging such as AOL AIM, etc. as a fit with Tb. Netscape was doing just that with Navigator 6 & 7, just as the old Netscape Corp. added AIM to Communicator 4.x. I would endorse this as an add-on for those needing the functionality.
Next action I favor is stripping the RSS function out. I believe that fits far better with the Fx platform and reduces code management for Tb thereby resourcing the features that fit the Tb "Platform" model.
-- Ron K. Don't be a fonted, it's just type casting
Ron K. wrote: > Next action I favor is stripping the RSS function out. I believe that > fits far better with the Fx platform and reduces code management for Tb > thereby resourcing the features that fit the Tb "Platform" model.
I agreed with everything you wrote except that. Apart from the outstanding 'rss duplication' bug, I *love* the way thunderbird handles RSS. Thunderbird is my "Push" client - anything that gets 'pushed' to be, be it email, rss feeds or newsgroups, I view with it. A Browser is a 'pull' client, and RSS doesn't belong there (IMO).
On 7/30/2007 10:27 PM, Thunderbird leader Bed by teletype announced:
> Ron K. wrote:
>> Next action I favor is stripping the RSS function out. I believe that >> fits far better with the Fx platform and reduces code management for Tb >> thereby resourcing the features that fit the Tb "Platform" model.
> I agreed with everything you wrote except that. Apart from the > outstanding 'rss duplication' bug, I *love* the way thunderbird handles > RSS. Thunderbird is my "Push" client - anything that gets 'pushed' to > be, be it email, rss feeds or newsgroups, I view with it. A Browser is a > 'pull' client, and RSS doesn't belong there (IMO).
When I gave the RSS feature a check out I found it to be very inefficient compared to having a live bookmark on my Fx personal toolbar. Now it is possible that the feed I set up, Gervase Markham's blog, may have been a poor test choice. I disliked having to dig into the folder pane to open the RSS folder to see what was available. At the time I thought the available extensions filled the feature gap. I did not see a need for it to be mainlined and shipped to every one.
Perhaps the tab concept proposed for Tb could deal with this by putting the RSS into it's own tab.
-- Ron K. Don't be a fonted, it's just type casting
Ron K. wrote: > On 7/30/2007 10:27 PM, Thunderbird leader Bed by teletype announced: > toolbar. Now it is possible that the feed I set up, Gervase Markham's > blog, may have been a poor test choice. I disliked having to dig into > the folder pane to open the RSS folder to see what was available. At > the time I thought the available extensions filled the feature gap. I > did not see a need for it to be mainlined and shipped to every one.
> Perhaps the tab concept proposed for Tb could deal with this by putting > the RSS into it's own tab.
If I only had one or two feeds I wanted to keep track of, then any feed reader is irrelevant. I have about 50 feeds, organised into folders. I use the 'Additional Folder View' extension to keep a list of unread folders all the time - since I only want to view a site's feed when there's new content this means I'm notified of new articles without having to open any folders to see what's available. Having all new unread 'push' items viewable in the one location (my unread folders view) is the key why TB is my one-stop push client.
> how my time was spent: > # non-coding activities - 50% > # bug fixing - 40% > # new features - 10%
> My hope is that there's a lot of leverage in helping contributors and extension writers, > so I try to spend as much time as possible doing that. > Opinions always vary on how time should be allocated. I'm interested to hear what other > folks think.
Hi David, thanks for opening the discussion here too. You and Scott and the contributing Community need to discuss, to get TB moved on.
Personally I think this time relation was ok to get a quality approved TB 2.0.0.5 out. But for the actual situation and to fulfill the needs to get TB pushed within the next few months under a watched environment by Mozialla, I suggest to define this as a wrong percentage. You are paid to much, to answer community questions on XUL.
Any new application gets someday interest and many wishes, many not needed features and bugs are found. But to find more users, new features need to be added.. now: soon and quick and dirty done.
So please, you both need to code and not to discuss or manage the community, mailinglists or financial things.
- coding for new features: 80% - bug fixing: 15 % - Non coding-activities: 5 %
If you both focus on that for the next 5 months, we get a nice christmas present, TB 2.6 with instant messaging. 230 Million Skype users... and we need that messenger market as well for TB. (not Skype and AOl, as they are serverbased).
>> I'm looking forward to contributing to the Thunderbird project. :) > That's great! Usually a good way to start is to find a bug or little > feature you want to add and work on that.
Think it would be useful, if it is declared, how to enhance the GUI of Thunderbird, to get new tabs and Im and so on into it and to invest on the new interface. Here giving coding help may be useful, especially how to relate the retroshare core to Thunderbird.
Can we agree on the retroshare IM protocol to be added? Would like to get a conclusion and commitment here as one point of the roadmap. Sameplace.cc offers all the other and could be bundled to the installer if wished.
See the mail towards the suggestion of a PGP Adressbook as a Friendslist.
maybe we can get soon the new gui (tabs) and added rs-core in? Then discussing the individual features & Functions and the more suggested roadmap containments how they interact...
The licensing of retroshare is not acceptable for Mozilla code.
Mozilla shouldn't include any P2P functionality by default.
The second cent is really just my personal opinion, but across the board, the legal implications of relaying other peoples data without knowing that you do, and knowing which data that is, is large. I would be highly suspicious about the implications in Germany, at least, other legal systems may be better or worse, the German one is sure getting worse, and directly and on purpose targets systems like retroshare.
I'm all good with having functionality like that in extensions, don't get me wrong, but as default functionality, hell no.
Michael Schmidt wrote: > <http://blog.mozilla.com/bienvenu> wrote: >> how my time was spent: >> # non-coding activities - 50% >> # bug fixing - 40% >> # new features - 10%
>> My hope is that there's a lot of leverage in helping contributors and extension writers, >> so I try to spend as much time as possible doing that. >> Opinions always vary on how time should be allocated. I'm interested to hear what other > folks think.
> Hi David, > thanks for opening the discussion here too. > You and Scott and the contributing Community need to discuss, to get > TB moved on.
> Personally I think this time relation was ok to get a quality approved > TB 2.0.0.5 out. > But for the actual situation and to fulfill the needs to get TB pushed > within the next few months under a watched environment by Mozialla, I > suggest to define this as a wrong percentage. You are paid to much, to > answer community questions on XUL.
> Any new application gets someday interest and many wishes, many not > needed features and > bugs are found. But to find more users, new features need to be > added.. now: soon and quick and dirty done.
> So please, you both need to code and not to discuss or manage the > community, mailinglists or financial things.
> - coding for new features: 80% > - bug fixing: 15 % > - Non coding-activities: 5 %
> If you both focus on that for the next 5 months, we get a nice > christmas present, TB 2.6 with instant messaging. 230 Million Skype > users... and we need that messenger market as well for TB. (not Skype > and AOl, as they are serverbased).
>>> I'm looking forward to contributing to the Thunderbird project. :)
>> That's great! Usually a good way to start is to find a bug or little >> feature you want to add and work on that.
> Think it would be useful, if it is declared, how to enhance the GUI of > Thunderbird, to get new tabs and Im and so on into it and to invest on > the new interface. > Here giving coding help may be useful, especially how to relate the > retroshare core to Thunderbird.
> Can we agree on the retroshare IM protocol to be added? > Would like to get a conclusion and commitment here as one point of the roadmap. > Sameplace.cc offers all the other and could be bundled to the > installer if wished.
> See the mail towards the suggestion of a PGP Adressbook as a Friendslist.
> maybe we can get soon the new gui (tabs) and added rs-core in? > Then discussing the individual features & Functions and the more > suggested roadmap containments how they interact...
Nobody hasn't committed to anything yet! We don't even know, where TB will be in a month from now...And Eddy hasn't started coding anything yet! Not even close to it...please stay on the record, thanks!
> The licensing of retroshare is not acceptable for Mozilla code.
> Mozilla shouldn't include any P2P functionality by default.
> The second cent is really just my personal opinion, but across the > board, the legal implications of relaying other peoples data without > knowing that you do, and knowing which data that is, is large. I would > be highly suspicious about the implications in Germany, at least, other > legal systems may be better or worse, the German one is sure getting > worse, and directly and on purpose targets systems like retroshare.
> I'm all good with having functionality like that in extensions, don't > get me wrong, but as default functionality, hell no.
> The licensing of retroshare is not acceptable for Mozilla code.
Retroshare is GPL, the XPGP is a modified Open SSL and causes maybe a discussion. The License of PGPME I dunno atm, is to proove. anyone?
> Mozilla shouldn't include any P2P functionality by default.
there is no P2P in. Only a DHT to discover the IP adress of the buddy in the next online session. If you do not like this easy service, you can disable it and "@"-email in every session your IP adress to all your buddies. Or use a stable IP and Dyndns was in and could be reactivated. So there is no data forwarding or something, it is only the bootstrap mechanism to get updated Ip adresses of the guid-number of your friend.
So where is the problem? There is nothing about p2p in it, Email is peer-to-peer as well (over a mailhost).
> Right! Therefore I suggest we start working on the various information > and ideas posted to the various blogs, wikis and here. Perhaps each of > us take a segment, for example the blog of Mitchell, the blog of Scott, > the Wiki etc...and compile a list of feature requests, ideas, possible > targets and revenue models.
> Anyone willing to help - step forward ;-)
Have you, or anyone else started with this? I could take the wikis and this discussion group and summarize the various ideas. I'll do my best starting from today.
Speaking of ideas, there have been a lot of suggestions on what exacly to add to the basic email capabilities of TB. Thinking about the "platform" aspect of TB, we could possibly do a lot of stuff as add- ins and focus on making TB a strong host for those add-ins.
Basically two types of add-ins would be created: user add-ins and system add-ins. The system add-ins would provide support for whatever protocols that interest the user, whether it's mail, chat, RetroShare,RSS,iCalendar or whatever. The user add-ins would provide ways the user does his/her work, it could provide search, visualization, real time notifiers or anyting the user needs.
All this would be backed by a database (mozStorage?), XUL+Javascript GUI,and strong API's. this would be "The platform".
> Have you, or anyone else started with this? I could take the wikis and > this discussion group and summarize the various ideas. > I'll do my best starting from today.
Great! All the Mozilla wiki comments are for you. Can you sumarize in short references and send it to me?
> Speaking of ideas, there have been a lot of suggestions on what exacly > to add to the basic email capabilities of TB. Thinking about the > "platform" aspect of TB, we could possibly do a lot of stuff as add- > ins and focus on making TB a strong host for those add-ins.
Which doesn't require anything special even today. However integration of certain features require perhaps special attention, specially what the UI concerns.
> Basically two types of add-ins would be created: user add-ins and > system add-ins. The system add-ins would provide support for whatever > protocols that interest the user, whether it's mail, chat, > RetroShare,RSS,iCalendar or whatever. The user add-ins would provide > ways the user does his/her work, it could provide search, > visualization, real time notifiers or anyting the user needs.
I guess that once we'll have a clear view on which direction TB should go, this will be answered by itself. I suggest TBs road map is not about extensions (since they exist today in that or other form) but what its default capabilities should be and what it will offer to the individual/corporation.
>> Right! Therefore I suggest we start working on the various information >> and ideas posted to the various blogs, wikis and here. Perhaps each of >> us take a segment, for example the blog of Mitchell, the blog of Scott, >> the Wiki etc...and compile a list of feature requests, ideas, possible >> targets and revenue models.
>> Anyone willing to help - step forward ;-)
> Have you, or anyone else started with this? I could take the wikis and > this discussion group and summarize the various ideas. > I'll do my best starting from today.
> Speaking of ideas, there have been a lot of suggestions on what exacly > to add to the basic email capabilities of TB. Thinking about the > "platform" aspect of TB, we could possibly do a lot of stuff as add- > ins and focus on making TB a strong host for those add-ins.
> Basically two types of add-ins would be created: user add-ins and > system add-ins. The system add-ins would provide support for whatever > protocols that interest the user, whether it's mail, chat, > RetroShare,RSS,iCalendar or whatever. The user add-ins would provide > ways the user does his/her work, it could provide search, > visualization, real time notifiers or anyting the user needs.
> All this would be backed by a database (mozStorage?), XUL+Javascript > GUI,and strong API's. this would be "The platform".
> just an idea I wanted to toss around.
> Mohamed
I am another proponent of the "Platform" model. I have already outlined my views on LDAP as a method to share address data between Gecko based applications and applets. The iCalendar idea is already in the works in two forms. Sunbird a stand alone calendar application running on Gecko, and the Thunderbird Lightning project that is integrating the Sunbird core code into Thunderbird. Thunderbird does have RSS support built in and it could use a fresh review for enhancements.
As for Chat, there is the Chatzilla IRC client that works with Firefox. That would be a good candidate for the system add-in concept. It has a solid code base built to run on Gecko in either a Fx tab or separate window. Another area of possibility is protocol support for streaming protocols for podcasts. This comes to mind from a couple of RSS feeds I used to have in Fx on another system. The feed I remember was Mozilla oriented and had a podcast option available.
Scott MacGregor floated an interesting idea to capitalize on the new Tag feature. He described it as a Tag Cloud. If you have visited the Flicker photo site you would have seen how they use a tag cloud. Only here for Tb it could be a way to organize mail messages.
Right now Tb needs eyes reading comments where ever they get posted, then feeding summaries back to this group.
-- Ron K. Don't be a fonted, it's just type casting
>> Right! Therefore I suggest we start working on the various information >> and ideas posted to the various blogs, wikis and here. Perhaps each of >> us take a segment, for example the blog of Mitchell, the blog of Scott, >> the Wiki etc...and compile a list of feature requests, ideas, possible >> targets and revenue models.
>> Anyone willing to help - step forward ;-)
> Have you, or anyone else started with this? I could take the wikis and > this discussion group and summarize the various ideas. > I'll do my best starting from today.
> Speaking of ideas, there have been a lot of suggestions on what exacly > to add to the basic email capabilities of TB. Thinking about the > "platform" aspect of TB, we could possibly do a lot of stuff as add- > ins and focus on making TB a strong host for those add-ins.
> Basically two types of add-ins would be created: user add-ins and > system add-ins. The system add-ins would provide support for whatever > protocols that interest the user, whether it's mail, chat, > RetroShare,RSS,iCalendar or whatever. The user add-ins would provide > ways the user does his/her work, it could provide search, > visualization, real time notifiers or anyting the user needs.
> All this would be backed by a database (mozStorage?), XUL+Javascript > GUI,and strong API's. this would be "The platform".
> just an idea I wanted to toss around.
I think that the concept of finding out the right APIs to create extensions for 'insert your favorite' is exactly the way to go.
One thing that we have for Firefox now, and not for Thunderbird, too, is FUEL. I'd call the Thunderbird part THULE, 'thunderbird utility library for extension developers' or so. Or, with pictures, your safe place in rough seas, http://en.wikipedia.org/wiki/Thule_Air_Base. For those of us crossing the Atlantic by plane on a regular basis :-).
> Great! All the Mozilla wiki comments are for you. Can you sumarize in > short references and send it to me?
Will do! I'll try to send it by tomorrow or so if everything goes well (I'm going to RSI therapy now and may have trouble typing in the immediate future).
> I guess that once we'll have a clear view on which direction TB should > go, this will be answered by itself. I suggest TBs road map is not about > extensions (since they exist today in that or other form) but what its > default capabilities should be and what it will offer to the > individual/corporation.
I was thinking of going beyond the normal add-ins and change TB to make it support not only mail-type capabilities but to be able to support any type of communication oriented application, now or in the future( and of course, the most important applications that fit with TB's decided direction would be already built in).
True the current architecture is capable of much of that already, but I wanted to suggest more strategic focus on this area, as a small example by adding a real database instead of the current mailbox format..etc
By the way, I'm happy that the ideas of tabs and "tag cloud" have been put on the table. When I was thinking about the design of TB I wanted them too :)
Tags in particular play a big role in my imagined "ideal Thunderbird" concept, as part of an overall system that helps the user organize all his/her messages and information.
> One thing that we have for Firefox now, and not for Thunderbird, too, > is FUEL. I'd call the Thunderbird part THULE, 'thunderbird utility > library for extension developers' or so.
That's also something Scott and I have been interested in. But with our limited resources, blah blah blah.
Very scary. The message composition and sending code has always been the scariest code in mail&news, even back in the Netscape 2 days. Perhaps exposing something similar in scope to the Simple MAPI API in a cross-platform way would make it easier. MAPI's not pretty, but it's a lot simpler.
> Will do! I'll try to send it by tomorrow or so if everything goes > well (I'm going to RSI therapy now and may have trouble typing in the > immediate future).
I'll try to summarize the blog of Mitchell and Gerv. Perhaps somebody wants to check the blog of Scott? Are there any other blogs or places with postings of ideas and suggestions? Does anybody want to summarize the ideas posted to the mailing list(s) so far? Please also include ideas for revenues and targets, not only feature requests.
I hope we can get something useful together within the next few days.
>> Will do! I'll try to send it by tomorrow or so if everything goes >> well (I'm going to RSI therapy now and may have trouble typing in the >> immediate future).
> I'll try to summarize the blog of Mitchell and Gerv. Perhaps somebody > wants to check the blog of Scott? Are there any other blogs or places > with postings of ideas and suggestions? Does anybody want to summarize > the ideas posted to the mailing list(s) so far? Please also include > ideas for revenues and targets, not only feature requests.
> I hope we can get something useful together within the next few days.
Yes, I have an account at wiki.mozilla.org where Scott MacGregor has opened some Wiki articles. I know one of them that I commented on is relevant to our fact finding. That topic is on improving the add-on installation method. Any other guidance for when I begin digging in the Wiki?
-- Ron K. Don't be a fonted, it's just type casting
> Yes, I have an account at wiki.mozilla.org where Scott MacGregor has > opened some Wiki articles. I know one of them that I commented on is > relevant to our fact finding. > That topic is on improving the add-on installation method. Any other > guidance for when I begin digging in the Wiki?
What we want as a first step is to gather all the information posted to the various places in a summarized form. It will help us to analyze what people had to say (minus the Google rants) and hopefully give us direction for Thunderbird. Next we'll compile a report and hopefully some recommendations, which might include organizational changes and what else would be required for TB. As Mitchell said in her Call for Action and successive postings, that there are funds, there might be ways, we need a vision and please convince me! ;-)
Perhaps ping Mohamed about the wiki entries you found, since he took the wikis already. Maybe you want to summarize postings made to Scott's blog? There are other blogs as well which need attention?
|
