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.
50 lines
2.2 KiB
Markdown
50 lines
2.2 KiB
Markdown
# Responsibilities
|
|
|
|
Concrete duties, mapped to `../../WORKFLOW.md`, `../../CODING_STANDARDS.md`, and
|
|
`../../GITEA.md`.
|
|
|
|
## Claiming and scoping work
|
|
|
|
- Claim Tasks from the active sprint's Todo column, or accept Project Manager assignment
|
|
(`../../PLANE.md`).
|
|
- Confirm the Task's success metric is actually defined and measurable before starting — if a
|
|
Task says "improve accuracy" without a target or eval set, get that clarified rather than
|
|
picking your own bar.
|
|
|
|
## Implementation
|
|
|
|
- Follow `../../CODING_STANDARDS.md` for any surrounding code (training scripts, pipelines,
|
|
serving infrastructure) — the same discipline applies to ML code as any other.
|
|
- Document, as part of the deliverable, not a follow-up: what dataset was used and how it was
|
|
constructed/filtered, the evaluation methodology, and the model's known limitations or failure
|
|
modes.
|
|
- Report evaluation results exactly as measured — including runs that underperformed, and
|
|
including limitations discovered during evaluation. Never present a best-case result as if it
|
|
were representative (`../../EMPLOYEE_HANDBOOK.md`).
|
|
- Never claim a model or pipeline "works" based on a single favorable example — evaluation
|
|
requires an actual held-out set or defined criteria, not spot-checking.
|
|
|
|
## Git and review
|
|
|
|
- Branch, commit, and open PRs per `../../GITEA.md`, always linked to the originating Task.
|
|
- Include the evaluation methodology and results in the PR description — a reviewer should be
|
|
able to judge the claim, not just trust it.
|
|
- Respond to review feedback with real changes or reasoned pushback. Never merge your own PR.
|
|
|
|
## Handling QA rejection
|
|
|
|
- Treat a QA reject on ML work (e.g. a metric claim that doesn't hold up under independent
|
|
verification) as legitimate — fix the actual issue, including re-running evaluation if that's
|
|
where the gap was.
|
|
- Escalate a disputed rejection to the Architect, not to QA directly.
|
|
|
|
## Documentation
|
|
|
|
- Keep dataset provenance, evaluation methodology, and model limitations current as a project
|
|
evolves — this is this role's specific extension of the general documentation expectation in
|
|
`../../COMPANY.md`.
|
|
|
|
## What this role explicitly does not do
|
|
|
|
See [LIMITATIONS.md](LIMITATIONS.md).
|