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
Abubakar Siddiq AngoAbubakar Siddiq Ango Developer Advocate
Cesar SaavedraCesar Saavedra Senior Developer Advocate
Community Programs Associate ManagerCommunity Programs Associate Manager Community Programs Associate Manager
Daniel MurphyDaniel Murphy Fullstack Engineer, Contributor Success
Emilio SalvadorEmilio Salvador VP, Dev Relations and Community
Fatima Sarah KhalidFatima Sarah Khalid Developer Advocate
Fernando DiazFernando Diaz Senior Developer Advocate
Itzik Gan-BaruchItzik Gan-Baruch Sr. Developer Advocate, Product Management internship
John CoghlanJohn Coghlan Director, Developer Relations
Lee TickettLee Tickett Fullstack Engineer, Contributor Success
Core Team member
Michael FriedrichMichael Friedrich Senior Developer Advocate
Nick VeenhofNick Veenhof Director, Contributor Success
Oksana KohuchOksana Kohuch Fullstack Engineer, Contributor Success
Raimund HookRaimund Hook Senior Fullstack Engineer, Contributor Success
William AriasWilliam 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:

Email us

File an issue

Emergency contact

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 Advocate 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:

  1. Follow the OKRs in GitLab handbook
  2. Create OKRs, and KR items.
  3. 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 encourage a diverse set of community members to participate in our First Look product research program.
  • 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.

  1. 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.
  2. Group members can then browse one another’s suggestions and collectively select what to study.
  3. When they determine what they’ll read, they re-label the issue Reading Group::Up Next.
  4. When they begin reading and studying proposed material, they re-label the issue, applying the Reading Group::Now Reading label.
  5. 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.


Community Learning Pathway: Course Resources
Community Learning Pathway The Community Learning pathway is a course on the GitLab Learn platform, designed to educate GitLab team members and the community about GitLab’s community pograms, our commitment to the community and how to engage the community team. At the end of the course, learners earn a badge showing they have a good understanding of the GitLab community and how to engage. Course Objectives At the end of this course, we expect team members to:
Community Programs
Meet the Community Programs team at GitLab
Contributor Success Team
Contributor Success Team
Core Team
Becoming a Core Team member A new member can be added to the Core Team at any time through the following steps: Any Core Team member or GitLab Team member can nominate a new member from the wider community at any time using a confidential issue in the Core Team group to limit any possible negative feedback in the smallest setting possible. The nominee will be added to the Core Team if they have received positive votes from two-thirds (2/3) of all current core team members within a four-week period and accept the nomination.
Developer Advocacy
Developer Advocates build GitLab's technical brand with deep, meaningful conversations on engineering topics relevant to our community.
Developer Relations - Content Effectiveness
How the Developer Relations team measures effectiveness of content it creates.
Developer Relations Content Requests
How to request content from the Developer Relations team
Developer Relations Department Performance Indicators
Performance Indicators for the Developer Relations Department at GitLab
Developer Relations Events
Events are a great way for GitLab and the Developer Relations team to connect with customers and the wider GitLab community. Types of Events The Developer Relations team regularly attends the following event types: Community Events Corporate Marketing Events Field Marketing Events Community events GitLab’s Developer Relations team regularly organizes virtual events including GitLab Hackathons and community office hours. We also support in-person contributor days and community-organized meetups. Many of these activities are organized through the GitLab network page on Meetup.
Developer Relations Program Management
The Developer Relations team works from issues and issue boards. If you need our assistance with any project, please open an issue and use one of the main program labels anywhere within the GitLab repo. Developer Relations handbook updates Merged updates to the handbook are posted to the #community-relations-fyi Slack channel. MRs must be tagged with the Developer Relations labeled before being merged in order to be posted to Slack. When you create a new MR, be sure to add the label upon creation so this step isn’t forgotten.
Developer Relations workflow: UTM Tracking Strategy
Overview The purpose of this page is to outline the UTM strategy of the Community team and how it drives dashboards of the team in Sisense. This strategy is designed inline with Marketing UTM Strategy and reviewed by the Marketing Strategy & Analytics team. Use Cases Workshop with referral to a marketing website for more resources or reference Free Trial sign-up suggestions during presentations Referencing surveys, blog posts, release posts or any other Content Referencing Documentation pages Campaign manager CommunityApps makes using working with this UTM Strategy easier, you can learn more in the CommunityApps User Guide.
Developer Relations Workflows and Tools
Workflows Team Workflows Code of Conduct Enforcement Team Budgets Developer Advocate Community Response Process Community Operations: Automated Community Programs Swag operations Content Review / Fix Fridays Community platforms Forum Discord Reddit StackOverflow Integrations Zapier Communication Zendesk Email Twitter Tool Stack Overview These are the tools the Developer Relations team is the DRI for: Tool Description How we use it Technical owner Common Room Common Room is a community growth platform that brings together community data to surface insights.
Developer Relations: Program Resources
Contact e-mails The team uses a set of contact e-mails, generally one per program, with additional specialized e-mails. They are used to enable contributors to directly contact the team outside of GitLab.com and for notifications related to each one of our programs. Program e-mails: opensource@gitlab.com: GitLab for Open Source Program, CrowdIn notifications education@gitlab.com: GitLab for Education Program evangelists@gitlab.com: Evangelist Program. Not currently connected to Zendesk contributors@gitlab.com: Code Contributor Program. Not currently connected to Zendesk startups@gitlab.
Evangelist Program
Overview At GitLab our mission is to change all creative work from read-only to read-write so that everyone can contribute. In order to fulfill this mission, we need to create both the tools and platform to enable this change and a community of contributors who share our mission. We are just getting started in building the GitLab community and we encourage everyone to contribute to its growth. There are many ways to participate in the GitLab community today: contributing to an open source project, contributing to our documentation, hosting your open source project on GitLab, or teaching your colleagues and collaborators about the value of Concurrent DevOps.
GitLab Community Apps
GitLab Community Apps Overview The GitLab Community Apps is a suite of tools that enables the community and other teams at GitLab measure the impact of activities, programs or campaigns they run. Application Hompage Source Code The applications are built and currently maintained by Abubakar Siddiq Ango and MRs are welcome! The tools available in the suite are described below. Campaign Manager Campaign Manager brings together UTM tracking, URL shortening & QR Code, allowing teams at GitLab to manage campaign links from an easy to use application.
Leading Organizations
Leading Organizations are groups and people who consistently make meaningful contributions to GitLab.
Strategic Plans
Technical Marketing
Learn more about the purpose, process and output of GitLab's Technical Marketing.