# Problem Statement Currently, GitLab support does not have a formal and scalable workflow process for requesting assistance from the various back end development teams. ## What is the problem? At present, if a support engineer has exhausted all avenues of investigation within the support team and they require further assistance they typically reach out to the back-end development teams via the various Slack channels. ## Why is this a problem? The above approach raises the following issues and concerns:
 * This is an informal and untracked pathway for an engineer to elevate an issue. * It provides no consistency in the content or structure of requests that are made to the back end development teams * The current voluntary basis by which a member of the slack channel (support or development) provides help, introduces the risk of requests being left with either a slow response or no response. * As we continue to grow, the slack channels become increasingly noisy and this impacts the ability to scale the current approach * A lot of useful debugging information resides in slack which is then deleted after 90 days meaning that valuable reusable information is lost * It is not possible to track the amount of assistance that development is affording to support * It is not possible to track via GitLab which are potentially the problematic areas of product ## Proposal To address these problems I propose that we provide support engineers with a documented pathway to elevate tickets or any support-related requests that they are unable to progress, this approach is not intended to completely replace slack communication in the channels but to offer a more formal elevation process when the need arises. The proposal requires support senior management to liaise with e-group and/or senior development management to get buy-in so we can begin the process of creating a new workflow that enables support engineers to elevate issues to development if they are unable to progress the issue and/or if there is ambiguity regarding if the issue is a defect or feature request. The new workflow could then be broken down into the following iterations: 1. Create a new GitLab project or use existing developer maintained projects to enable support engineers to request assistance from development 2. Create templates to assist support engineers to ensure that support has performed the necessary due diligence (gather the necessary logs, have exhausted doc troubleshooting suggestions) prior to creating an issue. 3. Add the appropriate labels to the templates for reporting and tracking 4. Work with the support ops team so issues can be linked to tickets in Zendesk and vice versa. 5. Create and document a workflow so that engineers are aware of the rules of engagement and how to follow the process. Please note: I previously raised a suggestion to dog food and use GitLab to track these requests in [issue 3507](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3507) a number of months ago but it never got off the ground, however since then and as noted below the "Geo“ development team have implemented a similar proposal so I believe the proposal is worth revisiting. ## GEO Team Project 1. The “Geo” development team have recently put a very similar process in place for support engineers that require development assistance. This could be viewed as a potential pilot project, and is documented in the handbook: [How to ask for support from Geo](https://about.gitlab.com/handbook/engineering/development/enablement/geo/#how-to-ask-for-support-from-geo). 2. They have created an [issue template](https://gitlab.com/gitlab-com/geo-customers/-/blob/master/.gitlab/issue_templates/Support%20Request.md) and encouraged support engineers to log requests for assistance via this project. 3. The following [issue](https://gitlab.com/gitlab-com/geo-customers/-/issues/57) is an example of support and development collaboration ## DRI @jlyttle @lbot # Potential Roadblocks/Things to consider * We do not get buy-in from some of the development teams * Such a significant new workflow approach would require bedding in time by both support and development * Further iterations of this proposal would likely be required. # Desired Outcome 1. There will be a clear pathway for engineers to obtain assistance for challenging tickets, this should reduce stress and increase collaboration between support engineers and developers. 2. We will have central searchable issue repositories where valuable debugging information will be stored. 3. If development help is required then we will have clear SLO's, ensuring that support engineers get help in a timely fashion and tickets are progressed quicker. 4. This is a scalable solution for GitLab as a growing business 5. It offers a reportable solution # Competition / Alternative solutions: * Continue to use the informal slack approach * Use a third-party issue tracking tool * Investigate if Zendesk can be used to elevate tickets to development