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 seamless license purchase and management experience with Gitlab.com.
The following people are permanent members of the Front End Fulfillment Group:
The following members of other functional teams are our stable counterparts:
|Rubén Dávila||Backend Engineer, Fulfillment|
|James Lopez||Backend Engineering Manager, Fulfillment|
|Vitaly Slobodin||Senior Frontend Engineer, Fulfillment|
|Mark Chao||Backend Engineer, Fulfillment|
|Amparo Luna||Backend Engineer, Fulfillment|
|Kirstie Cook||Backend Engineer, Fulfillment|
|Chris Baus||Engineering Manager, Fulfillment|
|Corinna Wiesner||Backend Engineer, Fulfillment|
|Tyler Amos||Senior Backend Engineer, Fulfillment|
|Shreyas Agarwal||Senior Backend Engineer, Fulfillment|
|Ragnar Hardarson||Senior Frontend Engineer, Fulfillment|
|Ammar Alakkad||Frontend Engineer, Fulfillment|
|Chloe Liu||Senior Software Engineer in Test, Fulfillment|
|Vladlena Shumilo||Backend Engineer, Fulfillment|
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. Technical discussion should happen in the MR, while questions for the Product and Design teams should be addressed in the associated issue.
We follow the standard MR and Code Review process with a few exceptions. Since the Fulfillment Frontend Team is relatively new, we don't have a maintainer for the Customer portal or the License app on the team. For the reason, and to increase diversity of reviewers, Frontend maintainers of the GitLab CE and GitLab EE projects should merge Frontend MRs for the Customer portal and Licence app projects.
For the Customer portal 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 Customers Portal 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.