At GitLab, our mission is to make it so that everyone can contribute.
The Developer Relations team supports this mission by working with our community to ensure they receive support and recognition for contributing to GitLab. Contributing to GitLab can include blog posts, code, documentation, discussions on forums/social media, meetups, presentations, translations, UX design, and more. We also support educational institutions and open source projects to host their work on GitLab.
#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 emojis]
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.
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.