General settings


Roles and Workflow

No customization has been set up for roles. The original workflow has been slightly modified. In general, developers permissions has been increased and Non members permissions has been reduced.


These are the topics that are not self explained.


The following trackers (type of tasks) have been globally configured in Redmine:

  • action: what we commonly recognize as task
  • analysis: evaluation, analysis, study of a situation, a problem...
  • coordination: management, meetings, etc.
  • communication: marketing, discussions, talks, presentations, conferences, social community work
  • report: elaborate, develop and present reports, conclusions, etc.

They can be disable for each project. New ones can be created for each project too.

Tracjker update

Some months after setting the above trackers, in order to simplify the usage of the tool, the openSUSE Team decided the following:

The openSUSE team will use only by default we will only use one tracker:

  • Action

The rest of the trackers will be deprecated when the current projects are finished or the tasks assigned to them are closed. It has been disabled some trackers from some of our projects so they should not show up as option. Instead of separating the tasks by tracker we will do it by category so:

  1. Tasks defined before as communication (tracker) now will be assigned to marketing (category)
  2. Task defined before as analysis (tracker) now should fit in one of the categories depending on the case
  3. Task defined before as report (tracker) now should fit in one of the categories depending on the case. Hint: documentation might work in some cases and management in others.
  4. Task defined before as coordination (tracker) now will be assigned to management (category)


  • Immediate: Crisis, drop everything
  • Urgent: On our way to crisis. The controller or manager should know about this.
  • High: somebody needs this to be done, please work on it as soon as possible.
  • Normal: default state of tasks. Work on it.
  • Low: Nice to have but we can skip it. Work on it if you have time.

Nice reading about the difference between urgent and important


The status of any task are:

  • New: the task is created but nobody is working on it.
  • In progress: the task is being done by somebody. The task must reflect the percentage of the task that is done.
  • Feedback: the task is done but somebody is checking it. The task needs that somebody else check that the partial work done so far is accurate. The task needs information (not action) from somebody to keep going).
  • Resolved: the task is done.
    • In order to avoid Resolved tasks showing up in the default views until the controller close it, we have set up the Resolved status as closed.
  • Closed: the controller verifies that the task is done, and the percentage and spend time is filled and correct.
  • Rejected: the assigned person send d back the task to the author for the reasons below. The rejection must be clearly justified.
    • Is not able to do it
    • Is not the right person to do it
    • Thinks that the task do not need to be done.
    • Do not agree with the conditions or information related to the task.

Documents, files and repository


The release process has been divided into the common milestones. For the generic Release process project, the dates are not accurate for each milestone. They are for the 12.3 Release process project and the following ones. These milestones needs to be configured for each subproject, since the dates and number of milestones might vary from release to release.

The configuration of the milestones are a key step to organize the tasks (issues), visualize them in the roadmap, calendar and Gantt diagram.

Time entries