How to Get Help

Workflow for Support Engineers on how to get help when working on a ticket.

Getting Help on a Ticket

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.

How to Get Help Workflow

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:

  • I don’t have the right knowledge to progress this ticket.
  • The customer’s query is out of scope, but they expect us to resolve this.
  • There is a deep technical issue which needs a development expert’s consult.

Then consider these options to help unblock you. And remember that escalating to unblock is an operating principle of Results.

Bring the ticket before a group of peers

Other Support Engineers are a great resource to help out with tickets. To get help from peers, you can try one or more of the following:

  1. Attend crush or help sessions such as those noted below (see the GitLab Support calendar for times):
    • AMER Senior SE Help Sessions
    • APAC/AMER or EMEA/AMER crush sessions
    • APAC or EMEA crush / collaboration sessions
    • Senior Support Office Hours (varying times)
  2. Ask for help in one of the broader Support Slack channels.

Expand to Support Pods and other subject matter experts

You can also do one or more of the following:

  1. See if there is a Support Pod that covers the area your ticket is in and ask one of the Pod members for help.
  2. Ask an expert within Support. You can check the Skills by Subject Support page to see who might have the skills to assist, or reach out to the Support Stable Counterpart for the appropriate product area. Mention those people in the thread and in the ticket to let them know you think they can help.
  3. Request help from the relevant GitLab Development Team. Gather what information you have and fill in as much detail as possible for the dev team in the issue. To get more attention, you can post in the relevant group Slack channel with a message and link to the issue. If you don’t get a response within the SLO, contact the listed engineering manager in the project readme. See below for more details. If you have a reproducible issue, then go straight to a bug issue in the appropriate GitLab product tracker.

Bring the ticket to managers

Especially if you feel you’re stalled on a ticket and need assistance identifying next steps:

  1. Always feel free to reach out to any available manager (such as your manager, or the Support Manager On-call in the #support_leadership channel. They will help you to determine next steps.
    • Avoid messages with no identified DRI for responding in #support_leadership as they can be missed or be a victim to the bystander effect.
  2. Open a STAR in situations where getting help is urgent and important because:
    • the customer has expressed unhappiness with the service we’re delivering via the ticket
    • the support engineer has noticed a correlation between several of a customers tickets that could use a more cohesive response
    • there is an urgent need for action in a different region (for example, finding a ticket owner or scheduling a call)

How to formally Request Help from the GitLab Development Team

To enhance collaboration between the support and development teams, GitLab has implemented the Request for Help (RFH) process. This allows support engineers to formally request assistance from the specific GitLab development groups responsible for the relevant functionality when facing technical challenges that impede ticket resolution. This section outlines the necessary steps to effectively utilize the RFH process.

It’s important to note that this process is part of a broader, iterative strategy aimed at deploying this workflow across all development sections and groups at GitLab. If an RFH template for a particular development group is not yet available, please reach out to John Lyttle to initiate the creation of the required RFH template.

Are you requesting for Dev help too soon?

NO! To drive this point home, here’s what one of our Developers Chad Woolley had to say about this:

If both Support and the Customer are confused about what the next steps are, at a minimum it’s an indicator that something is lacking, either in our docs or support processes, and this is an opportunity to improve those areas.

How to find the correct Development Section and Group to reach out for help

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:

  1. Locate a documentation page for the feature or topic on which you need help.
  2. Scroll down to the bottom of the page and click on either the “View page source” link.
  3. This will open up the .md source file of that docs page, which contains both the stage and group responsible for it noted on the top.
  4. Now go to the Product Categories handbook page and search for the Development Section to which the group identified on the previous step belongs to.
  5. Use the table and workflow below to create a Request for Help issue in the project identified above.

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

The Request For Help Landing Page

The Request for Help landing page consolidates all GitLab Development Sections and their respective groups into a single repository. Unlike the previous process, all RFH templates are now centralized within this repository for easier access and management. To submit an issue, navigate to the page, locate the relevant GitLab Group, and click on its “Associated Template.”

Change Process: If a section or group has been recently modified, please create a confidential issue in the GitLab project tracker, assign to @jlyttle and notify the relevant Slack channel. For additional details, refer to the support epic #222 for more information.

Research prior to opening an issue

Use the following repositories and resources for identifying similar issues or requests:

  1. Zendesk for related tickets.
  2. Previous GitLab Application bugs and feature requests.
  3. Previously submitted GitLab.com issues.
  4. Previously submitted Request for Help issues.
  5. Discuss with knowledge experts and support stable counterparts.

Create a detailed issue

  1. Open the Request for Help landing page.
  2. Review the Development groups and corresponding templates section.
    • Use the provided GitLab Handbook Section Breakdown link at the bottom of the Project ReadMe file if you are unsure about which Section Sub Group and corresponding template to use.
  3. Make sure to use the correct corresponding issue template when creating a new issue.
  4. Complete all the fields in the issue template and attach all necessary files.
  5. Ensure that an appropriate severity is set as defined by the support impact. You should set the approriate label severity::1, severity::2, severity::3, severity::4 so that it corresponds with the priority level in Zendesk.
  6. If the Zendesk ticket is escalated then add the label Support::escalated.
  7. Add a ‘Customer Impact’ statement if necessary, advocating for the customer.
  8. Ensure to follow any instructions on the template itself, such as who to assign the issue to (if not automatically assigned).
  9. Ensure that a link to the corresponding issue is added to the Zendesk ticket as an internal note and also to the ticket field named GitLab Issues.

Tips on getting timely responses

  1. Review the Opening a request for help to ensure all steps were covered.
  2. Mention the engineer who is helping or assigned with every comment where you need them to review or respond.
  3. If an issue is moved to another group (through a label change or moving to another project), check the corresponding template for the new group to see who to assign or mention in a comment.
  4. When linking to Kibana, also upload a copy of relevant entries, a screenshot of the graph, etc. as logs rotate out after 7 days. If possible, also link to the relevant Sentry entry.
  5. Many teams do not have access to customer information. So make sure if you are accessing information using elevated access (Such as GitLab.com Admin) that you provide information in the issue directly that may be required to understand the problem.

Escalate to unblock a request

If you encounter any problems, such as obtaining a timely response from Development, then please take one or more of the following steps:

  1. Check if the engineer(s) assisting with the request is on PTO through Slack or their GitLab status. If they are on PTO, mention the contacts (listed in the issue template) in the issue, or their backups if they are also on PTO, requesting an update via the issue. Backups are listed in a coverage issue, or in Slack.
  2. Make the corresponding Development group Engineering Manager aware by mentioning them in the issue. You can identify the relevant Engineering Manager by checking the Development Group Handbook Page from each Projects Readme Section which provides a section named Development Groups with their corresponding templates and labels.
  3. Feel empowered to ping the contacts and/or Engineering Manager in the corresponding product/development group Slack channel along with a link to the issue, requesting an update.
  4. Reach out to a Support Engineering Manager for further guidance directly or in the #support_leadership Slack channel.

Closing: Document and knowledge share

  1. Once you receive all the necessary assistance, ensure to close the issue and add a comment explaining why it is being closed.
  2. Consider whether the solution or information contained within the issue can be used to update the GitLab documentation.
    1. If you have updated the GitLab documentation, add the label documentation::created and link the merge request.
    2. Otherwise, add the label documentation::candidate, and create a GitLab issue to update the relevant documentation.

General Troubleshooting Resources

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:

Last modified December 13, 2024: Update the how-to-get-help handbook page to reflect the move from multiple repositories into a single Repository (0f0f14f7)
View page source - Edit this page - please contribute. Creative Commons License