Operational ownership of webhooks and integrations
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
About
Webhooks and integrations feature categories have no group ownership. gitlab-com/Product#14184 is defining decentralised group ownership for these feature categories based on product relationships.
Problem
Maintaining an engineering responsibility to all the *abilities that Sabrina mentions is important. Webhooks and integrations are critical for customer workflows.
However, with only a decentralised model, these things fall into a gap:
- Error budgets for webhooks and integrations
- Escalation path for incidents
Within decentralised ownership models, we describe a role for a group that involves "building a solid foundation and great tools for testing and troubleshooting for other engineering teams". Which isn't appropriate in this case, as the categories have no product investment and so a team should not spend time investing in those things.
Instead, operational ownership (term credit: Bob gitlab-com/Product#14184 (comment 2556200789)) of webhooks and integrations would have fewer responsibilities, they would be entirely engineering in scope and not product based.
Proposal
Keep decentralised product ownership of webhooks and integrations as being formed in gitlab-com/Product#14184, add a new engineering "operational" ownership.
Ownership model
Virtual Team ownership - the last point suggests: model may fit a subject domain that’s in maintenance mode.
Alternative: Pick a team that has existing engineering knowledge rather than product relationships. TBH this doesn't exist for webhooks and integrations.
Operational ownership responsibilities
Operational ownership would have limited threshold of responsibility from a normal team, and entirely engineering in its scope:
Responsible for:
- Dev escalations. If the problem relates to a particular product area as defined in decentralised product ownerships, they are DRI to assist with finding devs from that product area to become the DRI. If the problem relates outside of clear product ownership boundaries, the engineer from the operational ownership group becomes the DRI.
- Bug/security problems above severity2 Again, similar DRI logic as above. Their responsibility may be finding the correct DRI.
- Error budget. The thresholds may need to be softened for this team - to be discussed
Not responsible for:
- Tech debt if it does not pose a real *ability risk.
- Any product features
- Building any foundations, tools
- Anything where a responsible team can be determined through the defined decentralised product ownerships
Next steps
- Allow separation of product and operational ownership in YAML data gitlab-com/Product#14184 (comment 2556200789)
- Form a virtual team for these product categories. Could have handbook page that describes responsibilities, with listings of decentralised group ownerships to make escalating to product DRIS easier.
- Ensure error budget can work with this virtual team (might need some definition within some YAML)
- Consider whether error budget thresholds should be softened for this team