As a developer, when I hit a potential bug in an OSS lib I'm using, first thing I do is assume I'm doing something wrong (mileage varies by quality of the lib, of course). Then, back into a minimal reproducible example, if at all possible. By the time I actually submit a bug, I've already debugged for hours or days, sometimes even over weeks (once took me about 6 weeks of off again/on again debugging to find a bug in a Python DB lib I was using; the bug was in the C lib and in the certain circumstance I was hitting, uninitialized memory was being read).

Another case, I had a user raise an issue with mangling of datetimes in a C++ lib. Short of it is we were hitting an integer overflow issue. Under the hood, our datetime lib was using Boost to do the heavy lifting; our lib was mostly a facade over Boost. Boost being what it is, there was massive template instantiations. Templates all the way down... Anyways, somewhere along the instantiation chain, a 64-bit int got truncated to a 32-bit int and then promoted back to a 64-bit int. I think the bug was reported, and I don't there's a resolution some 10 years later (I haven't been doing C++ for a while, so haven't kept up). Definitely an issue trying to compute schedules for some 30 years in the future (Unix 32-bit Y2K type issue is in 2037 when 32-bit time_t overflows).

Also, I assume failure. I mean, software is written by fallible human beings. There will be bugs, crashes, etc. Sometimes the bug is in the implementation, sometimes it can even be a bug in the requirements. Users asked for X, but they really needed Y. If you want a favorable resolution to an issue, you need to be ready to work with the developer, not against them. This may be providing logs, inputs, steps to reproduce, etc.

I've had times where, as a developer, I've had users provide me fairly detailed steps to reproduce, but, well, I couldn't reproduce it. In those cases, ended up sending something along the lines of "let's cut the email; I'll come to your desk and watch exactly what you do." In those cases, they usually omitted a step they thought was inconsequential, but really wasn't (not that they'd know that).

I had one very expensive (for the client) incident at a former employer where we eventually sold the source code to the client to divest ourselves of a joint venture. The client then turned around and hired a 3rd party developer to continue development. As part of the hand off, we documented in pain staking detail the environment, versions of dependencies used, etc. It was a Python app and only have about 2 non-stdlib dependencies. However, those 2 dependencies each had bugs that had not been fixed upstream (patches had been submitted). We left very explicit instructions about download this specific version, then apply supplied patch, then install. We started getting emails along the lines of "Nothing works!!", and of course, we were like: "Did you follow the instructions?" and the response was: "Yes, of course we did.". We were unable to reproduce on our side, as we actually followed the instructions to the letter. After several weeks of back and forth and not being able to reproduce, I offered to visit the 3rd party developer to sit with them while they attempted to setup their environment. We started from scratch, and immediately it was apparent that they completely disregarded our instructions and downloaded the latest version of everything and didn't apply the patches (which wouldn't have worked because of the differences between the versions). 3 weeks of my time, billed at $500/hr 10 years ago. Yeah, I billed $60,000 over 3 weeks because a 3rd party didn't follow very explicit and detailed instructions. Not that I saw a dime of that...