Closed amartyaamp closed 7 years ago
Nice idea. I have a feeling that first-timers-only
issues are sometimes better fleshed out (thanks to FirstTimersOnly.com) than for other labels. I wonder if there is any way to determine that. I'll be okay with including other labels since the traffic doesn't seem to be too large for just first-timers-only
issues.
Also, it seems that the change will be slightly non-trivial since Github does not support logical OR while searching for labels.
Hence, the task may require N different search queries for N labels. This is not too bad, though.
Any ideas?
Checked the SO link, and the API docs and yes, as of now, I cannot think how this is possible without making N requests to the API (since, the source is the bottleneck ). Is optimization really necessary here? Can we test the N requests and see how good it works?
As far as I can see the issue with GitHub search and OR has not changed.
I opened a pull request (#3) that does 4 requests for 4 labels (the original, and the three suggested above). As the query interval in run.sh
is so long, this should not cause any trouble with the GitHub API limit.
I don't know about the twitter bot post limit, but seem to remember bots with much higher frequency than I could see with the mentioned labels.
Are there any other issues that could be relevant with the increase in requests?
I decided to only include the labels explicitly mentioned above, as I do not know what frequency/amount of issues you are going for, but some other labels I came across would be:
newbiefriendly
, beginner-friendly
, good first contribution
, Great First Issue
, easy
Please let me know if there is anything I should have done differently :)
Currently only supporting tags for first-timers-only. I think it should tweet for the issues tagged low-hanging-fruit or up-for-grabs or beginners. Different repos have different labelling schemes.