We want intuitive interfaces both within the company and with the wider community. This makes it more efficient for everyone to contribute or to get a question answered. Therefore, the following interfaces are based on the product categories defined on this page:
Departments: Dev and Ops. Dev and Ops map to departments in our organization structure. At GitLab the Dev and Ops split is different then the infinity loop suggests because our CI/CD functionality is one codebase, so from verify on we consider it Ops so that the codebase falls under one department. The stages that are the difference between the value stages and the team stages are part of the Dev department.
Stages: Stages start with the 7 loop stages, then add Manage and Secure to give the 9 (DevOps) value stages, and then add Distribution, Geo, Gitaly & Gitter to get the 12 team stages. Values stages are what we all talk about in our marketing. Each of the team stages has a dedicated engineering team, product manager. Within shared functions like quality and product management individuals are paired to one or more stages so that there are stable counterparts.
Categories: High-level capabilities that may be a standalone product at another company. e.g. Portfolio Management. There are a maximum of 8 high-level capabilities per stage to ensure we can display this on our website and pitch deck. Or the internal customers of the stage who practice our collaborate value of dogfooding.
Features: Small, discrete functionalities. e.g. Issue weights. Some common features are listed within parentheses to facilitate finding responsible PMs by keyword. Features are maintained in features.yml.
Eventually, every category and capability listed on this page should link to a product marketing page, documentation, or an epic/issue.
Adding more layers to the hierarchy would give it more fidelity but would hurt usability in the following ways: