Karsten Wade

It's hard to be consistent with Free/Open Source practices, and it's a particular kind of hard when it's your role in the project to guide other people toward such consistency. In this session we'll share some compassion and then some ideas of how we can actually get together as a community of practice. And then we'll do some practice demos together! In putting energy toward working on our practices together, we center the importance of Open Knowledge sharing and building communities for those and of those whose work includes enabling others to be successful in using and contributing to FOSS. We help ourselves fix our own leaky roofs, make shoes for our own friends and family, and help return time to everyone’s days. To engage in practice in this session, we'll explore a perspective on how to read and use the Open Source Way, the guidebook for community management. Written by a diverse group of more than a dozen FOSS expert practitioners, the guide extrapolates and distills knowledge of not just what to do and how to do it, but also why to do it. The chapters and checklists are ready to use and/or modify, and Karsten will chop and mix them live in the session. How can this help you use the guidebook and practices? Whether you are leading or guiding a Free/Open project, an engineering team, or any group of humans looking to be successful working within FOSS projects, you are facing the need to teach and reteach (and reteach…) the same information and practices. People need to know what to do, how to do it, and where to do it, while you hope you get them to understand a smattering of why it all matters in the short time you have their attention. This practice demo follows 3 steps to take the detailed and specific practices in the guidebook, and remix them to fit your education and practice needs. The contributors you support then have a tool to guide them in successfully creating, building, and maintaining their FOSS projects.

tl;dr - contribute to a community management guide written for practitioners, by practitioners; bring your internet-enabled device.

Whether you are a community manager or any other contributor to a free/libre open source software (FLOSS) project, you'll find yourself learning and thinking of good methods and practices for having a happy, successful, and productive project. Community managers and members share these practices with each other all the time -- in talks, in person, as blog posts, and sometimes as a stand-alone book. But has anyone ever really collaborated on a guide that is for practitioners and collaboratively written BY practitioners?

Actually, yes: 10 years ago The Open Source Way 1.0 was written and released. In the passage of that decade, the best practices around caring for FLOSS projects have evolved, as has the work of the people in those community shepherding roles.

We have embarked on a revamp to this guide, and we invite you to comelearn about, participate in, and contribute to this living document real-time during this BOF.

We will begin the BOF with a brief introduction to the guide itself, what is covered within it currently, and an overview of the narrative being told from/to community management practitioners. We'll then get hands-on with the contribution process, starting with a walk through for what is needed for the 2.0 release. After we do some real-time submissions to the guide, the BOF participants can begin working together in small groups or individually on portions of the guide, including both content and publication toolchain.

EPEL is a repository of packages rebuilt from the Fedora Project and available for use on RHEL, CentOS, Scientific Linux, and other *EL-based rebuilds. At FOSDEM 2015 there was a hallway session (literally), where we discussed the challenges of EPEL for users and developers, how to work best across the Fedora and CentOS projects, and how the repository should evolve. This session for FOSDEM 2016 intends to build on that discussion with a round-table of key people from EPEL, Fedora, and EL-rebuilds to discuss amongst themselves and with the audience what's right, what's wrong, how to fix, and what the future of EPEL should be.

EPEL has long been the filler gap that makes using an EL-based distro more sane for people not versed in building and maintaining their own packages. Being a curated set of packages, there is a higher trust level expected of the EPEL contributors by the end-users -- a promise that things will go slowly (like the RHEL releases), won't break on minor update (like the RHEL releases), and won't overwrite packages in the base EL distro.

However, EPEL comes from a time when getting packages from your Linux distribution was the best and most trusted way to use vetted and secure software. Software is now delivered in more ways than an RPM package -- containers and cloud images to name two key methods.

With an active relationship between the Fedora and CentOS projects, there have been various proposals about where the build system and repository should exist. In addition, the CentOS Project has layered projects on top of the platform who use the SIG process to provide even newer software for their end-users, where EPEL is often a key dependency. There are a number of technical and social issues to consider in terms of how Fedora as an upstream and the EL rebuilds as downstream need to hold and consume the EPEL bits.

The audience for this discussion are the systems administrators and devops engineers who are end-users of EPEL, either directly or indirectly (because they use a container that builds from EPEL, for example.) They come from myriad situations -- academia, scientific computing, corporations, non-governmental/non-profit organizations, and so forth. Their key similarity is a reliance on the EPEL promise of slow-moving, curated packages and ease of use.

For this audience, the round-table is a chance to tell core EPEL contributors what is going well and what is a challenge in the current setup. It is also a chance to have a front-row seat and input on the future of EPEL from technical and community perspectives. Finally it is a chance for finding solutions with other technologies and forming the communities which can deal with new stuff/slow change.

People we have or are asking to be on the round-table:

• Dennis Gilmore -- Fedora Releng representative
• Brian Stinson -- CentOS downstream representative
• Heikel Guemar or Alan Pevec? -- OpenStack/RDO packager user of EPEL
• TBD -- CERN end-user representative
• TBD -- Scientific Linux downstream representative
• Karanbir Singh? -- CentOS technical and project lead
• Matt Miller? -- Fedora project lead/Board representative
• TBD -- an EPEL packager
• TBD -- another EPEL big end-user
• TBD -- Fedora Packaging Committee member