F46 Change Proposal: Changes Discussion Only On Devel List

Project Discussion Change Proposals
,
1

ChangesDiscussionOnlyOnDevelList

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Starting with Fedora Linux 46, discussion of Fedora Changes as part of the Changes Process will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will continue to be announced on Discourse in read-only topics to provide a bridge between the two platforms. This Change aims to improve communication by avoiding having two separate mediums for the same discussion.

:link: Owner

:link: Detailed Description

Starting with Fedora Linux 46, discussion of Fedora Changes as part of the Changes Process will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will be announced on Discourse in read-only topics with links to the wiki page and devel discussion for each Change to provide a lightweight bridge between the two platforms.

This Change aims to improve communication by avoiding having two separate mediums for the same discussion. The current “split brain” approach has been a significant pain point for Change Owners, FESCo members, and other project contributors attempting to follow Changes feedback discussion. Contributors have noted this as a cause of burnout.

If technically feasible to use on read-only Discourse threads, we will keep the bot enabled that creates non-binding polls (“How do you feel about the proposal as written?”) to collect community feedback on Changes. We will also adapt the bot to disable the anonymous results option on the Discourse polls so individual voices are better heard. FESCo will consider the polls alongside feedback on the devel list when voting on proposed Changes.

:link: Feedback

There was some pre-Change discussion in “How can we improve the Changes Process?” (Maxwell’s summary/takeaways) on the devel list. This discussion was covered by LWN in Fedora grapples with change § Changes to changes.

Additional feedback was provided in a discussion in the #devel room on Matrix. Feedback about Changes Discussion on Discourse was largely negative. Multiple contributors expressed that the current state of Changes discussion led to burnout.

Q/A:

  • Why not just use Discourse for all Change Proposals and stop discussing them on the mailing list?
    • The Change Owners do not wish to alienate or exclude existing contributors who rely on the mailing list workflow to participate in discussion. Other Fedora development discussion takes place on the devel mailing list, so it does not make sense to migrate only Changes discussion. Additionally, we believe that Discourse is an ill-suited platform for long, threaded discussions surrounding Fedora Changes. This position was discussed in more depth in the Matrix and devel list discussions linked above.
  • What about the email interface for Discourse?
    • The email interface for Discourse is not comparable to a mailing list, and it de-prioritizes email users. The Discourse email support delays sending email notifications, makes formatting look out of place on responses sent via email, and email users miss out on reactions and other types of engagement. The ability to reply by email does not solve the issues with Discourse as a platform.

:link: Benefit to Fedora

This Change aims to address a significant pain point in discussion of Fedora Changes. This should also simplify the Change Wrangler’s work.

:link: Scope

  • Proposal owners:

    • Update documentation and FESCo issue templates to clarify that the devel mailing list is the canonical medium for Changes discussion.
    • Work with the Change Wrangler to implement the necessary process changes.

  • Other developers:

    • Change wrangler: Announce Changes as usual on the devel-announce list. Stop copying and formatting Changes Proposal wikitext to/for Discourse. Create read-only posts on Discourse with links to the Wiki post and lists.fedoraproject.org discussion thread for each Change.
    • Implement the proposed Changes to the Discourse voting poll creation bot. If these Changes are infeasible, disable the bot.

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

:link: How To Test

:link: User Experience

Users, contributors, Change Owners, and FESCo members will all have one less place to follow for discussion about proposed Fedora Changes. Changes will continue to be announced on Fedora Discussion, and anyone currently subscribed via Discourse can follow links to the corresponding thread on lists.fedoraproject.org, which provides a lightweight web interface (Hyperkitty) to respond to list threads. Additionally, we will no longer post misformatted Change proposal texts on Fedora Discussion, instead providing a link to the canonical proposal on the Fedora Wiki. If technically feasible, the community feedback straw polls will remain enabled on Discourse.

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2026-07-22T16:13:59Z

Last edited by @amoloney 2026-07-22T16:13:59Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

As someone that soley sticks to Discourse - I think this would be dreadful change. I don’t think alienating a subset of users is the way to go.

9 Likes
4

This seems like a sensible and uncontroversial step that could be actioned separately from the larger Change Proposal here!

1 Like
5

As someone who likes to follow Changes but not participate, I would appreciate if responses were mirrored to Discourse.

Though I recognize this is probably very difficult and not worth it to implement.

6

One key argument for this Change is that the current “split brain” causes burnout. But for many contributors, the mailing list itself is a source of burnout (high volume, poor threading in email clients, difficulty following fast-moving threads, and the feeling of inbox overwhelm)

Discourse’s web UI lets people engage on their own terms: browse by topic, catch up selectively, and participate without flooding their inbox.
If discussion moves solely to the devel list, those who find mailing lists draining will be forced to either endure the format they find burnout-inducing or drop out of Changes discussion entirely. That seems like a step backward.

8 Likes
7

There one thing about email, though, is that you get to pick your email provider, and your MUA separaetly. I personally can’t stand Gmail web UI’s threading, while @ngompa is fine with it; I deal with mailing lists via either Evolution or mutt and use Fastmail instead of Gmail. Choice is good.

I’d strongly suggest setting up mailing list filters anyway, nobody should ever see mailing list emails in their inbox instead of in dedicated folders.

This is a reasonable question to raise (though as you noted it will likely be very difficult to actually implement). Given there are links to the mailing list archives, would that suffice to keep up with the discussions?

I’d also note that you can actually reply to the mailing list right from the archives, without being flooded with all the discussions, - provided you’re logged in.

1 Like
8

A dreadful change for who?

I am all for gathering feedback and fostering healthy discussions.

But Discourse is … not that. At least not how we’ve been doing things.

The way many discussion threads for Change proposals have “evolved” since we started having discussions on Discourse (as an experiment!) is a major source of frustration, angst, and burnout for FESCo members. I know of at least one FESCo member who explicitly said they didn’t want to run for reelection because of the “discussion” culture here.

So if we’re speaking about alienating people, then the current system alienates current FESCo members - some of which avoid Discourse entirely, if they can, and probably also potential future FESCo members - who see how things are going and just decide not to run for election. Neither is a desirable outcome for a fully community-elected leadership body.

1 Like
9

A dreadful change for those the change owners wish to alienate which I do admit I include myself in so my bias may be showing.

I understand your point however there is way more users than there are Fesco members so I think that argument falls a bit flat.

Burnout happens all the time and even in this thread there was talk of the mailing causing burnout so seems both are bad as each other depending on who you talk to.

I’ll be the first to admit that I don’t have an answer on how to solve that but alienating a set of users to not alienate another set of users isn’t the way.

2 Likes
10

I’m sorry, but that comparison just doesn’t work.

Change Owners and FESCo members are supposed to follow and participate in discussions for Change Proposals. Others can participate and leave feedback, but this is entirely voluntary.

1 Like
11

The Change Owners are not trying to alienate anybody — please don’t assume malice. Improving community health and avoiding burnout and communication breakdowns are explicit goals of this proposal.

We do not think continuing to discuss Changes in two different places is in line with these goals or sustainable long-term. Between the mailing lists and Discourse, the Change owners view the former as the better choice. If folks want to read further, there are links to previous discussions about the myriad issues presented by dual discussion mediums and Discourse in particular in the Feedback section of the Change. The primary issue that I see here is the split discussions which have been a real cause of miscommunications between owners of Change Proposals, FESCo, and others; choosing a single platform addresses this.

This Change explicitly mentions the steps (read only announcements, public Discourse polls, Hyperkitty) attempting to bridge the gap between Discourse and the list. I understand that it’s not perfect, but it’s much better than the current untenable situation.

Anyone who’d like to provide constructive and respectful feedback on Changes are currently welcome and will continue to be very much welcome to do so via email or Hyperkitty. The proposal also emphasizes the Discourse straw polls that will remain available and proposes turning off the anonymous results feature to better gauge community sentiment.

5 Likes
12

If gathering feedback from the wider community is important, then Change Proposals are best suited to be discussed on Discourse.

This seems to illustrate that community feedback doesn’t weigh that much though. Maybe it’s just unwanted noise that this Change Proposal wants to address. While that could make sense, it is IMO still a step backwards in terms of openness.

