On Sun, 2026-06-28 at 15:21 -0500, Maxwell G 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. Yeah, makes sense & could definitely improve the state of the change when it is officially proposed.
> > 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. I can't say I am thrilled about this proposal - rather, I am personally seeing this as a downgrade from a somewhat instrumented visual process (can see how the result looks like at any time) into basically editing an obscure configuration file in a PR. While this can be preferable to some more technical Fedora contributors, to me it kinda looks like trying very hard to avoid making a simple web app instead, that takes the content of a couple fields, validates the content of them if possible (change type set, owner FAS account exists, Fedora version set, etc.) and generates outputs as needed (plaintext email summary, static web page, etc.). This would make the change process less daunting to new or less technical Fedora contributors + you could make sure basic data is valid before submitting the change. It seems to me we have been sliding in this direction for a while, with various simple self-service Web apps replaced with edit-this-file-in-a- PR workflows. Those could be definitely easier to deploy and maintain but are IMHO a downgrade UX wise & an unnecessary barrier for contributors. And one more thing about the current Wiki based process - while definitely not perfect, it has one huge benefit - it has been there for a while. This not only means that many users know how to use it, but more importantly you can easily find and link to changes for the last 20+ Fedora releases. I do this quite often, when explaining why something changed in the Installer - I just search the Wiki (by the Fedora version tag of plaintext search), find the change & link to it. If we do decide to change where the Change is store, we also need not only provide a similar system - search by Fedora number + plaintext, we also need to keep the Wiki based changes accessible, to not loose track of why things were done in a particular way in the past by Fedora. > > 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. Yes, the split of all the places where a Change can be discussed makes it very hard to track all the possible discussions. Not to mention keeping track of what is happening in the bazillion different Discourse categories and sub forums being in general almost impossible. Has someone started a new topic discussing the change is some random corner of Discourse ? How the can I even known as I change owner. This really benefited from the single shared ML timeline in the past. > > 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. > > All the best, > Maxwell -- _______________________________________________ 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
