This page contains information about issue management in Redmine. Currently, this is a preliminary draft, and only a proposal for how things work. Highlighted parts are not part of the intendend final content, but instead mention issues that may need discussion and/or conflict with the current approach. Please contribute to the discussion in and

    Issue states


    Below is a list of proposed states for Redmine issues. Those marked with a (*) do not currently exist. Above is a graphical representation of the states and their transitions. Also some transitive transitions not shown in the figure should be allowed to not enforce a too strict workflow for simple issues, where it would otherwise be necessary to update the same issue multiple times to just get it from one state to the other.

    All newly created issues are initially put into this state. Ideally, issues would quickly move to either Accepted or Rejected once someone has had time to look at the issue. If the assignee is the submitter, then additional information is required. Otherwise, the assignee is mainly responsible for evaluating the issue.
    Accepted (*)
    For bugs, indicates that the report is valid (and preferably reproducible) and a fix is required. For features and tasks, indicates that this fits into the future plans for Gromacs and will be implemented at some point (resources allowing). When work starts, the issue moves to In Progress. If there is an assignee, that person is planning to start working on the issue, but has not yet started.
    In Progress
    Person listed in Assignee is working on the issue. If Assignee is empty, then some work has been done, but no one is currently working on it. After the issue is done, it moves to Implemented or Resolved. If something prevents completing the issue, it moves to Blocked state.
    Blocked (*)
    Indicates that something is required before work on this issue can start/continue. This may include resolving some other issues first, or that a lengthier/bigger discussion/decision is required. Comments and/or related issue links in the issue indicate what is the blocker.
    Implemented (*)
    An optional state that follows In Progress for issues that require code changes. The person who did the implementation can put the issue into this state when the implementation is waiting for code review in gerrit.
    Resolved (*)
    The issue has been resolved, but is waiting for some final action. This can include extra testing, feedback from the submitter, checking that the information and fields in the issue have been filled correctly etc. When a commit with particular keywords (e.g., "Fixes #123") is merged, the referenced issue gets automatically put into this state. The issue may move to In Progress if it is determined that extra work is needed, or to Feedback if some extra action is required after receiving feedback. After no more work is necessary, or the issue has been in the state for a long time with no feedback, it moves to Closed. If Assignee is someone else that who did the implementation, indicates that that person is expected to provide feedback or do some other action.
    Follows the Resolved state in a case where Feedback that requires some action is provided. The issue is moved to In Progress if extra implementation is required, or back to Resolved if the feedback is resolved in some other way. Assignee is the person responsible to react to the feedback (most often, the person who did the implementation).
    Issue has been resolved and no further action is necessary.
    The issue reports a non-issue that does not need to be fixed, or for some other reason we do not want to take any action based on the issue.

    Issue categories

    The list below describes the intended use of issue categories. Those marked with a (*) do not currently exist.

    analysis tools
    Issues in individual analysis tools.
    build system
    Issues in the CMake code or in code that directly interfaces with the build system (e.g., code that communicates build system information to the user when tools are run). Can also include issues for code reorganization etc., if they are not clearly related to any other category.
    Issues in documentation.
    Issues that affect mdrun. Anything that has to do with the actual MD simulation most likely goes here.
    preprocessing (pdb2gmx,grompp)
    Issues that affect only the mentioned programs. Perhaps we should extend this to include also other utilities used for preparing the system (e.g., genbox, genion etc.).
    core library (*)
    Issues in shared code used across GROMACS.
    unit tests (*)
    Issues in the unit testing framework. Also possible to include issues in the build system related to unit testing, as well as issues in individual unit tests if they fit better here than in the category where the code to be tested is located. This could also be made more general by naming it just "tests" to also include regression tests. Currently, there is a separate subproject for regression tests.
    selections (*)
    Issues in the selection parsing and evaluation code. E.g., selections that are not evaluated correctly or requests for new selection syntax or new features in the selection API.
    analysis framework (*)
    Issues that are in the common code shared by most analysis tools, and features that should be implemented for all analysis tools. This category may not be necessary, and instead "analysis tools" could be used also for these issues.

    Issue fields

    The list below describes the intended use for some fields in the issues.

    Person who is responsible of taking the next action for the issue. What that action may be depends on the issue state; see description of the states above. If we want to use such strong wording, we should consider whether people currently set as the default assignee for different categories want to take such role, or whether we should clear those.
    Target Version
    This is the version where the issue is planned to be resolved. In particular, it does not indicate the version where a bug is found, although for many historical issues (in particular, those imported from Bugzilla), this is how it is used. The field is used by Redmine to populate the Roadmap page. If empty, indicates that no decision has been made. For issues that are not closed, it should never be a released version. The "future" pseudo-version means that it has been decided to postpone the issue into a more distant, not yet planned major release. For issues that are targeted for an undecided patch release, "4.6.x" or similar pseudo-version should be used.
    Known affected versions
    Free text describing the versions where the bug is known to be present. This field exists for bugs only.
    Page last modified 17:13, 17 Apr 2013 by tmurtola