<div dir="auto">Thanks!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 30, 2021, 8:42 AM Jos Purvis (jopurvis) via Infrastructure <<a href="mailto:infrastructure@cabforum.org">infrastructure@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"><div class="m_4302036745117396153WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">Using our test site, I set up the Git It Write plugin and then created a public repository with a few Markdown versions of minutes and ballots, then “published” them by pulling them into the test server. Have a look at the below info and let’s discuss at this week’s meeting.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Georgia",serif">TL;DR Version:</span></b><span style="font-size:11.0pt;font-family:"Georgia",serif"> It works! And it works pretty well, too—the resulting pages look just like the posts we normally create by hand. Here’s a couple samples:<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif"><a href="https://tj4.9bc.myftpupload.com/2021/11/30/20210916-2/" target="_blank" rel="noreferrer">https://tj4.9bc.myftpupload.com/2021/11/30/20210916-2/</a> (SCWG Minutes from 2021-09-16)<u></u><u></u></span></li><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif"><a href="https://tj4.9bc.myftpupload.com/2021/11/30/sc48/" target="_blank" rel="noreferrer">https://tj4.9bc.myftpupload.com/2021/11/30/sc48/</a> (Ballot SC48)<u></u><u></u></span></li></ul><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">Here’s the source repository:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"> <a href="https://github.com/castillar/proceedings-md" target="_blank" rel="noreferrer">https://github.com/castillar/proceedings-md</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Georgia",serif">Longer Version:</span></b><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">The way GIW works is to pull Markdown files from a public Github repo and then convert them into static WordPress posts. You can either do the sync manually on demand or by using a webhook from Github that will poke the server when an update is pushed to the branch it’s watching. The advantage of this is that we get Git review/update/approve workflows for things like ballots and minutes that need a standard format and review process, without imposing that on the rest of the website.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">Couple things I noticed:<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif">GIW will watch specific branches, but it does need a public repository. This would mean some extra steps for minutes, which require private review prior to being made publicly viewable. I have some ideas for this below, or we might decide that minutes are less important for this process and just focus on this for ballots.<u></u><u></u></span></li><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif">The Git flow is particularly useful for ballots, as we could make the Github repo the standard location for ballot proposals. Propose the ballot as a pull request, update the ballot pull request as it passes through discussion and voting, and then approve the pull request when voting is complete to automatically create a ballot record. In addition, we can code some Github workflows to accompany this, adding and modifying boilerplate on the ballot record to indicate IPR and link the final ballot to the updated document(s) through that process.<u></u><u></u></span></li><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif">The information flow is one-way only: if you edit a post on WordPress after importing it, those changes are not propagated back to Github. In addition, those changes may be overwritten the next time you run an import, so anything we’re publishing through Github needs to be exclusively edited in Github.<u></u><u></u></span></li><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif">GIW creates the post name from the filename, so if we have two files named the same thing, it’s going to create them as 20210916 and 20210916-2 in WordPress. Filenames therefore need to be globally unique, which would push for a more flat layout than I have (more like “ballots under this directory with unique names, minutes under this directory with unique names” rather than creating folders to organize content.<u></u><u></u></span></li></ul><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">For the minutes process, I can see two potential workarounds for the public repo problem:<u></u><u></u></span></p><ol style="margin-top:0in" start="1" type="1"><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif">Create a private repo for each working group (or one private repo for all, if we’re OK with that) and do the initial review of the minutes on that repo. This would require anyone wanting to view the minutes to have a Github account added to the repo, or we could probably configure it to publish a copy over email to the management list. Once the minutes are approved in the private repo, they’d be fast-tracked through the public repo into WordPress. That would obviate some of the advantage of the public repo, but we could still use it for ballots and as a standard publishing method (and to make sure the format is correct before publishing to the website).<u></u><u></u></span></li><li class="m_4302036745117396153MsoListParagraph" style="margin-left:0in"><span style="font-size:11.0pt;font-family:"Georgia",serif">Continue to do the private review of the minutes on the management mailer. When the minutes are approved by the relevant working group, they’d submit a pull request to the public repo, and the public repo owners would just make sure the formatting is correct and then approve it. This is the simpler option, although it does remove some of the git advantages.<u></u><u></u></span></li></ol><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">In addition, there’s the question of publication dates and layout. The repo is laid out like this:<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:Consolas">proceedings-md/<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:Consolas">minutes/<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11.0pt;font-family:Consolas">forum/<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:2.0in"><span style="font-size:11.0pt;font-family:Consolas">datestamp.md # e.g., 20210916.md<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11.0pt;font-family:Consolas">scwg/<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:2.0in"><span style="font-size:11.0pt;font-family:Consolas">datestamp.md<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:11.0pt;font-family:Consolas">ballots/<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:1.5in"><span style="font-size:11.0pt;font-family:Consolas">tag-ballotnum.md # # e.g., sc48.md or forum-13.md<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">GIW then converts this into WordPress layout by creating a Post page for each MD file it finds in the repository. It first creates a post like this:<u></u><u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Georgia",serif"><a href="https://tj4.9bc.myftpupload.com/2021/11/30/20210916/" target="_blank" rel="noreferrer">https://tj4.9bc.myftpupload.com/2021/11/30/20210916/</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif">The URL comes from the date of import (that is, the date GIW pulled the post into WordPress) plus the name of the file. Folders within the imported layout don’t seem to be mapped to slugs on WordPress, so we should probably just push for a flat repo layout as noted above.<u></u><u></u></span></p><p class="MsoNormal" style="text-indent:.5in"><span style="font-size:11.0pt;font-family:"Georgia",serif">The downside of this is that if we import all of this material into WordPress, it’s all going to appear as if everything was created on the same day. I haven’t played with it enough yet to know whether we can somehow set the creation date in the YAML front material on the post. I did check and we can manually edit the WordPress post to change the publication date, but the plugin will then create duplicate posts on the next import because it doesn’t see them as identical anymore, so that’s not going to be a good option. Going forward, things should be OK since the site will import new content close to the date of publication in Github, but for the initial import it might be problematic. One option would be to <i>not</i> import old content to Github, and simply start tracking new content from XX date forward, so that older content already on the website remains unchanged.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Georgia",serif"><u></u> <u></u></span></p><div><div><p class="MsoNormal"><span style="font-size:9.0pt;font-family:Consolas;color:black">-- <br>Jos Purvis (</span><a href="mailto:jopurvis@cisco.com" title="mailto:jopurvis@cisco.com" target="_blank" rel="noreferrer"><span style="font-size:9.0pt;font-family:Consolas;color:#954f72">jopurvis@cisco.com</span></a><span style="font-size:9.0pt;font-family:Consolas;color:black">)<br>.:|:.:|:. cisco systems | Cryptographic Services<br>PGP: 0xFD802FEE07D19105 | Controls & Trust Verification</span><span style="color:black"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div>_______________________________________________<br>
Infrastructure mailing list<br>
<a href="mailto:Infrastructure@cabforum.org" target="_blank" rel="noreferrer">Infrastructure@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/infrastructure" rel="noreferrer noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/infrastructure</a><br>
</blockquote></div>