Build and enhance a highly performant GitLab product portfolio, and establish best practices for performance oriented development.
The Memory team is responsible for optimizing GitLab application performance by managing the memory resources required. The team is also responsible for changes affecting the responsiveness of the application. We will accomplish these goals in two ways. First we will research and resolve reported memory issues to the best of our ability and within our published SLAs. Additionally, will build tooling to proactively inform developers of the static and dynamic memory consumption of their proposed changes. You can read more about our approach, in detail, here.
The following people are permanent members of the Memory Team:
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Yannis Roussos | Senior Product Manager, Database and Memory |
| Suzanne Selhorn | Staff Technical Writer, Verify (Runner), Configure, Enablement (Memory, Global Search, Sharding) |
Where we can we follow the GitLab values and communicate asynchronously. However, there have a few important recurring meetings. Please reach out to the #g_memory Slack channel if you'd like to be invited.
We follow the GitLab engineering workflow guidelines. To bring an issue to our attention please create an issue in the relevant project, or in the Memory team project. Add the ~"group::memory" label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the Stable Counterparts section above.
When planning for a milestone, the Memory Team creates a planning issue to discuss the upcoming milestone asynchronously. We outline the major efforts planned for the milestone along with who is working on each effort. Often there are individual issues that are either operational in nature, or don't belong to an epic. These issues are also called out in the planning issue for prioritization.
We have three main boards for tracking our work (listed below).
Memory by Milestone The Milestone board gives us a "big picture" view of issues planned in each milestone.
Memory: Build
The build board gives you an overview of the current state of work for group::memory. These issues have already gone through validation and are on the Product Development Build Track. Issues are added to this board by adding the memory::active and group::memory labels. Issues in the workflow::ready for development column are ordered in priority order (top down). Team members use this column to select the next item to work on.
Memory: Validation The validation board is a queue for incoming issues for the Product Manager to review. A common scenario for the Memory Team validation board is when an issue is created that requires further definition before it can be prioritized. The issue typically states a big picture idea but is not yet detailed enough to take action. The Memory Team will then go through a refinement process to break down the issue into actionable steps, create exit criteria and prioritize against ongoing efforts. If an issue becomes too large, it will be promoted to an epic and small sub-issues will be created.
We use the ~Deliverable label to track our Say/Do ratio. At the beginning of each milestone, during a Memory Team Weekly meeting, we review the issues and determine those issues we are confident we can deliver within the milestone. The issue will be marked with the ~Deliverable label. At the end of the milestone the successfully completed issues with the ~Deliverable label are tracked in two places. We have a dashboard in Sisense that will calculate how many were delivered within the mileston and account for issues that were moved. Additionally, our milestone retro issue lists all of the ~Deliverable issues shipped along with those that missed the milesone.
The Memory Team Roadmap gives a view of what is currently in flight as well as projects that have been prioritized for the next 3+ months.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
