Pair by branch name, document the agent workflow, and skip insider triage - #55
Merged
Merged
Conversation
…iage Three related changes to how cross-repo work is coordinated and filed. Pairing a change that spans repos is now a branch of the same name in each, replacing paired-<repo>:<branch> labels. A label is metadata: it did not travel with the commit, did not show in the diff, did not exist on a push - which is why mux-runtime main went red during 0.10.0 - and only took effect if you closed and reopened the PR, because labelling does not start a run and a re-run replays the original payload. A job that builds a sibling's branch source is a preview of a state that does not exist yet, since the consumer builds the commit its lockfile names. On a deliberately breaking change its failure is expected information rather than a defect. Those jobs report; the pin-bump PR gates, because it is the first build that actually contains the change. The governance doc gains the part it never had: how to file an issue and run a PR. Which template, why not to touch labels or milestones at filing time, what a title should say, merge order for a coupled change, and that a red check is a claim about your change until you have shown otherwise. That gap is what mux-context#28 was about. Also carries the triage workflow change so this repo matches the other six. Closes #19 Closes #28
|
| Filename | Overview |
|---|---|
| .github/ISSUE_TEMPLATE/adr_proposal.yml | Adds the Decision issue type and restores the ADR area label. |
| .github/ISSUE_TEMPLATE/cross_repo_question.yml | Assigns the Decision issue type to cross-repository questions. |
| .github/workflows/issue-triage.yml | Replaces association-based triage exemption with fail-safe repository permission checks and removes obsolete documentation-kind labeling. |
| docs/repo-governance.md | Documents issue-type governance, insider triage handling, issue and PR procedures, branch-name pairing, and pin-bump gating. |
Reviews (8): Last reviewed commit: "Clarify that exempt issues skip no proje..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Kind was inferred from which form was used, then re-encoded as a label at triage - two representations of one fact, and neither visible in an issue list. It is an org issue type now: Bug, Enhancement, Documentation, Chore, Decision, set by the template at filing time. Types and labels answer different questions, which is why both stay. A type is single-select, so there is no filing something as both a bug and a feature. Labels carry what a single field cannot: area, state, disposition. The rule is one type, any number of labels, and no label that restates the type. Closes #19
COLLABORATOR in author_association only means invited to this repo, which can be read-only or triage-level. It does not imply the ability to set priority and status, so removing 'needs triage' for one drops their issue out of the queue - the single outcome this must not cause. Leaving the label on someone who could have triaged it costs a maintainer one click. The reverse loses the issue. OWNER and MEMBER only. Caught in review.
Contributor
Author
|
Updated: It only means invited to this repo, which can be read-only or triage-level, so it does not imply the ability to set priority and status. Removing The template-sync branches were also rebuilt from |
The workflow guessed a 'documentation' label from the title and body. With Documentation as an issue type set by the form, that label restates the type, which is exactly what the governance doc now forbids. The guess was weak anyway: it could not tell a docs REQUEST from a bug report that happens to mention documentation. Caught in review.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three related changes: how cross-repo work is coordinated, how it gets filed, and who has to triage it.
Closes #19. Closes #28.
Pairing by branch name
A change spanning repos is developed on a branch of the same name in each, and cross-repo jobs look for that branch, falling back to
main. Nothing to label, create, or clean up.This replaces
paired-<repo>:<branch>labels, which were metadata rather than content:mainwent red during 0.10.0Implementation in muxlang/mux-runtime (
scripts/paired-ref.sh).What gates, and what only reports
A consumer builds the sibling commit its lockfile names. A job that builds the sibling's branch source is therefore a preview of a state that does not exist yet, and on a deliberately breaking change its failure is expected information, not a defect. Blocking on it produced red PRs for merge-order reasons.
Those jobs now report. The gate is the pin-bump PR - the first build that actually contains the change, running the consumer's full suite.
Filing an issue and running a PR (#28)
The doc said what the metadata means but never how to actually file and land work. New section covers: picking the template rather than prefixing the title, leaving labels and milestones alone at filing time, what a good title says, merge order for a coupled change, changelog in the same PR, and that a red check is a claim about your change until you have shown otherwise.
Insider triage (#19)
needs triagemarks work needing a maintainer's judgement. An org member files with priority and status in hand, so the label only asked them to review their own issue. The template applies it before the workflow runs, so it is removed again rather than not added.Identical workflow change in all seven repos; this PR carries mux-context's copy.
On "add issue types back"
Both
repository.issueTypesandorganization.issueTypesreturn empty, so there is nothing configured to restore - it may be a plan limitation or they were never enabled. Left alone rather than guessed at; say what you had in mind and I will follow up.