SPAM regression testing
Kent James
processing issues discussed in
http://wiki.mozilla.org/Thunderbird:SummerOfCode2006:SPAM
Right now, I have the ability to read in the TREC 2005 Spam corpus, and
process it through the TB junk mail processing. This is done using a TB
extension. Soon though I'll need to customize the C++ code so that I can
get to the junkscore, which I will need to develop ROC curves for the
filter.
In the short run, the main issues I am interested in implementing are
token pruning, and improved tokenization. Regression testing is a key
piece of any attempt to improve the spam filtering.
David Ascher
> 2) It really takes dedicated effort in TB to train routinely on ham,
> but really the main value of a local spam filter is the
> characterization of ham. Junk is common over many users, but each
> person has their own unique ham signature. Some methods need to be
> developed to automatically do this. Maybe, for example, we could
> consider each message ham that the user replies to.
I like that. I'd also suggest that senders to whom one replies should
probably be special-cased in the addressbook as well. They're likely to
be special. It might even make sense to consider some whitelisting hints.
> 3) There are now multiple text characterization schemes (starred,
> junk/nonjunk, tags) that could be unified into a single system, with
> possible benefits such as expanding Bayesian analysis to determination
> of tags for example (to say nothing of much-needed refactoring).
Agreed.
> 4) As I mentioned on another list, centralized reporting of spam from
> TB users would go a long way toward improving spam filter performance.
> Recent work such as http://www.ceas.cc/2007/papers/paper-74.pdf show
> how important that is. Local Bayes analysis is only going to be able
> to effectively reject about 90% of spam (plus or minus 5%). To get to
> the 99.5% rejection that we really need, requires interactions with
> other users.
Where was that other list? I'd love to brainstorm about ways that
MailCo/Mozilla could facilitate such a collaborative system.
--david
David Ascher
>
> David Ascher wrote:
>> Where was that other list? I'd love to brainstorm about ways that
>> MailCo/Mozilla could facilitate such a collaborative system.
>>
>> --david
>>
>
> https://labs.mozilla.com/forum/index.php/topic,334.0.html
Ah, right. Yes, I haven't been hanging out on the forums enough.
I've just posted a followup on that thread, FYI.
> Anything that you could do to build some community brainstorming would
> be welcome. I've never really figured out how to do that productively
> in the TB environment. It really is sorely needed.
I'm hoping to find the time and mental space to start organizing some of
the wiki pages to facilitate just that. I find wikis tend to elicit
slightly less negative energy than discussion lists/fora, and they
"remember" better. At the same time, it's hard to build energy in a wiki.
I know, we should build a new communication/collaboration tool =).
Kidding aside: I'm slightly jealous of people who get to use tools like
Campfire, which has the interactivity of IRC, but also more
institutional memory and better usability for non-simultaneous users.
If anyone knows of technology which could help bring those things to
IRC, let me know.
In the short term, however, I'm happy to use a combined approach of some
wiki pages, and an associated IRC channel that didn't get in the way of
either the support discussions on #thunderbird or the very pragmatic
stuff going on in #maildev.
--david
Eddy Nigg (StartCom Ltd.)
> In the short term, however, I'm happy to use a combined approach of some
> wiki pages, and an associated IRC channel that didn't get in the way of
> either the support discussions on #thunderbird or the very pragmatic
> stuff going on in #maildev.
not remain that "pragmatic"...maybe somebody has to start putting some
fire (speak positive energy) into this place? Just my two cents...
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Kent James
> I find wikis tend to elicit
> slightly less negative energy than discussion lists/fora, and they
> "remember" better. At the same time, it's hard to build energy in a wiki.
>
>
If I look at the wiki page
http://wiki.mozilla.org/Thunderbird:2.0_Product_Planning there are lots
of discussion comments there. But it is still just a long list of
features that people would want added, and not really any kind of firm
discussion of what will or will not be done. In that since, it
duplicates bugzilla. As you say, no energy. Also, I can't easily tell
who is making what comment. Authority of the poster matters a lot in
public places.
Really right now there are too many places to discuss things, not too
few. We have David Ascher's blog comments, new Mozilla lab forums,
bugzilla, mozilla wikis, mozillazine forums, and perhaps other that I am
not aware of (there must be some irc channel as well). Even you (David)
are not reliably monitoring the forums that you yourself setup for the
purpose of discussing Thunderbird!
For the discussions to work, it is important that the movers and shakers
are clearly present and participating in the discussions. I find this
forum (mozilla.dev.apps.thunderbird) to be the most reliable place where
names of people that I recognize as active will routine participate. Why
not just start here? I guess I'm seconding Eddy Nigg's posting. Let's
inject some positive energy into this forum.
rkentjames
David Ascher
> David Ascher wrote:
>> In the short term, however, I'm happy to use a combined approach of some
>> wiki pages, and an associated IRC channel that didn't get in the way of
>> either the support discussions on #thunderbird or the very pragmatic
>> stuff going on in #maildev.
> Well, once something interesting gets going, I guess that this list
> will not remain that "pragmatic"...maybe somebody has to start putting
> some fire (speak positive energy) into this place? Just my two cents...
This place here feels more quiet than pragmatic =).
Message received, though. I haven't spammed this newsgroup because I do
feel like a recent immigrant, and I'm learning the local customs.
I'll throw ideas here, see what happens to them.
--david
Ron K.
David, For an add-in to Fx and Tb for IM/Chat there is Same Place that
uses the Jabber/XMPP protocols. Permits cut & paste of content like a
white board and there is an option for remote annotation. No idea what
Campfire is, so can not draw a contrast.
Wiki is nice for being a collaborative editing medium with persistence
bordering on permanence. A Wiki is clearly deliberative and a bit
intimidating. Obviously not free wheeling like NNTP, where I prefer a
server with a 14 day retention and no propagation to Google Groups. I
view group brainstorming to be a group conversation that should stay
within the circle of subscribed participants. I do not want my ideas
being harvested from an archive by an outsider.
I have a dislike for Web Forum sites. They are slow, and lack tight
threading and ease of branch visualizing which I like about news. I have
used Mozillazine Forums, mostly when that was the only official site for
reporting Tb bugs, before Bugzilla use was authorized to receive reports
from Tb alpha testers.
Personally I see no reason why MailCo should not set up its own NNTP and
XMPP IM/Chat servers.
--
Ron K.
Who is General Failure, and why is he searching my HDD?
Kernel Restore reported BSOD use by Major Error to msg the enemy!
Ron K.
Yes, we are fragmented in part because I view the Tb community has been
forced to adapt to the Firefox business model. Having worked with Eddy
on a report in August, I am familiar with his enthusiasm. My
recommendation to David A. is to say "These are the places we will do
business" because I feel MailCo needs to flesh out it's identity and
community. I pointed out to David that Same Place is a Jabber IM/IRC
solution that has presence so we can see at a glance who is busy, away,
or available. It is both Fx and Tb 2.0+ compatible. Nit is it lacks
persistance.
Kent James
>
> David, For an add-in to Fx and Tb for IM/Chat there is Same Place that
> uses the Jabber/XMPP protocols. Permits cut & paste of content like a
> white board and there is an option for remote annotation. No idea what
> Campfire is, so can not draw a contrast.
>
That brings up a question I have had for a long time. Is there any
process or philosophy by which add-ins get incorporated into the main
code? Philosophies like, "we want the minimum base program, with most
new features as add-ins" Or, "we want a full-featured product, and will
merge quality add-ins into the trunk."
What I might propose as a compromise is that TB agree on certain add-ins
that will be fully supported (translated, kept updated). As part of TB
installation, the user would select which to include. That would provide
a compromise between bloat and feature set.
Kent
Ron K.
> David Ascher wrote:
>> In the short term, however, I'm happy to use a combined approach of
>> some wiki pages, and an associated IRC channel that didn't get in the
>> way of either the support discussions on #thunderbird or the very
>> pragmatic stuff going on in #maildev.
> Well, once something interesting gets going, I guess that this list
> will not remain that "pragmatic"...maybe somebody has to start putting
> some fire (speak positive energy) into this place? Just my two cents...
>
Hello Eddie. I did get my Vista box activated, so I am a happy camper
now that I dropped 2GB of RAM into it.
Ron K.
One thing I like is to hear from my leadership once in a while. Builds
moral and community. Actually I am hoping MailCo could set some of it's
own customs. We work in a different culture where direct
person-to-person communication is the name of the game.
David Ascher
> Really right now there are too many places to discuss things, not too
> few. We have David Ascher's blog comments, new Mozilla lab forums,
> bugzilla, mozilla wikis, mozillazine forums, and perhaps other that I am
> not aware of (there must be some irc channel as well). Even you (David)
> are not reliably monitoring the forums that you yourself setup for the
> purpose of discussing Thunderbird!
>
Guilty as charged. Working on fixing it, but yes.
> For the discussions to work, it is important that the movers and shakers
> are clearly present and participating in the discussions. I find this
> forum (mozilla.dev.apps.thunderbird) to be the most reliable place where
> names of people that I recognize as active will routine participate. Why
> not just start here? I guess I'm seconding Eddy Nigg's posting. Let's
> inject some positive energy into this forum.
>
I'll try to start with a topic I was just discussing on IM which
hopefully isn't going to start a flamewar, as soon as I get a caveat out:
** I'm not setting direction here -- I'm just speaking as a thunderbird
user who would like to foster creative discussions. In particular, if
anything I say in this mode shows up in a blog as "mailco mover and
shaker thinks blah blah blah", I'll be frustrated =). **
I find the RSS UI in Thunderbird just painful enough that it stops me
everytime I want to switch to it from Shrook, which is my current RSS
reader of choice. So I've been thinking about what it could become.
There are some "obvious" problems, which I suspect are in bugzilla
already, like:
- can't actually use TB as a feed subcriber from Firefox.
- can't drag and drop URLs into the News & Blogs container to have
them added
- no auto-discovery of feeds from web page URIs
- some bugs w/ import of hierarchical OPML files (can't recall details)
- in the add dialog, there's a folder per feed, which certainly
confused me at first.
But all of those are important, but catch-up. Let's maybe talk a bit
about how we could take it beyond the current system. Here are some
thoughts:
1) There are lots of RSS readers out there, and lots of blog authoring
software, but very few integrated solutions. Thunderbird has the
capability of being both a blog reader and an authoring system in one.
In particular, we could explore ways of integrating a commenting UI in
the communications client. I'm not familiar with the state of commenting
APIs in Atom Publishing, but someone must be =)
2) If we're thinking of reviewing the marking of messages
(starred/junk/tags/priority/etc.) as you mentioned, let's think about
tagging of folders and feeds as well. One of the things I liked about
Shrook is that it has a clean UI for creating dynamic folders based on
tags, giving one the hierarchical power of folders, with the overlapping
data set of tags. I wouldnt' be surprised if that stuff was possible in
TB from an architectural POV, with some (probably significant) UI work.
3) I'd like to explore ways that we can learn from and correct some of
the weaknesses that Thunderbird inherits because it's a desktop app. In
particular, I find it frustrating that some state is held server-side,
and some is held client-side, even when using stateful serverside
systems like IMAP. I'd love to talk more about what the right
evolutionary path of Nick Kreeger's work should be. In the world of RSS
readers for example, OPML is used for data import/export, but it seems
too little -- it specifies what feeds I subscribe to, but not what
messages I've read, or which ones I think are important. It's also not
geared towards synchronization. Would it make sense to think about what
protocol should be used to synchronize client state across channels, so
that there could be a "thunderbird metadata server" which would hold all
appropriate data, from "bookmarked" rss items to address book data, etc?
-david
Ron K.
From the early 0.1alpha days my understanding was that Tb would be as
light weight as possable core, mail/news application relying on
extensions to provide features on an as needed basis. Some extension
code has been incorporated over time when there features were seen as
more core than user customization. I like that philosophy. I think a
good suite of API interfaces, that permit plug-in and add-on expansion,
will aid keeping pace with new related technologies.
My understanding is that extension/add-on projects are third party
driven. A user with expertise has an idea and builds something for
personal use and then offers it to the global user base. Has some
weakesses, like the Dev is snowed under and postpones updating his
project. One that comes to mind is Newsworthy which is still needed
with Tb 2.0 but is capped at 1.5 and lacks a needed update. However I
believe that add-on is one that needs to be rolled into Tb is the
functionality was not added to the Tb 3 future. So here is a case for
your argument for MailCo to adopt an orphaned add-on if leadership views
it as in the community's interest.
Joshua Cranmer
> Kent James wrote:
>> Anything that you could do to build some community brainstorming would
>> be welcome. I've never really figured out how to do that productively
>> in the TB environment. It really is sorely needed.
> I'm hoping to find the time and mental space to start organizing some of
> the wiki pages to facilitate just that. I find wikis tend to elicit
> slightly less negative energy than discussion lists/fora, and they
> "remember" better. At the same time, it's hard to build energy in a wiki.
>
> I know, we should build a new communication/collaboration tool =).
> Kidding aside: I'm slightly jealous of people who get to use tools like
> Campfire, which has the interactivity of IRC, but also more
> institutional memory and better usability for non-simultaneous users.
> If anyone knows of technology which could help bring those things to
> IRC, let me know.
>
> In the short term, however, I'm happy to use a combined approach of some
> wiki pages, and an associated IRC channel that didn't get in the way of
> either the support discussions on #thunderbird or the very pragmatic
> stuff going on in #maildev.
>
> --david
>
My opinion on the various means of discussion:
Wiki: Ideal for information /a posteriori/; notification of updates is
haphazard and clumsy at best, impossible at worst, so a good
communication via this means wouldn't work very well.
Web forum: Once again, update notification is problematic. The best
place for these are for those who are more wary of other means for
communication (i.e., newsgroups, IRC).
IRC: Update notification is easy--but there is poor-to-nonexistent
archival ability, and being on all the time is necessary. Difficult to
have discussions, since everyone must be present for it to work, and we
have some potential time zone problems (I know of at least an 8-zone
shift...)
Newsgroup: These tend to have the best archival, and work well for
discussions. All competent newsreaders (i.e., everything not a WITUN)
show messages in a threaded hierarchy, which makes detailed discussions
easy to follow. Unfortunately, this method of communication would tend
to exclude neophytes more than others.
Mailing list: Similar in many respects to newsgroups. The largest
difference is that they come in the same stream as many other types of
messages, and require filtering. Also, joining one late makes historical
information difficult to access. Finally, it is easier to mess up a
reply (hit "Reply" instead of "Reply to All").
Bugzilla: Update notification is somewhat problematic, but is more
configurable than the Wiki/Web forum styles. Conversations persist, but
fragmented discussions can occur and become difficult to merge. Also
problematic in that searching for specific information easily fails to
often (try looking for `@page' in the quick search. It doesn't work).
Blogs: Conversation is nuanced in this format, but it is ideal for
announcements.
With respect to TB, these are my preferences:
* The wiki would be used to inform developers of extensions or as a
springboard for would-be developers of TB.
* The web forum is a support channel for people who need help with TB.
* IRC has a few channels:
@ Support, a la web forum
@ Developer information, like #developers or #maildev
@ A planning channel for when two people need to have instantaneous
communication.
* Newsgroup or mailing list (prefers newsgroup): main method of
communicating planning decisions.
* Bugzilla would be used as it is now, for detailing bugs and
works-in-progress
* Blogs would be used mostly for announcing decisions, such as
resolutions on a newsgroup/mailing list debate
* Where to put RFEs? Newsgroup (like mozilla.wishlist), Bugzilla, or Web
forum? There should be one standard place; ideally, it would be
cross-referable so that all interested parties would know about them.
With respect to IRC, perhaps we could have a configurable extension that
could store logs of rooms in a searchable-archive manner.
P.S. The TB dictionary has `unsearchable' but not `searchable'!?
Eddy Nigg (StartCom Ltd.)
>> This place here feels more quiet than pragmatic =).
>>
>> Message received, though. I haven't spammed this newsgroup because I
>> do feel like a recent immigrant, and I'm learning the local customs.
>> I'll throw ideas here, see what happens to them.
waters and it's making waves... ;-)
>
>
> One thing I like is to hear from my leadership once in a while. Builds
> moral and community. Actually I am hoping MailCo could set some of it's
> own customs. We work in a different culture where direct
> person-to-person communication is the name of the game.
>
we all know. Discussions on general issues belong to here (mailing list)
whereas communication between developers can be very dynamic (IM, phone,
mailing list or just email). Wiki is good to nail down decisions, plans,
road maps and other such stuff...and than there are the status meetings
(usually by phone) and at last but not least bugzilla...
But since you mentioned last August..what me concerns not much happened
since then. Except if there is somewhere something elsewhere
maybe....But I'd expect the crowned leader to hang out with the right
people :-\
...or is Thunderbird a ship sailing without a captain to nowhere?
Somebody knows? I don't so far....
Eddy Nigg (StartCom Ltd.)
> In
> particular, I find it frustrating that some state is held server-side,
> and some is held client-side, even when using stateful serverside
> systems like IMAP.
> Would it make sense to think about what
> protocol should be used to synchronize client state across channels, so
> that there could be a "thunderbird metadata server" which would hold all
> appropriate data, from "bookmarked" rss items to address book data, etc?
people from XMPP could help us thinking into the right directions a
little bit...
Eddy Nigg (StartCom Ltd.)
> That brings up a question I have had for a long time. Is there any
> process or philosophy by which add-ins get incorporated into the main
> code? Philosophies like, "we want the minimum base program, with most
> new features as add-ins" Or, "we want a full-featured product, and will
> merge quality add-ins into the trunk."
>
features which seem to be essential are integrated, others are excellent
add-ons (and will remain as such). But there certainly needs to be a
policy, "vision' and road map, which seems to be still lacking...
(By-note: Better heated discussions around these subjects (even
flame-wars if needed) than just void. Perhaps David and others could
outline where we are heading with the risk of opposing opinions....which
in turn could adjust the direction...
Ron K.
> David Ascher wrote:
>> In particular, I find it frustrating that some state is held
>> server-side, and some is held client-side, even when using stateful
>> serverside systems like IMAP.
> Yes, yes and yes! This is a key issue in every respect...
>> Would it make sense to think about what protocol should be used to
>> synchronize client state across channels, so that there could be a
>> "thunderbird metadata server" which would hold all appropriate data,
>> from "bookmarked" rss items to address book data, etc?
> Absolutely! I'm not sure if there is such a protocol, but I think the
> people from XMPP could help us thinking into the right directions a
> little bit...
>
Would LDAP or SQL-Lite have the flexibility and adaptability for such a
task ? The extensibility of XMPP might be an object model.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) keyboarded, On 12/13/2007 8:58 PM :
>
> task ? The extensibility of XMPP might be an object model.
>
>
Joshua Cranmer
> I'll try to start with a topic I was just discussing on IM which
> hopefully isn't going to start a flamewar, as soon as I get a caveat out:
>
> ** I'm not setting direction here -- I'm just speaking as a thunderbird
> user who would like to foster creative discussions. In particular, if
> anything I say in this mode shows up in a blog as "mailco mover and
> shaker thinks blah blah blah", I'll be frustrated =). **
And I almost always talk about everything from a developer's point of
view, or, sometimes, when I play Devil's Advocate on a topic (mostly in
relation to a development stance, though).
> I find the RSS UI in Thunderbird just painful enough that it stops me
> everytime I want to switch to it from Shrook, which is my current RSS
> reader of choice. So I've been thinking about what it could become.
>
> There are some "obvious" problems, which I suspect are in bugzilla
> already, like:
> - can't actually use TB as a feed subcriber from Firefox. - can't drag
> and drop URLs into the News & Blogs container to have them added
I found this and immediately had the "huh?" reaction.
> - in the add dialog, there's a folder per feed, which certainly
> confused me at first.
Yes, the subscribe dialog here is very confusing.
> But all of those are important, but catch-up. Let's maybe talk a bit
> about how we could take it beyond the current system. Here are some
> thoughts:
>
> 2) If we're thinking of reviewing the marking of messages
> (starred/junk/tags/priority/etc.) as you mentioned, let's think about
> tagging of folders and feeds as well. One of the things I liked about
> Shrook is that it has a clean UI for creating dynamic folders based on
> tags, giving one the hierarchical power of folders, with the overlapping
> data set of tags. I wouldnt' be surprised if that stuff was possible in
> TB from an architectural POV, with some (probably significant) UI work.
The account/folder/element is, IMHO, a mess right now. I tend to prefer
Outlook's style somewhat, in that it is the folder that has the
intrinsic type information (e.g., task list, message folder) in some
cases, and not the account. I am envisioning a pseudo-server that might
mix a blog feed with a newsgroup and a POP folder; that would certainly
help organization.
That said, the primary problem, as I see it, is that large parts of code
are in need of an overhaul in the APIs and cross-object coordination; I
expect some of that may come through in the near future with my
implementation of bug 11050, but the account manager is not part of that...
David Ascher
> The account/folder/element is, IMHO, a mess right now. I tend to prefer
> Outlook's style somewhat, in that it is the folder that has the
> intrinsic type information (e.g., task list, message folder) in some
> cases, and not the account. I am envisioning a pseudo-server that might
> mix a blog feed with a newsgroup and a POP folder; that would certainly
> help organization.
>
> That said, the primary problem, as I see it, is that large parts of code
> are in need of an overhaul in the APIs and cross-object coordination; I
> expect some of that may come through in the near future with my
> implementation of bug 11050, but the account manager is not part of that...
>
certainly sometimes refactoring can be done in absence of specific
features. Still, it'd be good to know where we're heading.
For example, I know that some wanted to be able to merge event info and
mail info, and that right now that's (unsurprisingly) hard. Figuring
out what the right data model is is a lot easier if we think about what
uses we want to allow.
--david
David Ascher
> since then. Except if there is somewhere something elsewhere
> maybe....But I'd expect the crowned leader to hang out with the right
> people :-\
>
> ...or is Thunderbird a ship sailing without a captain to nowhere?
> Somebody knows? I don't so far....
>
I can appreciate that people are impatient and want to see a plan in
place now. At the same time, I know that a deliberative and
collaborative process is a lot more likely to build a true community
with a shared goal than if I just dumped by raw thoughts and declared
them policy.
So please be patient -- feel free to poke me as often as you need, though.
I'll contribute more on this newsgroup, and we'll see how things evolve.
--david
David Ascher
> From the early 0.1alpha days my understanding was that Tb would be as
> light weight as possable core, mail/news application relying on
> extensions to provide features on an as needed basis. Some extension
> code has been incorporated over time when there features were seen as
> more core than user customization. I like that philosophy. I think a
> good suite of API interfaces, that permit plug-in and add-on expansion,
> will aid keeping pace with new related technologies.
>
Roughly, I agree.
I phrase the choice of what goes in the product vs. what should be an
extension slightly differently. In my mind, the core product should
provide that magical, subjective, and elusive blend of features which
provides the best experience for the largest number of people possible.
Add-ons then provide a wonderful vehicle for providing additional bits
that either don't provide enough value yet -- for example features that
aren't quite polished enough yet -- or to enough people -- because
different people have different needs.
The distinction is important. In particular, I don't subscribe to the
notion of Thunderbird being defined as "the most lightweight mail/news
client possible, with some extensions available". I think it's more
complicated and changing than that.
As an example, every interaction I have with "real users" who aren't in
the inner circles of Thunderbird development get very agitated at the
lack of any scheduling capability within Thunderbird. To what feels
like a _large_ number of people, calendaring functions are much, much
more important than, say, news reading or RSS integration, or LDAP
integration. Which isn't to say that I want to take those features out,
just that the blend of what features belong in a client like Thunderbird
is subject to reconsideration as things change -- as technologies
available change, as adoption of different technologies change, as
people's habits change. I also think that we can lead, not just follow
well established trends.
It would be a shame to look back on Thunderbird in ten years and see a
piece of software that lost a chance at having huge impact because it
didn't know how to evolve. There is _huge_ opportunity for Thunderbird
to become more than a good mailnews client that a few million people
use. I estimate that Thunderbird is used by less than 1% of email users
-- that's *a lot* given how many resources were dedicated to it! it's
also *not enough* given what we could and should do.
I believe that if we figure out together where we want to go,
Thunderbird could help change the way lots and lots and LOTS of people
feel about email, communication, computer work, work in general, social
interactions, and more. We won't do that by just being a mail/news
client. We need to think of the system in a different way. We have a
mindshare and impact because of Mozilla and Firefox's success that we
should use to our best advantage. Let's not squander it.
I'm still working on how to express my hopes for Thunderbird, but
hopefully the above gives a little window into my current thoughts, and
why I took this job. I'm keen to refine how I can explain this stuff,
in particular to this group, because you are the people who will help
get this thing jump-started.
Feedback welcome!
--david
Kent James
> I believe that if we figure out together where we want to go,
> Thunderbird could help change the way lots and lots and LOTS of people
> feel about email, communication, computer work, work in general, social
> interactions, and more. We won't do that by just being a mail/news
> client.
In my comment on your blog entry at
http://ascher.ca/blog/2007/10/17/i-just-really-want-to-know-what%e2%80%99s-going-on-with-thunderbird/
I suggested that TB focus on a single Big Idea (and suggested some
possibilities), rather than try to be all things to all people. But that
would not be an easy path. Your existing users are primarily interested
in a better email client - scheduling, LDAP, RSS, HTML editing, better
search, etc, etc. Also, if you spend much time browsing bugzilla you
will see many bugs that really should have been fixed a long time ago
that are still out there. So there is a long grind of incremental
improvement to existing features, along with bug fixes, that is clearly
the path of least resistance for moving TB forward.
Yet an open source project like TB really needs to attract developers. I
don't see the long grind as being very attractive. (Though, strangely
enough, I personally find the esoterica of spam filter token pruning as
an interesting subject. That clearly is a "long grind" topic.) Somehow
we need to move forward on the basic improvements that the product
needs, while at the same time leaving some space to try wild-eyed,
innovative things (or to at least provide Mozilla-style open leadership
to things that everyone is talking about, like unified communication or
open social networks).
What is sorely needed, and perhaps would be well-served by a Wiki, is to
start to identify and categorize both the wild-eyed and conventional
topics so that we could perhaps congregate around areas of interest, and
maybe see what the Thunderbird forest starts to look like. Perhaps it
would then be clear if there are a few Big Ideas that could develop a
critical mass of people interested in making them happen.
- Kent
Ron K.
> Ron K. wrote:
>> From the early 0.1alpha days my understanding was that Tb would be
>> as light weight as possable core, mail/news application relying on
>> extensions to provide features on an as needed basis. Some extension
>> code has been incorporated over time when there features were seen as
>> more core than user customization. I like that philosophy. I think a
>> good suite of API interfaces, that permit plug-in and add-on
>> expansion, will aid keeping pace with new related technologies.
>>
>
> Roughly, I agree.
>
> I phrase the choice of what goes in the product vs. what should be an
> extension slightly differently. In my mind, the core product should
> provide that magical, subjective, and elusive blend of features which
> provides the best experience for the largest number of people
> possible. Add-ons then provide a wonderful vehicle for providing
> additional bits that either don't provide enough value yet -- for
> example features that aren't quite polished enough yet -- or to enough
> people -- because different people have different needs.
In my reply to Kent I boiled my perception of the philosophy expressed
4.5 years ago down to simple statements. At the time Tb was carrying
some unneeded baggage. An example was program folder file pathways
filled with empty nested folders ending with a small overlay file. That
had to be causing excessively long path strings in the code.
Progressively deadwood and unneeded baggage were pruned and Tb became
lighter thus fulfilling the "as light as possable" concept. The context
of my statement of "Features on an as needed basis" is as perceived by
third parties to bring solutions to special needs. This includes Stock
Tickers, Weather Forecast monitors, etc.
> The distinction is important. In particular, I don't subscribe to the
> notion of Thunderbird being defined as "the most lightweight mail/news
> client possible, with some extensions available". I think it's more
> complicated and changing than that.
I am very much in agreement with you.
> As an example, every interaction I have with "real users" who aren't
> in the inner circles of Thunderbird development get very agitated at
> the lack of any scheduling capability within Thunderbird. To what
> feels like a _large_ number of people, calendaring functions are much,
> much more important than, say, news reading or RSS integration, or
> LDAP integration. Which isn't to say that I want to take those
> features out, just that the blend of what features belong in a client
> like Thunderbird is subject to reconsideration as things change -- as
> technologies available change, as adoption of different technologies
> change, as people's habits change. I also think that we can lead, not
> just follow well established trends.
Here we also are thinking in similar ways. My input to the Road Map
report, that I understand influenced your decision to accept the MailCo
job, was how to position Tb to be the best possible hub for a "Personal
Communications Platform" that could capitalise on emerging technologies.
> It would be a shame to look back on Thunderbird in ten years and see a
> piece of software that lost a chance at having huge impact because it
> didn't know how to evolve. There is _huge_ opportunity for
> Thunderbird to become more than a good mailnews client that a few
> million people use. I estimate that Thunderbird is used by less than
> 1% of email users -- that's *a lot* given how many resources were
> dedicated to it! it's also *not enough* given what we could and
> should do.
> I believe that if we figure out together where we want to go,
> Thunderbird could help change the way lots and lots and LOTS of people
> feel about email, communication, computer work, work in general,
> social interactions, and more. We won't do that by just being a
> mail/news client. We need to think of the system in a different way.
> We have a mindshare and impact because of Mozilla and Firefox's
> success that we should use to our best advantage. Let's not squander it.
I have several times referred to the Same Place Jabber/XMPP add in
bundle,not as a pet add in, but as a currently available technology that
I see as a good fit for a "Platform Model" seeking to tie users needs
together. E-mail is a basic element of the platform. An improved RSS UI
would be useful. Your thoughts on Blog reading and publishing surprised
me, but your reasoning is sound and I think it should be considered. The
Lightning add-in will be another important segment of the platform. The
Lightning team has two targets, small business and students. Students
are the market segment I think We want. They are deeply immersed in
communication in many ways. My generation, pre-boomer, can be
overwhelmed by all the technology. I still have not mastered inputing
phone numbers into my wireless phone. Computers, though, I know we are
still scratching the surface of what software can do.
> I'm still working on how to express my hopes for Thunderbird, but
> hopefully the above gives a little window into my current thoughts,
> and why I took this job. I'm keen to refine how I can explain this
> stuff, in particular to this group, because you are the people who
> will help get this thing jump-started.
>
> Feedback welcome!
>
> --david
>
Eddy Nigg (StartCom Ltd.)
> I phrase the choice of what goes in the product vs. what should be an
> extension slightly differently. In my mind, the core product should
> provide that magical, subjective, and elusive blend of features which
> provides the best experience for the largest number of people possible.
> Add-ons then provide a wonderful vehicle for providing additional bits
> that either don't provide enough value yet -- for example features that
> aren't quite polished enough yet -- or to enough people -- because
> different people have different needs.
>
> The distinction is important. In particular, I don't subscribe to the
> notion of Thunderbird being defined as "the most lightweight mail/news
> client possible, with some extensions available". I think it's more
> complicated and changing than that.
>
> As an example, every interaction I have with "real users" who aren't in
> the inner circles of Thunderbird development get very agitated at the
> lack of any scheduling capability within Thunderbird. To what feels
> like a _large_ number of people, calendaring functions are much, much
> more important than, say, news reading or RSS integration, or LDAP
> integration.
media center for any communication type. In that respect could be the
application for managing anything related to scheduling and communication.
> I believe that if we figure out together where we want to go,
> Thunderbird could help change the way lots and lots and LOTS of people
> feel about email, communication, computer work, work in general, social
> interactions, and more. We won't do that by just being a mail/news
> client. We need to think of the system in a different way. We have a
> mindshare and impact because of Mozilla and Firefox's success that we
> should use to our best advantage. Let's not squander it.
>
> I'm still working on how to express my hopes for Thunderbird, but
> hopefully the above gives a little window into my current thoughts, and
> why I took this job. I'm keen to refine how I can explain this stuff,
> in particular to this group, because you are the people who will help
> get this thing jump-started.
Robert Kaiser
> As an example, every interaction I have with "real users" who aren't in
> the inner circles of Thunderbird development get very agitated at the
> lack of any scheduling capability within Thunderbird.
Note that people always talk more about what they miss than what they
already have, so comparing that missing functionality with something we
have is probably not right.
Anyways, I think it might be a good idea to ease integration of
Lightning into Thunderbird by providing XUL elements they (or other
extensions) can easily overlay rather than having them rely on changing
around our XUL DOM tree for integration.
That makes life easier for the Lightning team so calendering
functionality can get integrated more smoothly with Thunderbird and
while we're at it (that's where I originally came from with this idea)
would also make it easier to have Lightning integrated into SeaMonkey,
given the suite provides the same integration points. And the SeaMonkey
team would be just as happy as the Thunderbird team and MailCo to
improve the Mozilla mail and messaging space, including testing, using
and improving calendering functionality integrated with it.
Robert Kaiser
Brian King
> Really right now there are too many places to discuss things, not too
> few.
...
> ... I find this
> forum (mozilla.dev.apps.thunderbird) to be the most reliable place where
> names of people that I recognize as active will routine participate.
FWIW, I agree, this is the best forum. It is where I look first for what
is happening in TB dev. It is archived and searchable. If there are
compelling arguments to use other forums, that is fine, but lets not
fragment it too much.
- Brian
David Ascher
> David Ascher wrote:
>
>> As an example, every interaction I have with "real users" who aren't in
>> the inner circles of Thunderbird development get very agitated at the
>> lack of any scheduling capability within Thunderbird.
>>
>
> Note that people always talk more about what they miss than what they
> already have, so comparing that missing functionality with something we
> have is probably not right.
>
Very fair point, Kairo! Bad logic, david, bad logic.
> Anyways, I think it might be a good idea to ease integration of
> Lightning into Thunderbird by providing XUL elements they (or other
> extensions) can easily overlay rather than having them rely on changing
> around our XUL DOM tree for integration.
> That makes life easier for the Lightning team so calendering
> functionality can get integrated more smoothly with Thunderbird and
> while we're at it (that's where I originally came from with this idea)
> would also make it easier to have Lightning integrated into SeaMonkey,
> given the suite provides the same integration points. And the SeaMonkey
> team would be just as happy as the Thunderbird team and MailCo to
> improve the Mozilla mail and messaging space, including testing, using
> and improving calendering functionality integrated with it.
>
Sounds good!
--david
Mark Banner
> we all know. Discussions on general issues belong to here (mailing list)
> whereas communication between developers can be very dynamic (IM, phone,
> mailing list or just email). Wiki is good to nail down decisions, plans,
> road maps and other such stuff...and than there are the status meetings
> (usually by phone) and at last but not least bugzilla...
I think you've summed it up well here Eddy. The point I'd like to extend
is that we should try and be active in getting some of the decisions and
ideas here onto wiki or something - especially the ones that are
directional. Otherwise decisions get lost in the archives and its harder
for folks inside & outside to know what is going on.
Standard8
David Ascher
> David Ascher wrote:
>
>
>> I believe that if we figure out together where we want to go,
>> Thunderbird could help change the way lots and lots and LOTS of people
>> feel about email, communication, computer work, work in general, social
>> interactions, and more. We won't do that by just being a mail/news
>> client.
>>
>
> In my comment on your blog entry at
> http://ascher.ca/blog/2007/10/17/i-just-really-want-to-know-what%e2%80%99s-going-on-with-thunderbird/
> I suggested that TB focus on a single Big Idea (and suggested some
> possibilities), rather than try to be all things to all people.
> But that
> would not be an easy path. Your existing users are primarily interested
> in a better email client - scheduling, LDAP, RSS, HTML editing, better
> search, etc, etc. Also, if you spend much time browsing bugzilla you
> will see many bugs that really should have been fixed a long time ago
> that are still out there. So there is a long grind of incremental
> improvement to existing features, along with bug fixes, that is clearly
> the path of least resistance for moving TB forward.
>
Yup.
> Yet an open source project like TB really needs to attract developers.
Oh yes. But I'll tell you this -- it feels like there are a lot of
people outside the door, peering in the windows, trying to figure out if
this is a fun party. I think as soon as we pull out the appetizer trays
and party games, it'll get crowded -- in a good way.
> I
> don't see the long grind as being very attractive. (Though, strangely
> enough, I personally find the esoterica of spam filter token pruning as
> an interesting subject. That clearly is a "long grind" topic.)
I'm often surprised at what people will do in their free time. Your
parenthetical comment is a case in point -- there's a long tail of
software problems that, if you can figure out how to match interests and
problems, can get you 90% of the way there. The paid staff in some ways
are there to pick up the other 10%.
> Somehow
> we need to move forward on the basic improvements that the product
> needs, while at the same time leaving some space to try wild-eyed,
> innovative things (or to at least provide Mozilla-style open leadership
> to things that everyone is talking about, like unified communication or
> open social networks).
>
Absolutely agreed.
> What is sorely needed, and perhaps would be well-served by a Wiki, is to
> start to identify and categorize both the wild-eyed and conventional
> topics so that we could perhaps congregate around areas of interest, and
> maybe see what the Thunderbird forest starts to look like. Perhaps it
> would then be clear if there are a few Big Ideas that could develop a
> critical mass of people interested in making them happen.
>
>
Let me think on how to structure some of this.
A related point: One bit of pain that I'm feeling is that I know there
are lots of great ideas in bugzilla, but it's very hard to extract
knowledge from that data. Is it reasonable to consider using a set of
whiteboard keywords to build queries which we could then link to wiki
pages, so that we can e.g. keep track of all the bugs & RFEs about
contact management features, or IM integration features, or ...? It's
what I'd have done in my last bugzilla, but it may not be Mozilla-ish
enough.
It's great to see all this energy in the last 24 hours, btw. I'm
feeling rewarded for posting. Good job to all on providing positive
reinforcment =).
--david
Gus Richter
Lots of good stuff mentioned, but it may be worthwhile to mention that
the basic function of Thunderbird is to be used to communicate via
e-mail. There are two ways to communicate; text/plain and HTML. While
text/plain is working like a charm, the HTML side has been thoroughly
neglected and is severely handicapped. I would like to suggest humbly
that Thunderbird should learn how to walk before it is asked to run.
--
Gus
David Ascher
> Yes, we are fragmented in part because I view the Tb community has been
> forced to adapt to the Firefox business model.
Do you really mean business model, or just "firefox community ways"?
> Having worked with Eddy
> on a report in August, I am familiar with his enthusiasm. My
> recommendation to David A. is to say "These are the places we will do
> business" because I feel MailCo needs to flesh out it's identity and
> community.
Agreed. Part of my job is to figure out where to adapt to existing
Mozilla-wide structures, where to adapt to existing Thunderbird &
Mailnews structures, and where to create new ones.
> I pointed out to David that Same Place is a Jabber IM/IRC
> solution that has presence so we can see at a glance who is busy, away,
> or available. It is both Fx and Tb 2.0+ compatible. Nit is it lacks
> persistance.
>
Yup. Along similar lines, it's too bad that libpurple is GPL, as that
makes incorporating it into mainline Thunderbird problematic.
--david
Dan Mosedale
> Kent James wrote:
>> but really the main value of a local spam filter is the
>> characterization of ham. Junk is common over many users, but each
>> person has their own unique ham signature. Some methods need to be
>> developed to automatically do this. Maybe, for example, we could
>> consider each message ham that the user replies to.
> I like that. I'd also suggest that senders to whom one replies should
> probably be special-cased in the addressbook as well. They're likely to
> be special. It might even make sense to consider some whitelisting hints.
They're already added to the personal addressbook by default (see the
composition / addressing prefpane), and I think anything in the personal
addressbook is in fact already whitelisted.
>> 3) There are now multiple text characterization schemes (starred,
>> junk/nonjunk, tags) that could be unified into a single system, with
>> possible benefits such as expanding Bayesian analysis to determination
>> of tags for example (to say nothing of much-needed refactoring).
> Agreed.
IIRC, Henry Jia of Sun long ago submitted a patch to generalize the
Bayesian code in some ways. I think the idea may have been to train it
to follow the user's general message filing pattern, rather than just
caring about two ham/spam buckets. It's been a while, though, so I may
be misremembering the details. Searching Bugzilla should turn it up...
Dan
Eddy Nigg (StartCom Ltd.)
>
> Yup. Along similar lines, it's too bad that libpurple is GPL, as that
> makes incorporating it into mainline Thunderbird problematic.
should this be a problem please?
Joey Minta
wrote:
> David Ascher wrote:
> >
> > Yup. Along similar lines, it's too bad that libpurple is GPL, as that
> > makes incorporating it into mainline Thunderbird problematic.
> Huuu? Mozilla itself uses a triple license model including GPL, why
> should this be a problem please?
>
Because the GPL is viral and exclusive in its terms. You can't take GPL
code and incorporate it into closed-source code that you don't release.
Similarly, the GPL license doesn't allow its code to be released merely
under the stricter LGPL. Mozilla's licensing is permissive, allowing a user
to choose its license. In other words, in order to incorporate GPL'd code,
the owners would have to agree that the code could be relicensed under
LGPL/MPL, effectively tri-licensing it. Without this permission, it's not
compatible with the Mozilla tri-license.
Note that this is an asymmetric situation. Because of the tri-license, GPL
code can incorporate Mozilla code, by electing to use the GPL part of the
tri-license.
At least, that's how I understand it. But IANAL (yet).
-Joey
See the actual text in the boilerplate license block:
* Alternatively, the contents of this file may be used under the terms of
* either the GNU General Public License Version 2 or later (the "GPL"), or
* the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
* in which case the provisions of the GPL or the LGPL are applicable
instead
* of those above.
Dan Mosedale
> Ed
>>> Would it make sense to think about what protocol should be used to
>>> synchronize client state across channels, so that there could be a
>>> "thunderbird metadata server" which would hold all appropriate data,
>>> from "bookmarked" rss items to address book data, etc?
>> Absolutely! I'm not sure if there is such a protocol, but I think the
>> people from XMPP could help us thinking into the right directions a
>> little bit...
In the past, there was a protocol called ACAP. It evolved from the IMSP
protocol, and I think Cyrus Daboo (one of the CalDAV spec authors) had a
hand in it. I'm pretty sure Mulberry Mail supports one or both of these.
<http://ietfreport.isoc.org/idref/draft-newman-acap-imsp-lessons/> is an
old document that talks about this some. Neither of these protocols
achieved super widespread use but a number of partial implementations of
servers exist.
Out of some of the ideas in ACAP evolved XCAP
<http://www.jdrosen.net/papers/draft-ietf-simple-xcap-12.txt>, and I
think there's actually some amount of usage of this in the VOIP
community, though I haven't really kept up. Because it's based on HTTP
and XML, it's fairly "webby", so it might be a good starting point.
> Would LDAP or SQL-Lite have the flexibility and adaptability for such a
> task ?
In the Netscape 4 timeframe, users had the option of roaming their data
to either LDAP or HTTP servers, so the former is definitely definitely
possible.
Dan
Eddy Nigg (StartCom Ltd.)
> On Dec 14, 2007 4:11 PM, Eddy Nigg (StartCom Ltd.) <eddy...@startcom.org>
> wrote:
>> Huuu? Mozilla itself uses a triple license model including GPL, why
>> should this be a problem please?
>>
>>
> Because the GPL is viral and exclusive in its terms.
(no flame-war please)
> You can't take GPL
> code and incorporate it into closed-source code that you don't release.
>
you release a product (software) based on this code you must share the
code along with the software. The parent project in question doesn't
have to make use of your code so...
> Similarly, the GPL license doesn't allow its code to be released merely
> under the stricter LGPL.
> Mozilla's licensing is permissive, allowing a user
> to choose its license. In other words, in order to incorporate GPL'd code,
> the owners would have to agree that the code could be relicensed under
> LGPL/MPL, effectively tri-licensing it. Without this permission, it's not
> compatible with the Mozilla tri-license.
>
projects, but one can always ask nevertheless...
David Ascher
The point I was trying to make is that jabber is really interesting, but
right now the vast majority of users have non-jabber IM accounts. So
finding a way to do interop with them would be good.
Hmm. Crazy idea: could we build a server-side proxy which talked jabber
to the client and whatever IM protocols to the world?
--david
Kent James
>
> The point I was trying to make is that jabber is really interesting, but
> right now the vast majority of users have non-jabber IM accounts. So
> finding a way to do interop with them would be good.
>
If you combine some of these discussions about IM clients with the
concepts of Mozilla providing web services directly, all kinds of
interesting possibilities open up. If, for example, each person using Tb
by default was signed up to a jabber account on a Mozilla server, then
the vast majority of Tb users would have immediate IM access to most
other Tb users. Similarly, you could use some sort of Mozilla-provided
web service to update personal contact information between Tb users.
That way, all Tb users would have accurate, consistent contact
information about all other Tb users. Of course you could make this open
source so that others could do the same, but in reality the
zero-configuration capability provided by owning both the client
application as well as the web service would make the default Tb version
extremely attractive. Also, since you can better interact with other Tb
users, then it would create some viral adoption incentive for Tb.
Kent
Eddy Nigg (StartCom Ltd.)
> David Ascher wrote:
>
>> I'm sorry I brought up licensing.
>>
>> right now the vast majority of users have non-jabber IM accounts. So
>> finding a way to do interop with them would be good.
>>
>> to the client and whatever IM protocols to the world?
>>
>
>
In order to make this a little bit clearer for David, XMPP (Jabber) can
talk to almost any IM protocol there is out there...It depends on what
the server supports, but many do GoogleTalk, MSN, Amazon etc. etc.
Now XMPP has been discussed in the past and is certainly a likely
candidate for IM integration for TB. But the initial idea in this
specific thread was, if XMPP can somehow be useful to store contact and
other data. To all of my knowledge most XMPP servers do store much more
(and are capable to do so) than the very least of user names as Peter
stated earlier. As such I can today save and retrieve various
information about other XMPP users including images etc...hence I
believe that it should be possible to extend in some way in an existing
framework. Peter, if I misunderstand something here, please correct me...
And since XMPP is based mostly (all?) on XML I think this should be
interesting in every respect as somebody else here already mentioned XML
as a likely candidate...
Dan Mosedale
XMPP was specifically built to allow Jabber servers to do exactly this,
and some deployed servers do support it.
Dan
Ron K.
> Ron K. wrote:
>> Yes, we are fragmented in part because I view the Tb community has
>> been forced to adapt to the Firefox business model.
>
> Do you really mean business model, or just "firefox community ways"?
The latter. Tbird has been forced into the Firefox style in may ways,
Try the add-on site. All the Tbird add-ons have an install button, not
a download button which would clarify the difference in add-on install
procedure, remote versus local. It is this issue that Scott wanted the
Tbird community to discuss at the Mozilla Wiki. Only two people
responded, I am one of them. So simple question: Why can't we have our
own template page so that the Webmaster would use it to setup a new
Tbird extension page. I consider this web page issue to be disrespectful
of Tbirds status as a Mozilla Foundation sponsored application.
>
>> Having worked with Eddy on a report in August, I am familiar with his
>> enthusiasm. My recommendation to David A. is to say "These are the
>> places we will do business" because I feel MailCo needs to flesh out
>> it's identity and community.
>
> Agreed. Part of my job is to figure out where to adapt to existing
> Mozilla-wide structures, where to adapt to existing Thunderbird &
> Mailnews structures, and where to create new ones.
>> I pointed out to David that Same Place is a Jabber IM/IRC solution
>> that has presence so we can see at a glance who is busy, away, or
>> available. It is both Fx and Tb 2.0+ compatible. Nit is it lacks
>> persistance.
>>
>
> Yup. Along similar lines, it's too bad that libpurple is GPL, as that
> makes incorporating it into mainline Thunderbird problematic.
> --david
>
LOL, I am being bombarded with terms right out of the Harry Potter
wizards manual. Pray tell, how does a purple library relate to Tbird.
David Ascher
> Tbird has been forced into the Firefox style in may ways,
> Try the add-on site. All the Tbird add-ons have an install button, not
> a download button which would clarify the difference in add-on install
> procedure, remote versus local. It is this issue that Scott wanted the
> Tbird community to discuss at the Mozilla Wiki. Only two people
> responded, I am one of them.
Do you know the URL by any chance?
> So simple question: Why can't we have our
> own template page so that the Webmaster would use it to setup a new
> Tbird extension page. I consider this web page issue to be disrespectful
> of Tbirds status as a Mozilla Foundation sponsored application.
>
The extension experience (for authors and users) is an issue that I want
MailCo to tackle soon. It's one of those problems which isn't
technically super hard, but which needs someone to figure out what all
the bits should be. For example, things get a bit complicated when you
realize that some extensions should be installable with a one-click in
Seamonkey, but shouldn't be installed in Firefox, etc. It's workable,
but it needs to be someone's priority. NB: This kind of problem is
_exactly_ why MailCo is being created, and why one of the roles I'm
looking for is someone who can be the extensions lead/evangelist.
> LOL, I am being bombarded with terms right out of the Harry Potter
> wizards manual. Pray tell, how does a purple library relate to Tbird.
>
Sorry, forgot to give background: libpurple is a cross-IM client library
which is part of Pidgin (née Gaim).
-david
Ron K.
> just trying to figure out how high a mozilla.com (or whatever) Jabber
> server would need to scale. :)
>
> Peter
>
>
Peter we are already at more than the "Big" size and closing in on
"Huge" My guess is more than 10 million and less than 100 million user
world wide. So what is the Scale factor in terms of bandwidth and server
boxes to put this idea into play?
Ron K.
Warms my heart to hear someone bring NS history into a contemporary
discussion. For all its flaws and blemishes, that suite broke ground
and in the process created the environment we work in now. I remember
bring able to use the LDAP feature of NC4 to query Bigfoot, or any of
the other LDAP directory servers, to ferret out my younger brothers
e-mail address and location in rural Iowa. It is this sort of capability
that I want any and all e-mail applications top perform with a simple
interface. The data is out there, it's public, so I want it here, now,
when I need it. My mother is dying,it's urgent that I coordinate our
response to this calamity. I want, no, need, a useful easy way to fined
an essential person for a critical reasion. Tbird give it to me, *Now* !!!
Wayne Mery
I'm not finding anything of Henry's in bugzilla that is related. I
thought I recalled such a thing, but perhaps just a false memory by
power of your suggestion :)
Selected list of enh bugs:
Bug 179518 – Automatically mark own (sent) emails as non-junk
https://bugzilla.mozilla.org/show_bug.cgi?id=179518
Bug 194455 – Offer more control to users when junk process is learning
https://bugzilla.mozilla.org/show_bug.cgi?id=194455
Bug 226908 – Junk Mail Controls Should Ignore Replies On User's Messages
https://bugzilla.mozilla.org/show_bug.cgi?id=226908
Bug 237403 – Bayesian Noise Reduction
https://bugzilla.mozilla.org/show_bug.cgi?id=237403
Bug 243430 – Improving the chi-square spam detection method
https://bugzilla.mozilla.org/show_bug.cgi?id=243430
Bug 366491 – Maintain...junkscore & junkscoreorigin, preserve junkstatus
https://bugzilla.mozilla.org/show_bug.cgi?id=366491
and intriguing but not directly related
Bug 181866 – Use bayesian filters for other features than spam
https://bugzilla.mozilla.org/show_bug.cgi?id=181866
Wayne Mery
> Ron K. wrote:
>> Tbird has been forced into the Firefox style in may ways, Try the
>> add-on site. All the Tbird add-ons have an install button, not a
>> download button which would clarify the difference in add-on install
>> procedure, remote versus local. It is this issue that Scott wanted the
>> Tbird community to discuss at the Mozilla Wiki. Only two people
>> responded, I am one of them.
>
> Do you know the URL by any chance?
perhaps http://wiki.mozilla.org/Talk:Thunderbird:Extension_Installation
Ron K.
Wow, I choked on you line about the snack trays. I wish your dream of
the paid staff being the 10% gap filler were true. I fear that We have
lost Scott. That young man toiled under very less than comfortable
conditions, from My perspective as a retired soldier.
Kent James
>> Selected list of enh bugs:
>
>
> Bug 256563 – Implement ... Chung-Kwei (Teiresias) algorithm
> https://bugzilla.mozilla.org/show_bug.cgi?id=256563
>
Thanks for all of the references. I have some working theories about
what makes the spam processing tick, plus there has been a lot of
research about it. I'm just starting to get actual results from Tb spam
processing on the TREC 2005 spam corpus (thank God for Enron!) so I may
be able to deal with those bugs, plus ideas of my own. Realistically, if
the native spam processing in Tb could increase in effectiveness by a
factor or 2 it would be amazing, yet that still does not completely
solve the problem. Still, there are some obvious annoyances (like the
need to retrain) that should be eliminated.
I think I'll start a blog in a day or so for anyone who might be
interested in my daily encounters with spam processing. But let me make
observations here for now.
For my initial pass on the TREC 2005 corpus, I divided the roughly
100,000 emails into 5 groups selected randomly. I trained on one of the
groups, then analyzed the entire set of emails. With that, I got roughly
.05% false positives, and 6% false negatives. Looking at a few of the
false positives, they typically involved only a few tokens that survived
the initial cuts, usually less than 10. Those tokens usually only had a
few previous references, say 2-5. The probability calculation used by
Tb, copied I believe from some of the original articles, uses a formula
to correct for the limited degrees of freedom available when there are
only a few samples, but the formula is biased to give stronger
probabilities than the data predicts. Anyway in my case they are
over-estimating the value of tokens that are rarely seen, causing the
false positives.
Using a classic Laplacian prior, calculating the posterior probability p
of an event (here the probability that an email containing the token is
spam) with s successes and n trials is done using:
p = (1+s)/(2+n)
so for example, if we see a spam token twice, it calculates
p=(1+2)/(2+2) = .75
Tb uses the formula:
p = (.225+s)/(.45+n),
which for the same example gives p=.91, overestimating the spam
prediction of that token. It's these kinds of tokens that are giving me
some of the false positives I am seeing. The Tb formula was justified in
some earlier paper based on empirical results. I want to understand what
that really means. My current hypothesis is that the Tb formula may help
with getting quick results with limited training, but gives poorer
results when there are large numbers of training examples. (My initial
hypotheses are often wrong, BTW)
These mathematical games are fun, but I still think that the UI and
available information when things aren't working are much more important
than a few percentage points improvement in detection performance.
Wayne Mery
also
Ron K.
Mark You have hit the nail on the head, (lame metafore) in that we do a
lot of great idea and concept sharing, but fail to codify it so those
who follow after us can see where we came from and why we traveled in
the direction we chose. News archives are just dry, lifeless; words
uttered as symbolic representations of our inner vision.
John Liebson
> David Ascher keyboarded, On 12/14/2007 3:28 PM :
>> Ron K. wrote:
>>> Yes, we are fragmented in part because I view the Tb community has
>>> been forced to adapt to the Firefox business model.
>>
>> Do you really mean business model, or just "firefox community ways"?
>
> The latter. Tbird has been forced into the Firefox style in may ways,
> Try the add-on site. All the Tbird add-ons have an install button, not
> a download button which would clarify the difference in add-on install
> procedure, remote versus local. It is this issue that Scott wanted the
> Tbird community to discuss at the Mozilla Wiki. Only two people
> responded, I am one of them. So simple question: Why can't we have our
> own template page so that the Webmaster would use it to setup a new
> Tbird extension page. I consider this web page issue to be disrespectful
> of Tbirds status as a Mozilla Foundation sponsored application.
>
That is a definite problem, judging by the number of people on
MozillaZine and mozilla.support.thunderbird who cannot figure out why
the extension(s) they are trying to install state that they are, for
example, incompatible with Firefox. That latter is, of course, correct,
but why should the download site offer to install something that cannot
be installed?
<non-installable words removed>
>
--
John Liebson
Ron K.
Yes Gus: The use of HTML by American commercial interests is essential
to the profitability of not only the American economy, but also that of
the globe we live on. The fanaticism of the plian/text purists is not in
the best interests of electronic commerce where a picture truly is
"Worth 1,000 words". More than once I have lost out on qualifying for a
fantastic sales discount for lack of timely notification of a time
limited offer by a major e-commerce vendor.
Brian King
Yes, based on this page of course:
http://wiki.mozilla.org/Thunderbird:Extension_Installation
The original discussions are at:
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_frm/thread/e9b08903bf100b29/4560c4e283faebb7
http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_frm/thread/1dc7f1fc0003b191/6f2218f515a099b2
This is something we probably need to reopen.
- Brian
Karsten Düsterloh
> I remember bring able to use the LDAP feature of NC4 to query
> Bigfoot, or any of the other LDAP directory servers, to ferret out my
> younger brothers e-mail address and location in rural Iowa.
Preferences -> Addressing -> Directory Server ?
(But I have no LDAP experience/don' know if that works as it did in NS4.)
Karsten
--
Feel free to correct my English. :)
Bed
> I find the RSS UI in Thunderbird just painful enough that it stops me
> everytime I want to switch to it from Shrook, which is my current RSS
> reader of choice. So I've been thinking about what it could become.
>
> There are some "obvious" problems, which I suspect are in bugzilla
> already, like:
> - can't actually use TB as a feed subcriber from Firefox. - can't drag
> and drop URLs into the News & Blogs container to have them added
> - no auto-discovery of feeds from web page URIs
> - some bugs w/ import of hierarchical OPML files (can't recall details)
> - in the add dialog, there's a folder per feed, which certainly
> confused me at first.
I've always found RSS to be clunky as lego (but much less solid) in
Thunderbird. Which is a shame because if these rough edges were
sharpened up it would be so much nicer to utilise.
For me personally, I have a clear idealogy for how I use Thunderbird. TB
is my 'Pull' client. It always runs in the background and I configure it
to automatically pull down content I want. This includes my email,
newsgroups and all my rss feeds. I can check it when I'm free and
anything available is there waiting for me.
This is compared to 'push'/'realtime' clients, like my web browser and
my IM app.
I'd hate to see Thunderbird incorporate IM as core functionality -
because I use another application for that. My experience with trying to
use the lightening extension is that any pause of delay while loading my
google-based calendar prevented me from accessing any of my 'pull'
content. Switching to using Sunbird made that issue go away (of course
now I just use google calendar directly via my web browser because the
speed difference is astronomical.
So to sum up, if it were my personal project, TB would be purely a
'pull' client. No IM, no web browsing, just automatically pulling all
content I configure it to pull and making it easy for me to view it.
Bed
Bed
> Lots of good stuff mentioned, but it may be worthwhile to mention that
> the basic function of Thunderbird is to be used to communicate via
> e-mail. There are two ways to communicate; text/plain and HTML. While
> text/plain is working like a charm, the HTML side has been thoroughly
> neglected and is severely handicapped. I would like to suggest humbly
> that Thunderbird should learn how to walk before it is asked to run.
I agree with this notion 100%. TB is 'pretty good' at what it does,
overall. But large chunks of functionality is just 'average' - it does
the job, but not nicely or smoothly.
If we focus on doing what it does now - but doing it BETTER, EASIER,
FASTER, more RELIABlY - then the alternatives will be forced to play
catchup, like FireFox has done. Its focussed on being a web browser -
not adding IM functionality.
Eddy Nigg (StartCom Ltd.)
> For me personally, I have a clear idealogy for how I use Thunderbird. TB
> is my 'Pull' client. It always runs in the background and I configure it
> to automatically pull down content I want. This includes my email,
> newsgroups and all my rss feeds. I can check it when I'm free and
> anything available is there waiting for me.
>
> This is compared to 'push'/'realtime' clients, like my web browser and
> my IM app.
>
different view. *Communication*, *integration* and *sharing* seems to be
the key words for a new Thunderbird...
> I'd hate to see Thunderbird incorporate IM as core functionality -
> because I use another application for that. My experience with trying to
> use the lightening extension is that any pause of delay while loading my
> google-based calendar prevented me from accessing any of my 'pull'
> content. Switching to using Sunbird made that issue go away (of course
> now I just use google calendar directly via my web browser because the
> speed difference is astronomical.
and makes a real difference for office usage today. If there is a
performance issue with Lightning than this should be solved differently
IMO...
Bed
>> For me personally, I have a clear idealogy for how I use Thunderbird.
>> TB is my 'Pull' client. It always runs in the background and I
>> configure it to automatically pull down content I want. This includes
>> my email, newsgroups and all my rss feeds. I can check it when I'm
>> free and anything available is there waiting for me.
>>
>> This is compared to 'push'/'realtime' clients, like my web browser and
>> my IM app.
>>
> This is what you've got now more or less and the majority support a
> different view. *Communication*, *integration* and *sharing* seems to be
> the key words for a new Thunderbird...
usability that could be made to the existing functionality to make it
more than *good*, but *exceptional*.
>> I'd hate to see Thunderbird incorporate IM as core functionality -
>> because I use another application for that. My experience with trying
>> to use the lightening extension is that any pause of delay while
>> loading my google-based calendar prevented me from accessing any of my
>> 'pull' content. Switching to using Sunbird made that issue go away (of
>> course now I just use google calendar directly via my web browser
>> because the speed difference is astronomical.
> Interestingly it is exactly this extension which was requested the most
> and makes a real difference for office usage today. If there is a
> performance issue with Lightning than this should be solved differently
> IMO...
To be fair, the performance issues I had with Lightning were more to do
with using remote google calendars and having to pull back events from
google's servers constantly.
Bed
Aaah yes indeed :D
Actually that was the problem - if the google cal provider automatically
pulled (ie synced) events, rather than being 'ondemand' it probably
would've worked better.
Robert Kaiser
> So to sum up, if it were my personal project, TB would be purely a
> 'pull' client.
In a time where the borders between pull and push are getting more and
more diffuse (the traditional pull service email e.g. goes popular as a
push service in Blackberry devices, etc.) I don't think it makes much
sense to try to restrict an app to one of those concepts. I think what
users want is more important than such theoretical concepts behind the
scenes.
Robert Kaiser
Eddy Nigg (StartCom Ltd.)
>
> Actually that was the problem - if the google cal provider automatically
> pulled (ie synced) events, rather than being 'ondemand' it probably
> would've worked better.
>
>
haven't seen working really in any case. Pull works, push not so...
ovidiu
> I phrase the choice of what goes in the product vs. what should be an
> extension slightly differently.
> The distinction is important. In particular, I don't subscribe to the
> notion of Thunderbird being defined as "the most lightweight mail/news
> client possible, with some extensions available". I think it's more
> complicated and changing than that.
> Which isn't to say that I want to take those features out, just that
> the blend of what features belong in a client like Thunderbird is
> subject to reconsideration as things change -- as technologies
> available change, as adoption of different technologies change, as
> people's habits change.
I take these as to go for a more refined way of dealing with
extensibility than is now.
First, extension and core can be treated more nuanced by having simply a
hierarchy or at least importance statements from tb. I mean they are
treated equally today, with no special reference to lightning vs some
small functionality tiny extensions, to keep this example, witch is
wrong as this is a whole new set of functionality and features and may
become more important in the future.
The idea is to have a way to say what is core, not core but big deal of
feature, not so big deal but new feature and peripherical improvement or
small correction. This goes for something like simply a tag for the
extensions page and some statements in the front page of tb.
I know I didn't got lightning from the beginning and i still am
wondering why is lost among other stuff, though I may wonder about ltng
maturity and find my answer..
Conclusion: I would wait for a 'Get TB with Lightning' (as the FF with
Google tool bar). It's a statement, for tb and lt, more then an ease of
download, and may be done with a simple link or just indication. It
shows the features available for tb and confidence in lt. Of course, as
soon as ltn is considered to be mature enough not to become a drawback ...
> There is _huge_ opportunity for Thunderbird to become more than a
> good mailnews client that a few million people use.
> We won't do that by just being a mail/news client. We need to think
> of the system in a different way.
Yes, but is doable beginning from mail client. Look at gmail that is
trying to gather all talk and cal and docks in one place. And yahoo and
others the same. The point is that having an UI that grows from the
classic 'organizing mail' UI may even be the key, cause it's a standard
and is more likely for people to begin organizing communication from
mail, cause is probably the most organized one.
On the other hand, let's see the bright side of desktop. Cause the gmail
and yahoo may very well do the job on the web side and I don't see tb as
an immediate alternative, but rather as a more settled option. Reasons
to have desktop comm client may be the offline access and intranet, more
thorough organization of data along with other local data (files),
archive and backup, better integration with os and other software and
more that don't come into mind. Corporate may be another point.
(Some people and most of the students are going for the web interface as
this is really portable (independent) and see it as a privacy thing
(like my mail is on the web and no one here in the office has anything
to do wit it- kinda reverse to what privacy looks like from the 'privacy
policy on the web' issue). Meaning that they even use web mail for
personal comm and client for work to keep different behaviors and
activity separated. Tb portable is not quite the same, but may be an
answer.)
I would even dear to say that gmail showed what I would call a
regression or down shifting with the imap methods, from the organizing
mail point of view. They are matching those virtual folders for the real
ones, witch shows how slow can be to propose new improved ways to people
over the habits or standards. But this is for the next paragraph..
Conclusion: If th AB is to be the core of the change (and is a deep
one), TB is to be the UI (and the most natural).
I plead for migration towards what you are looking for from what you
already have. And not for the legacy kind of approach, but cause it
seams right. Think reverse way, you are allowing to discuss 'comm hub'
cause you start from a mail app and if you were to begin from an im or
rss or other soft it would seam like too much or unrealistic. The thing
is that a software that organizes mail leads to organizing the other
channels cause mail is still the most well defined media (standard), or
just cause is the way people behave (mail is older..). And leaded you to
the idea. And the same, if today you help with an _UI to organize the
mail_ and the desktop, the web or other remote info should land here
when naturally people will find that this is the best way, witch means
inviting and the future.
> We have a mindshare and impact because of Mozilla and Firefox's
> success that we should use to our best advantage. Let's not squander it.
Communicate, promote, but teach people. Teach means sometimes just to
say something, but in the right place/time/audience. And always should
lead to learning (these threads are such a good example).
(The example of Gmail imap to use folders for virtual folders may show
that they are making a compromise with the most common user behavior (be
it habit or soft standard, no matter..) and go for a slower 'teaching
people' into something. )
Other things that go in circles:
Want more contributors?
1.get more users. There may be some dev at the door, but there may be a
scale/critical mass thing. (FF more users, ff more extensions..)
2.want more users, get a pole. But make sure is reaching as many as
possible and as simply as 123. It should show if they use tb, who they
are, but also why, how got here, what they want, how thy organize comm
data.. This would show that you care
3.show a different approach, attract more than IT or dev. There is this
thing with open soft witch may be intimidating, cause is viewed as soft
only, or geek only. There may be others that don't even know that they
can help, or not even going for 'How can I help' because of this
prejudice (so many places to improve, support, doc, dictionaries, etc
etc). A more organized way of dealing with contributions may be a + and
may help attractor people from various fields. And also for one to
evaluate his/hers place in it.
For example, should I post this here, or just watch, or should I just
mind my own business ? (but really, I hesitated and still not sure if
only interfering or waisting time of people with this outsider's
comments) There could be rules of collaboration including those not dev,
even if in a subtle way, thru guidance ..
By saying that I'll stop, cause, anyway, to define directions and solid
future is the most important here and also for communication, building
trust, etc
Ron K.
Neither Tb or Fx are adding IM functionality. One can have IM by
insytalling an add-on called Same Place the uses the open souce
Jabber/XMPP protocols. Same Place resides in a left side flyout sidebar
which is available as needed without requiring a new window the way
Chatzilla does on Fx.
Your comments on pull are relative. I can make a point that Tb is a
"Push" product. I write a message and I have to push it to get it off
my system so it can land on the server you pull from.
Eddy Nigg (StartCom Ltd.)
> Conclusion: I would wait for a 'Get TB with Lightning' (as the FF with
> Google tool bar). It's a statement, for tb and lt, more then an ease of
> download, and may be done with a simple link or just indication. It
> shows the features available for tb and confidence in lt.
> For example, should I post this here, or just watch, or should I just
> mind my own business ? (but really, I hesitated and still not sure if
> only interfering or waisting time of people with this outsider's
> comments) There could be rules of collaboration including those not dev,
> even if in a subtle way, thru guidance ..
post can look away anyway). So your post was somewhat extensive I
believe that an "outsider" view is as important (if not sometimes more)
than that of the insiders. Thanks for your time!
Ron K.
> Ron K. wrote:
>> Tbird has been forced into the Firefox style in may ways, Try the
>> add-on site. All the Tbird add-ons have an install button, not a
>> download button which would clarify the difference in add-on install
>> procedure, remote versus local. It is this issue that Scott wanted
>> the Tbird community to discuss at the Mozilla Wiki. Only two people
>> responded, I am one of them.
>
> Do you know the URL by any chance?
Sorry for the slow response, been a doggy weekend. The direct link
<http://wiki.mozilla.org/Thunderbird:Extension_Installation>
>> So simple question: Why can't we have our own template page so that
>> the Webmaster would use it to setup a new Tbird extension page. I
>> consider this web page issue to be disrespectful of Tbirds status as
>> a Mozilla Foundation sponsored application.
>>
>
> The extension experience (for authors and users) is an issue that I
> want MailCo to tackle soon. It's one of those problems which isn't
> technically super hard, but which needs someone to figure out what all
> the bits should be. For example, things get a bit complicated when
> you realize that some extensions should be installable with a
> one-click in Seamonkey, but shouldn't be installed in Firefox, etc.
> It's workable, but it needs to be someone's priority. NB: This kind
> of problem is _exactly_ why MailCo is being created, and why one of
> the roles I'm looking for is someone who can be the extensions
> lead/evangelist.
You may find the link plays into this. And a side note: Seems that with
the revisions the Fx team made to the extension manager that the Mr Tech
Local Install add-on no longer archives updates because they are being
directly applied during diring Fx and Tb start up.
>> LOL, I am being bombarded with terms right out of the Harry Potter
>> wizards manual. Pray tell, how does a purple library relate to Tbird.
>>
>
> Sorry, forgot to give background: libpurple is a cross-IM client
> library which is part of Pidgin (née Gaim).
> -david
ovidiu
>> For example, should I post this here, or just watch, or should I just
>> mind my own business ? (but really, I hesitated and still not sure if
>> only interfering or waisting time of people with this outsider's
>> comments) There could be rules of collaboration including those not
>> dev, even if in a subtle way, thru guidance ..
> You aren't waisting anybodies time here (whoever doesn't want to read
> a post can look away anyway). So your post was somewhat extensive I
> believe that an "outsider" view is as important (if not sometimes
> more) than that of the insiders. Thanks for your time!
point of the post and the point of the example, in the way I expressed
that (you know, subliminal..). And yes, the post is extensive, at least
for a brainstorming, witch is for the inner idea to suffer. Bud I'd say
that besides being really pleased by the responsiveness of moz-tb
generally (support,etc), I'm wondering about how to channel such
energy in a more effective way.
Thanks again.
Magnus Melin
> With respect to TB, these are my preferences:
> * The wiki would be used to inform developers of extensions or as a
> springboard for would-be developers of TB.
> * The web forum is a support channel for people who need help with TB.
> * IRC has a few channels:
> @ Support, a la web forum
> @ Developer information, like #developers or #maildev
> @ A planning channel for when two people need to have instantaneous
> communication.
> * Newsgroup or mailing list (prefers newsgroup): main method of
> communicating planning decisions.
> * Bugzilla would be used as it is now, for detailing bugs and
> works-in-progress
> * Blogs would be used mostly for announcing decisions, such as
> resolutions on a newsgroup/mailing list debate
> * Where to put RFEs? Newsgroup (like mozilla.wishlist), Bugzilla, or Web
> forum? There should be one standard place; ideally, it would be
> cross-referable so that all interested parties would know about them.
This list sounds pretty good to me, and may I say I'm glad to see all the recent
discussion here! I'd certainly support using this newsgroup/list for more
general level discussion and planning and using wikis for the documentation and
detailed plans. I recall the firefox3 brainstorming wiki-page got huge amounts
of publicity, not sure how much substance they got out of it though.
At the moment RFEs are a bit spread out, but I don't see that changing, since
the entry level is a quite different. We have a lot of RFEs in bugzilla so it's
not so easy for a newcomer to file something useful that isn't a dupe - and
filing an RFE in bugzilla for something general level is usually quite pointless.
-Magnus
David Ascher
> At the moment RFEs are a bit spread out, but I don't see that changing, since
> the entry level is a quite different. We have a lot of RFEs in bugzilla so it's
> not so easy for a newcomer to file something useful that isn't a dupe - and
> filing an RFE in bugzilla for something general level is usually quite pointless.
>
it's so hard to create an evolving "spec" that doesn't require people to
re-read the entire discussion each time.
I wonder if it would make sense to take the RFEs in bugzilla, create
wiki pages for them, where they can be discussed (in the Talk pages) and
refined, and as they are finalized, create new bugs to track the
development of those RFEs.
--david
Kent James
>
> I find that bugzilla is a lousy place to _discuss_ RFEs
One thing I've always been impressed with about the whole Mozilla
development environment is the traceability. I can pull up code using
lxr, see the history of changes of each line of code using CVS BLAME,
and then trace that back to its discussion on bugzilla. Any method
changes that you propose should consider those who come after us, who
will have to figure out what we did and why.
David Ascher
traceability is pretty good there.
--david
Wayne Mery
wiki is good for depicting relationships, summarizing and organizing
things discussed elsewhere, "lists" of <whatever>. traceability is
definitely there, if the page is kept. not good for discussion.
news good for discussion, if organized, i.e. with purpose and
self-control (but even then can get unwieldy for some). traceability is
there too.
relegate bugzilla to working through the technical issues of
implementation and code.
Ron K.
We get a *lot* of RFE's in news://news/mozilla.support.thunderbird as
well as "Bug" reports from people who think that support group is manned
by Mozilla software types. Support also get a quite a bit of OT
requests like why does my attached CSS,HTML, JS, or XHTML not work.
Personally I never use forums for support, the format is too cumbersome
and threading is non-existant. IRC might work if it was a private
standalone server. An RSS feed would be usefull if it agregated the
Wiki, Mozillazine home page, Tb blogs, etc.
Currently we refer people to Bugzilla from Tb support if a thread
indicated that is the best resolution for future fix. That is less than
40% follow through, so lots of RFE's are lost . One complaint is
Bugzilla is too intimidating.
Chris Ilias
I don't think that was the point Kent was making. CVS commits in Mozilla
usually cite a bug number, not a wiki page.
I find wikis good for documents, but not discussion. I agree that
bugzilla is lousy for discussion, but I think wikis are worse.
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Kent James
>
> I find wikis good for documents, but not discussion. I agree that
> bugzilla is lousy for discussion, but I think wikis are worse.
It's sort of ironic that we, who are trying to set the pace for the
world in communication, cannot recommend an environment that makes sense
for collaboration. I wonder if there are some lessons to learn here,
about perhaps what should be important directions for Thunderbird?
In one of the other contexts where I work, I am pushing SharePoint
pretty hard on an organization for collaboration. Yet it is also a lousy
way to collaborate in many ways. There are too many contexts for
comment, that do not get readily tied together. It's all too easy for
users to just throw up their hands, and revert to the Standard Method of
collaboration: reply-to-all email, quoting the entire thread in each
email and top posting. That actually works surprisingly well for most
people, and probably carries over half of the world's collaboration.
Kent
Ron K.
A reason Netscape named the News portion of the Communicator 4.x suite
Collabra was a view to news being a collaberation solution. Mial based
discussion here withe the MailMan interface Mozilla.Org is using
produced spotty results. David's postings are the only ones showing
both in the news group and dropping into my e-mail. I am not subscribed
to the list-serv. With that spotty communication I am only getting his
side of content others reply to David by the list.
David Ascher
than I'd usually be, and to see how it works in practice.
My current thinking is:
- we use wikis to _describe_ what the feature should "look like"
- we _discuss_ them on the mailing list
- we _update_ the wikis with revised version as per the results of the
discussion
- we mention the updates on the mailing list, to let people know when
those changes happen
- we create bugs to track implementation of features, and the bugs can
point back to the wiki pages to describe the "spec"
- checkins refer to bugs, as always.
sounds about right?
--david
Chris Ilias
> A reason Netscape named the News portion of the Communicator 4.x suite
> Collabra was a view to news being a collaberation solution. Mial based
> discussion here withe the MailMan interface Mozilla.Org is using
> produced spotty results. David's postings are the only ones showing
> both in the news group and dropping into my e-mail. I am not subscribed
> to the list-serv. With that spotty communication I am only getting his
> side of content others reply to David by the list.
If you're not subscribed to the mailing list, you shouldn't be getting
messages from this newsgroup in your mailbox. The reason why you're
receiving David's messages via email, is because he's sending his
replies to the address of the person he is replying to, in addition to
the mailing list address (ie. Reply All). I don't think the
dev-apps-thunderbird mailing list is set to add the mailing list address
to the reply-to header of each post; so Reply All is a quick/easy way of
replying to the list.
What I'm saying is, it has nothing to do with Thunderbird, unless bug
45715 is fixed. :-)
IMO, for discussions, nothing beats newsgroups. But I suppose that would
be popular opinion in *here*. Those who prefer a different technology,
are likely to be using a different technology. As long as people are
willing to use different communications technologies, this shouldn't be
an issue.
Eddy Nigg (StartCom Ltd.)
> All this feedback is great. I'm happy to be more mailing list centric
> than I'd usually be, and to see how it works in practice.
>
> My current thinking is:
>
> - we use wikis to _describe_ what the feature should "look like"
> - we _discuss_ them on the mailing list
> - we _update_ the wikis with revised version as per the results of the
> discussion
> - we mention the updates on the mailing list, to let people know when
> those changes happen
> - we create bugs to track implementation of features, and the bugs can
> point back to the wiki pages to describe the "spec"
> - checkins refer to bugs, as always.
>
> sounds about right?
Chris Ilias
>
> - we use wikis to _describe_ what the feature should "look like"
> - we _discuss_ them on the mailing list
> - we _update_ the wikis with revised version as per the results of the
> discussion
> - we mention the updates on the mailing list, to let people know when
> those changes happen
> - we create bugs to track implementation of features, and the bugs can
> point back to the wiki pages to describe the "spec"
> - checkins refer to bugs, as always.
>
> sounds about right?
Yup. As long as everything is traceable.
Wayne Mery
precisely.
If anything "new" or odd-ball is contemplated one can post in
m.d.planning so those who have great experience supporting
communications mediums for mozilla-land can offer advice. One recent
discussion was
news://news.mozilla.org:119/VJidneknu-f0scXa...@mozilla.org
Ron K.
What got my attention was, I got a mail item from David that contained
His reply to Kent at the head of this thread. I had not made any
posting to the news group at that point. So why would a non-list address
be getting list mail ? Only guess is, I might have been in David's
collected addresses, but still unexpected Tb or Mailman behavior.
Robert Kaiser
> My current thinking is:
>
> - we use wikis to _describe_ what the feature should "look like"
> - we _discuss_ them on the mailing list
> - we _update_ the wikis with revised version as per the results of the
> discussion
> - we mention the updates on the mailing list, to let people know when
> those changes happen
> - we create bugs to track implementation of features, and the bugs can
> point back to the wiki pages to describe the "spec"
> - checkins refer to bugs, as always.
>
> sounds about right?
I think this is one of the best descriptions of the Mozilla community
collaboration I've read so far - just spread in IRC for real time
communication somewhere and it's about complete ;-)
Robert Kaiser