Update service objectives page #143
Conversation
|
@choldgraf Thanks for sharpening the service objectives. I wonder whether quantifying support response time for outages could be reassuring for partners. IMHO, response time within 24 business hours can be challenging for mission-critical tasks like responding to outages (24 business hours ~ 3 working days?). Should support response time vary dynamically for such occurrences? My 2 cents - It will be a valuable support practice to segment tickets based on the priority of the issue (like you already do) and allocate a faster response time (say 8 business hours) for mission-critical tasks. I know there are practical constraints at your end for making such assurances. I do think such assurances in the future would be valuable for community representatives and support folks. Or you could tie this to your pricing model. Curious to hear your thoughts! |
|
That's a good idea - I think this matches our team goals as well, will update the PR here |
|
I've made a few updates to these documents per @balajialg and others' suggestions, let me know what y'all think! |
about/service-objectives.md
Outdated
| Our goal is to be more rapid in responding, communicating, and resolving support requests during incidents. | ||
| Our ability to meet these objectives will depend on the times they are reported relative to the working hours of our support team. | ||
|
|
||
| - We will triage and respond to Incidents within 8 working hours. |
There was a problem hiding this comment.
We should say something here about how this is an upper bound but we generally try to respond before that.
Co-authored-by: Yuvi Panda <[email protected]>
| (objectives:intentional-downtime)= | ||
| ### Intentional downtime | ||
|
|
||
| In some cases there may be intentional downtime for the infrastructure that we run. | ||
| For example, if we need to undergo major maintenance of infrastructure transitions. | ||
|
|
||
| - We will communicate with communities before any intentional downtime. | ||
| - We will aim for downtime windows that happen outside of heavy usage. | ||
| - We will communicate with communities when the expected downtime is over. |
There was a problem hiding this comment.
I would add a "To be refined" admonition to this section too as we haven't yet defined how this communication and scheduling would happen, e.g., 2i2c-org/team-compass#423
Co-authored-by: Chris Holdgraf <[email protected]>
Co-authored-by: Sarah Gibson <[email protected]>
There was a problem hiding this comment.
I think this is good to merge once https://github.com/2i2c-org/docs/pull/143/files#r884550187 is addressed.
|
Thanks for the feedback and suggestions all, I've taken another pass and I think have addressed everybody's concerns above! I tried to clarify "a working day" and also softened the language around response times that we promise. |
This provides some updates about our service objectives page to sharpen the language and make it easier to glance through. It is inspired in part from some recent conversations we had with @colliand, @balajialg, @ericvd-ucb, and the DataHub team.
Would love any feedback or thoughts on how this could be improved or made more clear.
I've also opened an update to our team support processes here, and would love feedback: 2i2c-org/team-compass#422