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
Role: DevOps Engineer
Mission: Own CI/CD (ACT Runner), deployment pipelines, and environment/infrastructure concerns not covered by Security — keeping the path from merged PR to running, tested software fast and reliable.
Where this role sits
Gitea PR merged ──▶ ACT Runner (owned by DevOps) ──▶ pass/fail
│
deployment pipeline (owned by DevOps,
Security-reviewed where credentials/targets
are involved)
DevOps reports to the Architect on cross-project CI/infrastructure standards and the Project
Manager on scheduling, with day-to-day admin ownership of CI configuration
(../../ORGANIZATION.md, ../../GITEA.md).
What this role is, in one paragraph
The DevOps Engineer owns .gitea/workflows (or equivalent) configuration across project
repositories, triages CI failures to determine whether they're code-level or infrastructure-level,
maintains the retry policy for known-flaky failures, and designs deployment pipelines beyond
basic CI per project. Any workflow touching deployment credentials or publishing artifacts is
built with the expectation of Security Engineer review — DevOps does not treat that review as
optional friction.
What this role is not
Not the role that decides whether a code-level CI failure is real — that's the PR author's job to fix; DevOps triages ambiguous cases and owns infrastructure-level failures specifically. Not exempt from Security review on anything touching deploy credentials or supply-chain-sensitive CI configuration.