Following up on this, I'm really happy to hear that there are others who would be interested. And, between the review-service and catalog ideas (in their threads) and the standard package-maintenance topics, it sounds like there is far from a shortage of things to work on.
I did want to throw a couple of additional subjects of my own into the mix, though, for the record.
- Recently I've been drilling into the question of how users manage fonts on their systems and how deep the difficulties with that go. IMHO, there are some vertical issues that could use attention well before anyone at the GUI-application-develop level would sit down and write the world's most perfect font manager. The list I made includes:
--- Getting reserved font names (RFNs) in OFL fonts tracked properly, because the RFN is generally hidden from the user. This would ideally involve adding the RFN clause as an "exception element" in SPDX and having it exposed in AppStream metadata. I've ben in contact with both projects about that.
--- There are a number of other type-specific metadata fields that could/should be added to the AppStream <font> element that would be beneficial for helping users find and select fonts. The AppStream folks seem amenable to considering this, but if they add support for it, it would mean a lot of packages needing updates....
--- Working to get specimens included in font packages — and by "specimens" here, I mean the upstream document(s) (usually PDF or HTML) created by the font designer to showcase the font. SIL packages currently include these, but virtually no other font packages in Debian do, even though there are a lot available. It may sound weird, but accessing specimens (in this sense) is an important part of how graphic designers select a font for a particular project. This may involve working with the upstream designer to make the specimen document available under DFSG-acceptable terms. It may also involve persuading people like Open Source Design to help create some specimens....
--- Figuring out a way to get font usage documentation into packages in a uniform way that's useful to users. The big target here is OpenType features, which go largely ignored. Design apps like Inkscape and Scribus started working on an OpenType feature UI a few years ago at an LGM workshop, but even once that becomes commonplace, packages would need to provide some sort of documentation of what variants, stylistic sets, and alternates are provided. A second category (arguably more important for users) would be language-specific features, also in OpenType albeit it a different vein. And there there are cases like colorfont usage. It would be virtually impossible to make use of a color font like Bungee without its documentation, for example:
https://github.com/djrrb/Bungee/tree/master/documentation