To build GitLab's technical brand with deep, meaningful conversations on engineering topics relevant to our industry by leveraging our community of team-members and the broader ecosystem.
The GitLab developer evangelists are engineers who enjoy learning and teaching the latest technology topics with the wider community. The evangelists are supported by program management within the team and also collaborate closely with the content and PR teams in corporate marketing to amplify their voices. There are two specific goals for the team:
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.
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.
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.
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.
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 |
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.
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 are members of the Community Relations team.
A good overview with specific area definitions can be found in the DevRel Notebook.
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:
