Document and formalize maintainer onboarding process

[fullsend-ai-triage]

Note

This issue was automatically generated from meeting notes by the scribe agent.
Please review, edit, and add any missing context before prioritizing.

Problem

The project lacks a formalized, documented process for onboarding new maintainers. The team has aligned on criteria but they are not recorded anywhere contributors can reference.

Options considered

• Markdown file in repo root or docs/: A MAINTAINERS.md or docs/guides/maintainer-onboarding.md file that codifies the process. This is the approach the team chose.
• GitHub team permissions only: Rely on GitHub's built-in team management without documenting expectations. Rejected because it doesn't communicate the contribution and consensus requirements.

Acceptance criteria

• Markdown file submitted via PR documenting the maintainer application process
• Document specifies that new maintainers require a demonstrated track record of contributions
• Document specifies that approval requires group consensus
• Document clarifies that new maintainers are not automatically invited to team meetings
• Document is discoverable from the contributing guide or repo README

Related

• Source: Meeting notes

[ralphbean]

This is being addressed in #2603

[fullsend-ai-prioritize]

RICE Priority Score: 0.45

Score breakdown

Dimension	Score	Reasoning
Reach	0.5	This is an internal governance/process documentation issue affecting the project's maintainer team and potential future contributors. It does not impact end-users of the software. Scored as 0.5 — a few people within the organization's contributor community.
Impact	0.5	The team has already aligned on these criteria verbally and in meeting notes; the workaround (referencing meeting notes or asking existing maintainers) exists and is easy. Formalizing the process improves discoverability and transparency but does not change core functionality. Scored as 0.5 — low impact since a workaround exists.
Confidence	0.9	Very high confidence. The issue has clear, specific acceptance criteria (5 checkboxes), the scope is a single markdown document, and a PR (#2603) is already in progress. There is minimal ambiguity about what needs to be done.
Effort	0.5	This is a straightforward documentation task — writing a markdown file with well-defined content requirements and linking it from the contributing guide or README. No code changes, no testing complexity. Scored as 0.5 — simple and well-scoped.

Formula: (0.5 x 0.5 x 0.9) / 0.5 = 0.45

[ralphbean]

/fs-triage

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 7:59 PM UTC · Completed 8:03 PM UTC

Commit: 508dfe1 · View workflow run →

[fullsend-ai-triage]

Previous attempt context

PR #2603 attempted this work but was closed without merging after substantive review feedback. Two key concerns emerged that a new attempt should address:

1. Time commitment: The previous draft stated "no time commitment" for maintainers. A reviewer felt this was inappropriate — the next version should include at least a vague expectation of ongoing participation.
2. Maintainer vs contributor distinction: The previous draft presented maintainers as essentially contributors with approval rights. A reviewer argued that if maintainers aren't offered an appropriate level of say in project governance, the title is misleading. The next draft should clarify what maintainers can do that contributors cannot, beyond merge permissions.

The previous PR author also noted that there is no public channel for maintainer participation (Slack and meetings are private), which complicates defining the role. The new document should either define a participation mechanism or be transparent about the current limitations.

Proposed test case

Verification checklist:
- [ ] Markdown file exists at expected path (MAINTAINERS.md or docs/guides/)
- [ ] Renders correctly on GitHub
- [ ] Specifies track record of contributions required
- [ ] Specifies group consensus for approval
- [ ] Clarifies meeting invitation policy
- [ ] CONTRIBUTING.md contains a working link to the document
- [ ] Addresses time commitment expectations (not "no commitment")
- [ ] Distinguishes maintainer responsibilities from contributor rights

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-coder]

🤖 Finished Code · ✅ Success · Started 8:04 PM UTC · Completed 8:10 PM UTC

Commit: 508dfe1 · View workflow run →