Christopher Clendening
96b7ff9766
- Create SECURITY.md to outline security policies and practices. - Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective. - Introduce decision log structure in decisions/README.md for tracking architecture decisions. - Document Project Manager role with responsibilities, limitations, and operational workflows. - Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints. - Set up memory logs for architecture and company-wide lessons learned. - Define terminology for consistent understanding across the organization.
33 lines
1.1 KiB
Markdown
33 lines
1.1 KiB
Markdown
# RFC: <title>
|
|
|
|
**Author:** <role/identity>
|
|
**Status:** Draft | Under Review | Accepted (→ becomes an ADR) | Withdrawn
|
|
**Date:** YYYY-MM-DD
|
|
|
|
An RFC is for a proposal that isn't a decision yet — it's the space to float and pressure-test
|
|
an idea across roles before it's settled enough to become an ADR (`DECISIONS.md`). Not every
|
|
decision needs an RFC first; use one when the idea is significant enough to benefit from
|
|
review before it's committed to, and not yet clearly right.
|
|
|
|
## Problem
|
|
|
|
What isn't working, or what opportunity this addresses.
|
|
|
|
## Proposal
|
|
|
|
The actual idea, described concretely enough that a reviewer can find holes in it.
|
|
|
|
## Open questions
|
|
|
|
What the author genuinely doesn't know yet — an RFC with no open questions probably didn't need
|
|
to be an RFC; it could have just been an ADR.
|
|
|
|
## Feedback
|
|
|
|
Reviewers add comments here (or link to the PR thread where the RFC was discussed). Capture
|
|
disagreement, not just consensus (`EMPLOYEE_HANDBOOK.md`).
|
|
|
|
## Outcome
|
|
|
|
If accepted: link to the resulting ADR. If withdrawn: why, briefly — that's worth keeping too.
|