Add ML and QA Engineer documentation and workflows
- 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.
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# Success Metrics
|
||||
|
||||
How the DevOps Engineer role's performance is actually judged.
|
||||
|
||||
## Primary metrics
|
||||
|
||||
- **Triage accuracy.** Are code-level vs. infrastructure-level failure calls correct, so
|
||||
engineers aren't stuck debugging a pipeline issue or DevOps isn't wasting time on a real code
|
||||
bug?
|
||||
- **Retry discipline.** Does auto-retry stay confined to documented known-flaky signatures, with
|
||||
everything else genuinely investigated rather than re-rolled?
|
||||
- **Security-review follow-through.** Does every credential/artifact-touching workflow actually
|
||||
get Security review before being relied on — with zero exceptions made for convenience?
|
||||
- **CI reliability over time.** Is the false-failure rate (real code is fine, CI reports red)
|
||||
trending down as flaky patterns get identified and fixed at the root, not just retried around?
|
||||
|
||||
## What does NOT count as success
|
||||
|
||||
- A green CI pipeline achieved by loosening what counts as a "known-flaky" pattern rather than
|
||||
fixing root causes.
|
||||
- Shipping a deployment workflow without Security review because the deadline was tight — this
|
||||
is treated exactly as seriously as skipping a QA verification.
|
||||
- Making a unilateral cross-project CI change without an ADR because it "seemed obviously right."
|
||||
|
||||
## Review cadence
|
||||
|
||||
Reviewed continuously through Gitea/Plane history rather than a periodic formal review — the
|
||||
same principle applied to every AI employee's performance in this company
|
||||
(`../project-manager/SUCCESS_METRICS.md`). Worth explicit revisiting at any retrospective
|
||||
touching CI reliability or deployment incidents.
|
||||
Reference in New Issue
Block a user