Feedback from the current onboarding workflow

[vv-monsalve]

After testing the UFR in a new project, it has been a great tool particularly to simplify the building process :) The following are some suggestions based on the current onboarding workflow.

Repository Structure

• If the primary intended function of this template is for users to quickly meet our standards, It should follow the repo structure required from the Spec, including the Documentation folder and the Fonts folder at once. We begin the process by testing the current font provided by the designer.
• From this note about Trademarks, it would be better to not include that .md file by default.

Testing

• It would be ideal if the FB .md result would be posted in an issue in the repo, instead of in a different branch. The issue allows us to make comments on it and give it a follow-up. Sometimes we keep posting further results in the same issue, similar to what happens in a PR where the results are published in new comments of the same issue, e.g.
• Having a flag that allows to not publish the FB result would also be great, as sometimes many intermediate tests are run as part of the production process, but are not intended to be reported publicly.
• Receiving a succinct report using the log-level argument -l WARN to focus the attention on Warns and Fails.

Proofing

• Typically we use the --imgs argument to create images of BrowserStack preview results on Browsers (currently Safari, Chrome and Edge results are included). This allows receiving results from OS and Windows platforms and different browsers, which is key for the testing stage, e.g.
• Similar to FB results, the resulting images are also posted in a new issue that the designer can inspect at one with the advantage mentioned above.
• Would it be possible to have an argument to use custom templates? We have been using for testing other scripts or languages(e.g. above)
• In addition to the images, including the HTML files in the resulting artifact from the GHA (also as it happens in the PR) would be extra helpful.

Tagging @RosaWagner and @eliheuer for their thoughts on this.

[eliheuer]

The TRADEMARKS.md file seemed like it might cause problems to me as well. For repos without trademarks, I wasn't sure if I should have an emptyTRADEMARKS.md file, no TRADEMARKS.md file, or a TRADEMARKS.md file with just None on the first line. Including the file when there are no trademarks might cause confusion.

[simoncozens]

This is great feedback, thank you; I will get on to it, but I'm heads-down in another problem right now.

[RosaWagner]

@simoncozens If you are okay, I can take care of that :)

[RosaWagner]

I would add that FONTLOG and ABOUT are also not necessary. We ask the designers to put all of this stuff in the README to avoid multiplication of files they forget to update.

[RosaWagner]

@vv-monsalve I just tested with --imgs arguments, and since Browserstack needs credential, it blocks the action. It also crashes when too much people is using it at the same time so… no images is better probably.

[simoncozens]

Just a thought: would it help to have two new make targets:

• make beta: tag and push a beta release, post fontbakery check result to new issue, add fontdiffenator check against contents of fonts/ directory in repo.
• make release: require fontbakery pass, bump version number of repo and fonts, check built fonts into repo, tag, push and create GitHub release.

[simoncozens]

Alternatively if we are trying to things driven more by GitHub actions instead of having people need to use the command line directly, there may be a way to do this the other way around: have GitHub actions do the above when a tag is pushed.

[simoncozens]

Notes from today's meeting:

• We should have a release Makefile target which runs make test and if it succeeds, bumps the font version in the sources, builds new fonts, checks them into the fonts/ directory, creates a GitHub tag and a GitHub release.
• We should include the MD fontbakery report and the proof files in the artefacts.
• HTML proof generation is currently broken and needs looking into.
• Long-term future we should have a much nicer proof generation tool, possibly built on SILE fontproof (actually, thinking about it, I'm probably not going to use SILE because there are long-standing difficulties putting variable fonts into SILE generated PDFs, because they need instantiating and ...reasons) which:
  • Includes the git commit of the font source in the PDF.
  • Displays appropriate strings/waterfalls/etc. for each script.
  • Interrogates the font for special features and demonstrates their use.
  • Provides a textual report on font internals such as avar/fvar/etc.
  • Runs (using GitHub actions platform matrix) on multiple OSes and produces a proof based on the "local" shaping engine.
• We need to make it clear in the README that we support UFO
• UFR should have a full-font which represents our best practices, potentially Rubik.
• There should be an update-ufr Makefile target which pulls in any changes from upstream.
• make test should use the gftools-qa wrapper around fontbakery and automatically open a GitHub issue with the MD report.
• A fontbakery "passing" shields.io badge would be quite nice too.
• Specimen images sources Add specimen image source file #25 is great and we should do it.

[simoncozens]

automatically open a GitHub issue with the MD report.

This is harder than it seems, because doing stuff with GitHub requires access tokens and they're not very easy to set up. I'd love a way to redirect the user to a GH URL where they create their token and then paste it back into the command line (I think the official gh client works like this) but I haven't found an easy way to do it yet.

[simoncozens]

I think this is as done as it can be.