Corporate Communications Handbook

Welcome to the Corporate Communications Handbook

Mission Statement

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.

What We Do

The GitLab Corporate Communications team is responsibility for the following activities and communications channels:

• Press releases
• Media relations (Print/Broadcast/Podcasts)
• Media sponsorships
• Contributed article placement
• Executive event speaking
• Awards
• Incident Communications (separate handbook page)

Team Norms

• We have trust in one another, are transparent and supportive
• We collaborate and share context, background and objectives on our initiatives and projects
• We are invested in one another’s growth and development
• We are committed to producing high quality work, being stewards of the GitLab values and sharing our expertise
• We get stuff done!
  • We are in a highly visible role, managing high stakes opportunities that impact the GitLab brand. While there are “glass balls” vs “rubber balls,” most of the opportunities we oversee are “glass” and will break if dropped.

Objectives and Goals

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.

• Leverage events to generate media interest in GitLab’s people and products
• Form and foster relationships with key reporters and publications
• Position GitLab executives and subject matter experts (SMEs) as thought leaders in their areas of expertise
• Increase GitLab’s presence in awards and accolades
• Cross-promote and amplify GitLab on social media

FY23 Corporate Communications Plan

Metrics and Results

The Corporate Communications team measures results using the following north star metrics:

Social Media:

• Organic Social Impressions
• Engagements (likes, comments, shares)
• Clicks
• Paid social ad value

Media and Awards:

• Impressions
• Ad Equivalency
• Efficiency Metric (Cost per Impressions)
• Business Impact Metric (Impressions/Spend)
• Competitor SOV/award ranking

Speaking:

• Impressions
• Audience demographic
• Business Impact Metric (Impressions/Spend)

Contacting GitLab’s Corporate Communications team

External Parties

Please visit our Get In Touch page for contact details.

GitLab Team Members

Please use the #external-comms Slack channel and please follow the Communication Activation Tree.

Incident Communications

To mitigate a potential incident and/or if an incident has occurred, please follow the incident communications plan.

Speaking on behalf of GitLab

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.

Spokesperson Criteria

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:

• Subject matter expert
• DIB (if relevant)
• Comfortable and ready to speak publicly
• Articulate with the ability to think on their feet
• Complete GitLab’s Media Training course
• Complete GitLab’s Speaker Training course
• Watch Social Media 101 course
• Manager approval
• Good company standing
• Bonus: speakers bureau member
• Exception: Referred by existing spokesperson due to subject matter expertise and it’s an immediate need

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 mentions, incoming media requests and interviews (including podcasts)

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.

Speaking Opportunities (conferences, meetups, webinars and other events)

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 Advocacy 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 Advocacy teams. If accepted to speak, please take the training “Best practices for public speaking,” notify the Corporate Communications and Developer Advocacy 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.

Pursuing Speaking Opportunities Separate from GitLab

We know GitLab team members are multi-faceted and there may be opportunities to speak publicly that don’t overlap with your role at GitLab. In these cases, it is okay to do that assuming the opportunity will not be in conflict with GitLab’s Code of Business Conduct & Ethics.

In these instances, it’s necessary to keep your role at GitLab and affiliation with the company separate from the presentation. Additionally, you should not use GitLab branding, resources, or time allocated to your work at GitLab to prepare or deliver your presentation. Please add “these views are my own” to your comments, presentation, or social media.

If you’re considering a speaking opportunity, which includes participating in podcasts or developing your podcast, that could be perceived as being associated with GitLab even if it is not, please share the opportunity with your manager and #external-comms for review before accepting it to avoid any potential conflicts.

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.

Research-oriented requests

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.

Social Media

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.

Writing about GitLab on your personal blog or for external platforms

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.

Public GitLab Issues

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.

Communications resources and training available to all team members

GitLab Master Messaging Document, Fact Sheet, Speaking Deck

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.

Sharing Media Coverage

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:

• photocopying, faxing, scanning, emailing or copying;
• saving on an internal or external intranet or shared drive;
• printing, photocopying, emailing or distributing material received from a media monitoring organisation or PR agency;
• posting material on internal or external websites or social media accounts.

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.

Training and Certifications

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:

