On Mon, Jun 29, 2026 at 10:03:45AM -0400, Ben Cotton wrote: > Hello from someone who has given a lot of thought to the Changes > process over the years! > > On Sun, Jun 28, 2026 at 4:21 PM Maxwell G <[email protected]> wrote: > > > > Any changes to the Changes Process should go through the Changes Process > > or a similar community feedback process. > > Agreed. I did that with the abandoned proposal[1] to use Taiga for > tracking Changes. More on that in a moment. > > > 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. > > I recall adding some text along those lines some years back. It's > definitely in the comments in the Feedback section of the form, but > adding it to the policy itself is a good idea. If it's not a required > step, though, I don't know how much people will follow it. And making > it a required step is an unnecessary burden for the vast majority of > Change proposals. So I'm not sure how much benefit we'll see in > practice. But still, explicitly encouraging it won't hurt and may > help. > > > We should move away from the Wiki and wikitext formatting. > > Changes should be written in markdown, or a markup format that can be > > easily converted to markdown ... > > We should store Changes as text files in a git repository.
> I would argue against storing Changes in Markdown, though, as it > doesn't really solve the "wikitext is bad for this" problem. Markdown > is more familiar and reusable, but the real problem is that a Change > proposal isn't just text. There's a lot of metadata. So something like > yaml, with some fields being Markdown, would be a more apt choice. > This, of course, means that people would either have to hand-write > yaml (boo!) or we'd have to write and maintain a small program that > would take input from the user and write the yaml (or json or XML or > ...). I would suggest that the metadata does not need to be tracked in the same way. Some can be dropped, some can merely be inline text for humans not machines and some could be represented by the forge features for merge requests/issues. For example, * Owner - a merge request has a submitter that tracks it, co-owners merely needs to be inline text * FESCO issue - should not exist - FESCO should look at open merge requests against a "fedora-changes" repo and vote to approve their merge or not. * Category: self-contained/system-wide - labels against a merge request * Category: proposed/accepted - the merge request is either open, or merged, or closed without merge * Category: distro version - the fedora-changes git repo should have a sub-folder for each distro version, and changes proposed for the appropriate folder. Could use labels against the MR too. > I get the appeal of a git-based workflow and I think it offers a lot > of benefits. But it's not as easy as it sounds on the surface. Or at > least, it still puts the Change Wrangler in a position where they > spend a lot of time fixing formatting issues to make the scripts work. IMHO the goal of any git based workflow is to fully eliminate any/all change wrangler scripts, and indeed eliminate most of the work that the change wrangler has to do. "change wrangler" as a concept should probably not even exist if we got the process right. It really doesn't have to be more complicated than submitting markdown docs against a repo as merge requests, and having FESCO approve/reject the merge requests. CI pipelines publish a website with the merged results, and CI pipeline can notify the forum/mailing list of new changes that need commentary from the peanut gallery. At most a change wrangler might want to periodically purge abandoned MRs, perhaps curate / assign labels. very mininal house keeping, that could even be done by FESCO as part of their task of periodically reviewing pending changes. Simplicity is what's needed here. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :| -- _______________________________________________ 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
