Issue Grooming
github.com
github.com
Compare it to the Istio project which just deletes your issue if someone doesn't respond it to after 28 days. Despite the issue often being quite real.
Also I wonder how these larger projects will fare once Github rolls out the Discussions feature.
Like the whole CLR telemetry thing.
Sure, you have closed the issue because you did not pay attention to it for the last year. But the problem is still there. So the next person who stumbles upon the old, locked issue will now open a new one. Now you have two issues.
Whenever I came across these issues, I'd just open up a new issue and link to the old one and politely ask if they planned on addressing it or not.
The quest for the perfect issue grooming continues.
Example: https://github.com/microsoft/vscode/issues/86409#issuecommen...
And auto-closing doesn’t mean the issue can’t be reopened. If OP posts additional information after the grace period, the maintainers will be notified and the ticket can be reopened.
But in the end, whatever works for you!
In this case, wouldn't it fall under being "not accurate" if the issuer doesn't supply requested information showing that it's accurate?
I also don’t like them, but it does force the reporter to stay engaged and bump issues they really care about.
Issue management seems like a major surface for Github to improve on.
I have a work category for each of my projects named simply “ticket laundry” and I know it eats up a lot of time for maintainers and reporters.
The only reason I knew those github issues existed in the first place was because I wasted hours (sometimes days) of my life looking into an issue only to eventually stumble upon them and realize its a bug and I'm not "holding it wrong". Good luck to the next person that goes spelunking on the internet for help on those issues.
Reminds me of: https://xkcd.com/979/
I think having a bot tag, but not close, issues over a certain age, seems to make a lot of sense.
Here's a nice write-up I found: https://dzhavat.github.io/2020/04/04/my-thoughts-on-github-d...
There are two common cases where some automation can help:
- User reports bug, dev explains that "it's not a bug, here's why, xxx" (or otherwise provides a satisfactory response) and user, even if satisfied, fails to return to close bug. So instead devs have to remember to close the bug which they usually do immediately after responding, which comes off as abrupt, even though it's not meant that way.
- User reports bug, dev responds with request for more info ("I can't duplicate; could you provide a better test case?"), user never responds.
In both cases it's OK to time out these old reports (which are essentially clutter). You could provide a way for the dev to flag this as one not to be auto-cleaned up.
Another improvement, while I'm at it: provide a Godbolt-like way to submit a test case that can be outrun (i.e. a CI case). Then the bug could be auto-closed if it's in the current release but already fixed in the dev sources. Not all bugs or applications could take advantage of this of course.
For example just one issue last hour "Slow performance" and basically list of extensions, OS info. To track that one down, they should test each and every extension listed, and still might not have a good understanding what is going on.
Everything ends up in a giant "bag", where you end up with 1000+ "issues". While you can go into issues then sort by a given label, this has to be done actively, and constantly kept up to date.
I'd prefer something more like an 'inbox', where issues can be filed into different categories which moves the out of the 'new' section. This is what most large projects are doing anyway with labels.
I think they use the backlog milestone for this, which acts as the folder of issues they will eventually work on. https://github.com/microsoft/vscode/milestone/8
The downside with GitHub projects is that you can't automate based on labels so the issues need to be organised into columns manually if you have more than the simple one board with To-Do/In-Progress/Done columns setup. Though search and filters slightly helps with that.
A majority of GitHub's users' first experience interacting with a bug tracker was probably on GitHub, so they never really knew any better. The rest seem to be experiencing some collective amnesia about how to effectively file and otherwise triage/manage bugs. Basically none of the issues ever stumbled upon start with a clear and anodyne set of steps to reproduce. Every "issue" is a conversation. (And this seems to be not only tolerated but encouraged. It's madness.) About half are support requests, maybe more. Even when GitHub is used "correctly" to file bona fide bugs, on the whole, project maintainers seem to treat it as a general intake area for everyone else to file issues, and the project authors themselves hardly use it as their own database for known bugs. They're all jotting down vague descriptions in a text file that stays on their local machine or something, who knows.
The entire phenomenon and attitude has to be one of the top 5 most annoying things about software development in 2020.
It has labels but most people just the powerful search abilities... It's not that different from Gmail in a lot of ways...
Before I could just do `node --inspect index.js` and get the debugger to auto attach with my node version set using NVM. There's a few different flags to try. I ended up wasting a few hours to just get debugging working again. Now I have to actually set a launch profile (I've got one which works) but wading through all the issues because they've changed, to me, a fundamental feature was just plan frustrating.
The is _so_ much churn and worthless changes in the JS ecosystem. AFAIK it's the only ecosystem that has this much churn, which proves that it's not necessary.
My best example of this is the fact that I can now no longer yarn install <package>. Instead, yarn informs me, the command is now yarn add <package>. For gods sake.
Every time I upgrade or build a project more than a week old I'm almost virtually guaranteed to have a deprecation warning somewhere in my stack, that's infuriating too.
And it takes me out of my flow. I'm solving difficult problem and these sorts of things, constant and unpredictable, make that task harder.
https://engineering.fb.com/web/yarn-a-new-package-manager-fo...
ah its funny what people qualify as "proof" these days. Javascript is in the unique position of being the only language integrated into browsers, surely you recognize that this is a big factor in the ecosystem?
Trivial faster-than-N^2 algorithm:
1. Compute simhash of each issue - O(1) in N, the number of issues.
2. Sort the issues by hamming distance of simhash (N log N in the number of issues)
3. Pick the K issues before or after the current issue in the results (O(1) in the number of issues)
You can precompute/incrementally update any of these steps as issues are added. This would make find duplicates itself O(1) because it would just be step 3.
If you put this in term of size of text in the issues instead of number (which is what you used) it changes the time bounds, but, for example, it's not any worse than sorting/comparing the issues as text strings.
Once upon a time, GNOME had 300 bugs in evolution bugzilla, and it was felt as "the end of the world."
What they need to do is just like GNOME projects a decade+ ago did: make a really hard, like HAAAARD! feature freeze, and keep doing long series of "housekeeping" releases as long as needed before unfreezing work on features.
The definition of that word is changing and not accepting that fact looks dated. Might just be my opinion, feel free to comment if you disagree.
[1] https://www.bing.com/search?q=grooming
No, it just has multiple definitions, like many words do.
Grooming is not an irregular word. The act of grooming oneself is hopefully a regular activity. Brushing your teeth, trimming your nails, getting hair cuts, etc. The word is also regularly used with pets.
IMO this is like when a while back all the news sites were talking about how the OK hand sign was a white supremacist symbol. If everyone had stopped using it, then perhaps it would still be seen as a symbol for that. But everyone that that was dumb and kept using it the way it always has always has been and that new association was lost.
Dozens and dozens of terms in our industry have "other" meanings.
For example it is common to talk about "pegging" a server -- a reference to how physical speedometers and other such gauges used to work. "Pegging" has a more recent sexual meaning as well.
And then of course there is "penetration" testing in the security sphere.
And so on and so on. It's fine. There is no conflict.
https://www.thefreedictionary.com/nonce
(I see that it is primarily a UK term)
Anecdotally...
I remember hearing and reading "pegged" in an IT context back in the 1990s, at least 10-15 years before the sex term seemed to gain widespread usage. It was definitely used in entirely work-safe contexts where one would never dream of making anal sex references.
Of course, now that you mention it, I think your belief is likely common enough to make me reconsider its use! I think a lot of folks hearing "pegging" in 2020 probably think of the sex practice before they think of speedometers -- a lot of people don't have cars, and many that do never notice the little pegs.
However, I do think "pegging" (a somewhat obscure IT jargon term, with obscure etymology) is in a different situation than "grooming," an incredibly common everyday word. Retiring a bit of jargon is entirely different than retiring a an everyday word.