Top-Ranking Issues (All Time) 📊 #5393
Comments
JosephTLyons
changed the title
JosephTLyons
changed the title
JosephTLyons
changed the title
|
: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. |
|
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. |
@JosephTLyons I think you should be able to use 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: |
|
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. 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". |
|
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. |
|
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. |
|
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. |
|
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 12/17/2024 07:13 PM (EST)
enhancement
design
.qmdfile format #12406 (54 👍)ai
/diffto the assistant #16821 (21 👍)copilot::Toggleto enable/disable automatic suggestions #9303 (15 👍)bug
not being correctly formatted in documentation #15463 (33 👍)vim
yank/cut/delete around class/function, oryank/cut/delete inside class/function#4320 (28 👍)ctrl-pandctrl-n#17461 (8 👍)linux
.debinstallation option #13952 (27 👍)windows
STATUS_ACCESS_VIOLATION#12041 (3 👍)panic / crash
STATUS_ACCESS_VIOLATION#12041 (3 👍)~) and root path support (use_system_path_prompts: false) #16227 (3 👍)Result::unwrap()on anErrvalue: () #15795 (2 👍)documentation
scroll cursor {top,center,bottom}actions toDefault Key Bindings#5075 (0 👍)support
duplicate
For details on how this issue is generated, see the script
The text was updated successfully, but these errors were encountered: