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.
(Specific examples TBD).
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.
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.
WIP, but stay tuned!
While they're not full-time support team members, advocates can field some of the questions the support team recieves.