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

Create:Knowledge FE Team

The Create:Knowledge FE team is responsible for all frontend aspects of the product categories that fall under the Knowledge of the Create stage of the DevOps lifecycle.

Team Members

The following people are permanent members of the Create:Knowledge FE Team:

Person Role
Roman Kuba Frontend Engineering Manager, Create:Knowledge & Create:Editor
Natalia Tepluhina Senior Frontend Engineer, Create:Knowledge
Tom Quirk Frontend Engineer, Create:Knowledge

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Person Role
Achilleas Pipinellis Senior Technical Writer, Create, Package, Monitor, Secure, Defend
Marcia Ramos Senior Technical Writer, Create, Release
Katherine Okpara UX Researcher, Create
James Ramsay Group Manager, Product, Create
Luke Duncalfe Backend Engineer, Create:Knowledge
Markus Koller Backend Engineer, Create:Knowledge
Tomislav Nikić Software Engineer in Test, Create:Knowledge
Matthew Nearents Senior Product Designer, Create:Knowledge
Christen Dybenko Senior Product Manager, Create:Knowledge
Darva Satcher Engineering Manager, Create:Knowledge & Create:Editor
Alex Kalderimis Senior Backend Engineer, Create:Knowledge

Collaboration

PM - EM

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.

Workflow labels

Let's look at a few of the workflow labels we should take as important cornerstones of our development workflow.

workflow::planning breakdown

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 backend and frontend work that issue will receive it’s weight based on relevant child issues that are created as part of the breakdown. The labels frontend-weight::x and 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.

Epic

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.

workflow::scheduling

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.

Directional, Deliverable and Discovery

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 scheduling or ready for development phase can receive the ~Deliverable label. 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 ~Deliverable label.

After the Kickoff

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

Engineering

What's expected from an engineer working in this department to support successful collaboration?

Communication

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.

Start of the Milestone

Once the milestone has started, focus on a few things:

Backup

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.

What can Engineers do to help

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.

What happens to 1-1s

1-1s will be run in an asynchronous manner, where a new Google Doc will be shared with focus on status and enablement.