Welcome to the Developer Evangelism team workflow page. Learn how the team works and how to work with the team. We primarily use the Corporate Marketing issue tracker. We own the team label
dev-evangelism and all of our other labels which are located at the gitlab-com group level. You can add the labels as necessary to any issue under this group for our team to track.
Opening an issue is the best way to get a conversation started. The
dev-evangelism label is at the
gitlab-com group level, which means it can be added to any issue or merge request in the group's structure.
dev-evangelism label is required, other labels are optional. The DE-Bot or a team member will do the triage and add the necessary labels. To reduce noise in the comments, please add the
DE-Type::Consulting and the relevant
Consulting team labels yourself.
You can use the request an evangelist issue template to submit a request. It provides a guide to collect the required information to triage the request.
The Developer Evangelism team workflow is supported by labels, which help determine the type of issue, its status, and other relevant information. The team's primary label is
dev-evangelism. All issues the team owns, are a part of, or needs to be aware of, should be tagged with
dev-evangelism. Other Labels are listed below:
||Issues that are planned for the future|
||Issues the team is currently working on|
||Issues that have been completed|
||Issues that are for whatever resume pending|
||Issues that have been cancelled, either by the team or the requestor in the case of a consulting request|
||Issues the team needs to be aware of but no action is required|
The default flow is from ToDo -> Doing -> (OnHold) -> Done. Issues with FYI don't go through any workflow, as they are owned by another team and will go through a different workflow.
These labels help identify the type of activity documented in an issue. These are useful for the team to understand where time is spent and assign appropriate DRIs.
||Issues for Content creation, this can be any type of content|
||Issues for the Evangelist program|
||Issues for operational activities of the team, mostly owned by the Developer Evangelism Program Manager|
||Issues for Community Response activities|
||Issues requested by other teams, more details below|
Requests from other teams for the Developer Evangelism to own, participate or collaborate on activities are classified as consulting, and these requests are usually labeled based on the team requesting. These are teams in the company that the Developer Evangelism team collaborate with often, here are their labels:
These labels are required where an issue has
DE-Type::Consulting, aside the team label
DE-Status scoped label. If your team is not listed, you can still submit a request and it will be triaged appropriately
Issues created for Consulting count against team quarterly budgets, you can learn more in the Request budgets section below.
These labels are automatically assigned by the DE-Bot for triaging purposes.
||Issue is automatically created by DE-Bot and will be closed after a period, usually 2 weeks from creation|
||Issue is currently on hold and should not be triaged by teh DE-Bot except where it has been in the Hold status for too long.|
||The DE-Bot should not perform any action on issues with this label|
||Issue has been silent for a while and needs to be triaged|
||An Issue needs a due date|
||Due date is not needed because the team doesn't own the issue or a due date is not applicable|
||Issue is past its due date|
||Issue is due soon|
||Release Evangelism issues, often autocreated and closed by the DE-Bot|
||Issues created by Other teams|
||Issues created & owned by the DevEvangelism team|
These labels are used to track workflow of the CFP submissions.
||Identifies CFP labels, this is needed|
||Identifies CFPs that will be open soon|
||Identifies Open CFPs|
||Identifies Closed CFPs|
||Identifies Cancelled CFPs|
||Identifies that submissions were made for the CFP|
||Identifies if any submission was accepted for a CFP|
||Identifies CFPs that are relevant to the Education team|
||Identifies CFPs that are relevane to the Open Source teams|
||This is used to note the number of submissions that were made for metrics purposes|
||This is used to note the number of acceptances for metrics purposes|
The CfP workflow is based on the CfP labels explained above.
Example CfP workflow using quick actions:
~CFP-Submitted::scoped label to reflect the correct number.
submissionssection in the issue. Comment on the issue for visibility.
/label ~CFP-Submitted ~CFP-Submitted::1
CfP::Closedlabel and update the due date to the CFP notification date listed in the issue.
/due <cfo notification date>
/label ~CFP-Accepted ~CFP-Accepted::1
DE-Status::Doneand close it.
/label ~DE-Status::Done /close
If no talks were accepted, only close the issue shown above.
If the CfP closed without submission, add the
CFP::Closed label. In case the CfP was planned to submit, and decisions were made otherwise, add the
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 asking a Developer Evangelist to submit a proposal for an event or media opportunity or support a fellow team member in submitting to 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||Existing / No content||1|
Each team listed below is allocated 15 points per quarter for requests:
|Field Marketing / ABM||
|Sales / SDRs||
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: