Christopher Clendening
038442d4fd
- 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.
1.8 KiB
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.