Skip to main content

Issues management

This page describes how issues are managed throughout their lifecycle in the project, from creation to completion. It also explains the roles of the different boards and statuses used during the process.

Overview​

Issues follow a structured lifecycle designed to ensure proper triage, analysis, prioritization, and implementation. Each stage is associated with a specific status and is visualized through dedicated boards.

The workflow can be summarized as:

1. Issue Creation​

Every issue should be created using the provided issue template.
Every newly created issue is automatically assigned the status new.
At this stage, no commitment has been made regarding its implementation.

2. Triage Phase​

All new issues go through a triage phase, which is tracked in the "Triage" board.

During this phase, the issue is reviewed and one of the following decisions is made:

Accepted issues​

  • The issue becomes available if it is accepted but not prioritized for immediate work.
  • The issue becomes analyzing if it is accepted and assigned to a contributor for further analysis.

Rejected issues​

The issue may be closed if it is:

  • Duplicate
  • Not planned
  • Not understandable or lacking sufficient information

3. Available Issues​

Issues in available status are waiting for a contributor to take ownership.
They remain in this state until someone explicitly starts working on them by moving them to analyzing.

An issue in state analyzing must have an assignee.
Otherwise, it will be put back to available.

4. Analysis Phase​

The "Analyzing" board provides a per-person view of issues currently under analysis.
When an issue is in analyzing, it is open for discussion.

Responsibilities​

The assigned person is responsible for:

  • Driving the discussion
  • Completing the issue with all necessary information
  • Clarifying requirements and scope

When the issue is considered as ready by the assign person, the discuss next label can be set.
This indicates that:

  • The issue is sufficiently mature
  • It is ready to be reviewed during the next PSC meeting

Validation​

The PSC (Project Steering Committee) meets approximately once per week.
During the meeting:

  • Issues labeled discuss next are reviewed
  • If validated, the issue is moved to status ready

5. Backlog​

Once validated, issues enter the backlog.
The backlog:

  • contains issues in ready status
  • represents work that is fully specified and ready for implementation

The "Backlog" board is used to:

  • Organize and prioritize upcoming work
  • Plan inclusion in future releases

Release planning​

There are 4 releases per year (one every 3 months)
Issues can be assigned to a target release

Partner involvement​

Company-specific tags can be added to issues, for example opengis, camptocamp or karakun.
These indicate that the implementation will be handled by a partner company.

6. Implementation Phase​

Implementation progress is tracked through version boards.

Status progression​

  • ready: The issue is planned but not yet started
  • in progress: Work has started. The issue is actively being implemented.
  • in review: A Merge Request (MR) has been created and is ready for review.

7. Review Process​

Issues in review go through the following steps:

Code Review​

  • A Maintainer of the project reviews the Merge Request.
  • The Definition of Done (DoD) is verified.
  • The application is tested on the demo.

Merge​

  • Once approved, the changes are merged into the main branch.
  • The commit message is clarified if necessary.
  • The release notes are clearty defined.
  • The Merge-Request is marked with the tag communication if necessary.
    Issues marked will be used in the next blog-post to show intereesting news about the project.

Demonstration​

During the next PSC meeting:

  • The implemented feature is demonstrated
  • Feedback is collected.
    This can lead to new issues, which will re-enter the lifecycle starting from the new status.

8. Completion​

After validation and demonstration, the issue is closed.

Automation Bot​

Some workflow consistency checks are performed automatically by the GeoGirafe Bot.

The bot runs scheduled maintenance tasks and helps detect issues that are no longer correctly aligned with the expected workflow. Its role is not to make product decisions, but to keep the issue tracker consistent and highlight problems that require human attention.

The bot does not replace triage, analysis, PSC validation, or review decisions. It only detects and marks situations that need attention. The final decision remains the responsibility of contributors and the PSC.

The following rules applies:

Closed issues cleanup​

When an issue is closed, all state/inconsistent labels are removed.
This ensures that closed issues no longer appear as active workflow items in boards or filtered views.

Analyzing issues​

An issue in analyzing must always have an assignee.
If the bot detects an open issue with analyzing but no assignee:

  • it adds the inconsistent label.
  • it adds a comment explaining the problem.

To solve this error, either someone should be assigned to the issue, or the issue should be set back to available.

Open issues without state​

Every open issue must have one workflow state label.
If the bot detects an open issue without any state label:

  • it adds the inconsistent label.
  • it adds a comment asking for a valid state to be set.

This helps identify issues that have fallen out of the normal lifecycle.

Inactive issues​

The bot checks open issues for inactivity.
If an open issue has had no activity for more than approximately 6 months:

  • it adds the inactive label
  • it adds a comment asking contributors to update the issue if it is still relevant

Issues already marked as inactive are ignored by this check.