Fedora-Council/tickets ticket #550: A new community policy/doc on what to expect from the Fedora community

Project Discussion
1

@ankursinha filed Fedora-Council/tickets ticket #550. Discuss here and record votes and decisions in the ticket.

Ticket text:

7 Likes
2

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.

3

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.

4

@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.

5

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.

6

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.

7

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?

8

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.

1 Like
9

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.

1 Like
10

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
11

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?

12

@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.

  1. ↩︎

  2. No assistive LLM was used here - Not even for checking grammatical mistakes. Please feel free to correct oopsies as you find them. ↩︎

2 Likes
13

Thanks for doing this! Looks great! I’ve left a few comments/suggestions.

2 Likes