Developer Relations Events

1. You are here:
2. Handbook
3. Marketing
4. Developer Relations
5. Developer Relations Events

On this page

• Community events
• Evaluation criteria
• Event content
• Sponsorship
• Diversity, inclusion, and belonging
  • Event organization best practices

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

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.

Evaluation criteria

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

1. 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 which clearly 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).

In order 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.

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

Event content

The Developer Evangelism and Technical Marketing teams create content for events including managing the Call for Paper submission process and producing presentations, demos, lightning talks, and other content.

The Corporate Event Support of the Developer Evangelism handbook page contains more detail on how these teams support events.

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 in order for a GitLab speaker to participate.

Sponsorship

GitLab's Developer Relations team does not hold or allocate 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 team, 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 in 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/interpreter, in the worst case scenario. This depends on if 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 min 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.

## Resources

Additional information about events can be found on the Events page of the GitLab Handbook.

A list of upcoming GitLab events can be found on the Events page of our website.