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

Create Team

On this page

Create Team

The Create team is responsible for all backend aspects of the Create stage of the DevOps lifecycle, which is all about creating code, and includes all functionality around source code management, code review (merge requests), the Web IDE, wikis, and snippets.

For more details about the vision for this area of the product, please see the Create stage page and the 2019 product vision blog post.

Team members

Person Role
Douwe Maan Engineering Manager, Create
Nick Thomas Staff Backend Engineer, Create
Oswaldo Ferreira Backend Engineer, Create
Bob Van Landuyt Backend Engineer, Create
Francisco Javier López Senior Backend Engineer, Create
Mark Chao Backend Engineer, Create
Luke Duncalfe Backend Engineer, Create
Patrick Bajao Backend Engineer, Create
Igor Drozdov Backend Engineer, Create

Stable counterparts

Person Role
André Luís Frontend Engineering Manager, Create
Sam Bigelow Frontend Engineer, Create
Phil Hughes Senior Frontend Engineer, Create
Paul Slaughter Frontend Engineer, Create
Pedro Moreira da Silva Senior UX Designer, Create
M.V. UX Designer, Create
James Ramsay Product Manager, Create, Gitter, Gitaly
Andreas Kämmerle Product Manager, Create
Mark Lapierre Senior Test Automation Engineer, Create
Amarbayar Amarsanaa Senior Site Reliability Engineer, Create, Plan, Monitor
Natalia Tepluhina Senior Frontend Engineer, Create
Tomislav Nikić Test Automation Engineer, Create
Denys Mishunov Senior Frontend Engineer, Create
Michal Wasilewski Site Reliability Engineer, Create & Plan


In general, we use the standard GitLab engineering workflow. To get in touch with the Create team, it's best to create an issue in the relevant project (typically GitLab CE) and add the ~Create label, along with any other appropriate labels. Then, feel free to ping the relevant Product Manager and/or Engineering Manager as listed above.

For more urgent items, feel free to use #g_create on Slack.

What to work on

The primary source for things to work on is the Create issue board for the current release (don't forget to filter by milestone!), which lists all of the issues scheduled for this release, in priority order: the deliverables. The backend and frontend lists are compiled by the Product Manager following the product prioritization process, with input from the team, engineering managers, and other stakeholders.

By design, we schedule more deliverables for each release than we can reasonably expect the team to deliver in that period. The expectation is that the top 70% of deliverables on each list on the board will be done by the [feature freeze] and will make it into the release they were scheduled for, while the next 30% will end up being moved to the next release, now with increased priority.

To ensure that the amount of scheduled work is reasonable considering these criteria, engineering managers estimate the weights of all issues the Product Manager puts forth for scheduling and limit the final scheduled set based on the issues' combined weight, historical team results, and the amount of time each engineer will be available to work on deliverables during this period.

What to work on first

The top 70% of deliverables are assigned to engineers on or ahead of the 8th of the month, and it is their responsibility to make a best effort to get them done by the feature freeze, and to inform their engineering manager if anything is standing in the way of their success.

You can find the issues assigned to you on the Create backend assignment issue board, which shows the same deliverables, now categorized by assignee, with the left-most list listing issues not currently assigned to any backend engineer. On each list, the issues are still ordered by priority.

Many things can happen during a month that can result in an assigned deliverable not actually making it into the intended release, and while this usually indicates that the engineering manager was too optimistic in their estimation of the issue's weight, or that an engineer's other responsibilities ended up taking up more time than expected, this should never come as a surprise to the engineering manager.

The sooner this potential outcome is anticipated and communicated, the more time there is to see if anything can be done to prevent it, like reducing the scope of the deliverable, or finding a different engineer who may have more time to finish a deliverable that hasn't been started yet. If this outcome cannot be averted and the deliverable ends up missing the release, it will simply be moved to the next release to be finished up, and the engineer and engineering manager will have a chance to retrospect and learn from what happened.

Generally, your assigned deliverables are expected to take up about 75% of the time you spend working in a month. The other 25% is set aside for other responsibilities (code review, community merge request coaching, helping people out in Slack, participating in discussions in issues, etc), as well as urgent issues that come up during the month and need someone working on them immediately (regressions, security issues, customer issues, etc).

What to work on next

If you have time to spare after finishing your top priority deliverables and other activities, you can spend the remaining time working on the lower priority deliverables you can find in the left-most list of the Create backend assignment issue board (again, don't forget to filter by milestone!).

Deliverables in the lower 30% of priority are usually not directly assigned to people, except in cases where there is clearly a most appropriate person to work on them, like in the case of technical debt, bugs related to work they did recently, or issues they started on before but haven't had a chance to finish yet. As mentioned above, these deliverables are not expected to be done by the feature freeze but to be moved to the next release, so any progress made on them ahead of time is a bonus.

As with the other lists on the assignment board, the issues in this list are ordered by priority, and should be picked up starting at the top. When you assign an issue to yourself to indicate you're working on it, it will move to your list and out of the left-most unassigned list, and the second issue will rise to the top for other engineers to pick up. If anything is blocking you from getting started with the top issue immediately, like unanswered questions or unclear requirements, you can skip it and consider a lower priority issue, as long as you put your findings and questions in the issue, so that the next engineer who comes around may find it in a better state.

Instead of picking up unassigned deliverables, you may also choose to spend any spare time working on anything else that you believe will have a significant positive impact on the product or the company in general. As the general guidelines state, "we recognize that inspiration is perishable, so if you’re enthusiastic about something that generates great results in relatively little time feel free to work on that."

We expect people to be managers of one and prefer responsibility over rigidity, so there's no need to ask for permission if you decide to work on something that's not on the issue board, but please keep your other responsibilities in mind, and make sure that there is an issue, you are assigned to it, and consider sharing it in #g_create.


The Create team conducts monthly retrospectives in GitLab issues. These include the backend team, plus any people from frontend, UX, and PM who have worked with that team during the release being retrospected.

These are confidential during the initial discussion, then made public in time for each month's GitLab retrospective. For more information, see team retrospectives.