Run it in 30 minutes with a pre-read, a named decider, and a decision written down before the call ends. Spend five minutes on facts, ten on options, ten on risk and five on the decision and next steps. If facts are missing, schedule a short follow-up instead of debating.
Before the meeting
The meeting is only as good as its pre-read. The person who raised the dispute prepares one page, shared a day ahead:
- The package, current version and proposed version.
- The reason: an advisory, a bug, or a compatibility need.
- Which services use it, from a dependency inventory.
- Whether the affected code is reachable in each service.
- The patch, minor or major classification, using Semantic Versioning definitions.
- The current test status of the proposed change.
Invite only the decider, one person from each affected team, and a note taker. More people turn a decision meeting into a briefing.
Roles
| Role | Job |
|---|---|
| Decider | Makes the call; the owner of the build or shared version list |
| Facilitator | Keeps time, parks tangents |
| Team reps | Speak for their service, not for the whole department |
| Note taker | Writes the decision record live |
The decider is named in your dependency policy, not chosen in the room.
The 30 minute agenda
Minutes 0 to 5: facts. The facilitator reads the pre-read summary. Team reps correct errors only. Nobody argues yet.
Minutes 5 to 15: options. List three at most, written on screen:
- Upgrade the direct dependency that brings in the version.
- Override the transitive version in the root build.
- Accept the risk for a stated period, with a review date.
Each option gets a one line cost and a one line risk. Maven, Gradle, npm and Cargo all support some form of root level override, so the question is rarely "can we" and nearly always "should we, and who owns it."
Minutes 15 to 25: risk. Each team rep answers one question: what is the worst realistic outcome for my service if we choose this? Keep answers concrete, such as "login flow fails on token parsing," rather than abstract.
Minutes 25 to 30: decide. The decider states the decision, the scope, the owner of the follow-up, and the review date. The note taker reads it back.
Anti-patterns to avoid
- Debating severity scores. Use the advisory and reachability facts instead.
- Letting the loudest team set the agenda.
- Ending with "let us align offline." Either decide, or name exactly which fact is missing and who will get it by when.
- Reopening a closed decision without new information.
After the meeting
Send the record to everyone within an hour. Link it from the manifest comment. Put the review date on a calendar or ticket so it fires without anyone remembering.
If your team uses a policy gate on pull requests, update the policy exception at the same time, with the same expiry, so the pipeline and the decision agree.
Quick check
What if the facts are disputed?
Pause the meeting and assign one person to produce the missing fact, such as a test run or an inventory export, with a deadline of one or two business days. Then reconvene for 15 minutes.
Do we need this meeting for every bump?
No. Use it only when two teams disagree and the default process has not resolved it.
Sources
Last reviewed: 19 October 2026.
