Hi, Ben, On Fri, Aug 24, 2018 at 3:48 PM Ben Cotton <bcot...@redhat.com> wrote:
> > 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. > Could you give an example, what kind of metadata is required? When you work with the change as a piece of code (~text in markdown), you can work via pull requests workflow. Thus, at the pre-merge phase while you are working on the proposal you can use tags and metadata on the pull request side. This can help to track Changes which require some work, Changes which were not voted upon and so on. And you don't need to create an issue on that. For the static metadata about the Change you can use the metadata in the Markdown itself. Almost every static generator site allows the metadata to be stored in the file [1]. And additionally the repo layout (folders hierarchy) can also be used for categorization. Both can be then exported in a machine-readable form. For dynamic info on the Change implementation (progress, blocked issues) we already have a Bugzilla tracking issue. And the good thing about Markdown here is that we can easily adjust any of static generators to collect and show info from Bugzilla right there on the Change page. Generally, I think that the Change itself is a content, which requires versioning, review and collaborative editing, and it fits much better to be the source code rather than the issues workflow. [1] http://docs.getpelican.com/en/3.6.3/content.html -- Aleksandra Fedorova bookwar at IRC
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
