The Fulfillment Frontend Team is responsible for the implementation and maintenance of the UI/UX experience for users who purchase or trial GitLab products and services. Our objective is to provide a simple, low barrier purchase and subscription management experience.
The following people are permanent members of the Front End Fulfillment:Purchase section:
|Ragnar Hardarson||Frontend Engineering Manager, Fulfillment:Purchase|
|Vitaly Slobodin||Senior Frontend Engineer, Fulfillment:Purchase|
|Ammar Alakkad||Frontend Engineer, Fulfillment:Purchase|
|Andrei Stoicescu||Frontend Engineer, Fulfillment:Purchase|
|Michael Lunøe||Senior Frontend Engineer, Fulfillment:Purchase|
|Angelo Gulina||Senior Frontend Engineer, Fulfillment:Purchase|
The following members of other functional teams are our stable counterparts:
|Amanda Rueda||Product Manager, Fulfillment:Utilization|
|Teresa Tison||Senior Product Manager, Fulfillment:License|
|Tatyana Golubeva||Principal Product Manager, Fulfillment:Purchase|
|Timothy Noah||Senior Product Designer, Fulfillment|
|Emily Sybrant||Product Designer, Fulfillment|
|Matthew Nearents||Senior Product Designer, Fulfillment|
|Suzanne Selhorn||Senior Technical Writer, Verify (Runner), Fulfillment|
|Rubén Dávila||Backend Engineer, Fulfillment:License|
|James Lopez||Backend Engineering Manager, Fulfillment:License|
|Mark Chao||Backend Engineer, Fulfillment:License|
|Dan Davison||Senior Software Engineer in Test, Fulfillment:License|
|Reuben Pereira||Backend Engineer, Fulfillment:Purchase|
|Ryan Cobb||Backend Engineer, Fulfillment:Purchase|
|Jason Goodman||Backend Engineer, Fulfillment:Utilization|
|Krasimir Angelov||Backend Engineer, Fulfillment:Utilization|
|Qingyu Zhao||Senior Backend Engineer, Fulfillment:Purchase|
|Tyler Amos||Senior Backend Engineer, Fulfillment:License|
|Etienne Baqué||Backend Engineer, Fulfillment:Utilization|
|Andrew Kelly||Senior Security Engineer, Application Security, Growth (Activation, Conversion, Expansion, Adoption), Fulfillment (Purchase, License, Utilization), Enablement (Distribution, Geo, Memory, Global Search, Database)|
|Chris Baus||Backend Engineering Manager, Fulfillment:Purchase|
|Amparo Luna||Backend Engineer, Fulfillment:License|
|Shreyas Agarwal||Senior Backend Engineer, Fulfillment:Purchase|
|Corinna Wiesner||Backend Engineer, Fulfillment:License|
|Josianne Hyson||Backend Engineer, Fulfillment:Purchase|
|Chase Southard||Backend Engineering Manager, Fulfillment:Utilization|
|Vincy Wilson||Quality Engineering Manager, Growth, Fulfillment & Protect|
|Vijay Hawoldar||Senior Backend Engineer, Fulfillment:Utilization|
|Vladlena Shumilo||Backend Engineer, Fulfillment:License|
|Chloe Liu||Senior Software Engineer in Test, Fulfillment:Purchase|
|Justin Farris||Group Manager, Product Management, Fulfillment|
Prior to the start of each milestone, the Product Manager prepares a planning issue which describes the objectives of the milestone. The Engineering Manager provides a weekly update on the team progress toward the milestone objectives. This should include the weight closed relative to the weight of the entire milestone. This update is added as a comment to the milestone planning issue prior to the weekly team meeting. In case the Engineering Manager is unavailable to provide the weekly update, an alternate team member will be assigned via the #s_fulfillment Slack channel.
The team meets once per week (see team calendar). This is the opportunity for the Fulfillment Frontend team to discuss topics related to our work. The objective of the meeting is to synchronously clarify any topics outstanding from the previous week or may affect our work in the upcoming week. This meeting also serves to fill-in context that maybe missing from purely written communication. Communicating highlights from this meeting to the greater team helps with any cross-team missing information.
All team members should feel free to contribute topics to the agenda.
Topics should include:
The Engineering Manager will assign issues to be weighted ahead of the weekly meeting. At the end of the meeting we will discuss any potential pitfalls and collectively assign a weight. We will use a weight system where 5 is roughly 2 engineer weeks of work. Issues with weight greater than 5 should be broken down into smaller issues.
When possible, larger issues should be broken into multiple MRs, and if not feature complete, merged behind a feature flag. Technical discussion should happen in the MR, while questions for the Product and Design teams should be addressed in the associated issue.
Frontend maintainers of the GitLab project can also merge Frontend MRs for the CustomersDot and LicenseDot projects.
For the CustomersDot MRs should be branched from and merged into the staging branch.
Engineers can find and open the milestone board for Fulfillment
and begin working first on those with the
It's possible for engineers to pick any of the remaining issues for the milestone once the deliverables are done. If the engineer has no preference, they can choose the next available issue from the top.
The following table will be used as a guideline for scheduling work within the milestone:
|Type||% of Milestone||Description|
|Deliverable||40%||business priorities (compliance, IACV, efficiency initiatives)|
|Bug||16%||non-critical bug fixes|
|Other||20%||engineer picks, critical security/data/availability/regression, urgent business priorities|
An issue will have at least 4 stages, and they should be moved accordingly using the Fulfillment workflow board
New features for the CustomersDot are released using unleash feature flags. The feature is first enabled on Staging by the engineer responsible for the merge request. The Product Manager and Designer are then assigned to the merge request for review. The label
workflow::verification should also be added the issue. After receiving approval from reviewers the engineer will set the feature live in production.
Complex features can be released using the percent rollout strategy at the discretion of Engineer, Engineering Manager, or Product Manager responsible for the issue. When using a percent rollout, the initial issue should be closed when the rollout begins, and a new issue should be created to track the progress of the rollout.
A follow-up issue must be created after features are released which will allow for removal of the feature flag and any code which is deprecated as a result of the new feature. This issue should be completed after feature is determined to be stable.