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.
|Douwe Maan||Engineering Manager, Create|
|Tiago Botelho||Backend Engineer, 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|
|L.D.||Backend Engineer, Create|
|E.P.B.||Backend Engineer, Create|
|L.D.||Backend Engineer, Create|
|André Luís||Frontend Engineering Manager, Create & Plan|
|Sam Bigelow||Frontend Engineer, Create|
|Phil Hughes||Senior Frontend Engineer, Create|
|Paul Slaughter||Frontend Engineer, Create|
|Jeethu Karthik||UX Designer, Create|
|James Ramsay||Product Manager, Create, Gitaly, Gitter|
|Mark Lapierre||Senior Test Automation Engineer, Create|
|Natalia Tepluhina||Senior Frontend Engineer, Create|
|Hendrik Meyer||Site Reliability Engineer, Create|
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.
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 is compiled by the Product Manager following the product prioritization process, with input from the Backend and Frontend Engineering Managers and other stakeholders.
Issues labeled P1 and P2 are considered top priority and are expected to be done by the feature freeze on the 7th so that they can make it into the intended release. The total weight of these issues is limited to the expected total weight the team will be able to complete, based on historical performance and developer availability. In the future, we may start using throughput to determine a reasonable amount of work instead.
These top priority issues will be assigned to developers 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. There are many things that can happen during a month that may result in a P1 or P2 deliverable not being done by the 7th, but this should never come as a surprise, and the sooner this potential outcome is anticipated and communicated, the more time there is to see if anything can be done to prevent that outcome, like reducing the scope or finding a different developer who may have more time to finish the issue.
Generally, your assigned P1 and P2 issues are expected to take up about 75% of the 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).
If you have time to spare after finishing your top priority issues and other activities, you can spend the remaining time working on P3 and P4 issues.
P3 and P4 issues are usually not directly assigned to people, except in cases where a specific developer is the obvious most appropriate person to work on it, if it's technical debt or a bug related to a feature they built very recently, for example. These issues are not expected to be done by the feature freeze but will become P1 and P2 issues in the next release, so any work done on them ahead of time is a bonus.
Instead of working on P3 and P4 issues, 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.