[Libreoffice-qa] [libreoffice-accessibility] Adding "Accessibility" component to Bug Assistant

Alex Midence alex.midence at gmail.com
Fri Aug 31 06:27:13 PDT 2012


Hi,

As I've been rather vocal on this issue in the last couple of days in
particular, I'd really like to be in a better position to lend a hand
with any proceedings.  Can anyone point me to some docs to look over
for bug reporting in LO?  And, does the user account creation
mechanism for the bug reporting site have one of those abominable
captcha thingies on it?  It's always been a barrier to me before since
I can never, for the life of me make out the audio challenges.  After
the third or fourth time I replay it, I  am ready to toss the old pc
out the window to the accompaniment of mad cackling and jumping up and
down in maniacle glee.

Alex M

On 8/31/12, Tom Davies <tomdavies04 at yahoo.co.uk> wrote:
> Hi :)
> In bug-reports there are several drop-downs.  One has "feature request" and
> i think another has "Easy hack"?  Would one of those be better than the
> other?  Which of those was which option of the a, b, c etc?
> Regards from
> Tom :)
>
>
>
>
>
>
>
>>________________________________
>> From: Ti tengo d'occhio <info at titengodocchio.it>
>>To: LibreOffice at bielefeldundbuss.de
>>Cc: Roman Eisele <post at roman-eisele.de>; Marc Paré <marc at marcpare.com>;
>> libreoffice-qa at lists.freedesktop.org; accessibility at global.libreoffice.org
>>
>>Sent: Friday, 31 August 2012, 10:35
>>Subject: Re: [libreoffice-accessibility] [Libreoffice-qa] Adding
>> "Accessibility" component to Bug Assistant
>>
>>Hi Rainer,
>>
>>well, I didn't know that there were developers focused on specific
>> components; in this case adding an "accessibility component" won't be the
>> best thing to do, in my opinion…
>>
>>> At this point I think we could go for solution C or solution A; in case
>>> of solution A, would it be possible to view all issues with the
>>> pseudo-keyword "accessibility"?
>>
>>However I think that solution C could be very suitable; in drupal, for
>> instance, to report accessibility issues there are two special tags:
>>- Accessibility: it means that this is an accessibility issue (it could be
>> a bug, a feature request, a task, etc etc) ;
>>- "needs accessibility review": this means that the issue or the patch to
>> solve it needs to be tested by a blind user or an accessibility expert.
>>
>>Now we could choose to use only the "accessibility" keyword or maybe both
>> "accessibility" and "needs accessibility review", I don't know; but also
>> using just the first keyword would be a great thing…
>>
>>               Vincenzo.
>>
>>Il giorno 31/ago/2012, alle ore 06:36, Rainer Bielefeld
>> <LibreOffice at bielefeldundbuss.de> ha scritto:
>>
>>> Ti tengo d'occhio schrieb:
>>>
>>>> in my opinion it would be great to have a component for accessibility;
>>>> it could let developers to better focus on accessibility bugs and, on
>>>> the other hand, blind people to know that accessibility is important for
>>>> this project and that submitting bug reports of this type is more than
>>>> encouraged…
>>>
>>> Hi,
>>>
>>> the advantage of an "Accessibility" Component would be that it can easily
>>> be selected from a pulldown, no typos or other mistakes can happen.But a
>>> problem is that an "Accessibility" Component would not indicate what
>>> developer might be the one who can fix the problem. So it always would be
>>> replaced during the bug triaging and fixing process.
>>>
>>> An other possibility would be a Whiteboard entry, but that only can be
>>> done after a report in a second step, typos might happen, it is too
>>> modest.
>>>
>>> So I currently think about a Bug Submission Assistant enhancement. We can
>>> add a checkbox "Accessibility affected", and the Assistant will add
>>> "Accessibility"
>>> a) as additional pseudo key word to the Bug Summary line. The advantage
>>> of this solution is that the key word would be very visible.
>>> or
>>> b) as additional pseudo key word to the whiteboard
>>> or will
>>> c) set Key word "Accessibility" to the Keyword pane (it should not be a
>>> problem to get this new key word from FDO). The advantae of this solution
>>> is that it also eases and unifies handling in Bugzilla itself, not only
>>> via BSA.
>>>
>>> And of course
>>> d) New Component "Accessibility"
>>> still can be discussed.
>>>
>>> My order of preference (descending):
>>> c - a - b - d
>>>
>>> Your opinion?
>>>
>>> When we have a solution here, we can start to mark and process
>>> accessibility bugs with increased priority.
>>>
>>> Best regards
>>>
>>> Rainer
>>>
>>>
>>> --
>>> Unsubscribe instructions: E-mail to
>>> accessibility+help at global.libreoffice.org
>>> Problems?
>>> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
>>> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
>>> List archive: http://listarchives.libreoffice.org/global/accessibility/
>>> All messages sent to this list will be publicly archived and cannot be
>>> deleted
>>>
>>
>>
>>--
>>Unsubscribe instructions: E-mail to
>> accessibility+help at global.libreoffice.org
>>Problems?
>> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
>>Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
>>List archive: http://listarchives.libreoffice.org/global/accessibility/
>>All messages sent to this list will be publicly archived and cannot be
>> deleted
>>
>>
>>
>>
> --
> Unsubscribe instructions: E-mail to
> accessibility+help at global.libreoffice.org
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/accessibility/
> All messages sent to this list will be publicly archived and cannot be
> deleted
>


More information about the Libreoffice-qa mailing list