• Social Media 101
• How to make your content work harder for you
• Tips on creating a solid speaking presentation
• GitLab’s Media Training course

Requests for External Announcements

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:

• A new product feature and capabilities
• A product promotion (launching or ending)
• A partner integration
• A significant milestone achieved
• A new initiative
• A customer case study
• Inclusion in an analyst report
• A breaking change
• A deprecation
• A change in policy or pricing
• Something else? If you’re not sure if your case applies, please follow the directions below anyway, so the team can assess how best to proceed.

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.

• Level 1 - A level 1 announcement will be announced via a press release and amplified with social media and a supporting blog post. The execution of a blog post will be determined by the content team on a case by case basis. If the editorial team agrees to publish a blog, then the social amplification will be the blog link as it includes assets that are helpful in the link cards across social channels. If there isn’t an associated blog post, the social amplification can be for the press release link or relevant news coverage of the announcement. (In this case, the DRI needs to ensure there is an associated image to use with the release link or would make the decision of which news outlet link to select for social amplification.) Example announcements and news include but are not limited to: major GitLab company news around funding/earnings, executive new hires, analyst firm industry awards, acquisitions/mergers, Commit announcements, major joint partner news (ex. a partner such as AWS or GCP) and major customer announcement (ex. enterprise or government agencies).
• Level 2 - A level 2 announcement will be announced via a blog post and amplified with social media. The DRI/SME of the announcement will be responsible for working with the content team on creating the content and MR for the blog post (please see the blog handbook for more on this process). Example announcements and news include but are not limited to: partner integrations, new feature/capability highlights from the monthly release cycles (ex. Windows Shared Runners), customer case study announcement (not household names).
• Level 3 - A level 3 announcement will be announced and promoted via GitLab’s social media channels. Example announcements and news include but are not limited to: awards from media publications (ex. DEVIES), speaking opps that GitLab employees are participating in (drive attendees/awareness) and ecosystem partner integrations.
• Other - In some cases, the following communications channels may be more appropriate:
  • A targeted email to affected users
  • Including an item in an upcoming release post (where the announcement is specifically tied to a release, does not require communication in advance of the release, and is not a sensitive topic)
  • A public issue (see below)

Requests for Press Releases

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:

• What are we announcing?
• What is the ideal headline that you want to see?
• Who is the target audience for this news? Why does this news matter to that audience and to the broader industry?
• Why is this announcement important to the business? Are there key business objectives that this announcement will support?
• How will this announcement impact customers, the marketplace, competition and investors?
• What are the top three key messages we want to convey in order of priority?
• What research data (e.g. statistics or research reports) could support the key messages or otherwise add news hooks to the release?
• What key point(s) would you like to make in the executive quote and who should be quoted?

Partner Requests for External Communications Support

Any use of GitLab’s name, brand, or logo requires prior email approval by GitLab according to the process outlined below.

• Partner-led Blog Posts: GitLab is proud of its collaborative partner program, and we encourage partners to showcase their solutions, capabilities and customer success stories through partner-led blogs. Please send all blog posts including GitLab to the GitLab Corporate Communications team at press@gitlab.com for review and approval.
• Press Release Criteria and Approval Process: Partners seeking to issue a press release that includes mention of their partnership with GitLab must meet the criteria outlined below (and in the GitLab Partner Portal).
  • Partner public relations participation criteria:
    • A signed partner contract
    • Minimum 10 joint customers
    • New partners: please reach out to your account representative for guidance.
  • Please note: GitLab requires up to 6 weeks of lead time to support external communications requests.
  • Please email your account representative for guidance on the approvals required and copy the GitLab Corporate Communications team at press@gitlab.com.
  • GitLab account representatives: Any requests for public relations support requires approval from your executive sponsor, Nick Cayou. Please reach out via #external-comms in Slack if you have questions about this.

GitLab Vendor Reference Requests

