Provide attendees with links to your slides, notes, code samples, etc. on one of your first slides. Repeat on one of the last ones.
If you link to things in your slides, make those links available outside of your slides in a notes section.
Provide contact info on your slides. (Name, Email (optional), Twitter handle, GitLab handle)
Put one contact method at the bottom of each slide. Twitter is a solid choice.
Prepare for your talk as if the tech you depend on will fail.
You should spend a few hours rehearsing what you will say.
Figure out where your potential pitfalls are and make sure those sections get ample attention.
Prepare your talk as if all technology will die that day and you'll be forced to give it in the dark as a Q&A session. This includes not having Internet.
At the Event
Have your slides on your computer, the Internet, and on a thumb drive.
The thumb drive is also a useful backup location for code samples.
Bring your own adapters, laptop, and charging cables.
Don't expect a reliable Internet connection.
Make sure your presentation works in a variety of screen resolutions (including 800x600).
Thank the organizers and the sponsors.
Be yourself, but remember you're representing GitLab.
If things go wrong (and they will!), don't let it ruin your day. Keep moving forward.
Ask the audience questions to keep them engaged. "How many of you have done $x?" or "Who here is familiar with $x?"
Allow Q&A sessions
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.
If you don't know an answer, saying so is fine.
Ask if someone else in the audience has the answer. If no one says anything, follow up with the person offline.
Don't lie your way through these sessions.
Send follow-up emails to anyone who had questions that went unanswered/anyone who gave you a business card.
Upload your slides/code/videos as soon as you can.
Fill out an event debrief and include information about your talk
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.
Talk Slides (if available online somewhere):
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:
Event prospectus/information on sponsorship packages
Approximate attendee count
Before the Event
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.
At The Event
Attend the event and be present even if you're done speaking.
Go to talks by other speakers and tweet things you find interesting.
Use the official event hashtag (if available) to find other attendees on Twitter.
Retweet conference updates put out by the organizers.
Be the first in and the last out. When attendees are starting their day or headed to an after-party, you should make an appearance.
Get a good night's sleep the night before any presentations you give.
If you're giving a talk, use the official hashtag to share location/time as well as your slides once you're done.
After the Event
Follow up with contacts you met/anyone who handed you a business card. Even if it's just to say "Thanks for stopping by!"
After an event, put a debrief together to help us determine whether we're hitting our goals. A short summary should answer:
Overall feedback about the event. Was the location okay? Was it hard to get to? Was it well organized?
Overview of who was there (Developers? C-levels? Non-technical people?)
Were there any competitors there? What was their presence like?
Who did you speak to that we need to follow up with? Did you meet any customer/hiring prospects?
What went well?
What didn't go so well?
What can we improve?
Would you attend/sponsor/speak at this event again?
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.
Book the cheapest travel option that causes you the least amount of agony. If the cheapest flight has a 9 hour layover, it's okay to select a more expensive flight with a smaller layover.
Try to arrive the day before the event begins, and try to leave the day after.
Stay at the conference hotel if possible. Attendees tend to hang out there.
Here's a list of things you may want to put in your carry-on bag:
Wallet (with company credit card if applicable)
USB Battery pack
Entertainment! (music, games, Kindle, etc.)
If you're speaking at an event, include the following:
Dongles (VGA, HDMI, DVI)
A backup of your slides on a USB drive
A water bottle (drinks are not always provided on stage, please note that your water bottle must be empty before going through airport security in the US)
In your checked bag:
Enough clothes for your trip
At least one extra set of clothes
Swag to give away at the conference (varies by event)
Extra pair of shoes
Advocates follow these guidelines when posting as GitLab.
Social Media Channels
GitLab has a presence across many social media channels. The following is a list of channels we actively monitor.
@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.
Representing GitLab on Twitter
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
From time-to-time, we also receive tweets that mention competitors in a negative way or about negative events related to them. Don't acknowledge these tweets, since that would violate our "Be friendly" policy.
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.
Respond with a quote and CC @GitLabSupport. Using a quote means pasting the full URL to the author’s original tweet into your reply. Check to make sure you are also replying directly to their account and not yourself.
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.
If a GitLab user would like to engage the GitLab team for custom consulting, for example to sponsor a feature, they can contact via this form: Development.
We post blog articles there if we think they are good and relevant.
Share "Inside GitLab" stories which highlight the people behind the product.
We post our webcast recordings there.
We post information for potential GitLab employees to show what it's like to work here.
We share jobs
We post links to relevant industry articles about open source, DevOps, or other trends and news.
Comments are enabled in the GitLab docs portal whereusers 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:
if the reply doesn't need any follow-up, use the checkmark icon as a reaction to the relevant chat message to indicate that the comment is answered
if the reply needs further clarification that the advocate cannot provide, start a thread in the relevant chat message by notifying the appropriate team(s) member(s) and urge them to reply to the comment
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:
Create an account on GitLab.com
For devops conferences we could have them set it up
Problem: Wifi will be an issue, need to have local mirrors/VM or something.
Create a project/clone a dummy project
Set up GitLab CI for the project
This can be tailored for the audience. Ex. At enterprise events we can use Java, at JS conferences we can use Node, generically we could use Python or Ruby.
Set up runners
Select a Docker machine to run tests on
Problem: Wifi is not always amazing at these events, so we will need to find a way to do this locally/in a VM that meets our min requirements
Walk through running tests
Do a TDD-style example test
If we’re at a language-specific conference, this is a great time to go over testing best practices. Can be skipped for generic events.
Walk through Docker+container registry
At devops-oriented conferences this should be a primary focus
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:
Twitter (schedule tweets up until the event and make sure to include an image for the tweet)
See if the venue has an event calendar/newsletter they can include the event in
Reach out to relevant meet-up groups to see if they'll share the information. Do not email the entire group directly or you might be banned. Email the group administrators instead.
Ask people (internally and externally) to share the information with their networks. Provide some example copy for them to use to make this easier.
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.