I’ve seen lots of GitHub issues where users have taken lots of time to report things get auto closed to no activity bot without any core team members acknowledgement. Would be great to have more visibility / community feedback on prioritizing / etc…
Home Assistant updates quite regularly, on a monthly schedule. Often issues are fixed by changes made in the updates but not reported as fixed by the person who opened the issue.
If the issue is not fixed they are expected to keep the issue from going stale and being auto closed.
It is the only way the team can keep up wit the enormous number of issues reported.
Is it a great method of issue triage?
Not really, but unless you can come up with a better plan it is the best we have.
2 Likes
it has to be marked as resolved by developers, not by reporters.
Incorrect. It can be closed by the person who opened the issue or by one of the dev team, and they prefer to get feedback before doing so (unless they can run the test on their own development system).
1 Like
never saw such an approach (except HA)
The reporter may be in duty to confirm the issue is fixed only if issue got potential fix.
What happens here is, reporter is being asked multiple times if it’s accidentally fixed even if issue hasn’t been touched at all. It’s not only pure wrong. It causes a lot of issues being slipped unfixed. If it makes devs or project owners sleep better then ok - goal achieved
4 Likes
All of GitHub is like this… and that’s not an exaggeration. The last 2 companies I worked for also did this.
The only difference with HA is that it requires the user to be proactive with their reports. It takes 2 minutes to simply reply: “still an issue” when you are notified. You can even reply to the email notification, saving more time.
1 Like
yes, I do. It’s not productive at all.
How many times have to confirm it’s not fixed? infinity of times?
Maybe the whole issue is matter of github settings. Stalling issues after a 4 weeks and then closing after another week is too short period to even pick it up by devs(considering ‘enormous number of issues’).
A week deadline is completely ridiculous. It might be missed when in vacations etc. Also single miss causes lost of the issue which potentially might be important to the system.
Why there is no responsible role to analyze all stalled tasks, tag them, link duplicates prioritize. Just making sure it won’t be forgotten? Just idea.
1 Like
Until someone has an interest in fixing it and actually does.
Or until it is marked WONT FIX, which thankfully happens very rarely for Home Assistant.
Edit: oh look, you don’t have to do it any more:
just because I posted it here 
Actually it supports the OP. Tasks are marked stalled/closed to quickly.
Before the bot was in place we did this by hand and no one was the wiser and no one complained. We would call an “all hands on deck” once a month, go through and reply on isseus with “Is this still a problem”. If anyone replied, we’d keep the issue open. If no one replied within a few days, we’d close it. It was like this for 4 years, zero complaints. This took everyone an entire day to clean up the issues.
All we did is create a bot that does the same thing to remove a days worth of workload out of volunteer developer hands.
All that we ask is for 2 minutes of any users time to keep an issue relevant. It’s not much to ask and it helps keep relevant issues relevant regardless if you believe that or not. It works. You’d realize that if you were the code owner of an integration.
2 Likes
I also have to ask, why didn’t you just fix that documentation yourself? It’s not even code, it’s just a link. You spent more time keeping that issue alive than you did to just change the link…
1 Like
because I didn’t know the answer. I didn’t know how this diagram looked like. And I don’t think so, removing it is optimal solution. I hoped some one who maintains the integration has better knowledge to replace wrong link with valid diagram
it’s nothing wrong in asking. I suppose however that current policy is too tight. confirming every 4 weeks is too often especially if some ussues take year to be picked up.
Also one week to cancel is very short time to react.
If you ask me for alternative, a maintainer (or dedicated role) should pick up issues and immediately map them them properly. Then there would be no reason to ask reporter. Granted with no resources to process issues it will create a queue. but eventually fixed things will close related issues.
Another approach is to push stalled issues for evaluation to developers . They know the best if the request is still valid or not. Also if something is not moving it means it might be forgotten thus deserves attention.
the easiest way is to move responsibility to unqualified persons (users) and wash the hands. But it doesn’t work well neither for software quality nor for users satisfaction.
Problem is, I’ve commented on some issues still an issue for months/years, some have a dev reply to others don’t. But you’d expect at least some kind of triage or way or response. There’s even open 1 line pr I know about without any comment or review still waiting to be reviewed / merged.
personally, I find this strategy of marking stale and subsequent auto close (way too fast indeed) most frustrating on Frontend especially.
eg a hold action shows the iPhone Share, Add to photos, Copy pop up. · Issue #9549 · home-assistant/frontend · GitHub not a single dev response, and we have to keep it open, even though a dev from another repo has provided the road to solution
Seems those repos are Chinese-walled now and then, which is not good for the greater project
You’re assuming all issues are actually issues. Many issues are user error, network problems, endpoint problems, or support requests. All of which do not belong as an issue and don’t need developer time. Often these issues are reported, the user finds and fixes the issue on their end, and the issue is never closed. A substantial amount of issues fall into this category. The bot is in place to manage this while keeping real issues up front to the developer.
This already happens. Code owners are notified immediately when an issue is present for their integration. They also get all notifications when anyone replies on the issue.
This actually works very well for this system. It keeps high priority, relevant issues in the eyes of the developer. The example you posted is definitely a low priority issue that anyone can fix, you just have to wait for someone to ‘want to fix it’. Remember, HA relies on volunteers. You can’t force anyone to fix issues.
Yes, code owners do that with their integrations. The core team works on the HA core. If they aren’t listed as owners, you’re waiting on the owner to respond. If they don’t log in for 6 months, then you’re waiting 6 months for them to fix it. Having the core team swoop in isn’t going to help anyone, especially if they aren’t familiar with the integration or the code behind the integration. That could lead to more issues and more breakages.
1 Like
Everyone needs to keep in mind that there is less than 50 active developers at a time and over 165K people adding issues each day. Sorry, the system isn’t perfect but it works for a project this large.
I am with the OP here.
There are too many real bugs that never get fixed and never even get triaged. I wish one release per year was a dedicated bug fixes only release where no new features are allowed and the devs focus on getting the backlog eliminated. Either by fixing or by
I have the impression that you have less than a week to react to the stale bot. I have received messages in the email while I was on a weekend trip and a few days later it was too late, the item was closed. I could not even reopen the report. The bot is setup way too aggresive with too little time to react.
2 Likes
I do think we need to do that once a year. It’s not a bad idea.
Nope, much longer than that, here’s a 22 day old issue I created. My last activity was 22 days ago. Frencks (code owner) last activity was 18 days ago.
1 Like
It is not the period from last activity till stale bot warning that is the issue
it is the time you have from you receive the warning from the bot, till you react. I have the impression it is more hours than days you have to react.
Kenneth