Peter Boy came to Fedora documentation the way many contributors do, by seeing a gap and deciding to fill it. As a researcher, writing is his daily work. When he looked at how he could meaningfully contribute to Fedora, documentation was the obvious answer. He started with Fedora Core 1, stepped away, and returned in 2020 when both the Server Working Group and the Docs Team were being revitalised at the same time. Since then, his focus has been on the “bigger-picture” content structure, readability, consistency, and inspiring others to get involved.
His first Flock was in Cork, Ireland in 2023, and what struck him most was the collaborative approach combined with open, structured dialogue and the sheer range of personalities all genuinely trying to get to know each other.
For a team like Docs, where so much depends on shared standards and careful communication, Peter sees Flock as irreplaceable. New ideas emerge from spontaneous conversation, something the formal structure of video calls simply can’t replicate. His message to anyone thinking about contributing? Fedora needs far more than technical contributors. Documentation, communication, community building these are all vital, and Fedora needs to do a better job of making that visible. At Flock 2026, he is most looking forward to the working groups and the hallway conversations, the ones that are simply too nuanced to have any other way.
Flock to Fedora 2026 takes place June 14–16 in Prague. Registration is at capacity but you can join the waitlist. Can’t make it in person? Follow along live on the Fedora YouTube channel.We hope to see you there!
Note: AI (Google Gemini) was used in drafting this article. The content was reviewed and verified before publishing.
Can we have a ICS or something to add to the calendar? or even a link to the flock calendar?
I’ll be watching on YouTube.
I wanted to say this is not a Fedora only issue but one thing that stops contributors is attitude from some people.
I had joined the Quality Team, even checked with them on Matrix whether or not a particular issue I was having was a bug and where it should be filed.
I was told to file under a certain category, do I did and the response from one of the devs was basically, “It has nothing to do with this” in a way that I found confrontational and not really recognising that someone was contributing with a bug report even if it was filed under the wrong thing (even though I had checked.)
I guess devs are not communicators and I don’t know how one fixes this across the Open Source world, especially when the main issue is that people are stretched so they don’t have time to babysit new contributors. But it did make me basically not want to triage that issue further. Usually I follow through bugs I report and test them as soon as the dev responds with a fix, but that interaction was discouraging.
I don’t know if we need some sort of buddy system or just have a few people who take care of the new contributors, check in with them and communicate feedback to existing contributors if stuff like this happens, but I feel there is a risk then that those mentors who might get the flak instead.
@ananya
I would recommend doing a more thorough review, you got @pboy 's name wrong in the first paragraph
Sorry Peter!
I’m sorry to hear about your experience. That’s not OK. If you felt it wasn’t in line with expected behaviour as codified in the Fedora code of conduct, please do flag it to moderators or even the CoC committee.
It’s ok to not be a good communicator, but we still have to follow the CoC. That’s not optional.
We do have this place, please come speak to us!
and:
Do come and talk to us in Join, even if we ultimately cant resolve any particular issue, we can show you that a lot of us do communicate well, and welcome you to many parts of the project.
Hey all, sorry I took a bit of a break from testing as I got rather busy with work, I didn’t just disappear.
I’ll look into the buddy system that @ankursinha mentioned!
It’s okay, it was just a bit confrontational, but I don’t think it broke the code really. It’s just I think someone who was really busy, I was trying to file bug for the upcoming Fedora 44 at the time while in beta. They probably were dealing with a lot of work due to the upcoming release themselves. And they weren’t wrong, they weren’t the ones who should have fixed it, I was told they were, but in hindsight it was the wrong instruction. And things like that happen.
I find in almost every open source project, devs seem to have their set of conventions or expectations, some of them clearer than others. And perhaps they think they deal with people who always know what they are doing, but some of us are a bit newer and would still like to learn. And a lot of the “read the manual” crowd might forget that instructions have to be understood by someone who doesn’t have the same context as the people who wrote those instructions.
I have had people in another distribution criticize me because I had posted a bug where wher code
didn't look like this. I had actually lost the formatting between me drafting the post in a text file and copying it into the bug post.And they ignored the bug itself, which frustrated me to no end because it prevented some PCs from booting with that kernel, and that was more important than how code looked.
When I posted this same bug in Bugzilla for Fedora, it got patched, so Fedora never shipped the kernel with the regression. So I already feel you guys do try to focus on what matters compared to some other places
(although the formatting was fine that time.)
I think it’s a bit of a general “cultural” divide between new people and veterans, rather than a breach of code
Given that a buddy system exists, the solution I mentioned is already in place. I will look into it.