How to work with RedMine? (.)

Share
Tuesday, December 3, 2024

Team Polaris

Please read this carefully!
We assume that you have attended a RedMine training session before you start working with it.

Basic principles:

  1. Only one bug, feature or support request must be reported in one ticket! Tickets describing multiple problems will be rejected and must be split by the author.
  2. The reporting language is English. You can also write the ticket description in another language but, in such case, you must also add an English translation. You can use DeepL, it works really fine.
  3. The assignee is responsible to handle the ticket. If you do not assign the ticket to somebody, nothing will happen. New tickets must be assigned to the Polaris Team members or the country coordinator or to the support center, depending on the support organization.
  4. All important changes of the ticket generate an e-mail to the author, to the assignee and to the watchers. This is how you get informed. There is no need to send e-mails! Do not reply to e-mail sent by RedMine! There are sent on-behalf and will not reach us.
  5. RedMine is the place to keep track of all types of tickets. It is possible that ticket remains open for very long time (years)! This is because we don't want to loose any information.

Priority definition for bugs:
  • Immediate = the system, or a part of it, is not running, not operational or not usable at all. Immediate = Mo-Fr. 8-16 action is required.
  • Urgent = the system, or a part of it, shows major errors. No workaround exists. The usability of the system is limited. Action is required within the next working days = ASAP.
  • High = a part of the system shows some errors. Some workaround exist. The system is usable. Fix is required in next deployment.
  • Normal = some functions of the system do not work correctly. workaround exists. The system is fully usable. Fix is required by end of the current release phase.
  • Low = suggestion for improvement. The issue has little or no impact on the function. Possible implementation is to be discussed or planned.

Please remember that Polaris is an application for organizing a voluntary activities of a NGO. It is not a "nuclear power plant" and its availability is not guaranteed.
The support is provided on working days 8-16.  Please keep this in mind when you assign priorities.

Reporting bugs and requesting support or new features.

The author crates a ticket in state "New" and describes the problem. These are the mandatory fields which must be set in order to process the ticket.

- Subject = unique, specific and descriptive text identifying the problem. Be precise!
- Description = What happened and how to reproduce?
Which steps led to the problem?
What are the steps you did before it happened?
Attach screenshots! (drag & drop works fine)
- URL = link to the page in BE or FE

When the information is incomplete or misleading, we will return the ticket back to you with a request to complete it. Please save your and our time and do it right from the very beginning.

The Polaris team is then automatically notified, will handle the ticket and set the new status to either:

  • "In progress" - The ticket has been considered for development. The implementation may be in next release or sooner, depending on time & budget.
    ... the implementation is running then ...
    Depending on the ticket type it may take from few days to several months, until the ticket comes back to you. If you write new comment to the ticket, Polaris team will be notified.

  • "Postponed" - The ticket is a valuable input and we want to keep it for the future, but there is no possibility to implement it now or soon. It may be implemented at some later time. Postponed tickets are periodically re-evaluated by the Polaris team. If you write new comment to the ticket, Polaris team will be notified only if you add it as watcher.

  • "Closed" - is coming back to you because no implementation will happen. The reason is described in the ticket.  If you do not agree, you can set the status "New" and assign it back to the Polaris team.

... When the implementation or solution is finished ....

  • "To be tested" - is coming back to you because it has been finished and deployed and should be re-tested by you now.

    If  your test fails, or you are not satisfied with the answer, you can set the status "New" and assign it back to the Polaris team . The Polaris team will re-evaluate it and decide again. The Polaris Team can also override your answer and close it again with an explanation. When further improvement is required, a new ticket must be created in order to track issues independently.

    If  you have successfully tested the issue, set the state "Closed" and clear the assignee.  This is a final state of the issue. Closed tickets should not be re-opened. If needed a new ticket must be created.

Process flow

Tips and Tricks:
  • Get familiar with the RedMine functionality.
  • Learn how to search for tickets.
  • Learn how to follow conversation.
  • Create your own queries to get information you need.
  • Always assign the person who should handle the ticket.
  • Add watchers if you want to inform others. (you can also add a group as a watcher)
    As an author you will be informed by e-mail in any case.
  • Use #nnnn to reference tickets in text.

If you do not use RedMine for longer than 12 months, your account will be removed. You will be notified before.

We understand the user frustration in a case of an error. However we need a precise description, plus as much material as possible to identify and find the problem. In order to increase the chance to find and correct the error soon, please:

  • Keep cool, handle the case without emotions.
  • Work systematically. Do not jump from one topic to another.
  • Communicate precisely, use common terminology.
  • Write down what you have done, later you will not remember the exact steps.
  • Do not continue any further processing if not absolutely necessary in case of an error. Other errors may subsequently happen.
  • Do not repeat the case again and again. It will be more difficult to read its trace.
  • Save all material, notes, screen shots in one place.

For convenience you can view the flow as large image here

Process flow

State transition by actor