The Corporate Marketing team includes Content Marketing, Corporate Events, PR (Public Relations), All-Remote Marketing, and Design. Corporate Marketing is responsible for the stewardship of the GitLab brand and the company's messaging/positioning. The team is the owner of the Marketing website and oversees the website strategy. Corporate Marketing develops a global, integrated communication strategy, executes globally, and enables field marketing to adapt and apply global strategy regionally by localizing and verticalizing campaigns for in-region execution. Corporate marketing also ensures product marketing, outreach, and marketing & sales development are conducted in a way that amplifies our global brand.
GitLab's brand has a personality that is reflected in everything we do. It doesn't matter if we are hosting a fancy dinner with fortune 500 CIOs, at a hackathon, or telling our story on about.gitlab.com…across all our communication methods, and all our audiences, GitLab has a personality that shows up in how we communicate.
Our personality is built around four main characteristics.
These four characteristics work together to form a personality that is authentic to GitLab team-members, community, and relatable to our audience. If we were quirky without being human we could come across as eccentric. If we were competent without being humble we could come across as arrogant.
GitLab has a higher purpose. We want to inspire a sense of adventure in those around us so that they join us in contributing to making that mission a reality.
The following guide outlines the set of standards used for all written company communications to ensure consistency in voice, style, and personality, across all of GitLab's public communications.
See the Blog Editorial Style Guide for more.
GitLab is an open source project with a large community of contributors. Over 2,000 people worldwide have contributed to GitLab's source code.
GitLab Inc. is a company based on the GitLab open source project. GitLab Inc. is an active participant in our community (see our stewardship of GitLab CE for more information), as well as offering GitLab, a product (see below).
GitLab is a complete DevOps platform, delivered as a single application. See the product elevator pitch for additional messaging.
The tone of voice we use when speaking as GitLab should always be informed by our Content Strategy. Most importantly, we see our audience as co-conspirators, working together to define and create the next generation of software development practices. The below table should help to clarify further:
| We are: | We aren't: |
|---|---|
| Equals in our community | Superior |
| Knowledgeable | Know-it-alls |
| Empathetic | Patronizing |
| Straightforward | Verbose |
| Irreverent | Disrespectful |
| Playful | Jokey |
| Helpful | Dictatorial |
| Transparent | Opaque |
We explain things in the simplest way possible, using plain, accessible language.
We keep a sense of humor about things, but don't make light of serious issues or problems our users or customers face.
We use colloquialisms and slang, but sparingly (don't look like you're trying too hard!).
We use inclusive, gender-neutral language.
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"
---
/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.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. Display 10 articles at a time. To avoid formatting mistakes, copy and paste a previous entry on the page, and edit with the details of the new coverage. You may need to search online for a thumbnail to upload to images/press, if coverage from that publication is not already listed on the page. If you upload a new image, make sure to change the path listed next to image_tag.@ mention team members who will be involved.Design and Website Redesign (if applicable) label(s) to your issue.Design label in issue trackerThe Design label helps us find and track issues relevant to the Design team. If you create an issue where Design is the primary focus, please use this label.
Per the Design team's discretion, the prioritization of design projects will be based on the direct impact on Marketing.
To get a better sense of corporate marketing project prioritization, you can view the Design Issue Board.
Design projects within the www-gitlab-com project can be tracked using the Website label. The prioritization of projects for about.gitlab.com can be viewed on the Website Issue Board.
Any design requests that do not fall in line with the goals and objectives of Marketing will be given a lower priority and factored in as time allows.
As the company continues to grow, incoming requests for internal team logos are increasing at a rate that is not scalable for the Brand Design team. We understand the desire for teams within GitLab to have their own identity, so we've created these guidelines to help direct your request:
The Design team has a rather wide reach and plays a big part in almost all marketing efforts. Design touchpoints range from the GitLab website to print collateral, swag, and business cards. This includes, but certainly not limited to:
In the spirit of 'everyone can contribute' (as well as version control and SEO) we prefer webpages over PDFs. We will implement a print.css component to these webpages so that print PDFs can still be utilized for events and in-person meetings without the headache of version control
To download the GitLab logo (in various formats and file types) check out our Press page.
The GitLab logo consists of two components, the icon (the tanuki) and the wordmark:
GitLab is most commonly represented by the logo, and in some cases, the icon alone. GitLab is rarely represented by the wordmark alone as we'd like to build brand recognition of the icon alone (e.g. the Nike swoosh), and doing so by pairing it with the GitLab wordmark.
Safe space acts as a buffer between the logo or icon and other visual components, including text. this space is the minimum distance needed and is equal to the x-height of the GitLab wordmark:
The x-height also determines the proper spacing between icon and wordmark, as well as, the correct scale of the icon relative to the wordmark:
Here are the recommended minimum sizes at which the logo may be reproduced. For legibility reasons, we ask that you stick to these dimensions:
The tanuki is a very smart animal that works together in a group to achieve a common goal. We feel this symbolism embodies GitLab's mission that everyone can contribute, our values, and our open source stewardship.
GitLab is a registered trademark of GitLab, Inc. You are welcome to use the GitLab trademark and logo, subject to the terms of the Creative Commons Attribution Non-Commercial ShareAlike 4.0 International License. The most current version of the GitLab logo can be found on our Press page.
Under the Creative Commons license, you may use the GitLab trademark and logo so long as you give attribution to GitLab and provide a link to the license. If you make any changes to the logo, you must state so, along with the attribution, and distribute under the same license.
Your use of the GitLab trademark and logo:
Examples of improper use of the GitLab trademark and logo:
gitlab.company.com or gitlab.citool.io.Logos used on the about.gitlab.com site should always be in full color and be used to the specifications provided by the owner of that logo, which can usually be found on the owners website. The trust marks component found throughout the site is the only exception and should use a neutral tone:
The tanuki logo should also not have facial features (eyes, ears, nose…); it is meant to be kept neutral, but it can be accessorized.
While the brand is ever-evolving, the GitLab brand currently consists of six primary colors that are used in a wide array of marketing materials.
The GitLab brand uses the Source Sans Pro font family. Headers (h1, h2, etc.) always have a weight of 600 (unless used in special situations like large, custom quotes) and the body text always has a weight of 400. Headers should not be given custom classes, they should be used as tags and tags alone (h1, h2, etc.) and their sizes or weights should not be changed, unless rare circumstances occur. Here are typography tags.
H1: Header Level 1
H2: Header Level 2
H3: Header Level 3
H4: Header Level 4
p: Body text
Buttons are an important facet to any design system. Buttons define a call to action that lead people somewhere else, related to adjacent content. Here are buttons and their classes that should be used throughout the marketing website:
Note: Text within buttons should be concise, containing no more than 4 words, and should not contain bold text. This is to keep things simple, straightforward, and limits confusion as to where the button takes you.
Primary buttons are solid and should be the default buttons used. Depending on the color scheme of the content, purple or orange solid buttons can be used depending on the background color of the content. These primary buttons should be used on white or lighter gray backgrounds or any background that has a high contrast with the button color. They should also be a %a tag so it can be linked elsewhere and for accessibility. Buttons should also be given the class margin-top20 if the button lacks space between itself and the content above.
There will be times when two buttons are needed. This will be in places such as our jobs page, where we have a button to view opportunities and one to view our culture video. In this example, both buttons are solid, but one is considered the primary button (orange), and the other is the secondary button (white). The CSS class for the solid white button is
.btn.cta-btn.btn-white.
This is the proper use of two buttons, both being solid, but different colors based on hierarchy. If the background is white or a lighter color that doesn't contrast well with a white-backgound button, a ghost button should be used as a secondary button, and should match in color to the primary button beside it as shown below:
DO NOT: Do not use these ghost buttons styles as standalone buttons. They have been proven to be less effective than solid buttons in a number of studies. They should only be used as a secondary button, next to a solid primary button that already exists. Here are the classes for the secondary buttons:
Icons are a valuable visual component to the GitLab brand; contributing to the overall visual language and user experience of a webpage, advertisement, or slide deck. The GitLab iconography currently consists of "label icons" and "content icons", each are explained in further detail below:
Label icons are intended to support usability and interaction. These are found in interactive elements of the website such as navigation and toggles.
Content icons are intended to provide visual context and support to content on a webpage; these icons also have a direct correlation to our illustration style with the use of bold outlines and fill colors.
A few examples include our event landing pages and Resources page.
Occasionally the old GitLab logo is still in use on partner websites, diagrams or images, and within our own documentation. If you come across our old logo in use, please bring it to our attention by creating an issue in the Marketing issue tracker. Please include a link and screenshot (if possible) in the description of the issue and we will follow-up to get it updated. Thanks for contributing to our brand integrity!
The goal of this guide is to provide written standards, principles and in-depth information to design beautiful and effective GitLab features. This is a living document and will be updated and expanded as we iterate.
We've broken out the GitLab interface into a set of atomic pieces to form our design system, Pajamas. Pajamas includes information such as our principles, components, usage guidelines, research methodologies, and more.
To work more efficiently as an asynchronous team, everything should begin in an issue or merge request as opposed to Slack or email.
Creating an issue may seem like an added burden, but the long-term benefit of having context around a given piece of work prevents knowledge gaps from occurring. Issue templates exist to make the process of creating issues easier. If you find yourself starting similar issues over and over, look through existing issue templates. If a suitable one does not exist, consider creating one in the appropriate repository.
For more on how to make beautiful templates, check out GitLab's Markdown Guide. To add an emoji in an issue, begin by typing : and the title of the emoji. A list of emoji markup is here.
Remember to always add Related Issues and Epics after you've created your issue so others have context on what issues connect to this work.
general-project-template in a newly-created Corporate Marketing Issue. This template is pre-populated and beautified with emojis and descriptors for common sub-sections such as Background, Details and reach, Goals and key messages, and Due dates, DRI(s) and next steps/to-dos.Below are some tips on being a better presenter. For an in-depth book that covers the entire speaking process, from submitting an abstract through preparing a structured talk to practicing and delivering read Demystifying Public Speaking.
In an effort to grow our engagement and connectivity with our community, we're pleased to offer a SPIFF incentive for our Sales (Sal's, TAM's, SA's, Professional Services), and Support Teams teams to get customers involved in speaking at any GitLab Commit Event.
For ideas to help customers get their submissions accepted, see How to Get Your Presentation Accepted (video) or schedule a chat with a Technical Evangelism team member.
For event execution instructions, please see the Marketing Events page for detail instruction and the criteria used to determine what type of events are supported.
All swag requests, creation and vendor selection is handled by the Corporate Marketing team.
If you would like to get some GitLab swag for your team or event, email your request to sponsorships@gitlab.com (managed by the community advocacy team).
In your request include:
The swag we have available can be found on our online store. Note: It is recommended submit your request for swag at least 4 weeks in advance from the event date or we may not be able to accommodate your request.
sponsorships@gitlab.com. Include the date needed, shipping address and items / volume desired. The request will be approved on the back end by the community team. All requests must be made 3 or more weeks out. You can expect a response within 5 business days.events@gitlab.com if you would like to borrow this setup. You will be shipped this set along with a return label.dsumenkovic@gitlab.com. Include address, date needed and order quantity in request.events@gitlab.com with your concerns.events@gitlab.com.events@gitlab.com or find the FexEx account number in 1password to create a return label. Returns are only recommended if you have a very large number of items (50+) or a booth setup (banner, tablecloth, backdrop) that need to be returned.Orders placed for customers via the Printfection link are subject to change based on inventory availability and cost.
We have GitLab stationary/ note cards- leave note in swag Slack channel of you would like a batch to send notes to use to send to prospects/ customers/ community members.
#swag Slack channel.Corporate handles the creating and ordering of all new swag. All swag designs should be run past design (Luke) for approval before going to production.
Please consult the Social Marketing Handbook.
The mission of GitLab’s All-Remote Marketing team is to champion the company’s all-remote culture and initiatives. This involves close collaboration with corporate marketing (PR, corporate events), people group (employment branding) and Diversity & Inclusion.
The audience we aim to reach with our all-remote initiatives is both internal and external to GitLab. It closely aligns with our employment branding audience, and expands to cover key segments in the investor and business communities.
As detailed in GitLab’s public CMO OKRs, GitLab’s All-Remote Marketing team seeks to elevate the profile of GitLab in the media and investor circles, positioning it as a pioneer of remote work. It will spread the story of GitLab’s global remote employees, remote work processes, transparent culture and the movement to remote work that GitLab has created. It also seeks to position GitLab as an innovator in the eyes of investors, a vital part of GitLab’s public ambition to become a public company.
The team's primary home for publishing informational guides and content is the all-remote section of GitLab's handbook. This will be the preeminent home to all-remote content, positioned for consumption by media, investors, prospective customers and candidates.
We are actively working on a GitLab template for GitLab team members to submit stories, photos, videos, etc. for inclusion in the aforementioned web destination. We will spotlight stories unique to GitLab's all-remote culture. Examples include:
In the interim, GitLab team members wishing to share their remote stories can reach out to @dmurph.
All-remote events should elevate GitLab as a thought leader in the remote work space, create new partnerships, generate leads and generate media interest/coverage. We will consider physical events, virtual events and events that combine an in-person presence with a livestream option.
We incorporate all-remote content on GitLab’s social media accounts, and are investigating a visual approach to new mediums that are aligned with culture and lifestyle stories.
We are working with employment branding to surface relevant all-remote stories from GitLab team members to recruiting channels and review sites, such as Glassdoor, LinkedIn and Comparably.
There are also a number of videos on GitLab's YouTube channel that relate to working here:
The mission of GitLab’s PR (public relations) team is to amplify GitLab's product, people and partner integrations in the media.
The audience we aim to reach is external press/media. This includes business, lifestyle, workplace, finance, and beyond, using mediums such as print, digital, video, events, podcasts, etc.
As detailed in GitLab’s public CMO OKRs, GitLab’s public relations team seeks to elevate the profile of GitLab in the media and investor circles, positioning it as a pioneer of remote work, increasing share of voice against competitors, and pulling through key messages in feature articles.
For external parties, please visit our Get In Touch page.
For GitLab team members, please use the #external-comms Slack channel.
If you would like to make a formalized announcement around a new product feature and capabilities, partner integration, significant milestone achieved, a new initiative, customer case study, inclusion in an analyst report, etc. through a press release or blog post, you can submit a request via an announcement issue template in the Corporate Marketing project. 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 PR 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 an optional blog post. The execution of a blog post will be determined by the blog editorial team on a case by case basis. If the editorial team agrees to have 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 Google) 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 blog editorial 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.
Note: If you are seeking feedback from customers or our community on a proposed change, our recommendation is to do so using a public issue on GitLab. See the blog handbook for more information.
Speaking to media or on a podcast as a GitLab team member is a significant responsibility. If you are unsure whether or not you should accept a speaking opportunity or provide comment representing GitLab to a member of the media, please see below for guidance.
If you are asked to speak on behalf of GitLab, consider reaching out to the PR and Technical Evangelist teams to ensure that the opportunity aligns with GitLab objectives. Inquiries should be initiated in the #external-comms Slack channel.
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 PR team in the #external-comms Slack channel.
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 PR team to review by posting in the #external-comms Slack channel. The PR team will ensure that the appropriate GitLab team member(s) review and approve in a timely manner.
Please consult the Social Marketing Handbook. 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.
