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
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+h...@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
>
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
