How can we improve the Changes Process?

Maxwell G <[email protected]>
Newsgroups gmane.linux.redhat.fedora.devel
Message-ID <[email protected]>
Hi everyone,

I've been thinking about the Changes Process recently and how we can 
improve it for Change Owners, Change Wranglers, FESCo members, and 
participants in Change discussion and feedback. I'm not officially 
proposing to change anything now, but I wanted to put some ideas out 
there and see how people feel about this or if anybody has other 
ideas/thoughts/opinions.

---

Any changes to the Changes Process should go through the Changes Process 
or a similar community feedback process.

We need to be aware of other processes/teams/scripts that consume 
Changes so that they can be adjusted accordingly.

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.

We should move away from the Wiki and wikitext formatting. Wikitext is 
yet another text markup format that we use in Fedora that is not 
familiar to everyone, and it's apparently hard to parse 
programmatically. We could consider storing metadata about Changes (such 
as targeted release, change owners, status, FESCo issue number) in a 
structured way using Markdown front-matter that tools that work with 
Changes can easily consume.

Changes should be written in markdown, or a markup format that can be 
easily converted to markdown or bbcode for display on Discourse, and 
also for plain text emails. If we use asciidoc, that would allow us to 
publish approved Changes to docs.fedoraproject.org which might be nice.

We should store Changes as text files in a git repository. Change owners 
would propose Changes by filing a PR against the repository and then the 
Change would be announced after the Change Wrangler reviews and merges 
the Change text. We could have CI checks to validate Changes (e.g., to 
make sure that system-wide Changes have the correct optional fields) and 
various other opportunities for automation that we don't have with the wiki.

Discourse should _not_ be the primary source of truth for Change 
Proposal texts. I've heard suggestions to use it for this, since it's 
one place and already supports markdown-formatted text and is currently 
used for discussion, but I don't believe it's a good place to store and 
work with Changes. There's not a good way to programmatically access 
Changes if they were stored in Discourse. Forum software is not meant 
for archiving anything. A repository of plain text files is 
better-suited for this purpose.

This part doesn't have to go along with a migration away from the Wiki 
that I am suggesting, but I wanted to float the idea here. I think we 
should consider whether to stop announcing Changes on Discourse. 
Cross-posting to Discourse was proposed as an experiment in fesco#2989, 
but there was never a decision made about whether to stop or continue 
with the experiment. I find the fractured discussions between devel@ and 
Discourse hard to follow. I think the Discourse setup makes it easier 
for discussions to "accelerate" or become toxic or repetitive. I don't 
think it's any better at handling large threads.

All the best,
Maxwell
-- 
_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.