Replying to two messages in one since they have very similar themes. I'm not going to spend much more time on the "why don't we just put it all in a git file and call it a day" idea, though. Could it work? Yes. Does it have drawbacks? Yes.
The current Changes process has been around since, IIRC, F21. I made a few changes to it in my time as Fedora Program Manager, but it may be time to consider a more substantial change. But the right approach there is to think about what a "modern" process looks like at a high level, and then think about how to implement it. On Mon, Jun 29, 2026 at 11:18 AM Daniel P. Berrangé <[email protected]> wrote: > > 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. That's absolutely true for some things! > For example, > > * Owner - a merge request has a submitter that tracks it, > co-owners merely needs to be inline text Sure, but it would be better if it was a validated field that contained only FAS account IDs. This way, any mapping that needs to be done between systems (and there will always need to be some kind of linkages) can ensure it gets the right data. For example, the most common way that creating bugzillas for approved Changes fails is because someone uses a different Bugzilla account than they put in the wiki. > * 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. I disagree. FESCo primarily votes in the issue tracker and has particular voting policies. Overlapping that adds confusion that a simple link would avoid. > * Category: proposed/accepted - the merge request is either > open, or merged, or closed without merge That ignores the fact that there's a week of comment before FESCo votes, which are two distinct states. > 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. You're right, it doesn't have to be more complicated than that. There are certain benefits to that complexity, though. > "change wrangler" as a concept should > probably not even exist if we got the process right. The primary job of the change wrangler isn't pushing paperwork around. It's ensuring proposals are complete, get communicated in the right venues, help with post-approval coordination, etc. That's why Red Hat paid for a full-time Fedora Program Manager for something like 15 years (and then created a new, legally-distinct version of the job when they realized they eliminated that role). On Mon, Jun 29, 2026 at 11:58 AM Kashyap Chamarthy <[email protected]> wrote: > > This YAML + Markdown sounds like an unncessary complication. Can you > please explain why we can't keep everything in a single file? It could. That's what we do now. But it's a pain to process because people get the formatting just a bit wrong. As I said in my first message, some fields could support validation (links, Fedora Accounts IDs, etc). > I don't understand -- why should the Change Wrangler spend a lot of time > fixing formatting issues? Because Changes start in the wiki, go to the mailing list, FESCo's issue tracker, Bugzilla, the wiki again, etc etc etc. There are a lot of moving parts. Could some of them be simplified? Absolutely. Is it a simple change to make? Nope. -- 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
