F46 Change Proposal: Changes Discussion Only On Devel List

Project Discussion Change Proposals
,
42

This won’t be surprising, but: I’m for moving all Change discussion to one place, and I think that place should be here. It’s not just visibility. The tools for discussion moderation and management are significantly better.

I also think that our long-term user base can handle the change. Python did it — they moved their mailing list entirely.

As I said in the devel list thread, there are some big things we could take advantage of which we’re not. Rather than the messy wiki-markdown copy, we can make a workflow that starts here, with change proposals owning and editing the post until it’s ready-for-wrangler. This could use the Discourse form-template feature, which is significantly nicer than the “fill-in-around-the-comments” “template” in the wiki. I’ll try to make some time soon to make a little demo of this so you can see what I mean.

There are also some things we could perhaps publicize better. For example, did you know that the Project Discussion > Change Proposals category is provided (automatically) as an RSS feed? You can also get pretty much any Discourse page in JSON format, for easy ingestion into whatever lightweight tools.

7 Likes
43

For what it’s worth, this is easily done if so decided. (We’d just set the permissions for the category so that only the system user can reply. Or system user and FESCo members. Or whatever.)

I’m curious about your second proposed change (which could be done independently of anything else). Why would making the poll non-anonymous “make individual voices better heard”? Is there a problem this is solving? Might there be drawbacks? I left it off initially because I wanted to reduce the possibility of name-recognition bias influencing people adding their own opinions… but I didn’t, like, make that on any scientific basis.

As a matter of fact, the current polls are actually only anonymized not anonymous — the vote tallies are in the database linked to user accounts, and in fact can be exported per poll pretty easily.

44

Yes, I wanted to make the Discourse polls more analogous to leaving a short +1 or -1 type comment where individual users’ opinions are attributed to them, as opposed to hiding people who are trying to express their opinion through the poll. This Change proposes that FESCo would more closely consider the polls during decision-making, so I want them to be more transparent. For example, if we can see that members of a certain SIG or other constituency strongly oppose a certain change, FESCo may want to explicitly loop in that group before we vote on the Change.

1 Like
45

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

ok. Might reword that in the change to more clearly reflect that?

…snip…

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.

Well, but that happens to mailing lists too? If people post a bunch of
things all right after each other, there’s always a delay for the email
to get to the list server, get processed, sent out and get to your and
your client polls.

There’s no way you can be sure you have read all comments in either
case.

I was wondering if I should propose making all changes threads on
discourse automatically use slow mode. If someone is posting a bunch,
it’s unlikely they are taking time to read everything and consider it
anyhow. Perhaps that would help stress…

8 Likes
46

Done! Does it make more sense now?

Yes, but Discourse introduces an artificial delay on top of this.

I usually in-line reply to individual messages in separate posts in Discourse to keep my responses focused and in an attempt to maintain proper threading and legibility for people following via email. Enabling slow mode everywhere would hinder that, and I’m not sure that it’d do much to deter trolls.

47

While the split-brain is annoying and it seems that contributions on the discussion forums are, on average, a bit lower effort I don’t particularly mind reading both places and responding/asking questions in both places for the changes I’ve submitted (and reviewed, with my FESco hat on).

One place would be nice, but at the cost of creating camps and threats of ‘if its A everyone leaves Fedora!’ I don’t know if it’s worthwhile to consider changing this, it’s not for me.

4 Likes
48

I am a curious person so I spent some time and tokens to try to gather a little bit of data.

I analyzed distgit (rawhide branch) commit history from 2020-01 to 2026-07, identifying contributors by git user.name with bot accounts and known name variants filtered out. The data isn’t perfectly accurate (it’s upper bounds for new contributors, can have name splits, and only covers rawhide), but it’s good enough for trend analysis.

Michael Winters’ Fedora Data WG graph (shown at Flock) reaches similar numbers using a different methodology, monthly unique package committers. The two datasets align

Data & Scripts used (AI Assisted) : Making sure you're not a bot!

From what I can tell, Discourse was neutral, it didn’t accelerate packagers departures, and it didn’t accelerate arrivals either. I’ve seen the argument that it drove people away, the data says otherwise

Active packagers were flat at ~1,066 for four straight years (2021–2024), the period before and after Discourse was introduced for Changes discussions in mid-2023. The first dip is 2025 (−27), but it’s a continuation of a trend, not a platform-driven cliff. The decline in new packagers (285 → 164/year) begins before Discourse.

Breaking it down by activity tier (core 500+ → 129→124, regular 51–500 → 391→376, occasional 6–50 → ~370 flat): the core is slightly contracting, the mid-tier carried most of the 2025 drop (−24), and everything else is flat.

That pattern, a stable core slowly shrinking and reduced mid-tier retention, is an onboarding and pipeline problem, not a Discourse problem. If Discourse were actively driving packagers out, we’d see a step change in 2023 or 2024. Those are the two flattest years in the data.

To be clear, this data doesn’t address the split-brain problem itself, I understand that following two places is painful regardless of packager counts. But it does directly counter the claim that Discourse is pushing packagers away. Those are two separate questions, and the data answers the second one.I take the split-brain problem seriously (I acknowledged that in my earlier reply) and I understand why the Change Owners want to fix it. But the Changes process documentation says the process is “ultimately about communication, not gatekeeping.” and it is my opinion that Discourse has been successful at making the Change process more accessible and visible to the community.

The data says the platform change was neutral it didn’t cause the decline, and moving back won’t reverse it. The split-brain is a real problem and this Change fixes it, but separating discussion channels instead of fixing how we manage the existing one risks sacrificing the visibility gains Discourse brought.

3 Likes
49

This is very resonant.

I don’t want to keep bringing up the AI discussion every time, but I believe it is very relevant here.

One thing which caught my attention (in a very bad way) is how fast some appointed council members were to put blame for not providing/actioning feedback on the community and/or elected members, despite actively participating in the discussion and making some quite controversial statements themselves. This is just not healthy for the community.

Elections are part of delegated decision making process, and desire to have undiluted feedback from people who participate in elections is quite natural, but having such space has its own risks of becoming a hermetic echo chamber. If a random “drive-by commenter” can illustrate that something is a bad idea, having advantage of not being constrained by established social relations, among other things, then this something is definitely worth being reconsidered.

Edit: updated the first paragraph to be more accurate and clear, after revisiting the referenced topic. Updated the second paragraph to be more clear.

1 Like
50

From what I can tell, Discourse was neutral, it didn’t accelerate packagers departures, and it didn’t accelerate arrivals either. I’ve seen the argument that it drove people away, the data says otherwise

I think the picture is a little more complicated. Maybe the Discourse change hasn’t directly caused a reduction in packager headcount, but it has led people to burn out and reduce their participation in the project, even if they’re still quietly pushing commits and submitting builds. When this was originally proposed, long-time contributors were told that having development discussions on Discourse would lead to an increase in active contributors and that they should therefore “adapt.” To be honest, I was always somewhat skeptical of this “build it and they will come” idea, but regardless, it didn’t grow the active contributor base in the end.

And this reminds me of another point. It was mentioned that this Change would create a visibility problem, but I think the fractured discussions that we currently have pose a much larger visibility problem. The people who “solely stick to Discourse” and vice-versa are still not getting a full picture of the discussion. And Change Owners aren’t either, in some cases, which causes important feedback to be missed and proposed Changes to get stuck in limbo. Hopefully, having one discussion per Change will make things clearer.

51

I think the distinction between packagers and contributors is important here.
The data I shared measures packagers. On that metric, Discourse was neutral. It didn’t help and it didn’t hurt.

But what Discourse did, IMO successfully, is bring more contributors into the process, people who follow Changes, provide feedback, vote in polls, advocate for their use cases. I’m an example myself: I haven’t submitted a dist-git commit in years, but I consider myself an active Fedora contributor.

Those two groups overlap, but they’re not the same, and the health of the community depends on both.

The data shows that declining packager numbers is a pre-existing trend that Discourse didn’t cause. Moving discussion back to the devel list won’t reverse it, that problem needs different solutions. But it will make the Changes process less visible to the broader contributor base that Discourse reached, and I think that would be a loss.

I think I’ve made my points on why I don’t think this is the right move, and I’m not sure I have much more to add :smiling_face: .

Thanks for listening

8 Likes
52

My first post in the discussion about this Change Proposal. But this doesn’t mean that I haven’t been listening… I have read all the comments, many of them very well thought out and insightful, and I think the overall summary must be that this is a complicated problem without one good solution. It’s more of what is the least bad option to pick.

Some comments in random order:

  • “split brain” —: this is the issue, it causes additional work, duplicated communication, and cognitive overhead for people. I hear when people say it contributes to exhaustion.
  • lack of threading on d.fp.o — another real problem. In fact, for me, following discourse discussion in the email client is often easier than dealing with the wall’o’text on the web forum.
  • following of d.fp.o threads via email client — apparently the experience depends a lot on the client and user setup. Reading single posts is OK, digests are misformatted. People who don’t use threading and/or folders, get their inboxes flooded. So a bit of a self-created problem, but I also understand that people can’t easily change their whole email setup. We could alleviate issues here by describing setups that work.
  • quality of discussion in the two places — I think the stance that the mailing list is so much better is grossly exaggerated. It is even enough to look at this topic in the two places. The mailing list has a few “+1”-style mails, and the discussion thread has blog-style posts with graphs, data, and detailed reasoning. I don’t think that the place matters that much. If people happen to make less useful posts in one place, and we move them to the other, they will make the same posts there.
  • “burnout of fesco members” — I get it that some folks are tired, but I don’t think it’s appropriate to generalize that to all members, in particular Kevin or me.
  • participation from different groups — this is the part that is so hard to measure and evaluate. With d.fp.o, it’s so much easier to subscribe to specific topic and/or start participating in a thread. The mailing list works great if you’re subscribed, have a good email client that does threading, etc. I assume that most packagers fall into this category. So if we’re trying to optimize for packagers, the mailing list is fine. It’s not great for fringe contributors and participants, but if we have to make a choice which group to prioritize, existing packagers must have higher priority.
  • participation via hyperkitty — after testing this myself, and seeing other people do this, this seems to be a functional workaround. It certainly is “good enough” to make an occasional post without subscribing to a mailing list.

In summary, I think that moving to one place is reasonable to avoid the “split brain” situation. And the mailing list seems to be a better choice for the target group and the discussion types that we have to prioritize. But leaving discussion.fp.o and losing out on the additional visibility boost there does not make me happy.

On the question of how to not lose visibility if we move to the mailing list, there have been some ideas, but no clear answer yet. I think it’d be worth to explore the options with read-only mirroring…

53

I’ve been wondering if a two-way sync would be possible as well.

54

I agree that the discussion of Changes should happen in one place.

But I think it should be discussion.f.o - and I am saying that as lover of emails and mailing list.

The discussion.f.o gives me a space to add emoji reactions to a post instead of writing an email with “+1”.

It is also worth noting how many reactions to THIS Change have been sent to ML and to discussion.f.o. :slight_smile:

2 Likes
55

This is yet another case where periodic census/survey/poll would be helpful.

1 Like
56

You repeatedly say that Discourse failed to bring the contributors, but if you look at the Change discussion threads, you will see that you got new people participating in them via Discourse. They maybe do not participate in the way the ideal spherical Fedora contributor in a vacuum is supposed to participate, but they show up.

And it means Discourse serves its purpose in making things more accessible.

The issue is that we do not know what do next, once it does. We brought new people, but we are now burning out from actually talking to them.

It is indeed a problem, but going back to hiding from people in a dark corner behind an artificial barrier is not solving anything.

The things I would consider doing instead:

Increase the split-brain

Don’t panic yet, let me explain.

The current split-brain is created based on the wrong criteria - the tool used for communication. We try to assign some imaginary meaning to that criteria, like a “better quality of discussion”, but it is a lie.

But there are different approaches which can be used to structure large discussions.

One model is the lines of support

The other is rounds of hearings.

Both are essentially examples of a “split-brain” situation, but done in a controlled way so that they help process the input from different audiences without making it particularly overwhelming for a small chosen number of decision makers.

How it might work in our case?

In the first round of news-making Change announcements have a link which points to a communication channel dedicated to Fedora Changes but not read by FESCo at all.

It would be a catch-all place, a first line of support for questions like - What is Fedora Change, will this change impact my user workflow, is there a workaround for this particular problem? etc.

It can be a Discourse thread. It can be a Matrix channel. It can be both. Owned by the Join SIG or other support-oriented groups.

Change Owners would be encouraged but not required to participate in them.

In the second round create a proper discussion thread where FESCo can participate and discuss the change in details.

Have it heavily moderated so that any non-useful comment will be removed without any need for explanation and justification.

In the third round move to a pull request in the Git Forge for a formal vote and approval.

Have a shortcut to go directly to the third round for certain changes.

7 Likes
57

As the change wrangler, I am in favour of finding a way to centralise feedback on changes when they are announced to make it easier for everyone to keep up with the conversation. (It would also reduce my workload by only needing to post the change in one place - so yay, a little less work for me :slight_smile: )

