Re: How can we improve the Changes Process?

Hi Ben,

Thanks for the feedback!

On 6/29/26 9:03 AM, Ben Cotton wrote:
> 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
> ...).

Well, my idea was to have frontmatter [1] in the markdown files to store 
the structured data, which could be formatted as YAML, TOML, or JSON. 
Having a proper way to deal with metadata in Changes without complicated 
text parsing is one of the main points that has come up in the 
discussions I've had before starting this thread, so I definitely want 
to make sure that whatever we land on addresses that problem.

I would also not be entirely against putting entire Changes in a single 
TOML file and making fields like Detailed Description multiline TOML 
strings that would accept freeform markdown-formatted text. We could 
provide a template TOML that should be easy enough for Change owners to 
edit (or at least not any worse than the existing wikitext template). 
I'm suggesting TOML and not YAML because there's no indentation quirks, 
and it has proper support for multiline strings.

>> 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).

I agree, and I do like the idea of reporting Changes to Discourse as 
read-only topics as a compromise approach.

> 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.

I'd prefer not to block this indefinitely on deciding on Bugzilla, but I 
do think it's something that we have to account for, and I'd like to 
avoid creating *more* dependence on Bugzilla as part of these changes.

All the best,
Maxwell

[1] https://www.markdownlang.com/advanced/frontmatter.html (this is one 
doc I found about markdown frontmatter, not necessarily sure it's *the* 
authoritative source)
-- 
_______________________________________________
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