Looking for technical support? Please visit the Support Page instead.
The overall direction for Support in 2016 is set by our operations strategy, and in order to meet our strategic objective, the following topics are being addressed by the team: (also see the related direction issue)
By hiring more service engineers, adding Support Turbos when needed, and making sure that the newly hired service engineers have training materials and pathway readily available and defined when they join. We'll also aim to do a better job acknowledging and incentivizing the rest of the community in their role of supporting the community at large through contributions to documentation and participation in social channels.
By gathering all our support channels in a central location, Zendesk, we'll be able to tag tickets with relevant keywords, and gather data on channel load, agent load, and topic trends. Likewise, through implementation of Swiftype on the documentation server, we'll get a better handle on what people are looking for and/or not finding.
By making training materials for customer trainings available on GitLab University, making documentation easy to find and easy to search, and constantly contributing to further documentation with the trend discovery showing where the need is greatest, we can help the community become as self sufficient as possible and empower users to problem-solve. A seamless interface between the support team and developers closes the feedback loop of user experience back to development, and provides 'network' support for the Service Engineers for tough issues.
Improve Customer Experience
By triaging support effort through internal SLA's, the team can improve the support experience for key customers while still addressing the questions of all subscribers, and the rest of the GitLab community.
The channels are sorted in order of priority, there are 4 SLA categories:
|2||Regular Tickets and Security||1 business day|
|3||Disqus and Twitter||1 business day|
|4||Posted Issues & Other||Two weeks but not sooner than two days|
Response time indicates the first reply time.
Preferably we like to answer tickets sooner than the SLA requires. The higher a channel is in the list the sooner it should be answered.
Service Engineers can work on any ticket they feel they can contribute to. However, tickets should be picked up in the following order to make sure that SLA's are not breached, and customers receive the proper level of service:
When a ticket is breaching or has breached its first reply (or next reply) SLA this ticket must be picked up by any Service Engineer independently of who is assigned to it (although see the note re: courtesy in the list above). This also applies to tickets for Premium Customers (i.e. anyone picks up if close to breaching, regardless of who the Dedicated Service Engineer is).
Every now and then, it may occur that we come close to breaching our SLA's. To prevent an actual breach from occurring, the Support team can call on the help of several 'Support Turbo' developers who are called out on the Team Page. The support team calls for help when necessary via Slack, but in case of doubt or conflicting priorities, the Backend Lead needs to give the green light for the support turbo developers to momentarily switch away from their other tasks.
SLA's are set as Business Rules within Zendesk. For more information, please refer to the specific Zendesk page.
The Zendesk Insight dashboard lists the activity for all our channels currently and summarized over the last 30 days (login to Zendesk required).
We can't fit more than 13 views in the dashboard panel. We have 6 views that are not channels. Meaning we have 7 views left for all our channels. That is why some channels are combined.
Certain subscribers have purchased Premium Support (TODO: create /support page), which gives them access to a Dedicated Service Engineer. This means that tickets that arrive in Zendesk from people within the subscriber's organization are routed to a dedicated SE by way of a trigger in Zendesk.
We have a Responsible Disclosure Policy. Emails sent to firstname.lastname@example.org go into Zendesk and receive an autoresponder that says: "Thank you for your responsible disclosure of a potential GitLab vulnerability. We'll follow up with you within one business day." We also accept reports via HackerOne, see more information on this channel.
Please be very patient with these reports. Do not say 'there is no problem', you might be misunderstanding something that can lead to a 0 day disclosure. Give examples and keep asking questions until you understand the problem or until the researcher concludes there is no problem. If someone invested time to help us, offer to mention them on our Security Researcher Acknowledgments page even if there was no actual vulnerability. If you say that we'll get back to them always mention that they can email us at any time for an update. This is really important to prevent a 0 day disclosure resulting from us forgetting to respond.
If you need help from developers to diagnose the issue please open an issue on dev.gitlab.org so we can work in private. If someone opens a public issue please leave a message: "Thank you for helping to make GitLab more secure! We removed the contents of your vulnerability disclosure to keep it private. We opened an internal issue to look at your disclosure. Can you please use our Responsible Disclosure Policy to send us an email that references this url so we can communicate in private?"
The key used to encode/decode PGP messages is stored in our Support Vault on 1Password. We only provide our public PGP key upon request because it makes collaborating much harder and only a small percentage of all disclosures are serious enough to require that overhead.
See PGP Process for information about using the security PGP key pair and decrypting messages.
Fellow GitLab team members can reach out for help from the Support Team in various ways:
The Support project hosts an issue tracker meant to improve our workflow by reporting any problems that may arise on our tools or processes. Its also meant to propose and discuss ideas in general.
The issue tracker is open to the community and part of the GitLab.com group. It should not contain any sensitive information. Links to Zendesk or other references are encouraged.
We use our chat internally as a communication tool. The support channels are as follows: