Thanks for the feedback so far. Some of the responses are fairly similar, so I'll try to clump them together: > Vote in the Change ticket or a FESCo ticket? The intent, for now, is to still have FESCo vote in a separate ticket, mostly for their visibility. Alternatively, I could tag all FESCo members in the change ticket. This part of the process is no different from what we do now, so I'd leave it to FESCo to decide where they would want to vote. > Three repos is too many repos Yes! As with the above, one option would be to have the Docs team use the Changes repo for release notes tracking as well. Again, the issue is visibility, but if they're open to using the Changes repo as the single source of truth, I think that works out better for everyone. > Changes as Markdown files This does address the history, but it loses the metadata aspect that makes the current process clunky. Being able to script against the metadata fields eliminates trying to parse the wiki text and hope nothing too unusual is in there. One option would be to change it so that the markdown file is submitted as a PR, but then the change is submitted as an issue that points to the PR. It's a little bit clunkier, but it would give us both edit history and some enforced structure. The downside means that if I were to automate, e.g., sending the announcement email, the script would have to find the PR from the issue and then find the appropriate file from the PR. The proposal isn't what I'd come up with if time and resources were no concern, but it's what I can come up with that stands a chance of being implemented. I'm really intrigued by the idea of using markdown files both from an easier-for-submission standpoint and also from a "here's the entire history of our changes" standpoint. I'm just concerned that it will make all of the backend processing more cumbersome. If there's something I'm missing on this, I'd love to explore the idea some more. > But what about Bugzilla? I agree that the ability to link other BZ issues to the Changes is helpful, but in my limited experience so far, it's not a common use case. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/GUYCGNJUZCBOFL2R7BFTG6RWCJKSGDHA/
