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.
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 |
| Nikola Milojevic | Senior Backend Engineer, Memory |
| Andreas Brandl | Staff Backend Engineer, Database |
| Matthias Käppler | Senior Backend Engineer, Memory |
| P.B. | Backend Engineer, Database |
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|
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.
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.
| 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.
