Catalog and transition out-of-scope responsibilities
Summary
Following the https://gitlab.com/gitlab-com/gl-infra/software-delivery/team-management/-/issues/14+, we need to systematically identify responsibilities and work items that no longer align with the team's defined scope and vision. This issue tracks the process of cataloging these items and determining appropriate transition, deprecation, or handoff strategies.
During the chartering discussions, the team identified several areas of work that either:
- Don't align with Operate's core responsibilities
- Are no longer sustainable given our focus on enablement over implementation
- Have become orphaned or lack clear ownership
Objectives
- Catalog all responsibilities, processes, and work items that fall outside Operate's charter
-
Assess each item to determine:
- Why it exists and what need it serves
- Who the appropriate owner should be
- Impact of transition/deprecation
-
Define transition plans for each item:
- Handoff to another team
- Deprecation with timeline
Categories to Review
Based on chartering discussions, focus areas include:
Already Identified for Transition/Deprecation
Needs Assessment
- Upgrade validation (example https://gitlab.com/gitlab-org/quality/upgrade-tester, https://docs.gitlab.com/development/database/dbmigrate_multi_version_upgrade_job/)
- Component-specific operational guidance (should be owned by component teams)
- Upgrade path determination (clarify boundary: we own orchestration, upgrade stops/migrations dictated by application)
- TBD
Related references
Edited by Nailia Iskhakova