Developer Advocate Team Workflow

Team Workflow

Welcome to the Developer Advocate team workflow page. Learn how the team works and how to work with the team. We primarily use the Developer Advocate Meta issue tracker. We own the team label developer-advocacy 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.

How to work with the Developer Advocate Team

Opening an issue is the best way to get a conversation started. The developer-advocacy 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.

The developer-advocacy label is required, other labels are optional. The DA-Bot or a team member will do the triage and add the necessary labels. To reduce noise in the comments, please add the DA-Type::Consulting and the relevant Consulting team labels yourself.

You can use the request a Developer Advocate issue template to submit a request. It provides a guide to collect the required information to triage the request.

Roadmap view

The Developer Advocate team uses the Roadmap in the Developer Relations Group to track our work. Epics for our team are tracked within this group using the developer-advocacy label.

Epics

Work items that fit our team strategy, including events and content plans, are tracked using epics and child epics. Use the following search filters to find the strategy epics for each fiscal year:

• DevRel Events Strategy
• DevRel Content Strategy
• DevRel Release Evangelism

For each activity of the team, a sub-epic should be created under the relevant parent epic and with relevant labels added.

For each fiscal year’s plan, we use the following structure to organize epics on our roadmap:

• FYXX Events
  • Child epic for each event we will support
• FYXX Content
  • FYXXQ{1,2,3,4}
    • Child epic for each piece of content (blog, video, contributed article, media interview, etc) we will publish
  • FYXX Release Evangelism epic (contains all release shares and results)

Start and due dates

For blog posts and other content, start and due dates should correspond with the expected week of publishing. Do not set start date to the time you’ll begin working on a piece of content as this can affect the roadmap view.

Epic Labels

These are the recommended labels for Epics created in the Developer Relations group. They are used for filtering the epics.

Important! Where you are adding a label to a sub-epic, its ancestors must include the label for filtering to work properly. This is a workaround, because the roadmap only filters top-level epics using labels, but works when an epic and its ancestors have the label you are filtering with. For example, in the image below, you will notice that the FY24 Content & the sub epic “Blog post - March 2023”, both have the label Content-Blog, they both appear when the label is used as a filter. The child epic will not appear in the filter, when its ancestors don’t have the label you are searching with.

Syncing epics roadmap with the technical content plan

The roadmap view needs to be synced with the Technical Content Plan - Developer Advocates (search in Google drive).

Checklist for updating delivery dates:

1. Sync the delivery date in the technical content plan with the epic due date.
2. Update the epic’s title to the month, year the content is delivered.
3. Update the epic’s parent epic to match the quarter where the content is delivered.
4. Update the epic’s labels to match the quarter where the content is delivered.

The following quick actions example updates a content epic from FY25Q1 to FY25Q2.

/unlabel ~"FY25-Q1"

/parent_epic https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/392

/label ~"FY25-Q2"

Subscribing to epic updates

To get notifications, you can subscribe to epic labels starting with the “DevRel” prefix.

Please follow the content library resources for general content updates.

Epic Templates

Please use this template when creating Epics for activities that should appear for the Developer Advocate team on the roadmap:

Content Epic Template

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

> Epic Title Guide:
> Dates should be using ISO dates, see https://about.gitlab.com/handbook/communication/#writing-style-guidelines
> Format:
>  Content: Title - Author - Publish Month, Publish Year


## Activity Summary

**Please consider addressing these key questions in your summary:**

1. Who is our audience?
    - A:

2. What is the best content type (blog post, video, how-to) to deliver this message?
    - A:

3. How does this content help our audience?
    - A:

4. How does this content help us achieve our goals?
    - A:


## Team or Individual DRIs
**Please add team label to epic.**


## Relevant Issues, Epics or resources

-

## Checklist
**Please review the tasks and tick them off.**

- [ ] Add to Technical content sheet.
    - [ ] When started: Mark the row as yellow (in progress)
- [ ] Add epic start/due date, synced with the technical content sheet row.
- [ ] Add issues for tracking content (blog pitches, etc.)

On completion:

