If I had written some code to solve a problem of mine, I'd want to know that it contains bugs; I would not want to wait until those bugs blew my systems up.
Even if it was past code that has run its course and I no longer use, if the code is posted somewhere such as github, future users might want to read the list of bugs reported by others to be aware of them (and to see workarounds potentially posted by others).
Some bugs are due to an esoteric setup of the user. There in a quasi infinite variation of those in the Linux world. Generally, supporting them makes the software more robust, but it's also very likely that you would never encounter that bug yourself.
Some bugs are just support requests. The user didn't understand how to use the software and is confused. Generally the report is quite lacking and it takes a few back and forth to get somewhere.
That's true to some extent. If you see a lot of users having the same issue it might be the case. Sometimes it's also people not bothering to read the documentation.
As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
> Sometimes it's also people not bothering to read the documentation.
Yes, sometimes it is.
> As a maintainer it's also your right to develop a tool just for yourself, and share it for the world. In which case, documentation is not necessarily the priority. And it's fine.
Absolutely fine. Although I'll point out that it is usually a lot easier to get documentation PRs contributed than code PRs.
Even if it was past code that has run its course and I no longer use, if the code is posted somewhere such as github, future users might want to read the list of bugs reported by others to be aware of them (and to see workarounds potentially posted by others).