If you receive a vendor request for GitLab to act as a reference (case study, blog post, 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. If the vendor requests a press release, please refer to the Corporate Communications handbook page.

GitLab Press Releases

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. If you have questions about 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 (see Requests for Announcements section above).

For partner-led blogs or press releases, please refer to the partner PR request section of the handbook. Note that due to the volume of requests, GitLab rarely writes joint press releases.

Using Public Issues to Communicate with Users

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:

• Soliciting feedback (e.g. gathering community input on a proposal)
• Explaining upcoming or ongoing changes to GitLab (not breaking changes, changes which require users to take action, or otherwise sensitive)
• Sharing updates on a live, ongoing incident (this would be owned by the Communications Manager on Call)

Using a public issue has a few advantages:

• In cases where you are seeking feedback or input from the community, your issue can serve as the single source of truth for communication on the subject, rather than spreading communication across a blog post and another page.
• You can easily add related epics and issues so that users can browse all the relevant information and contribute to the discussion. This also keeps the conversation all on GitLab, rather than spreading it across different channels.
• There is one fewer step/link to click on for community members to share their feedback.
• When seeking feedback, keeping things in an issue reinforces that a final decision has not yet been made. A blog post can give the impression of being a formal announcement rather than a proposal, which can have a negative impact on brand sentiment.
• You can get your message out there more quickly because for most team members creating an issue is more familiar than writing and formatting a blog post. There’s also no need to coordinate with the content team. However, please follow the guidelines above for review from the Corporate Communications team.

Creating your communication issue

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.

• Feedback for ending support for Internet Explorer 11
• Recent changes in GitLab routing
• Color updates in GitLab to establish an accessible baseline

At a minimum, your issue should:

• Be created in the most relevant GitLab project. This would likely be the project where most of the discussion or work on your initiative is being done.
• Have the user communication label applied.
• Include context for your message. What background information might someone need to know to understand what you are communicating or asking? What relevant issues or epics can you add to help people understand?
• Use subheadings for structure. This makes your issue easy for readers to skim and pick out the most relevant information to them.
• Include any key dates. Be sure to call out if there is a deadline for submitting feedback.

Promoting a Public Issue

We can spread the word about a public issue in the same way that we would promote a blog post or press release:

• You can request promotion of your item on GitLab’s social channels.
• You can request that your item be included in an upcoming newsletter by leaving a comment on the appropriate newsletter issue.
• Ask in #marketing on Slack if you would like to promote in some other way.

We can promote other items this way as well: for example surveys, landing pages, or handbook pages.

Best Practices for an Announcement and Understanding Media Embargoes

GitLab team members will find embargo and announcement guidelines in a confidential issue (must be logged in to access).

This answers the following questions.

1. What is an embargo?
2. Why do we set embargoes?
3. Why don’t we talk about embargoed news prior to the announcement?
4. Who do we share embargoed news with?
5. Who is it okay to discuss this news with?
6. When can I talk about news freely with anyone?

Submitting for an Award

Flagging an Award for Consideration

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.

Amplifying Award Wins

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.

Create and Submit Contributed Content

Guidelines

(Coming Soon)

Tips and tricks

(Coming Soon)

GitLab Press Page and Press Kit

Updating the Press Page

How to Add a New Press Release

1. Create a new merge request and branch in www-gitlab-com.
2. On your branch, navigate to source then press and click on the releases folder.
3. Add a new file using the following format YYYY-MM-DD-title-of-press-release.html.md.
4. Add the following to the beginning of your document:

---
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 emoji"
---

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”.

1. Add the content of the press release to the file and save. Make sure to include any links. It is important to not have any extra spaces after sentences that end a paragraph or your pipeline will break. You must also not have extra empty lines at the end of your doc. So make sure to check that when copying and pasting a press release from a google doc.
2. Assign @wspillane to the MR to add the social sharing image to the 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.

Updating the press/#press-releases Page

When you have added a press release, be sure to update the index page too so that it is linked to from /press/#press-releases.

1. On the same branch, navigate to data then to the press_releases.yml file.
2. Scroll down to press_releases:, then scroll to the most recent dated press release.
3. Underneath, add another entry for your new press release using the same format as the others, ensuring that your alignment is correct and that dashes and words begin in the same columns.
4. The URL for your press release will follow the format of your filename for it: /press/releases/YYYY-MM-DD-title-of-press-release.html.

How to Update the Recent News Page

1. On a regular basis the PR agency teams will send a digest of coverage highlights and news articles.
2. The PR team updates the 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/.

Updating the Press Kit

(Coming Soon)

View page source - Edit this page - please contribute.