Open IonicaBizau opened 8 years ago
I also think storing all entries in JSON, YAML, TOML or another structured data format is better than the current table in README. Then, the README can be automatically generated with a script.
If you go this way, you can split the data into two files: one which is auto-generated/created by your "build script", and another maintained by users. Then, the script I mentioned above (which would generate the README) can merge the two files, sort them by language, apply magic and output the README.
If you only store owners, you'd have to either 1) only show owners in README or 2) have your script also fetch those owners' repositories.
Then, the README can be automatically generated with a script.
@Aluxian I hope you didn't think I wrote this manually. π The readme is already generated from package.json
using json2md
. We will anyway need to store some json data in package.json
because that's the way how blah
generates the content for me.
If you only store owners, you'd have to either 1) only show owners in README or 2) have your script also fetch those owners' repositories.
Yes, I was thinking to fetch repos created by the owner
s. It's not that expensive operation since GitHub allows us 6k requests per hour. Actually, getting the users is a bit more painful: the rate limit for search endpoints is only 30 requests / min.
In fact, the hard thing is to decide who lives in Romania since not all the guys from Romania entered Romania
in their profile (some of them entered a townβe.g. Brasov
, others Europe
and others just didn't fill it). Once we have a good list of GH users living in Romania, it's relatively easy to take their top repositories and sort them.
Another idea would be to make queries to GitHub Archive. That will not require an API limit, probably.
An other idea: have a local cache and don't re-request information which is already in the cache (ie. when you rebuild the README, most of the user information would already be in the cache).
I got quite a few PRs with manual added repositories. That's great! β¨
The way how I first prototyped the build script is that it takes the top 29 developers (by the number of followers) from
location:Romania
(that means they filled inRomania
or something which contains it in the location input) and then it takes the projects having at least two stars.Since we should definitely handle manual added repos, I think one solution would be to store only the list of repo full names (or even just
owner
s):Any other ideas? π