This document is a guide for GitLab team members who manage social media accounts.
You are personally responsible for the tweets, likes, and replies you post on social media while representing GitLab. Everything you publish is publicly viewable and will be available for a long time even if redacted. Be careful and thoughtful when using the company accounts.
Remember that you represent GitLab and our culture. When commenting on posts please keep in mind: "Don't argue but represent".
Responding to Requests
Respond to mentions. Any time GitLab is mentioned or relevant to a thread it gets directed to our different chat channels and someone from GitLab should be responding to questions or feedback. The idea here is to be available for people without making them feel obligated to talk to you.
Respond quickly. The urgency to respond depends on the medium. On Hacker News we need to respond within an hour or so, responses after an item is no longer on the homepage are much less valuable.
Everyone in the team helps. Responding to social media is a task of all of us. Every team member is expected to contribute, especially if you have a leadership position.
Delegate to the experts. Nobody knows everything. Send the most relevant team member that is available a link over chat so they can respond. Make sure they can follow up quickly or find someone else.
Answer yourself. We should be personable and human. So if something is delegated to you don't answer the question and have someone else post it. Engage yourself. Make or create an account for the service if needed.
Continue the conversation by providing meaningful responses instead of just upvoting or saying a one word “Thanks!” If a post will add to a discussion, post it. If someone has given you feedback, link them to a relevant issue showing the feedback has been received. You can even provide people with links to non-GitLab things such as Git guides or DevOps guides. There is always a feature to mention or gratitude to express 'Thanks you so much for spreading the word about GitLab.'. For an example see the first three responses to a HN post where the first three comments where positive but no questions. Or see this response that links to the actual issue and therefore a reply that the original 'thank you' didn't get.
Stay positive. Don't feel the need to defend GitLab when someone says something negative (see "Assume good faith" below). Negative feedback is a great chance to learn or consider something new, so thank them for their feedback, document it in the issue tracker (add a comment to the issue if one is already open), and invite them to leave more comments if they wish. When people make criticisms, remember to acknowledge mistakes and stay constructive.
Remember that you’re speaking to a human being. The people behind the comments are real, so treat them how you’d want to be treated if the roles were reversed. Try to find their real name so that you can personalize your message to them.
Begin by thanking them for their feedback or apologizing to them for the inconvenience they experienced. We want to start and end conversations on a high note.
Assume good faith. Remember, people are commenting on the product, not the people. The line can get blurry, but it’s important to stay objective.
Address any and all points the user has made. If they made 4 points/requests, respond to each. If you don’t know the answer, don’t be afraid to tell them you don’t know but will look into it.
You’re allowed to disagree with people. Try to inform the person (respectfully) why they might be misguided and provide any links they may need to make a more informed decision. Don’t say “you’re wrong” or “that’s stupid.” Instead try to say “I disagree because…” or “I don’t think that’s accurate because…”
Replies are not endorsements. Just because you’re replying and not publicly disagreeing doesn’t mean you agree with the statement.
Always seek feedback. If someone has something negative to say, ask them how we could make it better. If they can provide examples that’s even better. As said on HN: "the responsiveness and agreeableness to look into issues and invite people to be a part of the solution they seek out are phenomenal habits".
Open issues! If someone has a point they’d like to discuss, feel free to open an issue and link them to it. Regardless of whether or not you agree with the point, you should be inviting the community to participate in GitLab’s direction. Be sure to link to the relevant post in the issue for easier tracking. This won’t work for all cases, so use your best judgment.
Provide details. If the request or the question is opened to more than just a straight answer, don't be afraid to detail it as much as possible. If there is already an opened issue or merge request for that case, link it to your answer. Do the same if there are other sources of information to support your statement, such as blog posts and webpages.
Do what you say you will. If you say you'll look into something, set a reminder to circle back with the person or link them to an issue on the issue tracker. Saying you'll look into something makes it impossible to continue the conversation until you do so, so it is essential that you continue the conversation at some later point. If this is too much work just say 'I don't know' and leave it at that.
Disclose. If you comment on social media (Hacker News, Reddit, Twitter, etc.) your profile should mention that you work at GitLab. By mentioning that you work at GitLab your comment will rightfully be vetted more critically. If you post a lot don't mention it in every post, prefacing everything with 'GitLab CEO here' became annoying. A subtle disclosure is possible by speaking in the we form (we shipped, we messed up, we will make that, our product).
When speaking for GitLab, use the “GitLab voice.” When replying from the official GitLab account, speak as “we” and represent the software and community. On the official @GitLab account Twitter account and in other social media we should model attributes of our software and community. We strive to respond to all messages and questions. We respond by encouraging collaboration and contribution.
Consider what benefits the software and community, and how the software would respond if we personified it. Be responsive, positive, open minded, curious, welcoming, apologetic, transparent, direct, and honest. Someone doesn’t like something? Ask them to tell us more in the issue tracker. Someone thinks GitLab could be better? Invite them to submit a feature proposal. Any criticism is an opportunity to improve our software.
When responding to posts from your personal account, feel free to incorporate your own style and voice. Talk to people as if you were talking to them in person.
Please do not engage in competitor bashing. Instead, highlight positive differences — it's best to focus on the ways that GitLab outperforms other solutions.
Dealing with Conflict
You may come across angry users from time to time. When dealing with people who are confrontational, it’s important to remain level-headed. You may also send them to Sid directly.
Assume good faith. People have opinions and sometimes they’re strong ones. It’s usually not personal.
If it’s getting personal, step away from the conversation and delegate to someone else.
Sometimes all people need is acknowledgment. Saying “Sorry things aren’t working for you” can go a long way.
Never submit GitLab content to Hacker News. Submission gets more credibility if a non-GitLab Hacker News community member posts it, we should focus on making our posts interesting instead of on submitting it.
Don't link to any Hacker News submissions to prevent setting off the voting ring detector. Trying to work around the voting ring detector by up-voting from the new page is not reliable, just don't announce nor ask for votes.
Don't make the first comment on a HN post about GitLab, wait for people to leave comments and ask questions.
Avoid using corporate jargon like 'PeopleOps'.
Always address the HN community as peers. Be sure to always be modest and grateful in responses.
If you comment yourself make sure it is interesting and relevant.
Please do not use the GitLab logo as the avatar for your personal accounts on social. You are welcome to use our branded banners, but it is important that your profile avatar does not lead users to confuse your account with the official GitLab accounts.
While you should display the fact that you work at GitLab in your bio if you intend to advocate for GitLab on social, we suggest that you avoid including the word gitlab in your handle. Team member advocacy is incredibly valuable and we are lucky to have so many engaged team members, but creating an account to solely post about GitLab is not effective. The reason team member advocacy is so powerful is because people trust employees more than brands and executives. Your advocacy is powerful when it is authentic, and having an account that only exists to promote GitLab will not ring true to others who browse your tweets.