Gitlab hero border pattern left svg Gitlab hero border pattern right svg

General guidelines

Handling mentions

Urgent and important mentions

It's important to be able to recognize events that are both important and urgent. Some might be important but not urgent, others urgent but not important while some are neither important nor urgent. However, mentions that are both urgent and important should be handled as top priority. HackerNews is a channel that commonly sees this type of mentions.

These mentions might be intimidating and/or hard to answer by yourself. Please involve several topic experts to respond instead.

When this type of mention comes up during a weekend, please ping more people than you would usually do. It's not considered rude (anyone and everyone can always snooze Slack notifications during weekends), you're just increasing the chance someone sees it in time.


Mention Important Urgent Explanation The OP mentions GitLab out of context. This required an urgent response because the thread momentum was very perishable. The OP expressed dissapointment with his support experience - This is important to address, but not time sensitive (a one or two hour response time woudln't have any difference in impact compared to a 6h response time). Content is volatile and affects a lot of users and the company image. This needed to be addressed as soon as possible and with care.

Community interaction archetypes

Stability complaints

Feature requests

General questions and issues with

Bug reports

General positivity

Tweets expressing positivity about GitLab.

Sample responses:


Special types

External resources

When responding to community messages, you may face a situation where our documentation doesn't have an official solution. In these circumstances, you can consider replying with a link to an external resource.

Before that, consider documenting the missing piece. It is time-consuming, but it saves time for both you and your colleagues when this comes up again. Respond after updating the documentation. This approach encourages immediate documentation improvements/edits, and it allows avoiding all external resources. If you have any questions about writing the documentation, ask the relevant Technical Writer or Product Manager. When your content is ready, assign it to one of them for review.

If you determine that this question is too specific for our documentation and decide to use an external resource, please make sure that:

Notes / remarks