If how the Supervisor releases and updates are handled in a way you find could be improved, could you please make a separate topic for this?
I’m saying this because this feature request seems to be in the works (thank you devs.) and the issues you raise in context, might end up in the tail of this thread as rather noise than legitimate concerns.
This is by no means an approval or dismissal of your concerns, rather a way for it to be addressed properly.
Thank you, I think you’re correct that this discussion needs to move elsewhere.
But before we do (and while we’re in the unnoticed tail end of this thread anyway) I wonder about exactly what the big issue is. How would we phrase it?
It’s hard to put into words. When a project, or business, or department of a larger corporation reach a certain point, they can develop an “Us vs. Them” attitude. I used the example of restaurant servers who become (probably justifiably) cynical to the point where they feel the customers are the enemy.
But it happens in other environments, too. A group of employees in one department feel that no-one else in the corporation listens to them, even though they’re the experts in whatever they’re doing. Or a group of developers on a project start to resent and dismiss user complaints, and plow ahead just doing things their own way with no input from those actually using the product.
I’m not blaming anyone. This is a natural evolution. I’ve developed products for my own use which grew to be widely used. It’s hard to transition from “this is the way I do it” to caring about all the different use cases and preferences of a larger audience. It’s hard to show genuine respect for users’ opinions when so many of them are nowhere near as involved or interested in the project as the dev. It’s very easy to dismiss “all those morons” who see things a bit differently, or use the product a bit differently than the dev intended.
Fully agree. This issue here is really the symptom of a larger fundamental problem. But I don’t see this as an inevitability. As users, it’s just as important to voice our opinion than it is for devs to listen to them. As a developer, I’m kinda on both sides of the fence. I understand the devs to some extend. Sometimes user feedback can be overwhelming, sometimes downright stupid and you get this feeling that the users just don’t get it. But then you need to ask yourself, why am I developing this ? Is it purely for my own personal use or is it for a wider audience ? If it’s the latter, you have to accept that people will do things differently and have different priorities. And more often than not, their way of doing things can just be as valid as yours.
A good counter example is Mozilla. At some point they just stopped listening to their users, even going full on hostile on them when their new highly disputed features and changes in Firefox upset a lot of people. They plowed ahead. The result - from having the second largest marketshare of all browsers in 2010, and well on their way to the top spot, they joined the ‘irrelevant other’ bin only 7 to 8 years later. I hope that won’t happen to HA.
@MDSDM, sorry we should probably focus on the specific password issue here. I just had to get that off my chest, because I really like HA and would hate to see it go down that slippery slope.
I wish I had a great answer. HA is mostly developed in the good spirit of volunteers. So the normal “backlog/groom/solve/qa”-thingy is in the hands of various people that each on their own have their free time, opinion and will to engage. I wish I knew who the receiver would be as I would gladly adapt to him/her. So I can only guess…
Maybe a user story?
I think a user story would maybe a way to go. “As a user, I appreciate mostly the aspect of HA as a platform where I can have my own data in control” and “if future releases contain aspects where I loose control, I would like to be clearly notified…yada yada… optional… yada yada”.
Maybe a proposed solution?
Some devs, prefer to get a solution. So it could be: “In the release notes, if data control is somehow changed, please inform…”
Write some code
I frankly don’t have the time to sit and write code for HA. Since others do, I have to respect those who contribute with their time.
I agree. I also think it’s a remarkable project.
Reminds me of Agile (…so tired of that word…), as we all must also keep a thick skin and accept that development isn’t a straight line, rather a bumpy road with trial and error. Bond between users and devs is probably most important in the long run.
I’m not so sure that’s 100% correct. I’ve seen devs complain that there are a lot of hoops to jump through, a lot of boxes to tick, before getting a change moved to production here.
Obviously I can’t speak first hand, but I know there have been some things I was anxious to use held up due to what the dev felt were roadblocks in the process.
Yet some steps which seem to me like they should be critical are routinely skipped. Such as making sure existing documentation is updated to reflect the change. And this fiasco shows how little community input is required, and how easy it is for someone experienced with the procedure to bury a significant change so it’s largely unknown until it’s too late.
Yet some steps which seem to me like they should be critical are routinely skipped. Such as making sure existing documentation is updated to reflect the change. And this fiasco shows how little community input is required, and how easy it is for someone experienced with the procedure to bury a significant change so it’s largely unknown until it’s too late.
Since I’m not part of the dev team, I don’t really know how their release process or backlog is managed. I think what can be done is to describe it from a user perspective. i.e “Please keep us user updated with what is happening to our data and even better, try to keep us responsible for it and not the devs”.
I used to develop using several methods and frameworks of decelopment. From real waterfall to Scrum recently. With this expexience I can say it’s not about process nor how it is set up. It’s about people and they will to communicate. If it’s lacking then no process nor mission nor other rule can change that.
Well true… no communication and it doesn’t matter what method is used…
I just feel, as I’m not part of this dev team, I should be somewhat humble to their situation and don’t give them solutions. Some people here where raging when this happened, meanwhile the dev was home with a sick kid. I totally 110% agree with his prioritisation.
However as my role as a user, I can share them what I would like to experience. If others agree with it, they might come up with a solution. (Like how this feature request came up).
Communication of things like this (i.e. almost none) has always been the Achilles heel of HA.
I was told by a moderator after the last round of “backlash” to a poorly thought out and communicated decision that with them being a newly appointed moderator they hoped that they could guide the devs toward a better communication model and potentially try to give them a better view from a users perspective.
Not to take anything away from that moderator (since I am obviously not privy to backroom discussions over this kind of thing and they could have put up a valiant argument for better communications) but it doesn’t “feel” like they have had much success.
in evidence, how many devs have come to any of these discussions trying to either justify their decisions or seek clarifications on the thoughts and suggestions of the users to allay/rectify their concerns?
To make it worse is that “circle the wagons” mentality that kicks in and the subsequent doubling down immediately as soon as there are rumblings of discontent with some change that was implemented.
There is almost never any “mera culpa” offered (one time ever that I can recall). Most of the time it’s “you don’t write code and aren’t a dev so you have NO RIGHT to voice your (negative) opinion on anything at all”. Even if it’s well intentioned and accompanied by any number of suggestions on how the situation can be resolved.
As followup to your remarks, see other simiar threads just have been closed.
A moderator published a command to disable security checks without chance to ask further questions:
is it new command or was here always?
because option name is not distinct, does it disable snything else?
will this switch appear in gui or stay hidden option for all newcomers
is that feature covered by documentation?
is it permament or will switch to default (on) on each system restart?
why that information is being shared by moderator and not developer?
After all this noise about pwned and the option to disable it, I’m curious what the “Join beta channel” option in the supervisor does, because these changes seem to be getting pushed straight to production very quickly without any beta testing or user feedback. User feedback on changes that have already been pushed through falls on deaf ears, unless there’s a larger outcry like in this case.
This isn’t unique to just Supervisor, but also Core, Frontend etc.
Join beta channel lets you use beta’s of everything you listed. Not enough people do it because it can sometime lead to unstable environments. But that’s the point of beta. You use beta and report your issues. There’s usually 2 weeks where you can use the beta before it gets built into release.
Where are beta issues (that are not actual bugs) reported? If a beta tester had flagged the pwned issue during beta, would it honestly have made any difference?
They were two honest questions though. I wanted to know where are non-bug beta issues brought up, and to ask if feedback is taken into consideration (and confirm that for myself)
Sadly, that response sort of confirms the “us vs. them” mentality that was touched on above. You’re assuming I’m hostile/trying to argue with you. Aren’t we trying to fix the current state of things?
I’m a mod, I’m not with them or with the community. I make sure everyone plays nice together.
And as always, GitHub issues are were these items are brought to light. The guide when reporting an issue has you fill out what version of HA you’re using.
Try the HA Beta discord however I don’t remember anyone mentioning this ‘problem’ in beta. I guess beta testers either already had good non-pwnd passwords or they updated their passwords - which is what everyone should do and then there is no ‘problem’
Thanks, was hoping it’d be a forum, but I guess times are changing I’ll hop over to the beta channel and join the discord. Maybe this could be made more visible somewhere, like a link in the supervisor when you join the beta channel, perhaps that would lower the threshold for others to join beta as well?
Not touching that one with a 10 foot pole I think everything’s already been said about that.
Theoretically though, if someone had brought it up, would the implementation of it been reconsidered or still pushed through? (less nag, ability to disable specific addon etc. or a command to disable completely as we have now)
I’ll hop over to the beta channel and join the discord. Maybe this could be made more visible somewhere, like a link in the supervisor when you join the beta channel, perhaps that would lower the threshold for others to join beta as well?
I think everything’s already been said about that.