Skip to content

Latest commit

 

History

History
90 lines (71 loc) · 4.77 KB

TRIAGE.md

File metadata and controls

90 lines (71 loc) · 4.77 KB
Raw

Triage

Target audience: Regular contributors to Cucumber Open.

This document describes how issues and pull requests (work items) are triaged across the Cucumber GitHub organisation.

The purpose of a triage process is to make it easier for regular contributors to decide what to work on next.

Triage should ideally happen whenever a new work item is submitted, but for practical reasons the triage may happen at less frequent intervals (ideally at least a couple of times a week).

Daily routine

The first step of the triage process is to assign relevant labels to new issues and pull requests. We maintain a consistent set of labels across repositories to make this simpler.

Sometimes a bit of discussion in the ticket is needed before we can label them correctly.

  • Label unlabelled issues:
    • Exactly one of the following:
      • ✅ accepted to indicate that we'd welcome a PR for this
      • 🙅 wont fix for issues we won't fix (or don't want a fix for)
        • Also close these issues and leave a comment explaining why it won't be fixed
    • At least one of these:
      • 🥒 core team these are issues that the core team will give priority to
      • 🙏 help wanted for accepted issues, but not a priority to the core team
      • 💵 bounty if we want to draw extra attention to an issue
      • 🔥 critical for urgent issues that are preventing users from using Cucumber
    • And one of these:
      • 🐛 bug
      • ⚡ enhancement
  • Engage in discussions on new/active issues and pull requests
  • Engage in Slack conversations
  • Merge Renovate bot pull requests

Weekly routine

  • Community Zoom meetings
  • Make Releases
  • Adding new work items to the Cucumber Open board
    • Partly informed by the weekly Zoom call
    • Partly informed by the labels

Pulling into Next

We aim to have about a dozen or so work items in the Next column at any given time so that regular contributors have a bit of choice (but not too much choice) when they pick up something new to work on.

Pull priority

Pull requests and issues tagged with 🔥 critical always have higher priority than regular issues. In other words, the Cucumber Open board should only have pull requests and 🔥 critical issues.

The reason for this is to build a culture that:

  • nurtures new contributors
  • places a higher value on "work done" (pull requests) than "work requested" (issues).

When pulling from Next to In Progress - pull the top work item if you can. When adding new work items into Next - put them at the bottom.

What gets pulled into Next is decided based on the following guidelines: