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.
|https://news.ycombinator.com/item?id=17032274||✖||✖||The OP mentions GitLab out of context.|
|https://news.ycombinator.com/item?id=17101902||✖||✓||This required an urgent response because the thread momentum was very perishable.|
|https://news.ycombinator.com/item?id=16914775||✓||✖||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).|
|https://news.ycombinator.com/item?id=13537052||✓||✓||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.|
Tweets expressing positivity about GitLab.
For posts about remote jobs and other kind of announcements that aren't strictly related to GitLab -> Use the
Mention ZenDesk macro
For issues related to self-managed instances -> Forward to Community Forum
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:
There are some common topics that surface in our community where the advocates team does not respond or engage experts.
Exceptions can be made if these are pressing issues, or if an expert is needed to correct misinformation. It's best practice to collaborate with Legal or External Communications teams before making these exceptions.
|Topic||Why We Don't Engage|
|Location Based Pay||Most participants in these conversations already have their mind made up on their perspective of our compensation model. Many conversations will naturally share relevant links from GitLab. There is no new information we can add to these conversations, and involvment on our part could just make people in the conversation angry.|
|GitLab's IPO Status & Being a Public Company||Anyone can read about the company's goals and plans in the handbook, however, use caution when dealing with these questions and err on the side of not commenting at all. Experience tells us that this conversation moves quickly to speculation and assumptions.|
|Country Specific Hiring Restrictions||All information about country hiring guidelines can be found in our GitLab Jobs FAQ section. We can share this list if users are asking questions, but we can add little value if users are angry about the policies.|
|Harrasment by Community Members||We do not engage with members of our community who harras anyone on the GitLab team, or who do not follow our Code of Conduct.|