Quick admin prefaces:
- Changed category.
- Changed title.
- Paused topic until 2023-12-19T08:00:00Z.
Hi folks. I suggest we take a deep breath and pause here. We are no longer on the original topic (a Discourse bot) and I worry there is talking past each other. I preface this with a reminder about the Fedora Friends Foundation:
"The Fedora community is made up of people from all walks of life, working together to advance free software. There is a place in Fedora for anyone who wants to help, regardless of technical skill level, as long as they believe in our core values.
Like any friends, we occasionally disagree on details, but we believe in finding an acceptable consensus to serve the interests of advancing free software."
I know personally that the people replying in this topic care a lot about Fedora. We care about doing quality work. We care about collaborating together as an open community. We care about contributing to Fedora being enjoyable and not painful. Somewhere along the way, there seem to be disagreements on how to keep up with the best ways of doing good work, collaborating together, and keeping it enjoyable.
I have short-term and long-term ideas on where we can go from here.
Looking at now
Right now, I sense confusion over one is supposed to contribute and how contributing works. In this confusion, some words made people feel like their work is not valuable and underappreciated. This is a serious accusation in Open Source communities, where often we rely on the merit of our work in the community to speak for ourselves and our capabilities.
Yet even if not intended, words can have intentions we do not expect. Knowing that, let’s assume good intentions first and lean into the Fedora Friends Foundation mentioned above.
First, I request better documentation how the process is supposed to work. During the drafting process, collect feedback from Fedora Docs contributors about how to make the process work well for everyone.
The Fedora Docs Team is one of the oldest teams still active in Fedora. There is a lot of history that comes with that. The tools we used 15 years ago changed, but many git-based workflows remain the same because that has not changed. But while some things are similar to 15 years ago, some things are not.
We want Fedora Docs to be accessible both to our ongoing and persistent Fedora contributors and our newcomers. To do this best, it requires both good documentation and contributor outreach.
How to improve
The biggest challenge I see right now is documentation for the process, not the tools. I reviewed about existing docs for how someone is instructed to contribute to Fedora Docs. I checked the team’s authorship docs, team’s infra docs, and Quick Docs guidelines. The below quote from the authorship docs was the only content I found describing the process and not tools:
The 4-eyes principle applies to the Fedora documentation. A different author reviews each contribution. When you complete your text or text modification, the system creates a “Pull Request” or “Merge Request” to integrate your text into the documentation body. This triggers other authors, board members or members committed to the part of the documentation body in question, to start a review and either initiates an inclusion or starts a discussion. Allow 2 to 3 days for an answer to a request.
Many words used here describe features of the tool. It is missing an explanations for the following:
- 4-eyes principle
- Who are the authors, board members, or members
- What happens in an answer/review?
- What happens after the first review?
- How does someone propose changes to the Fedora Docs Team that are not about documentation? What about contributions that don’t look like Merge/Pull Requests?
- How does someone participate at different levels?
Making this information is clear for old-timers and newcomers alike. So, this is a great “bugfix” opportunity for the Fedora Docs Team. By leaving this bug unchecked, it leaves room for miscommunication and confusion. By “fixing” this bug, we can invite feedback from other Fedora Docs contributors with a clear ask and build a strong process that works well for everyone.
@pboy, could you help with this by creating a first draft of how things are structured today? A HackMD pad could be a good place to start.
Looking at later
The challenges we see here are not new, not in Fedora and not in other Open Source communities. There are challenges that come from keeping up with the best ways of doing good work, collaborating together, and keeping it enjoyable.
I have two longer-term pathways forward that could help support the Fedora Docs Team in 2024:
Community Operations 2.0: The Fedora Docs Team should fully own thoroughly documenting their contribution process. But outreach should not be the team’s shoulders alone. Community Operations 2.0 could help the Fedora Docs Team by promoting the updated contribution process in various contributor channels and increase awareness about how and where to get involved with Fedora Docs.
Reviving Fedora Mindshare Committee: We need a strengthened Fedora Mindshare Committee with incoming feedback from the Docs Team. Through this topic, I learned there is a Fedora Docs Board. I am hesitant about Fedora Mindshare teams creating their own boards to manage change because this was the founding vision for the Fedora Mindshare Committee: a common group to coordinate decisions among non-engineering Fedora teams.
So, this is a good chance for us to check in and ask, is the Fedora Mindshare Committee working as designed? If not, in what ways can we redesign it for 2024 and make it work well for everyone? We could consider an in-person Fedora Hackfest to enable this too.
This was a lot of text. But I know folks here care about Fedora. So I am doing my part by giving my care that this discussion is taken seriously and it is also something we can work out as a community.
So for now, let’s unplug from this for a couple days. When we come back, I look forward to hearing what folks have to say about making our current situation better.