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 the 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 our Devs have to say about this:

[…] it’s almost never too soon and every dev I’ve talked to about it has nothing but mountains of respect for support folks […]

– James Nutt

I always love it when anyone from the support team reaches out to me. It’s not a bother at all; in fact, it has given me a lot of great ideas before.I actually wrote an article about how working with our support team helped get good outcomes for customers at a previous company

– Lesley Razzaghian

Most are happy to help anytime. My only suggestion is to search docs first. That’s really helpful for devs because we might link you to docs anyway. But then it’s also helpful to know “the docs didn’t address my question”. Or they did but not clearly enough. These conversations give all involved a basis for improving docs once the question is answered.

– Drew Blessing

[…] If you stumble through and figure it out, and never tell us that you (or the customer) struggled, we don’t get the feedback that we need to do better (which in many cases includes prioritizing doing better). And most of us want to do better.

Personally I wish Support would escalate to devs much sooner than they do on average. If that means that we get inundated with support requests that make it hard to focus on other work, then that’s a sign that we need to deprioritize other features to focus on UX and docs (which are also features).

– David Nelson

I’m never annoyed by support friends reaching out. It’s you + me vs the problem after all! Devs love a puzzle, so I’m always keen.[…]

– Charlie Ablett

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.

– Chad Woolley

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

Note: Some sections are not yet available. If a section is not listed, consider a confidential issue in the GitLab project tracker and post in the relevant Slack channel. Please follow support epic #222 for more information.

Development Section Section Product Breakdown Link to the GitLab RFH Project Corresponding Issue Board
Ops (CI, CD) Section Ops Section Breakdown Section Ops Request for Help Section Ops Issue Board
Dev Section Dev Section Breakdown Section Dev Request for Help Section Dev Issue Board
Sec Section Sec Section Breakdown Section Sec Request for Help Section Sec Issue Board
Core Section Core Section Breakdown Section Core Request for Help Section Core Issue Board
Fulfilment Section Fulfilment Section Breakdown Section Fulfilment Request for Help Section Fulfilment Issue Board
SaaS Platforms Section SaaS Platforms Section Breakdown SaaS Platforms Request for Help Section SaaS Platforms Issue Board
GitLab Dedicated GitLab Dedicated Breakdown GitLab Dedicated Request for Help GitLab Dedicated Issue Board

Please note: GitLab Dedicated is the first iteration for implementing a Request For Help Section for the SaaS section of GitLab development, therefore at the moment the GitLab project structure and workflows may not be consistent with the other development sections in the above table. You can find out more information on GitLab Dedicated internal processes by visiting the Dedicated Team’s ReadMe.

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 logged GitLab.com issues.
  4. Discuss with knowledge experts and support stable counterparts.
  5. Search for previously opened issues in the relevant Development Section Project on GitLab.com.

Create a detailed issue

  1. Open the corresponding Development Section Project as defined in the above table.
  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 November 1, 2024: Remove trailing spaces (6f6d0996)
View page source - Edit this page - please contribute. Creative Commons License