Skip to content

Issue and PR Hygiene

Jump to bottom
Emily Zhao edited this page Jun 14, 2025 · 1 revision

1. Overview

Issues, and PRs go through many changes throughout their lifespan - we need a set of guidelines to make sure they are filled out correctly, and maintained appropriately throughout their lifespan.

2. Scope

This document covers setting/maintaining project fields, labels, and PR<->Issue Linkages.

Intended Audience: Developers | Project Leads

3. Related Processes

  • [Issue Types](TO DO: add link here)
  • [Triage](TO DO: add link here)

4. Process/Main Body

Project Fields

GitHub Projects allow you to define custom fields for issues/PRs in the project. Not all fields must be filled out for an issue. the cuTile Project has the following fields:

  • [Status](TO DO: add project setting link)

    • To Do, In Progress etc.

  • [Type](TO DO: add project setting link)

    • Bug, Feature, Docs, Epic, Theme

  • [Priority](TO DO: add project setting link)

    • 0 > 1 > 2

  • [Milestone](TO DO: add project setting link)

    • Which release?

  • [CONDITIONAL] Start Date

  • [CONDITIONAL] Target Date

As the issue moves through its lifecycle, project values must be kept up-to-date and filled out. If we only set these values during triage, then our project is a snapshot in time, and not a living reflection of our work.

Labels

TO BE UPDATED e.g. can use label to indicate different modules of cuTile, type of work (e.g. enhancement, new feature), or a work need triage, origin of issues (e.g. nvbug, community)

PRs

There are two types of required PR labels for CI:

  1. Type
    1. Bug
    2. Feature Request
    3. Improvement
    4. Documentation
  2. Breaking Status
    1. Breaking
    2. Non-Breaking
  • It is not required for PRs to have the library label

Issue <-> PR Linkage

All PRs must be linked to issues, aside from rare exceptions.

To link issues, you must either:

  • Link them though the GH GUI in the issue under the "development" section in the issue or PR
  • Use Closes keywords
    • While GitHub allows you to use things like Contributes to, this doesn't actually link them together. The only way offically link them is through closing keywords
    • This can create the scenario where an issue has 2 PRs linked and automation gets in the way
      • Issue 1 is linked to PR 2
      • Issue 1 is linked to PR 3
      • PR 2 is closed
      • Automation closes Issue 1
      • PR 3 is still open
    • In this case, we need to manually reopen Issue 1 and set to the correct status

5. References/Appendix

This section intentionally left blank.

Clone this wiki locally