2 Likes
13

To be clear, I do not think anyone, including myself, is assuming malice. I understand that this is primary aimed at Fesco/change owners burnout/overload/fragmentation pick your poison etc. However alienation doesn’t require the intent to be real.

I’m generalising here and only going on my gut but moving discussion back exclusively to a mailing list forces a lot of non-packager/casual contributors to a platform they don’t use just to have a voice. Polls and read-only posts treat Discourse members like spectators rather than participants.

3 Likes
14

Minor things:

  • “Starting with Fedora Linux 46” is not very clear. You mean, starting with
    46 change proposal submissions (which can be anytime now)?
    When Fedora 46 is released?

  • according to discourse docs you can set poll results to:
    Always visible: Default poll results.
    Users can always see the results of the poll, regardless of if they’ve voted.
    Only after voting: Users must vote before they can see the results of the poll.
    When the poll is closed: Poll results will only be revealed once the poll is closed.
    Staff only: Only site staff will be able to see the poll results.

On email interface to discourse:

"The Discourse email support delays sending email notifications, makes formatting look out of place on responses sent via email, and email users miss out on reactions and other types of engagement. "

The delay is 5min. It is there in order to allow someone to edit
obvious typos or the like before the email copy goes out.
If this is some kind of major problem (although it’s not clear to me why it would be)
we could remove the delay.

Missing out on reactions and other types of engagement… this is also
100% the case for the mailing list, no? Since it doesn’t have those things
at all? I personally don’t think they are that important. It’s much more important
to get feedback on the change in actual text form.

In general:

I’m not really in favor of this. I would prefer if we come up with some way
to allow both groups to contibute. I thought that the mailing list folks who
are mostly long time contributors would be willing to adjust to allow for new
voices or could use the email interface to discourse to avoid some of the pain,
but it sounds like in at least the change owners case thats not the case and
currently they see too much pain.

I suppose some folks here will use hyperkitty and post to the list, but
many may not and that would be unfortunate.

4 Likes
15

Community feedback is welcome and valuable, and I do recognize that the audiences on discourse and on the mailing lists are different (with ~some overlap).

The goal of this proposal is not to “alienate” people (and I do think that this is a rather strong word to use here). The goal is to ensure that the decision making process doesn’t eventually break down as stakeholders learn to avoid the discussion platform - which would be a worse outcome, in my opinion.

If we continue to have discussion for Change Proposals on Discourse, I think at the very least we’d need much more active moderation, and more liberal use of “slow mode”.

16

I actually agree on that latter half - I only used alienate as that’s the word the change owner used for a reason not to move fully to Discourse so I in turn used it to argue against moving to mailing list fully (see below).

1 Like
17

I’m generalising here and only going on my gut but moving discussion
back exclusively to a mailing list forces a lot of non-packager/casual
contributors to a platform they don’t use just to have a voice.

And moving discussions exclusively to Discourse forces non-casual
contributors, the people regularly volunteering their time and expertise
to improve Fedora, to interact with a platform they don’t like to
maintain their level of participation in the project. I don’t want to
harm our dwindling Fedora packager base. We have given Discourse a fair
shot, in the hopes that it would increase active contributors to Fedora,
and it has only caused pain. Also, many of the Changes proposed are
about lower-level, technical issues and don’t receive feedback from the
wider community in the first place.

Keeping the cross-posting status quo is a worst-of-both-worlds
situation, I think. The “split brain” is real problem. For example, in
some cases, Change Owners miss feedback from one of the platforms, which
leads to FESCo rejecting or delaying or delaying approval of Changes —
because we actually do care about feedback!

Polls and read-only posts treat Discourse members like spectators rather than participants.

I purposefully emphasized the polls in this Change as a way to
increase constructive participation in Change discussions. This Change
proposes that these polls should be considered together with the list
discussion; they were not consistently paid attention to before.

Consider these two scenarios:

  • A bunch of “Strongly opposed” straw poll votes and some more focused
    discussion on the list (whether the poll voters or list posters each
    contain active contributors, casual contributors, or ideally a mix)
  • The previous discussions for controversial changes with list
    discussion alongside 300+ post Discourse topics that became circular and
    repetitive and hard to follow due to the lack of proper threading and
    lead to chaos and numerous CoC violations

