[Feature]: Pin a 1.0 Refactor Tracking Issue — Consolidate Existing Progress Info and Add a PR Merge Policy

[NiuBlibing]

Summary

Pin a 1.0 Refactor Tracking Issue — Consolidate Existing Progress Info and Add a PR Merge Policy

Problem statement

Context

As of 2026-04-24, the repository has 94 open issues and 286 open PRs — PRs outnumber issues by roughly 3×, and the merge cadence is clearly lagging behind submissions.

The Microkernel Architecture RFC (D1–D5) work is reasonably the main driver of the slower review cadence. After digging through the repo, I can confirm that the following information already exists publicly:

• RFC D1–D5 is referenced in AGENTS.md as the architectural direction.
• v0.5.x release notes explicitly state that 12 workspace crates have been extracted from the monolith, implementing the microkernel RFC roadmap.
• Stability tiers (Stable / Beta / Experimental) are now wired into the workspace.
• docs/contributing/ contains pr-workflow.md, pr-discipline.md, and reviewer-playbook.md.

The Gap

The information exists, but it is scattered across the RFC, release notes, AGENTS.md, and individual PR descriptions — external contributors have to piece it together. More importantly, one key question is not clearly answered anywhere:

For PRs submitted today, what will be fast-merged, and what will be held?

pr-workflow.md and pr-discipline.md describe how to write a PR, but not when it will be reviewed. This uncertainty leads contributors to keep submitting → backlog grows → review load increases further.

Proposed solution

Pin a 1.0 Refactor Tracking Issue that does two things:

1. Consolidates existing info — a checklist showing current RFC D1–D5 phase, extracted crates, and remaining milestones, linking back to the RFC and release notes rather than duplicating content.
2. Adds a PR merge policy for external contributors:
   • What can be fast-merged (e.g. bug fixes against Stable-tier crates, docs, CI improvements, isolated changes that don't intersect the refactor).
   • What is on hold (feature PRs against Beta/Experimental-tier modules still being migrated).
   • What will be closed (PRs targeting code paths scheduled for removal).

Benefits

• Reduces repeated explanation across PR threads.
• Lets contributors self-assess PR expectations based on stability tier, reducing low-signal submissions.
• Gives both existing contributors and newcomers a single stable entry point into the refactor status.

Non-goals / out of scope

No response

Alternatives considered

No response

Acceptance criteria

No response

Architecture impact

No response

Risk and rollback

No response

Breaking change?

No

Data hygiene checks

• I removed personal/sensitive data from examples, payloads, and logs.
• I used neutral, project-focused wording and placeholders.

[Audacity88]

A few corrections and context:

Numbers are off. As of today the repo has ~220 open issues and ~175 open PRs — not 94/286. PRs don't outnumber issues 3×. That said, the review/merge cadence concern is valid — several approved PRs have been waiting for merge for weeks.

Milestone trackers already serve this role. #5877 (v0.7.4) has a categorized checklist with review status per PR, and #5878 (v0.7.5) is tightly scoped with an explicit definition of done. These are the coordination points for what's in scope — a PR that's in a milestone has a clear path to merge; one that isn't is effectively queued. #5891 (multi-agent v1) does the same for a feature initiative.

The real gap is discoverability. These trackers exist but external contributors don't know to look at them. The question "for PRs submitted today, what will be fast-merged vs held?" is answered by whether the PR fits the current milestone's theme — but that's not stated anywhere in CONTRIBUTING.md or the PR template.

Your merge policy idea is the actionable piece. Rather than a new tracker (whose scope would be hard to bound), a short section in CONTRIBUTING.md mapping stability tiers to merge expectations would give contributors what they need:

• Track A (docs/tests/CI) and Stable crate bug fixes → lightest review, fastest merge
• Beta crate features → accepted with review
• Experimental crate features → may be held pending refactor milestones
• Check the current milestones to see what's actively in scope

That surfaces existing information without creating another tracking artifact to maintain.