I wasn’t going to respond any more but I need to clear up a missunderstanding here. The Foundation Board is not involved in the development of openHAB. They do not decide how issues need to be filed, what build systems are used, etc. The Foundation Board is there to own the openHAB trademark and to run communications and marketing about openHAB.
The core maintainers are the ones who developed how the over all development of openHAB is done.
I already do. But I can’t be the one who creates the issues. See my posts above: tl;dr the person actually experiencing the problem has to file it. I’m also not all knowing on all things openHAB. I can’t always tell whether something is a bug or working as it should. For most bindings I don’t even read the posts because I don’t know the technology.
When anyone on this forum is helping with a problem and it looks like there is a bug, link to How to file an Issue and ask the user to file an issue. I’ve seen several requests on the original thread asking users to do just that.
No one is saying that issues can not or should not be reported and discussed on the forum. But once it is determined that there is a real problem, an Issue must be filed on GitHub. Anyone who spends any time on this forum at all will see that roughly 90% of all the “something isn’t working right” posts are caused by a misconfiguration, a mistake made in the environment, or a known bug which already has an issue open. For the remaining 10%, what should happen and what does happen on all the threads I’m involved with is there is a gathering of information, some experiments and results posted to narrow the bug down, and then a request to the OP to file an Issue. In those rare cases where I’m able to reproduce the behavior on my own system, I’ll volunteer to file the issue.
Call it arrogant if you want. Demanding otherwise feels entitled to me. But this is how it works. This is how it is likely going to continue to work. So conform or refuse but realize refusing means that the problem will likely never get fixed.
To identify any regressions (i.e. bugs) and get those who discovered the regressions to file issues if one is not already in existence so the developers can rank and work them into their workflow.