Community Relations

1. You are here:
2. Handbook
3. Marketing
4. Community Relations

Maintained by:

On this page

• Our mission
• Meet the Team
• How to reach us
  • Chat with us
  • Email us
  • File an issue
• How we work
  • Community Team resources
  • Our handbooks
  • Our workflows
  • Our guidelines
  • Our calendars
  • Community Relations OKRs
    • How we update our OKRs
  • Community Relations KPIs
• Team Budgets
• Community Diversity, Inclusion and Belonging
  • Event organization best practices
  • Other ways we foster diversity, inclusion, and belonging

Our mission

At GitLab, our mission is to change all creative work from read-only to read-write so that everyone can contribute.

The Community Relations team supports this mission by working with our community to ensure they receive support and recognition for contributing to GitLab. Contributing to GitLab can include blog posts, code, documentation, discussions on forums/social media, meetups, presentations, translations, UX design, and more. We also support educational institutions and open source projects to host their work on GitLab.

Meet the Team

How to reach us

Chat with us

• On the internal Slack instance: by visiting the #community-relations Slack channel, or by tagging the @community-team
• On the public Gitter room

Email us

• Please use the e-mail address specific to each program

File an issue

• File an issue to work with us: See our project management section to find program-specific workboards where you can file an issue

How we work

Community Team resources

• Community Relations project management
• Common program resources

Our handbooks

• Community Operations
• Code Contributor Program
• Evangelist Program
• Open Source Program
• Education Program
• Startups Program
• Developer Evangelism

Our workflows

• Community Operations response workflows including Code of Conduct violations.
• Developer Evangelism Community Response Process

Our guidelines

• TBD

Our calendars

We use team-wide calendars for collective notification and to manage team logistics and events. Specific teams within Community Relations, might have their own calendars, such as the Developer Evangelism calendar.

• Community Relations Team
• Community Events

Community Relations OKRs

Every quarter, we work on team Objectives and Key Results (OKRs) that align with company OKRs.

How we update our OKRs

To update our list of current OKRs, team members create a new epic in the Community Relations project, and tag it with their program-specific label (e.g. open source program education program etc), as well as the red OKR label. The naming convention we use for OKRs are: FY-Year-Quarter OKR: Description of OKR.

We use issue health indicators to help people understand at a glance whether the OKR and its key results are on track needs attention or at risk.

Community Relations KPIs

The Community Relations team has several Key Performance Indicators and related Performance Indicators.

1. Meetups per month (target: 20) 📊
2. Wider Community merged MRs per release (target: 400) 📊
3. Developer Evangelism Monthly Impressions (target: 600000) 📊
4. GitLab for Education Quarterly Active Seats (target: 1000000) 📊

Team Budgets

Learn more on the Community Operations budget page

Community Diversity, Inclusion and Belonging

In alignment with GitLab's core value of Diversity, Inclusion, and Belonging (DIB), the Community Relations team seeks to purposefully design DIB into every facet of its programs and operations. We seek to foster DIB at GitLab and within the wider GitLab community.

This section is meant to document tips and best practices that the Community 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: 4 pm UTC - 8 pm UTC for EMEA and NORAM, and 2 am UTC - 6 am 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: 1 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 imparied. 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 deaf 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: Keep having a virtual even option even when in-person begins again!

Other ways we foster diversity, inclusion, and belonging

• Images: We seek to promote the use of images that represent a diverse group of users, customers, and community members. When we see a lack of diverse representation, we speak up and actively help update those images when possible.
• Speakers: As event organizers and participants, we seek to include a diverse set of speakers in events that GitLab organizes or touches.
• We are open-minded: We actively seek feedback and keep an open mind about our current policies. We are open to change and are willing to make structural changes to ensure that we continue to foster DIB among our team and the wider GitLab community.
• We retain a growth-mindset and keep learning: We read articple, attend workshops, and participate in trainings that help educate us about how to foster DIB in our community and how to be inclusive ourselves.
• We encourage a diverse set of community members to participate in research: We recognize the product inclusivity is important and that we need to build with our community, not just for them. We encourage a divers set of community members to participate in our First Look product research program.
• We promote the GitLab Diversity Scholarship program: This scholarship supports Diversity, Inclusion, and Belonging-focused events financially.