Ray Paik

During the Covid-19 pandemic, we were all forced to move our events to virtual platforms, and we got used to attending events online. Even as our lives are returning to normal and people are returning to in-person events, I believe there will continue to be a place for virtual events as the virtual format offers some important advantages.

In this talk, Ray will discuss some of the advantages of virtual events, such as smaller resource requirements, simpler logistics, easier distribution of content, and opportunities for experimentation. In addition, virtual events do not need to be limited to tutorial-type sessions, but they can also be used to provide additional opportunities for community members to get together, network, and collaborate (e.g., for triaging issues, working on documentation, etc.). Even as life returns to normal, virtual events should remain an important tool–and complement what we’re doing with in-person events–for helping open-source communities grow.

Ray will also discuss some of the common mistakes and challenges in virtual events, such as limited opportunities for casual interactions, difficulty facilitating hands-on work, time zone challenges, etc., and how we can work together to mitigate these issues.

Recognizing community members is one of the most enjoyable activities for community managers. It is a great opportunity to thank people for their work and highlight their contributions to the rest of the community. However, we need to evaluate if we’re truly being inclusive with our community recognitions. For example, when discussing contributors, we still see a lot of emphasis on the volume of contributions on project repositories (i.e., code) that some may find intimidating. This focus on code is partly because contributions on tools like GitHub and GitLab are easier to measure and quantify.

On the other hand, it can be more challenging to measure (or even notice) how much a community member is helping others on platforms like Discord, Matrix, Slack, etc. When someone helps a newcomer by answering a quick question in chat, it’s easy to miss that among other discussion threads. Even though it can be more challenging to quantify non-code contributions, it’s crucial to look beyond repositories to see how people are helping to improve our communities. In addition to contributions in chat-like platforms, this can include sharing their use cases, participating in meetups, providing honest feedback in 1-on-1 conversations, etc. Looking across a broad spectrum of contributions will help ensure that we recognize everyone regardless of their background, interests, and skillset.

Also, not everyone is comfortable with public recognition. Some may feel uncomfortable being in the spotlight or even think what they have done is not significant enough (sometimes I see this with contributors from underrepresented groups). In these instances, it is important to find ways to let them know that the community appreciates their work without putting them in an awkward position.

In this talk, Ray will share his experience identifying different contributions, community recognition examples (both good and bad), and feedback he received on community recognition programs. There will also be a discussion on how inclusive recognition is vital for strengthening the sense of belonging in the community.

We often see many open source projects struggle with maintaining quality documentation and finding contributors who are interested in helping with project documentation. There are several reasons for this, such as many viewing documentation as a separate product from code or a belief that people will be able to make sense of what the code is doing by reading the code.

For these and other reasons, documentation work is often done at the last minute and done by people with low motivation and minimum effort. So the quality of the output will naturally suffer. These issues can be addressed by ensuring that documentation is everyone’s responsibility and that documentation is a core part of the product created using the same development and community processes. Besides, documentation is often an entry point for new community members and is a great place for early contributions. When everyone in the community is actively engaged in documentation--e.g., reviewing documentation fixes--it can help provide a valuable onboarding experience for new community members.

In this session, the speakers will share their experience in documentation from both foundation-based open source projects and open source software companies. There will be a discussion on how community contributions for documentation can be encouraged and how community members can apply their learnings from documentation to other areas of open source communities. 

Traditional open source projects involve contributors from different organizations with the goal of addressing a common challenge for participating organizations or even the entire industry. Today, there are also many companies with businesses built around open source software. At first glance, it may seem impossible to build an open and authentic community for a company-based open source project when you need to balance the needs of the company with those of the community. In this talk, you will find that there are actually a lot similarities between contributors in company-based and traditional open source projects. Additionally, it is possible to build a thriving community by satisfying the intrinsic motivation of contributors and providing opportunities for community members to have a voice in how the community (or even the business) is run. The presenter will also discuss how they transitioned from working as a community manager in foundation-based projects to a company-based open source project.

Some of the attributes of successful open source projects include welcoming diverse viewpoints, lowering barriers to entry, being responsive to community contributions, and remaining transparent about decision making. When you are building a community for a company-based open source project, there’s no reason why you can not incorporate most (if not all) of these aspects.

Additionally, community members often decide to get involved in an open source community (whether it is company-based or otherwise) because they are passionate about the technology, culture, and/or other members of the community. So when you are building a community in a company-based open source project, it is important to understand your members’ (especially intrinsic) motivations and to focus on cultivating an environment where community members can have a fulfilling experience. In your community, you may also be able to provide opportunities for professional growth (e.g. in programming, leadership, collaboration, and other skills) that community members can benefit from.

There are of course differences between company-based and traditional open source communities, and you will need to adopt different approaches in areas such as communications, community governance, metrics, recognition, etc. The presenter will be sharing their learnings, including their transition from traditional open source communities to a (for-profit) open source company.

GitLab is a complete DevOps platform, delivered as a single application, changing the way Development, Security, and Ops teams collaborate and build software. GitLab is also an open source project with a wider community of over 2,500 contributors[1] since we started as an open source project in 2011.

This meetup is for GitLab team members, users, contributors, and others who want to meet with community members attending FOSDEM. Anyone who wants to share their learnings from using GitLab and discuss how we can improve GitLab (both product and community) are welcome to join us!

[1] https://contributors.gitlab.com