Documentation

This document captures how the Kubeapps team triages and prioritizes issues.

To guide and simplify the process, Kubeapps provides a set of issue templates to create new issues:

Kubeapps keeps a backlog of issues on GitHub submitted both by maintainers and contributors.

• The backlog is completely open. The maintainer team, along with the entire Kubeapps community, files all feature enhancements, bugs, and potential future work into the open repository.
• Issues are closed if solved, or outdated (meaning the issue does not apply anymore according to the evolution of Kubeapps or it was waiting for more information which was never received).

Kubeapps maintainers team operates with 4 groups of labels:

The type of issue. kind powers our filtering to understand what qualifies as a bug, proposal, feature, enhancement, question or documentation.

The relevant component(s) for the issue. Components are high level areas of the Kubeapps architecture. They are used to group issues together with other related issues.

Specific labels for contributors. Contribution labels help to identify a relevant attribute of the issue.

There is some metadata for Kubeapps project in GitHub to be added to the issues:

Milestones are used by Kubeapps maintainers to map issues into EPICs. An EPIC represents a series of issues that share a broader strategic objective. An EPIC will typically require development work covering several iterations (in our case, EPICs must be defined to be covered in a quarter). Every triaged issue should have a milestone associated.

Kubeapps EPICs must include: title,description, acceptance criteria, end-date (the end of a quarter).

Kubeapps new issues will be triaged by the maintainers team. The triage process will consist of:

• At any moment:
  • Read the new issue:
    • If more information is requested, the issue must be labeled as awaiting-more-evidence and a comment requesting for information should be added.
    • Metadata for size and priority for the issue must be set as: Needs triage.
    • Check if it is an issue to be accomplished as soon as possible (P0) and move it to the To Do column.
    • If not, the issue must remain in the Backlog column.
• During planning session:
  • Review issues marked as Needs triage.
  • Add labels and update metadata (required): kind, component, size and priority.
    • Check if it is a good-first-issue to start contributing to Kubeapps and label the issue as such.
    • Check if it is an issue to be discussed to be included in next iteration and label it as next-iteration.

Automatically stalebot is checking inactive issues to label them as stale. An issue becomes stale after 15 days of inactivity and the bot will close it after 3 days of inactivity for stale issues. To be considered:

• Issues labeled as kind/bug, kind/documentation, kind/enhancement or kind/feature, will never be labeled as stale.
• Issues labeled as awaiting-more-evidence, kind/proposal or kin/question could be considered stale.
• The label to use when marking an issue as stale is stale.

This process mainly consists on checking issues in the Backlog and moving to the To Do column to be tackled during the following iteration.

Criteria:

1. Issues marked as P0 → Add to the iteration (To Do).

2. Review issues to complete those milestones planned for the current quarter and add issues to be completed during next iteration by priority. To be considered for the capacity:

   • At least 1 issue labeled as kind/bug must be included for every single iteration.
   • At least 1 issue requested from the Kubeapps community must be included for every single iteration.
   • At least 1 issue labeled as component/ci must be included quarterly to make improvements in ci system.

3. Then review issues labeled as next-iteration and discuss what issues should be included according to the maintainers team capacity, issues already added to the To Do column and uncompleted issues from previous iterations (In progress).