
Turning Off GitHub Issues (2016) - jashkenas
https://gist.github.com/ryanflorence/8a62abea562ca2896dee
======
BinaryIdiot
Issues are important for a large verity of reasons. This just smacks of
arrogance and hostility towards other developers you make your work open to.

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.

~~~
jlg23
> This just smacks of arrogance and hostility towards other developers you
> make your work open to.

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 stfu

~~~
BugsJustFindMe
> _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 stfu_

The 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.

~~~
Etheryte
I think you're trying to paint this too black and white. It's perfectly
reasonable to be interested in supporting only the proactive user base of your
project – that way both parties give and gain something.

~~~
BugsJustFindMe
> _It 's perfectly reasonable to be interested in supporting only the
> proactive user base_

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.

~~~
jasode
_> If you only care about the bugs that someone else fixes for you, then you
don't actually care. _

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.

------
chipotle_coyote
I'm going to quote @BugsJustFindMe in a separate comment, because I think it's
a terrific counter-argument to "just open a pull request" as a _universal_
rule:

 _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.

~~~
roblabla
It's funny because i actually did exactly what you're talking about once when
I ran into a bug in the parsing logic of wikitext tables in pandoc. I read the
(extremely well organized) source, having never ever done any haskell before.
The fix ended up being a 2 character change, it took me an hour to do, and I
didn't really have to learn haskell to do it.

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.

~~~
notacoward
What about if they _did_ take a quick look around, and determined that trying
to fix it themselves or even find the guilty line would take too long? If I
spend hours, days, or even weeks like that every time I found a bug in someone
else's code, I'd be doing _my own_ users a severe disservice. I owe it to them
to spend my time more productively than that. So if the author's answer is
"patch or GTFO" then I've found someone I'd never hire and probably wouldn't
even want to interact with.

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.

------
dmethvin
This is from a year ago.

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.

~~~
bowlich
Fork it, fix it. Pull in upstream changes until the maintainer fixes it. I
suppose file a ticket with a snippet of what I did to fix it so a regular
contributor can create a request faster.

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)

~~~
chii
> Pull in upstream changes until the maintainer fixes it

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?

------
BugsJustFindMe
> Think you found a bug? Fork the repo, add a failing test

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.

~~~
robotresearcher
Do whatever you want.

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.

~~~
BugsJustFindMe
> _' screw you'? Not classy._

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.

~~~
robotresearcher
I agree with your argument completely.

Just be nice, and your accurate advice is more likely to be useful. That's
all.

~~~
BugsJustFindMe
> _Just be nice, and your accurate advice is more likely to be useful. That 's
> all. _

[https://en.wikipedia.org/wiki/Tone_policing](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.

~~~
robotresearcher
There is an obvious meta comment to make here that I leave as an exercise for
the reader.

~~~
BugsJustFindMe
Nah, you're probably mistaken.

------
gkoberger
I really like Issues as a sanity check: if I'm getting an error or something
isn't working, it's nice to know if it's a known issue (or an issue with a
workaround). Even if there's no official fix.

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.

~~~
agrippanux
Totally agree. First thing I do when encountering an issue with a repo is
check the Issues and see if anyone else is experiencing it as well. Many times
the there is already an active discussion going on, and the thread can contain
workarounds or an ETA for the fix.

------
wildpeaks
A benefit of Github Issues is that users can also help each other.

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 :)

~~~
maweki
There are a few repositories where I know that I am one of the users with the
most experience, so I watch them and as soon as issues arise I'll try to help
debug and pinpoint the issue or even solve it.

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.

------
notacoward
The author definitely seems to be assuming that every project fits a single
profile - small enough to have only a single maintainer, simple enough that a
non-specialized programmer can navigate it or create a patch easily, etc. If
turning off issues works for people like that, good for them. But this kind of
thing really grates.

"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.

------
ReligiousFlames
This is arrogant and misguided.

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?

~~~
yjftsjthsd-h
Because I want to call my daughter once a week, and publish a Python module
that someone else might find useful (which does not mean I want to support
them).

~~~
Klathmon
Then put that you don't want to support this in the README and allow others to
support themselves if they wish via issues.

------
ProAm
This would stop a lot of important communications. Sure some repo's would
benefit but others would merely wither and die. Not everyone that uses open
source is a programmer or technically apt enough to put code into and editor
and submit a pull request.

~~~
derimagia
Even as a developer, an issue from anyone (even non-technical people) helps
people find out quickly if someone else is having the same issue you are with
something, even if it's not fixed.

~~~
ReligiousFlames
Yes. As a maintainer whom actually cares about feedback and usability, I care
that features developed apply to the real world and aren't imagined in an
utopian vacuum by own possibly insane biases. Social democracy, not
authoritarianism. If code isn't usable by other people in the real world, it's
just graffiti while waiting for Godot.

~~~
throwanem
As a maintainer who also cares about feedback and usability, but who doesn't
maintain any high-traffic projects, I can just about imagine how frustrating
and destructive of motivation it gets to see the same no-thought issues raised
over and over and over.

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.

~~~
BrailleHunting
Oops, hit logout on that throwaway account. Bye-bye, religious flame wars. ;)

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.

------
kodablah
I'd almost want to do the opposite and disable PRs, at least until discussion
has been had. I'll take discussion before code much more than code before
discussion. Heck, I'll oftentimes take pure discussion without any code added
over code before discussion.

English is easier than code; don't be the person that puts up barriers.

~~~
franciscop
Ah I think that highly depends on the situation. In some instances a code
example makes up for a thousand words, in some examples quite the opposite.
The problem is that random PR are often hundreds of lines changed instead of a
stub to start a conversation.

------
tzs
I predict that this will result in smart-ass pull requests that just take the
text that would have gone in an issue and puts it in a comment to the main
code file of the project.

------
mosselman
If you don't want to deal with feedback on your open source project, fine,
just state it in the README "We don't care about your issues unless you are a
developer who can contribute.", but don't try to veil this indifference with
some ill thought out excuses for why it is a best-practice to do so.

------
exception_e
I agree that "Pull Requests for Everything" is actually a good idea to
encourage programmers to be practical and provide value (I have a pretty
strong opinion here... fork, work, pull is always better than passively
entering in an issue).

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!

~~~
dasil003
It's also not good for technical people with limited time.

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.

~~~
exception_e
EDIT: I re-read your post a few times and understand what you mean (originally
thought you were directing name calling to _me_). Yes, it is important to be
flexible with these things and not operate in absolutes. It is very important
to be kind and human to others in open source.

Also, I learned what "help vampires" are. Neat.

------
gbrown_
The problem - and I use the word "problem" here _very_ loosely - is the ease
of access that GitHub provides. Even back in the heyday of mailing lists there
was noise to deal with, but nowhere near the amount maintainers on GitHub can
find themselves dealing with these days.

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.

------
graphememes
This is a very emotionally charged and drastic approach to open source. I am
not seeing the benefits of doing this, I can only see downsides:

    
    
      - 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?

------
StreakyCobra
As always, the best solution is probably in-between the two extremes, i.e.
keep issues open because they are useful for discussions and non-technical
people bug reports, but don't be afraid to close PR and issues [1] to avoid
the problems like burnout.

[1] [https://www.jeffgeerling.com/blog/2016/why-i-close-prs-
oss-p...](https://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-
maintainer-notes)

(edit: I know the link talks about PR, but for me it applies to issues asking
for features or weird bugs as well)

------
shadowfiend
It's hard to read the title here (or even the content) and not take it as a
categorical statement, but I think this is aimed at a very particular subset
of all open source: projects that have one or few maintainers, with relatively
little time to devote to maintenance, and that are primarily developer-facing
libraries.

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.

------
lacker
My preferred compromise would be if GitHub started sorting issues by "number
of upvotes" by default. (Upvotes aren't entirely a thing on GitHub issues, but
you can add a thumbs-up emoji which is pretty similar.) For some projects,
there is just far more desire for free help than there are people available to
help for free. In these cases it is still useful to discover issues that
enormous numbers of people have, even if you won't have the bandwidth to deal
with a large fraction of them.

------
franciscop
This seems to be solving a problem that most of us would like to have, so it
indeed comes out as arrogant. However look at it from another point of view.
Imagine you are working on your job and a manager comes every 30-60 min to
your desk to ask you a question about your project, often silly and already
answered, breaking all your workflow (guesstimate about the email frequency
for popular projects).

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.

