Write a project README that remains useful
A project README is the front door to a workspace. It should tell a new contributor why the project exists, who owns it, where current work lives, and what needs attention next.
The README's role
Folder names explain structure; the README explains intent. Place it at the project root and give it an obvious name such as 00_about_this_workspace.md or README.md. Keep it short enough to scan and specific enough to act on.
Minimum useful content
- Purpose
- The outcome the project exists to produce.
- Ownership
- The accountable owner, working owner, reviewers, and primary contact.
- Current state
- Status, current working file, last review, next review, and open decision.
- Folder map
- The role of each top-level folder.
- Naming rules
- The field order, version convention, and allowed status words.
Show current state without writing a diary
The README should answer what matters now. Keep historical detail in a decision log or changelog. Update the current file, current status, next review, and open decision whenever ownership or phase changes.
Status: reviewed
Current file: 02_active/work/handbook-draft-v04-reviewed.docx
Next review: 2026-07-14
Open decision: confirm distribution ownerExplain the folder map
Describe top-level roles, not every subfolder. A new contributor should know where incoming material goes, where active work lives, where final outputs are packaged, and where retained records belong.
"Keep things organized" is not a rule. "Move reviewed inputs out of intake every Friday" is.
Record durable links
Link to the project brief, source of truth, decision log, handoff package, and archive location. Prefer links that remain valid for the team rather than personal shortcuts or temporary share URLs.
Keep it current
Assign ownership of the README. Review it when the project changes phase, when the current working file changes, and before handoff. Archive it with the project so future readers can understand the final state.