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. wikitext was the bane of my existence for 5 years. As I mentioned above, we tried at one point to move to Taiga. This offered a couple of benefits: * Each field was an actual field, which allowed us to enforce types/formatting/etc * The state of each Change could be represented visually * We could programmatically move things through the process, reducing a lot of copy/paste error and manual toil We ended up not doing this because Taiga's interface required people to click the "save" button on each field individually. This was, in my mind, an unacceptable burden to place on contributors. 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 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. > Discourse should _not_ be the primary source of truth for Change > Proposal texts. > I think we > should consider whether to stop announcing Changes on Discourse. I definitely agree with the first part and I think I agree with the second part. Discourse is a good discussion forum, it's not a good data store. As for posting Changes to Discourse, I agree that it adds a lot of conversation, but not necessarily helpful conversation. It also splits the Discussion. If, at some point, the devel list is moved to Discourse, then the Changes should follow. Otherwise, they should stay on this list. (A weekly post with a list of Changes proposed/approved/etc that has comments disabled would be a decent compromise). Given how integral Bugzilla is to the current process, it might make sense to hold off on major changes until it's more clear if Bugzilla will continue to exist for Fedora long-term. A major Change to the Changes process is going to have a lot of interactions with existing workflows. [1] https://fedoraproject.org/wiki/Changes/fedora-change-wrangler -- Ben Cotton (he/him) TZ=America/Indiana/Indianapolis https://fedoraproject.org/wiki/User:Bcotton -- _______________________________________________ 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
