What are you talking about? The first section after “supported units” says:
The preferred way to setup the Harmony remote for your installation is via Configuration >> Integrations in the UI, click the button with
+sign and from the list of integrations select Logitech Harmony Hub .
First off I would like to apologize if I misinterpreted your comment. That is a fair concern, but historically it has never really played out like that. This is the first time that I’m aware of, and there’s a good reason for it.
Integrations are a bit of a different beast. There’s 1574 unique ones now, different code for each. It requires a lot of work and time to get an integration added initially because it goes through a (human) code review and approval process. And then it requires even more work to maintain that integration - lots of bug reports to address, some of which only occur on certain hardware or installation methods. Lots of time spent keeping up with changes to that integrations API and so forth. It’s easy to take these things for granted, but contributors often have to do lots of upkeep in order to keep integrations running smoothly for the users.
When you start adding extra burdens/requirements like maintaining two different configuration methods, it makes things a lot more complicated and time consuming than they already are. It’s adding complexity not just for the contributor but also the code reviewers I mentioned earlier. This is a bad thing, as a lot of integrations might never get off the ground in the first place. In other cases the contributor might abandon the integration due to stress / workload involved. Then users are stuck with something broken that’s not being actively maintained and not getting bug fixes.
So this solution puts all contributors on the same page, they have to support one method and not two. In theory it should be less stressful on them and reduce burnout, it will mean less bugs to fix, and should result in higher quality integrations across the board. Users will also be on the same page, they’ll have a consistent place to install integrations. And it’s easier and faster, and with no breaking changes or restarts. These benefits outweigh the minor inconveniences to power users who wish to still have 100% of their config in YAML.
I realize you’re probably still going to be upset with this change regardless of any reason for it. You had something working a certain way and wish for it to continue working that exact same way still, totally understandable. But hopefully this provides a little bit more context as to why things went in this direction. You don’t have to believe me, but I can assure you there wasn’t any ulterior motives behind this decision.
So we used to have an awesome documentation with all fields available and all. Now I can also get the example of Doorbird below, documentation is limited to a paragraph or two, no description of the list of elements to expect or anything, I guess we have to install and click to see, no way to know in advance features in advance. I mean, that ‘okay’ lot of software have limited documentation, but HA got us used to great extensive documentation for people who knew what they were doing.
" To add DoorBird to your installation, go to Configuration >> Integrations in the UI, click the button with + sign and from the list of integrations select DoorBird . After filling out UI prompts, click the gear icon to edit device settings. Enter device event names here to associate with a schedule in DoorBird app. See Schedules"
Where does it say the secrets file will be removed? 
This is only for integrations. And for the most part, you could never simply copy and paste integration config in YAML either and have it work right away, because values like your host IP, username, password, API key and tokens will ALWAYS be different from the persons config you copied it from.
If you’re going to have change most values anyway, what difference does it make if you’re typing them into a text editor and hitting save, or typing them into a web dialog and hitting save? It is pretty much the same amount of keystrokes/clicks.
So how exactly is it harder? In above example you can click a checkbox rather than typing out a full word “true” (easier and faster), and you can use the integration right away after hitting “Submit” button rather than waiting for a Home Assistant restart (again, easier and faster).
This is a good example thank you. How do I secure secret storage with the GUI? In the past I had control what went to secrets.yaml, and I could make sure it’s not part of my backups on Git.
Anyway, if you like to document your change management via screenshots, this is fine. But I used to be able to version my config via Git the right way: as any Infra of Code, I could commit the changes, and auto restart my podman container via a gitlab runner. All easy peasy, using best practices of IT. If a week later I notice a regression, I can easily see the history of changes.
About sharing online, I Google often pieces of config, which is not working that well with screenshots unless Google starts doing OCR.
It’s good to have choice, like Windows vs Linux. My point is that HA is now simply targeting the same user base as all Google Assistant, Mi Home, etc. I’m glad those platforms exists for non-ITers, but even Microservice started to recognize the limitations of GUI-only applications, and improve its command line again for power users.
If the config is not in yaml you can’t use the secrets file. When you put the .storage folder in git as they suggest all your passwords will be in plaintext in your git repository.
So put the auth files in gitignore…
What are you talking about? There are no separate auth files, configuration and authorization are in the same file.
But that only applies to integrations that are UI-exclusive. In some cases yaml-configs will remain available (at least for a while), and there the secrets-file should stay available. 
What#s the point in googeling how to configure an integration? It will only have so many options that will be documented if necessary. There’s just no reason to google that. Your point only applies to things that can come in different flavours, like scripts and automations. Which, as stated quite a few times now, will remain in yaml.
For now. If both YAML and UI were supported I would have no problem at all with this, but YAML configuration of integrations is actively discouraged, will receive no updates and already several integrations have dropped it.
Great! Finally a GUI, so clear that people will never need to Google to find more information 
can’t wait to see it!
Alright then, I guess all I am missing then is to configure HA from my Ansible script using Selenium 
I just managed to configure fully my home server from Ansible scripts hosted on Git and applied from Gitlab Runner. No, more seriously, I will check what can be configured from the REST API, then I could still configure HA using a clean CI/CD pipeline by writing a few Ansible Roles.
And how is someone supposed to commit code to address the issues if it has been stated in advance that such code will not be accepted?
“We will no longer accept any changes to the YAML configuration for existing integrations that communicate with devices and/or services.”
My main objection with this announcement is the refusal to let people address their needs for YAML through pull requests. Any of the following options would be OK:
So what is the issue with refusing contributions for YAML configs? It seems like removing that bit from the ADR would address people’s concerns while still setting the priority to focus on the subset of users who prefer GUI.
Thanks for your view @templewood. 
Maybe it is an idea to listen to the latest Home Assistant Podcast where Paulus explains it a bit more.
Other than that, I think my previous comments cover a response on your matter.
…/Frenck
Why not keep YAML for the select few
That was answered in the first post.
That should not be the case. Imagine all the non geeks which only option would be to use a cloud based solution?
Home assistant should focus on providing an home automation alternative for those who care about privacy and control.
Hi @frenck . Unfortunately they don’t, even after wasting an hour finding and listening to the entire podcast in the hopes of finding an answer. I can’t find any justification as to why the project would refuse functional commits of code that address a need that an overwhelming number of people in the community have expressed. It seems blatantly incompatible with the claim that this is a community or volunteer project. Since I’m getting the feeling at this point that I (we) are being jerked around, I am going to be direct:
What is the technical reason that Nabu Casa and the Home Assistant project cannot move forward with volunteer commitments of YAML code for sensors?
Community depends on dialog and dialog is two parties having a conversation. The moment people start saying “This is our decision for us, and we’re going to enforce it for you too. Discussion over,” it stops being a community and becomes something else. Is it so wrong to let people continue to collaborate?
The problem with that approach is that it’s very similar to what we have today, super messy. YAML users would understandably complain when an integration dropped YAML config (see top reddit comment on 0.108 release notes for example).
But under your proposal you’re allowing an endless cycle where an integration gets rewritten and drops YAML, someone else re-adds YAML support, then another person drops it again, etc. Instead of being frustrated just one time you’re allowing them to be frustrated over and over again. That’s a large waste of time for everyone involved IMO, from the contributors and code reviewers and also the users who have to constantly update their configs.
Your proposal still wouldn’t satisfy the vast majority of complaints in this thread. Most of the people complaining passionately about this want to have their setup 100% YAML, your proposal doesn’t really solve that. Those complaining about certain integrations being UI-only would still be complaining. It doesn’t solve the concerns some have that YAML is “going away” because now you would just be feeding into that even more by hiding YAML integrations or referring to them as “unofficial.” Etc etc.
IMO it’s better to just rip off the bandaid now and set clear expected guidelines on this stuff in order to keep a sane user experience.
