Changes to review policy
mkmelin+mozilla at iki.fi
Sun May 1 19:57:20 UTC 2016
In addition to Kent's points I think at the heart of the proposal there
are many reasons it's not likely to work out.
You say you don't, but basically you do in reality propose a
"not-change-a-thing" policy. I'm not a big believer in prefs in general
- if it doesn't really work out of the box it just doesn't work.
Re #3: users won't really have any way to say if they like a feature or
not before trying it out for a period so adding some click-through is
Re #4: personally I think the migration wizard we had at some point was
a major mistake. It builds on the assumption that people read these
pages, and they really don't (nor should they have to). Plus the effort
put into it was absolutely huge, especially in comparison to the small
impact it had.
On 28.04.2016 08:33, Jim Porter 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
> 1) No data/program state should be lost.
> 2) Before changing a default, we should be sure the new default is
> 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.
> - Jim
More information about the tb-planning