Re: Fwd: Application of UIFEs

2012-10-14 Thread 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 
> To:   product-strat...@lists.canonical.com
> CC:   Sebastien Bacher , Didier Roche
> , Jason Warner ,
> iain.l...@canonical.com, kate.stew...@canonical.com, Cristian Parrino
> 
> 
> 
> 
> 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

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release


Fwd: Application of UIFEs

2012-10-14 Thread John Lea
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 
To: product-strat...@lists.canonical.com
CC: 	Sebastien Bacher , Didier Roche 
, Jason Warner , 
iain.l...@canonical.com, kate.stew...@canonical.com, Cristian Parrino 





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.

cheers,
John








-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release