Gitlab hero border pattern left svg Gitlab hero border pattern right svg

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

How We Work

Project Management

There is an initiative underway to simplify Project Management across all of Marketing.

In the meantime, we have implemented a few practices to help us get organized:

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

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 the Blog Editorial Style Guide 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 complete DevOps platform, delivered as a single application. 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 mission & vision. 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

Adding 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:
---
layout: markdown_page
title: "Title of press release"
description: "short sentence overview of press release'
twitter_image: "/location/of/image.png"
twitter_creator: "@gitlab"
twitter_site: "@gitlab"
twitter_image_alt: "Celebrating GitLab's press release about xx with fun emojis"
---

description, twitter_image, and twitter_image_alt would be the three, net-new tags needed to be custom to every single release. twitter_creator and twitter_site would be static with the value "@gitlab".

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

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.

Design

Read more about our brand guidelines in the Brand and Digital Handbook.

Speakers

For GitLab Team-members Attending Events/ Speaking
Finding and Suggesting Speakers and Submitting to CFPs
Best practices for public speaking

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.

  1. Use a problem/solution format to tell a story. Many talks, especially tech talks, talk about what they built first and then what the result was. Flip this around and start with the why. Why did you need to take the action that you did? Talking about what problems you were encountering creates a narrative tension and people will listen intently to the talk because they want to hear the solution.
  2. Drive towards an action. Ask yourself, "What will people do once they hear this talk?" The answer can't be, "be more aware of this topic." By deciding what action you expect the audience to take you can build your talk to drive towards this action. Talks that motivate the audience to action are more engaging and memorable than talks that simply describe. Some good example answers are
    1. Contribute to an open source project.
    2. Implement the technology or process you've come up with
    3. Follow the best practices you've outlined
  3. Practice how you play. Practicing your talk is key to being a great presenter. As much as possible, practice exactly how you plan to give the talk. Sand up and pretend you are on stage rather than sitting down. If you'll demo, build the demo first and practice the demo. Even practicing while wearing the outfit you plan to wear can help.
  4. Give concrete examples. Real life details bring a talk to life. Examples help people to understand and internalize the concepts you present. For each of your points try to have a "for instance." As an example, "We recommend using this script to delete old logs and free up diskspace. For instance, one time our emails lit up as users were complaining about slow performance. Some were reporting tasks hanging for over an hour when they should have completed in less than a minute. It turned out we were out of diskspace because we had verbose logging enabled. Once we ran the script we saw performance return to normal levels."
  5. Be mindful of your body language when presenting as it will impact the way the audience perceives your presentation. Move around the stage purposefully (don't pace or fidget). Make natural gestures with your hands, and maintain good posture to convey confidence and openness which will help you to better connect with your audience.

Customer Speakers

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 to get customers involved in speaking.

SPIFF criteria- only applicable for Commit our user conference series

The SPIFF will payout for each customer speaker submission that has the following criteria met
Eligibility
Payout

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.

Corporate Events

Mission Statement

What does the corporate Events team handle?

Corporate Events Strategy / Goals

GitLab Commit User Conferences

Event Execution

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.

Best Practices on site at a GitLab event

Swag

Swag for Events - see details on Events page

All swag requests, creation and vendor selection is handled by the Corporate Marketing team.

Community & External Swag Requests

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.

Internal GitLab Swag Ordering:

Returning Swag to Warehouse

Swag for customer/ prospects

Deal Size, by License Suggested Order
50-100 2 shirts, up to 20 stickers
+100-250 5 shirts, 1 camper mug, up to 100 stickers
+250-500 2 shirts, up to 200 stickers
+500-1000 10 shirts, up to 250 stickers
+1000 1 hoodie or beanie, 20 shirts, 5 socks, max 500 stickers

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 (Luke) for approval before going to production.

Suggesting new items or designs

Social Marketing and Social Media

Please consult the Social Marketing Handbook.

All-Remote Marketing

Mission Statement

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 & Belonging .

Vision

GitLab is an influencer and educator in remote work. It serves the community by creating valuable content that furthers the proliferation and ubiquity of remote-first and all-remote organizations, while enhancing the operations of colocated and hybid-remote companies by sharing implementable remote-first practices.

We believe that the remote principles relied on by GitLab are applicable even to colocated companies, and educating on pillars such as asynchronous workflows and informal communication can benefit all organizations.

Evangelism materials

If you are asked by peers for more information on how GitLab thrives as an all-remote team, please see the below.

GitLab's Guide to Remote Work

If you're wondering where to start, direct people to a blog post — Resources for companies embracing remote work — which gives background and context, and lays out a logical flow of links for leaders and workers to follow as they learn.

We've built The Remote Playbook, a curated eBook with GitLab's top advice for companies transitioning to remote. This can be downloaded via a prompt on the all-remote homepage, accessible at http://allremote.info/

In scenarios where you need a quick link to vocalize, tweet, email, or otherwise share, we have established a memorable redirect: http://allremote.info/ ("All Remote Dot Info")

Why remote?

GitLab's overview video on its all-remote culture can be viewed here.

Presentations (slide deck)

You may be asked to give a presentation on how GitLab works as an all-remote team, including requests that are specific to your role (sales, engineering, finance, people, etc.).

In these instances, you're welcome to use this Google Slides presentation, Thriving as a Remote Team: A foundational toolkit. (This link is only viewable by GitLab team members.) A suggested script following this presentation is available for your use.

For a video of GitLab's Head of Remote walking through this presentation to a group of founders, click here. This presentation will serve as a guide to narrating the slides and connecting GitLab's approach to remote with the current reality of your audience.

Other slide decks are below.

Usage guidelines:

  1. Please make a copy of the presentation and script instead of overwriting the template.
  2. Swap out existing names/headshots for your own.
  3. Feel welcome to add a slide or two related to the specifics of the request.

Teaching other companies how to go remote

GitLab is unique in that every single team member is remote. All-remote is the common thread that we all share, regardless of what department we serve. This means that each GitLab team member is uniquely equipped to share best practices with other leaders and companies.

The requests may be varied, from small firms looking to unwind their office strategy and go all-remote, to multi-nationals which are looking to implement remote-first best practices to account for more of their team working outside of the office (or in different offices).

Regardless of the nuance in the request, here are the foundational areas that should be covered. Be sure to describe how GitLab implements these tactics using low-context communication, leaning on examples and detail such that a non-GitLab company can envision how such a tactic could be useful in their own organization.

  1. Set the stage. GitLab is the world's largest all-remote company, which is why our advice matters.
  2. Remote requires a different mindset. All the tools and processes in the world will falter if leadership doesn't lead with trust and transparency rather than micromanagement and fear.
  3. Lead with data. GitLab's Remote Work Report surveys thousands of global remote workers. As leaders and team members grapple with going remote, this report provides insights on what matters to those who adopt this way of working, charting a path for building culture around autonomy and flexibility.
  4. Remote-first practices aren't just for remote companies. Empathize with challenges. Offer up common issues that teams who are going remote will face. Although GitLab is all-remote, we should make clear that our advice applies to colocated companies and hybrid-remote companies as well.
  5. How do I manage a remote team?
    • What tools do we need?
    • How much communication is too much?
    • What is in charge of our remote transition?
  6. Guidance is about the here-and-now, but approach this for the long-term.
    • Recognize that companies forced into work-from-home need communication gaps filled now.
    • The reason to do this with intention is that it will become a core part of a company's talent and operational strategy.
    • Remote de-risks a company, making it less susceptiable to socioeconomic swings and crises.
  7. Three biggest challenges!
    • Workspace challenges and work/life separation.
    • Communications in a remote world, and keeping everyone engaged/informed.
    • Mindset and culture, leaning into the reality that change takes time, and a focus on iteration.
  8. How does GitLab do it?!
    • This is your moment to showcase specific examples of how GitLab does things differently. If you are addressing an department-specific audience (sales, engineering, HR, finance, etc.), surface examples germane to that audience.
    • Feel welcome to share that GitLab uses GitLab. It's a tool built by an all-remote team to enable remote practices such as asynchronous workflows and prevent typical challenges such as communication silos.
    • Share our GitLab for remote teams solutions page.
    • Prepare for minds to be blown. These things feel like second nature to GitLab team members, but are revolutionary to most.
  9. You must have a single source of truth
    • It's not about blanket documentation. It's about working handbook-first.
    • Start now! Designate a scribe if you have to. Start small, as an FAQ, and build it out.
    • Show an example of a handbook page — a great example is our Communication page.
  10. Asynchronous over synchronous
    • Explain how GitLab requires each meeting to have an agenda and someone documenting.
    • Explain how meeting takeaways then need to be contextualized and added to relevant handbook pages.
    • Explain how this added burden on meeting is a forcing-function to work first in GitLab, and rely on a meeting as a last resort.
  11. "OK, but where do we start?"
    • Start small, don't be overwhelmed. Get your executives out of the office and have EA's document the communication gaps that emerge. (Hint: That's your priority list of what voids to fill.)
    • Establish a team responsible for communication. Everything that comes next requires clear, frequent, transparent communication and an understanding of where to communicate and who are the DRIs for various functions.
    • Provide a feedback mechanism. It's impossible to know everything, so ask your team members what's missing in their remote approach. Prioritize those asks as you see themes forming.
    • Remind people that GitLab has two Getting Started guides: one for leaders/companies, another for workers.
  12. Minimize your tool Stack. The fewer moving pieces when transitioning to remote, the better.
  13. "But wait, I still need help!" Fret not! GitLab's entire library of remote guides are available at http://allremote.info/ ("All Remote Dot Info")

In case you as a subject matter expert are invited to write an Unfiltered blog post or create other written content, please feel free to make a copy of the "Going remote in __" blog post template and tailor based on your audience.

How do I talk about remote?

If you're looking for examples of the GitLab team describing our experience with remote work, have a listen at the podcasts below.

Social media assets and guidelines

This is the issue to get everything you need in order to evangelize remote work on your social media accounts. It includes:

How does a company create their own handbook?

Learn more in GitLab's Handbook-First Documentation guide about how GitLab (the company) uses GitLab (the product) to build and maintain its handbook, as well as tools and tips for other companies who wish to start their own.

All-remote guide creation

GitLab's growing library of remote guides is designed to be bolstered by new pages. Below is an overview of the process for adding a new guide.

  1. Check this GitLab Issue to ensure that your proposed guide isn't already being scheduled
  2. If it's a net-new idea, please put each new guide idea/topic in a new issue within Corporate Marketing
  3. Put Proposal: [NEW ALL-REMOTE GUIDE] as the subject
  4. Add the label mktg-status::triage
  5. Assign to @dmurph to evaluate and provide feedback

What's the difference between an all-remote guide and a traditional GitLab handbook page?

See below for an A/B comparison of how an inward-facing GitLab handbook page is written vs. an external-facing all-remote guide is written.

Design and illustration assets

GitLab's Brand and Digital Design team are building out images and illustrations to visualize all-remote.

The Google Drive repository is here, which is home to all-remote photography, presentation decks, animations, banners, illustrations, iconography, e-books, social graphics, and more. (Note: The Google Drive folder is private to those within the GitLab organization.)

Approvals

Any GitLab team member is welcome to offer 1:1 advice or consultations on remote work. If you're asked to give a broader presentation or webinar to a group, private or public, please create a new issue in Corporate Marketing per the instructions in How To Contribute with details of the request.

An example of these details in an issue can be found here.

Once created, please tag @jessicareeder in a comment with a note that includes Seeking Approval.

The all-remote team will be available to help direct if you feel unprepared, or pair the creator of the issue with someone else on the GitLab team if there's opportunity to add another layer of expertise (e.g. a DevOps expert, an HR expert, a Finance expert) depending on the company that's requesting.

Other assets

GitLab Remote Work Report

GitLab's Remote Work Report sheds light on the current reality of remote work during a critical time in its global adoption. As leaders and team members grapple with going remote, this report provides insights on what matters to those who adopt this way of working, charting a path for building culture around autonomy and flexibility.

For example, 86% of respondents believe remote work is the future and 62% of respondents said that they would consider leaving a co-located company for a remote role. Contrary to popular belief, we found that most remote workers aren't digital nomads, and 52% are actually likely to travel less than their office working counterparts.

Remote Work playlist on GitLab Unfiltered

GitLab is a very transparent company. As such, our AMAs, webinars, and other conversations with team members and other companies are uploaded to a dedicated Remote Work playlist on the GitLab Unfiltered YouTube channel.

Universal Remote webcast playlist on GitLab YouTube channel

Universal Remote is GitLab's weekly web show focused on helping teams transition to a fully remote world. The running playlist of episodes can be found on GitLab's YouTube channel.

All-Remote on the GitLab blog

All-Remote Initiatives Parent Epic

This parent epic houses all corporate marketing campaigns, projects, child epics, and issues related to all-remote initiatives.

Our audience

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.

Key Messages for All-Remote

GitLab: The Remote Strategy

Best practices for managing teams and communications remotely

Managing your team

Communication

Connecting to GitLab's values of iteration and transparency

Iteration

Transparency

Objectives and goals

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.

Channels

Web

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.

Video

GitLab is a very transparent company. As such, our remote-centric AMAs, webinars, and other conversations with team members and other companies are uploaded to a dedicated Remote Work playlist on the GitLab Unfiltered YouTube channel.

Events, panels, keynotes and webinars

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 believe that all-remote is for everyone, and that almost every company is already a remote company. This includes all company sizes, from solo enterprises to multi-nationals, and geographies. Our event strategy should reflect this, offering education, insights, and actionable advice that applies to a wide spectrum of remote companies.

Events should create an inclusive atmosphere, welcoming and beneficial to those who are not receptive to remote or are working in a company where remote is not feasible/acceptable.

Social media

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:

Remote Work Report

Beginning in 2020, GitLab is sharing important data that quantifies the state of remote work globally via the Remote Work Report.

How to contribute

To contribute an idea or proposal to further GitLab's all-remote mission:

  1. Please put each new idea/topic in a new issue within Corporate Marketing
  2. Put Proposal: [IDEA] as the subject
  3. Add the label mktg-status::triage
  4. Tag @echin and @jessicareeder

All-Remote content calendar

The All-Remote content calendar is hosted on Google Calendar. It's used to keep track of what is being released (and when), including the following.

For GitLab team members who need edit access or wish to add their own content to this calendar, please contact @jessicareeder in the public #all-remote_action Slack channel.

Corporate Communications and PR (Public Relations)

Mission Statement

The mission of GitLab’s Corporate Communications team is to amplify GitLab's product, people and partner integrations in the media. This team is responsible for global PR (public relations).

Our audience

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.

GitLab Master Messaging Document

GitLab's corporate communications team is the DRI (directly responsible individual) for the GitLab Master Messaging Document. If this document is needed, please request access in the #external-comms Slack channel.

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 investor circles, positioning it as a pioneer of remote work, increasing share of voice against competitors, and pulling through key messages in feature articles.

Contacting GitLab's PR team

For external parties, please visit our Get In Touch page.

For GitLab team members, please use the #external-comms Slack channel and please follow the Communication Activation Tree.

Requests for Announcements

This process allows us to decide on the best channel to communicate different types of updates and news to our users, customers, and community.

Please follow the instructions below to request a formalized announcement around any of the following:

Please submit a request via an announcement issue template in the Corporate Marketing project before opening an issue for a blog post, for example. In the issue template, you will be able to provide additional information on the proposed announcement. As a general guide, below the team has outlined three levels for announcements based on the type of announcements and suggested communications activities associated with each tier. The 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.

Using public issues to communicate with users

In some cases it may be more appropriate and efficient to communicate with users in a public issue. Below are some examples of the types of communications that may suit an issue as opposed to a blog post, press release, or email, for example:

Using a public issue has a few advantages:

Creating your communication issue

Below are some examples of using an issue to communicate something with our audience. Feel free to use these as a template for your issue. See below PR review and media guidelines section for more details on the review process.

At a minimum, your issue should:

Promoting your public issue

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

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

PR review and media guidelines

Speaking on behalf of GitLab via a public channel such as a media interview (in-person or via phone), a podcast, a public issue on GitLab, a forum, a conference/event (live or virtual), a blog or an external platform is a significant responsibility. 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 comment representing GitLab to a member of the media or influencer, please see below for guidance.

Speaking opportunities

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.

Media mentions and 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 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.

Public GitLab Issues

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

Social media

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.

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. If you would like someone to check your draft before submitting, you can share it with the PR team who will be happy to review. Please post it in the #external-comms Slack channel with a short summary of what your blog post is about.

GIT is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
Edit this page — open Web IDE — please contribute. Creative Commons License