Matthias Clasen <[email protected]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
