Objecting well
An objection is the most useful answer a reviewer can give, as long as the author can act on it. unbranch requires two things in every objection: the specific risk, and the revision that would resolve it.
A good objection
Section titled “A good objection”Risk: Exporting every customer’s data on a nightly schedule sends personal data to a destination we have not reviewed. What would resolve it: Limit the export to accounts that have opted in, or add a constraint that exports go only to the destinations listed in the data-processing agreement.
The author knows exactly what to change, and you know exactly what you will consent to.
A weak objection
Section titled “A weak objection”I don’t think we should do this right now.
That is a preference, not a risk, and it gives the author nothing to revise. If timing is the real concern, name the risk the timing creates.
Habits
Section titled “Habits”- Object to the revision in front of you. Answer the current text, not the proposal you expected.
- Prefer a constraint to a block. Often the fix is one boundary the proposal will respect. Say which.
- Consent when the risk is gone. After a revision resolves your objection, answer again. Your earlier reasoning stays in the ledger.
- Abstain when it is not yours to judge. Abstaining counts as answered without endorsing.
- Remember the escape valve exists. If no revision can resolve it, a project owner or admin can reject the proposal on the record. That is a decision, not a failure of the process.
For authors receiving one
Section titled “For authors receiving one”Treat an objection as the next revision’s brief. Address the named risk directly, mark the revision as material, and say in the description what changed and why.