We tried this on a project with not great results, chief among them being the project maintainer always classifying a problem or defect as "Not a bug" even when it provably is.
Perhaps the worst offense was the insecure-by-default config I mentioned in the other comment. I was unknowingly running it on a public port on a dev machine without auth for months before I realized (the network I was on didn't happen to filter inbound connections on ports >1024).
I used Node-RED pretty extensively for controlling experiments (see e.g. https://github.com/avian2/sigfox-toolbox)
It should, like any other Linux server, be available via ::1 and 127.0.0.1 without credentials. Better yet would be to automatically run a credential script on install to bootstrap, as this project focuses on ease of use of node.js and modules.
I had my own bugs as well that I reported, to no avail. I did find solutions myself.
Instead, I fixed this via the DNS resolver daemon within Linux itself, so my systems natively can handle .onion sites. In a way, it was a better fix, since every program is torified if connecting to an .onion .
We get a lot of questions raised that are better handled on the project forum, slack or Stack Overflow, and try to ensure the github issue list is kept as genuine code issues rather than general support questions. That can be misinterpreted, but it isn't our intention.
The issue template we use does try to steer the user to the forum or slack if it isn't a specific issue. But if they don't read the template and continue to raise an issue regardless, we will generally provide help in the issue and encourage them to use the other channels in the future.
One of the main reasons we prefer the general support type questions to be handled on the forum is the community on the forum is much larger than those paying attention to the github issue list. Someone asking a question on the forum will get a response much quicker than the issue list. It also takes the pressure off the core development team who ultimately, are only human.
Yes we could use labels and have the issue list as a mix of support, feature development tasks and genuine bugs. But we choose not to use it that way.
2. rationalize decision
3. ask for examples when ex-users bring up stories of being dismissed. rarely get said examples coz ex-users have moved onto another project with actual support. this supports your decision to dismiss support issues and send them to the magically huge forum community.
4. why is no one using our project?why do we get badmouthed on STEM oriented social media?
There's a reason people goto github instead of forums, they're looking for technical help not a chat
But now you and others have a real opportunity to discuss the issue here on neutral ground and I feel it is rude to just dismiss the invitation to provide actual examples.
Even my favourite elitist deletionism club: Stack Overflow, has been changing their ways lately it seems and are accepting requests to undelete.
This whole "not putting support" in github issues is kind of BS in my opinion. Whats wrong with the issues being cluttered up? It has a search functionality, and tags, Id rather have one source of truth.
If its basic then answer the question, put it in the readme, or link to another issue that has the question alread answered. Maintainers fail to realize that some people search for issues from a particular context and sometimes variations on the same question are useful when you are searching for something.
This does annoy me. I'm not sure theres a great solution though. Should the maintainer create a new forum post of behalf of the user? Probably not, often with support requests to open source projects - the user disappears right after posting it. This is likely to happen even more if the issue is moved by the maintainer elsewhere.
> This whole "not putting support" in github issues is kind of BS in my opinion. Whats wrong with the issues being cluttered up? It has a search functionality, and tags, Id rather have one source of truth.
The clutter does make things harder. Issues now need to be tagged, issue counts on the project page are meaningless, maintainers must constantly search for the "IsReallyAnIssue" tag instead of just clicking on the issues link, etc etc. How much these things annoy you or anyone else will vary wildly based on personal preferences, and the scale of the project.
But - Heres the thing. It's their project - they are entitled to request help/support requests are made in one place, while bug reports are in another.