The following people are permanent members of the Create:Knowledge FE Team:
|Roman Kuba||Frontend Engineering Manager, Create:Knowledge & Create:Editor|
|Natalia Tepluhina||Senior Frontend Engineer, Create:Knowledge|
|Tom Quirk||Frontend Engineer, Create:Knowledge|
The following members of other functional teams are our stable counterparts:
|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|
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
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:
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.