Developer Relations Events

Events are a great way for GitLab and the Developer Relations team to connect with customers and the wider GitLab community.

Types of Events

The Developer Relations team regularly attends the following event types:

• Community Events
• Corporate Marketing Events
• Field Marketing Events

Community events

GitLab’s Developer Relations team regularly organizes virtual events including GitLab Hackathons and community office hours. We also support in-person contributor days and community-organized meetups. Many of these activities are organized through the GitLab network page on Meetup.

Corporate Marketing Events

Corporate Events include conferences with large attendance such as KubeCon, AWS Re:Invent, as well as user conferences (DevSecOps World Tour), and internal conferences (GitLab Summit).

To learn more about Corporate Marketing Events, See the Corporate Event Marketing at GitLab Handbook page.

Field Marketing Events

Field Marketing Events are events that strategically support the Large, Mid-Market & Public Sector go-to-market teams at a regional level through in-person and virtual interactions.

To learn more about Field Marketing Events, See the Field Marketing GitLab Handbook page.

Evaluation Criteria for Event Attendance

When deciding how Developer Relations should support an in-person event, we use the following criteria:

1. The event will take place in a Tier 1 or 2 country. Tier details are in the internal handbook.
2. More than 1,000 attendees with a (content and audience) focus that aligns with GitLab’s marketing strategy as detailed in the internal handbook.
3. GitLab is a sponsor.

The Developer Relations team will prioritize events that meet at least 2 of these criteria, however, we may not be able to support all events that meet these criteria. Events that do not meet these criteria will be considered if there is a compelling business case to attend (ex: keynote opportunity at a 500-person event in a priority market).

To effectively manage team member travel and time, we prioritize who from our team will attend in-person events using the following criteria:

1. Team members will not attend events during scheduled PTO.
2. Team members who live within the region of the event will be given priority whenever possible.
3. Team members will not attend more than 1 in-person event per month.
4. Team members will not attend more than 1 in-person event outside their region per quarter.
5. No more than 2 Developer Relations team members will attend any event.

Note: For virtual events, we will assess the opportunities on a case-by-case basis given they require less time and travel from the team.

Evaluation criteria for partner and community events

For events that are organized by partners and members of the wider GitLab community, we require that organizers provide the following for GitLab team members to ensure their participation:

1. Registration page, which must be live and shared with the speaker 4 weeks in advance of the event
2. An update on registrations one week before the event
3. An enforced, public Code of Conduct to ensure it is a safe environment for all contributing. If needed, event organizers are welcome to use GitLab’s Community Code of Conduct.

These steps will help us ensure that the events will have a sufficient audience to justify the time and cost spent preparing for and attending the events.

Event Content Generation

The Developer Advocate team creates content for events including managing the Call for Paper submission process and producing presentations, demos, lightning talks, and other content.

GitLab team members who are seeking support for a speaking opportunity should review the Speaking Resources in the handbook. This page documents the process for a team member to secure approval including the requirements an event must meet for a GitLab speaker to participate.

Event Reporting

1. Search in Google Drive for TEMPLATE: DevRel event report: [EVENTNAME YEAR] to access the event report slide template.
2. Make a copy of the slide deck and add event insights, results, and new learnings.
3. Add the results deck to the event epic.
4. Share an update in Slack.
5. Add to the DevRel end-of-week updates document.

Event Content

The Developer Advocate team holds a pivotal role in generating content for events. The content we generate includes:

• Lightning Talks
• Demos
• Event Booth Training
• Event Presentations
• Code Challenges

Note: The types of content generated depend on the event being supported.

Lightning Talks

Developer Relations team members engage at events by giving lightning talks. The session length ranges from short (5 minutes) sessions to long (20 minutes) sessions, depending on the event requirements. Team members, GitLab partners, and wider community members present the lightning talks.

Talk topics provide a range of informal, technical, and cultural insights, sometimes enriched with a live demo when time permits. The topics are aligned through a lightning talk CFP in collaboration with the corporate events team, for example, at KubeCon NA 2023 (internal).

A recommended structure for lightning talks is as follows:

• Introduction (1 min): Introduce the topic and the value it brings to attendees.
• About the Author (1 min): Introduce yourself, and your role, and provide social media handles
• Main Content (13 min): The main presentation
• Questions and Answers (5 min): Leave time at the end for answering user questions

Note: Providing a link for attendees to download a PDF of the presentation allows our audience to maintain a connection with GitLab and gather resources even after the presentation is complete. Including QR codes pointing towards relevant links is highly encouraged.

The content of the lightning talks should be related to the theme of the event (for example: If a security conference, the lightning talks should revolve around GitLab Security and Governance Solutions). Here are some examples of lightning talks given at KubeCon EU 2023.

Demos

The Developer Advocate team is responsible for building demos for the booth staff to leverage when showcasing GitLab features to customers. The demo environments consist of:

• GitLab.com Demo Projects
• Click-through Demos

Note: If you feel more comfortable with leveraging your demos over the ones we provide, that is completely okay. We provide and maintain these demos for your consumption.

GitLab.com Demos

GitLab.com demos are projects that can be run live at a conference, during sales calls, webinars, and much more. They allow you to show either the DevSecOps platform as a whole or focus on individual components as needed. The available environments are as follows:

• Simple Notes - The Complete DevSecOps Platform Demo: This demo environment shows various aspects of GitLab, from setting up a CICD file, adding templates, running security scans, managing vulnerabilities, and much more. It also provides a full usage tutorial.
• Ask Me Anything - GitLab Duo AI Demo: This demo environment shows various GitLab Duo features from Explaining and Summarizing Code, Issues, and MRs to Suggesting Reviewers and Explaining Vulnerabilities.
• GitLab Flow: This demo environment covers the GitLab flow from planning to deployment (including monitoring). GitLab features such as Feature Flags, GA4K, Flux, Kubernetes overview, Compliance Pipelines, Operational container scanning, GitLab Duo, CD are covered.

If those demo environments do not suit your needs, you can view our other demo projects which are sorted by use case. You can also check out the CS Shared Demo Library for ready-to-go sales demos created by other solutions architects.

All Developer Advocacy maintained projects are documented in the projects handbook. Conference-specific demos are maintained in the gitlab-da/conferences group.

Note: Before demoing using these projects you should familiarize yourself with the project and its instructions provided in their README. The projects are meant to be cloned and used within your own space.

Click-through Demos

Click-through demos are demos that can be run offline as well as be used as self-guided training. They are linear and primarily used to showcase a particular feature, and are a great asset for those with less experience in delivering demos and in environments where there is limited internet connectivity. The available click-through demos are as follows:

• GitLab Duo (AI)
• Workspaces
• Feature Flags
• CI Overview

Note: To enhance performance and reduce reliance on the event’s Wi-Fi network for events, it is recommended that you download the click-through demos locally onto the booth laptops. You can obtain the HTML files for this purpose directly from here.

Event Booth Training

The Developer Advocate team also provides training and guidance to the booth staff before the event. This training and guidance entails:

• Going over the available demo environments
• Providing instructions on how to deliver a demo
• Providing a list of commonly asked questions for the event
• Addressing booth staff questions

How to deliver a demo

In many instances, an event attendee wishes to see GitLab in action and understand the value that GitLab could bring to their organization. The following steps provide insight into how live demos can be delivered successfully and how they can highlight the value GitLab could provide their organization.

Note: This guide assumes that you are using the Simple Notes - The Complete DevSecOps Platform Demo however, you can easily tune another project to apply a similar delivery.

1. Explain how GitLab is the most comprehensive DevSecOps platform which enables you to:
   • Manage, Test, Deploy, Secure, and Govern your applications all from one place.
   • Leverage AI to speed up your workflows across the complete SDLC
2. Begin by showing how simple it is to get started with using GitLab:
   • Show a .gitlab-ci.yml file and describe how a pipeline is defined
     • Show the built-in templates, explaining how they can be used to automatically add different jobs to your pipeline
   • Show the pipeline in action, and explain how extensible pipelines are and how they can be tailored towards your needs with rules
     • Further, explain each stage, and how we go from building and pushing to our container registry to deployment to Kubernetes (or other any medium)
3. Jump into the platform-tools
   • Create or View a GitLab issue, explaining how it can be used in Agile planning
     • Show the AI feature that can quickly summarize an issue, saving developers time in deciphering large issues with many comments
   • View a Merge-Request, and explain how a Merge-Request is moving code from a feature branch to the default branch. Explain that it runs a pipeline and can be blocked if failures occur, etc.
     • Show active Security Policies and how they prevent insecure code from being merged into production.
4. Jump into security tools, security is the main part of GitLab Ultimate which we want attendees to leverage:
   • View the Vulnerability report, and explain how it allows you to triage and manage vulnerabilities and enables collaboration between the security team
   • Dive into a Vulnerability and show the AI: Explain this Vulnerability feature, and show how it allows the security team to assess and remediate risk with ease
