XeplosionTechnologies/.forgejo

Watch

Fork 0

Remove obsolete `Branch/` label guidance from canonical issue templates #31

New issue

Closed

opened 2026-09-07 17:38:30 +00:00 by Xeplosion · 0 comments

Xeplosion commented

2026-09-07 17:38:30 +00:00

Owner

Type of chore

Repository / project maintenance

What needs to be done and why?

Review the canonical Forgejo issue forms maintained on the .forgejo repository's main branch and remove references to the obsolete Branch/ label workflow.

Several current forms still include fields or lifecycle checklist items such as:

Maintainers should apply corresponding `Branch/` labels when appropriate.

and:

Applicable `Branch/` label(s) assigned when branch targeting matters

This is no longer the intended workflow.

Branch relationships should use Forgejo's native functionality instead:

issues may reference their implementation branch using Forgejo's branch-reference feature;
pull requests already identify their source and target branches.

Update every affected canonical issue form, including any applicable:

Bug Report
Chore / Maintenance
Documentation Update
Enhancement
Feature Request
Investigation
Question
Testing / Validation
Security Vulnerability

Remove Branch/ label language from:

branch/version field descriptions;
maintainer lifecycle checklists;
guidance text.

Where an affected branch/version field itself is still useful for reporter-provided context, keep the field but rewrite its description so it does not instruct maintainers to apply a Branch/ label.

For example:

Affected branch(es)

may still be useful on a bug report when the reporter knows which release or branch is affected.

The incorrect part is the manual label duplication, not necessarily the collection of branch/version context.

Technical-debt impact

Leaving the stale guidance in the canonical forms causes every repository receiving synced templates to continue teaching an obsolete workflow.

Because these files propagate through the managed template system, inconsistent guidance becomes organization-wide technical and process debt.

Fixing the canonical source prevents the incorrect convention from continuing to spread.

Risk / compatibility impact

Low implementation risk, but the canonical forms are shared template assets.

Changes should be reviewed to ensure useful reporter fields are not removed simply because their current descriptions reference Branch/ labels.

Template propagation should be verified after the canonical files are corrected.

Affected branch(es)

Canonical issue-template changes belong on main, which is the source for shared template propagation.

The issue itself should use Forgejo's native branch reference if an implementation branch is created.

Additional context

This task is specifically about the canonical templates, not merely the documentation describing them.

A separate documentation issue tracks removal of stale Branch/ references from the written standards.

The existing issue forms themselves currently demonstrate the problem, including branch-label instructions in reporter fields and the shared lifecycle checklist.

Request checklist

I described why this work provides value or avoids future technical debt
I identified known risk, compatibility, or coordination concerns where applicable

Workflow lifecycle

Triage

Kind/ classification confirmed
Issue validity reviewed and appropriate Reviewed/ label assigned
Priority/ assigned when appropriate
Applicable Branch/ label(s) assigned when branch targeting matters
Information requirements resolved; no Status/Needs More Info remains
Status/Needs Triage removed before leaving Triage

Backlog

Issue is confirmed valid and accepted into the project backlog

To Do

Scope and expected outcome are sufficiently defined
Known prerequisites, dependencies, and required decisions are resolved or understood
Work has been deliberately selected as upcoming work

In Progress

Assignee or active owner identified when appropriate
Forgejo timer started when time tracking provides meaningful value
Relevant implementation, research, or work notes recorded as needed
Forgejo timer stopped when active work ends, pauses, or becomes blocked

Review Gate

Review requirement assessed based on complexity, criticality, reversibility, and impact
If review is required: moved to In Review and appropriate testing / validation performed
If review is required: review comment records what was reviewed, how it was validated, findings, and outcome
If review is not required: rationale is evident from the low-risk nature of the change

Completed

Acceptance criteria / intended outcome satisfied
Related PRs, commits, documentation, or external changes linked where applicable
Final resolution comment explains what changed, how the issue was resolved, and how it was verified
Follow-up work split into separate issues where appropriate
Any Forgejo timer is stopped and recorded time is final
Issue moved to Completed and closed

