Science Vs Engineering - Why Will / Won't My Suggestion Be Included in HE...?

Please don't take this as some kind of "high-and-mighty" topic to impose my thoughts on the Community or as some kind of gospel or doctrine to follow when considering requests by Community members..... These are just my observations.... Feel free to tear them down :slight_smile:

My memory from Chemistry in High School was that scientific methods involved starting with a theory, coming up with a method to test that theory, performing that set of steps, coming to a conclusion and continuing that process, refining the theory as a result of the investigation.

My later academic and ultimately professional career has cemented the engineering concepts of taking what have become accepted and trusted approaches to a problem and putting the solutions through rigorous real-world testing by applying the approaches to real-world situations. Even these early applications of a solution need to have some level of scientific rigour applied, ensuring they achieve the same outcome expected. From an engineering perspective we are most interested in whether the approach can be applied consistently when the same problem is identified.

I'll acknowledge that engineering in the software / IT space is a relatively recent application of engineering principles compared to industries like construction or aviation, where the outcomes can have much more dire consequences when applied incorrectly or the assumptions are incorrect.

But, for me, when considering conversations here on the Community, it is important to understand that Hubitat need to straddle the scientific and engineering divide, looking to push the boundaries through scientific endeavour, but maintain the reliable outcomes that come from an engineered solution.

In the end not all options work in all situations, and that provides a grey area where we can be left wondering why can't we have what we want.... This consideration between a great theory and a proven engineering solution can offer some insight into why the development team may opt to say no....

3 Likes

I cannot answer for the staff, but I know that the staff consists of only a few people. They have limited resources and limited time. They have to prioritize their workload. One priority is supporting current customers who are having significant difficulties with their hub. Another priority is fixing firmware issues reported by the community. Such bugs are typically corrected quickly and updates are released. The final priority is improving the functionality of the system. However, there are always more suggestions than it is possible to implement with the resources available. Every enterprise whether large or small has to evaluate suggestion for improvement to determine which are worth devoting resources and which are not.

Fortunately, the Hubitat community has many who donate their time and talents to the project. Since they are not focused on the main priorities of the staff, they are free to explore whatever options seem fitting. There have been many superb new features that have come about through community efforts.

6 Likes

That is most certainly true.... "No" does not always mean "No".... With enough benefit and interest from dev's like me, ideas can get up without the same degree of rigour required from a corporate entity. We can do what we want :smile:

4 Likes

Great topic to toss around! It brings to mind the following thoughts:

  1. VOTING – I've watched other successful home automation communities thrive under a Voting based system, whereby members/owners/staff/users regularly cast their +1 on proposed system enhancements. What a delightful way to feel like you have a hand in the company's roadmap, while the execs can rest easy knowing their efforts are focused on something that customers really want.

  2. DEBUGGING – While this Forum does a stellar job of identifying and squashing bugs and bug-like behavior with each firmware revision, it's challenging for the beta tester or casual user to keep up and chime in without reading A LOT of threads and committing to potentially hours of DIY troubleshooting. Whereas tech outfits who utilitize a dedicated, centralized bug tracking system can pivot on a dime the moment some new issue gets posted (and its curated History means newcomers can instantly review previous activity, instead of recreating/hunting up possibly-related threads). It's been said repeatedly that such a system (like Mantis BT) will not be considered here, yet I'm forever puzzled why this pinnacle of efficiency would not appeal (especially to an operation with limited staff/resources/time).

  3. AMBASSADORS – Check your Badges. Are you one of our 11 Leaders (out of nearly 27,000 Users)? Want to become an Ambassador (I count 10)? I believe the Hubitat community would be well-served by the introduction of a new role (call it Specialist?) which members could earn based on their skill set, comportment, Forum involvement, etc. These volunteers could be "deputized" to that Trust Level upon passing some degree of certification, and "demoted" if they do not maintain a requisite participation level. Rate them like you would an Uber driver. How did I do? Did my solution work? (When is that last time someone clicked "Solution" on your otherwise viable 3-page answer to their urgent Help question?) A formal framework that embraces Helpers the way it does Developers would do wonders, IMHO.

7 Likes

Detailed and useful as always... :slight_smile:

Voting - I expect the powers that be will say that they keep a close eye on the various indicators for acceptance within the Community posts, assessing the popularity of suggestions using existing Discourse methods such as Likes. I accept that these can be misconstrued because of the context of the comment, so a more formal voting system may be more targeted and precise (tailoring to my engineering bias... ).

Debugging - I agree that a list would ultimately be ideal, but the current setup of thread Bruce and/or Gopher maintain with those that have been solved in the next release is at least worth mentioning. Beyond that, ye, it would be nice to know the list of known issues, even those not currently on the list of those resolved in the next release.

Ambassadors - Not something I have worried about a lot myself.... Not to downplay the status of those who have been bestowed this privilege, there is obviously some credence attributed to the badge and should be honoured where these users have input into a significant issue (not the Cartoons and Memes Topic :wink: ).

3 Likes

Careful, you would be among the first people I nominate. Can think of 20 other Regulars who are so solidly committed to improving life around here that they make it look like a full-time job (and kick ace while doing it). Don't make me name names.

3 Likes

On the one hand, thankyou, one the other... Meh... who needs an accolade... :slight_smile:

You are right, there are plenty who contribute regularly without recognition... but I like to think we are part of a place where that is not the driver in terms of contributing to the Community. Not that I'm suggesting you are pushing that agenda, or that it is somehow counter to the ideals I am promoting... You are obviously looking to offer those who deserve recognition the rightful accolades, which is a worthy pursuit.

I guess I want my cake and... :slight_smile: In the end... Take your advice from those you trust, like "real-life".

4 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.