Developer Advocates act as spokespeople and liaisons between GitLab and its users. Their role is to make developers happy to use GitLab by getting customer feedback into the product.
In addition to providing enhancements to GitLab itself, Advocates can also provide miscellaneous code samples for everyone to view.
Speaking at/attending events is an important facet of developer outreach as it's one of the best places to get in front of people.
There are a few places where you can keep tabs on open Calls for Papers.
In general, try to avoid sponsored speaking slots/slots we have to pay to get. There's value in these, but attendance rates are lower than organic conference talks.
If you do a Q&A session, it's important to maintain control of it so that everyone gets a chance to ask questions they may have.
After speaking, it's important to make note of things that went well and things that need improvement. You can use the following template to get started (but feel free to modify it). Put your debrief in a comment on the event's issue. If no issue exists, please create it and tag Emily so she sees.
Event Name: Event Dates: Event Location: Talk Title: Talk Presenter(s): Talk Slides (if available online somewhere): Talk Abstract: Talk Time (include timezone): Attendee Estimate (how many people attended your session?): How was the talk received by the audience? What went well? What didn't go so well? Were there any technical difficulties? What questions did people ask?
Events are an important part of developer relations efforts. You can expect to travel a lot. Keep track of which events you go to via your calendar and make sure you take some vacation time.
Most events will be selected by field marketing. If you have suggestions for events, open an issue with the following information:
Be sure to use social channels to let people know you'll be there. If you're giving a talk, make sure to include that too. Add events to your calendar and make sure to let everyone else on the developer relations team know so they can plan accordingly.
After an event, put a debrief together to help us determine whether we're hitting our goals. A short summary should answer:
This information can be posted on the relevant event issue in the issue tracker. If no issue exists, please create one and tag Emily in it. If you gave a talk be sure to include a debrief about that as well.
Make sure to follow up with anyone you spoke to at the event, even if it's just to say "Thanks for chatting!"
Event organizers also love to hear feedback about their events. Make sure to thank them and tell them what they did well. If things didn't go according to plan, make sure they know that too so they can incorporate your feedback next time.
Please abide by GitLab's travel policy unless an exception is noted below.
Here's a list of things you may want to put in your carry-on bag:
If you're speaking at an event, include the following:
In your checked bag:
Advocates follow these guidelines when posting as GitLab.
GitLab has a presence across many social media channels. The following is a list of channels we actively monitor.
There are two GitLab Twitter accounts
@GitLab - This is the main account for the project and company, which is managed by team members at GitLab, Inc. Everything tweeted, RTd, or liked from @GitLab also gets promoted to https://about.gitlab.com
@GitLabStatus - This account tweets about the status of GitLab.com services and is managed by the GitLab infrastructure team. We don't generally retweet GitLabStatus, but point users to follow that account or check it.
Favorite tweets which include positive comments about GitLab or articles mentioning GitLab in a positive way.
Thank users for feedback and comments with @mentions like: ‘Thank you’, ‘Glad to hear that’, ‘You’re welcome’, do this even when you already favored something.
When responding to tweets, be polite and brief.
It’s OK to invite CE or GitLab.com users to collaborate, the easiest way is to direct a user to the relevant issue tracker.
About using the tools
Zendesk is a good place to reply to tweets, but always check for the tweet history on Tweetdeck.
Use Tweetdeck to find GitLab mentions without the # or @.
Ignore tweets that are negative about competitors
GitLab communicates in English so please tweet in English.
If a foreign language tweet comes in, replies in that language are okay but discouraged as we can't guarantee making our support SLA.
Please no foreign retweets, these break the flow of people reading their timeline and cause people to unfollow.
Feature proposals: It would be really cool if GitLab could…
If there’s an existing feature request, ask the user to vote on the request with a link to the feature request.
If we’re accepting merge requests, tell them with a link to the feature request. Often the feature request thread will indicate that as well.
Bug reports: I think I’ve discovered a bug.
Product specific questions: I need some help with X.
Check if there is existing documentation and reply with a link if there is.
GitLab.com specific: Ask the user to add the Issue to our GitLab.com Support Forum. https://gitlab.com/gitlab-com/support-forum/issues
GitLab CE or CI: ask the user to add the Issue to our CE Issue tracker. https://gitlab.com/gitlab-org/gitlab-ce/issues
Support or help: I think I ran into a problem.
GitLab is down!
If there is a known issue, apologize and invite them to follow @GitLabStatus
If this is not known, alert the infrastructure team, and thank the reporter.
Request for consulting or development.
Comments are enabled in the GitLab docs portal where users can leave a note if something is wrong with our documentation.
They are powered by Disqus and are tracked in the
docs-comments chat channel. When an advocate replies to a comment:
See the ones listed on our getting help page.
The developer relations team may need technical content that is more abstract than how-to technical guides. Developer Advocates can produce relevant content to fill the content calendar.
We're offering training around CI/CD and GitLab to raise awareness of the feature and introduce people to the concept of rapid testing and deploying.
In general, the slides contain the most up to date outline of the content. However, attendees can expect to see the following points in a 3 hour session:
Thank everyone for coming and make sure attendees get swag.
Each attendee should be asked to fill out a survey while on-site at the event. You can view an example survey here.
The slides for this training can be found here. The content is subject to change from time to time, so please be sure to make a copy for your own reference.
In general, the speaker notes contain the content to be covered on the slide. Much of the training is a live demo, but there are slides with screenshots in case the live demo doesn't work. You're encouraged to do the live demo whenever possible as it's a more compelling story.
If you'd like to use this deck or make edits, please make a copy in your own Drive folder first.
Ideally CI/CD training will be paired with events that we plan on attending. If there are no events to attend, we will host trainings in cities with larger GitLab user bases such as San Francisco, Toronto, or Amsterdam. Community members can host these trainings anywhere provided that the location is conducive to getting more than 20 attendees and there’s a strong community.
Try to find venues that are close to public transit/have parking. Ideally venues are located downtown in the desired city. Make sure we can bring snacks and drinks for attendees or ask about catering.
Follow this guide to create campaigns in SalesForce and Marketo. If you get stuck, talk to the Marketing Ops team for help.
You will also need to create a landing page in Unbounce to collect RSVPs. You can copy an existing page, but make sure to change the information outlined in the guide above so that RSVPs count under the right event.
When the details are finalized, create a quick blog post that outlines what the training is about and key details such as time and location. Make sure this gets tweeted.
Once the landing pages are set up, advertise the event through the following channels:
Paid ads can be set up by the Marketing Ops team as needed. Use the "Social Media" issue template in the Marketing project.
While they're not full-time support team members, advocates can field some of the questions the support team receives.