Corporate Marketing

  1. You are here:
  2. Handbook
  3. Marketing
  4. Corporate Marketing

Welcome to the Corporate Marketing Handbook

The Corporate Marketing team includes Content Marketing, Corporate Events, PR, 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.

On this page

Brand personality

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.

  1. Human: We write like we talk. We avoid buzzwords and jargon, and instead communicate simply, clearly, and sincerely. We treat people with kindness.
  2. Competent: We are highly accomplished, and we communicate with conviction. We are efficient at everything we do.
  3. Quirky: We embrace diversity of opinion. We embrace new ideas based on their merit, even if they defy commonly held norms.
  4. Humble: We care about helping those around us achieve great things more than we care about our personal accomplishments.

These four characteristics work together to form a personality that is authentic to GitLab team members, communioty, 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.

Style guide and tone of voice

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 General editorial style guidelines for more.

About

GitLab the community

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 the company

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 the product

GitLab is a single application for the complete DevOps lifecycle. See the product elevator pitch for additional messaging.

Tone of voice

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.

Updating the press page

Updating the /press/releases page

  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

layout: markdown title: "Title of press release" —

  1. Add the content of the press release to the file and save. Make sure to include any links.

Updating the recent news section

  1. Every Friday the PR agency will send a digest of top articles
  2. Product marketing will update the 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.
  3. Move older content to the archive.

Design

Requesting design help

  1. Create an issue in the corresponding project repository
    1. For tasks pertaining to about.gitlab.com create an issue in the www-gitlab-com project.
    2. For all other marketing related tasks create an issue in the marketing project.
  2. Add all relevant details, goal(s), purpose, resources, and links in the issue description. Also @ mention team members who will be involved.
  3. Set due date (if possible) — please leave at least 2 week lead time in order to generate custom design assets. If you need them sooner, ping @luke in the #marketing-design slack channel and we will make our best effort to accommodate, but can't promise delivery.
  4. Add the Design and Website Redesign (if applicable) label(s) to your issue.

The Design label in issue tracker

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

Project prioritization

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 marketing project prioritization, you can view the Design Issue Board. More specifically the Design - Working On and Design - Top Priority lists.

Design projects within the www-gitlab-com project can be tracked using the Design 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.

Design touchpoints

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:

Web & Digital

Field Design & Branding

Content Design

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

Brand Guidelines

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.

Logo safe space

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:

Logo safe space

Logo safe space

The x-height also determines the proper spacing between icon and workdmark, as well as, the correct scale of the icon relative to the wordmark:

Logo safe space

The Tanuki

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 trademark & logo guidelines

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:

Using other logos

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.

Colors

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.

Hex/RGB

GitLab Hex/RGB Colors

Typography

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

Buttons are an important facet to any design system. Buttons define a call to action that lead people somewhere related to the content it's contained in. There are common practices and data that prove certain types of buttons work better for conversion than others. Here are buttons and their classes that should be used throughout the marketing website:

Primary buttons

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.

Primary Button 1 
.btn.cta-btn.orange

OR

Primary Button 2 
.btn.cta-btn.purple

Secondary Buttons

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:

Primary Button Secondary Button
Primary Button Secondary Button

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:

Secondary Button 1 
.btn.cta-btn.ghost-orange
Secondary Button 2 
.btn.cta-btn.ghost-purple

Iconography

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

Label icons are intended to support usability and interaction. These are found in interactive elements of the website such as navigation and toggles.

Label icons example

Content icons

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.

Brand oversight

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!

GitLab Product UX Guide

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.

GitLab Product UX Design Pattern Library

We've broken out the GitLab interface into a set of atomic pieces to form this design pattern library. This library allows us to see all of our patterns in one place and to build consistently across our entire product.

Design System

Brand resources

Asset libraries

Icons

Icon patterns

Social media

Templates

Presentation decks

General editorial style guidelines

We use American English by default and follow the AP Style guide unless otherwise noted in this style guide. We do not use title case.

Abbreviations

Acronyms

When using acryonyms or initialisms, ensure that your first mention uses the full term and includes the shortened version in parentheses directly afterwards. From then on you may use the acronym or initialism instead.

Example: A Contributor License Agreement (CLA) is the industry standard for open source contributions to other projects.

Below are some common acroynms and initialisms we use which don't need to be defined first (but use sparingly, see Tone of voice above):

Ampersands

Use ampersands only where they are part of a company's name or the title of a publication or similar. Example: Barnes & Noble

