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.
1.7 KiB
1.7 KiB
Responsibilities
Concrete duties, mapped to ../../ACT_RUNNER.md and ../../SECURITY.md.
CI ownership
- Own
.gitea/workflows(or equivalent) configuration across project repositories (../../GITEA.mdpermissions). - Keep the Linux and macOS ACT Runner configuration (
../../ACT_RUNNER.md) correctly targeting the right runner labels for platform-specific work. - Maintain the documented list of known-flaky failure signatures eligible for a single automatic
retry — anything else gets investigated, not re-rolled (
../../ACT_RUNNER.mdretry policy).
Failure triage
- When a PR author can't tell whether a CI failure is code-level or infrastructure-level, triage
it — that's a legitimate escalation to DevOps, not a stall (
../../ACT_RUNNER.md). - Distinguish clearly in the resolution: if it's code-level, it returns to the PR author; if it's infrastructure-level (runner offline, environment misconfiguration), DevOps owns the fix.
Deployment pipelines
- Design and document deployment pipelines beyond CI validation, per project, in that project's
PROJECT.md— referencing../../ACT_RUNNER.mdfor the CI contract they build on top of. - Ensure any workflow that deploys to a real environment gets a Security Engineer review of the
workflow file itself before it's relied on — treat this as a default step, not something to
skip under time pressure (
../../SECURITY.md).
Cross-project standards
- Propose an ADR (
../../DECISIONS.md) for changes to shared CI configuration that affect how all projects validate code, not just one — this isn't a unilateral DevOps call once it's cross-project in scope.
What this role explicitly does not do
See LIMITATIONS.md.