Our service 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 Service Engineers to strengthen the team and provide support to the community.
When an emergency ticket comes in, it triggers a PagerDuty incident. All Service 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.
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.
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 (#infrastructure, #development, #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, Service 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.
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 a confidential issue so we can work in private. Only if the security report is about confidential issues, then use dev.gitlab.org instead. 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.
We also use HackerOne to manage security reports. The HackerOne dashboard lists all reports for which you need to respond within one business day. These reports are also piped into ZenDesk, but they need to be responded to from the HackerOne dashboard and closed manually in ZenDesk upon completion. Remember that all researchers should receive feedback as with regular support tickets, and you should not hesitate to triage or escalate the report. Always mention that they can email us at any time for an update. Eventually each report has to be accepted and/or closed through the HackerOne dashboard even if you've followed through on ZenDesk.
After a report has been closed as resolved or informative it can be publicly disclosed. This is can be requested either by GitLab or the reporter. If the reporter requests this then it will be released when you accept it or 30 days after the request is submitted. Prior to publication you should edit the report and make sure that it has:
If you need to grant HackerOne permissions to a new GitLab user, have an admin send an invitation from HackerOne and add you to the Internal group. You can find out who the admins are by asking on the #support channel.
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 service engineers to easily pick on unassigned tasks at a glance. Some people use this forum to report issues they are having with their on-premises installation. In that case, you should refer them to the CE issue tracker or to our Getting Help 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).