@lildude As I understand it, the popularity requirement is as described in #5756, normally 2000 files, or 200 files if it's typically a single file per repo. This extension currently has 836 files. However, because of the role this kind of file has, I'm not sure the normal requirements fit this case all that well.. These are interface files, which conceptually have a 1-to-1 relationship with the compilation units ("code files") they describe. But they are also usually implicit, because the file can be omitted if nothing needs to be abstracted away. Therefore there aren't all that many of them, but when they do exist they are really important.

Could I therefore ask that you consider either:

1. Treat this as a single-file-per-repo extension and use the 200-file requirement instead. Because public repos are mostly libraries, and most libraries are simple enough to only need a single .resi file to describe their public interface.
2. Include private repositories, if possible, as they tend to have a higher amount of these files since they're more often complex applications that need more internal abstraction than simple libraries. As just one example, the private repo I'm working on has a 1-10 ratio of resi. to .res files (16 of 162, to be precise).
3. Factor in .res files to get a better sense of language popularity.

• Treat this as a single-file-per-repo extension and use the 200-file requirement instead. Because public repos are mostly libraries, and most libraries are simple enough to only need a single .resi file to describe their public interface.

No, as this isn't the case and is bending the "rules" to suit a single use case. This will in turn set a precident which I'll have to argue over and over again.

• Include private repositories, if possible, as they tend to have a higher amount of these files since they're more often complex applications that need more internal abstraction than simple libraries. As just one example, the private repo I'm working on has a 1-10 ratio of resi. to .res files (16 of 162, to be precise).

Most definitely not. This is an invasion of privacy and contradicts the whole purpose of private repos. Private repos are also private to GitHub staff.

• Factor in .res files to get a better sense of language popularity.

Linguist doesn't work like that. It looks at files in isolation so we do the same thing for the popularity requirement.

There is already a solution users can, and many do, use: implement an override in the repo like these repos to tell Linguist to treat these files as ReScript.

No, as this isn't the case and is bending the "rules" to suit a single use case.

The referenced issue also says that these are "loose rules", implying that they are intended to be bent to fit cases that don't fit that mold. Though this might still be bending it too far of course.

There is already a solution users can, and many do, use: implement an override in the repo like these repos to tell Linguist to treat these files as ReScript.

Thanks! I did not know about that, and this does neatly solve my immediate issue. 🙏