5. Conclude by explaining how all these features are provided with GitLab Ultimate.
6. Make sure to scan the lead and add a note based on their interest. This will be added to Salesforce.
7. Provide the lead with collateral, business cards, etc. and explain how they can get a free 30-day trial of GitLab Ultimate

Note: These steps provide you with generic demo steps that showcase many of the areas where GitLab provides value. If an attendee wishes to learn about specific features, those features should always be showcased first before moving on to other parts of the GitLab platform.

Commonly Asked Questions & Answers

Common questions and corresponding answers can be found in the “Event Booth FAQs” Google Doc for the appropriate event.

Note: These are common questions likely to be found at each event. However, if events are specific to a particular field, expect the questions to be more around how GitLab addresses a particular problem in that field. For Example, at BlackHat (a Security Conference), you are likely to be asked how GitLab solves particular security problems. These questions and answers are typically found in the messaging doc for the event.

Event Presentations

Speaking at events is an essential path for our team to connect with the wider GitLab community and the tech community at large. We love to support team members and members of the wider community on their presentations, too.

CFP

The Developer Advocate team directly contributes to the wider community by speaking at conferences themselves. The team also supports and manages responses to CFPs for team members across GitLab through issue boards.

Speaker Enablement

The Developer Advocacy team provides support to new and experienced speakers where necessary. These can range from presentation reviews, CFP ideation, or dry-run sessions. You can learn more about the different resources and activities you can benefit from.

Note: People who regularly speak about GitLab may be interested in joining the GitLab Speakers Bureau.

Code Challenges

Code Challenges provide a way for event attendees to get directly involved with using and/or contributing directly to GitLab. These challenges involve solving a particular problem using GitLab. The challenges are usually hosted at events coordinated by Developer Advocates in collaboration with the corporate events team, and other teams.

CodeChallenge.dev is the application used to create challenges tied to features in GitLab. You can review the application’s documentation on how to use the application.

Please use the Code challenge checklist template to create a new Code challenge issue for the event. Review the requirements and use them as a guide to ensure every component is in place. Add the new code challenge issue into the event epic in the event roadmap.

Sponsorship

GitLab’s Developer Relations team does not hold or allocate a budget for event sponsorships. All events sponsorship requests should be directed to Corporate Events or Field Marketing. Please follow the decision path for suggesting an event for sponsoring.

Diversity, inclusion, and belonging

This section is meant to document tips and best practices that the Developer Relations team, and GitLab teams should keep in mind as they plan events and activities.

Event organization best practices

• Tools: We purposefully think about the tools we are using to engage our audience. For example, some people in the open-source world may not be able to use tools that are proprietary software. Also, some people in certain countries may not be able to use certain tools because of country restrictions. Sending a survey beforehand with different tool options could help identify good tools to use for a specific event.
• Time zones: We try to be as inclusive of as many different time zones as possible. It is recommended to have 4-hour segments to spread out participation. Possible times: 16:00 UTC‒20:00 UTC for EMEA and NORAM, and 02:00 UTC‒06:00 UTC for APAC and India.
• Code of Conduct: We make our Code of Conduct a requirement at all GitLab events and actively help our community with friction and conflict.
• Accessibility: We advocate for accessibility in all of our events and materials.
• Captioning and Interpretation: Having both captioners and interpreters for online events is important. There are differences between American English and American Sign Language, for example, so captioning alone is not enough. Having a dial-in relay service would work as a “hack” to captions/interpreters, in the worst-case scenario. This depends on whether the blind person has a video phone/captioned phone to access these services.
• Share slides beforehand: One week before your online event, share the slides with attendees so that people who use screen readers can follow along.
• Images should have alt text: This is for screen readers for people who are blind or are visually impaired. Be descriptive with the image. Maybe a few sentences about what the most important content is.
• Use proper headings in your editor: Use your editor’s headings so that screen readers understand the organization of the page.
• Introduce yourself descriptively when you give a talk: In talk intros, briefly describe what you look like so that people who are blind or visually impaired can create a mental image of what you look like and associate that image with your voice.
• Schedule breaks with the 30:5 rule: Make sure to have a 5-minute break after each 30 min section.
• Describe infographics with audio: Describe the most important parts of infographics to help with accessibility.
• Hybrid events: Provide a virtual option next to in-person events.

Additional Resources

Additional information about events can be found on the Events page of the GitLab Handbook. For a list of upcoming GitLab events see the Events page of our website.