Commit 24e55aaa authored by David Dieulivol's avatar David Dieulivol 4️⃣
Browse files

DA: Highlight monolith and Modular Features as targets in mission and pillars

parent 0111ed9c
Loading
Loading
Loading
Loading
+4 −4
Original line number Diff line number Diff line
@@ -11,17 +11,17 @@ Every GitLab project gets a development health score out of the box: real-time,

### Mission

We surface development health signals across the SDLC and make them visible to the teams that own them. We are customer zero: we prove patterns on GitLab's own Engineering first, then influence and collaborate with product teams to ship them to every customer.
We surface development health signals across the SDLC and make them visible to the teams that own them. We are customer zero: we prove patterns on GitLab's own Engineering first, then influence and collaborate with product teams to ship them to every customer. We work with both the GitLab monolith and Modular Components as first-class targets — each initiative focuses on whichever platform makes sense, but we keep both in mind.

### Strategic Pillars

#### Development Health Signal Platform

Own the full SDLC signal layer for GitLab engineering. Push development health data into the product so it is available to users, AI agents, and dashboards. Deliver scorecards from engineer to VP level.
Own the full SDLC signal layer for GitLab engineering, covering both the monolith and Modular Components. Push development health data into the product so it is available to users, AI agents, and dashboards. Deliver scorecards from engineer to VP level.

#### Customer Zero -> Product Influence

We operate as an internal lab embedded in GitLab Engineering. We identify development health gaps, build lightweight signals and/or instrumentation to surface them, and validate their value on real Engineering work. Then we partner with product teams to bring those signals natively into GitLab — so every customer gets them without custom instrumentation.
We operate as an internal lab embedded in GitLab Engineering. We identify development health gaps, build lightweight signals and/or instrumentation to surface them, and validate their value on real Engineering work — across both the monolith and Modular Components. Then we partner with product teams to bring those signals natively into GitLab — so every customer gets them without custom instrumentation.

#### Tooling Stewardship

@@ -59,7 +59,7 @@ There is also a direct product opportunity: GitLab is prototyping [in-product fl

#### Theseus — CI/CD & Test Observability for Modular Features *(best effort)*

Theseus is the future development platform for GitLab. Every new Modular Component will build on it. DA has a chance to get involved early and establish what good observability looks like for Modular Features. Nobody in DA has validated the end-to-end CI/CD and test signal flow for a Theseus-based component yet. If we do it on a pet project first and validate it on Artifact Registry, we give every future Modular team a paved path to follow.
Theseus is the future development platform for GitLab. Every new Modular Component will build on it. DA has a chance to get involved early and establish what good observability looks like for Modular Components. Nobody in DA has validated the end-to-end CI/CD and test signal flow for a Theseus-based component yet. If we do it on a pet project first and validate it on Artifact Registry, we give every future Modular team a paved path to follow.

*Epic: [Theseus Test & CI Observability](https://gitlab.com/groups/gitlab-org/quality/analytics/-/work_items/49)*