Re: [Libreoffice-qa] [libreoffice-accessibility] 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 libreoff...@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+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/
Re: [Libreoffice-qa] [libreoffice-accessibility] Adding Accessibility component to Bug Assistant
Rainer Bielefeld píše v Pá 31. 08. 2012 v 06:36 +0200: 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. Well, I think think that most bugs will be about that accessibility does not work at all or that it does not work for some particular UI elements. I think that most bugs will affect all LO applications and will be in the shared code = the component would be fine after all. I would imagine that we get an expert interested for these bugs. So I currently think about a Bug Submission Assistant enhancement. We can add a checkbox Accessibility affected, and the Assistant will add Accessibility Interesting idea; Well, it does not solve the problem when people report bugs directly into bugzilla. 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? After all, my preference is: d a b c d - is easiest for implementing and also for using by disabled users; it would work well a - is natural; people would mention this word anyway in the summary b - we use whiteboard in many other situations already c - keywords are not much used these days = non-standard solution Best Regards, Petr ___ 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/
Re: [Libreoffice-qa] [libreoffice-accessibility] Adding Accessibility component to Bug Assistant
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 i...@titengodocchio.it To: libreoff...@bielefeldundbuss.de Cc: Roman Eisele p...@roman-eisele.de; Marc Paré m...@marcpare.com; libreoffice-qa@lists.freedesktop.org; accessibil...@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 libreoff...@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+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 -- 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/
Re: [Libreoffice-qa] [libreoffice-accessibility] Adding Accessibility component to Bug Assistant
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 tomdavie...@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 i...@titengodocchio.it To: libreoff...@bielefeldundbuss.de Cc: Roman Eisele p...@roman-eisele.de; Marc Paré m...@marcpare.com; libreoffice-qa@lists.freedesktop.org; accessibil...@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 libreoff...@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+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 -- 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 -- Unsubscribe instructions: E-mail to accessibility+h
Re: [Libreoffice-qa] [libreoffice-accessibility] Adding Accessibility component to Bug Assistant
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 ___ 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/
