-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
[Tool] Batch close old issues #12679
Comments
I also wonder if "feature requests" that haven't been implemented until 2 years are worth keeping in the repo? I am pondering if I should run this tool a second time and not skip "feature requests" that are more than 2 years old. Any thoughts on this? |
The thing is most of the feature requests are being ignored. |
@sledgehammer999 As for the feature requests, I am against closing them. I think we should leave them all open, and then start to prioritize them according to popularity. I can start to do this and formulate a more structured plan about this once the major cleaning has been completed. |
@sledgehammer999
This is to avoid users complaining about "you're being lazy closing/locking old issues instead of fixing things!". It's better to provide at least a small justification for this action IMO. Speaking of issue templates, can you take a look at #12574? For the sake of sanity, I'd like to have something like this merged sooner rather than later. It's getting really tiring to deal with all the low-effort bug reports and having to constantly ask for logs and settings. |
@sledgehammer999 The locking message could be almost the same as the message above, but with the first sentence changed to:
|
Breakdown of "Labelled Issues Only" with "Open" statusApplicable to 45x qBittorrent Issue Tracker Labels
|
Issue Tracker Label x15 | Open | Issue Tracker Label x15 | Open | Issue Tracker Label x15 | Open |
---|---|---|---|---|---|
Accessibility | 5 | GUI | 331 | PR abondoned | 0 |
Backport | 0 | Help wanted | 19 | PR waiting author | 0 |
Build system | 15 | Hotfix | 0 | Project management | 19 |
Can't reproduce | 44 | Invalid | 6 | Proxy/VPN | 41 |
Code cleanup | 8 | Libtorrent | 43 | Qt bugs | 24 |
- | - | - | - | - | - |
Confirmed bug | 79 | Look and Feel | 44 | RSS | 167 |
Core | 128 | Meta | 7 | Search engine | 45 |
Crash | 133 | Network | 115 | Security | 3 |
Data loss | 13 | Not an issue | 13 | Temp folder | 58 |
Discussion | 30 | NSIS | 3 | Translation | 11 |
- | - | - | - | - | - |
Documentation | 10 | OS: Linux | 65 | Waiting upstream | 11 |
Duplicate | 0 | OS: macOS | 69 | Waiting Web implementation | 1 |
Easy to fix | 13 | OS: Windows | 127 | WaitingInfo | 68 |
Feature request | 851 | Performance | 88 | WebAPI | 43 |
Feature | 7 | PPA | 2 | WebUI | 117 |
NOTE:
(Some Issues may have more than 1 designated Issue Tracker label assigned)
Breakdown of "Labelled Issues Only" (Without "Feature request" label applied)
|
Issue Tracker Label x15 | Open | Issue Tracker Label x15 | Open | Issue Tracker Label x15 | Open |
---|---|---|---|---|---|
Accessibility | 1 | GUI | 227 | PR abondoned | 0 |
Backport | 0 | Help wanted | 17 | PR waiting author | 0 |
Build system | 13 | Hotfix | 0 | Project management | 16 |
Can't reproduce | 44 | Invalid | 6 | Proxy/VPN | 38 |
Code cleanup | 7 | Libtorrent | 32 | Qt bugs | 23 |
- | - | - | - | - | - |
Confirmed bug | 75 | Look and Feel | 34 | RSS | 110 |
Core | 106 | Meta | 7 | Search engine | 22 |
Crash | 133 | Network | 111 | Security | 2 |
Data loss | 13 | Not an issue | 11 | Temp folder | 50 |
Discussion | 26 | NSIS | 1 | Translation | 11 |
- | - | - | - | - | - |
Documentation | 9 | OS: Linux | 62 | Waiting upstream | 4 |
Duplicate | 0 | OS: macOS | 62 | Waiting Web implementation | 1 |
Easy to fix | 2 | OS: Windows | 112 | WaitingInfo | 66 |
Feature request (Only) | 542 | Performance | 87 | WebAPI | 38 |
Feature | 3 | PPA | 1 | WebUI | 84 |
NOTE:
(Some Issues may have more than 1 designated Issue Tracker label assigned)
Feature request (Only) has no other label applied.
I've been through all issues a couple times and as far as i'm concerned, unlabeled ones remained thus because no label seemed appropriate for them (obviously there are surely some i missed). For example #7095 what label would be fitting for that? Other than that, there are many where i simply don't know if it's libtorrent, core or something else, and then there are those where user error is suspect, and from my experience, it's too late to disprove that (no replies after all this time).
Feature requests are timeless, no? The main devs may never implement most of them but it doesn't mean some new contributor won't, just like it happened with the tags subsystem. |
well sledge was running/going to run his tool to close all issues equal to/below At this stage, the Label/close what you can & anything that is left open/unlabelled can be decided on collectively later on.... Also, (libtorrent 1.1.x series has been dropped) (v4.2.x has been using 1.2.x.x) With everything labelled/organized:
I'd have to agree not to close the 2yr+ "Feature requests". |
Thanks for the breakdown and the initiative. I actually posted a very similar action plan in the team page (https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions) all the way back in February. However, most of the plan got stalled due to @sledgehammer999's absence, namely in what concerns bulk actions like closing old issues. Fortunately, while the issue count situation has not improved much, at least it hasn't got much worse. Even at the current pace, I expect we'll still be below 3k issues by the end of the year. I must have closed several hundreds of issue so far. One of the things that is much needed as well is the issue template rework: #12574.
I think we need a new labeling/triaging/priority system. I'll try to work something out. In the meantime, there's around 50 issues that should be low-hanging fruit to close - they were marked as Also, I would ask you to please lock closed issues. Otherwise many people just will just necro them at some point without providing enough relevant new information. |
@thalieht Here's some revised boilerplate from #12679 (comment) to help close old issues. You can save it and apply it automatically using GitHub's "Save reply" feature: https://github.com/settings/replies
|
Since I'm not a team member, I'm not privy to that info....
#11161 seems to have been abandoned?!
That may be so, that's why I did the breakdown (one of which removes the "feature request" which gives an actual better indication of the issues) & was trying to have everything currently labelled as it makes it easier to go through for review/closing etc. |
I think we'd all be wasting our time if the/a bot is still considered. So unless sledgehammer999 or whoever becomes the new maintainer explicitly says that the idea is abandoned, i'll refrain from doing such a thing.
Sorry but i'm lazy :). If there was a close+lock button i might consider it. I think it's preferable to have a very small % of issues being necro'ed than having to perform 2 clicks on every last one of them, one of which is most probably pointless (IMO). Oh i don't remember if i mentioned it again but personally, i see nothing wrong with necro-ing. I never understood why some people hate it. I'll see if i can find the duplicates. |
Of course a bot would be the preferred way of carrying out this task all the way to completion, but recently you've already taken to closing issues with messages like "most likely fixed" and "useless information provided" (effectively doing part of the bot's work), so might as well use the nice boilerplate. WIth GitHub saved replies, it's probably faster as well, just 3 clicks: 1 - click icon; 2 - click reply; 3 - click comment. Ideal for lazy people :)
This is a joke, right? The cost of 2 or 3 extra measly clicks is more than offset by the fact you won't receive a useless notification for a necro'ed thread with new comments that do not present any new useful or actionable information in the future. It's not about the % of issues being necro'ed, it's about the % of (useless) traffic coming from them compared to new issues/new developments on currently open issues. It's significant enough to be a nuisance for those that are subscribed to all repo notifications, such as me. If anyone wants/needs to resurrect an issue topic, they should open a new issue with full information as requested by the issue template, to save everyone's (especially the contributor's) time. The user just has to put in the effort to write a new issue, the contributors "have" to answer to multiple ones. @sledgehammer999 themselves understood the importance and necessity of locking closed issues, and designed the tool/plan to do exactly that:
(emphasis mine)
I see you've resolved more than half of them already, great job 👍 |
#12574 is effectively an implementation of it. I'm shouting fire in a crowded theater to get it merged, but no one is moving (I think because the decision to merge such a PR is implicitly understood to be the sole responsibility of the maintainer, but they're away and they're not the ones who manage the issue tracker). That issue you linked is a good reference, if others want more template categories such as those mentioned in that issue, I can add them.
The thing is, it is useless to label issues that would get closed anyway by the bot/tool due to the being too old. That is the real blocker. Old issues need to be closed first - all the rest comes after. I only mention the new labeling system now because I think we might need to start investing in this effort that in parallel; it has been so long, that many new (as in, posted post-February 2020) have started to accumulate unlabeled. I've always done my best to label all of the new issues since then, but indeed, with the current label system, sometimes I too face the problem of not being able to find a suitable label for some of the issues. EDIT: |
**Issues related to OP "user accounts" that have been deleted by github/now represented by "ghost" what should be done with these? (x60) #416 #428 #516 #590 #1167 |
Fair enough, at least now though we have some "direction" & "drive" while there's no new release to add more workload, otherwise I think we'd be just going around in circles.... Now, seems the right time to get a grasp on things.... |
The validity of some of those issues is not contingent on the OP's user account still existing (e.g. feature requests). However, some bug reports which only affect the OP can be closed, if they can't reasonably be reproduced. I'll see what I can do about them. Thanks for bringing this to my attention.
With all due respect, there are some internal team matters that you're not aware of that are stalling progress on this matter (expect to know more about this by the end of the year). Sadly, right now it's not possible to bring you into the team, even though you would definitely join it in some capacity, if it were up to me. Your initiative is much appreciated nonetheless, and you can rest assured that resolving this matter is still one of my top priorities. |
No problem, Just trying to do the best I can to make things easier (unless I'm making it worse, lol) Had to search page by page with
Appreciate that & totally understand. Also, #11175 & #9511 can probably be closed as well since there is some more active focus now no matter how small.... |
Ok, I went through them all. I was able to close some of them, not others. I tweaked the titles/labels where needed. Here's what's left open: #416 #428 #516 #590 #1167 There's a few of these I might close still, depending on whether I can reproduce them tomorrow. |
another tip to aid review/labelling etc is to click a "user name" to view what issues that user has created to date as sometimes they can be similar to ones they've already opened previously/duplicate of something that's already reported/taken care of by now or have more than one issue reported. |
30 remaining. |
planning to do a status update at wknd 02-04 OCT (time permitting.) |
What do you mean? Can you please elaborate about what you are working on? |
updating of this: #12679 (comment) this: #12679 (comment) & this: #12679 (comment) with latest figures etc. |
updated #12679 (comment) & #12679 (comment) with latest figures but didn't update #12679 (comment) as maintainer is back - will continue his own action plan. sledgehammer999 On a personal note, really glad to see you back & that you are ok!! I hope my actions here didn't have too much of a negative effect in what you had previously decided etc., you would've probably noticed anyway that the ghost issues would've been excluded in the search filters/batch tool |
Tuesday December 3rd 2019 - qBittorrent v4.2.0 release
Below may need a follow up though...... because of #11399 (comment) & #11399 (comment) |
|
It's a snippet of 4.2.0 Release History from official website |
|
How so? (Am I missing something obvious here?)
Doesn't that signify support for windows versions less than 7 are no longer supported so that means |
@xavier2k6 Oh God, I'm so sorry, I kept reading |
why not https://github.com/marketplace/stale ? |
Edit: similar #11363 |
qBittorrent v4.3.0 Released (Sunday October 18th 2020 )Support for libtorrent 1.1.x is dropped This makes 4.2.0 (Released Dec 3rd, 2019) the NEW MINIMUM supported version.
If we take We could potentially close:
NOTE:(Some Issues may have more than 1 designated Issue Tracker label assigned) |
@xavier2k6 I took care of the 6 "Invalid + Not an issue" issues and edited you post accordingly. |
Updated #12679 (comment) with new info/removed closed/taken care of, thanks @FranciscoPombal & general clean-up/aesthetics |
I have updated the tool and run it. It seems to have closed 594 old issues. |
Just finished double-checking those that i was mentioned/participating in - there are none that I would like to reopen 👍. However, only 594 closed is not enough IMO. We need either a more aggressive time interval or better heuristics. For example, detecting versions in the OP < 4.2.0. This could be done by simply checking for one, and only one instance of the string |
The 594 were the ones that were in the "instant close" category. |
@FranciscoPombal don't reopen this issue. It's purpose is done. |
@sledgehammer999 @FranciscoPombal please review #12679 (comment) again as (although not currently updated due to running of tool) 557 could be closed..... |
@sledgehammer999 The some examples: If I apply Does the labelling system need to be amended?? Here are the ones, that seem to show up: |
@FranciscoPombal Could you take a look at #12679 (comment) there was something like this before & when it was commented on or something like that.......it closed properly......perhaps a re-open/close may fix it?! |
Seems the scripts missed out on closing quite a few old issues, but that is a problem for another time. Tthis looks good to me: i.e., there are no open issues that are labeled with the auto close label. As for the closed issues that were still shown up with the |
@FranciscoPombal Thanks, seem to be fixed now alright from what I've checked. I think the scripts didn't take in to account the Will have to use something like e.g. |
@sledgehammer999 Do you plan to do another run of this batch tool in the near future? |
@qbittorrent/bug-handlers @qbittorrent/frequent-contributors
I have coded this tool in the past couple days.
It can close old issues, leave a comment, apply a label, lock the issue and skip issues with certain labels.
After I apply my other tool mentioned in #12101 I intend to run this tool on the repo with the following arguments:
I chose
2019-05-06T00:00:00Z
semi-randomly. It is the day after the v4.1.6 release which was about 1 year ago. I figured that all those issues can be closed instantly.PS: This will not close issues that were updated after that timepoint. eg by someone leaving a comment, applying a label etc.
A dry-run of the above cmdline shows that 819 will be closed.
Second Phase
After the above procedure, I plan the following for all issues between v4.1.6 and v4.2.0:
Do you have any comments on the above before I proceed?
The text was updated successfully, but these errors were encountered: