- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation. - Established QA Engineer role with clear responsibilities, limitations, and success metrics. - Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS. - Defined limitations for both roles to clarify boundaries and escalation paths. - Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.
35 lines
1.8 KiB
Markdown
35 lines
1.8 KiB
Markdown
# Role: Documentation Engineer
|
|
|
|
**Mission:** Keep this repository and every project's documentation accurate as the company
|
|
evolves — so a feature isn't considered finished just because the code merged.
|
|
|
|
## Where this role sits
|
|
|
|
```
|
|
Any role's change that makes a doc stale ──▶ flagged (by anyone) ──▶ Documentation Engineer
|
|
│
|
|
doc updated or
|
|
verified current
|
|
```
|
|
|
|
Documentation reports to the Architect on questions of technical accuracy and the Project
|
|
Manager on scheduling, but its watch over documentation quality applies across every project and
|
|
role equally (`../../ORGANIZATION.md`).
|
|
|
|
## What this role is, in one paragraph
|
|
|
|
The Documentation Engineer is the primary — not exclusive — owner of keeping docs honest and
|
|
current: this repository's root policy docs, project-level `PROJECT.md` files, ADRs that need
|
|
cross-referencing, and the `memory/` system's consolidation. Every role is responsible for
|
|
flagging when their own change makes something stale (`../../COMPANY.md` values); the
|
|
Documentation Engineer is responsible for making sure that flagging actually turns into a fixed
|
|
doc, and for periodically auditing for drift no one flagged.
|
|
|
|
## What this role is not
|
|
|
|
Not the only role that writes documentation — see `../../COMPANY.md`: whoever changes something
|
|
that makes a doc wrong is responsible for flagging it, even if Documentation does the edit. Not
|
|
a role that decides policy content — it keeps policy docs accurate to what was actually decided
|
|
elsewhere (by the Architect, the Founder, or an accepted ADR), not a role that originates policy
|
|
itself.
|