We just merged GOVERNANCE.md, the first official governance document in Meteor’s history.
It explains how the project is organized, who does what, and how decisions get made. It sits alongside CONTRIBUTING.md, which stays the day-to-day reference for contributing.
Before anything else: thank you to everyone who spent the last four months arguing with me in #14426. The document that got merged is very different from the one I opened, and it’s better because of that discussion.
Why now
For years Meteor ran on informal trust and a small group of people who simply showed up. That worked. But informal doesn’t scale, and it doesn’t make the path visible to the next person who wants in.
The honest version is that there are decisions in this project only two or three people can make right now. Whether an old issue is still worth reopening. Whether a proposal is the right shape. Which of two approaches to take inside DDP or the build system. Those calls need context, and the context has stayed inside a very small group. That’s a bottleneck we created, not one the community created.
AI-assisted development made it harder to ignore. Writing code got cheap; what didn’t get cheaper is context, judgment, and follow-through.
This document is a first step toward that.
Contributors and maintainers are not the same thing
This is the part I most want to get across, because it’s the why behind everything else.
When you contribute to a project, the usual pattern is a lot of PRs, often small, often real improvements. You look at what you need or what you want to fix, and you fix it. That’s healthy, and we want more of it, not less.
A maintainer looks at the whole project. The horizon is longer. You tend to work on the pillars, open fewer PRs, and spend a good part of your energy helping the community converge on what matters most right now.
Nacho and I don’t open nearly as many PRs as we’d like. We usually spend months inside a single bigger feature: change streams, the Rspack integration, better TypeScript support, CapacitorJS. And while we’re heads-down on one thing, we try to triage and bring in as much of the community’s work as we can.
We can’t keep being the only ones doing both. Not because too much is coming in, but because Meteor has real problems that deserve someone thinking about them the way we think about ours, and there’s no room for that when every call routes through the same three people.
So this isn’t a request for help clearing a queue. It’s an invitation to people who already care about a part of Meteor to have a real say in it, and to be trusted to make decisions there without checking with us first.
What a Core Maintainer is
Core Maintainers are trusted community members who help keep Meteor moving. They review pull requests and triage issues: labeling, assigning, and helping move contributions toward merge. They hold triage permissions on meteor/meteor.
They do not merge into core or publish releases. That stays with the TSC. This was a deliberate change during the discussion: recognition and stewardship shouldn’t automatically come bundled with the most dangerous permissions in the project. If you’ve been following the supply-chain conversations in open source over the last couple of years, you know why.
Being a Core Maintainer is not a job. No contract, no pay, no employer relationship with Meteor Software or anyone else. Core Maintainers are independent open-source contributors trusted with triage rights. Everything below is a community expectation, not a work obligation.
What’s expected
Four things.
Review and triage. Pull requests and issues. Not as a chore being handed off — a review is a judgment call, and those are better made by someone who knows the area than by whoever happens to have a free afternoon.
Pick at least one front and give it attention. A roadmap item, a package, another repo under the Meteor organization, whatever you care about. It’s voluntary; it shouldn’t stop you from working on other things, and you can take breaks. It just means the community knows this is something you’re looking after.
Guide and invite new contributors. Being a Core Maintainer means your read on things carries weight here. When you say a proposal is worth pursuing, or that an approach is the wrong shape, people listen. We expect you to use that to bring people in rather than only to filter them out: answer the first-timer’s question, tell someone their idea is good and point them at where to start, nominate people you think should be maintainers themselves. Writing docs and creating Meteor content counts here too. Most of us are in this project because someone did that for us once.
Follow the Code of Conduct.
That’s the whole list. You are explicitly not required to work on the roadmap. You work on what you think matters most.
What Core Maintainers get a say in
Core Maintainers are close to the code and close to users, so their voice carries weight:
- They help shape the roadmap — what to prioritize, what to postpone, what to drop. The roadmap stays the TSC’s call, but there’s now a defined advisory role: the TSC and the active Core Maintainers hold a roadmap discussion before major updates go public, and a short summary gets published.
- They can be brought into discussions before a decision opens to the wider community.
- They have a say in how the governance document and the project’s processes change over time.
On decisions: small calls inside a front belong to the Core Maintainer looking after it. For changes to core like a breaking change, a new experimental package, a change to the governance document, the active Core Maintainers deliberate and make a recommendation, and the TSC makes the final call. When the TSC goes against the recommendation, it normally documents the reasoning publicly.
Where Meteor Software fits
The document states this plainly rather than leaving it to be inferred: Meteor is owned and led by Meteor Software, with meaningful community participation. It is not an independent, foundation-run project.
The TSC is made up of Meteor Software employees. Official releases, the long-term roadmap, and this governance model stay under Meteor Software’s control. Everything day-to-day: triage, reviews, priorities within a front, recommendations on core changes is the community’s.
Taking a break
Core Maintainers move to Alumni after 12 months of inactivity. It’s automatic, no vote, no drama. Reviewing PRs and joining discussions counts as contributing, so this only affects people who’ve genuinely stepped away.
Twelve months is deliberate. Several people in the PR discussion said the same thing: life happens, work gets busy, you need a vacation. You shouldn’t lose your standing over a quiet quarter.
Alumni keep their recognition and stay listed on the site. They just don’t hold triage rights or a vote. Coming back goes through the same nomination as anyone else.
How to become a Core Maintainer
- Anyone can open a PR nominating someone (self-nominations included). There’s no minimum time served and no required number of contributions. The nomination stands on the person’s work and on community support.
- It stays open for at least 14 days so existing Core Maintainers and the community can weigh in.
- It needs explicit support from at least two active Core Maintainers or TSC members.
- The TSC approves and merges it. Permissions are granted only after that.
- Once accepted, it’s recorded on the contributors page, which is now the single source of truth for who holds which role.
What happens next
A few things follow from this, as separate and smaller changes:
- Discord channels for contributor and maintainer coordination
- A clearer lightweight step for discussing substantial work before it becomes an active PR in the review queue
Hacktoberfest
Hacktoberfest is around the corner. More contributors is exactly what we want. What makes that go well is having people who can tell someone early whether an idea fits, point them at the right part of the codebase, and stay with it through review — so the work lands somewhere it sticks.
An invite for you
If you want to help carry a front, or you know someone who already is, open a nomination PR. And if something in the document is wrong or unclear, say so changing it is a PR like anything else.
Read it here: GOVERNANCE.md
