Re: Improving Quality

[Allan Day <allanpday gmail com>]

Matthias Clasen <matthias clasen gmail com> wrote:
...
> I think this is a great idea. When we discussed this at Guadec, I got
> the impression that we should use this to draw attention to
> longstanding UX annoyances, early enough in the cycle to address them.
> Here is a short list of (my personal) candidates for this category:
>
> 728496 evolution-data-server - Gnome shell keeps poping modal dialog
> for gmail password
> 710848 polari - private messages vs shell chat
> 705177 gnome-shell - Full-screen apps disappear on Alt+Tab

We'll need some guidelines for which bugs we include, and for what the
list should look like as a whole. My idea for this would be something
like:

 * Bugs should affect user experience quality - commonly experienced
papercuts, lack of polish, or enhancements that would make a positive
difference.
 * Only bugs from core applications and modules should be included.
Priority should be given to the most generally visible issues.
 * Bugs shouldn't be allowed to linger on the list without an
identifiable solution.
 * The vast majority of the bugs should be in a fixable state.
 * At any one time, the list shouldn't be longer than 40 [?] issues.
 * The list should contain a mix of issue types, ideally including a
combination of easy polish fixes and more difficult tasks.

There are possibilities to be systematic about which issues we
prioritise. I'd really like to have scheduled walkthroughs during the
development cycle, for example - and we could use those to populate
the list. Likewise, user testing results or results from QA testing
could be fed in. Of course, if we do that, the list could get quite
long - so that would require some thought.

Allan