Both scenarios would likely lead to the Change being rejected by FESCo
(i.e., the negative feedback “having a voice”), but the first one
doesn’t burn everyone out.

2 Likes
Possibly controversial things to say in regards to the dwindling packaging base
18

To be clear, I’m not arguing for moving to Discourse exclusively.

19

Minor things:

“Starting with Fedora Linux 46” is not very clear. You mean,
starting with
46 change proposal submissions (which can be anytime now)?
When Fedora 46 is released?

Correct, for proposal submissions that target Fedora 46 or greater

according to discourse docs you can set poll results to:
Always visible: Default poll results.
Users can always see the results of the poll, regardless of if
they’ve voted.
Only after voting: Users must vote before they can see the results
of the poll.
When the poll is closed: Poll results will only be revealed once the
poll is closed.
Staff only: Only site staff will be able to see the poll results.

I think we should change it to always visible. That was what I intended
when I wrote the Change.

On email interface to discourse:

"The Discourse email support delays sending email notifications, makes
formatting look out of place on responses sent via email, and email
users miss out on reactions and other types of engagement. "

The delay is 5min. It is there in order to allow someone to edit
obvious typos or the like before the email copy goes out.
If this is some kind of major problem (although it’s not clear to me why
it would be)
we could remove the delay.

For active topics, the discussion keeps moving on in Discourse and then
you are responding to the (n-3)th post since Discourse has not sent you
the latest state of the thread.

Missing out on reactions and other types of engagement… this is also
100% the case for the mailing list, no? Since it doesn’t have those things
at all? I personally don’t think they are that important. It’s much more
important
to get feedback on the change in actual text form.

Indeed, this is a relatively minor point, but the idea is that these
reactions exist on Discourse but are not reflected on the email interface.

I thought that the mailing list folks who
are mostly long time contributors would be willing to adjust to allow
for new
voices or could use the email interface to discourse to avoid some of
the pain,
but it sounds like in at least the change owners case thats not the case and
currently they see too much pain.

Yes, it’s not only us. We received similar feedback from other long-time
contributors (see the Feedback section). For me, the problem is not
primarily “Discourse is bad,” but it’s “two separate but concurrent
discussions are really bad.” I tried to emphasize the second point in
the proposal.

20

I believe there should be a middle ground here somewhere. For routine technical changes that occur with each new version of fedora (update python, golang, lua, etc. to a new version x) that don’t typically break or change user experiences - ok I don’t see a problem, let the developers focus on their work.

But to apply this same standard to all change proposals (especially controversial ones) is moving towards a lack of transparency and engagement; potentially starting a decoupling of the community from the development process. This proposal’s fundamental premise is to limit the participation of discussion on change requests to those who actively work on development.

Also even though the straw poll would remain with the change proposal listed…there would be no way from the ‘read-only’ post to understand why there is disapproval for a particular proposal. If there is no “why?” Does the straw poll have actual meaning at that point?

You may also see similar/near identical change request topics/threads pop-up instead posted by community members who want to actually discuss these changes on discourse…creating- you guessed it- more redundancy not less.

Another option may be to set a hard limit for discussion time on change proposals, and/or delegate mods to handle and relay feedback if the devs don’t want to directly deal with whatever is on discourse.

Some of the friction that comes with “controversial” change requests stems not just from the rules but also from a lack of acclimation and shown benefit. Step by step introduction and roadmaps are always welcome. Showing benefit: If someone proposes an ai desktop the first thing to consider is how does the user benefit from the proposal and then clearly show it… example: as a powerpoint or a youtube video. Let’s say someone is a photographer…who wants to quickly organize a massive number of photos based on sharpness and image quality and hide/separate/remove photos that are blurry or out of focus. And then wants to upscale them to a set resolution. Wouldn’t that be a fantastic use case for ai, to save that photographer’s time instead of them going through each photo one by one. When we have future discussions about ai put the user first and all of a sudden you will see more support. Just having a platform is not enough, users need to see the use cases in action, that is how you build support and concensus.