@ankursinha filed Fedora-Council/tickets ticket #550. Discuss here and record votes and decisions in the ticket.
7 Likes
I don’t think this necessarily needs to be a Council matter. The Council defines the project, yes, and we have it written in Fedora’s Mission and Foundations :: Fedora Docs.
But you need a more clearly stated answers to be used and referenced in the Ask Fedora, or Matrix channels and what not for the purpose of simplifying the life of the Fedora Ambassador and similar roles. Why would not you just create such an FAQ then?
A thread on Discourse could be a good start. And folks from various support groups should be able to collaborate and choose the right wording.
It’s not really about creating FAQs, although the document would help with that too. It’s about including/formally documenting expectations from the Fedora community in our mission documentation—and that is a council matter.
@jflory7 had replied (Making sure you're not a bot! ):
I believe this is a really important page to create, and I can think of more than a few situations where having some public information like this would be useful. I think there is a great opportunity for someone to try authoring this. If there are no other takers, then I might try and take a spin on this in early 2026.
Hmm…
In my wanderings through the ecosystem over the last decade, I’ve seen this as a pattern of behavior that’s increasing. There are a lot of “best effort” projects out there who have similar interactions. Which is another way to say, I have thoughts on this.
As someone who has been involved in the onboarding work of the Fedora Project, I understand just how discouraging it can be when a person is doing their best to be around, but that is not seen as enough. An agreed-upon documentation from the Fedora Council could be a good recommendation for newcomers on the extent of support they can expect from the community to begin with. This should help both sides, i.e. the experienced ones, with the understanding that they don’t really have to stretch themselves thin and the newcomer ones, with the understanding of why a certain request might be taking longer than usual.
That said, I would like to work on a draft for this, if folks don’t mind.
I concur with @ankursinha. Although it is not something that strictly falls under the Council, I believe this is a kind of guidance that is necessary, and other recent events in the community warranted this topic to come up to the Fedora Council. Ankur opened this Council ticket at the guidance of myself and a few others in the community.
I believe the Council has the wisdom and experience of the Fedora community to create something useful and accurate to help set expectations for newcomers in the community.
@t0xic0der Thanks for raising your hand here. It would be great if you could get a first draft going and share it back for discussion with the Council. I will assign the Pagure ticket to you in the meantime.
When is an appropriate deadline for a first draft? Do you think it would be possible to have one ready for the next Fedora Council meeting on 2025-12-17T15:00:00Z?
I do not like the idea of the Council starting to prescribe in a top-down matter, in a form of a policy, what and how drives the contributors of the project, and all the details of the interactions within the FOSS-community.
I also don’t like the idea of generating more policies which no one will read and apply.
So I am a bit concerned that we start to use council policies as our only universal communication tool.
The problem raised in the top post is described as “community members reply with the same information”. Meaning that we are not looking for an answer to a controversial question. We are looking for a way for already existing answers to be heard. Policies are not a good tool to make things heard. In this case you need education, not governance.
So before we go straight into drafting, I’d like to still talk about why we are doing it. How the new document is supposed to be different from existing mission statements and legal disclaimers, and so on.
2 Likes
P.S.
I am not saying that this topic does not deserve attention of the Council. I am just applying the previous experience with the AI-policy.
We also started with “let’s have some guidance”. We then spent a year on it. And in the end got a tiny policy which still sounds like legalese, and doesn’t cover any of the guidance we originally discussed. It is an important policy, but it is just a policy - a tool to enforce rules and processes, not to explain the culture behind them.
I’d like us to not fall into the same trap again.
2 Likes
I 100% agree that this should not be policy. I don’t think creating a policy that is rigid and anticipates mandatory compliance is what we are going for. As I understood the motivation and the intent, it would be to create a new page in the Project level documentation, which for better or worse, is primarily maintained by the Council, because these documents live together in the Fedora Council docs git repo. So, we are the one with the commit rights.
Rather, I see the proposed concept for a new page fitting the same role as the Upstream First page that we drafted earlier this year:
So, this is not policy, but rather, an attempt to make an implicit community norm into something more explicit. It is an opportunity to explain the unique dynamics of how our community naturally works together, and avoid scenarios where someone reports a bug to a package maintainer on Bugzilla, with the expectation that they will receive corporate-level SLA service agreement when they open a bug report. We all know that is not how Fedora works, but we have scenarios and conflicts arise where misunderstandings on this basic principle rise to the level of Code of Conduct situations even.
So, I see this as a useful opportunity for making something that has been implicit for a long time into something more explicit. Just like the Upstream First page did earlier this year.
I believe we very much want the same thing!
Does my context in this reply add any clarity to the motive?
1 Like
I think we agree on the goal now, but I am still not sure about the means to achieve it, and the Council role.
If the goal is education, and not governance, why do we try to centralize the effort and make it a Council responsibility instead of empowering existing community members to cover it?
We have Fedora Ambassadors, Join SIG and so on - folks who do work directly with users asking questions or posting complaints. Why we think that Council member is better equipped to create the educational materials than them?
I mean, yes I can try to write a doc like this, but not because I am a Council member. Rather because I had several years of prior experience as Fedora Ambassador actively participating in multiple flamewars and debates on a range of topics.
When we need a Fedora Wallpaper - we don’t ask Council to create a Fedora Wallpaper, we ask the Fedora Design group. When we need Common Issues we ask Fedora QA. Why do we expect that only the Council can write about the project culture?
I think that by making this task a Council task we weaken the role of Ambassadors, and overly centralizing this topic. While it could be a great opportunity to engage a large community.
If the only reason for this to become a Council task is the current location of the doc repository, maybe it is the wrong location to start with?
@jflory7 and @ankursinha (and everyone else), here’s the initial draft[1][2] for the guideline (not policy) document.
I have opened up the access to everyone with the link to be able to comment and/or propose their changes to the document.
4 Likes
Thanks for doing this! Looks great! I’ve left a few comments/suggestions.
3 Likes
@ankursinha Thanks for taking the time to make the suggestions. I have made those changes and then some more. Please feel free to take another look.
1 Like
Thanks for kicking this off, @t0xic0der. I’d like to triage this for our last Fedora Council meeting of the year next week.
Mostly because the Project docs module is owned by the Fedora Council. We have the delegated authority that nobody else in Fedora has. Therefore, I do see it as our responsibility.
I also see documenting cultural norms as something very different from making a wallpaper. Cultural norms are something that are often exemplified through leadership. A sense of legitimacy comes with this when it comes from the top-level of the Fedora Project and not an individual SIG or team. I think the Council is in a unique position to provide this level of guidance, especially in a way that overlaps with the Fedora Code of Conduct.
I disagree. Mostly because there is not a functioning, healthy Ambassadors group in Fedora anymore and sadly there has not been for a long time. I also think that running this as a Council process invites more feedback. For example, on the Upstream First Pull Request, we have 17 people weigh in on the proposal and share feedback on how it could be improved. This is remarkable; I have never seen any Fedora Docs merge request get more feedback from as many people as this one got.
Therefore, I think if we run a transparent, open process on creating this education material, and explicitly invite the community in to engage and iterate on it with us, we have the opportunity to create something that is truly community-influenced, versus it being in the niche of a single team or SIG to define something as significant as project culture and working norms.
I also believe in this specific case, we need some legitimacy on this topic that best comes from the Fedora Council, or at least in something that appears to “Fedora-wide documentation.”
1 Like
Discussed during the 2025-12-17 Council meeting.
The Council reviewed the draft policy from @t0xic0der that intends to manage contributor expectations regarding communication and response times in a volunteer-driven community. Debate arose regarding the effectiveness of a long-form document, with some members suggesting that an FAQ or “talking points” format might be more practical for resolving immediate contributor frustrations. Participants also discussed the potential role of automated responses to manage expectations, though concerns were raised about such automation potentially feeling disrespectful to reporters. The consensus was that while the intent is valid, the current format may need adjustment to ensure it is actually read and useful to the target audience.
An action item was assigned for Council members to provide specific feedback on the Google Doc and the broader concept on this Fedora Discussion topic.
2 Likes
Discussed during the 2026-01-14 Council meeting.
This ticket was briefly raised during the Open Floor section of the January 14th Council meeting. @t0xic0der noted that work is progressing and committed to providing a detailed asynchronous update directly on this ticket soon. The Council is standing by to review that draft once it is posted.
1 Like
Suggestions and comments to the documentation have been accounted for, and for the last week, the suggestions and comments have stopped coming. I wanna give folks one more week, until the next Fedora Council meeting call, beyond which I will begin with creating an ASCIIdoctor document based on the updated draft. If folks have not yet provided their feedback on the progress or want to provide some more of that, now is the best time to do so.
1 Like
Do you think it would be possible to get a Pagure Pull Request created before the next Fedora Council meeting?
Depends. I am kinda neck-deep with the Forgejo work and the Mindshare update.
Which namespace do you want me to make it against?
1 Like