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