I'd really like to get the process passed as official, put it on our wiki
page, and encourage people to report UX bugs.
Since none of you replied to the original message, please give input before
next Saturday 17:00 UTC. If nobody has any problems with it by then, I'll
just pass it off as official.
(It will, of course, still be modifiable afterwards, but not as easily.)
On Wed, Sep 11, 2013 at 7:02 PM, Mirek M. <email@example.com> wrote:
I'd like there to be a clear step-by-step guide on how to report UX bugs.
Unfortunately, I don't really know how to report these bugs myself, so I'd
like to work with all of you to devise a clear process.
Fabiana Simoes lays out the ground rules in her "How to not report your UX
bug" GUADEC talk . Her presentation talks about how UX bugs should
center on a problem rather than on a proposed solution. To give a real-life
example, the summary of a UX bug should be "Non-printing Characters are Not
Set Apart from Text" rather than "Give non-printing characters a color
different from the text", as the former describes the problem, encourages
discussion around the best solution, and makes the reasoning behind the
picked solution clear, whereas the latter proposes a solution right away
without questioning if it is the best solution.
As a start, I'd propose these guidelines:
1) In the Summary/Subject field, describe the problem, not the solution.
Rather than saying "X should be Y", say "I can't figure out how to X" or "I
expected X, but Y happened".
*The pieces of information that Fabiana says a user should provide 
are basically covered by the Bug submission assistant , but should be
mentioned in the guidelines nevertheless:
2) In the Description, mention what you were trying to accomplish, how you
tried to accomplish it, what you expected to happen, and what actually
3) In an additional comment, feel free to propose a solution. If your
proposal is long or includes mockups, put it on your user page on the TDF
wiki (https://wiki.documentfoundation.org/User:[your user name]) and
provide a link to it in the comment instead.
In regard to Whiteboards, the design team may decide to make one for a
bug, but I'd rather leave them out of the guidelines, as I don't want to
see a load of whiteboards being created without approval.
The solution should be agreed upon based on discussions in the bug
comments, on the design list, and on our IRC chats (all of which should be
linked to in the bug comments), using our UX principles  and guidelines
 to resolve controversies.
I'd also like to ask: What is the role of the ux-advise mailing list? Is
it a place for devs to ask designers for UX help or a place where designers
and devs can ask each other questions? When should a bug be tagged
"ux-advise"? Is it a component that should be used for all UX/UI bugs, both
confirmed and unconfirmed, until a solution is agreed upon?
P.S. elementary's UX bug process is also worth a look:
* What were you trying to do?
* Why did you want to do it?
* What did you do?
* What happened?
* What were your expectations?
* What are you running?
To unsubscribe e-mail to: firstname.lastname@example.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy