As i Said @maxym i doubt there is way that is acceptable for all and that’s the point.
i had no problem with it, so did most but some found it unacceptable
Reading all the breaking changes is not feasible in such a release like this.
If they would be filtered in such a way that what is applicable to you is at the top then I believe everyone would take the time to read what is needed.
The analytics is in a way all that is needed from our HA instances.
If that data is feed to a “personal breaking change” page then it would make reading breaking changes a lot easier.
What’s the problem? Go through the list, open the ones you use, read.
There are 79 line of ~3 words in average in that list. Assume average reading speed of 200 wpm, that’ll take you about 1 minute…
Should differs from have to.
Not only because there is no checkbox “I have read and accept blah blah”. But it’s because those are two separate activities. Because quality/form of release notes (how, where, when) - which directly impacts readers awareness - have no QA.
Last but not least, a lot of recent changes in HA leans this project toward less experienced users. You cannot require more and more technical-based attention from such a user.
The developer/owner responsibility is to maintain software as transparently as possible. And if any breaking changes has to be made, developers/owner’s responsibility is to communicate it correctly.
If community signalizes that something went wrong, then something went wrong which the fact goes after the message creator.
Of course reading release notes is good practice. But it’s a domain of more experienced users (the skill of reading release notes is important though).
BTW speaking of community: In community driven project community should be treated with more respect. I mean, informing in cold way that something is going to be shut down isn’t probably optimal approach. I guess that pulling interested users into discussion first, offering alternatives, explaining that those alternatives might cover 100% of their original needs would work better than just putting the message into release notes just to be justified.
1 Like
Respect is a 2 way street. You’re going to get a lack of respect when you start a thread the way that OP did and act like OP has, as it shows no mutual respect.
Also keep in mind that there is 100k+ users and only, what ~2500 volunteer devs and 9 of the 12 nabucasa people are devs. It’s very easy for users to gang up and crap on devs. Lets take OpenZwave 1.4 and OpenZwave (Beta) for example.
Zwave 1.4 is a very old system, the guy who developed it over 10 years made a new version around 2019-2020, which is what we know as OpenZwave (Beta). He decided to make that specifically for HA. It took this community and it’s users 6 months to kill his motivation on his 10 year project. He quit, didn’t tell anyone and we ended up with the huge push to move to zwave_js last year. All because this community ganged up on him about his decisions and prioritization of bug fixes. Do you think this is acceptable? Is that really acting like a community?
3 Likes
Don’t know details of the situation you are describing. But I would say it’s common in internet based societies and online multi-language, multi-cultural communication. Real life appearance equalizes our behaviors (to some extent). Online is the opposite.
Nobody should be surprised about that. One can live with it others cannot. But it is not reason to blame a community. It is how it is.
Yes, it is common. But that’s why you have many people who will defend the decisions. Because we’ve been in their shoes. Just look at this GPIO thing, how many people in this thread, including OP, do not understand this deprecation? A lot. They think all GPIO is being deprecated, when it’s only the integrations that are being deprecated. And these people are extremely vocal and pissed off, spreading lies without understanding what the deprecation means. From my standpoint, these people aren’t trying to understand, they just want to cause turmoil.
I find it (not) funny that you think users you should be treated with extreme deference but that open-source devs working for free should “live with it”.
Hint: They don’t. They move on, like the devs of those GPIO related integrations did.
1 Like
This is why I said release notes are not enough and are not an excuse.
And this is why I said that if anyone fails here is a messenger, who is always responsible in case the message is not understood correctly. It’s a common rule.
What happened to fishwaldo was brutal and unacceptable
It might sound rough, but yes: devs decided on their own to be open source developers, providing a software consumed by internet communities. With all consequences related to that decision.
1 Like
I understand that, but it clearly states GPIO integrations and lists them out. There’s only so much you can say to get the point across, and even then people will still not understand.
And dev’s have the choice to walk away, which is what happened with GPIO. That doesn’t mean someone will pick it up.
Then surely the enduser consuming the software should be also accepting of the developer decisions and how they communicate it to the community. It works both ways remember
Hint 2: Open-source devs generally don’t care about “community”. They had a problem to solve, they solved it and shared the result. Some are kind enough to “support” the code and those using it, but at the end of the day, when the code they created is not useful to them, they abandon it.
Hint 3: The more demanding those users are, the more likely they are to go dark.
Yep, I have a harmony integration I built that helps marry devices to activities. It’s in my repo and anyone can use it. But I purposely don’t add directions and I haven’t put it in HACS because it would spiral out of control with support issues. The configuration is overly complicated, but it does what I want it to do. Some guy forked it a month ago and I was super worried for a minute but I haven’t heard a peep.
2 Likes
Agree he can. It would work as expected if the component wouldn’t be included into core.
Once it is, it changes perspective. It gives impression to users the core component is maintained by HA core team which takes responsibility for making this feature operating.
I’m sure I mentioned that already (in other words obviously). HA team has interests to include as many integrations as possible into HA, to increase Home Assistant functionality/value. Since this, those components shouldn’t be treated just like separate ones maintained or not by 3rd party. Hence mentioned responsibility.
Otherwise, exclude all components to HACS, let random developers work on this. Let HA core devs work on the core alone. Yes, at some point it will cost more works (like back- and future-compatible changes, longer period of dimm-out of old apis etc). At the same time there will be less responsibility for components. The owner has to balance pros and cons. Likely did that already. But seems some of us forget about responsibility and consequences of those decisions (I write “some” because my judgment is based on comments of forum members rather than on an interview with decision makers).
Most do, some make a noise. Some have valid reasons for that, others exaggerating.
But if one ask me what is the solution I would reply: live with it and if you can improve communication if possible (a messenger), because you cannot change the reality. Simply do the best on giving as fewer reasons to dissatisfaction to a mob as possible.
2 Likes
Hehe, I have one that mimic harmony activities with some kind of state machine, for when my Harmony will eventually die.
1 Like
I just read through a perfect example of this over on the Release Notes thread. Now I understand the frustration of the mods and devs, and why they’re so abrupt and dismissive of anyone who asks a question they think has already been answered. I have a new-found respect for their patience.
In future if I feel personally attacked, I’ll assume it was because they misunderstood what I was trying to convey, and perceived it as just another uninformed rant.
Here’s a good example of how we’re talking at cross-purposes, not hearing each other out.
Four months is plenty of notice. That wasn’t the point being made. The point was, perhaps the group of people who were knew about this before that posting in the Release Notes wasn’t large enough to generate the discussions which led to someone ultimately taking over the integration.
Apparently that person knew, and was hoping someone else would step up. I’d do exactly the same thing.
The problem is, nobody who just reads the release notes knew any of this. They saw the deprecation and abandonment as an immutable, final decision. When you hit thousands of users with a notice that the function they depend on will no longer work, even if it’s four months away, you have to expect that decision to be questioned.
If anyone reads this far before firing off an angry retort, what I’ve been trying to say is that it could have been broadcast in the Release Notes (or anywhere else users will see) that developer support was needed to help avoid losing the integration. I think most of the community would respond positively to a request for help, to keep something they use alive. The negative response was because of how it was presented, not when.
3 Likes
I want to be clear here: The problem isn’t being frustrated with the change. The problem is being an immovable object when it comes to a solution to the change. The same people who are frustrated are unwilling to adapt… at all. That’s how these arguments start, every time.