Assign Product group DRIs for remaining integrations and decide on ownership of Webhooks category
Results
Webhooks are maintained by Import group, you can see it here: https://handbook.gitlab.com/handbook/product/categories/lookup/.
Integrations have group DRIs assigned, you can review the ownership of integrations in the handbook.
Summary
This issue proposes assigning Product group DRIs for integrations that are currently labelled as belonging to the Import and Integrate group. It also poses questions about ownership of foundational aspects of integrations and Webhooks category.
With the recent re-org, the Integrate part has be downscaled, leaving those integrations and Webhooks category without a clear ownership.
Following the success of the previous initiative Integrations group DRIs (gitlab-org/gitlab#438682 - closed), we seek to complete the transition of integration ownership to product teams within their respective domain areas.
Motivation
GitLab leadership "have determined that a better strategy is to federate out the work of Integrate” (point 7 in doc). Therefore we need to find "home" for integrations left without a responsible group.
As previously established in issue #438682 this also supports the goal to:
- Give product groups full visibility and ownership in serving customers in their domains
- Enable comprehensive strategies for integrations within each domain
Proposal
Based on the analysis of remaining integrations without dedicated Product group DRIs, we propose the following assignments. We have added a confirmation column for each group to explicitly indicate their acceptance of DRI responsibilities for the assigned integrations.
External Issue Trackers
| Integration | Proposed DRI Group | Rationale | Confirmation |
|---|---|---|---|
| Asana | Plan:Project Management | Aligns with project management tooling | |
| Bugzilla | Plan:Project Management | Issue tracking functionality | |
| ClickUp | Plan:Project Management | Project management integration | |
| Custom issue tracker | Plan:Project Management | Generic issue tracking framework | |
| EWM - IBM Engineering Workflow Management | Plan:Project Management | Enterprise project management integration | |
| Jira issue integration | Plan:Project Management | Core issue tracking integration | |
| GitLab for Jira Cloud app | Plan:Project Management | Extension of Jira integration | |
| Pivotal Tracker | Plan:Project Management | Agile project management integration | |
| Redmine | Plan:Project Management | Issue tracking and project management | |
| YouTrack | Plan:Project Management | Issue tracking integration |
Notification Integrations
Based on the conversation below, chat integrations should live within Category:Notifications. The ownership of this category is currently being discussed.
| Integration | Proposed DRI Group | Rationale | Confirmation |
|---|---|---|---|
| Slack Notifications (deprecated) | Team communication with incident management capabilities | ||
| Discord | Team communication and alerting notifications | ||
| Google Chat | Enterprise team communication and incident alerting | ||
| Irker | IRC-based communication for alerts and notifications | ||
| Mattermost notifications | Team communication platform with incident management features | ||
| Microsoft Teams | Enterprise team communication with operational alerting | ||
| Pumble | Team communication platform for notifications | ||
| Unify Circuit | Team communication platform for operational alerts | ||
| Webex Teams | Enterprise team communication with incident response features | ||
| Telegram | Mobile-focused team communication for alerting |
Other Integrations
| Integration | Proposed DRI Group | Rationale | Confirmation |
|---|---|---|---|
| Slack slash commands | Run slash commands from a Slack workspace to operate on GitLab data, e.g. create project, issue. | ||
| GitLab for Slack app | groupproject management | Combination of Slack slash commands integration, and Slack notifications integrations, with additional incident management flows | #14184 (comment 2727865972) |
| Mattermost slash commands | Run slash commands from a Mattermost environment to operate on GitLab data, e.g. create project, issue | ||
| Trello PowerUp | Plan:Project Management | Board-based project management | |
| Pipeline status emails | Verify:Pipeline Execution | CI/CD pipeline notification | |
| Emails on push | Create:Source Code | Source code event notification | |
| Gmail Actions Buttons | Email integration with operational response capabilities | ||
| Mock CI | Verify:Pipeline Execution | Testing CI integration | |
| Squash TM | Verify:Pipeline Testing | Test management integration |
DRI Group Responsibilities
As established in the previous issue (#438682), product groups designated as DRIs will be responsible for:
- Deciding if new community-contributed integrations should be added to GitLab codebase based on their domain strategy
- Determining if existing integrations should remain in GitLab codebase according to domain strategy
- Following proper process for deprecating and removing integrations when needed
- Maintaining integration documentation
- Re-assigning and triaging integration-related issues to determine prioritization
- Remediating bugs and security vulnerabilities within target SLOs
- Addressing infradev issues and responding to urgent requests
- Responding to Requests for Help and iterating on the integration
Product groups may also designate certain integrations as Community-supported for improvements and additional features at their discretion.
Who should maintain the foundations of integrations?
As with the recent re-org, the Integrate part has be downscaled, it's unclear who/which group should:
- Maintain ownership of integration foundations
- Provide guidance on integration best practices and review related MRs
- Maintain the Integration development guidelines
- Work on foundational improvements that benefit all integrations
Webhooks Category ownership
The reorganization has left the Webhooks Category without clear ownership. However, individual webhook events (triggers and payloads) remain owned by the teams responsible for their related features.
Rather than creating a comprehensive mapping of which team owns which webhook event — which would quickly become outdated — we'll rely on feature ownership to determine webhook ownership organically.
The key question: Should any team own the foundational webhook infrastructure?
Currently, our webhook development guide provides engineering teams with self-service guidance for webhook implementation. This may be sufficient for maintaining the foundational aspects without dedicated ownership.
Next Steps
- Product groups review their proposed DRI assignments
- Provide feedback or confirm acceptance of DRI responsibility in the
Confirmationcolumn - For notification integrations and other integrations with empty DRI assignments, discuss which group should take ownership
- Update documentation metadata for each integration to reflect new ownership
- Transfer issues to appropriate groups
- Find a good SSOT for integration ownership, that could be shared with a wider team - Support, CSM etc. as the Integration ownership table will be removed with this direction page removal.
- Decide if and who should maintain the foundations of integrations.
- Decide if and who should own the Webhooks category.