Directions for Thunderbird
Ben Bucksch
I would like to suggest some directions for the future of Thunderbird.
It's a high-level view, in the lines of "If I had to make the future of
Thunderbird, what would I do?"
Calendar
Currently, there is no real open-source proposal for email in companies,
at all. Companies need a calendar, and we have code in form of
Lightning, but we didn't integrate it. There are interesting proposals
from the server side, open-source shops creating an integrated server
for email and calendar. While we'll have a hard time to make a dent in
Outlook and Exchange, we should at least offer something that companies
*wanting* to use open-source can use. With the existing code, plus a
community, I think it wouldn't be too hard to tackle.
Chat
I personally would build Thunderbird into the chat direction, using
Jabber, with extensions to reach many people at once. Twitter and
Facebook are popular in part because it's easy to make quick small
messages to many people. Facebook and GMail both support Jabber, so
there are servers and there is interoperability with the popular
services. As for code, I recently wrote an XMPP client protocol
implementation using chrome JS and nsISocketTransport for a customer, I
just have to convince them to open-source it. As UI, we could use code
from InstantBird.
News
I spend a good deal of my day reading newspapers, on the web. In the
browser. I am still lacking an RSS client that's working well for me.
Thunderbird would be in a very good position for that. Myk's prototype
that he showed at Firefox Summit 2008 was perfect, IMHO.
Reading
Myk's prototype also really innovated in the way messages are prevented,
making email reading a lot more efficient, in a way that will be hard
for most webmail. *Please* please pick this up, including his
dramatically different user interface and code design.
When Linus switches to GMail web interface, surely not because he likes
webmail, but because it's more efficient - that shows that we have grace
technical deficiencies. We need to analyze those and swiftly fix them.
Andrew Sutherland has been great for that.
Andrew also likes to visualize things. *Please* let him innovate freely,
free him from any barriers (including review), and give him assistants.
I think of how he wanted to use drag&drop to select messages, show
relations etc.. He can innovate things for TB that will make people
"wow", which will be highly efficient in everyday usage, and which will
be hard for webmail to copy.
Dev process
For the "swiftly" part, I feel like Thunderbird's development process
makes it impossible to contribute. When MoMo was created, with Mark
Banner, Andrew Sutherland, dmose, and many others, I felt a new,
innovative spirit. But when trying to contribute, it turned out to be
impossible. Innovations (including contributions with 1000 lines of
code) are stopped short to a screeching halt in their tracks by the
review nit-picking procedures and test requirements. I for myself have
concluded that it's impossible to contribute, although would have liked
to. This must change for TB to be alive, which is a pre-condition for it
to survive.
Outreach
I also think we should do more advocacy. Facebook sure does make efforts
to advocate its use, the "like it" buttons are partially just there to
let Facebook be in people's face. It's good that F1 is countering that.
Be we should reach out and educate users about the advantages of our
approach.
Hope this high-level view from me starts a few constructive thoughts and
that they'll be put into action.
Thank you,
Ben
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
Ben Bucksch
> Reading
> Myk's prototype also really innovated in the way messages are prevented
Correction: presented.
> that shows that we have grace technical deficiencies.
grave
> advantages of our approach.
our = email client, that being decentralization, implicit better
privacy, higher efficiency in UI and features, more control, and
community contribution.
Jonathan Protzenko
> News
> I spend a good deal of my day reading newspapers, on the web. In the
> browser. I am still lacking an RSS client that's working well for me.
> Thunderbird would be in a very good position for that. Myk's prototype
> that he showed at Firefox Summit 2008 was perfect, IMHO.
something? I was planning on doing a quick experiment with a
dashboard-style tab for RSS reading, I'd be happy to build upon any
preexisting mockups.
Andrew Sutherland
> When Linus switches to GMail web interface, surely not because he
> likes webmail, but because it's more efficient - that shows that we
> have grace technical deficiencies. We need to analyze those and
> swiftly fix them. Andrew Sutherland has been great for that.
>
> Andrew also likes to visualize things. *Please* let him innovate
> freely, free him from any barriers (including review), and give him
> assistants. I think of how he wanted to use drag&drop to select
> messages, show relations etc.. He can innovate things for TB that will
> make people "wow", which will be highly efficient in everyday usage,
> and which will be hard for webmail to copy.
Thank you for the kind words! I assure you I have been given the
latitude to innovate freely. (I'm pretty sure I never wanted to use
drag&drop to select messages though! :) My innovation money is
currently on :protz and :squib, but others are closing in on them >;).
:protz has been doing fantastic fast-paced work on Thunderbird
Conversations, and :squib has been churning out a stream of excellent
and significant usability enhancements to the existing Thunderbird UI.
:bwinton has also been doing great things with open search and other
extensions, and Thomas Schmid has been fancying up our tabbed interface
which had fallen way behind the state-of-the-art and now is
leap-frogging Firefox in some ways! And these are just the things I am
aware of...
As you note, Thunderbird has a lot of technical deficiencies. I believe
this is because it has a lot of technical debt, which leads into my next
point...
> Dev process
...
> Innovations (including contributions with 1000 lines of code) are
> stopped short to a screeching halt in their tracks by the review
> nit-picking procedures and test requirements. I for myself have
> concluded that it's impossible to contribute, although would have
> liked to. This must change for TB to be alive, which is a
> pre-condition for it to survive.
...which is that I believe that code review and tests (and code
comments) are critically important for us to improve the technical debt
situation and we should not relax review or test requirements in the
name of speed or innovation. I completely agree that they can be
demoralizing, but the alternative is potentially much worse for the product.
In fact, I would argue that our testing requirements are a net benefit
to potential new contributors in the sense that they make it easier for
everyone to ensure that a patch does not break existing functionality
and that its new functionality does what it promises to do. The review
burden of even a one-line patch in an untested component that does not
come with its own tests is a function of the complexity of the component
and its interactions with the rest of the system, not of the single line
that is changed. And there is a *lot* of complexity and high levels of
coupling throughout large swathes of Thunderbird (the previously
mentioned technical debt).
The fallout of this is that making large changes to Thunderbird,
especially in the areas that have not gained a lot of test coverage
requires a sizable burden of tests. This does tend to result in a
catch-22-like situation; no one wants to touch components without tests
because of the huge initial test burden required, so no one writes tests
for the component. The flip-side is that at least those areas aren't
gaining complicated new regressions. But it's not a true catch-22;
people just need to write tests for those areas. (Unfortunately, it's a
lot of tests and there are cost/benefit reasons to not lock everyone
with back-end experience in a room and tell them to write tests for
several years straight.)
Having sung the praises of tests and review, let me say that I recognize
there are at the same time weaknesses in our current test framework
documentation, tests, and review tools. A test that fails and you don't
understand why is not extremely helpful (but can still be useful).
Likewise, the mechanics of the review process in bugzilla can be sucky.
Various efforts are going on to try and improve these things; some by
me, some by others. While my review board instance (see
http://www.visophyte.org/blog/tag/review-board/ and consider installing
the "Bugzilla Tweaks" extension for its "review" link it adds to the
attachment list which links to it) is probably still the best option for
improving reviews at the immediate moment, MoCo has hired 2 fulltime
bugzilla hackers, who should hopefully fix up the review situation
lickety split. Test documentation-wise, :protz has been looking into
using jsdoc, and if that doesn't work, we will try some other options.
Test failure logging improvements are being pursued with my ArbPL work
(see http://www.visophyte.org/blog/tag/arbpl/ and keep following
tb-planning), plus MoCo has awesome QA and Automation teams doing
development work that should be applicable to Thunderbird too!
Andrew
Archaeopteryx
https://addons.mozilla.org/firefox/addon/mozilla-labs-snowl/
My usage pains which also affect other users:
1) Lack of multi-account handling. If you have only one account, it is
fast to do everything in web mail. Thunderbird offers good possibilities
as aggregator, but fails on simple things like setting the correct mail
identity when replying.
2) In news groups: No view which shows all messages of a thread in a
single view. It's a pain to see an interesting thread and have always to
click in the message list, move the mouse to the message pane, scroll,
go back to message list etc.
3) RSS is more tricky: Thunderbird is useful for low volume feeds, but
in high volume feeds like news, you are likely to miss items if your
machine doesn't run 24/7. Web aggregators like Google Reader and Tiny
Tiny RSS try to aggregate all items, but lack customization and guidance
for the user (like filtering out duplicates from multiple feeds, saved
searchs, filtering and moving to priority folder, deleting ranges which
you read etc). Currently, RSS is in a mediocre to unusable state (you
cannot filter feeds and move the items to a local account because the
content won't show up - which is itself a workaround to Thunderbird
having to customized favorite folder view in which you could (put and?)
_sort_ the folders like you want them).
The ideal for Thunderbird imho would be a data aggregation and
communication central.
@Ben: Why did you write a XMPP client? Was
https://addons.mozilla.org/thunderbird/search/?q=xmpp&status=4&sourceid=Mozilla-search
not good enough?
@Jonathan: Glad to see you having interest in improving the RSS component.
Bye
Sebastian
schrieb Jonathan Protzenko:
Mark Banner
> On 04/02/2011 12:04 AM, Ben Bucksch wrote:
>> Dev process
> ...
>> Innovations (including contributions with 1000 lines of code) are
>> stopped short to a screeching halt in their tracks by the review
>> nit-picking procedures and test requirements. I for myself have
>> concluded that it's impossible to contribute, although would have
>> liked to. This must change for TB to be alive, which is a
>> pre-condition for it to survive.
>
> ...which is that I believe that code review and tests (and code
> comments) are critically important for us to improve the technical
> debt situation and we should not relax review or test requirements in
> the name of speed or innovation. I completely agree that they can be
> demoralizing, but the alternative is potentially much worse for the
> product.
to continuously improve Thunderbird and move it forward.
Although tests can be a pain to write, sometimes taking longer than the
fix, they also catch errors and regressions - the majority of these I'm
sure we don't even see in the main source repo because we run the tests
before check in. For example, Mike is looking at removing RDF from the
address book, I'm going to be reasonably confident that we're not going
to see big regressions for at least the mork/local part of the address
book because we currently have a lot of tests which cover getting
address books, mailing lists (iirc) and other address book functions. If
we didn't have that, I'd be a lot more concerned about it.
I also think that over the last couple of months we've got a bit more
used to new contributors and we're generally more willing to help with
tests - its not just r- this needs tests, but typically this needs tests
and here's where to get information on them and here's some examples (or
in some cases, we'll actually do the tests or templates for the tests).
Mark.
Ben Bucksch
>
>> News
>> I spend a good deal of my day reading newspapers, on the web. In the
>> browser. I am still lacking an RSS client that's working well for me.
>> Thunderbird would be in a very good position for that. Myk's
>> prototype that he showed at Firefox Summit 2008 was perfect, IMHO.
> Any links to that prototype, or screenshots, or HTML mockups, or
> something?
It was Snowl
<http://hg.mozilla.org/labs/snowl/>
Karsten Düsterloh
> Dev process
…
> But when trying to contribute, it turned out to be
> impossible. Innovations (including contributions with 1000 lines of
> code) are stopped short to a screeching halt in their tracks by the
> review nit-picking procedures and test requirements.
Part of the problematic state of /mailnews is the *lack* of such
requirements in the past. Dumping scarcely reviewed code inside a
codebase just because "it (mostly) works" is not a solution, it only
leads to major pain afterwards.
I agree, though, that writing meaningful tests often requires knowledge
of code dependencies which newbies usually don't have — probably even
much more knowledge than the limited scope of the bug they're fixing …
The actual patch probably should not necessarily be blocked by a missing
test, if the test still to come. (Yes, may be hard to tell.)
Karsten