Dear Mailing-List user, you are welcome
to participate in a productive and forward looking manner
on this discussion.
And the lists not on many of us. Makes it difficult to get a community wide idea of the topic. If this proposal get accepted, I wish we do get at least the topics display in a subcategory in Discourse.
This way we can follow the issues and catch them when they enter over ask fedora, and offer workarounds[1].
It definitely would make the ask fedora section more agile and would integrate new users more into the community, guiding them towards to the lists for other topics not listed on the change set.
Making visible that such changes are to improve security etc. âŠď¸
That is not what I asked for. I meant that we can display the lists topics like rpm6 as read only linking to the list where it is discussed. That we can filter them with tags.
The first contact with the Fedora Community is for a vast amount of users Discourse.
Neither did I. Iâm just pointing out that the fundamental problem is having two unconnected places for discussion a topic, and that fundamentally leads to all manner of issues. This isnât the âhow should Fedora change discussions be handledâ topic though, so lets leave it at that.
Ok true, i made in the Site Help & Feedback category a topic and took the off-topic part out of it.
I am agree, that we not have to tell each other what our tools should be. However to have an Idea where and how things work makes sense. And thinking of bringing things together also makes sense right?
Since I signed up before covid, we are talking about to find a common tool to exchange information, between several groups in the Community. Discourse was the choice for forum, discussion and announcements.
While we do introduce changes before they will be made, we would also like to be able, to see the path how we do get there. That is why my question in the other topic. I agreed that we were off-topic. However this not means that we do have to discard the idea for approximation.
In discourse I made a Topic (this one) to talk about this idea. If you (lists user) prefer to talk this somewhere else, please let us know where, that we are able to find a way to participate.
Maybe we could create a FAS group âdiscourse-listsâ, which a discourse user has to be part of to get some experience with lists. Using the email they used while sighing up. So we can see which group of users is interested in this experiment.
@pmatilai hope you understand that I not just talk to you personally rather than to a group of âFedoriansâ which are interested to make a step ahead, for growth and new ideas
I think a read only link to the mailing lists is not an inherently bad idea.
How much traffic do the mailing lists get? Iâm subscribed to about five lists and I rarely get any mail from them.
There are probably other lists that have heaps of mail. Maybe development lists??
The downside to having lists linked here is that they become more visible to lay-users who might âget in the wayâ of the advanced developers. The change proposals we see on discourse are comprehensive, is that enough?
Another idea would be to pin a link somewhere in Discourse directing people to sign up to mailing lists. Everyone has an email or three, so doing that is not very difficult.
I agree, and I strongly believe we need to pull people here. Mailing lists are a barrier to participation, and if we keep that as the center of conversation, the project will slowly die. I two years ago, I proposed shifting, but to be honest, lost momentum and energy after the RH layoffs.
We could look at mirroring more lists â I want to do devel-list and test-list, at least. It wouldnât be really hard to mirror discussion lists too (more work to copy the archive, but that should happen eventually too).
Itâs enough that if youâre not experienced with setting up mailing list filters, itâs overwhelming.
although, something is broken and it doesnât have enough traffic to make it easy to figure out what, ughh âŠď¸
Can I quote you on that in a proposed talk from the Join SIG?
I think this is really interesting. Iâm pretty new here, Iâve been watching and talking with people in various channels for about a month now. My presumption was that there is an elite group of developers who are wanting to keep people out of development issues. But you are saying that if we donât onboard many more people over the next say five years we will lose all the developers to attrition. What I thought might be seen as a downside is in fact required.
Do you (Matt) have evidence (charts, graphs, spreadsheets) of developer and contributor numbers over the past ten years? Iâm super keen to analyse these issues.
I agree with your sentiment about the viability of mailing lists into the future, but at the same time I still find myself engaging with fedora change proposals on the mailing list much more than the forum. If Iâm honest, I think both options are suboptimal & outdated, as is our use of the wiki for writing the proposals in the first place. For example, the wiki text gets snapshot, and copied over into the forum & mailing list, where we can debate it, but if the change owner makes iterative changes to the wiki those arenât visible on the forum/mailing list. Then we have the bugzilla tickets for each change, and the FESCO tickets doing approval. None of this leads to an effective workflow IMHO.
Ignoring our historical practice, if I was designing a change proposal process from scratch, I would expect to have a Git Forge repo, containing markdown text files, with one branch per Fedora release. New proposals would come in as merge requests, they can get reviewed and debated in-context of the authoritative document with no copy+paste of text, and approvals would again happen in context. A CI job could publish all approved docs per release. The question of mailing list vs discussion forum shouldnât even arise IMHO. A change wrangler would have much less administrative work to-do to shepherd things along, which could only be a good thing, given the impact Fedora suffered from the unexpected departure of our previous change wrangler.
Yes, I know thatâs glossed over lots of subtleties & pros/cons of various options, and of course our historical baggage, but my general point is that the entire Fedora change process is frozen in time using a workflow thatâs been outdated by modern project standards for a good 10 years.
One thing I have learned is that the number one reason things have been stuck in place in different procedures and tooling is that the most important job of Fedora Infrastructure is: The ~spice~ sorry the builds must flow.
I think most of the items you listed have been on the planning boards for at least a decade, but keeping the build system working 24x7x365 as best it can while dealing with ever increasing compilation and artifact delivery requirements eats up available time and energy. What ends up happening is various parts get written as prototypes and either stopped there or included in some part of the infrastructure as âfix in productionâ.
Many of the out-dated tools which we have are there because random things require them and fixing any one of them requires more resources than have been available.
The wiki is bad, but replacing it would completely break parts of the release cycle as QA tooling requires it. To replace that would require some rewrites of tools on a front and backend from the people who are trying to keep bodhi/greenwave/openqa from blowing up at any point.
Most other tools in the process tend to quickly get used by multiple different teams to fix some problem they have. This means that turning off any one of them turns out to be a long list of âwhy did X break⌠it doesnât call dead-Y⌠oh it calls G which calls ⌠which waits for Y and is timing out but not broken.â
Looking at how much of large projects like Fedora and Debian have âfrozenâ infrastructure which just changes either during a crisis or at glacial waits⌠I think it is easier to set up such tooling methods with a completely new âOSâ organization where the enthusiasm and must-run technical infrastructure is low.
Exactly, if you have a rpi5 and you want to get info, you have to sign up the dev mailing list. This is a busy list and not really a pleasure to dig thru. The idea of displaying would be filter for tags.
I think having tags is not an option in lists? I thought filtering topics about keywords and tag them.
This will give a totally new experience to read a mailing list.
With the setting here in discourse I can tracking such topics. And get notifications here. So I can see without digging in the lists, what is going on and while helping here, everything can be done with the discourse interface. I do not want to discuss there, I want to gent a notification of a specific change/information, also to act as an interface between newbies with technical background.
This way we can also slowly guide them to the lists, if they have the desire to know more and bring their knowledge into Fedora.
I am talking from the point of view of a person with 50+ of age. So do understand when someone wants to keep on a infrastructure they used to use. However making tests and try new things not means we will from day x work this way.
That is why I proposed the FAS group. This way we can prepare this users to participate and tell them the netiquettes for the lists. Eventually also make a restricted list to make tests without disturbing or get disturbed from web-crawlers. As soon we do have something to show we make it visible for all to fine tune it.
Learning by doing in a gentle and slow way, taking into account our own limits and the limits of others.
If you want to elbow people to discuss the changes on Discourse, seems to me thereâs a simple enough way to do that: cut the change proposal body out of the announcement emails. Taking my rpm proposal (that started this discussion) as an example, something like:
Subject: F43 Change Proposal RPM 6.0 (system-wide)
---
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.
Summary: Update RPM to the upcoming 6.0 major release.
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-wide/146855
---
Itâs of course still possible to reply to that on email but not being able to quote makes it annoying enough that at least I would head to the discussion instead.
Yes, some people will find it annoying. But the current situation with two disconnected discussions is annoying to everybody, and also detrimental for the process.
The last thing I want is, to force someone. In the other hand, while reading this with the wiki, that it has to be copied screenshots, would solve two things at once. Then Discourse lets you create a wiki and using templates is also not an issue. It is also possible to post per email.
I do not know how far a list can be configured, that answers on a specific list show up in discourse. This would create duplicated content, however it would be more a guiding than a elbowing this way, right?
What it not would solve is, the possibility if discussions in several lists (about the same topic) would be held. I do not know how far this is an issue?
