4 ms·

> ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementio

> ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.” This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope. It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.

kenjackson 5y ago
There are multiple types of issues. You’re describing a bug in a very pure sense. But often the most important issues are customer issues where they are blocked and need help. Then it is less about the big that you’re tracking and more about this customers experience. The resolution to their issue might not even be in your products code, but we still track it until the customer is unblocked to use our product.
- pwdisswordfish0 5y ago
  > Then it is less about the big that you’re tracking and more about this customers experience. Obviously. (Isn't it? Not sure why this explanation is appearing as a reply here. How could the previous comment have been written without a strong understanding that there's distinction? Why would it have been written unless there was a strong belief in the distinction?) > we still track it until the customer is unblocked As you should... in some place that isn't the bug tracker. (See "muddled.")
User23 5y ago
You're focusing too much on correctness. Bug reports are almost never because a user has identified incorrect behavior, they are because the user has identified unpleasant behavior. The maintainer then takes that reported unpleasantness and decides whether it's a bug or a feature. If it's a bug then the maintainer, usually implicitly, updates the program specification such that the unpleasant behavior is now incorrect, perhaps by writing a test, and then corrects the incorrect behavior. But since the primary motivator is actually the user's reported unpleasant behavior, it makes sense to check that the now correct software also behaves pleasantly for the reporting user. And since pleased users may well just be using the software instead of following up in the bug tracker, it makes sense to close those issues with the proviso that displeased users are welcome to reopen them. It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.

kenjackson 5y ago

There are multiple types of issues. You’re describing a bug in a very pure sense. But often the most important issues are customer issues where they are blocked and need help. Then it is less about the big that you’re tracking and more about this customers experience. The resolution to their issue might not even be in your products code, but we still track it until the customer is unblocked to use our product.

pwdisswordfish0 5y ago
> Then it is less about the big that you’re tracking and more about this customers experience. Obviously. (Isn't it? Not sure why this explanation is appearing as a reply here. How could the previous comment have been written without a strong understanding that there's distinction? Why would it have been written unless there was a strong belief in the distinction?) > we still track it until the customer is unblocked As you should... in some place that isn't the bug tracker. (See "muddled.")

User23 5y ago

You're focusing too much on correctness. Bug reports are almost never because a user has identified incorrect behavior, they are because the user has identified unpleasant behavior. The maintainer then takes that reported unpleasantness and decides whether it's a bug or a feature. If it's a bug then the maintainer, usually implicitly, updates the program specification such that the unpleasant behavior is now incorrect, perhaps by writing a test, and then corrects the incorrect behavior. But since the primary motivator is actually the user's reported unpleasant behavior, it makes sense to check that the now correct software also behaves pleasantly for the reporting user. And since pleased users may well just be using the software instead of following up in the bug tracker, it makes sense to close those issues with the proviso that displeased users are welcome to reopen them. It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.