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
