@markstos @futzle
- It allows for people to contribute a solution *eventually*
- It serves as a reference for people newly running into the same bug, especially if workarounds are suggested
- It doesn't communicate "I don't care about your work" (assuming you've communicated expectations correctly)
- It provides more reliable statistics on how well things are going in terms of reliability/support/etc., both to you and to potential contributors
- Closing it will just cause a new bug to be created once the next person runs across it anyways so it doesn't even meaningfully reduce your bugs anyway
Are those sufficient reasons? I'm sure there'll be a couple more reasons not to fudge the data if one thinks about it for a bit
@markstos @joepie91 I’d like to be untagged from this conversation, please. I’ve been in open source development teams myself and I’m yet to read anything compelling enough to change my mind. Not that I asked anyone to change my mind: my original post was about setting boundaries and it seems that some have taken this as an invitation to convince me to move my boundaries.
@markstos By this point it is clear to me that you are looking to justify your current position, rather than learning about a different one, so I am stepping out of this conversation.
There is not enough time in my day to be arguing with someone who only asks questions and then does nothing with the answers.
@joepie91 @futzle Most of the projects I volunteer with were written by an author who left the project. I was user who helped out and was given commit rights. Sometimes other users have stepped up and helped too, other times, not.
Some bug reporters seem to have the idea that there's someone behind the curtain who has the time and interest to craft the software to perfection or add endless features. In reality, often one or two volunteers trying to leave things better than the found them.