Developer Relations drives platform awareness and adoption by reaching deep into wider communities and engaging developers where they are. GitLab currently engages with more than 3000 developers every month on GitLab.com alone, and receives more than 250 contributions every month, giving us a unique level of influence in the DevSecOps space and helping accelerate our innovation. Our ultimate goal is to raise awareness of GitLab and drive customer success by winning the hearts & minds of developers through best-in-class technical enablement and an active community of contributors.
In Developer Relations, we align our mission and vision with the company's three year strategy. We believe that everyone can contribute. To help GitLab reach this goal, we aim to double outreach and engagement, strengthen our community presence, secure a healthy contributor base of 1,000 by the end of FY25. Ultimately, these goals help boost platform adoption and GitLab revenue. We aspire to be recognized as thought leaders and key influencers across technical communities. Developer Relations takes developers from awareness to consideration, learning, and adoption. Moreover, Developer Relations is critical in establishing GitLab as the industry leader and platform of choice: more than 85% of developers either make purchase decisions or have a strong influence on technical decisions on platforms and tools (Source: Evans Data, Cloud Development Survey 2019).
Our operational strategy is documented in our internal handbook but is classified as confidential due to business sensitivity, customer impact and to foster a psychological safe environment for our team members. Below you can find our strategic plans that are open to the wider community and where the Developer Relations team welcomes collaboration.
#developer-relations Slack channel, or by tagging the @community-teamTeams within Developer Relations are reachable in these Slack channels:
#incident-management, #infrastructure-loungeIf you are working on changes to the company, product, or pricing that are expected to have a meaningful impact on members of the wider GitLab community or the GitLab brand, we encourage you to use the label ~Community Interest so that the Developer Relations team can represent the interests of the wider GitLab community in the planning process.
All members of the Developer Relations team should be subscribed to this label in both the gitlab-com and gitlab-org projects.
Our team has a few weekly events that we use to stay connected and aligned on our work:
We host a Group conversation for the benefit of other team members. When posting to the What's happening at GitLab Slack to announce a Group Conversation, use the following format to create an engaging and entertaining post.
[Intro with emoji]
Please join me on [Day, 202X-XX-XX, time] for the :community: Developer Relations Group Conversation!
:flashlight: We plan on highlighting:
- [list of highlights]
:google_slides: Check out the [slides link] to learn what we've been up to.
:google_docs: Please add questions to the [ agenda doc link] ahead of time so we can jump right in. :ninja_turtle_jumping_yay:
[outro with call to action to join and some more emoji]
See you then!
We use team-wide calendars for collective notification and to manage team logistics and events. Additionally, specific teams within Developer Relations may maintain calendars specific to their programs (such as the Developer Evangelism calendar).
Every quarter, we work on team Objectives and Key Results (OKRs) that align with company OKRs.
OKRs we seek to align with:
To update our list of current OKRs:
gitlab-com project. The naming convention we use for OKRs is: FY-Year-Quarter OKR: Description of OKRopen source program education program etc).Developer Relations label.OKR label.Issue Health: We use issue health indicators to help people understand an OKRs status at a glance. These status indicators are:
on trackneeds attentionat riskThe Developer Relations team monitors several Key Performance Indicators and related Performance Indicators.
GitLab Developer Relations team logos can be found in .png and .svg formats by searching for gitlab-devrel-logo in Google Drive.
Learn more on the Developer Relations budget page
In alignment with GitLab's core value of Diversity, Inclusion, and Belonging (DIB), the Developer Relations team seeks to purposefully design DIB into every facet of its programs and operations. We seek to foster DIB at GitLab and within the wider GitLab community.
This section is meant to document tips and best practices that the Developer Relations team, and GitLab team, should keep in mind as they plan events and activities.
We take inspiration from the great work being done by other communities. Some of the communities who we take inspiration from:
The Community Learning Pathway is a course built to educate the community on how the Developer Relations team works, the different community programs and how to contribute the GitLab. Members of the Community and GitLab team members who complete the course will earn a badge.
The Community Building Reading Group is for GitLab team members interested or engaged in building communities at GitLab. Hosted by members of the Developer Relations team, this learning-focused group examines various principles and practices related to imagining, designing, building, nurturing, growing, and supporting communities. Potential topics of study and discussion include:
By collaborating as part of this group, members aim to:
Any GitLab team member interested in community building practices is welcome to participate in and contribute to the group. Unlike typical GitLab book clubs, this reading group:
The reading group operates on a cadence group members determine together. Group members also collectively determine the material—for example, a book chapter, a white paper, a research report, a presentation recording, or a case study—they'll cover each week.
Community Building project using the reading-group template, then attaching the Reading Group::Proposed label to it.Reading Group::Up Next.Reading Group::Now Reading label.Reading Group::Finished label to the associated issue. A project board tracks all selections.As they read, group members share notes and impressions asynchronously via files stored in the Community Building project. When they have completed a selection, they polish these notes and update the Community Building wiki accordingly.
Each cycle, a group member (typically the person who proposed the materials) acts as "leader." Group leaders pose some basic discussion questions or thought-generating insights to guide the group's reading and frame its discussion. Group members meet at regular intervals for live, synchronous discussion of the reading materials (suggested time for discussion meetings: 45 minutes). Recordings of these meetings are available, but because discussions often contain personal details and sensitive issues, these recordings are only access to GitLab team members via an internal Google Drive.