From ff11e549b57edd2d20a232e9588d269b437ce9d7 Mon Sep 17 00:00:00 2001 From: hetaoBackend Date: Tue, 13 Oct 2026 20:34:36 +0800 Subject: [PATCH 1/6] docs(community): add community on-call SLA and group layering docs Register the two new community documents in the public source inventory so check:source passes. - docs/community/oncall.md: role split (chat vs GitHub), rotation windows, 48h triage SLA, label hygiene rules, contribution-request rules, weekly feedback replay, reply templates, weekly metrics. - docs/community/groups.md: three community layers and what belongs in each, the single entry point, movement rules, Insider external-disclosure rule, showcase wall and AMA format. --- docs/community/groups.md | 87 +++++++++++++++++++++ docs/community/oncall.md | 156 +++++++++++++++++++++++++++++++++++++ release/public-source.json | 2 + 3 files changed, 245 insertions(+) create mode 100644 docs/community/groups.md create mode 100644 docs/community/oncall.md diff --git a/docs/community/groups.md b/docs/community/groups.md new file mode 100644 index 000000000..a2ed8c10a --- /dev/null +++ b/docs/community/groups.md @@ -0,0 +1,87 @@ +# Community groups + +This document defines the three community layers, what each layer is for, and the rule for moving +between them. It is public so that joining a group is a predictable decision rather than a guess. + +## Layers + +| Layer | Who can join | What belongs there | What does not | +| --- | --- | --- | --- | +| Newcomer | Anyone with the group QR code or the Discord link | Install, configuration, first-run usage, frequently asked questions | Unreleased features, internal roadmap, internal test builds | +| Advanced | Anyone who has opened at least one issue, or who is invited | Architecture discussion, PR intentions, performance findings, design proposals | Internal roadmap, unreleased features | +| Insider | Invitation only, after signing the external-disclosure rule | Test builds, unreleased features, early feedback | Screenshots of accounts, session identifiers, or unreleased versions | + +The three layers are rules first and separate groups second. A new group with fewer than 50 active +members is not created; the rule applies to the existing group until the volume justifies a split. + +## The one entry point + +Every layer carries the same pinned card, pointing at the same three places: + +1. **Report an issue** — `https://github.com/MiniMax-AI/minimax-code/issues/new/choose` +2. **Claim a task** — the `good first issue` label: + `https://github.com/MiniMax-AI/minimax-code/labels/good%20first%20issue` +3. **See the on-call rota and the weekly replay** — [Community on-call](oncall.md) + +Feedback posted in chat without an issue number is not tracked. If a chat report is not converted into +an issue within 24 hours, the on-call owner raises it on the reporter's behalf. + +## Moving between layers + +- **Newcomer → Advanced**: automatic, as soon as the member opens an issue or is invited. There is no + application and no approval. +- **Advanced → Insider**: invitation only. The invite includes the external-disclosure rule below, and + the rule is acknowledged before any test build is shared. +- **Insider → public**: content returns to a public layer only through the formal release notes. Chat + history is never the source for external material. + +## External-disclosure rule for the Insider layer + +Acknowledged by every Insider member before receiving a test build. + +1. Test builds, unreleased feature names, and internal version numbers stay in the Insider layer. They + are not posted to a public group, a public issue, a screenshot, a blog post, or a video. +2. Account identifiers, session identifiers, tokens, and customer project content are never shared in + any layer. Use synthetic files and dedicated test accounts. +3. External material about a feature comes from the release notes for a released version, not from a + chat log. If a screenshot is needed for a public post, it must be regenerated from a released + build. +4. A leak is reported to the release coordinator immediately, and the affected material is withdrawn + as soon as it is identified. Reporting a leak is never held against the reporter. + +## What a layer may be used for + +| Activity | Newcomer | Advanced | Insider | +| --- | --- | --- | --- | +| Install and configuration help | Yes | Yes | Yes | +| Bug report and question answering | Yes | Yes | Yes | +| Weekly feedback replay | Yes | Yes | Yes | +| AMA session (biweekly) | Yes | Yes | Yes | +| Showcase wall submission | Yes | Yes | Yes | +| Architecture and design discussion | No | Yes | Yes | +| Pull request review participation | No | On invitation | Yes | +| Test build distribution | No | No | Yes | + +## Showcase wall + +Showcases are collected in `docs/showcase/` and mirrored to a GitHub Discussions category. + +- **Threshold:** a showcase must be runnable — a repository, or a prompt that reproduces it, plus the + verification command. Screenshots alone are not accepted. +- **Every showcase produces a task.** Each accepted showcase must yield at least one + `good first issue` task, by extracting the step a newcomer could do independently. This is the point + of the wall: a showcase that produces no task brings in visitors who find nothing to do. +- **Low bar by design:** the entry requirement is "post a prompt that runs". A showcase is not a + product pitch. + +## AMA sessions + +Biweekly, 30 minutes: 20 minutes of product questions, 10 minutes walking through live issues. + +- **Agenda comes from the queue.** Every question discussed is drawn from the current + `needs-triage` queue or a contribution request. The host does not choose topics independently. +- **Recording and minutes** are archived to the Discussions `AMA` category, with the issue numbers + discussed listed in the minutes. +- **Failure condition:** if three consecutive sessions draw fewer than 30% of registrants, the format + changes to a smaller closed-door session over live issues instead of a public AMA. Adding more + sessions is not the response. diff --git a/docs/community/oncall.md b/docs/community/oncall.md new file mode 100644 index 000000000..8ee676e91 --- /dev/null +++ b/docs/community/oncall.md @@ -0,0 +1,156 @@ +# Community on-call and issue SLA + +This document defines who watches the community channels, what counts as a response, and how +feedback is replayed back to reporters. It is a public commitment: anyone reading it should be able +to predict when they will hear back. + +## Scope + +The community on-call covers two surfaces: + +| Surface | Meaning | Owner | +| --- | --- | --- | +| Community chat (Chinese Feishu group, Discord) | User questions, feedback, event coordination | On-call A | +| GitHub issues (`MiniMax-AI/minimax-code`) | Bug reports, feature requests, contribution requests | On-call B | + +These are two different roles and they are staffed by two different people. A single person holding +both roles cannot cover the 18:00–20:00 window, so that window is explicitly not covered by either +role. + +## Rotation + +| Role | Window | Timezone | Coverage | +| --- | --- | --- | --- | +| On-call A | Weekdays 10:00–18:00 | Asia/Shanghai | Community chat | +| On-call B | Daily 09:00, 20:00–23:00, and weekends | Asia/Shanghai | GitHub issues | +| Uncovered | 18:00–20:00 weekdays | — | Neither role; escalate to the release coordinator | + +The rotation is published in the community chat as a pinned card. It is replaced every two weeks. + +## Response SLA + +**Every open issue must receive a triage action within 48 hours of being opened.** A triage action is +one of the following, and one of them counts: + +- applying a type and product label; +- asking the reporter for the specific missing information (`needs-info`); +- linking a duplicate to its original issue; +- recording a next step in a comment, including a decision to decline with a reason. + +A triage action is not a promise to fix or to ship in a release. Classification alone does not commit +the project to a delivery date, and this distinction is stated in every response so reporters know +what they are getting. + +Anything that has been open for more than 48 hours without any of the above is a SLA breach and is +listed in the weekly feedback replay. + +## Label hygiene + +- An issue must not stay on `needs-triage` after it is closed. When closing an issue, remove + `needs-triage` in the same action. +- `needs-triage` counts only open issues. Reporting a `needs-triage` ratio that includes closed + issues overstates the backlog; the canonical number is `is:issue is:open label:needs-triage`. +- When an issue is closed as `duplicate` or `wontfix`, the reason is stated in a comment, per the + triage policy in [Maintainers](../maintainers.md). + +## Contribution requests + +A request for repository access is a request for a decision, and a decision must be communicated. +Even when the answer is "no", the answer is sent. + +- Tag contribution requests with `contribution-request` so the funnel from request to decision is + measurable. +- Respond within 48 hours with one of: approved, declined with a reason, or already completed + internally. +- **When the underlying task is completed internally first, the requester is told explicitly and their + fork and branch are still declared valid.** If the internal fix missed anything, the requester is + invited to open a fork PR. Silently closing a contribution request because the work was done + elsewhere is treated as a SLA breach, not as resolution. +- Submission of a fork PR does not require collaborator access. Access is a convenience for + maintainers, not a precondition for contributing. + +## Weekly feedback replay + +Every Friday, the on-call owner posts a single message to the community chat summarising the week: + +- every issue that received a triage action, with its number and what the action was; +- every issue that was asked for more information, and what is still needed; +- every issue that was closed, and why; +- every open issue that has breached the 48-hour SLA, listed by number. + +The replay links issue numbers directly. It exists so that a reporter can see what happened to their +report without having to ask, and it is the mechanism that keeps feedback from being silently dropped. + +## Reply templates + +### Triage response + +``` +Thanks for the report — received and triaged. + +Triage action: