Proposal: Project Team and maintainer governance

[ascorbic]

EmDash has grown a lot since its first beta release in April. From a single engineer, to a community of contributors, triage team and now a maintainer team. The project needs more people able to keep work moving, with clear boundaries around who can decide, approve, merge, and administer it.

This proposal defines the Project Team, Maintainers, and Project Lead, establishes how people join and leave those groups, separates project roles from technical access and sets a human review requirement for merges. It also moves routine project work out of private maintainer conversations.

It draws on the detailed post-1.0 proposal prepared by some maintainers and the follow-up discussion about how the project should operate.

Feature planning, RFCs, and the roadmap are covered by a separate proposal. The two proposals are related, but this Discussion is about people, authority, access, and review.

Proposed outcome

• Rename the current Triage Team to the Project Team and #triage to #project-team, and define its expanded scope.
• Give Project Team members GitHub Triage access by default.
• Create a visible Maintainers team whose members have GitHub Write access.
• Retain a Project Lead who is accountable for project direction and makes the final call when consultation does not produce agreement.
• Require approval from another human maintainer before a normal merge. Automated reviews do not satisfy that requirement.
• Keep public GitHub artifacts as the record of project decisions.
• Use #contributing by default for discussion of the project's development, #project-team for trusted operational coordination and #maintainers only for matters that genuinely cannot be public.
• Review privileged access regularly and remove access that is no longer needed.

Governance principles

Work in public by default

Product direction, architecture, roadmap priorities, feature acceptance, RFCs, bug evidence, review judgments, and project policy belong in public GitHub Discussions, issues, RFCs, and pull requests.

Discord can help people discover and coordinate work, but it must not hold the only record of a decision. If a private or synchronous conversation affects the project, its conclusion must be written back to the relevant public GitHub artifact (Discussion, issue or a merged markdown file).

Define roles by responsibility

A project role describes responsibility and decision-making authority. GitHub permissions support that role; they do not define it. Granting Write access does not by itself make someone a maintainer. For example, for technical or administrative reasons, additional Cloudflare employees may have Write or Admin access, but this does not make them maintainers.

Release access, package publishing, infrastructure access, repository administration, secrets, and Discord administration are separate capabilities. They are granted only when a person needs them for an agreed responsibility.

Apply rules consistently

Review and contribution rules apply to the Project Lead, Cloudflare employees, external maintainers, and other contributors. A person's employer or project title does not replace independent review.

Keep privileged access current

Maintainer access is an operational capability, not a permanent award. Dormant privileged accounts create supply-chain risk: an abandoned or compromised account can retain the ability to approve or merge code, modify automation, or publish releases without the activity being noticed promptly.

The project can continue to recognise past contributions without retaining unnecessary access.

Project roles

Project Team

The Project Team is a group of trusted, regular contributors who help operate the project in public. Contributions can include code, documentation, issue and Discussion triage, reviews, design work, support, and community work.

Project Team members can:

• Triage and classify issues, Discussions, and pull requests.
• Close duplicates and work that is clearly outside documented project policy.
• Help contributors develop proposals and find the appropriate process.
• Coordinate reviews, handoffs, and community work.
• Participate fully in planning, RFC, and governance discussions.
• Review pull requests and provide useful technical or product feedback.

Project Team membership does not grant merge authority. A Project Team review is valuable evidence, but it does not satisfy a required maintainer approval.

Project Team members receive GitHub Triage access by default. They receive the "Project Team" role in Discord to help other community members identify them as trusted sources of information.

Maintainers

Maintainers are Project Team members trusted to approve and merge changes and to apply project policy consistently.

Maintainers can:

• Perform all Project Team responsibilities.
• Submit the human approval required for a pull request to merge.
• Merge changes that meet the documented contribution, design, review, and test requirements.
• Accept or decline work where an existing policy or accepted design supplies the necessary direction.
• Share responsibility for compatibility, security, release quality, and contributor experience.
• Participate in confidential discussions when the subject requires it, such as security reports.

Maintainers receive GitHub Write access by default. Write access does not automatically include package publishing, releases, production systems, secrets, or repository administration.

Project Lead

The Project Lead is the maintainer accountable for the project's overall direction and governance. The Project Lead:

• Makes the final decision when consultation does not produce a clear outcome.
• Appoints Project Team members and maintainers after consulting the active maintainers.
• Decides product, architecture, roadmap, and governance questions that have not already been delegated through an accepted policy or design.
• Holds repository Admin access and grants other privileged capabilities according to need.
• Can take immediate action to protect the project during a security, conduct, or operational incident.

The Project Lead should seek public input on public project decisions and consult the maintainers before exercising this authority. Ordinary work within an accepted design or documented policy does not require separate Project Lead approval merely because the Project Lead has final authority.

Decision-making

EmDash retains a Project Lead appointed by Cloudflare. Discussion and consensus are preferred, but the Project Lead makes the final call for project decisions, and is responsible for explaining public project decisions in the relevant public artifact.

Maintainers are trusted to make routine decisions within documented policy without waiting for the Project Lead. A decision is escalated when it establishes new direction, conflicts with an accepted design, changes governance, or cannot reach agreement through normal review.

Public and private channels

Public channels and GitHub

Use public channels for discovery and informal community input. Use the relevant GitHub Discussion, issue, RFC, or pull request for substantive reasoning and the durable decision record.

The public #contributing Discord channel covers contributing, triage, roadmap, RFCs, implementation, and how the project is run. Threads can keep individual topics together.

#project-team

#project-team is for trusted operational coordination, including:

• Finding an owner or reviewer.
• Handing work over during leave or limited availability.
• Coordinating duplicate cleanup or a triage rotation.
• Preparing an agenda or public response.
• Asking for help handling a difficult public thread.
• Flagging public work that needs attention.

It is not a second forum for product, architecture, roadmap, RFC, review, or governance decisions. If a coordination thread becomes substantive, move the reasoning to a public channel or GitHub.

A useful boundary is: discussion about what the project should do is public; coordination about who will handle the work can happen in #project-team. If the boundary is unclear, use the public channel.

#maintainers

#maintainers is limited to subjects that cannot be discussed safely in public:

• Private security disclosures and embargoed fixes.
• Code of Conduct and moderation cases involving identifiable people.
• Appointments, removals, and private concerns about an individual's suitability.
• Credentials, secrets, and production administration.
• Legal, privacy, or confidential partner information.

Routine triage, planning, reviews, and project decisions do not belong there.

Calls can be used for coordination, but an agenda should be available beforehand and decisions must be recorded on GitHub. Attendance at calls is not required to participate in governance.

Review and merge authority

A normal pull request can merge when:

• Required checks pass.
• Blocking review threads are resolved.
• At least one human maintainer other than the author has approved the current revision.
• The change follows an accepted design when the contribution process requires one.

This rule applies to every author, including the Project Lead and other maintainers. Routine self-merge is not permitted.

emdashbot and other automated reviews provide evidence for the human reviewer. Their findings must be considered, but a bot approval does not satisfy the human approval requirement even if GitHub currently records it as an approving review. Repository rules and review-state automation should distinguish human maintainer approval from bot state.

Changes to governance, protected-branch or release automation, package publishing, access controls, or other privileged supply-chain paths require two human maintainer approvals. Neither approval can come from the author.

During an urgent security or production incident, the Project Lead or nominated maintainer can bypass the normal approval requirement when waiting would create greater risk. The bypass and the change must receive retrospective review as soon as it is safe to disclose and review them.

Joining the Project Team

Someone can join the Project Team when they have:

• Made multiple useful contributions to the project or its community over time.
• Demonstrated constructive judgment and dependable collaboration.
• Participated in at least one of the project's public working spaces.
• Expressed an interest in taking on ongoing project responsibilities.

Useful contributions include code, documentation, reviews, triage, design, support, and community work. Regular Discord activity is not required, and GitHub-focused contributors are not excluded.

Anyone can express interest or suggest a candidate. A maintainer normally sponsors the candidate, the active maintainers have an opportunity to raise relevant concerns privately, and the Project Lead makes the appointment. Successful appointments are announced publicly. Unsuccessful nominations and private concerns are not published.

Becoming a maintainer

A maintainer candidate should normally already be on the Project Team and have demonstrated:

• Sustained ownership and sound technical or project judgment.
• Useful work beyond their own proposed changes, such as reviews, triage, planning, documentation, or contributor support.
• An ability to apply compatibility, scope, security, and contribution policies consistently.
• Constructive representation of the project in public.
• Current capacity and interest to share maintainer responsibilities.

An existing maintainer nominates an interested candidate. The active maintainers discuss the nomination privately, and the Project Lead makes the final decision. The appointment is announced publicly after the candidate accepts it.

There is no fixed maximum size for the Project Team or Maintainers. Each group should contain the qualified, active people who have genuine responsibilities to perform. Maintainer membership remains more selective because every appointment adds merge authority and supply-chain exposure.

Participation and inactivity

Project Team members and maintainers are volunteers. There is no minimum number of hours, commits, reviews, or other contributions. Members can take breaks and can step down at any time without giving a reason.

Members should nevertheless remain sufficiently involved to exercise their current responsibilities with up-to-date project context. Activity includes implementation, review, triage, planning, documentation, support, and community work.

The project handles inactivity through a private check-in rather than an automatic public removal:

• After roughly six months without meaningful project activity, the Project Lead or another maintainer contacts the member privately.
• A member who expects to return after a break can remain in the role when that remains appropriate.
• A maintainer who no longer expects to participate can move to the Project Team or an alumni role.
• An inactive Project Team member can move to an alumni role.
• If the person does not respond within a reasonable period, unnecessary access is removed.
• Returning alumni use a lightweight reappointment process that recognises their previous service while confirming current interest and account security.

The project reviews privileged access at least annually. The review covers GitHub, package publishing, releases, infrastructure, secrets, and Discord administration separately.

Removing inactive access is a security and responsibility decision, not criticism of the person's previous contributions.

Area ownership and rotations

Maintainers and Project Team members can volunteer to watch particular areas or participate in a triage rotation. These are coordination tools, not permanent ownership or additional authority. An area owner helps route and review work but does not gain a veto over that area.

Rotations must allow handoff and skipped turns. They do not create a standing time commitment for volunteers.

Implementing this proposal

If accepted, the governance documentation PR will:

1. Add GOVERNANCE.md as the canonical description of roles, authority, appointments, participation, and channels.
2. Add MAINTAINING.md for the detailed review and merge process.
3. Update CONTRIBUTING.md to act as the directory for project processes.
4. Update TRIAGE.md for the Project Team name, public-first coordination, and escalation rules.
5. Rename the Discord role and channel from Triage Team and #triage to Project Team and #project-team.
6. Create or update GitHub teams so Project Team maps to Triage access, Maintainers maps to Write access, and repository administration remains separate.
7. Update repository rules and review-state automation so bot approvals cannot satisfy the human review requirement.
8. Review and document release, publishing, infrastructure, and administrative access separately.

The initial Project Team and Maintainers membership can then be announced under the accepted policy.

Feedback requested

This proposal takes a position rather than asking for a governance model from scratch. Feedback is particularly useful on:

• Whether the boundaries between Project Team, Maintainers, and Project Lead are clear enough to use.
• Whether the default one-maintainer approval and the two-approval rule for privileged paths cover the right changes.
• Whether the public, #project-team, and #maintainers boundaries leave any common work without an appropriate place.
• Whether the six-month private check-in and annual access review balance volunteer breaks with supply-chain security.
• Which operational responsibilities need clearer delegation before maintainers receive Write access.

After public feedback and consultation with the current team, the Project Lead will post a decision summary and open the documentation and configuration pull requests needed to implement the accepted model.

[keybits]

This looks excellent and a great evolution for emdash governance (from the perspective of an interested user / hopefully more active community member soon)!

The heading Public and private channels could maybe be renamed Public and private Discord channels for clarity.

I especially like:

Discord can help people discover and coordinate work, but it must not hold the only record of a decision.

[ascorbic]

I think it should be the other way: it needs to be clearer that "channels" refers to all places where we're having discussions, such as GitHub

[swissky]

Thanks for writing this up, Matt. This is a really clear proposal, and it puts into words a lot of what has been working informally over the last months.

A few things I especially like:

• Public by default, with decisions written back to GitHub. As someone on the triage side, the rule that discussion about what to do is public and coordination about who handles it can happen in #project-team is the most useful line in the doc. It's easy to apply in practice.
• Separating roles from access. Treating Write, publishing, releases and secrets as separate capabilities, plus the regular access review, is a good answer to the supply-chain risk. Framing inactivity as a private check-in rather than a public removal keeps it humane for volunteers.
• No routine self-merge, and bot reviews don't count as approval. emdashbot catches a lot, but having a human own every merge, including for the Project Lead, is the right call.

On your feedback questions, two small things:

1. Delegating operational responsibilities: ci:rerun already lets triagers retry failed runs, but runs from first-time contributors that are waiting for approval (action_required) are deliberately left to a maintainer, since approving them needs Write access. That's one of the first things a triager runs into when helping a new contributor along. It might be worth stating who handles those approvals, or whether some Project Team members should be able to.

2. Making the Maintainers list visible in the repo: GitHub team membership isn't always visible to outside contributors. A short list in GOVERNANCE.md would make it clear whose approval counts toward the merge requirement.

Happy to help with the TRIAGE.md update once this is accepted.

[ascorbic]

1. Yes, we should add another automation to allow project team to trigger CI in that case too. Maybe just simplify to a single ci:run label.

2. Absolutely. GitHub team membership might not even be the canonical source. I think we follow Astro again here: the teams are listed in the GOVERNANCE.md

[MA2153]

LGTM! Thank you for working on this 🙌

[CacheMeOwside]

Thanks for putting this together, Matt!

I support the distinction between Project Team reviews and maintainer approval, as it is especially valuable for bot-authored changes: a passing check or bot verdict may not verify runtime behavior. The Project Team can contribute that validation while the maintainer remains responsible for the merge decision.

[ascorbic]

Yeah I think we need to be clear that the bots are an example where permissions != team membership. A bot can review, but it's not a maintainer

[danielmlr]

Thanks Matt, this reads really well.
Public by default and "a bot can review, but it's not a maintainer" are exactly the right calls.

Two small things:

1. Who counts as the author. The approval has to come from a maintainer "other than the author". But what if I push a few commits to someone else's PR, or to an emdashbot PR? As Establish governance and contribution processes #3808 is written, I could still approve it, and my approval would then cover my own code. Maybe anyone with commits in the current revision shouldn't count as an approver?

2. When you're away. Accepting RFCs, placing roadmap items and appointments all go through the Project Lead. It would help to say who covers those while you're on leave, or that you can hand the RFC decisions for an area to a maintainer.

[ascorbic]

1. I'd say just the main author, unless someone has made substantial changes to it
2. Let's say that I will designate somebody when I'm away, and will set the scope. I would imagine that in most cases RFCs can wait til I return, but other design PRs can be approved by whoever I designate