FIWG Meeting, 2018-Nov-28

Present: Wayne, Ryan, Gordon, Dimitris, Jos

  1. Review and approval of minutes
  2. Ballots and Canonical Versioning:
  3. Wiki Management:
  4. Website Management: test site construction; Amazon VMs; standards for publication
  1. Minutes approved

The minutes from the 14 November meeting as posted to the wiki by Dimitris were approved and will be published to the mailing list.

  1. Anti-trust statement

We read the statement and made plans to do this at each meeting; suggested that we provide a reminder on the next SCWG/Forum call for all WGs to make sure they do this.

  1. Website management

This was tabled for the next meeting due to missing Dimitris/Daymion.

  1. Document management

We started by examining the current system, which uses a Markdown flavor (Kramdown) to produce multiple artifacts. The current flow in the automated artifact generation process is to export Kramdown to HTML (generating an HTML artifact) and then export the HTML to PDF using Weasyprint. This provides two places to potentially modify the look and feel of the final product: the CSS that produces the HTML output, and the Weasyprint template that produces the PDF document. Ryan volunteered to talk with Peter Bowen—who created the automated generation system—about the reasoning behind using Kramdown and the generation process. Ryan is confident he and Jacob have the technical knowledge of the innards of the current production process to keep it running, but wanted to ask Peter about why decisions were made that way and whether there was significance to the use of Kramdown over something else (another Markdown flavor, e.g.).

The discussion settled on a movement towards an open standard such as the current Markdown format as the canonical version, with the ballot changes more strongly tracked through Git branching. Dimitris, Wayne, and Dean have been collaborating on a set of instructions for the production of documents after ballot changes, with the emphasis on making those the responsibility of the Chair/Vice Chair. Ryan pointed out that the discussion in the FIWG currently was focused on pre-voting change work, which was symbiotic with that work but not identical; there was agreement therefore on ensuring that the two processes aligned and didn't obviate each other. The group generally agreed that the important part of the ballot work for members was on content and not look-and-feel, so it was crucial to focus our work on optimizing the content management piece of the process, while leaving the look-and-feel to the responsibility of the chair/vice-chair. Jos pointed out that this work is often done by a Secretary in other organizations; Ryan concurred that open organizations like the W3C have a Secretariat person or group whose responsibility encompasses document look-and-feel management, so that members can focus efforts on changing the content of guidelines.

There was some discussion of red-line version generation. The initial discussion of this previously had focused on identifying requirements for a red-line version but not dictating the tools to use. The group didn't come to a decision but did feel like perhaps red-line generation could be handled by more strongly tracking proposed ballot changes using Github and adjusting the automated tooling to produce a red-line version for each change (some or all of which is already in place for branching).

Finally, the group agreed to review the use of Kramdown as a potential final document version, to see whether we can adjust the markup in the existing BRs to accommodate the list of required|https://cabforum.org/wiki/FIWG-DocMgtFormats|required features for documents] that were laid out in earlier discussions. There are several areas of the BRs that contain odd or questionable markup due to attempts to dictate specific layout results. Ryan pointed out that in several cases this is due to the importance of ensuring that, for example, numbered list elements do not change in case someone is referencing a specific list item number. The group agreed some cleanup of the BRs was necessary, and would be part and parcel of settling on a final document format.

  1. Wiki management

This was not discussed due to time, but Jos asked the group to continue this discussion on the mailer and plan to make it a focus of the next meeting, in particular to focus on next steps and what to begin testing.

  • fiwg/fiwg-meeting4.txt
  • Last modified: 4 years ago
  • (external edit)