- [ ] [Distribute the content](https://handbook.gitlab.com/handbook/marketing/developer-relations/developer-advocacy/content/content-distribution) (Highspot, Slack, social media, etc.)
- [ ] Add results to the epic, and to the technical content sheet. Mark the sheet row as completed (green).

<!-- these labels should be included on all templates -->
/label ~"developer-advocacy"

<!-- Note: These are samples for guidance, please add relevant labels for activity region, type, quarter or any other labels relevant to your team/program. Please update or include additional relevant labels here. -->

/label ~"DevRel-Content" ~"FY25-Q1"

<!-- Link to parent epic where necessary. Please choose the quarterly epic from the
FY25 epic https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/339 -->

<!-- FY25Q1 -->
/parent_epic https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/391

<!-- Link to Child epic where necessary -->
/child_epic

<!-- Mention team members that should be aware of the epic -->
/cc

Events Epic Template

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

> Epic Title Guide:
> Dates should be using ISO dates, see https://about.gitlab.com/handbook/communication/#writing-style-guidelines
> Format:
>  Content: Title - Author - Publish Month, Publish Year
>  Event: Event Name, Location, ISO Date

## Activity Summary

**Please consider addressing these key questions in your summary:**

1. Who is our audience?
    - A:

2. What is the best content type (blog post, video, how-to) to deliver this message?
    - A:

3. How does this content help our audience?
    - A:

4. How does this content help us achieve our goals?
    - A:

## Team or Individual DRIs
**Please add team label to epic.**


## Relevant Issues, Epics or resources

-

## Checklist
**Please review the tasks and tick them off.**

- [ ] Add epic start/due date.
- [ ] Add issues for tracking tasks (CFPs, code challenge, lightning talks, staffing, etc.)
- [ ] Document learnings, notes, ideas, etc. in the epic.

On completion:

- [ ] [Create event report slides and share them](/handbook/marketing/developer-relations/events/#event-reporting)

<!-- these labels should be included on all templates -->
/label ~"developer-advocacy"

<!-- Example: These are samples for guidance, please add relevant labels for activity region, type, quarter or any other labels relevant to your team/program. Please include additional relevant labels here.  -->

/label ~"DevRel-Events" ~"Region-AMER" ~"FY25-Q1"


<!--Link to parent epic where necessary -->

<!-- Events epic (FY25) -->
/parent_epic https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/326


<!-- Link to Child epic where necessary -->
/child_epic

<!-- Mention team members that should be aware of the epic -->
/cc

Release Evangelism Epic Template

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

## :eyes: Pins

* [Release Evangelism handbook](https://handbook.gitlab.com/handbook/marketing/developer-relations/developer-advocacy/social-media/#release-evangelism) provides all resources.
* [#release-post](https://gitlab.slack.com/archives/C3TRESYPJ) Slack channel (internal)
* [Release post MR items](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests?label_name%5B%5D=release+post)

### :construction_site: Tasks

1. Create campaign short URLs in the [Release Evagelism Campaign](https://campaign-manager.gitlab.com/campaigns/view/3), under the Developer Relations Team in [CommunityApps](https://campaign-manager.gitlab.com/), and add them into the releases sections below.
1. Review and identify social share items, add text examples for team members to copy/paste.

## :bulb: Releases

- https://about.gitlab.com/releases/
- https://about.gitlab.com/upcoming-releases/

<!-- Repeat the template below 12x for all releases for the coming fiscal year. -->
### <version> (yyyy-mm-dd)

- Release blog post:
- Twitter/X:
- LinkedIn:
- Mastodon:

Social shares

1.

Feature highlights

| Feature | Section | URL | Social text example |
|---------|---------|-----|---------------------|
|  |  |  |  |
|  |  |  |  |
|  |  |  |  |


/label ~"developer-advocacy" ~"DA-Type::Evangelist" ~"DevRel-Content" ~"Content-Releases"

CFPs

CFP epics should not be created to avoid clutter on the Roadmap, instead the CFP label should be added to the corresponding event’s epic. If no related event epic exists, create one and add the CFP issue to it.

Epics Triage

The DevRel-Bot uses the GitLab Triage project to ensure appropriate & consistent usage of labels.

Labels

The Developer Advocate 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 developer-advocacy. All issues the team owns, are a part of, or needs to be aware of, should be tagged with developer-advocacy. Other Labels are listed below:

General labels

Issue management

The team creates issues for iteration, team discussions, and other issues for internal processes. These issues are tracked using the following labels:

Workflow

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.

Issue Types

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.

Consulting Labels

Requests from other teams for the Developer Advocates 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 Advocate team collaborate with often, here are their labels:

• DA-Consulting::Alliances
• DA-Consulting::CorpComms
• DA-Consulting::CorpEvents
• DA-Consulting::Community
• DA-Consulting::Engineering
• DA-Consulting::FieldMktg
• DA-Consulting::GrowthMktg
• DA-Consulting::Product
• DA-Consulting::Sales

These labels are required where an issue has DA-Issue-Type::External and DA-Type::Consulting, aside the team label developer-advocacy and DA-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.

Bot Labels

These labels are automatically assigned by the DA-Bot for triaging purposes.

Other Labels

CFP Labels

These labels are used to track workflow of the CFP submissions.

CFP Workflow

The CFP workflow is based on the CFP labels explained above.

start
: CFP, CFP::Upcoming;
: CFP, CFP::Open;
if (CFP submissions) then (yes)
    : CFP, CFP::Submitted, CFP-Submitted::{0..7};

    if (CFP is Accepted) then (yes)
        : CFP, CFP::Accepted, CFP-Accepted::{0..7};
    else (no)
        : CFP, CFP::Closed;
    endif;
elseif (No submissions) then (missed)
    : CFP, CFP::Closed;
else  (cancelled)
    : CFP, CFP::Cancelled;
endif
stop

Example CFP workflow using quick actions:

1. Planning to submit, or when you have submitted already:
   1. Create a new CFP issue.
   2. The issue template already sets the ~"CFP" ~"CFP::Open" labels.
   3. Set the due date to the CFP submission due date.
2. Submitted 1 talk:
   1. Change the label to ~CFP-Submitted ~CFP-Submitted::1
   2. In case you have submitted multiple talks, adjust the ~CFP-Submitted:: scoped label to reflect the correct number.
   3. Update the submissions section in the issue. Comment on the issue for visibility.

/label ~CFP-Submitted ~CFP-Submitted::1

3. After the CFP closed, set the CFP::Closed label and update the due date to the CFP notification date listed in the issue.

/due <cfp notification date>

4. CFP notifications come in, and at least 1 talk was accepted.
   1. Change the label to ~CFP-Accepted ~CFP-Accepted::1
   2. In case you have multiple talks accepted, adjust the ~CFP-Accepted:: scoped label.
   3. Comment on the issue with the talk titles for visibility.
   4. Set the due date to the event date, and ensure all speakers are assigned.

/label ~CFP-Accepted ~CFP-Accepted::1

5. When the event is done, update the issue with feedback and results.
   1. Add talk videos to the YouTube playlist, if existing.
   2. Mark the issue as DA-Status::Done and close it.

/label ~DA-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 CFP::Cancelled label.

Boards

• Team General Issue Board
• Team Activity Type Issue Board
• CFP Issue Board

Request budgets

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:

1. Event requests
2. CFP requests
3. Content requests

Ongoing activities including team-driven content creation and speaking opportunities that supports our goals and OKRs, release support, and social media monitoring, including Hacker News, do not count towards any team budgets.

Event requests

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 (Call for Proposals) requests

CFP requests include asking a Developer Advocate 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 Advocate to submit a CFP to request a Developer Advocate to submit to a CFP for a corporate, field, or partner event.

Content requests

Content requests include blog post, podcasts, media interviews, or any request that involves engaging a Developer Advocate in a media opportunity.

Scoring requests

Each team listed below is allocated 15 points per quarter for requests:

If your team is not listed above, we will handle your request based on our availability.

Managing requests

This process covers any content request, Webcast, Interview, Meetup, etc. The process involves the following:

• Requestors should assign a label that identifies their team and a weight correlating with their budget score to allow us to track each team’s budget consumption.
• A member of the Developer Advocate team will triage the issue and provide all necessary details and directions
• The necessary labels are applied to the issue as actions are taken on the request
• Once the request is complete, the issue is assigned back to the requestor to provide the necessary metrics generated as a result of the before it is closed.

View page source - Edit this page - please contribute.