Understood it’s a pickle and there’s nothing owed to even the popular vote, but has this at least been discussed or is there an ultimate solution that lies in the years ahead?
They have far more in common than in differences. The original post identified the difference as “not for requesting new integrations”.
“I really want this new integration to be implemented, so I can use my devices. Is this the right place for it?”
No, this event is not for requesting new device or services integrations. Please use the “Feature Requests” forum category instead.
The key question remains, what attracted developers to address so many WTH issues in such a short time when, in comparison, Feature Requests collect dust?
My theory is that its success was due to officially promoting it as a place where one could vent one’s peeves for a limited time. In a way, https://www.reddit.com/r/TrueOffMyChest/ for Home Assistant.
This is in contrast to Feature Requests which gets no promotion (certainly nothing like what WTH did), is not framed as a place to complain, and its availability has no time limit.
Perhaps Feature Requests could benefit from some heightened marketing. Maybe a biannual, or even quarterly, promotion that calls developers to ‘cull the herd’ in Feature Requests. Whatever the ‘bump’ in fulfilled requests, would be worth the small promotional effort.
1 Like
There is a big difference in focus. Furthermore, it allowed for annoyances/bugs, which are in general not really feature requests. Lastly recent content, things that matter now, as top of mind stuff from everybody. The contents of the WTH category is really hardly comparable to the feature requests category. Sure, some overlap is there, nobody denies that.
As for developer focus, it is an open source project, it relies on people willing to contribute. Sure, doing a month like this motivates the whole community, which is part of the goal. Similar to what Hacktoberfest does as well.
The same promotion directed at Feature Requests could spur a similar uptick in contributions.
As for WTH vs Feature Requests, I recognized several gripes in WTH that were already long-standing Feature Requests (need to restart for changes, Automation Editor deficiencies, stunted expand in Template Sensors, etc). Nevertheless, they sat there unaddressed for ages whereas their WTH equivalents were resolved ASAP. That’s impressive and the ‘magic’ responsible for this is valuable. All I’m suggesting is to consider using some of the same magic to help whittle down Feature Requests.
1 Like
Well, I do agree, but that doesn’t work like that. These are boost we can do limited times and not constantly, as it loose its effect.
True, a promotion loses its impact if it occurs too frequently. All I’m suggesting is that it be tried at least once for Feature Requests. For example, next Valentine’s Day as a ‘Show your Love’ for Home Assistant … by fulfilling a Feature Request. Or something along those lines.
2 Likes
Yes please!
Another difference between the “Month of WTH” and “Feature Requests” section is that often the WTH posts focused on core parts of the way HA looks, works, and feels which all developers can work on (given the skill), and the Feature Requests often require the developer own a specific piece of hardware, account on a cloud service, live in a specific country, or other requirements that raise the bar for being able to work on them.
Also that WTH posts often focused on things that everyone can benefit from, where as feature requests would only benefit those who wanted to use that specific component.
I’m not saying that it’s any less of a reason to work on them, just thinking of reasons they often get less traction and receive less developer love.
3 Likes
Yes please!
I would say don’t combine it with Hacktoberfest. Maybe it would be good to have it offset from hacktoberfest by 6 months?
Those state triggers on reboot cause automations to occur in my case. They need to change the way they handle initialization of previous states versus setting a new state at boot time. Currently at boot time all states appear to be discovered and set and events triggered, instead of discovered, compared to previous, and then set and events triggeredif required.