7 ms·

Issue Grooming

81 points by pcr910303 6y ago

niffydroid 6y ago
I can understand why so many issues get created. I've had to read through quite a few issues for node.js debugging issues because they've made changes to the feature. 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.
- SCHiM 6y ago
  I'm solidly in 'that' crowd. 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.
  - daniellarusso 6y ago
    It pays well, at least, right?
    - sixothree 6y ago
      I always hate explaining these kinds of issues to whomever is paying me. I always feel guilty when I have to log "4 hours debugging tooling". 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.
  - noahlange 6y ago
    For what it's worth, "yarn add" has been the "correct" way to add new dependencies from the beginning. https://engineering.fb.com/web/yarn-a-new-package-manager-for-javascript/ https://engineering.fb.com/web/yarn-a-new-package-manager-fo...
  - venatiodecorus 6y ago
    >AFAIK it's the only ecosystem that has this much churn, which proves that it's not necessary. 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?
    - coddle-hark 6y ago
      That doesn't explain churn in the tooling though. This isn't some new, pre 1.0 ecosystem; node has been around for 11 years now.
qaq 6y ago
Wow MS pc police is asleep ? We have not being allowed to use term grooming for like 2 years now.
moritonal 6y ago
The wiki is a great reference, but a search of the word "grooming" across Bing [¹], Google [²] and DuckDuckGo [³] all lead to references to child pedophilia. 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 https://www.bing.com/search?q=grooming [2] https://duckduckgo.com/?q=grooming https://duckduckgo.com/?q=grooming [3] https://www.google.com/search?q=grooming https://www.google.com/search?q=grooming
- JohnBooty 6y ago
  This is nothing new. 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.
  - sneak 6y ago
    My favorite: cryptography frequently uses a nonce.
    - deleted 6y ago
      [deleted]
    - JohnBooty 6y ago
      Ah. I was never even aware of the slang definition here: "prison slang a rapist or child molester; a sexual offender" Thank you for the knowledge! https://www.thefreedictionary.com/nonce https://www.thefreedictionary.com/nonce (I see that it is primarily a UK term)
  - bregma 6y ago
    Now I want to get a job in the server room. Boot strapping the master sounds like fun suddenly.
  - 6y ago
Ciantic 6y ago
I remember when the issue tracker for TypeScript or VSCode was still relatively new, the issue quality was much better. Now if you look at their issues, it's like trying to wade through spam, I hope they have specialized people who don't get demoralized from reading the issue list. 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.
- aloisdg 6y ago
  I would close the issue because the OP didnt search enough. A MCVE should be provided with steps to reproduce. OP should do the work of testing each extensions one by one
- Cthulhu_ 6y ago
  The bigger your OS project gets, the more you have a need for help curating and triaging issues; you need a team of customer support, basically. And patience. So much patience.
throwawgler87 6y ago
What do "dev question" and "user question" mean? Are these support questions that get asked using a GitHub Issue as the medium, rather than bug reports?
- DominikD 6y ago
  Yup, people do this all the time.
  - int_19h 6y ago
    And GitHub kinda endorses this by having a stock "question" label in newly created repos.
    - IshKebab 6y ago
      The VSCode recommend this as a way to get help. They used to have multiple channels, e.g. UserVoice, but closed them all in favour of just using GitHub Issues. I can't see anything obviously wrong with that.
CJefferson 6y ago
This is one area where I feel github is really letting us down. 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.
- DominikD 6y ago
  I definitely prefer this over trackers that for some inexplicable reason have different flows for bugs, requests, API comments, features and what not. The "inbox" you speak of already exists: unlabelled issues are your inbox. :)
- eznzt 6y ago
  Sure, there you have it: https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3Aopen+no%3Alabel https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3...
  - CJefferson 6y ago
    You are right, but I'd prefer myself something folder based. You could use the same argument to say mail clients don't need explicit folders, but most people seem to want them :)
    - Ajedi32 6y ago
      Gmail doesn't have folders. Even the Inbox is just a label.
- jayflux 6y ago
  > 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 https://github.com/microsoft/vscode/milestone/8
blackbear_ 6y ago
Finding duplicate issues should be an O(N^2) problem, I wonder how they manage to do it with 5.3k issues (28 million pairs)?
- DominikD 6y ago
  Institutional memory. If you work on a project long enough, you tend to remember these things. You may not recall the exact issue id, obviously, but you know you've seen something like this and there's a limited number of keywords you have to search to get there.
- Cthulhu_ 6y ago
  Hopefully they can edit or label issues in such a way that helps with searching for duplicates; older issues become a knowledge base / documentation. IIRC it's what Stack Overflow tried to do, turn questions into wiki pages / references.
- ThePadawan 6y ago
  You're not finding duplicates within open issues, you must find them among ALL issues. There are 20 times more, making that 400 times more pairs (10 billion).
- DannyBee 6y ago
  Nobody does this in an N^2 way. See simhash, minhash, etc 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.
threeseed 6y ago
I had a quick check and it looks like Microsoft doesn't have an automatic clean-up bot running which is really nice to see. 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.
- qz2 6y ago
  They don’t. They do however have a policy of closing down tickets which are unpopular after beating customers down. Like the whole CLR telemetry thing.
- gitgud 6y ago
  The @angular repositories do that too... The worst are the "lock bots" which prevents any new information being added to the issue... Which is super annoying.... But it must be hard for a maintainer to deal with the notifications
  - birracerveza 6y ago
    Yeah, but sweeping the issue under the rug is not the way to go. 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.
  - acoard 6y ago
    Doesn't this just cause more noise and notifications, not less? A stale issue can be ignored, a closed issue may be duplicated. 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.
- diggan 6y ago
  Seems they do have automatic cleanup but it's not documented. Seems if the label "needs more info" was added more than a week ago, they close the issue. The quest for the perfect issue grooming continues. Example: https://github.com/microsoft/vscode/issues/86409#issuecomment-713502637 https://github.com/microsoft/vscode/issues/86409#issuecommen...
baybal2 6y ago
The problem is that project like VSCode racking up these bugs, and letting them to snowball. It's not that they can't sort them out with 30+ full time professional QAs at Microsoft. 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.

81 points by pcr910303 6y ago

I can understand why so many issues get created. I've had to read through quite a few issues for node.js debugging issues because they've made changes to the feature. 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.

SCHiM 6y ago
I'm solidly in 'that' crowd. 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.
- daniellarusso 6y ago
  It pays well, at least, right?
  - sixothree 6y ago
    I always hate explaining these kinds of issues to whomever is paying me. I always feel guilty when I have to log "4 hours debugging tooling". 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.
- noahlange 6y ago
  For what it's worth, "yarn add" has been the "correct" way to add new dependencies from the beginning. https://engineering.fb.com/web/yarn-a-new-package-manager-for-javascript/ https://engineering.fb.com/web/yarn-a-new-package-manager-fo...
- venatiodecorus 6y ago
  >AFAIK it's the only ecosystem that has this much churn, which proves that it's not necessary. 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?
  - coddle-hark 6y ago
    That doesn't explain churn in the tooling though. This isn't some new, pre 1.0 ecosystem; node has been around for 11 years now.

qaq 6y ago

Wow MS pc police is asleep ? We have not being allowed to use term grooming for like 2 years now.

moritonal 6y ago

The wiki is a great reference, but a search of the word "grooming" across Bing [¹], Google [²] and DuckDuckGo [³] all lead to references to child pedophilia. 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 https://www.bing.com/search?q=grooming [2] https://duckduckgo.com/?q=grooming https://duckduckgo.com/?q=grooming [3] https://www.google.com/search?q=grooming https://www.google.com/search?q=grooming

JohnBooty 6y ago
This is nothing new. 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.
- sneak 6y ago
  My favorite: cryptography frequently uses a nonce.
  - deleted 6y ago
    [deleted]
  - JohnBooty 6y ago
    Ah. I was never even aware of the slang definition here: "prison slang a rapist or child molester; a sexual offender" Thank you for the knowledge! https://www.thefreedictionary.com/nonce https://www.thefreedictionary.com/nonce (I see that it is primarily a UK term)
