5 ms·

From brief conversations with the team behind the GitHub stale bot, the original idea was clearing up tickets where the user didn't respond to the maintainer. I

From brief conversations with the team behind the GitHub stale bot, the original idea was clearing up tickets where the user didn't respond to the maintainer. I don't think this is what happens usually though. Sadly most cases I see are the same as the angular case in this article. I made an issue suggesting tickets not be marked as stale if they've not had a maintainer comment yet. As you can imagine, the stale bot installed on the repo itself kept trying to close it due to it being "stale". After several months the irony wore off and I let it get closed.

tobr 6y ago
Ideally an issue is not a conversation between a “user” and a “maintainer” though, but a place for a community to coordinate around a bug or feature request. I wouldn’t open an issue unless I thought someone more than me might find the topic useful, and so I also don’t feel like I have an obligation to participate in the conversation – after all, it’s not about me, but about ways to improve the code. I find it somewhat offensive when people post to request support on something that can’t reasonably be useful to anyone else.
- geerlingguy 6y ago
  Sadly it seems about 90% of people don't have your mentality :( And the worse fact is, in terms of sponsorships the 10% of people who are more helpful in the issue queues and are already helping make maintainers lives easier are often the ones who consider sponsorship or other means of support. That's great, but it's disheartening that the people who feel entitled to an answer about a support question are almost 100x less likely to show any kind of support to open source projects (monetary or otherwise).
  - wolco5 6y ago
    This makes total sense. 10% of your users are superfans they read / understand everything you publish. They are so into it they give support (word of mouth, helping onboard others, bug patches, they will test alpha builds and give money/time where possible). 90% of users don't understand your product as well. They haven't totally bought in. They will need more support/handholding in order to convert. People are trying to get your product to work for their situation and if they can't 90% will go away and 10% will ask (usually dumb questions). Your unhappy with the 10% who can't get it working but want your product to work enough to bother to ask? I guess you can feel that way. Those 10% do represent an opportunity to get a group of people who want to use your product to onboard. The ones who tried and failed and never asked a question will probably never come back. If you ultimately want more support you are going to need to convert this group (or invest more time in advertising hoping to get more superusers/fanboys)
- cdubzzz 6y ago
  > Ideally an issue is not a conversation between a “user” and a “maintainer” though, but a place for a community to coordinate around a bug or feature request. What do you mean by this? A bug report or feature request will generally come from a “user” and is likely of interest to a “maintainer”. What should the two do if not converse? Neither the maintainer nor the user really knows whether or not an issue will be “reasonably useful to anyone else” without talking about it.
  - zeckalpha 6y ago
    Those personas are not mutually exclusive. Projects that divide the two don’t tend to be successful, leading to maintainer burnout, and autoclosed issues.
- studius 6y ago
  > it’s not about me, but about ways to improve the code This is true for me, but I also would admit that it's not all altruistic. Specifically, I will report problems that may be rare for others and unlikely to be reproducible by the maintainer. I often provide information about the operating system, version, etc. in those cases to put a reasonable amount of effort into it, but I don't always expect it to be fixed by the maintainer. However, if I determine later that the bug was caused by something else, I'll go find the bug I created and add a comment indicating that it was fixed or related to another problem, if it's simple.
rapnie 6y ago
A not-stale bot is needed here, that reacts on stale notifications. /s
abathur 6y ago
Right. In a very different context, I implemented something a lot like this for a game's bug tracker, using assignments. Ask the player to clarify something, assign the bug to feedback. If no one ever comments to save it, it'll get nudged a few times before it's automatically dismissed. It was a godsend, because it got those issues out of the triage queue and didn't return them until they were actionable again.
- dathinab 6y ago
  The problem is it had become not uncommon that any kind of stale issues get automatically closed not just such which "need feedback". I.e. you make a bug report, it get's verified but is low priority. Because of higher priority issues the maintainers do not yet work on it. The issues becomes stale and now the maintainers will never work on it unless you always prevent stall or reopen a new issue. And sometimes there are issues which can not be resolved but still are issues (e.g. (for now) unsolvable bug) IMHO such issue should stay open even if there will not be any work/improvement on them for maybe years.
  - abathur 6y ago
    Yes, this is why I'm describing a design that focuses on just what needs feedback.

tobr 6y ago

Ideally an issue is not a conversation between a “user” and a “maintainer” though, but a place for a community to coordinate around a bug or feature request. I wouldn’t open an issue unless I thought someone more than me might find the topic useful, and so I also don’t feel like I have an obligation to participate in the conversation – after all, it’s not about me, but about ways to improve the code. I find it somewhat offensive when people post to request support on something that can’t reasonably be useful to anyone else.

geerlingguy 6y ago
Sadly it seems about 90% of people don't have your mentality :( And the worse fact is, in terms of sponsorships the 10% of people who are more helpful in the issue queues and are already helping make maintainers lives easier are often the ones who consider sponsorship or other means of support. That's great, but it's disheartening that the people who feel entitled to an answer about a support question are almost 100x less likely to show any kind of support to open source projects (monetary or otherwise).
- wolco5 6y ago
  This makes total sense. 10% of your users are superfans they read / understand everything you publish. They are so into it they give support (word of mouth, helping onboard others, bug patches, they will test alpha builds and give money/time where possible). 90% of users don't understand your product as well. They haven't totally bought in. They will need more support/handholding in order to convert. People are trying to get your product to work for their situation and if they can't 90% will go away and 10% will ask (usually dumb questions). Your unhappy with the 10% who can't get it working but want your product to work enough to bother to ask? I guess you can feel that way. Those 10% do represent an opportunity to get a group of people who want to use your product to onboard. The ones who tried and failed and never asked a question will probably never come back. If you ultimately want more support you are going to need to convert this group (or invest more time in advertising hoping to get more superusers/fanboys)
cdubzzz 6y ago
> Ideally an issue is not a conversation between a “user” and a “maintainer” though, but a place for a community to coordinate around a bug or feature request. What do you mean by this? A bug report or feature request will generally come from a “user” and is likely of interest to a “maintainer”. What should the two do if not converse? Neither the maintainer nor the user really knows whether or not an issue will be “reasonably useful to anyone else” without talking about it.
- zeckalpha 6y ago
  Those personas are not mutually exclusive. Projects that divide the two don’t tend to be successful, leading to maintainer burnout, and autoclosed issues.
studius 6y ago
> it’s not about me, but about ways to improve the code This is true for me, but I also would admit that it's not all altruistic. Specifically, I will report problems that may be rare for others and unlikely to be reproducible by the maintainer. I often provide information about the operating system, version, etc. in those cases to put a reasonable amount of effort into it, but I don't always expect it to be fixed by the maintainer. However, if I determine later that the bug was caused by something else, I'll go find the bug I created and add a comment indicating that it was fixed or related to another problem, if it's simple.

rapnie 6y ago

A not-stale bot is needed here, that reacts on stale notifications. /s

abathur 6y ago

Right. In a very different context, I implemented something a lot like this for a game's bug tracker, using assignments. Ask the player to clarify something, assign the bug to feedback. If no one ever comments to save it, it'll get nudged a few times before it's automatically dismissed. It was a godsend, because it got those issues out of the triage queue and didn't return them until they were actionable again.

dathinab 6y ago
The problem is it had become not uncommon that any kind of stale issues get automatically closed not just such which "need feedback". I.e. you make a bug report, it get's verified but is low priority. Because of higher priority issues the maintainers do not yet work on it. The issues becomes stale and now the maintainers will never work on it unless you always prevent stall or reopen a new issue. And sometimes there are issues which can not be resolved but still are issues (e.g. (for now) unsolvable bug) IMHO such issue should stay open even if there will not be any work/improvement on them for maybe years.
- abathur 6y ago
  Yes, this is why I'm describing a design that focuses on just what needs feedback.