Developer Relations

The Developer Relations team supports GitLab’s mission by working with our community to ensure they receive support and recognition for contributing to GitLab.

Welcome to the GitLab Developer Relations Handbook

What is DevRel?

Developer Relations (short: DevRel) operates at the intersection of technology, community, and advocacy, serving as the voice and ears of GitLab in the wider tech world. Their core mission revolves around nurturing and sustaining a vibrant, engaged community of developers, contributors, and users. This involves a multifaceted approach that includes creating educational content, organizing events and workshops, developing programs, and providing platforms for knowledge exchange and collaboration. The team not only focuses on promoting GitLab’s features and capabilities but also actively listens to and incorporates feedback from the community to inform product development and improvements.

Our mission & vision

Developer Relations drives platform awareness and adoption by enabling GitLab customers, connecting through community, and engaging developers where they are. GitLab 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, and support a healthy community of contributors. Ultimately, these goals boost awareness, adoption, and power our dual flywheels.

Our Strategy

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.

Meet the Team

Name	Role
Arianna Haradon	Senior Fullstack Engineer
Cesar Saavedra	Senior Developer Advocate
Daniel Helfand	Developer Advocate
Daniel Murphy	Senior Program Manager, Contributor Success
Emilio Salvador	VP, Dev Relations and Community
Fatima Sarah Khalid	Developer Advocate
Fernando Diaz	Senior Developer Advocate
Itzik Gan-Baruch	Sr. Developer Advocate, Product Management internship
Jana Sena	Senior Developer Relations Program Manager
John Coghlan	Director, Developer Advocacy
Lee Tickett	Fullstack Engineer, Contributor Success Core Team member
Michael Friedrich	Staff Developer Advocate
Nick Veenhof	Director, Contributor Success
Raimund Hook	Staff Fullstack Engineer, Contributor Success
Rostyslav Safonov	Fullstack Engineer, Contributor Success
William Arias	Senior Developer Advocate

How to reach us

Chat with us

Developer Relations team members use three Slack channels:
- #developer-relations: for all GitLab-related discussion (ex: questions about an issue, announcement of an upcoming event)
- #developer-relations-hangout: for all social discussion and updates shared via the Community Catch bot (ex: plumbing problems, weekend plans)
- developer-relations-confidential: (private) for discussion of confidential topics that cannot be shared in a channel with people from outside GitLab (ex: discussing a topic that was shared in #company-fyi-private among our team)
GitLab team members and others with Slack access can reach us by visiting the #developer-relations Slack channel, or by tagging the @devrel-team group handle.
Members of the wider GitLab community can connect with us in the public Discord rooms

Teams within Developer Relations are reachable in these Slack channels:

#dev-advocacy-team: the Developer Advocate team shares content updates, thought leadership & product ideas, and support community responses, CFPs, etc.
#community-programs: for all inquiries regarding GitLab Community Programs (EDU/OSS/Startups)
#contributor-success: for all inquiries regarding Contributor Success

Email us

Please use the e-mail address specific to each program

File an issue

File an issue to work with us: See our project management section to find program-specific workboards where you can file an issue

Emergency contact

Developer Relations emergency contacts
Incident management roles
Relevant Slack channels for incident/infrastructure: #incidents, #infrastructure-lounge

How we work

Developer Relations Team resources

Our handbooks

Our workflows

Community engagement:

Community platforms:

Content:

Organization:

Community Interest

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

Team touchpoints

Our team has a few weekly events that we use to stay connected and aligned on our work:

Team meeting (bi-weekly)
- Team meetings are recorded via Zoom and recordings linked to the corresponding date in the meeting notes.
1:1 meeting between each team member and their manager.
Question check-in via Geekbot in Slack for each team member. The responses are shared in the #developer-relations-hangout Slack channel.
- Monday (weekend social, plans for the week)
- Thursday (reminder to share achievements, thoughts, blockers, etc.)
End of week updates: Results and wins, search for Developer Relations - End of Week updates in Google drive.

Our calendars

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 Advocacy team calendar).

Developer Relations OKRs

Every quarter, we work on team Objectives and Key Results (OKRs) that align with company OKRs.

OKRs we seek to align with:

DRI Responsibilities

For each quarterly objective and key results, the Developer Relations team will assign a DRI. For our team, we have responsibilities that build upon the GitLab guidance on achieving and updating. Typically, People managers are the DRIs for objectives while ICs are the DRIs for key results.

Objective DRI Responsibilities
- Own strategy for achieving objectives including supporting the DRIs for key results that will help to achieve our objectives.
- Collaborate with the owners of the key results that contribte to your objective to set a plan to deliver on the KRs and objective.
- Maintain communication with KR owners - synchronous or asynchronous - throughout the quarter as needed.
- Provide bi-weekly updates in the epic and in the Developer Relations bi-weekly team meeting agenda on the objective including completion percentage and status. We recognize that there will be no change from the previous report at times.
- Present overview and status updates in team business reviews.
- Escalate any urgent needs to your manager.
Key Results DRI Responsibilities
- Create and manage strategy for achieving the key results. Manage dependencies, set actions, and define how your items will be scored.
- Provide bi-weekly updates in the issues in the GitLab OKRs project including completion percentage and status. The issues are the single source of truth for your KR. We recognize that there will be no change from the previous report at times.
- Ensure key result information is up-to-date for team business reviews.
- Escalate any urgent needs to your manager.

How we update our OKRs

To update our list of current OKRs:

Follow the OKRs in GitLab handbook
Create OKRs, and KR items.
Add the following labels: Division::Marketing, Department::Developer Relations, OKR.

OKR Health: We use issue health indicators to help people understand an OKRs status at a glance. These status indicators are:

on track
needs attention
at risk

Progress: Edit the progress attribute in KRs to indicate how much progress has been made.

Developer Relations KPIs

The Developer Relations team monitors several Key Performance Indicators and related Performance Indicators.

Team Logos

GitLab Developer Relations team logos can be found in .png and .svg formats by searching for gitlab-devrel-logo in Google Drive.

Team Budgets

Learn more on the Developer Relations budget page

Community Diversity, Inclusion, and Belonging

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.

DEI Strategies

As DEI (Diversity, Equity and Inclusion) allies in the open source community, GitLab’s Developer Relations team is committed to the following DEI efforts within our contributor communities:

DEI project badging:
- Partner with community-wide initiatives to establish a mechanism to recognize, support and promote DEI efforts through a badging system.
- Highlight the DEI values and inclusion efforts of GitLab’s projects.
- Encourage open-source projects hosted on GitLab to do the same.
First-time contributor inclusion:
- Perform user research studies on first-time contributors to learn and improve the experience.
- Improve documentation from perspectives of first-time contributors.
- Improve community onboarding for newcomers.
DEI group participation:
- Track DEI group participation among GitLab team members, beginning with the Developer Relations team.
- Encourage team members to attend open-source DEI working groups and events.
- Poll team members quarterly to track participation.
- Expand from Developer Relations to Marketing and then across GitLab.
Swag/contributor points coupons at qualifying events:
- Offer GitLab swag and GitLab contributor points coupons at qualifying events.
- Incentivize community members and potential contributors with coupon codes.
GitLab contributor resource groups:
- Form GitLab contributor resource groups similar to GitLab Team Member Resource Groups (TMRGs).
- Include mentoring/coaching opportunities.
- Consider groups for non-contributing developers or for Developer Relations team members.
- Consider hosting events/days for specified underrepresented groups.

Planning Events and Activities

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.

