decision: should shipped scripts and hooks state the reason inline instead of citing an issue number? #738
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea#738
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The question
#15 set the principle for user-facing steering and refusal text: shipped strings carry the rule, not the reference. Script and hook header comments are a gray area - they ship (the hooks reach plugin users, the operator scripts ship in the repo), and several cite a bare issue number as the justification for a check or a step.
Should that principle extend to those headers - state the reason inline, never point at an issue number - or is an issue citation acceptable there as contributor context?
Not decided
Open question. If the answer is yes, it sets the standard the cleanup follow-up applies, and stops the citations creeping back.
Example of the swap
# Why this exists (issue #47): the running Go must exactly match go.modbecomes
# Why this exists: the running Go must exactly match go.mod, so a stale toolchain cannot ship.