Summary
Three repository-maintenance paths have drifted from the current project structure and governance model.
1. CI package matrices are out of sync with workspaces
The root package.json lists 18 workspaces, while the PR workflow's code-quality matrix lists 13 package workspaces and the merge-queue workflow's matrix lists 10.
Exact deltas against the root workspaces array:
reusable-run-linting-check-and-unit-tests.yml is missing packages/testing, packages/signer, examples/snippets, layers, and examples/app.quality_check.yml is missing packages/testing, packages/validation, packages/kafka, packages/data-masking, packages/signer, examples/snippets, layers, and examples/app.- Neither matrix contains an entry absent from
workspaces.
The non-package workspaces have dedicated jobs, and packages/testing is private and needs deliberate handling. Among publishable utility packages, Signer is missing from both matrices; Validation, Kafka, and Data Masking are additionally missing from the merge-queue matrix. Signer, added in #5344, appears in the end-to-end matrix, but no workflow currently runs its package lint or unit-test commands.
The new root maintainers playbook in #5618 already documents all three workflows under “Wiring the package into CI”. Separately, on_pr_updates.yml still says requirements are checked in on_opened_pr.yml, but that workflow does not exist.
2. The RFC discussion form likely does not render
The repository defines .github/DISCUSSION_TEMPLATE/rfcs.yml, while the GitHub API reports the RFC category slug as rfcs-request-for-comments. GitHub requires a discussion form filename to match its category slug, so the expected filename is rfcs-request-for-comments.yml.
Discussion #5614, created September 3, 2026, has the area New Feature: Feature Flags, which is absent from the form's configured dropdown options. This is consistent with the form not rendering, although a discussion body can be edited after creation.
The dropdown also omits newer package areas present in package.json: Kafka, Data Masking, and Signer.
3. Issue forms still use labels for issue type
The project is moving type tracking to GitHub Issue Types, as documented in the updated maintainers playbook. The organization currently enables the Task, Bug, and Enhancement issue types.
However, four issue forms still declare the archived type labels alongside triage:
Archived labels cannot be assigned by the forms, so these templates currently retain only triage and do not set an Issue Type. config.yml does not carry label assumptions, but docs/features/metrics.md still links to the old feature_request.md filename and pre-populates feature-request and triage labels.
Why is this needed?
These gaps let publishable packages bypass expected CI coverage, prevent RFC authors from receiving the intended structured form, and leave new issues without the project's new type metadata. They also make repository guidance and automation disagree with the current governance model.
Which area does this relate to?
Automation, Governance, Tests
Solution
- CI: add the missing publishable packages to both matrices; explicitly handle or document private/non-package workspace exclusions; preferably derive relevant matrices from workspace metadata; and fix the stale
on_opened_pr.yml comment.
- RFC form: rename the file to
rfcs-request-for-comments.yml, add Kafka, Data Masking, and Signer, then verify the form by opening a draft RFC.
- Issue forms: replace archived type-label declarations with the appropriate top-level
type: values (Bug, Enhancement, or Task), keep triage, and sweep stale issue-creation links such as the Metrics link.
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Summary
Three repository-maintenance paths have drifted from the current project structure and governance model.
1. CI package matrices are out of sync with workspaces
The root
package.jsonlists 18 workspaces, while the PR workflow'scode-qualitymatrix lists 13 package workspaces and the merge-queue workflow's matrix lists 10.Exact deltas against the root
workspacesarray:reusable-run-linting-check-and-unit-tests.ymlis missingpackages/testing,packages/signer,examples/snippets,layers, andexamples/app.quality_check.ymlis missingpackages/testing,packages/validation,packages/kafka,packages/data-masking,packages/signer,examples/snippets,layers, andexamples/app.workspaces.The non-package workspaces have dedicated jobs, and
packages/testingis private and needs deliberate handling. Among publishable utility packages, Signer is missing from both matrices; Validation, Kafka, and Data Masking are additionally missing from the merge-queue matrix. Signer, added in #5344, appears in the end-to-end matrix, but no workflow currently runs its package lint or unit-test commands.The new root maintainers playbook in #5618 already documents all three workflows under “Wiring the package into CI”. Separately,
on_pr_updates.ymlstill says requirements are checked inon_opened_pr.yml, but that workflow does not exist.2. The RFC discussion form likely does not render
The repository defines
.github/DISCUSSION_TEMPLATE/rfcs.yml, while the GitHub API reports the RFC category slug asrfcs-request-for-comments. GitHub requires a discussion form filename to match its category slug, so the expected filename isrfcs-request-for-comments.yml.Discussion #5614, created September 3, 2026, has the area
New Feature: Feature Flags, which is absent from the form's configured dropdown options. This is consistent with the form not rendering, although a discussion body can be edited after creation.The dropdown also omits newer package areas present in
package.json: Kafka, Data Masking, and Signer.3. Issue forms still use labels for issue type
The project is moving type tracking to GitHub Issue Types, as documented in the updated maintainers playbook. The organization currently enables the
Task,Bug, andEnhancementissue types.However, four issue forms still declare the archived type labels alongside
triage:bug_report.yml:bugfeature_request.yml:feature-requestdocumentation_improvements.yml:documentationmaintenance.yml:internalArchived labels cannot be assigned by the forms, so these templates currently retain only
triageand do not set an Issue Type.config.ymldoes not carry label assumptions, butdocs/features/metrics.mdstill links to the oldfeature_request.mdfilename and pre-populatesfeature-requestandtriagelabels.Why is this needed?
These gaps let publishable packages bypass expected CI coverage, prevent RFC authors from receiving the intended structured form, and leave new issues without the project's new type metadata. They also make repository guidance and automation disagree with the current governance model.
Which area does this relate to?
Automation, Governance, Tests
Solution
on_opened_pr.ymlcomment.rfcs-request-for-comments.yml, add Kafka, Data Masking, and Signer, then verify the form by opening a draft RFC.type:values (Bug,Enhancement, orTask), keeptriage, and sweep stale issue-creation links such as the Metrics link.Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.