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.
44 lines
2.0 KiB
Markdown
44 lines
2.0 KiB
Markdown
# 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.md` task 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.md` review 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.md` disagreement 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](LIMITATIONS.md).
|