-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FYI: Temporary change in language and extension popularity assessment #5756
Comments
Might be a good time to request a "search by extension/filename" feature to simplify the task of adding new languages to GitHub... 😉 |
Wow, regular expressions will be supported? Now we're talking. 😀 Also, I tried to access https://cs.github.com/ but it simply redirected me to my activity feed (i.e., https://github.com/). Is it staff-only or something? |
Nope. You need to be invited. Join the waitlist at https://cs.github.com/about |
Done. Hopefully this'll make Harvester's rewrite less intimidating. 😅 |
That's what really matters anyway -- yay! 🎉 |
I want to submit support for Unison (https://unison-lang.org), but there are zero GitHub repositories with Unison code in them since Unison is an image-based language and can't really use Git and doesn't have source files. I estimate that Unison has roughly 2000 users total. Is it worth trying to submit? |
One perhaps stupid question (I'm sorry if I missed this!) but how should we (as a language's creators) find the ~5k lines of code/200 repos? I believe we're getting to the right point (based on the telemetry we do have), but we're finding it really hard to turn the repos up based on keywords. I also blindly attempted to see if I could declare a language that Github would process somewhat generically for the sake of marking repos to no avail. https://github.com/atopile/spin-servo-drive/blob/main/.gitattributes |
Use GitHub's Search. This is the only way we assess the popularity based on the search URL offered in the PR template and any further customisations you make to it. The more precise you make the query, the better. Note, we do not, and never have nor will, count lines of code.
The new search is pretty good now and you can use regular expressions too.
This is expected. This has been discussed at length in other issues and will not be discussed in this issue. |
GitHub's Search is struggling at the moment so all Search requests are being heavily restricted making it almost impossible to count the number of unique
:user/:repo
combinations via the likes of Harvester or the API.Search is in the process of being rewritten with the Tech Preview available at https://cs.github.com/ (please tinker with it and send GitHub feedback) however it isn't accessible via the API yet and doesn't quite yet meet our needs to determine our current usage requirements so for the foreseeable future I'll be using my judgment to determine popularity until the new Search gains the functionality we need and/or the restrictions are lifted (or we can come up with other qualifying criteria).
I know this is subjective and open to debate so the loose rules I'll be using are along the lines of:
:user/:repo
combinations assessed by manually and randomly clicking through the results.If particular users are showing a high proportion of the results, I'll manually filter out those users using
-user:<username>
to reduce their impact on my assessment.I know this isn't ideal, but I think it's the best option for the moment. I'm open to suggestions too. On the plus side, it does mean a lot more PRs are likely to be merged 😁.
I'll be going back through older PRs in the next week or two and will re-assess based on these notes and merging any that satisfy them.
The text was updated successfully, but these errors were encountered: