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:
| Person | Role |
|---|---|
| Angelo Gulina | Senior Frontend Engineer, Fulfillment:Purchase |
| Vamsi Vempati | Senior Frontend Engineer, Fulfillment:Purchase |
The following people are permanent members of the Front End Fulfillment:License section:
| Person | Role |
|---|
The following people are permanent members of the Front End Fulfillment:Utilization section:
| Person | Role |
|---|---|
| Ammar Alakkad | Senior Frontend Engineer, Fulfillment:Utilization |
| Kos Palchyk | Senior Frontend Engineer, Fulfillment:Utilization |
| Sheldon Led | Senior Frontend Engineer, Fulfillment:Utilization |
The following members of other functional teams are our stable counterparts:
| Project | Engineer leading project | Target |
|---|---|---|
| Community Programs Self-Checkout | @agulina | |
| Move CI minutes purchase flow into GitLab.com | @agulina |
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 project.
For the CustomersDot MRs should be branched from and merged into the staging branch.
Engineers can find and open the milestone board for Fulfillment which is ordered by priority.
We're currently evaluating how work is scheduled for the Purchase Frontend team.
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.
