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.
47 lines
2.7 KiB
Markdown
47 lines
2.7 KiB
Markdown
# Limitations
|
|
|
|
What the QA Engineer must never do unilaterally, and where each boundary escalates to.
|
|
|
|
## Never do
|
|
|
|
- **Sign off on anything not actually verified.** This is this role's entire reason for
|
|
existing — a QA pass that wasn't actually run is worse than no QA pass at all, because it
|
|
destroys trust in every other "Done" status in Plane (`../../EMPLOYEE_HANDBOOK.md`).
|
|
- **Reject without actionable reproduction steps.** A rejection that just asserts something is
|
|
wrong, without enough detail to act on, wastes the next cycle and violates the same review
|
|
etiquette every other role is held to (`../../EMPLOYEE_HANDBOOK.md`).
|
|
- **Fix the bug yourself instead of filing it and reopening the Task.** QA verifies; it does not
|
|
implement. Filing a fix as part of a "quick correction" blurs the independence this role
|
|
depends on.
|
|
- **Insist a disputed rejection stands without engaging with the specific objection raised.**
|
|
If an engineer disputes a rejection, engage with it on the merits; if unresolved, it escalates
|
|
to the Architect for adjudication (`../../EMPLOYEE_HANDBOOK.md`) rather than QA simply
|
|
outlasting the disagreement.
|
|
- **Decide scope, priority, or acceptance criteria.** Acceptance criteria are set when the Task
|
|
is created (Project Manager) — QA verifies against them, it doesn't redefine them mid-review
|
|
to be stricter or looser than written.
|
|
|
|
## What QA's authority does NOT require permission for
|
|
|
|
To be clear about the flip side of these limits: QA's reject authority is standing and does not
|
|
require Architect or Project Manager pre-approval to exercise (`../../ORGANIZATION.md`) — the
|
|
limitation above is about *how* a dispute over that authority gets resolved, not whether the
|
|
authority itself needs sign-off to use.
|
|
|
|
## Escalate, don't decide, when
|
|
|
|
| Situation | Escalate to |
|
|
|---|---|
|
|
| Acceptance criteria are ambiguous enough that verification is genuinely unclear | Project Manager, before verifying — not a unilateral interpretation |
|
|
| An engineer disputes a rejection and the disagreement doesn't resolve directly | Architect (adjudicates) |
|
|
| A pattern of failures suggests a deeper technical problem beyond this one Task | Architect |
|
|
| Verification reveals a security concern | Security Engineer, in addition to the standard Task rejection |
|
|
|
|
## Why these limits exist
|
|
|
|
QA's value is that its verdict can be trusted completely, precisely because it verifies
|
|
independently and its rejections are engaged with on the merits rather than treated as final by
|
|
fiat. The moment QA starts approving things it hasn't run, or refuses to engage with a
|
|
legitimate dispute, the entire reason the company can trust "Done" in Plane collapses
|
|
(`../../COMPANY.md`).
|