On 29/06/2008, at 11:12 PM, Joost Andrae wrote:
Hi Per, I've added the IssueTracker role for you. Kind regards, JoostDoes anyone know how to get the CANCONFIRM role in IssueZilla?I would like to be able to confirm issues, and maybe also change component/subcomponent if I know it's incorrect.Can anyone do this for me? :)
So, if any member of this QA team wants to be able to confirm issues [1], s/he only needs to request that right here. Normally, we will only grant that right once you have gained some experience in testing bugs and have a reasonable understanding of the OpenOffice.org QA process. So, start testing issues! :)
from Clytie Vietnamese Free Software Translation Team http://vnoss.net/dokuwiki/doku.php?id=projects:l10n [1] UNCONFIRMED -> NEWAll issues start out as UNCONFIRMED, which means someone has reported them, but we don't know if this is a genuine problem or not. Inexperienced users sometimes report situations which aren't bugs, e.g. I processed a bug the other day where the user complained that OpenOffice.org didn't automatically open a text document each time the application booted. This is not a bug, since OpenOffice.org provides many different types of documents, and offers you a choice of which type of document to open. Spreadsheet or database users, for example, would be very annoyed if OpenOffice.org always opened a text document.
So, to be able to decide if an issue is a genuine bug or not, you need to have experience using OpenOffice.org, and understanding of its purpose. If a bug is not a genuine problem, we mark it INVALID. If it is indeed a genuine problem, we mark it NEW. If we can't reproduce the bug in the latest build of OpenOffice.org, we mark it WORKSFORME (using which build on which system). The developers responsible for that issue will decide when it has been FIXED, but the information that that function works OK on your system is very useful to them.
If you are a coder, you can take responsibility for fixing an issue marked as NEW (genuine), by accepting it and marking it as STARTED. You can ask for help in fixing this bug, but it is your responsibility. Write your patch and submit it: you'll need to ask about the procedure for integrating it into a child workspace (CWS), to be tested prior to integration into the main codeline.
Other common changes to issues are marking them as a _duplicate_ of another, previously or better-described issue (I found two duplicates of the same previous issue, the other day), or marking an issue WONTFIX, because the user is requesting something unreasonable, not useful or not part of the OpenOffice.org development goals. LATER means the issue is not dismissed, but it is postponed, due to lower priority or changes in the development roadmap. REMIND means make sure we don't forget this one later on.
PGP.sig
Description: This is a digitally signed message part
