exalted
commented
2 years ago :two-cents: You'll know better, but a GitHub project sounds like a better solution.
Open JosephTLyons opened 2 years ago
exalted
commented
2 years ago :two-cents: You'll know better, but a GitHub project sounds like a better solution.
JosephTLyons
commented
2 years ago :two-cents: You'll know better, but a GitHub project sounds like a better solution.
It would be nice to have something that is more directly supported by GitHub with less custom code involved, but I don't know if GitHub Projects support sorting on the fields I need. I checked it out and wasn't able to find a way to sort on reactions and comments and such. You can create custom fields in the project table, but you'd have to manually update those, or write another script to tap into them. I'm not sure what the best solution is for generating a list like this - this is just my first attempt.
maxbrunsfeld
commented
2 years ago This is very cool @JosephTLyons; thanks for setting it up.
JosephTLyons
commented
2 years ago This is very cool @JosephTLyons; thanks for setting it up.
Yeah no problem
I'm currently running it manually; I don't have any experience with GitHub actions and I don't know want to assume there are enough Action Minutes to go around, but if I spent some time to learn it and if there were enough minutes to spare, I could try to automate it to run once a day.
I've done my best to optimize the script, it still takes about 5 seconds to run it because I can't seem to find a way to limit the query size using the GitHub Search syntax, so even though I only display 5 items per label, I have to pull all open issues per label and slice the list down to size locally.
clo4
commented
2 years ago I have to pull all open issues per label and slice the list down to size locally
@JosephTLyons I think you should be able to use ?per_page=5 in the query, eg. https://api.github.com/search/issues?per_page=5&q=... -- I've had to fight the API to get more than 100 issues for the fig support dashboard 😄
Also, should be possible to do this concurrently - if the script is public, I'd be happy to optimize it :)
It can probably just run in a repo on your user account, using a gh actions schedule. If the repo is public, you don't need to worry about it using up your minutes!
JosephTLyons
commented
2 years ago I have to pull all open issues per label and slice the list down to size locally
@JosephTLyons I think you should be able to use
?per_page=5in the query, eg.https://api.github.com/search/issues?per_page=5&q=...-- I've had to fight the API to get more than 100 issues for the fig support dashboard 😄Also, should be possible to do this concurrently - if the script is public, I'd be happy to optimize it :)
It can probably just run in a repo on your user account, using a gh actions schedule. If the repo is public, you don't need to worry about it using up your minutes!
I'm currently using PyGitHub in a Python script. I haven't found how to limit the results using it, as the search uses the search syntax that you have on the frontend on the issues page. I probably missed something, but I felt like I couldn't get the "per_page" filter (or any other limit to the final query) to work there:
JosephTLyons
commented
2 years ago Need some opinions here. Previously, I was just skipping all issues with these tags ("discussed", "meta", "needs info", "triage"}, as these type of labels are just optional ones; all issues with these labels have other "core" labels that are required.
We are adding more more labels now and it seems issues can now have multiple "core" labels, which means issues can end up in multiple label groups in the generated markdown above. I'm not sure how to handle this. I could either filter out duplicate issues, but this would be a bit misleading, since issues would just not show up in places they technically should, or maybe I just get rid of the label exclusion list all together and allow all duplicates to surface in all label groups, but this would probably result in a bunch of noise.
Until I get some feedback on this, I will just generate the list assuming that all issues will at least have one of the following labels: "enhancement", "defect", "polish, and "documentation".
iamnbutler
commented
2 years ago Honestly, tags will probably be fast and loose for a bit while we figure out how to parse feedback.
In the coming few weeks the fire hose will probably open up a lot, as I think we'll be increasing the amount of people with access by triple digits.
Suggestions are welcome for a framework to organize/parse feedback.
JosephTLyons
commented
2 years ago Honestly, tags will probably be fast and loose for a bit while we figure out how to parse feedback.
In the coming few weeks the fire hose will probably open up a lot, as I think we'll be increasing the amount of people with access by triple digits.
Suggestions are welcome for a framework to organize/parse feedback.
Yeah, this was just something I tossed together randomly without much thought; if it ends up not working with however the repository is ultimately organized, it can be tossed.
JosephTLyons
commented
2 years ago This issue should be auto-generating now, every 12 hours UTC (the cron scheduler can't be set to any timezone specifically). I also set it to rebuild after issues close. Feel free to change the triggers, cron schedule, or timezones in the script to your liking.
JosephTLyons
commented
2 years ago I'm thinking it might make sense to remove comments from the sorting mechanism. With likes, users can only add one, and no one can change the creation datetime, but anyone can comment multiple times to boost the issue up (to the top of the group of issues with the same number of likes). I'm thinking just likes and creation datetime is enough to stabilize the sort and prevent others from artificially boosting an issue's importance. It also might help to reduce some of the noise in this issue. Let me know what you think about this.
As a note, I did experiment with having the script generate a table, to reduce the amount of repeated emojis showing, but GitHub does not render the dynamic issue links (the ones that show the name of the issue and whether its closed or open) inside of markdown tables, so that idea was tossed.
jamesmunns
commented
2 years ago Hey there! Apologies if this is off-topic, is there somewhere I can :+1: linux support as a blocking issue? I do have a Mac, but don't use it as a primary development machine, which means that I probably won't have a chance to test out Zed until there is some kind of Linux client.
I can open an issue, but it seems explicitly documented that is a WIP feature :)
JosephTLyons
commented
2 years ago Hey there! Apologies if this is off-topic, is there somewhere I can 👍 linux support as a blocking issue? I do have a Mac, but don't use it as a primary development machine, which means that I probably won't have a chance to test out Zed until there is some kind of Linux client.
I can open an issue, but it seems explicitly documented that is a WIP feature :)
Sure, I went ahead and made a meta issue here:
Updated on 11/28/2024 07:07 AM (EST)
enhancement
design
ai
bug
vim
linux
windows
panic / crash
documentation
support
duplicate
errors with issues (this section only shows when there are errors with issues)
This script expects every issue to have at least one of the following core labels: "duplicate", "panic / crash", "bug", "documentation", "enhancement", "support", "design" This script currently ignores issues that have the following label: ignore top-ranking issues
what to do?
missing core label
For details on how this issue is generated, see the script