[SOLVED] Handling and responsibilities in bug tracking

@rlkoshak

This may be. But the developers also benefit from the users. They are always available for tests and reports. They mostly provide the free and voluntary helpdesk, they usually filter out and analyze the real bugs. They give the developer new ideas and make suggestions for improvements and enhancements.

That’s exactly how an open source project works.

1 Like

In life, thing change and projects like this hopefully grow and mature. Older, mature people like me sometime have trouble accepting that things have changed. They then get frustrated, left behind, and ignored.

1 Like

Give up, Alex… We seem to be the only two who believe this.
It´s quite clear to me, there are some people in here who believe the users time spending is worth nothing, unless they are willing to spend even more time on Github as well. It´s their responsibility to do so, it seems.

We become the ‘grumpy old men’.
In this particular matter, I dont feel grumpy though. Old yes, this I cant ignore. But not grumpy.

As I have tried to explained a few times, I see this as a more flexible way rather than pulling obligations and responsibilities down onto people (neither users, developers or anyone else), who I believe are part of this project, because of interest and they care.
My experiences tells me, each time you put obligations and responsibilites onto someone, they either demand something in return, (which then puts obligations and resposibilities onto others) or they will back off. This is how commercial products works.

A open source project should, (in my opinion) be driven on interest and caring from all involved parts.
That involves, (but not limited to), interest in filing issues on Github as well as participate on the forum from the users side. But also receive and respond on issues filed on github as well as participate on the forum from the developers side as well, (Ofcouse this has to be limited in some way to make room for developing. Otherweise nothing really matters).

I know you as well as others, as it seems, do not agree on this. The problem is, if/when thats the way the users sees it, you´re back to the situation explained above, where they will pull obligations and responsibilties down onto each other, and caring/interest become a secondary drive, if any drive at all. By then, you have the recipe for a commercial product insted.

2 Likes

Just to clarify for those in the future.

This thread topic refers to users sunning Testing (Milestone & Release Candidate) builds of OH. It also applies to those running unstable (snapshot) builds.The purpose of these builds is testing and bug reporting (onGitHub). Although forum discussion can help narrow the scope and isolate the root cause of an issue, the issue MUST be reported in GiHub to be resolved.

Users running Stable versions do not have these same responsibilities.

Does it really change anything?
A user running stable who runs into a issue has the exact same responsibility, (read - possibility), if he wants the issue fixed. Only other option is to change to the unstable/testing/milestone hoping the issue has been resolved. But then he ends up in this “responsibility demand” thread.
By then, you´re back to the same once again.

You are contradicting yourself. See here.

Isn’t he on 2.5 Stable?

Possibility vs. Responsibility. I did not say stable users cannot file on GH.
I asked nicely since NPEs are usually bug. The user does not have the responsibility to do so though,

Agree.
But you agreed with the original statement - There is no issue if it hasn´t been filed onto Github. Right?

With the above in mind, please answer this:

  1. Which options are available for a stable user, who run into an issue?
  2. Which options are available for a testing user, who run into an issue?

The answer seem pretty logic to me with the original statement in mind - Github!

When you are pulling obligations and responsibilities onto the testing users, you´re accepting the stable users are not having the same responsibilities. But the original statement from the users side of view, are the exact same. If not, please explain how its different?.

Problem seems to be, if a stable user run into an issue, he´s automatically beeing pointed towards Github for his reporting. According to the original statement, thats the only option you can offer, right? In that case, he is beeing threated as a testing user. There are no other options.

So I simply have to repeat my previous question:
Does it really change anything?

Yes, as stated by Kai, starting this thread discussion that there is no bug unless it is on GitHub…

A Testing or Unstable user has obligated themselves to files discovered issues since that is the major purpose of those versions. There is no such obligation for the stable users.

Taking a totally pragmatic view ;
If you want the right people to see the problem you have, the ones capable of fixing it for you - put it on github.
Putting it on github should also encourage you to formalize your problem - examples, evidence, impact etc. - to make it easier to fix. You want it fixed, right?

Totally self-serving, but seems in agreement with much of what’s said here.

2 Likes

Also, if users do not want that responsibility, stick to using stable versions.

But again - Does it change anything from the stable user point of view?

And this goes, wether or not the user is testing or stable, right?

If you want/need a issue fixed, Github is where it goes. If you dont report on Github, there is no issue. I dont see anywhere this differs from the users preferences.

1 Like

We can help them, possibly my pointing to a known issue / bug.

The problem is Testing/Unstable users who complain here while not fulfilling their obligations to help resolve the issue.

This dead horse is now well beaten.

image

But stable versions still have deficiencies … we’re back to “but you want it fixed, right?” which leads to “well, here’s the process.”

Process as I see it - raise it here, discuss, share experiences, maybe get help with your own stupid mistake, maybe find a workaround, maybe find someone who understands it better than you. If its still a bug, github it.

Versions don’t seem to matter much.

3 Likes

Stable release users are allowed to complain? :wink: If so, I’m going to switch to “Stable Version” immediately! There are the same errors inside like in latest Snapshot or like in (M1, M2, M3, M4, M5 ,M6 and RC1). :wink:

Yes, and we are free to ignore them. :smiley:

Developer here.

I see sometimes people refer to developers being on GitHub and not here. I don’t think this applies anymore. This was (probably) true when openHAB core was the Eclipse Smarthome project. But now that ESH has been integrated back in openHAB I see all active developers very regularly interacting here on the forum. So my suggestion is to not make this distinction anymore as it only creates a artificial distance between users and developers (who are users anyway).

What about GitHub? Since everyone is completely free how to handle feature or bug reports there is no one way how these things are handled. I follow the forum regularly for bindings I maintain and if there is problem I try to fix it. However this is my personal approach as a developer. And if other issues are reported here and either there is no developer or it is handled by someone who can’t fix or hasn’t the time to fix it right away the best advice is to create an issue on GitHub. Why? Because on GitHub it’s better suited to track specific issues. Here on the forum there a very long threads and a specific issue can easily get lost. On GitHub I can assign it to me and I always have it as a todo. For this reason I also suggested recently in some topics for users to report the issue on GitHub as I don’t have enough time on short notice to fix it and I already saw these issues got buried as multiple people reacted with different issues. So should issues be reported on GitHub? Yes if it’s critical and if you don’t want it to get buried this is the best advice.

How about it being to much to ask for a user? I’d like to give another point of view for the user. Here is a constraint: A developer has limited time and can decide what to work on obviously. So any time not having to figure out what the problem is increases the chance to get it fixed. Look at it from a production line optimization (Like the Toyota Production System) So it’s in the interest of the user to optimize the problem to be as concise and best described as possible in order to reduce the noise. Because the less time it takes to pin point the problem the faster the developer can get it fixed. So basically the user is in control to manage the developer time in order to get the user problem fixed faster. And as a user you should use ways that best help your case to enable the developer to operate effectively and filling a GitHub issue certainly helps. As this is an open source project and not a commercial project there are no commercial priorities to fix issues. So developers also look what can be fixed easily. Therefor suggestion to file a GitHub issues should not be seen as annoying the user. But to give the user more means to manage the developer’s time and progress the users case to get solutions. That said. In the end there is never a guarantee something gets fixed, but as a user you can provide the means to make it easier.

6 Likes

Everything also has been said in this tutorial from February, 22nd, 2019:

.

EDIT: This Topic has been read only by 306 users… :frowning:

So I guess: only ~1% of all (~33700) forum users ever could have known this…

Kai explicitly stated if it is not on GitHub it is not a bug. What started this discussion was issues discussed on the forum but not on GitHub so therefore not addressed.

You can suggest to Kai he change the policy if you wish.

Perhaps that should be pinned in the forum.

1 Like