The R&D portion of Product and Engineering is generally structured by product section, stage, and group. Currently, we consider the data YAML files in the www-gitlab-com repository to be the single source of truth (SSOT), namely `stages.yml` and `sections.yml`. While there are efforts to create a SSOT for some of the information (such as using Workday for which team member is in which group) we would like to do a more comprehensive and holistic review of the requirements, needs, and use cases to determine the best path forward. The goal is not to choose a single tool as information can be synced across various information stores, and instead to focus on whether and how we can accommodate all stakeholders’ needs, and provide clarity through documentation for where and how updates are made. ## Additional background This issue is a follow up to https://gitlab.com/gitlab-com/office-of-the-ceo/office-of-the-ceo-team/-/issues/365 We have a number of [data YAML files](https://gitlab.com/gitlab-com/www-gitlab-com/-/tree/master/data) which are used for various websites (including handbook, marketing) and automation (including triage-ops and roulette). Refer to the [data readme](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/README.md) for more information and a diagram. At the moment, many of the YAML files are considered the Single Source of Truth (SSOT) for R&D, such as our sections, stages, and groups structure. ## Requirements list These divisions/departments were requested for information and let us know it does not apply to them: 1. IT `@dzhu-gl` 2. Marketing `@de_fraz` <details> <summary>Requirements</summary> ### People: `@ajrom` Uses cases 1. Workday stays as SSOT for which division, and department team members are in. 1. Workday soon is the SSOT for which “specialty” (stage and group) team members are in. Requirements 1. Workday is the membership SSOT, so any other data sources should sync from there. 1. Other team member information should sync from Workday, or another information source that syncs from Workday as much as possible. ### GitLab (the product) metrics: `@cbraza` `@amiebright` Uses cases 1. Display metrics by section, stage, or group. 1. Leverage the section/stage/group mapping in data models and downstream reporting (ex: group/label Service Ping metrics by section, stage, or group; filter issues by section, stage, or group) Requirements 1. Section, stage, group hierarchy in easily digestible format, such as JSON (in a location that can be brought into Snowflake). ### GitLab Handbook Use cases 1. Team member information that can be public populates the team page, and various shortcodes. 1. Sections, stages, and groups and team member membership and counterpart roles are displayed. Requirements 1. Data in an easily digestible format: YAML, JSON. YAML preferred as that’s the current format. 1. Basic team member information: name, GitLab username, role. 1. Section, stages, and groups membership and counterparts. ### Engineering: `@avanbelleghem-gl` Uses cases 1. Section, stage, group hierarchy with respective labels and list of DRIs (PM, EM) for triage purposes. 1. Basic team member information and projects list for reviewer roulette. 1. Categories used for error reports, dependencies, tests. Requirements 1. Data in an easily digestible format: YAML, JSON. 1. Basic team member information: name, GitLab username, specialty, projects. 1. Automatically assign team members to appropriate section, stage, or group according to specialty. 1. Section, stage, group hierarchy with categories. 1. Ability to add triage-ops config. 1. Specify categories for ownership of error reports, and other metric reports. ### Product: `@dtuan` Uses cases 1. Information about a product section, stage, group including members, Slack channel, direction page. 1. Questions to answer 1. Can we have a sectionless stage? - Not at the moment, but can have single stage section. 2. What if Product and Eng want to be organized differently? Example: Runners Platform (Hosted Runners), where Product: CoreDevOps > CI > Verify; Eng: Infrastructure > Production Engineering - One possibility is to separate code feature categorization for metrics, and marketing categorization. We can default to marketing categorization if the code one is not specified. Membership for Product can be one group, and Eng in a different group. 1. Team tags (to denote team members are part of a specific group) only have Backend and Frontend, no Fullstack. We do have SET for Quality, and SRE for Infra, but no DBE for Database. Should we keep these split? Or should it just all be “IC Engineers” vs “Engineering Manager”. We now have other titles like Model/AI/etc. Requirements 1. Data in an easily digestible format: YAML, JSON. YAML preferred as that’s the current format. 1. Automatically assign team members to appropriate section, stage, or group according to specialty. 1. Information about each section, stage, and group. 1. All: 1. Display name 1. Members (PM, EM, PDM, PMM, UXR, TW, QM, REM; BE, FE, SRE, SET) 1. Counterparts (Support, AppSec, SET; AR, Legal, CS) 1. Direction page 1. Slack channel 1. Analyst reports (link) 1. Competitor comparison (link) 1. Stages only 1. Section 1. Description 1. “Body”: longer description 1. Focus 1. Roadmap (link) 1. Established year 1. Lifecycle (number) 1. Driver scores: usage, revenue, SAM, ASP 1. Stage development spend percentage 1. Groups only 1. GitLab group 1. Internal customers (department) 1. Categories 1. Group Link (link to handbook heading or page) 1. Performance Indicator (link): GMAU, PGMAU ### Finance: `@JessSmith` Use case 1. Track team members by investment area, Stage and Group, including borrows. See [R&D Resource Investment Mapping Business Case](https://docs.google.com/document/d/1l-jK138c0yv1HNyMFKnwj6X4ybpXCPn-6MlxawazWs8/edit) Requirements 1. Reliable data which team members are in each product group in raw CSV/XLSX format or something that can be exported into Google sheets 1. Employee Name 1. Employee ID 1. Job Title 1. Manager 1. Division 1. Department 1. Subdepartment 1. Section 1. Stage 1. Group 1. Borrow Tag 1. Borrow Stage 1. Borrow Group 1. Frequent exports (monthly) or historical on-demand views/reports </details> ## Options 1. Status quo 2. Existing system with improvements 3. Build new system: likely require database-type system with outputting in YAML/JSON/CSV format ## Recommendation Based on the current requirements, priorities, and available resources, the recommendation is to keep the existing system with improvements: 1. add additional linting :white_check_mark: 2. make specialty a controlled value, allowing some automation > https://gitlab.com/gitlab-com/Finance-Division/finance/-/issues/6458 3. automate updates where possible > once above item is complete