Reassign support tickets for any PTO

Why is this change being made?

Issues encountered

1. I was doing #support_response-crew recently. During my day, I came across 3 tickets that were soon to breach and had assignees that were on PTO.
2. Currently, Support Team Member Time Off page states the following as a general guideline:

As per the working with tickets workflow, aim to update a customer daily. If your PTO will prevent a timely update, ask the customer whether they would prefer to pause the ticket till your return or have someone else step in to work with them. If they want to pause, put the ticket on-hold. Otherwise, find a new assignee.

However, after few paragraphs we have a title If your absence will be three or more business days and then we are talking about reassigning tickets. I see a discrepancy here (no guidelines for 1 or 2 days absence).

3. In the current workflow, we say to simply "unassign" tickets if they cannot find anyone to work on them. I think that, in general, this gives room for not giving our best for those tickets we took on as we can unassign them and forget about them.

Summary of changes

1. Reassign tickets even if you will be out for 1 day.

• If a ticket needs attention, it makes no difference to the team whether the person is out for 1 day or 1 month. Action is needed and work needs to be done, so we also need to find someone do that work for us.
• We already say, as a general guideline, to reassign all of the tickets we are not sure about what will happen to them. This MR moves the steps we already have for "3 or more days PTO" to steps for "any PTO".
• Reassigning tickets should be part of our regular activities and we shouldn't think of it as a significant event. In order for that to be the case, we need to reduce friction of reassignment as much as we can. And in order to do that, we need to practice, learn by doing it.

2. Don't unassign tickets as a last resort, assign to a manager instead.

• It is not expected of a manager to work on the actual ticket. They are there as a catch-all phrase and the idea is for them to find new assignees.
• Managers will be more exposed to the reassignment process and will be aware of any potential improvements needed (e.g. if they start getting too many tickets - they will understand that it's not easy to reassign the ticket right now).
• Managers will be exposed to the way their reports work and communicate with the team (e.g. some ICs might benefit from more help in general than others when it comes to "asking others to take on their work").

Author Checklist

• Provided a concise title for the MR
• Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
• Assign this change to the correct DRI
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the "Maintained by" section in on the page being edited.
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies.
  • If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping @gl-static-site-editor in a comment for a review and merge. For example changes to .gitlab-ci.yml, JavaScript/CSS/Ruby code or the layout files. (this requirement has been removed pending identification of a new DRI for the handbook)