Hi, Ben,
On Fri, Aug 24, 2018 at 3:48 PM Ben Cotton <bcotton@xxxxxxxxxx> 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.
--
Aleksandra Fedorova
bookwar at IRC
_______________________________________________ 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
