Our support engineers handle the channels listed below. They are sorted in order of priority (strictest SLA at top), and as a result, it is possible that channels that appear lower in this list experience longer delays in receiving responses. We are actively hiring more Support Engineers to strengthen the team and provide support to the community.
When an emergency ticket comes in, it triggers a PagerDuty incident. All Support Engineers must have the PagerDuty application installed on their phones once they are added to the on-call rotation schedule.
When a PD incident is triggered, the alarm will go off for the person on call. You should acknowledge the incident within 5 minutes, or the person on second level support will be alerted. The PD incident will have the link to the corresponding Zendesk issue from where you will continue the conversation with the customer.
Once acknowledged, you need to login to Zendesk, go to the corresponding ticket and let the customer know that you will handle their case. On this response you should ask for the best way to contact them. Usual channels are Phone, Skype, WebEx or Hangouts. It is also a good idea to send them a meeting link where you are waiting, requesting that they join and to let you know if they will not be able to join.
Once the emergency has been resolved, return to the ticket in Zendesk and document any steps taken to resolve the issue.
If you are unable to help the customer and their instance is in a critical state (unavailable, uncertainty of data loss, etc.), you should escalate the PD incident to second level support, and work through the issue together. It may also be necessary to ask for assistance from a developer in the appropriate slack channel. While you are waiting for help to join the call, focus on getting their server to a usable state.
If an emergency takes longer than an hour to resolve, and/or multiple people are or need to be involved, start a google doc that is open to the customer and the wider team at GitLab, and keep track of the issues and ideas there. Zendesk's 'linear' display of communication with a customer is not as effective in crisis situations, and the majority of developers do not have access to Zendesk in the first place. Announce the google doc in the appropriate slack channel (
#general) so that individuals can contribute solutions and ideas. When the crisis has been resolved, be sure to transfer pertinent know-how from the google doc to relevant documentation, handbooks, and/or issue trackers, so that the google doc can be deprecated a.s.a.p. In addition, Support Engineers and Developers involved in the crisis should make time to have a hangout for hand-off to make sure that everyone has the chance to recover and stay clear-headed.
We have a Responsible Disclosure Policy. Emails sent to email@example.com 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.
Occassionally issues do not get automatically routed as
security labeled or assigned the the Security team, refer to working with Security for information on identifying and handling these tickets. Sometimes issues that would be better served directly by support engineers end up in the
security queue. It is okay to take and handle issues such as 2-factor and other authorization configuration problems for GitLab.com users.
When in doubt, 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.
Issues created from reports to
firstname.lastname@example.org must follow the security issue triage process.
Reports that are PGP encrypted will be handled by the security team.
If a team member requires access to HackerOne, create an access request.
You should always answer the tickets in a FIFO manner. Make sure that you answer the tickets that are assigned to you first and then move on to new tickets that have come in and are unassigned, again using FIFO. When you need others to help please create an issue on the relevant GitLab issue tracker.
For ZenDesk issues you will have created issues on the relevant issue tracker. Please refer to the priority as listed under GitLab Workflow in the handbook.
For issues specific to GitLab.com that have nothing to do with availability we have the Support Tracker. This forum must also be checked periodically for new issues and to report back if an issue has been solved. Ensure that you assign the issue to yourself to enable you to keep track of the issue and also to enable other support engineers to easily pick on unassigned tasks at a glance. Some people use this forum to report issues they are having with their self hosted installation. In that case, you should refer them to the CE issue tracker or to our get hep page, depending on the issue they are having.
It is always encouraged to take a look at all our issue trackers and respond to bug reports or feature requests:
See the issue triage policies for the above trackers for more information on how issues should be handled.
TODO Questions from Docker's GitLab CE page flow into ZenDesk.
If you have time for it please improve GitLab: fix bugs, add features, and polish the website. You can also consider hanging out on IRC to answer questions and help people (#gitlab on freenode.net).