Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Memory Team

On this page

Vision

Build and enhance a highly performant GitLab product portfolio, and establish best practices for performance oriented development.

Mission

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.

Team Members

The following people are permanent members of the Memory Team:

Person Role
Craig Gomes Engineering Manager, Memory
Kamil TrzciƄski Distinguished Engineer, Ops and Enablement
Qingyu Zhao Senior Backend Engineer, Memory
Aleksei Lipniagov Senior Backend Engineer, Memory

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Person Role

Meetings

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.

Work

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.

Planning

(WIP) The Memory Team uses the Memory by Milestone board to plan issues for each milestone.

We are adopting a lightweight weighting system, similar to those adopted by other teams.

Since we are a small team, each member is expected to comment on issue weight. Asking each member to estimate the weight will give the team a better understanding of the goals of the milestone, encourage communication around the issues, and lead to clarifying questions. If anyone feels they do not have enough information to comfortably apply a weight, they are encouraged to comment on the issues asking for more details. After feeback on issue weight has been gathered, the Engineering Manager is responsible to ensure that all issues within the milestone have a weight assigned.

Weights

Weight Description
1: Trivial The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.

Examples are documentation updates, simple regressions, and other bugs that have already been investigated and discussed and can be fixed with a few lines of code, or technical debt that we know exactly how to address, but just haven't found time for yet.
2: Small The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution. Few surprises are expected, if any, and no coordination with other teams or people is required.

Examples are simple features, like a new API endpoint to expose existing data or functionality, or regular bugs or performance issues where some investigation has already taken place.
3: Medium Features that are well understood and relatively straightforward. A solution will be outlined, and most edge cases will be considered, but some extra investigation will be required to realize the solution. Some surprises are expected, and coordination with other teams or people may be required.

Bugs that are relatively poorly understood and may not yet have a suggested solution. Significant investigation will definitely be required, but the expectation is that once the problem is found, a solution should be relatively straightforward.

Examples are regular features, potentially with a backend and frontend component, or most bugs or performance issues.
5: Large Features that are well understood, but known to be hard. A solution will be outlined, and major edge cases will be considered, but extra investigation will definitely be required to realize the solution. Many surprises are expected, and coordination with other teams or people is likely required.

Bugs that are very poorly understood, and will not have a suggested solution. Significant investigation will be required, and once the problem is found, a solution may not be straightforward.

Examples are large features with a backend and frontend component, or bugs or performance issues that have seen some initial investigation but have not yet been reproduced or otherwise "figured out".

Anything larger than 5 should be broken down.

Boards