Sven Slootweg @joepie91@pixie.town

@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.

@markstos @futzle Oh, and bonus reason: it allows for identifying patterns in bug reports that suggest a more structural change that can be made to solve a lot of issues at once, instead of whack-a-moling individual issues forever

@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 @futzle (Also, if you want more volunteers, a good start would probably be to recognize that people submitting detailed bugs are *also* contributors, and not indiscriminately closing their issues without ever resolving them, which is functionally equivalent to telling them you don't care about their work.)

@markstos @futzle I have read the whole thing. No, it is not just for commercial teams, that is just the context in which it is explained.

I have also been doing open-source development and community management for some 15 years by this point so I understand perfectly well how volunteer work works, thank you.

@markstos @futzle Here's an extensive guide that suggests some strategies: https://apenwarr.ca/log/20171213

@rvansleen Ik denk dat het heel erg nuttig zou zijn, als het zo geschreven zou worden als de 'ouderwetse' boeken over "hoe met Office te werken" enzo - dus veel uitleg van basisconcepten, schermafbeeldingen en stap-voor-stap instructies.

De nerds weten doorgaans wel wat er te vinden is in open-sourceland, en zo niet, dan komen ze er met wat googlen ook wel uit. De 'leken', echter, hebben vaak toch echt meer hulp nodig, en daar wordt maar weinig meer voor geschreven.

Of je het qua energieniveau aan kan, dat is een vraag die ik niet voor je kan beantwoorden. Mogelijk is het haalbaar als je iemand anders vindt die hier ook aan mee wil werken?

@markstos @futzle The underlying point here is that there are a lot of ways to deal with the situation of "too many problems to fix" and stalebots (or manual approximations of them) is probably literally the least-respectful-to-contributors option at your disposal.

@markstos @futzle The problem here is closing an issue for a still-existing problem to begin with, whether it's automated or manual is besides the point really.

An open issue costs nothing if you have a halfway decent workflow (eg. having some kind of sorting metric to prioritize work, and communicating that not all issues may be solved).