Images: We seek to promote the use of images that represent a diverse group of users, customers, and community members. When we see a lack of diverse representation, we speak up and actively help update those images when possible.
Speakers: As event organizers and participants, we seek to include a diverse set of speakers in events that GitLab organizes or touches.
We are open-minded: We actively seek feedback and keep an open mind about our current policies. We are open to change and are willing to make structural changes to ensure that we continue to foster DIB among our team and the wider GitLab community.
We retain a growth mindset and keep learning: We read articles, attend workshops, and participate in trainings that help educate us about how to foster DIB in our community and how to be inclusive ourselves.
We encourage a diverse set of community members to participate in research: We recognize the product inclusivity is important and that we need to build with our community, not just for them.
We promote the GitLab Diversity Scholarship program: This scholarship supports Diversity, Inclusion, and Belonging-focused events financially.

Communities who inspire us

We take inspiration from the great work being done by other communities. Some of the communities who we take inspiration from:

Linux Foundation - A large, engaged community that act as custodians for important open source technology.
CNCF - A large, engaged community that act as custodians for important open source technology.
FINOS - A large, engaged community that act as custodians for important open source technology.
Debian - A large, engaged community that act as custodians for important open source technology.
GNOME - A large, engaged community that act as custodians for important open source technology.
KDE - A large, engaged community that act as custodians for important open source technology.
Fedora - A large, engaged community that act as custodians for important open source technology.
Drupal - A large, engaged community that act as custodians for important open source technology.
Wikimedia Foundation - This community is a champion for free information with a large, engaged community.
Kubernetes - This community consists of a large network of user groups and champions that serve to help each other grow and better utilize Kubernetes.
AWS - This community consists of a large network of user groups and champions that serve to help each other grow and better utilize AWS.
Dev.to - This community creates a welcoming place for the tech community, particularly newcomers, to learn and share content.
Hacker News - This community is known for its engaging discussion of the latest tech news and trends.
Google Summer of Code - This community inspires us through their work to make the tech community more diverse and inclusive and create new opportunities for people new to tech.
Outreachy - This community inspires us through their work to make the tech community more diverse and inclusive and create new opportunities for people new to tech.
Grace Hopper Community / Systers - This community inspires us through their work to make the tech community more diverse and inclusive.
Lesbians Who Tech - This community inspires us through their work to make the tech community more diverse and inclusive.
Techqueria - This community inspires us through their work to make the tech community more diverse and inclusive.
Latinas in Tech - This community inspires us through their work to make the tech community more diverse and inclusive.
Women in Tech - This community inspires us through their work to make the tech community more diverse and inclusive.
Women Who Code - This community inspires us through their work to make the tech community more diverse and inclusive.
Rails Girls - This community inspires us through their work to make the tech community more diverse and inclusive.

Community Learning Pathway

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.

Community Building Reading Group

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:

Leading and conducting community activities
Welcoming new contributors
Managing relationships in and with communities
Negotiating community authority and power relations
Architecting and enforcing community codes of conduct
Cultivating community cultures
Measuring community health and success
Converting community participants into community contributors
Encouraging community mentorship
Building community-powered innovation and business models
Assessing community infrastructure and governance models
Understanding community value propositions and exchanges

By collaborating as part of this group, members aim to:

Hone their craft. Working with communities requires thoughtful and skillful practice. This group provides a space for collectively reviewing, assessing, and learning from materials that help members become better practitioners.
Create space for support and growth. Working with communities requires emotional labor, and people who undertake it often benefit from spaces to discuss the work’s challenges with like-minded collaborators. This group would function as one such space.
Generate and share resources. Working with communities is easier with knowledge of best practices and trusted frameworks. By reading and reviewing materials on the state of the art, members generate a knowledge commons others can access and from which they can learn.

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:

is an ongoing effort rather than a discrete and time-delimited event
is focused on a series of works rather than a single one

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.

Group members propose materials for the group to study and discuss by opening an issue in the Developer Relations team’s Community Building project using the reading-group template, then attaching the Reading Group::Proposed label to it.
Group members can then browse one another’s suggestions and collectively select what to study.
When they determine what they’ll read, they re-label the issue Reading Group::Up Next.
When they begin reading and studying proposed material, they re-label the issue, applying the Reading Group::Now Reading label.
And when they’ve finished a selection, they apply the 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.

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

View page source - Edit this page - please contribute.