6 ms·

Having robust reply templates is pretty key. If the templates explain why a thing was closed, there isn't much for the user to refute. They can always fume, but

Having robust reply templates is pretty key. If the templates explain why a thing was closed, there isn't much for the user to refute. They can always fume, but fuming on a closed ticket is like screaming into the void. Leveraging bots helps as well. e.g. if an issue template isn't followed, removed, or omits key required info the issue is closed by a bot and a reply is dropped letting the user know that their attempt to circumvent the requirements means they get no support.

necrotic_comp 6y ago
I quite like the idea of using bots - that way there's no human making a decision, and since we've already internalized bots as cold and unfeeling, no one's feelings are hurt. IIRC, Gentoo does this, and my first patch was rejected multiple times. But because it was a bot that responded,I just felt like I had made a mistake, whereas with a human in the mix I probably would've asked a bunch of a questions and wasted her time and mine.
gitgud 6y ago
Bots are good in moderation, but in some cases bots can annoy everyone involved... For example; the Angular repository has a "stale bot", which closes and locks the issue after a certain amount of time of inactivity. This sounds great on the surface, however it's insane in practice. The users constantly need to recreate duplicate issues, as the original issue is locked. Most of the duplicates are not linked, so maintainers can't determine which issues are duplicates. And it also increases the friction of users notifying that the issue is still occurring. Basically the result of "stale bots" is more duplicate issues and less engagement on old issues (as they're locked) Moral of the story, use bots in moderation
- andrew_ 6y ago
  I manage a couple of high volume projects on a few open source initiatives. Stalebot is a sanity saver. Users are always welcome to trigger the bot to reopen. I won't presume your experience on open source projects of a big size, but when you're dealing with dozens of new issues daily, and have hundreds of issues that go back five years with no activity, the stalebot saves the day. That speaks to another issue of open source - it's more common than not for a user to report an issue with no intention of following up, nor helping to triage (let alone contributing). Drive-by issues are noise and take precious time away from maintainers. There again, stalebot steps in to help. YMMV but my personal experience is that we don't get too many reopens, and we don't get too many duplicates from closed issues.
  - switchbak 6y ago
    Drive by issues are noise? So if I say "library X fails with this input" and don't follow up/triage/commit code, then this is a waste of time? I strongly disagree. Follow-up and collaboration are great, but someone taking the time to write a decent bug report is also valuable.
    - detaro 6y ago
      Presumably if it's a "decent bug report", needing additional feedback etc is less likely, and I assume GP is more talking about bug reports that are not really usable without further information. (Although even if you are careful at providing information, you can easily hit cases where more information is needed)
    - andrew_ 6y ago
      This presumes that all opened issues are decent. It also presumes that the author of the issue responds to feedback. What I would quantify as drive-by issues include poorly written, lacking information, or providing information that results in a follow up reply from other users or maintainers with a fix or ask for more information that goes unanswered. "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
      - account42 6y ago
        Closing bugs because they don't contain enough info and the reporter is not responsive to providing the required info is commpletely fine. Closing based on inactivity alone is just rude. > "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies. They could still be a hint that the documentation or reported error could be clearer.
        andrew_ 6y ago
        We disagree. My experience with several extremely large projects has yielded the judgement that closing tickets which are years old without activity is prudent, as is setting a reasonable time frame in which an issue is too stale.
mlindner 6y ago
I'm going to disagree as someone who reports issues to open source. Often the templates request info I know as an experienced user of the software to be completely irrelevant to the issue, and if provided would only confuse the cause of the problem. Templates often assume a stupidity level of issue submitters. If there is a github template, I'll usually heavily modify the template and delete sections, which then gets flagged by a bot if such a bot exists. This only slows down the process of getting something fixed, not speed it up.
- roryokane 6y ago
  A compromise could be to have a bot to check the issue template, but to make the bot aware of users' contribution histories. The bot would skip checking the format of someone's issue if, for example, they had already reported at least three bugs or gotten one patch merged.
- andrew_ 6y ago
  Frankly; it's not up to you to determine what info maintainers need - thinking otherwise is an entirely entitled point of view. That's why the project members and maintainers ask for what they need to triage not just your issue, but all issues from a wide variety of users on any variety of platforms. If you can't take a few extra seconds to enter information in a template, why on earth should maintainers donate their time to you to triage what you're reporting?
  - tga_d 6y ago
    While I agree with the point you're making, I'd like to point out the tone of your wording. It's not cruel or anything, but there are some pretty easy changes to it that could have made it an explanation instead of an argument. As for the original point: I suspect every developer has encountered a bug in their code that couldn't possibly be caused by something, but ultimately was. Getting all the information requested up front in a regularly structured way, even when we think it's irrelevant, can make tracking these problems much easier.

necrotic_comp 6y ago

I quite like the idea of using bots - that way there's no human making a decision, and since we've already internalized bots as cold and unfeeling, no one's feelings are hurt. IIRC, Gentoo does this, and my first patch was rejected multiple times. But because it was a bot that responded,I just felt like I had made a mistake, whereas with a human in the mix I probably would've asked a bunch of a questions and wasted her time and mine.

gitgud 6y ago

Bots are good in moderation, but in some cases bots can annoy everyone involved... For example; the Angular repository has a "stale bot", which closes and locks the issue after a certain amount of time of inactivity. This sounds great on the surface, however it's insane in practice. The users constantly need to recreate duplicate issues, as the original issue is locked. Most of the duplicates are not linked, so maintainers can't determine which issues are duplicates. And it also increases the friction of users notifying that the issue is still occurring. Basically the result of "stale bots" is more duplicate issues and less engagement on old issues (as they're locked) Moral of the story, use bots in moderation

andrew_ 6y ago
I manage a couple of high volume projects on a few open source initiatives. Stalebot is a sanity saver. Users are always welcome to trigger the bot to reopen. I won't presume your experience on open source projects of a big size, but when you're dealing with dozens of new issues daily, and have hundreds of issues that go back five years with no activity, the stalebot saves the day. That speaks to another issue of open source - it's more common than not for a user to report an issue with no intention of following up, nor helping to triage (let alone contributing). Drive-by issues are noise and take precious time away from maintainers. There again, stalebot steps in to help. YMMV but my personal experience is that we don't get too many reopens, and we don't get too many duplicates from closed issues.
- switchbak 6y ago
  Drive by issues are noise? So if I say "library X fails with this input" and don't follow up/triage/commit code, then this is a waste of time? I strongly disagree. Follow-up and collaboration are great, but someone taking the time to write a decent bug report is also valuable.
  - detaro 6y ago
    Presumably if it's a "decent bug report", needing additional feedback etc is less likely, and I assume GP is more talking about bug reports that are not really usable without further information. (Although even if you are careful at providing information, you can easily hit cases where more information is needed)
  - andrew_ 6y ago
    This presumes that all opened issues are decent. It also presumes that the author of the issue responds to feedback. What I would quantify as drive-by issues include poorly written, lacking information, or providing information that results in a follow up reply from other users or maintainers with a fix or ask for more information that goes unanswered. "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies.
    - account42 6y ago
      Closing bugs because they don't contain enough info and the reporter is not responsive to providing the required info is commpletely fine. Closing based on inactivity alone is just rude. > "library X fails with this input" is great, unless the input is wrong, the usage is wrong, or the environment is awry - and those issues are useless if the author doesn't reply to follow up replies. They could still be a hint that the documentation or reported error could be clearer.
      - andrew_ 6y ago
        We disagree. My experience with several extremely large projects has yielded the judgement that closing tickets which are years old without activity is prudent, as is setting a reasonable time frame in which an issue is too stale.

mlindner 6y ago

I'm going to disagree as someone who reports issues to open source. Often the templates request info I know as an experienced user of the software to be completely irrelevant to the issue, and if provided would only confuse the cause of the problem. Templates often assume a stupidity level of issue submitters. If there is a github template, I'll usually heavily modify the template and delete sections, which then gets flagged by a bot if such a bot exists. This only slows down the process of getting something fixed, not speed it up.

roryokane 6y ago
A compromise could be to have a bot to check the issue template, but to make the bot aware of users' contribution histories. The bot would skip checking the format of someone's issue if, for example, they had already reported at least three bugs or gotten one patch merged.
andrew_ 6y ago
Frankly; it's not up to you to determine what info maintainers need - thinking otherwise is an entirely entitled point of view. That's why the project members and maintainers ask for what they need to triage not just your issue, but all issues from a wide variety of users on any variety of platforms. If you can't take a few extra seconds to enter information in a template, why on earth should maintainers donate their time to you to triage what you're reporting?
- tga_d 6y ago
  While I agree with the point you're making, I'd like to point out the tone of your wording. It's not cruel or anything, but there are some pretty easy changes to it that could have made it an explanation instead of an argument. As for the original point: I suspect every developer has encountered a bug in their code that couldn't possibly be caused by something, but ultimately was. Getting all the information requested up front in a regularly structured way, even when we think it's irrelevant, can make tracking these problems much easier.