The following people are permanent members of the Create:Editor FE Team:
|Roman Kuba||Frontend Engineering Manager, Create:Knowledge & Create:Editor|
|Paul Slaughter||Senior Frontend Engineer, Create:Editor|
|Denys Mishunov||Senior Frontend Engineer, Create:Editor|
|Himanshu Kapoor||Senior Frontend Engineer, Create:Editor|
|Tomas Vik||Frontend Engineer, Create:Editor|
The following members of other functional teams are our stable counterparts:
|Kai Armstrong||Senior Product Manager, Create:Editor|
|Mike Nichols||Senior Product Designer, Create:Editor|
|Marcia Ramos||Senior Technical Writer, Create (Source Code, Knowledge, Static Site Editor, Editor)|
|Evan Read||Senior Technical Writer, Create (Gitaly, Gitter)|
|Francisco Javier López||Senior Backend Engineer, Create:Editor|
|Matt Nohr||Backend Engineering Manager, Create:Knowledge & Create:Editor|
|Darva Satcher||Senior Manager, Engineering, Create (Interim)|
|Anastasia McDonald||Software Engineer in Test, Create:Editor|
|Vijay Hawoldar||Senior Backend Engineer, Create:Editor|
|Marcel van Remmerden||Product Design Manager, Create|
|Katherine Okpara||UX Researcher, Create|
|James Ramsay||Group Manager, Product Management, Create|
Iteration is key to success for GitLab and every developer inside the company. In our team we try to work as iteratively as possible. Following the companys key metrics we aim for small and focused MRs.
Some examples of successful Iteration Work
The approach can be summarized like so:
GitLab.com is the source of truth. Everything that is not shipped and live is not done.
"Talent wins games, but teamwork and intelligence win championships." – Michael Jordan
Our team follows the general Product Development Flow but this guide is intended to elaborate on a few elements to represent the team internal flavor, emphasis certain points, and smooth the collaboration.
Let's look at a few of the workflow labels we should take as important cornerstones of our development workflow.
This is the point where EM’s join the efforts, unless requested earlier. For work that requires UI or UX changes it’s expected that they have gone through the design phase already. More details can be found on this handbook page.
Should a feature require
frontend work that issue will receive it’s weight based on relevant child issues that are created as part of the breakdown. The labels
backend-weight::x will help keep track of these.
If needed we will create a Technical Discovery issue for features that have a higher level of complexity. A Technical Discovery Issue should produce either an Epic, another Issue or feed back into the spawning Issue.
If the team determines that multiple issues must be created. An Epic should be created. All of the new issues created including the Technical Discovery issue, will be assigned to the Epic. The issues will be displayed on the Epic in order of priority. The issues will include dependencies so that the order the issues must be completed in is transparent. An Epic can be spread over multiple releases to support the GitLab Core Values around Iteration
Issue If only one issue is created, the Technical Discovery proved that a simple solution can be implemented. The traditional Product Workflow should be followed.
For an Issue to reach the scheduling phase it requires it weight to be set. It can be treated similar to the
workflow::ready for development state except it's in a holding pattern using the
%Backlog% milestone, until a proper milestone gets assigned.
workflow::ready for development
A feature that is ready for development should be able to be picked up at any point by an Engineer and should have a provisional milestone assigned. If such a feature requires BE and FE, the corresponding features should also be in this state.
Product will provide the directional items for upcoming milestones and the EM will make sure that these get prioritized accordingly. To account for enough resource planning time it's recommended to have
direction items ready ~10 days prior the next milestone. We need to account for engineers, who might be critical for scheduling the work, might be Out of Office (OOO) or live in the APAC zone.
Engineering will use the
~Deliverable label on any issue the team commits to during the milestone. Only features that reached the
ready for development phase can receive the
Issues that might be in the planning breakdown phase, but on track for a upcoming Milestone, migh receive the
~Discovery label to indicate that Engineering discovery needs to happen on it.
Should issues be added during the milestone (unexpected work), they will not receive the
As Engineer, plan accordingly and communicate if something changes.
The EM will provide a overview of committed work in the corresponding milestone planning issue and raise potential blockers. The initial focus will lie on resolving these blockers as fast as possible
What's expected from an engineer working in this department to support successful collaboration?
GitLab's asynchronous communication is great, but also requires some extra effort. As we collaborate not only with our department of frontend, but also backend, we should proactively communicate things like OOO. Share it in the appropriate group Slack channel to give others a heads-up. No one should be hit by surprise as sometimes work depends on the other person to be here.
Once the milestone has started, focus on a few things:
Every week engineers should drop their status updates on the planning issues. Here's an example For the 1:1 it's enough to reference that status update. You'll always find the latest planning issue linked in the teams frontend channel.
Why on the planning issue? This creates visibility to various stake holders, and allows for direct conversation. Another step for transparent communication.
If you are a frontend engineer and you are working on the Web IDE code, please consider the following questions:
filestate object? - Please visit Web IDE: Move properties away from the file object epic and see if you can move away some properties.
In the scenario where an Engineering Manager (EM) is unexpectedly out of the office we will immediately implement this backup plan to support a smooth and stable day-to-day work experience for all team members and stable counterparts. In case that the regular EM is not available, the stable counter part will jump in and support the team wherever possible.
Consider pinging the standing EM on important things and help proactivley to follow the usual processes around Weekly Catch Up Meetings, Sprint Planning, Retrospectives or other meetings.
1-1s will be run in an asynchronous manner, where a new Google Doc will be shared with focus on status and enablement.