Resolve a public split between senior maintainers

Question: Resolve a public split between senior maintainers

Companies: Hugging Face

Problem statement

As a new maintainer facing two senior maintainers publicly split over an architectural change, propose governance that resolves this dispute, prevents repeats, and repairs trust. Reported on 1point3acres' Hugging Face bank; reconstructed in our own words.

What the question probes

The scenario: you've recently become a maintainer of an open-source project. Two senior maintainers disagree, publicly and sharply, about an architectural change. Contributors are taking sides in the issue thread, pull requests are stalling, and users are asking whether the project is in trouble. You're asked how you'd resolve this dispute, prevent the next one, and repair trust.

It tests:

1. Humility and standing. You're new. You can't overrule two senior people; you can help them reach a decision.
2. Process over verdict. The best answers don't say who's right. They create a way for the project to decide.
3. Separating the technical question from the relationship. Both need work, in different places.
4. Governance design. Lightweight rules that would have prevented this, proportionate to the project.
5. Public communication. Users and contributors need to know the project is functioning.

Step 1: lower the temperature

In the first day or two:

• Move the discussion out of the hot thread. Post a short, neutral comment: the disagreement is important, both maintainers care about the project, and a written comparison is coming. Lock or slow the thread if your project's norms allow, explaining why.
• Talk to each maintainer privately, separately. Ask what they're worried will happen if the other approach wins. The stated position is usually "approach A vs B"; the underlying concern is often performance for a key user group, maintenance burden, or feeling sidelined.
• Don't take a side yet, even if you have a view. Your value is as the person both trust to run a fair process.

Step 2: turn the argument into a decision record

Write, or ask both to co-write, a short design document:

Agreeing on criteria before looking at evidence is the most important move. It turns "who wins" into "what does the data say about the things we both said matter".

If evidence is missing, propose a time-boxed experiment: each side prototypes the critical path in two weeks, measured on the agreed benchmarks.

Step 3: decide, with a fallback

Most projects have some decision rule, even if implicit. Use it, or propose one:

• Consensus among maintainers with a deadline.
• If no consensus by the deadline, a pre-agreed tie-breaker: the project lead, a vote of the maintainer group, or a small technical steering group.
• Whoever loses gets their view recorded in the decision document, and a review point (for example, after the next release) where the decision is checked against the criteria.

Step 4: prevent the next one

Propose governance proportionate to the project's size. For a project with, say, 8 maintainers and 300 contributors:

• A lightweight RFC process for changes that affect public APIs or architecture: a template like the one above, a two-week comment period, decision by maintainer consensus with a named tie-breaker.
• A written decision rule in GOVERNANCE.md: who decides what, how disputes escalate, and that design debates move from issues to RFCs once they pass a certain length.
• A code of conduct section on disagreement: critique ideas in public, raise concerns about people in private.
• Regular maintainer syncs (monthly video call) so disagreements surface early, before they're public.

Don't over-build. A 20-page charter for an 8-maintainer project will be ignored.

Step 5: repair trust

• With the maintainers: credit both publicly in the decision post. Give the maintainer whose option lost a visible role in the implementation or the review point, if they want it.
• With contributors: a short post explaining what was decided, how, and the new RFC process so they know how to propose changes.
• With users: confirm what the change means for them and the timeline. Most users care only about that.

Worked answer (L5)

"I'd start by talking to both maintainers privately, separately, within a day. In my experience the public argument is about the design but the private concern is about something else. Say maintainer A worries that B's plugin architecture will slow down the core path by 15–20% for the common case, and B worries that A's monolithic approach means every new backend has to go through the two of them, which is already the project's bottleneck: 40 open PRs waiting on review.

Both concerns are measurable. I'd propose a short design doc where each writes their own option, and we agree on criteria first: overhead on the three standard benchmarks, and how many files a new backend has to touch. Then a two-week prototype of the critical path.

If the prototype shows plugin overhead at 2%, B's approach wins on the agreed criteria; if 15%, A's does, or we look for a hybrid. Either way the decision follows from criteria they both agreed to.

For the future, I'd suggest an RFC template and a rule that once a design thread passes about 30 comments it moves to an RFC. And I'd publicly thank both, because they both care about the project, which is why they argued."

Worked answer (L6)

"Three things are broken here, and I'd treat them separately: a technical decision, a relationship between two people the project depends on, and the community's trust that the project can make decisions.

For the decision: private conversations first, then a decision record with criteria agreed before evidence, and a time-boxed experiment. I'd ask a respected maintainer from a neighboring project to review the criteria for fairness, so the process doesn't depend on me being seen as neutral.

For the relationship: they've probably been arguing for a while. I'd ask each what they'd need to be comfortable if the other approach won. Often it's a guarantee, like a performance budget in CI, which can be added regardless of the outcome. That makes the decision less zero-sum.

For the community: the project has no visible way to decide disputes, which is the real failure. I'd draft a short governance document with the other maintainers: an RFC process, a decision rule with a tie-breaker, and a norm that design arguments move out of issue threads. I'd measure whether it's working: time from RFC to decision, number of design disputes escalated, and whether new contributors' first PRs get reviewed faster.

One risk I'd name: I'm new, and proposing governance can look like a power grab. So I'd propose it with existing maintainers as co-authors, and only after the immediate dispute is resolved."

Red flags

• Picking a winner on technical merit as the newest maintainer.
• Only fixing the technical decision, ignoring the relationship and community trust.
• Heavy bureaucracy for a small project.
• Taking it all private. The community needs to see the outcome and process.
• Ignoring the power dynamic of being new.

Follow-ups

• "One maintainer threatens to fork the project if they lose. What do you do?"
• "The data supports neither option clearly. Now what?"
• "What if a corporate sponsor of the project prefers one option?"
• "How would this differ inside a company, where there's a manager to escalate to?"
• "How do you tell whether the new governance is working?"

Interviewer expectations

Mid-level (L4)

• Calms the public thread, talks to both people, and suggests evaluating options against criteria.
• Communicates the outcome to contributors and users.

Senior (L5)

• Uncovers each side's underlying concern and makes it measurable; criteria agreed before evidence; a time-boxed experiment.
• Proposes a proportionate RFC process and a decision rule with a tie-breaker.
• Credits both maintainers and gives the losing side a role.

Staff (L6+)

• Separates the decision, the relationship and community trust, with a plan for each.
• Makes the decision less zero-sum (guarantees like performance budgets), and builds governance with existing maintainers as co-authors.
• Is aware of their own position as a newcomer and of outside pressures (forks, sponsors), and defines how to measure whether the new process works.