What this template is for
RFCs (also called tech designs, ADRs, or just “design docs”) are how teams make non-trivial technical decisions without the result being whatever the loudest engineer in the room argued for. Done well, RFCs are the difference between a system that evolves coherently and one that accumulates incompatible decisions made in isolation.
This template has two halves:
- Required fields on the create screen - author, context, proposed approach, alternatives, trade-offs, reviewers, deadline. The discipline of filling in alternatives and trade-offs is the most valuable part of writing an RFC.
- STM-created review sub-tasks - draft, identify reviewers, announce, address feedback, decide, communicate, link implementation. The communication step is the one that fails most; RFCs get approved but the team that needs to act on them never finds out.
When to use it
Use this template for changes that meet the rule of three: 3+ engineers affected, 3+ months of impact, or 3+ alternatives worth considering. New service introductions, major refactors, cross-team API changes, and infrastructure choices typically qualify.
Don’t use this template for individual feature work (use stories) or for time-boxed research (use spikes). The RFC is for decisions, not investigation - if you don’t yet know enough to propose an approach, you need a spike first.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | RFC: replace bespoke queue with Kafka for checkout events | Yes |
Author | @engineer.who.wrote.it | Yes |
Status (custom) | Draft / In Review / Approved / Rejected / Superseded | Yes |
Context (custom) | Why is this RFC needed? What problem prompted it? | Yes |
Proposed Approach (custom) | What we'll do; not how we'll implement | Yes |
Alternatives Considered (custom) | At least 2 alternatives with reasons for rejection | Yes |
Trade-Offs (custom) | Honest about what gets worse, not just what gets better | Yes |
Required Reviewers (custom) | List the named reviewers whose approval is required | No |
Approval Deadline (custom) | 2026-05-30 - reviewers respond by, or silence = approval | No |
Linked Doc | Link to the full RFC document - the ticket is the tracking record | No |
Components | checkout, infra | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Draft the RFC document and link it from the ticket
- Identify required reviewers and add them as watchers
- Announce in the team channel with the approval deadline
- Address reviewer feedback - either accept or document why not
- Final decision: approved / rejected / superseded by [link]
- Update status field and notify watchers
- If approved: link the implementation stories or epic
Common questions
What's the difference between an RFC and an architecture decision record (ADR)?
An RFC proposes a decision and invites discussion before it's made. An ADR documents a decision after it's been made. The Jira RFC ticket and document evolve through draft -> review -> approved status; once approved, the document becomes the team's ADR for that area. Same content, different lifecycle stage.
When does a change need an RFC vs a regular Jira story?
Use the rule of three: 3+ engineers affected, 3+ months of impact, or 3+ alternatives worth considering. Smaller changes can be made in code review or PR description. Larger changes need explicit team agreement before code is written, because reverting design decisions is much more expensive than reverting code.
What goes in the 'alternatives considered' section of a Jira RFC?
At least two alternatives with honest reasons for rejection. The point isn't to perform thoroughness; it's to flush out the unstated assumptions in the proposed approach. RFCs without alternatives often get approved and then re-litigated when someone notices an obvious alternative six months later.
How long should an RFC stay open for review?
Long enough that anyone who needs to weigh in can, but short enough that decisions don't stall. One to two weeks is typical. Set an explicit approval deadline on the ticket; the silence-equals-approval default lets the author ship if reviewers don't engage.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →