And we wonder why the devs dont interact here and they stick to discord where they can interact with other devs. its just to toxic towards them here
2 Likes
I’m not sure I agree it’s toxic, but it can get a little out of hand, from both sides sometimes.
Which came first though, the chicken or the egg? I ask because I don’t think people naturally become aggressive about something unless it’s something repetitive happening that really starts getting to them.
2 Likes
If you feel that way, what can be done to correct it? Do you have a solution?
Here’s mine. Document every change and update the documents accordingly. Then if a user chooses not to read the docs, it’s on them not the Devs.
1 Like
This is already done. Go check out github for the change set. That’s all I did.
I offered the solution to add every Supervisor PR to the blog post list and you shot that down (even though we do that for core). 
I most certainly didn’t shoot it down.
I’ll retract this comment now, and agree with you that it would be a good idea “to add every Supervisor PR to the blog post list”.
Honestly, I’m not trying to fight you here, I’m only trying to point out that there can be a better way to do things. I might appear as though I’m just being an a$$hole and complaining for the sake of complaining - I’m not, although I am an a$$hole 
Can we just agree that things can be done better and try to make that happen?
I have a very limited skill set as far as being able to contribute to this project, but what I can help with, I have offered help with. I look forward to my offer being taken up.
6 Likes
And that is exactly the same on the other side too.
it’s the same group of people not getting it that communicating changes before they happen with the acceptance of feedback (good or bad) is important to alleviate issues like this. Over and over and over and over and over.
Oh, ok then they are just taking their ball and going home because they don’t like it that people are trying to communicate that they need to do some things better - like communicate? (ironic isn’t it…?)
Once they retreat to their “safe space” where they don’t have to listen to any criticism then the game is over.
For the most part it’s the devs reactions to users asking questions or posting a concern that starts things going downhill. I can’t count the number of times I’ve seen on here the “you have no right to complain if you don’t write code” response to a “why would you do this?” or “can this be changed?” question.
2 Likes
Well when they do pick up their ball and leave, we all lose out. the attitude toward them from certain people is toxic to the point its beyond critism
1 Like
No its not. Look at this month. The month of what the heck. It’s to find out what people actually want. Notice where the votes are? They are trying, you give them no credit and constantly complain. Where’s the incentive to help you out?
2 Likes
I’m not saying that there hasn’t been some progress being made. The change in title of this thread is (finally…) an example of that. And I was right there saying thank you and trying to show my appreciation that they (finally…) listened to feedback. But unfortunately things like the change in heart on this topic and the “WTH” section are fairly few and far between. AS evidenced by the reaction to the latest round of questions and concerns about the unannounced and uncommunicated big red warnings in peoples installs along with the lack of “official documentation” on how to fix things.
But the “poor little devs don’t get any respect” trope is draining too.
So do you mean me personally or the generic “you”?
1 Like
me personally i would say you
FFS, they forgot to mention one thing. You don’t make mistakes? If I had a partner that would flip out on every mistake I made, I’d leave.
I’m sorry to hear that. Got any proof?
I may be more outspoken about issues but for the most part my “complaining” is in response to BS responses to simply saying WTH? Which seems to be OK as long as it’s an officially sanctioned “WTH?” otherwise you’re just a complainer. 
EDIT to add:
It’s not like it’s just me, either. You need to look back thru the posts here and see how many likes I get on my posts. I may be the one saying things but other people feel the sam,e way apparently. They just don’t want to say it because they don’t want to deal with derogatory comments and being called a “complainer”.
It’s not a mistake. It’s a trend.
If I kept “making mistakes” over and over again with only minimal attempts to fix it then my spouse would be the one leaving.
There’s only been 3 “hot” issues. Yaml, Supervisor, and State color. 2 of which were reversed and 1 that is in the minority. It’s not a trend, you’re trying to make it a trend.
For me, I don’t like the placement of the warning, the color (red means something is broken and take action immediately - just look at your car dashboard), and the lack of precisely what is wrong (OS, dbus, docker logging, etc.) As others have intimated, it’s half-baked.
Make this “feature” (?) a section in the Configure --> Info screen. It’s more appropriate there, standardize the colors for informational, warning/caution, and critical, and be detailed about the transgressions.
BTW, “(un)supported” is the wrong word to use in this context. It’s supported by the community and the person installing it and maintaining it. “(un)recommended” would be a much more appropriate word.
Terry
2 Likes
IME offering help gets thrown back in your face with a “we don’t want to discuss this - closed”.
Terry
the whole thing with the coloured warning wasn’t an intentional thing i believe. We have logging in the systems i use at work and certain word or log level are colour formatted. critical/error is red,
Maybe they should change it to informational, but then again, most people set logging to only error and above so they would never see it
For the wording i probably put “community supported installation”
2 Likes
It’s unsupported by the install scripts. That’s the context, I’m not sure there is a better word.
Some things are not up for discussion.
This on the other hand is probably something that could be negotiated in the correct channels. If you want this to change, write up an issue. Or create a what the heck before the month runs out. TBH I don’t think anyone is adamant that this stays a critical error. That’s just what it was made. It’s critical information to correctly installed supervisors. Based on that logic, it makes sense to make it red. Sometimes you guys need to put yourselves in others shoes. It’s not just about you. I’ve said this 3 or 4 times in this thread. The error message helped me fix my installation. Had it been buried, I would have not seen it or noticed that I had out of date packages. I don’t touch the OS often, how am I supposed to know?
Well, not true because:
-
If you get to the point of seeing the error message in the supervisor screen… The Install script worked.
-
I installed it on Ubuntu using the install script (before it was removed/hidden) and it worked just fine. Like with ANY Linux install, I reviewed and installed the pre-requisites, then ran the script. Done. That simple. If it is no longer supported by the install script, it’s because the script is doing specific checks for silly violations that have no bearing on the outcome.
EDIT: They can call it, color it, place it where ever they want, just give us an “Acknowledge” button to accept liability and make it go away.
Terry
Totally off-topic, but
if you run supervised, it is your responsibility to keep the OS up-to-date. It is not a big work to run every three weeks, before you upgrade HA, to do a
sudo apt-get update && sudo apt-get upgrade -y
1 Like
Yes, I know. Was just giving my personal experience.
It is true because that’s the intent. It’s only tested against Debian. This is what they mean by not supported. If you run into issues installing, they aren’t going to make changes to the script to fix it. Only if it’s Debian.