Custom Models Group
Vision
The Custom Models group focuses on additional, custom models that power GitLab Duo functionality in support of our customers unique data and use-cases.
Organisation
The AI-powered:Custom Models team focuses on GitLab’s suite of Custom Model features and is responsible for all backend aspects of the product categories that fall under the Custom Models group of the AI Powered stage of the DevOps lifecycle. Our Product direction is found on the Category Direction - Custom Models Management page.
The features we work with are listed on the Features by Group Page.
Team OKRs
If you’re interested in the team’s Objectives and Key Results (OKRs), you can find them on GitLab.
Team Members
Engineering Manager & Engineers
Engineering Manager: @sean_carroll
| Name | Role |
|---|---|
 Sean Carroll
|
Senior Engineering Manager, AI-Powered:Custom Models |
 Igor Drozdov
|
Staff Backend Engineer, Create:Source Code, Systems:Gitaly API |
 Patrick Cyiza
|
Backend Engineer, Create:Source Code |
Product, Design & Quality
Product Manager: @susie.bee
| Name | Role |
|---|
How to reach us
- Issue Tracker:
~group::custom models - Slack Channel: #g_custom_models
- Label Subscription:
~group::custom models
Organisational Labels
Issues owned by the Custom Models group should have these labels, as appropriate:
~"group::custom models"~"devops::ai-powered"~"section::dev"~"category::model personalization"~"category::self-hosted model deployment"
In addition, issues should contain the relevant ~type: and subtype labels.
Team Milestone Planning Process
Custom Models follows the Product Development Flow and uses a planning issue and boards to manage the planning process. Planning issues for each milestone are created by the PM and are used to coordinate upcoming work between the PM, EM and stable counterparts.
In the last week of a milestone, planning is completed for the next milestone. The following activities are undertaken.
- Creation of planning issues and boards (EM)
- Identification of candidate issues for the milestone and addition to Planning Board (PM, EM, SET)
- Team member capacity planning (EM)
- Estimation of effort using weights (Engineers and EM)
- Joint planning session to finialise the planning board (PM, EM, SET)
- Assignment of work to engineers, addition of the
~Deliverablelabel, update to the planning issue (EM)
Planning Issue
Each month a planning issue is created by the EM, using the Custom Models Planning Issue. This is the discussion area for the planning team members (PM, EM, and Software Engineer in Test (SET)) for a specific milestone and links to the Planning and Build Boards.
Planning Board
The Planning Board is created for each milestone by the PM, and is a curated list of issues by category. The EM requests engineers to allocate weights to all issues on this board prior to milestone planning.
Ready for Development Status
Issues that are ready to be worked on by an engineer are labelled workflow::ready for development. Only issues with this label should be assigned to an engineer as a Deliverable. If research is required, the ~spike label is assigned, but the scope of the spike should be clearly stated in the issue and an outcome might be code written or a refined issue created.
Capacity Planning Spreadsheet
The EM maintains a Google Sheet GitLab internal only for calculating team capacity, and the same Spreadsheet is also used to perform the process of assigning issues to the release based on weight and priority. The EM posts the team capacity on the Planning Issue.
Build Board
The EM selects issues from the Planning Board based on:
- previous milestone slippage
- PM preference
- weight
- priority
The EM then applies the ~Deliverable label to each issue in the Release and assigns then to an engineer. The issues are tracked through the release via the Build Board.
Issue Weights
A weight is assigned to each issue as an estimation of work to close the issue. A weight of 1 is approximately 2 working days of effort. Generally issues are not weighted above a weight of 3: larger weights indicate the issue should be broken down further.
Planning and Delivery Boards
All workflow statuses in the Product Development Flow are valid, and the statuses and milestones tied to boards are below.
The Next 1-3 and Next 4-6 milestones boards are used to house issues which need refinement or are ready to be worked on.
| Board | Filters | Columns |
|---|---|---|
| Planning Board | Milestone, ~group::custom models, ~planning priority |
~type::bug, ~type::maintenance, ~type::feature |
| Build Board | Milestone, ~group::custom models, ~Deliverable |
~workflow::ready for development, ~workflow::in dev, ~workflow::in review, ~workflow::awaiting security release, ~workflow::blocked |
| Next 1-3 Milestones | %Next 1-3 Milestones |
~workflow::problem validation, ~workflow::problem validation, ~workflow::design, ~workflow::solution validation, ~workflow::planning breakdown, ~workflow::ready for development |
| Next 4-6 Milestones | %Next 4-6 Milestones |
Same as Next 1-3 Milestones |
Issue Milestones
- Issues are assigned the current or next milestone if they are planned to be worked on or are currently being worked on.
- A milestone of
%Backlogis assigned if issues are not intended to be worked on, although they may be addressed by a community contribution. - Issues with a milestone of
%Awaiting Customer Feedbackmay be worked on, pending customer interest.
The issue triage report highlights issues which need a milestone assignment.
Shared calendars
TBD
Communication
The Custom Models communicates based on the following guidelines:
- Always prefer async communication over sync meetings.
- Don’t shy away from arranging a sync call when async is proving inefficient, however endevour record it to share with team members.
- Transparency by Default
- The primary channel for work-related communication is the #g_custom_models Slack channel.
- Internal team issues and projects are namespaced under
gitlab-org/ai-powered/custom-models
Asking for help
Don’t hesitate to ask for help from other team members via the #g_custom_models Slack channel.
Acknowledgement of Pings
If you are pinged by name in either Slack or GitLab, please acknowledge the ping by either:
- A threaded comment
- An emoji
Time Off
Team members should add any Paid Time Off in the “Time Off by Deel” slack app, so that the Engineering Manager can use the proper number of days off during capacity planning. Where possible, try to add time off a full milestone in advance.
It is recognised there can always be last-minute, unplanned PTO needs. Please take any time you need, but enter it into PTO Deel and communicate with the EM as soon as you can.
Ad-hoc sync calls
We operate using async communication by default. There are times when a sync discussion can be beneficial and we encourage team members to schedule sync calls with the required team members as needed.
