Note: Jeremy recently conducted an on-boxing exercise that suggested a number of updates to the visuals for the on-call schedule page. We can also update the visuals as part of this batch of changes.
@abellucci - I've added the two epics we discussed to this UX Theme issue. While the main designs for scheduled overrides are done, they don't yet include Jeremy's update to the visual display of on-call schedules. I'm assuming we'd want to go ahead and make those changes to the visual display as we're adding overrides? If so, I'd need to go through and update the designs accordingly.
Lastly, For the Improve usability of on-call schedules can we call out the specific issues? This will help me identify what's ready for engineering when I do planning. It looks like there is a lot of work in this section and I want to make sure we can quickly see what's included in this work directly on this issue.
Yes! Let's implement Jeremy's update while we're doing Scheduled Overrides.
Great!
I noticed in the issue under Next Steps it says we only have one data point for this request. Is it worth doing a problem validation at this time?
Yeah, I'm not sure, @abellucci. I'd say probably not, to be honest. Since that's a UX Scorecard issue though, I think there is a SLA associated with completing it. I think we could do two things here: 1) I could try out combining schedules and policies on a single page, and then I can test it to see if people prefer the version where everything is on one page, or if they prefer keeping it separate. Or, 2) we can close that issue, for now, and we can perhaps re-open in future if we get similar feedback from a customer or stakeholder. WDYT?
Yeah, sure! Have added it to the issue description, but should we move that issue to the main GitLab project? I notice it's in the Respond project currently.
Lastly, For the Improve usability of on-call schedules can we call out the specific issues?
Okay, sure. Have added each issue individually
Let me know on the remaining items and we can get this one finished up
Amelia Bauerlychanged title from Improve on-call schedule experience to Ensure on-call schedule experience is accurate and flexible enough to fit incident response teams' needs
changed title from Improve on-call schedule experience to Ensure on-call schedule experience is accurate and flexible enough to fit incident response teams' needs
Amelia Bauerlychanged the descriptionCompare with previous version
During setup I was a bit surprised to see gitlab#259239 (closed) was not possible. For info or low severity alerts I want a very different escalation policy compared to 24/7 critical alerts that need to wake someone up if things are on fire.
Hey @vermeeren, thanks so much for reaching out – so excited you're giving on-call schedules a try
I definitely agree that that would be an important improvement; I've gone ahead and added that issue to the design theme specifically about improving the escalation policy experience, since the other improvements we're hoping to make to escalation policies are gathered there: #1905 (closed)
The team has pivoted a bit to work on service desk currently, so I'm not sure when they're likely to loop back around to escalation policy work. But, having feedback like yours helps us to prioritize that work so, thanks so much for letting us know that that improvement is important to you!
I'm actually really happy with the recent service desk improvements, have been slowly starting to use it past months for direct customer interaction and it's doing really nicely. When I first evaluated it in 2020 there were quite some serious issues with losing data (stripping mails permanently), attachment handling, lack of customisation (for company/customer specifically), etc.
Fast forward to today there is of course still some edge cases and improvements in progress (following that quite closely) but overall so much better to the point when I feel confident in using it for real together with some custom rules and rewriting in our postfix mail server for some last touches.
Definitely feel free to stay on service desk a little longer and get that last polish out before revisiting incident handling. :p
Was exploring on-call software and was curious if GitLab are still investing in building these Incident Response capabilities? From what I can see all of the epics associated were last updated almost a year ago and there are no updates to the direction doc below?
Hello @stevebryen, thanks for reaching out! @msaleiko is looking after these features now. He's currently focusing on service desk but perhaps he has more of an idea of when there might be space to loop back around to incident management. Marc, thoughts?
But I'm always happy to help with small improvements and community contributions. For example, we're currently adding iterations to incidents. So I'm trying to help wherever I can, but TBH I don't have the capacity to push features forward.
Does the current state of on-call schedules work for your use-case? If not what's the gap? Have a great day
Right now we were exploring our options for managing on-call capabilities and given we are Ultimate users were seeing if GitLab could be an option. I think the biggest gap would be the maturity around the paging capabilities today from our initial look.
I think the biggest gap would be the maturity around the paging capabilities today from our initial look.
Totally understand
@stevebryen - out of curiosity's sake - guessing you're meaning proper text paging, vs just email/UI/Slack notifications?
I'm currently working on notifications. For now that's just focusing on email/UI notifications but if there are opportunities to expand notification channels in future, I will make sure and highlight this thread/conversation to see if there's anything we can do to help support this use case
Closing this issue for now as we're not currently actively working on incident management features. We can re-open this issue, if/when we pick these features back up.