Check upstream repo is in good order

[davelab6]

We need a checker with a heuristic that checks that an upstream is in good order.

That means the repository layout conforms to some good standard (such as https://github.com/unified-font-repository/Unified-Font-Repository)

It also means the README.md file has all relevant info. Some ideas from @crystaltype :)

• Family Name
• Designer
• Visual sample image
• Current version status: Stable release on DATE, link
• Description
• Languages covered
• How to contribute, issues need to be fixed
• Contact information
• Dependencies
• License

@crystaltype prepared this list of some good examples:

https://github.com/m4rc1e/Abel
https://github.com/cyrealtype/Vidaloka
https://github.com/weiweihuanghuang/Work-Sans
https://github.com/itfoundry/teko
https://github.com/cyrealtype/Sirin-Stencil
https://github.com/impallari/Raleway
https://github.com/graphicore/Questrial-Font
https://github.com/googlefonts/nunito
https://github.com/typeoff/martel_sans
https://github.com/typeoff/martel
https://github.com/cyrealtype/Marko-One
https://github.com/huertatipografica/Kadwa
https://github.com/ossobuffo/jura
https://github.com/cyrealtype/Jacques-Francois-Shadow
https://github.com/cyrealtype/Jacques-Francois
https://github.com/cyrealtype/Federo
https://github.com/khaledhosny/sahl-naskh

Here are examples of repos in a semi-good state:

• https://github.com/EbenSorkin/Aplous/tree/46e559c70941f31efe5e9097f261020a21c14a97
• https://github.com/eliheuer/orbitron/tree/bdfbfe609d38609e8bc9b736cd77d16b171e7d1d

[davelab6]

Assigning this to @laerm0 from Felipe.

@laerm0 has been working to stack rank all the add new fonts requests, and once that is done, the next step will be to to come up with the list of things that we should check an upstream has, so that Felipe can write FB checks.

Above is a list of upstreams to look at, in good and not so good states; I think both can be helpful in defining a list of the attributes of the best ones (things to check are there) and things done we want to be done differently (things to check are not there)

That list of "dos and donts" can become a set of requirements for Felipe can code up, to ensure that all our upstream repos are set up nicely.

Then we can plug these into the upstream sheet, and then the FB dashboard, and then see them flow through to the production API.

[felipesanches]

Thanks, Dave! A precisely defined specification of what needs to be checked will be very useful for me to implement such new checks. And it will likely easily convert into good rationale metadata for such checks.

[laerm0]

Excellent, good idea Dave. I'll finish the chunk of the process that I am on and then start on this.

[davelab6]

There are several more issues I found in the issue tracker related to this.

#291 - "Track project metadata: upstream repo, downstream package targets/requests, etc"

• Does a bakery.yml exist anywhere in the repo (warn it should be in the following location) or at /sources/bakery.yml (pass); if no, fail; also check if more than 1 exists, then warn. Never fail.
• Does the bakery.yml include a downstreams key with a googlefonts child with a specimen child with a value that .startsWith("https://fonts.google.com/specimen/")? If any of these are no, then warn. Never fail.
• Does the bakery.yml include a upstream key with at least 1 repo child with a value that .startsWith("http[s]://") (this seems a bit redundant, but since there can be several upstreams that people may be interested in, it may be worth having this. Again, only ever warn.)

#342 - "Is repo set up for bower?" is really a child of the above issue. I think today that there are several other downstream packaging projects for self-hosting web fonts, that we might want to track...

#1860 - "Is there a build script?"

• Similar to above checks for bakery.yml just existing.

#1841 - "Check Upstream repo has a minisite"

• Similar to above checks for files just existing, but inside a branch.

#1849 - "Add upstream check for correct subs feature". This is going into the .glyphs source file, which is a departure from the above 'repo layout' checks. Still, I expect that many source .glyphs file may have done this in a way we don't want, so we should check for that.

[laerm0]

Hey Felipe –

Here's what I think the checklist should be to determine if a family can easily be onboarded.

0. on GitHub ;)
1. the Unified Font Repository spec is good but I think more than we need.
   • documentation is nice to have but can be empty
   • fonts we need and I want it to have OTF or TTF
   • scripts is unnecessary
   • I don't think we need to ensure the sources folder has subfolders for drawing OTF TTF and features. Just some kind of source file in there that we can work with (UFO .glyphs .sfd .sfdir or .vfb).
   • the files loose in the base directory are nice to have: can fontbakery autogenerate some of these?
   • LICENSE.txt needs to be there and be OFL
2. have FB do --check-googlefonts on whatever is in the fonts directory
   • where should the report go? @m4rc1e suggests posting that in the source repo with some boilerplate and tag him/me on the post. I bet FB can't do that, though, can it? 😉

...and more to come? What are your thoughts on this so far?

[davelab6]

I want a lot more detail. :)

[laerm0]

Okay, I'll go trawling repos to see what I can find that's good and bad and learn from it.

[davelab6]

I once attempted to write detail up, but my browser crashed and lost my stuff.

However, here's a PR that fixes 2 cosmetic things, that we should have checks for:

polarsys/b612#2

[felipesanches]

fixes 2 cosmetic things, that we should have checks for:

If I understood correctly the two things are:

• Font family names should not have spaces in the filename.
• All repos should have a folder called docs/ on their rootdir. And if a documentation/ folder exists, then we should suggest renaming it.

Is that what you meant, @davelab6 ?

[davelab6]

Yes :)

Also: When I posted googlefonts/gf-docs#34 I also thought of this issue; fb could check all markdown files in a project pass a markdown linter, and all markdown & html files pass a 404 checker...