Post comments to status details pages from incident issues
Problem to solve
Status detail pages update automatically when an incident issue description is updated. This capability allows incident response teams to update a public-facing status page. However, this is cumbersome if it is the only mechanism to update external parties. Incident response teams need to either sift-through the description or scroll to the end in order to post incremental information.
Being able to use comments to publish information is an efficient and natural way for incident teams to work. Because they are already using comments to communicate with each other dure a fire-fire the experience of publishing status becomes a seamless part of the same workflow.
Not all information posted in an incident is helpful or desirable to publish make public. Incident teams need a way to choose between private comments that should only appear in the incident issue the team is working from and public comments that should be published to the status detail page.
Intended users
See #205164 (closed)
Further details
Proposal
- Comments in incident issues should have a method to mark the comment as public or private. While we hope to rely on the functionality being built as part of #2459 (closed), that won't be available until the end of 12.9 (at the earliest). For a first pass, comments with a specified emoji will be published to the site.
- Emoji suggestion: microphone
🎤 - Emoji can
appear either in the text or beadded to the comment after it's posted, depending on what's most feasible from an engineering POV. It seems likely that including the emoji within the comment's text will be the most straightforward option as we are already tracking changes to comments.
- Emoji suggestion: microphone
- User IDs for the individuals posting will be hidden
- Text comments should display for now; embedded images can be added as part of a later iteration
Out of scope
- Threaded comments
- Interactive chats
Design
Single comments shown as part of the incident detail page:
While we hope to rely on the functionality being built as part of #2459 (closed), that won't be available until the end of 12.9 (at the earliest). It's likely we will need to rely on some other behavior to mark comments as public/private for the first iteration. We discussed the possibility of perhaps utilizing an emoji for the first iteration, so any comments with a specific emoji would be published to the site. That's one possibility but, if there are better short-term options we can utilize, we can do so.
Permissions and Security
For the initial iteration, emoji will be used to publish comments. Anyone who has permission to add an emoji response to a comment should have the ability the publish that comment to the status.
developer
access should be required to publish comments to a status detail page.
Although guests
can add emoji reactions to comments in some cases, it's far more likely that users would not want guests
to publish comments than they would want guests
to publish comments. Upping the permissions to developer
conforms with the security principle of least privilege.
Documentation
Availability & Testing
A new end to end test will be introduced to cover the functionality of this feature, please follow up in E2E test for Status Page with Incidents
What does success look like, and how can we measure that?
Links / references
Full designs for the MVC and future iterations in Sketch cloud
User flow viewable in Mural