Do not use as a substitute for "and."

Capitalization

Use sentence case for all titles and headings.

All GitLab feature names must be capitalized. Examples: GitLab Issue Boards, GitLab Pages.

See below for styling of specific words.

Contractions

We favor contractions ("can't," "didn't," "it's," "we're") to sound more human and less formal.

Formatting

Lists

Numbers

Spell out one to nine. Use numerals for 10 upwards. Try to avoid beginning a sentence with a number, but if unavoidable, spell it out.

Numbers with four or more digits should include a comma. Examples: 2,000; 100,000

Punctuation

Only one space after a period is necessary.

Include one space after ellipses (… )

See below for when to hyphenate specific words.

We use en dashes (–) rather than em dashes (—). Include a space before and after the dash.

Quotes

Quotation marks

Use double quotation marks for direct quotes, and single quotation marks for a quote within a quote. Single quotation marks may also be used for specialist terms or sayings.

Include punctuation in quotation marks.

Example: What do you think of the claim, "software is eating the world?"

Tense

When including direct quotations from interviewees in blog posts, we prefer to use the feature journalism style of present tense for verbs such as "said," "explained" etc.

Example: "Ruby was optimized for the developer, not for running it in production," says Sid.

Referring to interviewees

For blog posts, prefer referring to interviewees by their first names as this is less formal and more in keeping with our tone of voice.

Word choice

When in doubt, use the "future" styling of a word. So, "internet" is not capitalized, "startup" is not hyphenated, etc.

Word list

How to spell and style commonly used words.

Appendix A: When to use en dashes and semicolons

Appendix B: UK vs. American English

Use American spelling in your communications. Please consult this list of spelling differences.

Swag

Community/ External Swag Requests:

Email your request to sponsorships@gitlab.com (managed by community advocacy team). In your request please include the expected number of guests, the best shipping address, and phone number along with what kind of swag you are hoping for. The swag we have available can be found on our online store. Note: We recommend you request swag at least 4 weeks out from the event date or we may not be able to accommodate your request.

Internal GitLab swag ordering:

Returning Swag to Warehouse

Swag for customer/ prospects

Anyone with access to Salesforce can send swag through Salesforce directly. Please review sending swag to customers parameters. Instructions on how to do so below:

  1. Create general task for whichever contact you want to send swag to. You need to create a task and save it before the "order swag" button will show up as an option in the task menu.
  2. Go into created and saved task and click the button that says "order swag".
  3. If you do not see the window pop up for ordering, please check your pop up settings and verify pop ups are not being blocked.
  4. Previous step will bring up a printfrection page where you can order desired swag. (please note not all swag is listed in sfdc, for more options email emily@gitlab.com).

Swag Providers We Use

New and Replenishment Swag Orders

Corporate handles the creating and ordering of all new swag. All swag designs should be run past design for approval before going to production.

Suggesting New Items or Designs

Speakers

For GitLabbers Attending Events/ Speaking
Finding and Suggesting Speakers and Submitting to CFPs

Corporate Events

Goals

How to add events to the about.gitlab.com/events page

In an effort to publicly share where people can find GitLab at events in person throughout the world, we have created about.gitlab.com/events. This page is to be updated by the person responsible for the event. To update the page, you will need to contribute to the event master.yml. If you need more information about our exact involment in an specific event please visit the marketing project in gitlab.com and search the name of the event for any realted issues. The "Meta" issue should include the most thorough and high level details about each event we are participating in.

Details to be included (all of which are mandatory in order for your MR to pass the build):

Example

- topic: The Best DevOps Conference Ever
  type: Conference
  date: January 1, 2050
  date_ends: January 3, 2050 # Month DD, YYYY
  description: |
               The Best DevOps Conference Ever brings together the best minds in the DevOps land. The conference consists of 3 full days of DevOps magic, literally magic. Attendees will have the opportunity to partake in fire talks and moderated sessions. This is one you won’t want to miss.
  location: Neverland, NVR
  region: APAC
  social_tags: DEVOPS4LIFE
  event_url: https://2050.bestdevops.org

Template

- topic:
  type:
  date:
  date_ends:
  description:
  location:
  region:
  social_tags:
  event_url:

How to add an event specific landing page linking from the about.gitlab.com/events page

At times, we will want to create an event specific page that links from the about.gitlab.com/events page. The purpose of this page is to let people know additional details about GitLab’s presence at the event, how to get in touch with us at the event, and conference sessions we are speaking in (if applicable).

