Fwd: Application of UIFEs

[Scott Kitterman]

On Friday, October 05, 2012 11:54:01 AM John Lea wrote:
> Forwarding to ubuntu-release,ubuntu-doc,and ubuntu-translators at Iain
> Lane's suggestion.
> 
> 
> -------- Original Message --------
> Subject: 	Application of UIFEs
> Date: 	Fri, 05 Oct 2012 11:28:19 +0100
> From: 	John Lea <john.lea at canonical.com>
> To: 	product-strategy at lists.canonical.com
> CC: 	Sebastien Bacher <sebastien.bacher at canonical.com>, Didier Roche
> <didier.roche at canonical.com>, Jason Warner <jason.warner at canonical.com>,
> iain.lane at canonical.com, kate.stewart at canonical.com, Cristian Parrino
> <cristian.parrino at canonical.com>
> 
> 
> 
> Hi All,
> 
> Over the past week there have been a couple of cases where bug fixes
> have been IMHO incorrectly marked as requiring UIFEs.
> 
> UIFEs are an important process step to make sure that string changes are
> translated and that users reading documentation are not confused.
> However visual bug fixes that do not involve string changes or bug fixes
> will not cause any user confusion if the documentation is not updated
> should not require a UIFE.
> 
> Two of the examples from last week are:
> 
> #1043808 - Preview activation doesn't have instant feedback
> 
> #1052513 - 'More suggestions' icons in App Lens are too large
> 
> In the case of the first bug, although adding a loading spinner is a
> visual change, if the documentation is not updated users will not be
> confused.  This change also has no translation impact.
> 
> In the case of the second bug, making the 'More Suggestions' app icons
> in the App Lens the correct size and thus fixing the bad pixelation will
> again not confuse users even if the documentation is not updated, and
> also this bug fix has no translation impact.
> 
> Over zealous application of the UIFE rules increases the likelihood that
> fixes to bugs like these will not land in Quantal.  I hope that we can
> take a more pragmatic approach when considering which bugs do or do not
> require a UIFE, and consider the total impact on all Ubuntu users of
> landing or not landing a bug fix, and not just the documentation impact.
> 
> For example should we choose:
> 
> a) perfectly consistent documentation with badly pixelated app icons in
> both the documentation and the App Lens for the Quantal cycle.
> 
> b) to fix this bug in the App Lens even though the documentation would
> then become slightly inconsistent with the implementation?
> 
> A yardstick to help make this choice could be "will the user be confused
> by this documentation inconsistency".
> 
> Of course the root cause of these problems is how late all the features
> have been landing this cycle.   Ideally all the features that are
> landing into a release should be complete by Feature Freeze; this would
> then give us enough time to really reduce the number of bugs we are
> seeing at this point in the cycle.  However this is a different (and
> also very important) discussion.

You misunderstand the purpose of UIF and there is time between feature freeze 
and UI freeze precisely to work out UI affecting bugs.  I believe you are 
trying to solve the wrong problem.

I agree it is a problem that so many bugs needed review for a UIFe, but I 
think the root of that problem is that PS landed so much, so late.  The 
bureaucracy is much easier if you get your stuff in on time.  

Scott K