That sounds like a good idea. Though that thread is already lengthy and posters get annoyed when we ask them to read it.
Usually, when a user has a problem and they post it to this forum, we will attempt to solve their problem or if it is a bug, narrow down what part of OH the bug resides. Then we will ask them to go file an Issue, often proving a link on where to go.
I would prefer that the users follow this approach really because I don’t think that “normal users” as Michael put it, have the knowledge necessary all the time to know to go post an issue all on their own or know which repo it should be filed in.
But at the same time, when asked by someone here to go file an Issue, I do expect them to do so. As someone who is not experiencing the problem myself and maybe not even using that binding, I’m not the right person to file the issue. If additional information is required like debug logs and the like I won’t be able to provide it.
Because the only way the developers who will fix the bug know there is a bug is by there being an issue on GitHub.
As Jan said, it is unreasonable to expect the developers to read every posting trolling for potential issues.
Not all Issues are actual bugs but instead miss-configurations or miss-understandings. That’s what the forum is for. But to repeat myself, when the helpers determine that the issue is indeed a bug, we need the user to file the issue because the helpers are not in a position to help the developers figure out the source of the bug.
Honestly, if this is too much to ask of a user, then that user is a net drain on the project over all. Open Source development is a community effort. We ALL must pitch in and do our part to make the project succeed. As a user of the project, you can do your part by filing issues when you find a bug.
It’s not hard. We can help you with the process if you run into trouble or can’t figure something out.
If you can find ANY open source project that works differently I’d be very interested to see it. They may not have you go to GitHub but they will require you to file an issue
This. ^^
The forum is for asking for help. Sometimes on the forum we may determine that you have found a bug. If we do, we need you to do your part as a member of the community and file the issue. If that is too much then I’m sorry to say that you are a net drain on the community.
In this context issue == bug.
We will never recommend you file an issue over a problem. And as I’ve said several times in this one reply, we don’t expect users to just know when to file an issue. But when the helpers on the forum ask them to, we expect them to do it.
The documentation is almost never adequate. Honestly, the folks like me and vincent and dim and all the rest are the first line of triage. We end up being the ones that walk the users through some diagnostic steps that will help us to determine if the problem is configuration, indeterminate, or really a bug in a binding or the core. If it’s determined to be a bug, we will ask the user to file an issue.
That’s why we wrote that “Help us Help You” posting. We spend a huge amount of time playing 20 questions and reading through logs and such to try to diagnose problems. 80% of the time we find it’s a configuration problem. The rest we send to file issues where we assume the devs pick up the 20 questions and hopefully find a fix.
In this particular case, Jan asked vossivossi to file an issue. I went and looked and found the wrong already opened issue confusing matters. But the fact remains, the user knew to go file a bug because we asked him to. We don’t expect any more of users than that. We don’t expect them to know to go file an issue on their own. We do expect them to ask for help if something doesn’t work and file an issue if they are asked to.
So it would seem. The problem must not be in the JDK on Network Binding.
Expire is really not the focus of the conversation because it never should have been a binding in the first place. It should have always been part of the core. And I suspect that what Expire does will become a part of the core in OH 3. At least I’ll continue to squeak about it until it is.
We do have an approach to provide continued support for OH 1.x bindings. But realize that OH 1.x bindings ARE old code. If you need to keep using OH 1.x bindings, then staying on old code is your only viable option.