The mission of GitLab’s Corporate Communications team is to amplify GitLab's product, people and partnerships in the media, via social media channels and through award wins. This team is responsible for global public relations (PR), social media, and executive communications (speaking). Corporate Communications Job families can be found here.
This page is the single source of truth for corporate communications objectives/goals, contact information, messaging, PR/social media guidelines, approval processes, strategy and more.
The GitLab Corporate Communications team is responsibility for the following activities and communications channels:
As detailed in GitLab’s public CMO OKRs, GitLab’s corporate communications team seeks to elevate the profile of GitLab in the media and on social media, positioning it as a pioneer of remote work, increasing share of voice against competitors, and securing key narratives in feature articles.
FY23 Corporate Communications Plan
The Corporate Communications team measures results using the following north star metrics:
Social Media:
Media and Awards:
Speaking:
Please visit our Get In Touch page for contact details.
Please use the #external-comms Slack channel and please follow the Communication Activation Tree.
To mitigate a potential incident and/or if an incident has occurred, please follow the incident communications plan.
Speaking on behalf of GitLab via a public channel such as a media interview (in-person or via phone), on a podcast, in a public issue on GitLab.com, on a forum, at a conference/event (live or virtual), in a blog or an external platform is a significant responsibility.
As of September 13, 2021, all GitLab team members who speak with the media are required to first complete the GitLab Media Training and all GitLab team members who speak externally at a conference or event are required to first complete the GitLab Speaker Training. Both of these trainings have been designed to keep us aligned in representing the company following GitLab’s SAFE framework. Being mindful of how you say things within open issues, on social media, or at a booth during an event will help keep the company SAFE. We all represent the company. Note, any spokesperson who violates the Speaking on Behalf of GitLab guidelines will have their spokesperson privileges revoked.
If you are unsure whether or not you should accept a speaking opportunity, create a public issue to gather feedback/communicate a message, or provide comments representing GitLab please see below for guidance.
Being a designated company spokesperson on topics ranging from Company background to Remote Work to DIB to technical topics like CI/CD or security practices is a responsibility that should be taken with the utmost seriousness. While each team member represents the company and GitLab’s mission is to ensure "everyone can contribute," it is important to hone our list of designated company spokespeople. Spokespeople are SMEs, seasoned in their role (minimum 6 months at the company) and positioned to be at the company for a while for consistency (exceptions may apply).
Spokesperson Criteria:
Watching the above training courses are very important to ensure we are consistent with company narratives and messaging and key points are effectively delivered publicly.
If you are new to being a spokesperson for GitLab, the Corporate Communications team may ask you for video examples of past speaking engagements (events, webinars, tutorials, etc.) to assess the level of speaking comfortability. If you are new to speaking externally and/or do not have a video asset, the team may conduct a 15 minute practice interview to quickly assess if you meet the above criteria.
Media coverage is common and expected for growing companies. GitLab's transparent nature has led to some positive media coverage and community engagement on social channels and forums; however, it has at times resulted in negative criticism of the company — both valid and invalid. This is common and is expected to continue as the company continues to mature. To stay up-to-date on media coverage, flag any articles or podcasts you see or ask questions, please post in the #newswire Slack channel.
Due to GitLab's unique company transparency and mission that everyone can contribute, team members may be approached by reporters, podcasts hosts, etc. to comment on the company and/or conduct interviews. If you are asked to be quoted or to provide commentary on any matter as a spokesperson of GitLab, please provide detail of the opportunity to the Corporate Communications team in the #external-comms Slack channel before engaging. The Corporate Communications team may ask you to open an issue for further evaluation and engagement for the opportunity.
While team members may have established relationships with reporters, podcasts hosts, etc., engagement on any matter related to GitLab should go through the Corporate Communications team. You can reach the team in the #external-comms Slack channel before engaging.
In the event that a media member, editor, or publisher offers a draft or preview of an article where you are quoted, please allow the Corporate Communications team 5 business days to review by posting in the #external-comms Slack channel. The Corporate Communications team will ensure that the appropriate GitLab team member(s) review and approve in a timely manner.
Invited to Speak
If you are asked to speak on behalf of GitLab at an event, on a webinar or at a Meetup (and you are not already a member of the GitLab speakers bureau), please reach out to the Corporate Communications and Developer Evangelist teams to ensure that the opportunity aligns with GitLab objectives and key narratives. Inquiries should be initiated in the #external-comms Slack channel before you accept the speaking invitation. Please allow 5 business days for evaluation. Opening an issue under Corporate Marketing to further collaborate on the opportunity may be requested.
Submitting to Speak
If you are planning to submit an event CFP or request to participate as a speaker for a webinar or Meetup (and you are not already a member of the GitLab speakers bureau), please ensure the opportunity aligns with GitLab objectives and key narratives. If you are unsure, please reach out to the Corporate Communications and Developer Evangelist teams. If accepted to speak, please take the training “Best practices for public speaking,” notify the Corporate Communications and Developer Evangelist teams via the #cfp Slack channel w/link to the accompanying issue and ensure the teams have 7-10 business days to review your final presentations.
E-Group External Communications Request
If you have an opportunity (media opportunity, podcast, video, webinar, fireside chat, conference, meetup, etc.) that you would like to invite an e-group member to participate in, please create a GitLab issue within the Corporate Marketing project using the E-Group External Communications Request Issue Template. When possible, please plan 90 days minimum from time of open issue to time of speaking opportunity for preparation. Once the issue is created, please post in #external-comms Slack channel for further assistance. Please allow the Corporate Communications team 5 business days to review your request.
Amplifying your Speaking Opportunity
When speaking at an event, on a webinar or at a Meetup, if you are open to being a spokesperson with media or creating a contributed article on your talk, reach out to the Corporate Communications team via the #external-comms Slack channel.
For ways to amplify your speaking opportunity, check out the “How to make your content work harder for you” presentation.
Event Booth Staffing
If you are staffing the GitLab booth at an in-person or virtual event, you are representing GitLab. Please follow the company’s SAFE framework when engaging with booth visitors and event attendees.
Analysts
For analyst research-oriented requests, please consult the Analyst Relations handbook section and direct questions to the #analyst-relations Slack channel.
Media
For media inquiries that are more research oriented, please share the request and associated context in the #external-comms Slack channel. An example of a research-oriented request is an invitation to participate in an interview to share more about one's day-to-day role at GitLab, specific tools teams use on a daily basis, how a team interacts and collaborates with other teams, specific products that are most helpful to them in their workflow, etc. The Corporate Communications team will evaluate for reach, awareness, merit, and potential conflicts of interest, and advise on a case-by-case basis.
Honorariums
If the request has an honorarium offered (for example, a gift card or cash amount awarded for participation), please go through our Approvals for Outside Projects & Activities process to ensure a conflict of interest is not present.
You may be approached by external parties seeking to provide payment for a GitLab team member's time to discuss GitLab remote practice to help them guide a client. While this is not a traditional research or speaking opportunity (i.e. event or Meetup) it is still considered an external speaking opportunity. We ask that team members verify who they are speaking with to make sure the source is indeed valid and the request legitimate. Remember that you represent GitLab and if any question makes you uncomfortable or gives you a pause on whether you should answer, we recommend that you do not answer. Questions regarding GitLab financials, sales, compliance, executives or where the company is heading should adhere to the SAFE framework and be treated with caution, as should anything which is not already available in the GitLab handbook. We encourage all team members to be company evangelists and this can be done without sharing Not Public information about GitLab.
Please consult the Social Marketing Handbook for guidelines on how to represent GitLab on your personal social media platforms. If you are contacted on a social media platform and asked to share/retweet or provide commentary as a spokesperson of GitLab, feel welcome to provide detail of the opportunity to the social team in the #social-media Slack channel.
You are welcome to write about your experience as a GitLab team member on your personal blog or for other publications and you do not need permission to do so, as long as you follow the company’s SAFE framework. If you would like someone to check your draft before submitting it, you can share it with the Corporate Communications team who will be happy to review. Please post it in the #external-comms Slack channel with a short summary and allow 5 business days for review.
Posting in and discussions occurring within a public GitLab issue should follow the same guidelines as if you were posting about GitLab on social media, engaging with community members in a forum or conducting an interview with a media outlet. You are externally representing and communicating on behalf of GitLab.
When representing and/or communicating externally on behalf of GitLab, please follow the SAFE framework. Being mindful of how you say things within open issues will help keep the company SAFE. We all represent the company.
GitLab's Corporate Communications (PR/Social Media) team is the DRI (directly responsible individual) for the GitLab Master Messaging Document, Guide on Speaking About Remote work at GitLab and company Fact Sheet. These documents are regularly kept up-to-date and should be the single source of truth for all company information used for media interviews and award submissions.
GitLab's Corporate Communications and Product Marketing teams are the DRI (directly responsible individual) for the GitLab Master Company Deck. This deck is regularly kept up-to-date and should be the single source of truth for all company information used for external speaking presentations and engagements.
Some media outlets (including these ~14,000 newspapers and magazines) require GitLab to hold a license to share (and do the various other things noted below with) extracts, quotes or headlines of print and online articles - both internally (eg. via slack, email or in confidential GitLab issues) and externally (eg. on GitLab's social media channels). The sharing of bare hyperlinks to articles (without extracts, quotes or headlines) does not require a license.
A license may be required to do any of the following with extracts, quotes or headlines of print and online articles:
If you are interested in doing any of the above with a media article (or an extract, quote or headline) internally or externally beyond just sharing the bare hyperlink, please reach out to the Corporate Communications team via the #external-comms slack channel before proceeding to confirm if a license is required.
The communications team develops training and certifications for GitLab team members to build up their practices when representing the company with the media, at an event, or on social media. Visit our training page and consider taking a communications training to learn more about:
This process allows us to determine the best channel to communicate different types of updates and news to our users, customers, and community.
Please follow the instructions below to request a formalized announcement around any of the following:
Please submit a request via an announcement issue template in the Corporate Marketing project before opening an issue for a blog post, for example. In the issue template, you will be able to provide additional information on the proposed announcement. As a general guide, below the team has outlined three levels for announcements based on the type of announcements and suggested communications activities associated with each tier. The Corporate Communications team will assess your request in the issue and determine how to proceed. If you are requesting a joint announcement and you are not part of the Partner Marketing team, please ensure you ping them on your issue.
If your request for an external announcement meets the Level 1 criteria, please open an issue using the press-release-template issue template. The issue template will prompt you to fill in logistics details, such as timing, and answer the following questions:
If a channel or alliance partner is interested in taking the lead on making a formal announcement, please complete a partner announcement issue template, which includes details on the review and approval process as well as links to the press release template.
A few stipulations:
If you receive a vendor request for GitLab to act as a reference (case study, blog post, press release, GitLab logo on their website, etc.) for the product, service, and/or technology that your GitLab team is using, please refer to the process outlined on the Brand Strategy team's handbook.
GitLab's corporate communications team is the DRI (directly responsible individual) for writing all press releases that are issued by the company and routing through the appropriate approval process. The team has developed an issue template to help make the press release development and approval process more streamlined and consistent. If you have any questions on the press release process or how to make an announcement request, please reach out via the #external-comms Slack channel or submit an announcement issue template in the Corporate Marketing project (see Requests for Announcements section above).
If you would like to use a GitLab public issue to communicate an update to customers/users or gather feedback from customers/users, please complete the announcement issue template with the details of the specific request and draft of the issue announcement copy. The Corporate Communications team will review the request details and issue copy, as well as recommend other relevant teams (product, product marketing, legal, etc) to loop in for review before posting the public issue.
In some cases, it may be more appropriate and efficient to communicate with users in a public issue. Below are some examples of the types of communications that may suit an issue as opposed to a blog post, press release, or email, for example:
Using a public issue has a few advantages:
Below are some examples of using an issue to communicate something with GitLab's audience. Feel free to use these examples as a template for your issue.
At a minimum, your issue should:
user communication label applied.We can spread the word about a public issue in the same way that we would promote a blog post or press release:
We can promote other items this way as well: for example surveys, landing pages, or handbook pages.
GitLab team members will find embargo and announcement guidelines in a confidential issue (must be logged in to access).
This answers the following questions.
If you would like to propose an award for consideration by the Corporate Communications team, please start by creating an issue, using the pr-award-submissions issue template. The template will prompt you to provide a few key pieces of information, including deadlines, fees, and a brief description of the award.
Please flag awards as soon as possible – ideally, six weeks ahead of the deadline. This helps the PR team create and stick to a timeline, and allows for the necessary stakeholder and legal reviews.
As a standard practice, we don’t issue press releases for award wins. However, there are many ways to spread the word about your recognition, both within GitLab and externally.
The publication that arranges the award will typically conduct its own promotion cycle. The accolade will be shared on its website, social media platforms, and in some cases, will be presented as part of a virtual or in-person event. In addition to the publication's promotion, other recommended mediums for promotion include submitting a blog post request and sharing the accolade via GitLab's social media channels.
Internally, we share the recognition in our #whats-happening-at-gitlab channel with links to GitLab social posts, as well as posts for our team members to share on their own social media accounts. We also share award wins in our monthly newsletter.
(Coming Soon)
(Coming Soon)
source then press and click on the releases folder.YYYY-MM-DD-title-of-press-release.html.md.---
layout: markdown_page
title: "Title of press release"
description: "short sentence overview of press release"
twitter_image: "/images/opengraph/Press-Releases/image.png"
twitter_creator: "@gitlab"
twitter_site: "@gitlab"
twitter_image_alt: "Celebrating GitLab's press release about xx with fun emojis"
---
description, twitter_image, and twitter_image_alt would be the three, net-new tags needed to be custom to every single release. twitter_creator and twitter_site would be static with the value "@gitlab".
twitter_image: section above and to merge the release. If the team has previously discussed the work, the social team may have already created a sharing image. If not, they will need to create it from this mention. The social team will add the data necessary to the MR for social sharing and merge the press release.press/#press-releases PageWhen you have added a press release, be sure to update the index page too so that it is linked to from /press/#press-releases.
data then to the press_releases.yml file.press_releases:, then scroll to the most recent dated press release./press/releases/YYYY-MM-DD-title-of-press-release.html.Recent News section with the most recent listed at the top. To update the Recent News section with articles, go to the press.yml file. You will then copy and paste a previous entry on the page and edit with the details of the new article. Repeat this process for each new article entry that you add. You may need to search online for a thumbnail to upload to /images/press/ if articles from that publication are not already listed on the page. If you upload a new image, make sure to change the path listed next to logo: /images/press/.(Coming Soon)