A new community policy/doc on what to expect from the Fedora community #550
Labels
No labels
category
budget
category
code-of-conduct
category
docs
category
elections
category
events
category
initiatives
category
mindshare
category
policies
category
spending-request
category
Strategy Summit
category
trademarks
state
resolved
good first issue
help wanted
?
needs changes
?
needs reporter feedback
?
needs triage
?
needs vote
role
engineering
role
fca
role
foa
role
fpl
role
initiative lead
role
mindshare
scope
bug
scope
improvement
scope
new
state
approved
state
blocked
state
duplicate
state
invalid
state
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
council/tickets#550
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(Moving over from https://pagure.io/Fedora-Council/council-docs/issue/275)
We've always had people turn up on various channels and say "Fedora should do this" in different forms. A common request on the discussion forum, for example, is "Please add this package to Fedora".
Each time this happens, community members reply with the same information on these lines:
In short, that for most of us volunteers, it's a "best effort" system. We do what we can, when we can.
For package maintainers, we explain that package maintainers tend to maintain packages they use, so that they can test them out and keep up with them---and that they don't take on "packaging requests" unless they use the package themselves.
These conversations sometimes don't go well, because people making these requests are generally unaware of how we work. They are so used to the industry model where they pay for a service and so expect the service (and expect to be able to complain to "someone higher up") that when they're told that we're unable to service their request (for whatever reason), it can be perceived as us not taking accountability or that there's a lack of support towards our "userbase".
It isn't that we're not accountable, but that we follow a different model of accountability. The issue is that this is not set out anywhere in the community. Community members learn this over time, but people that are not community members apply the industry model of service/expectations/accountability to us, and that mismatch can create unpleasantness/friction.
So, I am wondering if it is possible for us to clearly set out how we work, and what users can expect from us somewhere, either as a sort of policy, or even just a page in the docs. Not only will it help people outside the community understand how/why/when things happen (or don't happen), it'll also give community members a resource to point to when such conversations do come up.
See linked Fedora Discussion topic for Ticket 550
Metadata Update from @jflory7:
Metadata Update from @jflory7:
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 the Fedora Discussion thread.
Metadata Update from @jflory7:
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.
It took me a while to get to this after completing the DevConf.IN 2026 organization duties but a pull request has been created here based on the original draft (and the subsequent edits) made here. Please feel free to review this inclusion and let me know if changes are needed.
PR #282 was merged. Thanks @t0xic0der for working on this! I am closing this issue as complete. 🌊