[SOLVED] REST endpoints: Unify different approaches

[rlkoshak (Rich Koshak)]

@David_Graeff

What I’ve learned: don’t fix other people’s problems, because they will complain that something has to change.

What I would hope the lesson would be is that not one single person on this forum can know and understand all the different ways that users are using OH. Indeed change is inevitable but understanding the impacts of these changes is important too. When users speak up and complain that change X will cause problems Y and Z for me, this is useful information. You can use that information to perhaps modify what you change or how you change it to lessen the impact on some of the users.

You will never make any user happy that they must make changes to how they are doing things. To expect that you can make every user happy about any change, no matter how innocuous seeming, is unreasonable. You WILL have unhappy users for any change.

But in my opinion, it is far better to understand how you are impacting those users and if possible ease their burden.

Perhaps approaching these discussions more from the perspective of “I propose changing X, how does that impact you?” Then you are not trying to convince anyone that your way is best because if your way requires any changes or extra work for the user they will never be convinced. Instead, you are just gathering information about how disruptive your change may be and perhaps you can avoid some of that disruption.

A lot of the arguments and the “let’s gang up on David” that has taken place on these threads I think stem from both sides trying to convince the other. Ultimately the developers will have the final say about what gets built and how it gets built. But I would hope that the developers would want to understand how their changes impact the users. These threads are great for that because for all the heated postings and arguing back and forth, a lot of very useful information about how people are using OH was posted as well.

Just don’t expect everyone to be happy with the changes. And some of the unhappiness could be ameliorated by this slight change in focus. The threads come across as “David wants to make all these changes, let’s try to convince him it’s a bad idea because it impacts me” and you spend your time trying to adjust your original proposal to accommodate the users but you are stuck in a no win situation because you can’t accommodate everyone’s needs.

But if you change to focus on information gathering instead of convincing, and you make the posters feel heard, then I think you will get what you need from the threads and there might be less argument.

Or I could be completely wrong. Who knows?

[hakan (Hakan Tandogan)]

@rlkoshak

But in my opinion, it is far better to understand how you are impacting those users and if possible ease their burden.

This. This is the main reason why I started my “I want to create a foo binding” threads with a first post that was meant to collect requirements and asking how people would have used that binding.

In this case, I’m talking about the nanoleaf binding (which @mraepple ended up writing), the migration of Withings from 1.x to 2.x including OAUTH2 (which is still being written) and pushbullet action (which I’m converting to OH2 just now).