The following people are permanent members of the Create:Code Review Group:
|Pedro Moreira da Silva||Staff Product Designer, Create:Code Review|
|André Luís||Frontend Engineering Manager, Create:Source Code, Create:Code Review, Delivery & Scalability|
|Tomislav Nikić||Software Engineer in Test, Create:Code Review|
|Patrick Bajao||Backend Engineer, Create:Code Review|
|Kerri Miller||Senior Backend Engineer, Create:Code Review|
|Tomas Vik||Senior Frontend Engineer, Create:Code Review|
|Kai Armstrong||Senior Product Manager, Create:Code Review|
|Justin Boyson||Senior Frontend Engineer, Create:Code Review|
|Thomas Randolph||Senior Frontend Engineer, Create:Code Review|
|Phil Hughes||Staff Frontend Engineer, Create:Code Review|
|David Sincheol Kim||Senior Backend Engineer, Create:Code Review|
|Amy Qualls||Senior Technical Writer, Create (Source Code, Code Review, Editor, Ecosystem), Growth (Activation, Adoption, Conversion, Expansion, Product Intelligence)|
|Gary Holtz||Backend Engineer, Create:Code Review|
|Marc Shaw||Senior Backend Engineer, Create:Code Review|
|Michael Henriksen||Senior Security Engineer, Application Security, Create:Code Review, Create:Editor, Create:Ecosystem|
The Code Review group is responsible for the following product categories:
In general, we use the standard GitLab engineering workflow. To get in touch with the Create:Code Review FE team, it's best to create an issue in the relevant project (typically GitLab) and add the
~"group::code review" label, along with any other appropriate labels (
~section::dev). 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_code_review on Slack.
The Code Review group believes it's important that team members are empowered to explore and experiment with areas of the product that interest them. Sometimes, the best way to get the conversation started is with a merge request.
In order to better provide opportunities for team members to pursue interest areas, engineers are encouraged to reserve about 10% of their scheduled capacity.
If you're choosing to work in these areas or explore new ideas, there's a few ground rules to make sure we're all on the same page:
It can be hard to figure out where to get started, so here's a handy list of places you might look for inspiration:
gitlab-orgissue list - filter this to issues with labels you're interested in
Whenever possible, we prefer to communicate asynchronously using issues, merge requests, and Slack. However, face-to-face meetings are useful to establish personal connection and to address items that would be more efficiently discussed synchronously such as blockers.
We record our meetings and upload them to the Create Code Review Playlist on GitLab Unfiltered.
This is a chance for all members of the Code Review Group to meet to discuss current priorities, blockers, planning, and discuss the middle of milestone check-in.
The agenda for this meeting is set in advance and anyone can contribute topics. If there are no items on the agenda 30 minutes before the meeting is scheduled to start, we cancel the meeting.
This meeting is focused on collaboration between UX and PM, though all are welcome to attend and contribute.
Weekly calls between the product manager and engineering managers (frontend and backend) are listed in the "Code Review Group" calendar. Everyone is welcome to join and these calls are used to discuss any roadblocks, concerns, status updates, deliverables, or other thoughts that impact the group. Every 2 weeks (in the middle of a release), a mid-milestone check-in occurs, to report on the current status of ~"Deliverable"s. Monthly calls occurs under the same calendar where the entire group is encouraged to join, in order to highlight accomplishments/improvements, discuss future iterations, review retrospective concerns and action items, and any other general items that impact the group.
You are encouraged to work as closely as needed with stable counterparts outside of the PM. We specifically include quality engineering and application security counterparts prior to a release kickoff and as-needed during code reviews or issue concerns.
Quality engineering is included in our workflow via the Quad Planning Process.
Application Security will be involved in our workflow at the same time that kickoff emails are sent to the team, so that they are able to review the upcoming milestone work, and notate any concerns or potential risks that we should be aware of.
Since we support such a large feature set, our team often reviews community contributions from the wider GitLab community. You're encouraged to give each contributor our version of "white glove treatment". Providing recognition for their donated time, giving exceedingly helpful reviews, and encouraging them in their contribution are all excellent ways to build a sense of community. If you don't have time to respond to a ping for a review or suggestion, please quickly let the person who pinged you know so they can ping someone else.
For tips, tricks, or quick shell scripts that aren't "ready" or sufficient enough to add to our developer documentation or handbook, we use the Create stage wiki.
Expanding on the concept of Middle of milestone check-in:
The way we try to grasp how well we are doing according to the scheduled and committed set of Deliverables is simply trying to calculate the level of completeness of all of them.
We do this by tallying up:
We then compile a small report like this:
Done + Verification: 1 w1 2.27% In review: 6 w15 34.09% In dev: 6 w20 45.45% Unstarted: 3 w8 18.18% Progress: 47.73% Conclusion: ...
Progress is calculated with:
100% * 2.27 + 80% * 34.09 + 40% * 45.45 + 0% * 18.18
In the conclusion we write an interpretation of what this means and what we'll be doing to correct course, if needed.
The easiest way for engineering managers, product managers, and other stakeholders to get a high-level overview of the status of all issues in the current milestone, or all issues assigned to specific person, is through the Development issue board, which has columns for each of the workflow labels described on Engineering Workflow handbook page under Updating Issues Throughout Development.
As owners of the issues assigned to them, engineers are expected to keep the workflow labels on their issues up to date, either by manually assigning the new label, or by dragging the issue from one column on the board to the next.
The goal is to support the members of these groups in connecting at a personal level, not to check in on people's progress or replace any existing processes to communicate status or ask for help, and the questions are written with that in mind:
Our team is encouraged to post links to their deliverable issues or merge requests when they are mentioned in relation to the second question. This helps other team members to understand what others are working on, and in the case that they come across something similar in the future, they have a good reference point.
We have 1 regularly scheduled "Per Milestone" retrospective, and can have ad-hoc "Per Feature" retrospectives more focused at analyzing a specific case, usually looking into the Iteration approach.
The Create:Code Review group 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.
If a particular issue, feature, or other sort of project turns into a particularly useful learning experience, we may hold a synchronous or asynchronous retrospective to learn from it. If you feel like something you're working on deserves a retrospective:
All feedback from the retrospective should ultimately end up in the issue for reference purposes.