Define and communicate SLA for user requests

[balajialg]

Summary: Given the extensive data collected over the past few years while creating new hubs, installing new packages, data archival requests or increasing the RAM size, It would be an ideal time to start thinking about defining SLA for such repeatable requests.

User Story

• As a Datahub user, I will be able to know the expected response time from the Datahub team if my requests are related to the installation of a new hub (or) a new package (or) increase/decrease in the RAM size of my hub

Acceptance Criteria Every request related to these three types of requests will get responded to with a response time as defined by SLA.

Tasks to complete

• [x] Review ds-infrastructure list, GitHub issues, and slack channels to identify a reasonable time frame for responding to such requests
• [x] Get the team's buy-in for the defined SLA
• [x] Update documentation

[balajialg]

I went through the previous issues to get a sense of the time it takes for us to respond to repetitive requests from our users! I considered the average time it took to honor such requests and the maximum time to honor a specific request. Let me know if this is something we can define as SLA going forward?

1. SLA for package installation: Within three working days
2. SLA for admin access: Within two working days
3. SLA for data archival request: Within three working days??
4. SLA for RAM increase (if the team validates the raised request): Within three working days

@felder @yuvipanda

[felder]

@balajialg these seem reasonable to me assuming the SLA provides for tricky requests. Sometimes package requests aren't always quite what they seem to be.

[balajialg]

Fair enough! What do you prefer? ​Keep the time limit the same but add a statement that this timeframe is under the assumption that,

1. Users have tested it in their datahub instances and package installation didn't cause any issues
2. Have provided complete information on the package/version dependencies.

Does that make sense?

[felder]

@balajialg I think the way to go might be to add a support response time to the SLA such as "all requests will be acknowledged within some number of working days." Then we can perhaps specify estimated times to service various requests without making firm commitments.

Ideally with a well oiled support process, there will be piazza and/or github issues where customers can track the progress.

[balajialg]

Makes sense! I am comfortable adding that - "all requests will be acknowledged within three working days" for at least package requests as part of our SLA!

[yuvipanda]

Package requests and RAM requests can require a bunch of extra work, so let's set SLAs for those to be 'acknowledge'. 2 days maybe?

Admin access and data archival should be more straightforward though, as all information required should be acquired from the user during an initial form. Perhaps for those, we can set SLAs for completion?

[yuvipanda]

For admin access, for example, we can design a form that requests the following information:

1. Name of Hub
2. List of usernames
3. End date (defaults to end of current semester)

We will somehow then need to determine that the requestor is authorized to provide us this list of usernames. If we can do all this, then we can have a SLA that we can actually meet. So I guess the SLA should be determined by the process, and can't be set independently.

[balajialg]

Great points @yuvipanda!

Editing SLA's based on your inputs: SLA for package installation: "Acknowledgement within two working days." SLA for RAM increase: "Acknowledgement within two working days." SLA for admin access: "Request completed within two working days." SLA for data archival request: "Request completed within three working days."

For admin access, I will create a new template today. In addition to the points highlighted for the admin access form, I will add more entries for, i) Name of the person making this request ii) Course name iii) Role as part of the teaching team

I guess this information will give me enough inputs to co-ordinate with the course staff (if required to validate their request further)

[yuvipanda]

yep - and for all of these, the time should start from when we have complete information needed to perform the action.

[balajialg]

@yuvipanda Makes sense!