Ops Steps needed before page can lunch:

  1. Create an issue in the general marketing project using the Event Landing Page Ops template. Ops needs the following info:
    1. Who will be at the live event taking meetings. This person will also need to be setup in Outreach.
    2. Meeting time and dates open for meeting scheduling, plus default meeting duration
    3. Copy for invite flow- this is what customer will see once they set meeting.

Steps to take to create the new page:

  1. Create new a new branch of the www-gitlab-com project.. - Branch name should be what event you’ve added.
  2. From new Branch, navigate to Data, then to events.yml
  3. Scroll down to the area where its date appropriate to add the event
  4. Add event using instructions in handbook

  5. To create the event specific page you need to add a subset of the following information:

    • url: - you make this up based on what you want the URL to be from about.gitlab.com
    • header_background: choose from an image already in the images folder or add your own image. If you do not know how to do this, please watch this tutorial.
    • header_image: choose from an image already in the images folder or add your own. (optional- if you prefer not to include, remove field altogether)
    • header_description: what CTA would you like the person to do on the page
    • booth: booth number at event, if there is no booth number, then remove this line of code (optional)
    • form: code that tells the system to add the contact info form. Marketing Ops will provide you with this number. They need to create a specific form for each page associated with a campaign in sfc.
    • title: CTA for why someone would want to give their contact info. Also used in contact: to distinguish a header title.
    • description: additional info on why someone would want to give their contact info
    • number: Marketo form number - Marketing Operations will need to give this number to you. Under form:
    • content: all of the information in the example section is all optional based on your event. If its not needed, simply delete.
  6. Please watch this tutorial for additional help.

Example

Giving the following data will give this event it's own dedicated page on about.gitlab.com, must provide a unique url.
  If it is text, it needs to be wrapped in "double quotes". This is so you can use characters like : and ' without breaking anything.

  url: aws-reinvent
  header_background: /images/blogimages/gitlab-at-vue-conf/cover_image.jpg
  header_image: /images/events/aws-reinvent.svg
  header_description: "Drop by our booth or schedule a time, we'd love to chat!"
  booth: 2608
  form:
      title: "Schedule time to chat"
      description: "Learn more about how GitLab can simplify toolchain complexity and speeds up cycle times."
      number: 1592
  content:
    - title: "How to can get started with GitLab and AWS"
      list_links:
        - text: "Simple Deployment to Amazon EKS"
          link: "/2018/06/06/eks-gitlab-integration/"
        - text: "GitLab + Amazon Web Services"
          link: "/solutions/aws/"
        - text: "Top Five Cloud Trends"
          link: "/2018/08/02/top-five-cloud-trends/"
        - text: "How Jaguar Land Rover embraced CI to speed up their software lifecycle"
          link: "/2018/07/23/chris-hill-devops-enterprise-summit-talk/"
    - title: "Let's Meet!"
      body: "Join us for a live demo on getting started with Auto DevOps on Nov 28th at 1pm to learn how Auto DevOps simplifies your deployment pipeline to accelerate delivery by 200%, improves responsiveness, and closes the feedback gap between you and your users."
  speakers:
    - name: "Josh Lambert"
      title: "Senior Product Manger, Monitor"
      image: /images/team/joshua.jpg
      date: "Tuesday, Nov 28"
      time: "1:00pm PT"
      location: "Booth 2608 at the expo floor in the Venitian"
      topic: "GitLab CI 101"
      description: "In this talk, we will review how simple it is to get started with GitLab's built in CI tool."
    - name: "Reb"
      title: "Solutions Architect"
      image: /images/team/reb.jpg
      date: "Tuesday, Nov 27"
      time: "2:00pm PT"
      location: "Booth 2608"

Template

Giving the following data will give this event it's own dedicated page on about.gitlab.com, must provide a unique url. If it is text, it needs to be wrapped in "double quotes". This is so you can use characters like : and ' without breaking anything.

  url:
  header_background:
  header_image:
  header_description:
  booth:
  form:
      title:
      description:
      number:
  content:
    - title:
      list_links:
        - text:
          link:
        - text:
          link:
        - text:
          link:
    - title:
      body:
  speakers:
    - name:
      title:
      image:
      date:
      time:
      location:
      topic:
      description:
    - name:
      title:
      image:
      date:
      time:
      location:
Edit this page — please contribute. Creative Commons License