Does anyone share my sense of irony about the removal of the GUI for customisations? When HA moved to GUI for configuration there was outcry for the loss of yaml. Yet when one small element is removed from GUI so that people must use yaml people don’t know what to do and/or think some functionality has been removed.
plus ca change, plus le meme chose.
Are those the same persons complaining?
IMO there are two groups of users, each one was/is complaining about different change.
IMO there is a lack of clear strategy communicated transparently enough (prior to changes). Sharing the information after development, in fact on day of rollout if far too late.
If it hits bigger group of users it has a chance to be refined afterwards. Otherwise devs has a luck to be not pushed for further changes.
Btw users (incl me) learn to not get a voice about some changes. Mostly it’s waste of energy since it brings no outcome except being categorized to moaners. At the end we most times can accustom to changes whatever they are. Not sure it is good for such a project or not though
Hear, hear!
This is 100% the issue with the recent UI changes. Its not about whether its a ‘good’ change ot not. Frankly that doesn’t matter. It was a very VERY impactful user facing change. In my previous life as a Support manager for a global software publisher, that would have MANDATED a study on the effects and a UAT before deployment to the production branch. It would have also mandatory to make the change an opt-in by the user. So no checkbox, old behavior, checbox that user MUST click on thier own… New behavior. Pain from a dev perspective but a very simple method to allow users to adopt new changes.
It would have been an easy mitigation too… Had they published intent to change UI in the blog for the 12.x release and held it until the 2022.2.x release, people would have had two whole months to comment and flesh out issues (like cant access companion app settings when a non admin user, or a critical use case that got hammered by the removal of an entry point.)
But mentioning that, ‘hey I might want to change some things this month’ on a Git thread and then just doing it by the end of month (yes I read ths entire thread, thats basically what it amounts to, change intent in first week of November and change added to the December release. Less thab one month.) Not very good organizational change management…
I hope lessons were learned from this and it won’t happen again. Change can be managed, but you have to at least try. I hope they do better.
You must be new here 
This is an open source project, don’t expect money oriented business decisions. There’s a group of ~50 developers that handle all this work and they manage it based on discussions in GitHub. If you don’t partake in the discussion, things like this can (and will) happen. If you do plan to partake, please just maintain an “This is a discussion” attitude.
Hmm… 
Well, I’m not new. We might not “expect money oriented business decisions”, but I do pay Nabu Casa every month, and had been thinking about upping that contribution (because I can), as well as supporting several favorite developers directly.
However, if this is the attitude being taken by the development team at large… then maybe I’ll wait and see, do a little “partaking”, or maybe just lurk a bit in the discussions.
BTW, where, exactly, are these discussions taking place? Links please.
I have no idea what you are talking about…I’ve never ever seen that happen to anyone…(where’s that sarcasm emoji again…?) 
OK, ignore me. Carry on… 
You’re reading way to much into that comment. All the discussions on code changes happen where the code changes occur, on GitHub. Everything else (forums, Reddit, Facebook, discord) is just a place for people to talk about HA.
I don’t have a link handy, currently on mobile. But each repo on home assistants GitHub page has a discussions tab.
That is the place for frontend discussions and feature requests that petro referred to: Discussions · home-assistant/frontend · GitHub
Thanks for that.
just noticed we had all these android requests in there that we missed since I dont check that discussion thread often 
tried to reply to as much as I could to fulfill them and/or ask they be placed in the appropriate location
Maybe it would help if the pace at which updates are released were slowed down a bit. Once a month is extraordinarily fast. I gather that the next will not be until February, and I for one am looking forward to the peace and quiet.
I think the pacing is necessary (at least for the minor versions) to keep up with all the changes in the eco system (meaning changes in HA connected devices/services and their APIs that HA has no control over). Some people would even go the other direction (asking for even more frequent releases) as they are used to the HACS speed where individual custom components can release updates without having to wait for HA itself.
And in the end, people can choose to e.g. skip every 2nd version or even stay on a fixed version, if everything they need works and is stable & secure there. If however you are waiting for a certain feature, it is nice knowing it is usually only a few weeks away (once it has been implemented of course that is).
Plus from a dev perspective the relatively short periods are nice, since it motivates to see your changes being in an official release rather than e.g. having to wait a quarter to see the fruits of ones labor.
The pace has already been reduced… it was bi-weekly at one point (maybe even weekly I don’t remember) but they moved to once a month for exactly the reasons you are mentioning and have done an amazing job of making sure each release is stable before releasing.
And unfortunately if it was reduced further there would be a thread of people complaining that they have to wait 2 months for their new bulb/device to be supported.
I have been using HA for 4 years and my personal opinion is that for free software that is done by 99% people with absolutely zero monetary compensation… I have absolutely no right to complain about anything…
I agree, the pace seems right atm. I don’t know if there is a medium where major design changes can be announced before work commences, or if those interested in providing input are required to check github often to see what’s going on, but I would think floating ideas that are significant or that might cause some backlash could be helpful. Kind of like public comment on an EIS, though I suspect not all such discussions take place on github (but I’m fairly new to github so idk).
I think a large part of the issue is to filter the noise and to determine bias (statistically, in whatever direction): It can be hard to know whether a particular issue at hand is actually supported at large. The Internet has learnt us that a small group can often have a big impact. In some cases it’s useful (say a societal or social issue) and in others not (which feature to build next). My point is: Even if you get people to vote, upfront discuss changes, or whatever, you may still end up with only half a view.