On Sun, Jun 28, 2026 at 1:22 PM Maxwell G <[email protected]> wrote: > Hi everyone, > > I've been thinking about the Changes Process recently and how we can > improve it for Change Owners, Change Wranglers, FESCo members, and > participants in Change discussion and feedback. I'm not officially > proposing to change anything now, but I wanted to put some ideas out > there and see how people feel about this or if anybody has other > ideas/thoughts/opinions. > > --- > > Any changes to the Changes Process should go through the Changes Process > or a similar community feedback process. > > We need to be aware of other processes/teams/scripts that consume > Changes so that they can be adjusted accordingly. > > The policy should encourage requesting unofficial "pre-feedback" on the > devel list before writing or submitting an official proposal for > large-scale or potentially controversial/disruptive Changes. This > happens sometimes right now but not always, and I think some Changes > could benefit from this optional extra step. > > We should move away from the Wiki and wikitext formatting. Wikitext is > yet another text markup format that we use in Fedora that is not > familiar to everyone, and it's apparently hard to parse > programmatically. We could consider storing metadata about Changes (such > as targeted release, change owners, status, FESCo issue number) in a > structured way using Markdown front-matter that tools that work with > Changes can easily consume. > > Changes should be written in markdown, or a markup format that can be > easily converted to markdown or bbcode for display on Discourse, and > also for plain text emails. If we use asciidoc, that would allow us to > publish approved Changes to docs.fedoraproject.org which might be nice. > > We should store Changes as text files in a git repository. Change owners > would propose Changes by filing a PR against the repository and then the > Change would be announced after the Change Wrangler reviews and merges > the Change text. We could have CI checks to validate Changes (e.g., to > make sure that system-wide Changes have the correct optional fields) and > various other opportunities for automation that we don't have with the > wiki. > > Discourse should _not_ be the primary source of truth for Change > Proposal texts. I've heard suggestions to use it for this, since it's > one place and already supports markdown-formatted text and is currently > used for discussion, but I don't believe it's a good place to store and > work with Changes. There's not a good way to programmatically access > Changes if they were stored in Discourse. Forum software is not meant > for archiving anything. A repository of plain text files is > better-suited for this purpose. > > This part doesn't have to go along with a migration away from the Wiki > that I am suggesting, but I wanted to float the idea here. I think we > should consider whether to stop announcing Changes on Discourse. > Cross-posting to Discourse was proposed as an experiment in fesco#2989, > but there was never a decision made about whether to stop or continue > with the experiment. I find the fractured discussions between devel@ and > Discourse hard to follow. I think the Discourse setup makes it easier > for discussions to "accelerate" or become toxic or repetitive. I don't > think it's any better at handling large threads.
I really like the idea of updating the change process. I can't speak to the specific problems that FESCo experiences with the current implementation, but it touches on a few things that I do know about and I want to mention them for your initial round of feedback: 1. Bugzilla is definitely going away sooner or later. I expect to hear more about the responsible team's plans later in July. So whatever part Bugzilla plays in the current process, expect it will need to migrate. 2. People tend to want both a single source of truth *and* for the places they look to be that source of truth. You can't satisfy both directly, but with URLs you can achieve a good compromise. Pick your source of truth, pick the place where discussion is going to take place, and provide pointers Every. Other. Place. to the official places where things will be recorded, discussed, etc. Then stick to it. It's not easy to do this at first, but after a few rounds it will become self policing. Your mileage may vary, but combining these two ideas makes it obvious, to me, that the right approach is to move from bugzilla to forgejo and likewise redesign the change process to be forgejo-native. I don't know if that means the existing forge or if it means the new dist-git, or both, but that's what makes sense to me. So much energy is focused on bringing this online. Let's take advantage of it. -- Brendan Conoboy / Community Linux Engineering / Red Hat
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