My 2c is is that the change process is the mechanism/process that FESCo uses to manage each Fedora Linux release. That is a big task, and if the current process is making that difficult for FESCo members to do, then I am glad we are looking at changes to make this easier.

I would like to resuggest @bcotton’s suggestion he made on the devel-list: use the email lists for the announce and discussion, and post one post linking changes announced on discourse highlighting that the changes are live. This could be a potential middle ground. I also lean to batch-posting changes, so this means there would be one post every week/every few days containing the current changes announced, their summaries and links to their posts on the devel-list.

I do like @bookwar 's suggestion in point 1, but Im not convinced the changes process should be included as a way to get new contributors to the project. I feel like someone proposing a change to Fedora Linux is already part of the project for a time, so maybe its a way to retain contributors? I dunno, thats a topic for another thread in any case :slight_smile:

4 Likes
58

Change digests on Discourse were proposed in the first draft of this Change (before I submitted it) as suggested in the earlier discussion, but I figured it’d be best to preserve that same information (only the link to the wiki, link to the devel discussion, and no full-text reproduction of the proposal text that is already present on the wiki) in one post per Change so that everything is better organized and we can keep the straw poll bot working. Does that still work for you/seem reasonable?

59

Yeah that’s fine for me @gotmax23 . I honestly am happy to row in with whatever FESCo would like to do with the process that keeps things easier to manage and track the discussion part, as that’s the most important part, imo.

60

For last few years, if there is one thing I hear every time a topic of Fedora problems is approached from any side, it’s this one.
Split-brain and adding more work and mental load to the Doers. (mainly Change owners + FESCo)

Without Doers, nothing can ever be done, while Observers are welcome, but ultimately expendable. (and Recipients are just consumers not interacting with the community at all)

All of these people want more people to be the Doers, as everyone benefits. But in practice few step in themselves.

Lately I often hear the Doers saying their experience degraded. And the Doers thinks the benefits (mainly much larger Observers involvement in Observing - discussing, but not Doing) are simply not worth it. Otherwise we wouldn’t have this discussion in the first place.

The essential personnel - the Doers - are asking to revert back, because the current situation is painful to them.

So unless some Oberver(s) (or anyone) step in to become Doers and architects of a solution that would remove the pain, I think the Doers are right to propose - and even force the action to protect themselves. (as that protects the existence of the project)

(Could the solution be fresh new implementation of a better Discourse < - - > Mail threads bridge?)

No need for a discussion where everyone agrees?
I think mailing lists get solid traction on topics the participants see controversial.

i think it supports my take - this change favors Mail people so they mainly agree, while it affects Discourse people, so they mainly oppose. And opposition creates traction.

I agree and it IMO supports my previous sentence, as the groups would not mix (much); just some Mail people (Change Owners, FESCo) are forced to watch both, while no Discourse people are.
(OK, maybe depends on whether any Mail people converted, but let’s not split hairs?)

I think we all have the idea of the benefits the Discourse discussion of Changes brought, and we don’t need to iterate over that to such extent. The larger audience discussing is great.

It’s not that mail people are ignorant of Discourse people. I think we all value useful engagement of more of community members.

Instead of a discussion trying to convince the other side that my side is better, I’d rather see discussion that simply splits to:

  • can we solve it?
    • IF YES - who will be the Doer that will save us?
    • IF NOT - protect the Doers. (which IMO mostly translates to Mail users)

As any FOSS project rise and falls on having (ideally happy) Doers.

I support the revert to just mailing list, until a reasonable technical solution is found and implemented.

4 Likes
61

The Doers have nothing to lose but their chains. They have a world to win.

Obviously, it is highy inconvenient and frustrating to have routine day-to-day communication spread across many different platforms. But it is hard to force something to not being discussed elsewhere.

This is a weird sentence. If we take it to the extreme, some most important and overlooked point may be made in the middle of yet another flame fest on Phoronix forums or over a communal meal. Better awareness results in better decision making. Utlimately, it is the goal of the ideal decision maker to have all information which can be had. Obviously, there are diminishing returns, it impossible to track and process every thought (until Neuralink is ready and being implanted into everybody right after birth by the decree of Unified Government of Earth) and bandwidth of the decision makers is finite, so the line has to be drawn somewhere.

“All I am aware of is the mailing list and I want to feel good about myself” is a perspective one can have, of course, but in my mind it is not compatible with adequate decision making. Non-adequate decision making can threat existence or well-being of a project as well.

Doers of the world, unite!