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.
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, 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.
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.
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 single application for the complete DevOps lifecycle. 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
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.
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 workdmark, as well as, the correct scale of the icon relative to the wordmark:
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 concise, containing no more than 4 words, and should not contain bold text. This is to keep thing 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 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.
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.
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):
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."
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.
We favor contractions ("can't," "didn't," "it's," "we're") to sound more human and less formal.
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
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.
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?"
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.
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.
When in doubt, use the "future" styling of a word. So, "internet" is not capitalized, "startup" is not hyphenated, etc.
How to spell and style commonly used words.
Use American spelling in your communications. Please consult this list of spelling differences.
If you would like to get some GitLab swag for your team or event, 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.
ATM a limited test group of SDR's have sendoso accounts and the ability to send physical swag, handwritten notes, and coffee giftcards. We are slowly adding new SDR users weekly and should have the whole SDR team on Sendoso accounts by end of Feb, 2019. If you have questions on what is appropriate to send review sending swag to customers parameters.
Coming soon (Q2): Swag send triggers. When a deal of a ceratin size is closed a swag package will ship on behalf of the AE. When a customer contract is up for a renewal another swag package will be triggered. Working to take any manual time spent on swag and building in paramaters.
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.
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.
All GitLab events must check at least drive two or more of the aims of our events below to be considered.
In addition, corporate events must meet:
Please review our events decision tree to ensure Corporate Marketing is the appropriate owner for an event. If it is not clear who should own an event based on the decision tree, please email events@gitlab.com.
We ask the following questions when assessing an event:
Each question is graded on a scale of 0-2. We then tally the scores and assign the event to a sponsorship tier.
| Criteria / Score | 0 | 1 | 2 | |—————-|—————|—————|—————-| | Thought Leadership | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | | Audience type | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | | Attendee interaction | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | | Location and Timing | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | | Event Relevance/ Strategy | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | | Brand Reach | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | | Opportunity size/ Potential ROI | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> | <ul><li>[ ] </li></ul> |
We ask these questions and use this scorecard to ensure that we're prioritizing the GitLab's brand and our community's best interests when we sponsor events.
If you have questions, you can always reach us by sending an e-mail to events@gitlab.com.
Event Participation Request template. The same should be done for Support team staffing. Open an issue in the support project requesting assistance.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.
Diversity, Conference, MeetUp, Speaking Engagement, Webinar, Community Event or GitLab Connect. Events cannot have more than one type. If more than one apply, choose the best. If you feel your event doesn’t fit in the below category, do not just manually add a type. Please reach out to events@gitlab.com to suggest a new type of event.NORAM, LATAM, EMEA, APAC, or Online- 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
- topic:
type:
date:
date_ends:
description:
location:
region:
social_tags:
event_url:
For featured events include:
featured:
background: background/image/src/here.png
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:
Steps to take to create the new page:
Data, then to events.ymlTo create the event specific page you need to add a subset of the following information:
contact: to distinguish a header title.form: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"
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:
