To support, grow, and engage the GitLab community through collaboration, content, and conversations.
Developer relations and developer evangelism is an ever-expanding space that can seem saturated with marketing aimed at developers. This type of developer marketing can have the inverse effect - causing developers and other technologists to be less likely to interact with companies and communities that seem disingenuous.
For this reason, we choose to have a team with credibility from real-world engineering team experience. Additionally, we enable others to tell their authentic stories - engineers, open source community members, and GitLab's diverse set of customers. For those reasons, we chose the title of Evangelist as defined as "an enthusiastic advocate."
When differentiating this approach from traditional developer relations programs or groups, we want to focus on areas that are often overlooked, including:
When we are reviewing opportunities or requests for support, we must be able to answer yes to each of these questions to move forward with the work:
If the answer to any of the above questions is "no", our team will collaborate with each other and the requestor to do one of the following actions:
Social media Content creation Presentations and events CFPs Community engagement Release evangelism Projects OSS Contributions Metrics KeyHole
Our developer evangelism team can be summarized by the "Three Cs":
We build our thought leadership on social media. See Developer Evangelism on Social Media to learn more about our strategies and become an evangelist yourself.
We build out content to help educate developers around best practices related to DevOps, GitLab, remote work, and other topics where we have expertise. Content includes presentations, demos, workshops, blog posts, and media engagements.
We maintain a YouTube playlist with our talks, workshops and community engagements.
When contributing to articles on external sites, please request that the author or publisher include a UTM code linking to the GitLab marketing website (i.e. about.gitlab.com) pages that are referenced in the article or story.
The UTM codes to use are:
social, presentation, email, partners, other or any other medium specified in the UTM Tracking sheet. To use any source not listed, the Digital Marketing team needs to be informed.de-external-blogposts or any other periodic campaigns.Any UTM links created should be added to the UTM Tracking sheet for GitLab-wide tracking and coordination. Review the Digital Marketing handbook page for more information on UTM tracking.
We write across diverse platforms, but a primary destination for our writings is the GitLab Blog, where all our blogposts include the dev-evangelism postType in their frontmatter for proper tracking.
The Developer Evangelism team creates alot of content that can be reused for any campaigns. All contents and activities the team participates in are added to the team's activity tracking sheet. You can search for relevant content and contact the author or the team on slack in the #dev-evangelism channel for clarification where needed.
Speaking at events is an essential path for our team to connect with the wider GitLab community and the tech community at large. We love to support to team members and members of the wider community on their presentations, too. We also help with the organization and execution of GitLab events and other tech community events.
Recordings from past workshops and other team activities can be found on the Developer Evangelism Team playlist on the GitLab Unfiltered channel on YouTube.
Our Developer Evangelists directly contribute to the wider community by speaking at conferences themselves. We also support and manage responses to CFPs for team members across GitLab through our issue boards.
Our team provides support to new and experienced speakers where necessary. These can range from presentation review, CFP ideation, or dry-run. We also host a monthly Speakers Lean Coffee to help folks prepare to speak. You can also learn more about the different resources and activities you can benefit from or drop a message on Slack if you need direct support.
People who regularly speak about GitLab may be interested in joining the GitLab Speakers Bureau.
Part of our role is to respond to engage with and answer questions from community members. We do this organically on social media, when prompted by our social media team or other GitLab team members, and by monitoring GitLab and other selected keywords on Hacker News.
Given the Developer Evangelism team's understanding of our community and broad knowledge of GitLab, we regularly engage in responding to situations that require intervention to address urgent and important concerns of our community members. We have a documented process how we manage these situations.
Developer Evangelists should always be prepared to promote our monthly release and engage in community response on release days given the historical performance of release posts on Hacker News.
Our team maintains many projects to help show off technical concepts, engage with communities, provide examples of using GitLab with other technologies, and automate our team processes. See Developer Evangelism Projects for a list of all of those projects.
We actively contribute to OSS projects and share our technical expertise. You can learn more about our ideas and visions in our OSS contributions handbook page.
Measuring what we do is very important to understand our impact and how we are able to reach our OKRs. A key metric is the Developer Evangelists' cumulative Twitter impressions. Learn more about the our tools, data collection and how to access the data sources for integrations.
Request Event or Content support Request Community Response support
In order to prevent burnout, prioritize requests appropriately, and ensure we successfully deliver on the requests to which we commit, our team has created budgets for our internal stakeholders. These budgets encourage team members to prioritize their requests, ensuring our team addresses the highest priority needs for GitLab.
These request types fall into the following categories:
Ongoing activities including team-driven content creation and speaking oppportunities that supports our goals and OKRs, release support, and social media monitoring, including Hacker News, do not count towards any team budgets.
Event requests include both event attendance (ex: attending client meetings, event staffing, attending dinners or social events, monitoring events for news) and speaking engagements at events such as demos and presentations.
CFP requests include any request for a developer evangelist to submit a proposal for an event or media opportunity or support a fellow team member in submitting for an open CFP.
See Requesting a Developer Evangelist to submit a CFP to request a Developer Evangelist to submit to a CFP for a corporate, field, or partner event.
Content requests include blog post, podcasts, media interviews, or any request that involves engaging a developer evangelist in a media opportunity.
| Request Type | New / Existing Content | Budget score |
|---|---|---|
| Event | New | 3 |
| Event | Existing / No content | 1 |
| CFP | New | 2 |
| CFP | Existing | 1 |
| Content | New | 2 |
| Content | Existing | 1 |
Each team listed below is allocated 15 points per quarter for requests:
| Team | Team Label |
|---|---|
| Corporate Events | de-corpevents |
| Corporate Communications | de-corpcomms |
| Community Relations | de-community |
| Growth Marketing | de-growthmktg |
| Field Marketing / ABM | de-fieldmktg |
| Sales / SDRs | de-sales |
| Alliances | de-alliances |
If your team is not listed above, we will handle your request based on our availablity.
This process covers any content request, Webcast, Interview, Meetup, etc. The process involves the following:
The developer evangelism team will apply the parent dev-evangelism label, then transition the issues through different stages using the scoped labels below:
| CFP Labels | Description |
|---|---|
DE-Content::new-request |
New content request |
DE-Content::draft |
A member of the TE team is working on the content |
DE-Content::review |
Content Author is seeking review from other team memebers |
DE-Content::published |
Content has been published |
DE-Content::Repurposing |
Content is being repurposed on other platforms or mediums |
DE-Content::cancelled |
Content is no longer needed, and no one is working on it |
Upon the completion of a request, the assigned Developer Evangelism team member will reassign the issue back to the requestor. The issue should only be closed after the impressions generated by the request are added to the DE Impression Tracker spreadsheet. Learn more, which we use to collect and track impressions and other metrics.
We are members of the Community Relations team.
Inspired by GitLab's collaboration value, the Developer Evangelism team has chosen to align ourselves as stable counterparts with divisions outside of Marketing. The alignment is as follows:
As stable counterparts, Developer Evangelists are expected to actively engage with the divisions to identify collaboration opportunities and act as the primary point of contact for requests for DE support from these divisions.
We work in the open using the GitLab's Corporate Marketing issue tracker. We own the label dev-evangelism which can be applied to issues in any project under the gitlab-com and gitlab-org parent groups.
You can follow the latest our team is working on by looking at our label-based issue board.
Using the dev-evangelism label on an issue means we are working on it or participating in the ongoing conversation. Team members are subscribed to issue/MR updates for this label.
The dev-evangelism label is accompanied by some labels we use to organize our work.
You only need to use the dev-evangelism label on issues requiring the attention of the Developer Evangelism team. Other labels are applied by the team as their state change or as contained in various issue templates.
| CFP Labels | Description |
|---|---|
DE-DueSoon |
This is used to monitor DE issues that are due soon |
DE-Peer-Review |
Feedback is needed on the issue from DE team members |
DE-Ops |
Used to label issues related to the Developer Evangelism Ops in DevOps theme |
DE-Dev |
Used to label issues related to the Developer Evangelism Dev in DevOps theme |
DE-k8s |
Used to label issues related to the Developer Evangelism Kubernetes theme |
The team creates issues for iteration, team discussions, and other issues for internal processes. These issues are tracked using the following labels:
| Process Labels | Description |
|---|---|
DE-Process::Open |
Process related issues that are still being discussed or worked |
DE-Process::Pending |
Process related issues on hold due to an external factor |
DE-Process::Done |
Completed Process issues |
DE-Process::FYI |
Issues that require no action from the team, but need to be aware of |
Our team has a few weekly events that we use to stay connected and aligned on our work:
GitLab team members can also reach us at any time on the #developer-evangelism Slack channel where we share updates, ideas, and thoughts with each other and the wider team.
We use dev-evangelism-updates for our weekly Geekbot check in and content shares.
The Developer Evangelism Team calendar contains team member speaking engagements, important conferences, CFP timelines, and other important dates.
Developer Evangelists should add new speaking engagements to this calendar as they are scheduled. The Developer Evangelist Program Manager will manage team-wide events such as industry conferences and their CFP timelines.
A good overview with specific area definitions can be found in the DevRel Notebook. DevRel Resources is a comprehensive collection of resources on DevRel.
We engage with Developer advocacy, relations and evangelism friends on social media:
Our KPIs and processes follow industry best practices. We regularly iterate on new ideas and different strategies. The following articles can be helpful to explore new ways of Developer Evangelism: