Changes to review policy

Tanstaafl tanstaafl at libertytrek.org
Thu Apr 28 19:07:54 UTC 2016


A huge +1 from me on your proposed changes.

Scroll down for why...

On 4/28/2016 1:33 AM, Jim Porter <squibblyflabbetydoo at gmail.com> wrote:
> Therefore, I'd like to propose the following: any change to
> Thunderbird's defaults should have a super-review before landing.
> Super-reviewers would be especially focused on making sure that changes
> meet most or all the following conditions, in descending order of
> importance:
> 
> 1) No data/program state should be lost.
> 
> 2) Before changing a default, we should be sure the new default is
>    fully-operational.
> 
> 3) Users should have an easy path to roll back to the previous UI/UX if
>    they don't like the new version. If possible, ask the user *before*
>    upgrading them.
> 
> 4) It should be easy for users to find out what's changed, along with
>    instructions for how to adjust the new behavior to their liking.
> 
> Of course, I understand the desire to ship new features, especially if
> we think they're better than the old ones, but we need to be very
> careful. Email is mission-critical for many people, and as such, we have
> a responsibility not to break things. Hopefully with a few more eyes on
> changes like this, we can come up with ways to satisfy existing users'
> needs while still working to modernize Thunderbird.

Couldn't agree more.

As for these most recent events - Correspondents column and HTML
composition <P> change - I didn't like either of them at first, but now
I think I actually do prefer both. So, I understand a little better the
motivation to change a default - people may not ever even know about a
change, otherwise.

While some changes are more or less annoying than others, one older
event comes to mind that made me spend at least a week looking very
seriously for an alternative to Thunderbird...

I can't remember the exact version, but I think it was one of the minor
releases after v3... but, it was when someone decided it was a good idea to:

a) enable GLODA globally for all IMAP accounts
and
b) ignore any/all users carefully selected per-folder offline settings
and unilaterally set them all to full offline mode.

I routinely have 15+ IMAP accounts, many with multiple GB of email, and
rather than having 50+ GB of mail stored locally, I only want a few
select folders set to full offline mode. I have very little use for
searching in the bodies of emails, so this is a satisfactory solution
unless/until bug ### is implemented allowing Thunderbird to take full
advantage of body searches only using server side indexes.

Anyway, when this happened, Thunderbird was basically unusable for more
than a day, because that is how long it took me to figure out what
happened, and how to fix it.

It then took me the better part of another day to get all of my offline
settings back to how I wanted them, but as I said, I was so furious that
I was determined to do away with Thunderbird, so started looking for an
acceptable alternative. I was unable to find anything even close to as
good, and I eventually got over my anger, and thankfully Thunderbird has
improved dramatically since then.

So, if a developer feels strongly enough about a new feature and wants
to make it a new default, it should be their responsibility to provide
the code to save the users prior settings (if applicable) and/or provide
an easy way to revert the change. I think it would help adoption (less
people reverting the new default) if they recorded a short video
presentation on the new feature, explaining how to use it properly
and/or why it is better, and this could be displayed/linked to
prominently in the release notes.


More information about the tb-planning mailing list