- bregma 6y ago
  Now I want to get a job in the server room. Boot strapping the master sounds like fun suddenly.
- 6y ago

Ciantic 6y ago

I remember when the issue tracker for TypeScript or VSCode was still relatively new, the issue quality was much better. Now if you look at their issues, it's like trying to wade through spam, I hope they have specialized people who don't get demoralized from reading the issue list. 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.

aloisdg 6y ago
I would close the issue because the OP didnt search enough. A MCVE should be provided with steps to reproduce. OP should do the work of testing each extensions one by one
Cthulhu_ 6y ago
The bigger your OS project gets, the more you have a need for help curating and triaging issues; you need a team of customer support, basically. And patience. So much patience.

throwawgler87 6y ago

What do "dev question" and "user question" mean? Are these support questions that get asked using a GitHub Issue as the medium, rather than bug reports?

DominikD 6y ago
Yup, people do this all the time.
- int_19h 6y ago
  And GitHub kinda endorses this by having a stock "question" label in newly created repos.
  - IshKebab 6y ago
    The VSCode recommend this as a way to get help. They used to have multiple channels, e.g. UserVoice, but closed them all in favour of just using GitHub Issues. I can't see anything obviously wrong with that.

CJefferson 6y ago

This is one area where I feel github is really letting us down. 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.

DominikD 6y ago
I definitely prefer this over trackers that for some inexplicable reason have different flows for bugs, requests, API comments, features and what not. The "inbox" you speak of already exists: unlabelled issues are your inbox. :)
eznzt 6y ago
Sure, there you have it: https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3Aopen+no%3Alabel https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3...
- CJefferson 6y ago
  You are right, but I'd prefer myself something folder based. You could use the same argument to say mail clients don't need explicit folders, but most people seem to want them :)
  - Ajedi32 6y ago
    Gmail doesn't have folders. Even the Inbox is just a label.
jayflux 6y ago
> 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 https://github.com/microsoft/vscode/milestone/8

blackbear_ 6y ago

Finding duplicate issues should be an O(N^2) problem, I wonder how they manage to do it with 5.3k issues (28 million pairs)?

DominikD 6y ago
Institutional memory. If you work on a project long enough, you tend to remember these things. You may not recall the exact issue id, obviously, but you know you've seen something like this and there's a limited number of keywords you have to search to get there.
Cthulhu_ 6y ago
Hopefully they can edit or label issues in such a way that helps with searching for duplicates; older issues become a knowledge base / documentation. IIRC it's what Stack Overflow tried to do, turn questions into wiki pages / references.
ThePadawan 6y ago
You're not finding duplicates within open issues, you must find them among ALL issues. There are 20 times more, making that 400 times more pairs (10 billion).
DannyBee 6y ago
Nobody does this in an N^2 way. See simhash, minhash, etc 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.

threeseed 6y ago

I had a quick check and it looks like Microsoft doesn't have an automatic clean-up bot running which is really nice to see. 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.

qz2 6y ago
They don’t. They do however have a policy of closing down tickets which are unpopular after beating customers down. Like the whole CLR telemetry thing.
gitgud 6y ago
The @angular repositories do that too... The worst are the "lock bots" which prevents any new information being added to the issue... Which is super annoying.... But it must be hard for a maintainer to deal with the notifications
- birracerveza 6y ago
  Yeah, but sweeping the issue under the rug is not the way to go. 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.
- acoard 6y ago
  Doesn't this just cause more noise and notifications, not less? A stale issue can be ignored, a closed issue may be duplicated. 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.
diggan 6y ago
Seems they do have automatic cleanup but it's not documented. Seems if the label "needs more info" was added more than a week ago, they close the issue. The quest for the perfect issue grooming continues. Example: https://github.com/microsoft/vscode/issues/86409#issuecomment-713502637 https://github.com/microsoft/vscode/issues/86409#issuecommen...

baybal2 6y ago

The problem is that project like VSCode racking up these bugs, and letting them to snowball. It's not that they can't sort them out with 30+ full time professional QAs at Microsoft. 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.