When working on tickets, collaboration is critical, especially when troubleshooting complex issues, or technical areas of focus that fall outside of your experience level. Asking for help means having a low level of shame, and also shows that you are putting the customer first because you are working towards resolving their problem.
If you are stuck on a ticket, the following workflow seeks to help Support Engineers realize and utilize all of the resources available to progress a ticket to resolution. This workflow lists some common resources, you can lean on to get the help you need.
If you’re stuck on a ticket…..
Identify what's causing you to get stuck. Some examples are:
Then consider these options to help unblock you. And remember that escalating to unblock is an operating principle of Results.
Ask in your group's Slack channel for help. You might get all the help you need in responses right there, or you might open up the group's Zoom room for an impromptu pairing session to work on the ticket. And remember:
#spt_managerschannel. They will help you to determine next steps.
#spt_managersas they can be missed or be a victim to the bystander effect.
2022-06-13 the Support Team and the Development Team are rolling out a series of projects that will enable support engineers to request help from a GitLab Development group, for more information on this please review the associated proposal. The aim is to provide a formal and accountable workflow process for Support Engineers to request assistance from the various Development Sections for any technical issues which they are currently unable to progress. Please note that this is an iterative process, which aims to roll out the process for each of the 10 development sections at GitLab. If the Development Section that you require assistance from is not listed in the table below then please continue to use the existing methods for contacting the relevant Development Teams, such as Slack.
The easiest way to determine the correct place for a Support Request for Help issue is to use the docs pages. One possible workflow is as follows:
.mdsource file of that docs page, which contains both the
groupresponsible for it noted on the top.
Alternatively, if you have set up the Support dotfiles, you can use the
gls_request_for_help command to quickly retrieve the "New issue" link with the correct issue template.
NOTE: A video recording of a similar workflow as the one described above can be found in the Support Training repository
|Development Section||Section Product and Group Breakdown||Link to the GitLab Project for requesting help|
|Ops Section||Ops Section Breakdown||Section Ops Request for Help|
|Dev Section||Dev Section Breakdown||Section Dev Request for Help|
|Sec Section||Sec Section Breakdown||Section Sec Request for Help|
|Enablement Section||Enablement Section Breakdown||Section Enablement Request for Help|
|Fulfilment Section||Fulfilment Section Breakdown||Section Fulfilment Request for Help|
The steps for submitting a help request are as follows:
ReadMe(displayed on the project page):
Support Engineer User Guidancesection and follow the steps outlined.
Development groups and their corresponding templatessection and use the Handbook links provided if you are unsure as to which Section Sub Group and corresponding template you should use.
Development Groups with their corresponding templates and labels
documentation::candidateso that the issue can be identifiable for future use. If you have actually updated the GitLab documentation then please add a link to the MR to the issue and add the label
Every problem is a little bit different. Sometimes it makes sense to try a different troubleshooting technique. These resources talk about general purpose approaches to troubleshooting: