Turning Off GitHub Issues (2016)
gist.github.com
gist.github.com
Yes, you don't have to answer people but when you put code out there for someone to use is it crazy to think people may have a question? That should go in an issue. People can search and find those answers. Telling someone to read the docs or go to StackOverflow, where the creator of the project may not be, is a terrible idea. Questions give a maintainer an idea of what should be focused on while keeping ownership of those questions for triage. Getting lots of people asking the same thing over and over? There's a good chance your design isn't that intuitive for that use case so maybe adjust? Good luck aggregating that information from multiple third party services.
You can even find issues, even MAJOR issues without understanding the code at all. If someone finds a major issue but has no way of knowing how to tackle it now you're going to either miss out on knowing about it or they're going to submit a PR that is a big waste of their time and your time.
This suggestion loses out on data and more direct interaction with users. Seems like a big loss-loss to me.
You have gotten a sign wrong here in your sensor readings where arrogance and hostility are. Someone gives you a present that comes with a condition. You either take it, or you leave it. But calling the donor "arrogant and hostile" because you don't like a condition just got you uninvited from all future gift exchange parties.
Back then when people still knew what patches were, the whole post of the OP would have been a one liner:
[x] send patches or stfuThe person who says that is either an idiot or doesn't care about the product. There's really no third option.
It's fine if you made something once that you no longer care about and want to abandon. Really! I understand that free software isn't free! Someone has to make it, and that takes time and effort and energy, and maybe you don't want to give that anymore! That's OK!
But don't for a second think that it's reasonable to give a song and dance about pretending to still care while demanding pull requests for every bug. Mark the project abandoned, and go do something else without stringing people along. Otherwise you're being a prick to your users for no reason. Non-technical users discover bugs that you didn't catch all the time. If the developer/maintainer gives half a shit, they'll listen to those users.
If you only care about the bugs that someone else fixes for you, then you don't actually care. They do, and you're just pretending. It's perfectly reasonable to stick your fingers in your ears and go "LALALALALALALA" instead of listening to reports about bugs in your product the moment you stop giving a shit about it having bugs. A competent person who actually gives a shit isn't willing to put their head in the sand like that.
You're mischaracterizing the author's post. Notice that the author specifically wrote:
+ "Fork the repo, add a failing test."
+ "Add an example in the repo that illustrates the bug."
Neither of those requests is "fixing" the bug for the author. Maybe those tasks in your opinion is asking too much of users -- and that's fine to feel that way -- but it's obviously false to say that submitting bug reproductions actually fixes the bug. It certainly doesn't.
Obviously an idiot.
> It's fine if you [...] want to abandon [a project]. Really! I understand that.
The idiot does not understand:
It is NOT ok to reduce interaction with endusers when it becomes too tiresome.
It is NOT ok to demand patches instead of bug reports.
It IS ok to just completely abandon a project though, i.e. not even accept patches?
Bwahahahaha.... (that is a good laugh born out of an idiot's blissful ignorance).
PS: The only "prick" in the discussion is the one who feels entitled to something and who calls people names because they don't deliver for free what her/his majesty wants.
Not everything has to be a "product." Sometimes developers toss their projects up on Github just to get it out there. They don't necessarily want to make it a "product." There are plenty of valid reasons to open source something besides just, "I want a bunch of people to use my product so I can become famous."
Word choice aside, I don't think the author is trying to say, "send patches or stfu." I read it as the author pointing out the shortcomings of standard "issues", and exploring alternatives that might encourage closer collaboration.
Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
Recently I've opened an issue on a project I really appreciate, and I'm so sorry I don't have time right now to help the developers solve it. And so I don't blame them either.
When I'll have more time/skills I will totally stick around, keep giving feedback and maybe propose PR if he hasn't solved the issue by then. But I really don't feel like signaling a serious issue without PR was spamming them.
And who know maybe I'll become a contributor one day if I can. But right now, had I been "forced" to submit a Pull request I would have either submitted a really crappy one or more likely censor myself...
Here is the issue if you feel like having a look : https://github.com/pgRouting/osm2pgrouting/issues/167
NOOOOO. No thank you. There's a mailing list, a gitter.im channel, a Stack Overflow tag, and my email address, all of which can be found in the README file you see first thing. Don't abuse Issues for asking questions.
I don't bother with mailing lists, and when I post an "issue" on the site, the system mails you on your preferred mailing list. Then You reply to the mail with your preffered client and it shows up for me in the issue thread on github?
Questions in an issue tracker are like rocks in my shoes. You have to work around them, and they bug you (the developer), not the person who put the rock there. When can a maintainer close a question-issue? Never - because whether a question has been resolved is up to the person asking, not the person answering. As a maintainer, if half the open issues in an issue tracker are questions, my "open issues list" is suddenly completely useless. And this is really common because lots of people asking questions will disappear and never never close the issue once the question has been answered.
User questions are important, but the github issue tracker isn't the right place for them. If you want to take notes but the only paper you can find is my todo list, its still not ok to take notes in my todo list. Github issues is the same.
If you can't be bothered to send an e-mail or submit to a mailing list, why should he/she be bothered to deal with your preferences? He/she is delivering the value, not you.
An issue feels, on the receiving end, like an accusation. The word says you did something wrong, and you've inconvenienced/harmed/let down someone, who is now waiting for you to make them whole again.
Answering a question gets you a thank you–you've done something altruistically,. You're a good person.
Fixing an issue? "Took long enough. Are you sure you're any good at this?"
At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
Yep, even if you are a kindergartener.
https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
I normally search through Google, which will find the best source for my question, be it Github or SO. Maybe the creator is not on SO because they have no time to go there.
I do agree on everything else except that affirmation though, but I also think you are looking at it from the point of view of a maintainer with lots of time, when that might not be the situation. The maintainer might just not like providing free support for a company, while still caring for improving the project. This just seems like a way of (over)filtering things.
Yes. Even if it's a stupid question in the docs maybe that means the docs are not as good as they could be. Or maybe it's a lazy developer / user. It doesn't really matter; most questions are going to be asked multiple times. Saving it in an issue will help those users who use GitHub or Google search and come across it.
> If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question?
This is a pipe dream. You're never going to get issues of substance. Even if the proposed gist you're going to get a lot of PR garbage that maybe wouldn't have been a PR in the first place.
> I also think you are looking at it from the point of view of a maintainer with lots of time
I don't see why. My position isn't A maintainer has to answer all questions in an expedient fashion. When you add friction you're going to get less of both the good and the bad. If that's a trade off you want to make, fine, but that's not how you make a good product IMO.
It's an important skill to learn to take a lot of incoming noise and filtering it out to find the signal. It may be a good time to work on it if you have a OSS project people are using frequently enough to file issues. Don't forget there are other resources available to you. You may find people in the community to help answer questions, maybe you already answered a question in the past and you can quickly search for it and reply, etc.
Of course if you remove issues and reroute people to PR the quality of them will lower (though not so low as Issues) while you will miss important things, but still seems like the net result is a easier to review _issues_ which might be what saturated maintainers want.
Edit: I totally agree with the last paragraph (and parts of others of course).
A month ago I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves.
QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here.
If the open source project in question is one where users can be reasonably expected to be familiar with your code base, then "propose a fix with a unit test" is fine. But when it's a project whose nature means that users have little to no incentive to look at the code, then the reasonableness of this request decreases with the the size and complexity of the project. And, quoting BugsJustFindMe again:
Caring about FOSS doesn't fix bugs.
I'm a competent developer, but if I ran into a bug in the text-processing utility Pandoc, it's very unlikely I'm going to drop what I'm doing, analyze the source, pinpoint the problem, and submit a PR with a unit test, and oh yes, learn enough Haskell to do all this, and I don't think it would be reasonable to expect me to do so.
Point being, if you find a bug in a software, as a fellow developer, I think it's reasonable for the maintainer to expect you to at least take a quick look around. Regardless of prior knowledge. You get to learn stuff, and the project maintainers have their load lighten up.
Real open source is about the community as much as the code. It's not about authors and users each trying to set themselves above the other. True collaboration involves mapping tasks to expertise in the way that results in the greatest overall good. If an expert in an area unilaterally shuts off that conversation, then they're not really helping open source. They're just throwing stuff over the wall and pretending it's open.
For batch-processing tools like Pandoc, uploading an example input file, output file, and description of what's wrong in the output would still be very useful.
I guess the nearest analogy for a graphical tool that you use as an end user, rather than a developer, would be recording a video of you triggering the bug :)
Yes, a cursory glance at the author's repositories shows he's talking about libraries for other developers and not consumer apps like LibreOffice/GIMP/VLC/etc used by non-programmers.
As someone who wants to contribute to a project for the first time, there would be nothing more frustrating than spending time creating what I think is a good pull request, only to have it be turned down (which it will be).
Issues help new contributors and repo veterans determine whether it's worth the extra effort to create a pull request. The problem with low-quality issues needs to be addressed by automation and filters, which GitHub hasn't done yet.
If this is a random one-off drive by bug, then why go through the hassle of figuring out what particular standards any individual maintainer wants to follow just to have it turned down, or discover that some regular contributor already patched it while I reading the documentation.
(I mean, I'd love to contribute, but the few times that I've stumbled upon a bug, fixed it, figured everything the maintainer wanted in a pull request... it was aleady fixed by the maintainer and I'd just wasted a lot of time)
that's not a very scalable thing to do, as it involves unbounded amount of work. what if the maintainer never pull in your fix?
Ugh. No. 999 times out of 1000, the person maintaining the code actually knows what it does and how it works. And if I'm not that person, I don't. I found a problem. The problem affects me. It also probably affects other people.
I'm an intelligent, capable, curious, knowledgeable, and caring professional software developer. I write code for fun, but I write _my_ code for fun. And after that I don't have the energy or the inclination to learn how your shit works deep down where it matters. Because what will take you a minute, will take me a month unless I stop going to work every day.
I will do my best to describe what I was doing when the problem occurred, what I expected to happen, and what happened instead, but screw you if you think I need to understand your codebase or your testing infrastructure in order to report a problem.
But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or leave it, or recommend a different approach in a civil tone if you must. But 'screw you'? Not classy.
Also, many Github-hosted projects are critical infrastructure for some people. They will make it as easy as possible for the developer to fix their bugs, if they are rational.
To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason.
Emotional comments beget emotional comments.
Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR.
> Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea.
If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).
It's still nasty to be rude to a developer instead of offering politely worded advice.
Work smart, not hard. If you're getting a lot of support requests (entitled or not), add a paid support option. If you have so much traction already that you constantly have to deal with "hundreds of issues", you're well past the point where you should have done that.
Then, fine, tone police, I'm not classy.
I am, however, a FOSS developer who understands the value of non-technical contributions to a project.
Know which kinds of bugs don't get fixed? The ones your users never tell you about because you decided to make it hard to report them.
In almost all cases, turning issues off is incredibly counter-productive.
But apparently they're not allowed to decide what works best for their project as far as bug reports.
Just be nice, and your accurate advice is more likely to be useful. That's all.
https://en.wikipedia.org/wiki/Tone_policing
My advice is already useful. If someone chooses not to take it because they'd rather tell non-technical users to pound sand, then I hope their project suffers for it.
This seems like a reasonable thing to think and say.
A better alternative to the article's suggestion is to state somewhere that it is very likely your issue won't be considered unless it takes the form of a PR. The maintainers, if they don't want to deal with the bug, will say "could you make a PR with a failing test case? Otherwise I don't have the time to work on this".
That way, those who really want the bug fixed have to put in work, but those who just noticed a problem and are kind enough to let the maintainers know can do so easily. Why discourage bug-reporting?
It's the 'screw you' that put my back up.
Most people freaking out about being burned out by their open source stuff are generally people who don't open source their stuff. Most open source projects, even very good ones, get very little traffic therefore very few issues. If you can't deal with the occasional email once every few months, turn notifications off.
> But 'screw you'? Not classy.
Saying "Write a test" is essentially saying "screw you". Github has been a blessing, in that it greatly lowered the barrier of entry in filing an issue with a project. It's a blessing for users and it's also a blessing for maintainers if you know how to deal with the influx of issues. Increasing the barrier of entry again is not the solution.
When I myself find bugs I'll certainly PR a fix if I'm able to (and have the time); but I often can't. Most of the time, because the development environment is unknown to me and I have no way to even run the tests (if there are any), let alone write one. So asking someone to get involved and up to speed with a project to the point that they're able to do this, before they can even file an issue with a screenshot that says "the padding looks bad on firefox", that's nonsense. It's even more nonsense when this is just a pet project of yours that most people will not care about.
IMHO, "this is stuff we do give away for free" is an excuse that's too often passed around. It is always true that projects you push to Github for free come with no obligation to care about it, its issues or the pings and cries for help from your desperate potential users. However, you lose the ability to say you're a good open source citizen and you're "giving things away".
A real-world parallel I can make is to the people giving their old/smelly/crappy/torn/bad clothes to charity shops and feeling ever so good about themselves. It's cool you have good intentions, but it's not charity if it ends up in the bin anyway.
Disclaimer: 99% of my work is open source and ends up on Github. A bunch of it sucks and when issues come up, I ignore them or write a 10-second close-reply. A bunch of it is good and I actually care about; and if I care about it, I'm not going to turn off issues just to make myself feel better about having an already-perfect project.
This is what we call a strawman. Also, I guarantee that you do exactly what you're glibly dismissing every day of your life.
That attitude sounds crippling to being productive. At some point you have to trust code based on usage, brand, peer-reviews etc.
For a command line tool you can write a shell script demonstrating the problem.
That being said, maybe there could be a "found problem, not sure is a bug" flag that defaults to on. Or a warning dialog that says "without example code or detailed repro, this issue probably won't be looked at."
Ugh.
My partner, who doesn't know the first thing about code, understands the value of FOSS. Caring about FOSS doesn't fix bugs.
A month ago (more?) I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves.
QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here.
Back here in the real world I was able to report the bug and have it fixed by someone who knows what the code does.
If you see Issues as a place where anyone can demand new features or bug fixes for free, then I can see it being overwhelming. But I think most people see it as a community-based repository for thoughts, bugs and ideas.
For example, this happened recently:
User 1 kept having an issue, but no idea how to get debug infos.
User 2 had the issue once too and knows how to get debug infos, but can't reproduce the error.
By having both post in the same issue, the root cause and a matching solution were found before the maintainer even saw the issue :)
Since the Issue-tracker is public, we can have those benefits where we can take weight of the maintainer's shoulder.
In another repo I just do releases to a specific distribution platform and my users basically do all the work.
"If we want to include more people in open source, I can't think of a better way than getting open source code on their machines and into their editors."
Wrong pronoun. The author presumes to speak for "us" in open source, but doesn't really represent anyone but himself. For most of "us" getting more people involved requires quite a bit of work explaining how the code works, how the tests work, and so on. Anybody who's not putting in that kind of effort, even if it's because they don't need to on their personal hobby project, should STFU about what "we" can or should do to get more people involved in open source. Try working on a big, complex, multi-person project in a less-obvious specialty, and see if "just load this up in your editor and get back to me when you have a patch" will work.
There are a minority of very capable people whom need to be able to report security issues and want to contribute valuable additions easily.
I for one just found a CVE-worthy DoS in a popular YAML library, and an working to resolve it and improve testing.
Shutting off the phone and answering machine because of telemarketers isn't "the" solution, because then no one can get ahold of you.
Instead, deal with the shit to get the sugar too. Otherwise, why use GitHub or why have a phone?
But if you close them NOTABUG or WONTFIX, you get a reputation as that guy who just doesn't want to hear about it, what a bastard.
I think there must be a middle way somewhere, for those projects which attract a lot of interest but few or no co-maintainers. But I'm glad I'm not on the hook for finding that middle way, too.
Support is what it is, and it's a two-way street.
Most engineers usually don't have customer support or sales experience, and so don't have the experience to triage and communicate pro-socially. (I sold software as a high-school job and also had my own consultancy at 17.) It's important to push outside one's comfort-zone when young (or old) to acquire skills that will be vital later on.
Post the policies, requirments and desires in contributing.md promenently. (I think a CoC is redundant and tyrannical SJWing.) Setting expectations and not making promises is important.
Finally, there is a cost to FOSS on both supply and demand sides. I just had some company fork the repo of a project I fixed, make a pointless PR and then offer no contributions in a grsec-theft-style way.
PS: Subversion has a great talk about defending the community.
While chats can be used for that, they do not make a good job to archive the results a group discussed. For open source projects, this is essential. I often read 1 year+ old issues and they discussions are still accurate and good.
When people chat, they do not have a lot of discipline to document this. Chats are more like a conversation. They are great for two or more people to discuss something but not really good for an outside person who just gets to read the protocol.
SO is not the place to have discussions. You help people for their specific problems. You do not discuss changes there. At best, you leave a link to the issue tracker which deals with that topic.
Is this not literally the point of comments in the code?
English is easier than code; don't be the person that puts up barriers.
However, this approach is not good for non-technical end users. Remember that there is a lot of end-user facing open source out there and those folks aren't programmers!
I get that help vampires are a thing, but so are prickly developers. As a developer it's your prerogative to be an asshole, but consider the effect on your reputation.
Also, I learned what "help vampires" are. Neat.
Formal bug reports are certainly important, however as the author points out the Issues feature in GitHub too often gets used for simple questions that could have been answered reading the docs, searching past issues, or just googling it.
The templates GitHub added last year have been a godsend in terms of improving things but I'd like to see an option to make filling out the template mandatory.
- Users who are loyal who cannot code are discouraged from voicing issue or asking for help
- Users who can code are dejected because that is the only way they bring up an issue first without coding.
Sometimes the creator is best suited to give advice or to simply do the thing at initial report or query.
- Makes the project look closed off.
- Lack of community and vibrancy, there are no issues, is it finished -- encounter issue -- bad software.
- Why are there no issues, is this developer giving up?[1] https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-p...
(edit: I know the link talks about PR, but for me it applies to issues asking for features or weird bugs as well)
For example, saying that you shouldn't allow a user to report an issue without an associated test for a project that is a UI tool isn't feasible, because there's no guarantee that the user is going to know how to write a test. The same goes of a developer-oriented tool that isn't strictly a code library.
The reason a library or framework is a bit different is because these generally fit in the culture of a particular language. That means questions like where a test goes, what the directory structure is, etc, should be relatively understood by a contributor. If the contributor is too new to understand them, this does leave them out in the cold, in a sense---but it's also important not to ignore the value of the developer's time.
Some may say, hey, you don't have to address all issues. And in a basic sense this is true. I have no obligation to respond to issues in my repo. But I'm a human being who likes to follow the golden rule. I want to interact with others if they are willing to engage me, but I also need to keep in mind that I have, say, 5 hours a week to devote to this project. Saying “bring some of your time and I will give you some of mine” doesn't seem rude in this context. Indeed, it seems natural.
If you're just doing a side project and you don't have the time to invest, that's fine. Go use another library, and be well. No hard feelings. If you're using this professionally, you're using my code to save you time, which is to say money in this case. I have zero qualms about asking you to invest a modicum of that time to reduce the few cycles I have that must be devoted to reproducing your issue.
Audience matters. And one must remember that choices like this shape the audience of one's project. If I decide to turn off GH issues and only accept pull requests, that means I've probably reduced my audience. But it also means I've set a tone for that audience. If that's the choice someone wants to make, I think they should be encouraged. After all, the more quality code that is out there to see and learn from, the more we all benefit---even if we don't use a given library directly because its interaction style isn't our own.
Wouldn't you basically device some way to avoid this as much as possible? This seems to be a similar case to popular, single-maintainer OSS. The largest open issues I've had I think was under 10 in 1 day after launching a mid-popular project of mine and luckily it was _after_ launching (so no middle-of-workflow). I cannot even start to imagine the load for a popular dev, and this indeed seems like a good way for a saturated person to offload some of the work to contributors while raising up the entry bar. Cmon, this is even a basic economy rule: supply and demand.
An alternative I've thought is, for purely one-on-one support that only benefits OP, redirect them to some support platform where it can be handled as the developer prefers. In that way it makes it even more viable for the developer to keep working on the project. I just don't love the perverse incentives it generates, but seems better than other alternatives.
But I can describe an issue, I'm trying to find out how to reproduce an issue. I try to write issue reports which could help a developer what I want or what I think is not working correctly.
It is not perfect, sometimes it is a wrong setting or something else which breaks. But I doubt it is 99% on GitHub.
People don't get burnt out from people discussing / proposing fixes or improvements, they get burnt out from not having the time or support to fix / implement them or from to much concurrent work and context switching.
You get what you pay for when you use open source. You are either paying for it in time and or cash.
As a developer I would LOVE to have everyone submit a failing test or a PR rather than reporting issues but that's just not feasible. Most never will, because there's a learning curve they don't have time for - the language, the tooling, the product itself, Git/github/PRs, etc.
As the project maintainer, that's what I signed up for. It really sucks sometimes, but I'd rather sort through the junk and personally fix the issues people report than funnel everyone through hoops they likely won't spend time on and lose that valuable feedback entirely.
It's obviously much more efficient for a few experts to understand each OSS library.
I understand open source maintainers get burnt out. I don't think he should focus on a solution that doesn't even seem to be working for him.
I'd love it if I didn't have to use GitHub Issues as an ad hoc FAQ document, but it's better than nothing.
My favourite approach is to make all issues LABELED, then you can easily focus on those which you need, and let other issues for people who have time to read and help them.
In fact, github issues are indeed for asking for help: "Issues are used to track todos, bugs, feature requests, and more. As issues are created, they’ll appear here in a searchable and filterable list. To get started, you should create an issue." you can also read here some interesting facts https://guides.github.com/features/issues/
Instead I'm in favor of the fire-and-forget feedback form. This makes it clear that feedback is a pure gift with no obligations on either side. Users: you don't need to look for duplicates or come up with a way to reproduce it. Just talk about what happened to you. Developers: it's just data, do with it what you like. Go wild, run machine learning on it.
Okay, sure, add optional contact info, so the developers can ask for a repro case if they think it's particularly interesting.
(There was a great Paul Ford article about Internet feedback but my searches aren't finding it.)
(I'm aware the gh issues discussion is the more valuable one to most, but as I don't worry about gh much I doubt my thoughts on it haven't already been covered by comments here and before)
I've gone down the path described above and I've been equally burned by maintainers who are not interested in the feature, not interested in the bug fix, or in general are inactive.
I want to contribute to projects instead of simply forking and doing my own thing, but before touching the codebase I want to poke the maintainers to see if the feature, bug, etc. is worth the effort.
I'm going to submit an issue before I write a single commit. It's not worth my time understanding a codebase, debugging, submitting a PR just to have it rejected or fade away into the abyss.
Checkout some of the issue I have in my repo: https://github.com/sergiotapia/magnetissimo
They are valuable insight into the problems people have, and if I asked them to open a PR for every problem I would most likely have 1 or 2 at most issues open. Everybody loses.
For example, I recently started using someone else's code for a project, largely unchanged. However, I have run into issues. I normally just file these issues under my own github fork, rather than the upstream. If I really can't figure something out, I may choose to file an issue with the upstream, but otherwise I'm trying to only send pull requests instead.
It seems like this would also really help with duplicated error reports which can be burdensome to sift through, and hey if someone else comes along and has the time to fix the bug in question they now have a great means to validate their fix by.
Then tell users to read both before opening an issue. Set some rules on how you want the issues written, tone of voice, etc.
A project without issue is a project nobody is using.
Issues aren't just off powerless users, their for users who are focussed on the downstream, not your codebase.
Yes, open source means of they want to get into your codebase, they can. It doesn't mean that it should be a prerequisite. Certainly, you'll get less distraction from people opening issues (invalid or otherwise) if you do this, but it's a particularly user-hostile move unless your target user audience has very similar skills to the projects core devs.