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.