Time tracking allows teams to plan, track, and evaluate (after the fact) time spent by individuals and teams on work. It is an important category since in the world of digital work (where GitLab is a tool for), an organization's ultimate resource is ultimately people hours.
GitLab has basic time tracking functionality (estimation and actuals) for issues and merge requests. This forms the baseline layer of project management functionality relevant to time tracking. There are several possible directions for time tracking.
Our next steps is to consider quick wins such the first two items above, before tackling more ambitious goals in time tracking (third bullet point).
Time tracking is a critical set of features in project management and more broadly, portfolio management. So the main competitors here are similar to those categories. It is Jira, Asana, Notion, and Monday.
GitLab will win by not just having similar time tracking capabilities (which is not very differentiated on its own), but by taking those time tracking capabilities (and generated data), and plugging them into the larger project management feature set used by teams.
The relevant analyst landscape here is the broader category of Project Management, so the same remarks from that category applies here as well.
Improving the API of time tracking will allow customers to better manipulate time tracking data and allow customers to further customize their needs of time tracking. See issue. Customers can already export time tracking data via issue CSV files.
Users want additional customization with time tracking, since different teams evaluate and use time units slightly differently.
Users also want more integration with other parts of GitLab, including integration with issue boards.