Incident Design - MVC
Build upon the existing workflow that organizations may use when tracking incidents with GitLab, using Issues. An example organization of this type is GitLab itself. Here is a typical incident for GitLab.com: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/3838 (internal only)
I propose we can make this experience better by focusing on a few core items:
Embed operations data directly in the issue
Allow users to embed errors and metrics directly into an incident/issue. These would then show up inline within the issue, with real data and interactions. This would save users from having to take screenshots or jump between tabs.
- Link/embed metrics into issues: https://gitlab.com/gitlab-org/gitlab-ce/issues/30423
- Link/embed charts into issues: https://gitlab.com/gitlab-org/gitlab-ce/issues/55619
In the future, we could have an incident specific dashboard where this information can be display side-by-side, but that can be a later iteration.
SSOT for key Incident information
We should make it extremely easy to understand a few key pieces of information: what the status of the incident is, and where communication is happening while working the incident.
For the MVC - we can take a similar approach as above, for specific services:
- Google doc
- Video call (Zoom, etc.)
- Chat channel (Slack, etc.)
We could detect these types of links and "unfurl" or embed them much like Slack or other services do, directly in the issue. This would make them more easily recognizable, and later on we could integrate and even show whether a call was active or not.
This way we can postpone/avoid "Issue Type" or other major architectural work, as we continue to iterate and gather feedback.
Embedding as a primitive
In essence the above boils down to building a system where we can embed a variety of different types of content, to enrich the Issues/Comments experience.
This could also be extended to other features as well, like viewers for various file types.