| name | engineering-emergency-changes |
| description | Use when a code hotfix, rollback alternative, production/security/legal fix, launch blocker, or hard external deadline claims expedited review or relaxed process. TRIGGER on "emergency change", "hotfix", "prod incident", "major security hole", "must ship today", "hard deadline", "bypass review", or "fast-track this PR" for qualification only. DO NOT TRIGGER for ordinary urgency, soft deadlines, Friday timing, manager pressure, time-zone delay, or review unless emergency status is disputed.
|
Engineering Emergency Changes
Emergency review is for rare cases where speed of the entire change matters more than normal review depth. It does not mean "skip engineering judgment"; it means narrow the change, verify the emergency, prioritize correctness, and schedule follow-up review.
Adapted from Google Engineering Practices Documentation, especially "Emergencies" and the reviewer speed guidance. Source: https://google.github.io/eng-practices/review/emergencies.html. License: CC-BY 3.0.
Emergency Gate
Treat a change as an emergency only when it is a small targeted change and at least one condition is true:
- It prevents a major launch from failing when rollback is not the right option.
- It fixes a bug that is significantly affecting production users.
- It addresses a pressing legal or compliance issue.
- It closes a major security vulnerability.
- It satisfies a hard external deadline where missing it would cause contractual, legal, security, production-user, or clearly disastrous launch harm.
These are usually not emergencies by themselves:
- Wanting to launch sooner.
- A feature has taken a long time and the author wants it merged.
- Reviewers are asleep, away, or in another time zone.
- It is late Friday.
- A manager wants it done today for a soft deadline.
- The team wants to avoid normal review discomfort.
