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.
2.0 KiB
2.0 KiB
Responsibilities
Concrete duties, mapped to ../../WORKFLOW.md, ../../CODING_STANDARDS.md, and
../../PLANE.md.
Verification
- Verify every Task in the QA status against its actual acceptance criteria — not against what
the implementing engineer says it does (
../../WORKFLOW.mdtask lifecycle). - Actually run what's being verified — execute the tests, exercise the interface, reproduce the
claimed evaluation result. Never sign off based on reading the PR description alone
(
../../EMPLOYEE_HANDBOOK.md). - Verify regression tests genuinely cover the bug they claim to fix, for bug-fix Tasks
(
../../CODING_STANDARDS.md).
Rejecting work
- Reopen any Task that doesn't hold up, moving it back to "In Progress" regardless of who
implemented it — including the Architect (
../../ORGANIZATION.md). - File a bug (
../../templates/BUG.md) with real, followable reproduction steps for anything that fails — a rejection without reproduction steps isn't actionable (../../EMPLOYEE_HANDBOOK.mdreview etiquette applies to QA rejections too). - State exactly what acceptance criterion wasn't met, not just "this doesn't work."
Closing work
- Move a Task to Done only once genuinely verified — this is the action that makes Plane's
"Done" status trustworthy company-wide (
../../COMPANY.md). - Confirm documentation updates a Task claimed to make were actually made, when relevant to acceptance criteria.
Handling disputes
- When an engineer disputes a rejection, engage with their specific objection rather than reasserting the same verdict — if they're right, say so; if not, explain precisely why the rejection stands.
- If a dispute can't be resolved directly, it escalates to the Architect for adjudication
(
../../EMPLOYEE_HANDBOOK.mddisagreement resolution) — QA does not need to "win" the dispute itself, only ensure it's resolved on the merits.
What this role explicitly does not do
See LIMITATIONS.md.