### Type of chore Repository / project maintenance ### What needs to be done and why? Review the canonical Forgejo issue forms maintained on the `.forgejo` repository's `main` branch and remove references to the obsolete `Branch/` label workflow. Several current forms still include fields or lifecycle checklist items such as: ```text Maintainers should apply corresponding `Branch/` labels when appropriate. ``` and: ```text Applicable `Branch/` label(s) assigned when branch targeting matters ``` This is no longer the intended workflow. Branch relationships should use Forgejo's native functionality instead: * issues may reference their implementation branch using Forgejo's branch-reference feature; * pull requests already identify their source and target branches. Update every affected canonical issue form, including any applicable: * Bug Report * Chore / Maintenance * Documentation Update * Enhancement * Feature Request * Investigation * Question * Testing / Validation * Security Vulnerability Remove `Branch/` label language from: * branch/version field descriptions; * maintainer lifecycle checklists; * guidance text. Where an affected branch/version field itself is still useful for reporter-provided context, keep the field but rewrite its description so it does **not** instruct maintainers to apply a `Branch/` label. For example: ```text Affected branch(es) ``` may still be useful on a bug report when the reporter knows which release or branch is affected. The incorrect part is the manual label duplication, not necessarily the collection of branch/version context. ### Technical-debt impact Leaving the stale guidance in the canonical forms causes every repository receiving synced templates to continue teaching an obsolete workflow. Because these files propagate through the managed template system, inconsistent guidance becomes organization-wide technical and process debt. Fixing the canonical source prevents the incorrect convention from continuing to spread. ### Risk / compatibility impact Low implementation risk, but the canonical forms are shared template assets. Changes should be reviewed to ensure useful reporter fields are not removed simply because their current descriptions reference `Branch/` labels. Template propagation should be verified after the canonical files are corrected. ### Affected branch(es) Canonical issue-template changes belong on `main`, which is the source for shared template propagation. The issue itself should use Forgejo's native branch reference if an implementation branch is created. ### Additional context This task is specifically about the **canonical templates**, not merely the documentation describing them. A separate documentation issue tracks removal of stale `Branch/` references from the written standards. The existing issue forms themselves currently demonstrate the problem, including branch-label instructions in reporter fields and the shared lifecycle checklist. ### Request checklist - [x] I described why this work provides value or avoids future technical debt - [x] I identified known risk, compatibility, or coordination concerns where applicable ### Workflow lifecycle ### Triage - [x] `Kind/` classification confirmed - [x] Issue validity reviewed and appropriate `Reviewed/` label assigned - [x] `Priority/` assigned when appropriate - [x] Applicable `Branch/` label(s) assigned when branch targeting matters - [x] Information requirements resolved; no `Status/Needs More Info` remains - [x] `Status/Needs Triage` removed before leaving Triage ### Backlog - [x] Issue is confirmed valid and accepted into the project backlog ### To Do - [x] Scope and expected outcome are sufficiently defined - [x] Known prerequisites, dependencies, and required decisions are resolved or understood - [x] Work has been deliberately selected as upcoming work ### In Progress - [x] Assignee or active owner identified when appropriate - [x] Forgejo timer started when time tracking provides meaningful value - [x] Relevant implementation, research, or work notes recorded as needed - [x] Forgejo timer stopped when active work ends, pauses, or becomes blocked ### Review Gate - [x] Review requirement assessed based on complexity, criticality, reversibility, and impact - [x] If review is required: moved to **In Review** and appropriate testing / validation performed - [x] If review is required: review comment records what was reviewed, how it was validated, findings, and outcome - [x] If review is not required: rationale is evident from the low-risk nature of the change ### Completed - [x] Acceptance criteria / intended outcome satisfied - [x] Related PRs, commits, documentation, or external changes linked where applicable - [x] Final resolution comment explains what changed, how the issue was resolved, and how it was verified - [x] Follow-up work split into separate issues where appropriate - [x] Any Forgejo timer is stopped and recorded time is final - [x] Issue moved to **Completed** and closed

Xeplosion added the

labels

2026-09-07 17:38:30 +00:00

Xeplosion self-assigned this

2026-09-07 17:38:30 +00:00

Xeplosion added this to the Issue & Pull Request Templates project

2026-09-07 17:38:31 +00:00

Xeplosion added the due date 2026-09-09