Recently an interesting commit landed in the GNU Emacs Flycheck package, which shows diagnostics obtained from 'checkers', including Emacs language server clients such as Eglot (which are in turn getting their diagnostics from language servers for various languages). In the commit ( also ), Flycheck was updated to better handle a diagnostic source that reported information asynchronously; one such source is Eglot , partly because the diagnostics come from talking with language server processes.

The bug report for this stems from something I reported , and then when the core bug I reported was fixed, I reported a side effect of the fix . When I made the initial bug report I reproduced the issue both with and without Eglot, because I wanted to be sure that this wasn't specific to Flycheck's integration with Eglot. Since the initial issue was independent of Eglot, when I saw that the fix had a side effect I didn't bother to redo the dual check and tested in Eglot because it was most convenient.

(I have a Go project with a known issue Flycheck will report and I normally use Eglot with Go code. It's a lingering issue because I disagree with the specific lint diagnostic.)

I assumed that because the initial issue hadn't depended on Eglot versus non-Eglot, the new problem didn't either. This turned out to be incorrect because of a detail I hadn't known before I saw it in the commit , which is that Eglot produces diagnostics asynchronously while Flycheck's conventional checkers produce them synchronously (from Flycheck's perspective, although the checking happens in the background from your main Emacs work). If I'd known this detail I'd have checked in both situations but since I didn't, I assumed that all sources of diagnostics were functionally the same and I could test in whichever was most convenient.

I knew that bug reports were hard and that details could matter, and I still made an assumption when making my report of the side effect , which was in effect a bug report about a new issue. The assumption seemed reasonable based on what I knew, but I also didn't know all the inner details of how the system operated and one of those inner details turned out to matter and make a difference.

You (I) can and should draw an analogy to people reporting problems in our systems. I know the inner details of how our systems work and what details (probably) matter and which ones don't, but the people who are using our systems don't know either. It should not be a surprise to me to get problem reports that have irrelevant information in them but omit important details. What's happening is that people are guessing or making assumptions about what details matter and which ones don't, just like I did. And just as I did, maybe the person was fully detailed in their initial problem report but then when there are follow-up problems they start making assumptions about what they can not bother checking, trying, and so on.

(Because let's face it, doing all of those checks and looking at everything and so on is work, and if it turns out to be pointless you'll feel annoyed about it. At a certain point people stop doing work that only ends up annoying them.)

Applications to the experiences we system administrators have when filing problem reports with various organizations are left as an exercise to the reader. I may feel a bit more sympathetic to the organizations now, since they're dealing with this too (but certain behaviors are still quite irritating).