------
tehabe
I'm not a programmer, and when I tried to learn it I understood the concept
but actually programming something is difficult for me. No idea why this is.

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.

------
mrmondo
Issues are very important, how you handle them is more important and that
includes acknowledging the difference between discussion / decision making and
bug or feature implementation.

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.

------
_e
We track issues by monitoring log files so we can quickly get to the root of
the problem. Do you want your developers spending time writing issues on
github/trello/etc. or actually coding? You should let the DevOps help the
developers do what they are best at.

You get what you pay for when you use open source. You are either paying for
it in time and or cash.

------
botskonet
For most projects, this is nothing more than an even higher barrier for users.

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.

------
smoyer
The problem with this is that it forces anyone who finds an issue into
investing the time to understand the code-base. I'm assuming this developer
uses other OSS libraries and I wonder how many of these projects he
contributes PRs to if he finds an issue. If you're going to play this way you
need to make sure you're not a hypocrite about it (I would have looked but the
author didn't actually link to Michael Jackson's project).

It's obviously much more efficient for a few experts to understand each OSS
library.

------
seattle_spring
I think it's kind of ironic that the author focuses on pull requests. I say
this because me and 2 other people created pull requests for a repository
fairly widely used, one created by the author. The pull requests were opened
in early April and haven't been acknowledged or responded to.

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.

------
aaronbrethorst
Many open source libraries that I end up using have terrible documentation,
and borderline meaningless commit messages. Issues are one of the only places
I can go to find any sort of useful explanation or backstory on how a
particular part of a library should work.

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.

------
jaimehrubiks
I don't buy it. Issues are great for users and mantainers in many manyways. I
agree that it may be frustrating when you don't want to be a support center
for users, but then you should just ignore those.

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/](https://guides.github.com/features/issues/)

------
skybrian
I think the problem is that most people (both users and developers) mistake an
issue tracker for a world-writable TODO list. If something goes wrong, it
imposes an obligation that someone fix it.

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.)

------
jontro
Please add a [2016] tag. I think issue templates solved a lot of frustration
with github issues

~~~
dang
Added.

------
nebabyte
What a weird opening sentence. Unless he was planning on making a Michael
Jackson joke (quick skim ~ none?) or just wanted to call attention to the
"fun" point that he has a friend named Michael Jackson, I don't see why it
wouldn't be more prudent to just open with "My friend Michael..." rather than
appearing to set up a Checkov's gun with no payoff (even if just a quick
"(heh)" after the name).

(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)

------
qudat
This article is from the perspective of the maintainer, but what about the
potential contributor?

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.

~~~
Etheryte
If it isn't worth your time to look at the codebase before doing something,
why should it be worth the maintainer's time to look at your issue?

------
sergiotapia
I can see this working if your project's target audience is developers. But
for most projects where the target audience is just regular users, most vastly
prefer a simple CRUD form to create an issue.

Checkout some of the issue I have in my repo:
[https://github.com/sergiotapia/magnetissimo](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.

------
ansible
As someone who ends up using other people's code more than fixing other
people's code, I try to be sensitive to the issue.

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.

------
haney
> Think you found a bug? Fork the repo, add a failing test

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.

------
rpdillon
It's better to simply leave issues enabled, but put in place rules for what
constitutes a valid issue, noting that other issues will be closed without
further consideration. Well-reported issues are gold, and the others are easy
to ignore.

------
vatotemking
His problem can easily be fixed by adding a FAQ and Guide to Contributing and
Opening Issues doc.

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.

------
dewiz
Perhaps make it easier to attach a failing test, running through the CI
process and reporting the result inline? And perhaps allow to vote an issue
quality, i.e. demote badly written ones?

------
chriswarbo
I get the sentiment, but bug reports are distinct from test cases. Better to
track the bugs inside the repo, e.g. using something like bugseverywhere or
artemis.

------
alistproducer2
So the only people able to report bugs should be contributors? Do whatever you
want, I guess, but this sounds like a good way to have a very buggy project.

------
dragonwriter
For some projects, this makes some sense. For many, it does not.

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.

------
draw_down
Making code public does not imply support. Of any kind. Those are very, very
different things.

