22 ms·

Turning Off GitHub Issues (2016)

160 points by jashkenas 9y ago

ProAm 9y ago
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.
- haney 9y ago
  For this, I've seen several large projects push discussions to discourse or stack overflow, which are much better-suited mediums for discussion IMHO.
  - Matt3o12_ 9y ago
    I do not like to have discussions in chat because of how unstructured they are. Important details get lost and can never be hard to recover. Furthermore github comments are an excellent place for seeing different aspects and workarounds for an issue that has not been fixed. They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way). 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.
    - yjftsjthsd-h 9y ago
      > They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way). Is this not literally the point of comments in the code?
    - riking 9y ago
      Who said anything about chat? Parent was talking about https://discourse.org https://discourse.org which has effort put into archival / finding old discussions
- derimagia 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        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.
haney 9y ago
> 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.
BugsJustFindMe 9y ago
> 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.
- blazespin 9y ago
  You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. 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."
  - BugsJustFindMe 9y ago
    > You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. 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.
    - 9y ago
gkoberger 9y ago
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 9y ago
  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.
tzs 9y ago
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.
ReligiousFlames 9y ago
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 9y ago
  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 9y ago
    Then put that you don't want to support this in the README and allow others to support themselves if they wish via issues.
exception_e 9y ago
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 9y ago
  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 9y ago
    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.
dmethvin 9y ago
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.
- ReligiousFlames 9y ago
  How can we mentor the next gen of code craftsmen/women if we disengage and unplug the phone?
- bowlich 9y ago
  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 9y ago
    > 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?
StreakyCobra 9y ago
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-project-maintainer-notes 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)
BinaryIdiot 9y ago
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.
- creepydata 9y ago
  >You can even find issues, even MAJOR issues without understanding the code at all. Yep, even if you are a kindergartener. https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-security-bug-81686748317.html https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
- franciscop 9y ago
  "That should go in an issue." => Why? Does it apply for everyone? 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? 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.
wildpeaks 9y ago
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 9y ago
  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.
mrmondo 9y ago
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.
lacker 9y ago
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.
qudat 9y ago
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 9y ago
  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?
seattle_spring 9y ago
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.
chipotle_coyote 9y ago
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 9y ago
  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.
  - davezatch 9y ago
    That's nice when possible, but of course when something breaks you never know if it will be one hour or 30, and even then, I think there are a lot of cases where "let the developer know there's an issue" is still worth it, especially if the alternative is "drop it and say nothing because it's too much of a hassle."
kodablah 9y ago
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 9y ago
  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.
alistproducer2 9y ago
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.
dewiz 9y ago
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?
dewiz 9y ago
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?
jontro 9y ago
Please add a [2016] tag. I think issue templates solved a lot of frustration with github issues
- dang 9y ago
  Added.
botskonet 9y ago
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.
tehabe 9y ago
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.
_e 9y ago
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.
shadowfiend 9y ago
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.
franciscop 9y ago
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.
dragonwriter 9y ago
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.
skybrian 9y ago
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.)
graphememes 9y ago
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?
smoyer 9y ago
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.
notacoward 9y ago
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.
sergiotapia 9y ago
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.
aaronbrethorst 9y ago
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.
mrout 9y ago
>This isn't a rigorous statistic, but I'm pretty sure these are 99% of the issues on Github. Total rubbish
rpdillon 9y ago
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.
chriswarbo 9y ago
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.
nebabyte 9y ago
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)
vatotemking 9y ago
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.
draw_down 9y ago
Making code public does not imply support. Of any kind. Those are very, very different things.
mosselman 9y ago
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.
gbrown_ 9y ago
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.
jaimehrubiks 9y ago
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/
ansible 9y ago
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.

160 points by jashkenas 9y ago

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.

haney 9y ago
For this, I've seen several large projects push discussions to discourse or stack overflow, which are much better-suited mediums for discussion IMHO.
- Matt3o12_ 9y ago
  I do not like to have discussions in chat because of how unstructured they are. Important details get lost and can never be hard to recover. Furthermore github comments are an excellent place for seeing different aspects and workarounds for an issue that has not been fixed. They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way). 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.
  - yjftsjthsd-h 9y ago
    > They also often show inner structures of the program that can be hard to gasp from the code itself (why x has been done this way instead of that way). Is this not literally the point of comments in the code?
  - riking 9y ago
    Who said anything about chat? Parent was talking about https://discourse.org https://discourse.org which has effort put into archival / finding old discussions
derimagia 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.

haney 9y ago

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

BugsJustFindMe 9y ago

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

blazespin 9y ago
You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. 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."
- BugsJustFindMe 9y ago
  > You're being sarcastic, right? This is OS. It's fundamental underpinning is that if you want to use it (or at least engage its maintainers), you have to care. 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.
  - 9y ago

gkoberger 9y ago

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 9y ago
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.

tzs 9y ago

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.

ReligiousFlames 9y ago

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 9y ago
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 9y ago
  Then put that you don't want to support this in the README and allow others to support themselves if they wish via issues.

exception_e 9y ago

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 9y ago
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 9y ago
  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.

dmethvin 9y ago

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.

ReligiousFlames 9y ago
How can we mentor the next gen of code craftsmen/women if we disengage and unplug the phone?
bowlich 9y ago
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 9y ago
  > 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?

StreakyCobra 9y ago

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-project-maintainer-notes 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)

BinaryIdiot 9y ago

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.

creepydata 9y ago
>You can even find issues, even MAJOR issues without understanding the code at all. Yep, even if you are a kindergartener. https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-security-bug-81686748317.html https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
franciscop 9y ago
"That should go in an issue." => Why? Does it apply for everyone? 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? 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.

wildpeaks 9y ago

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 9y ago
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.

mrmondo 9y ago

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.

lacker 9y ago

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.

qudat 9y ago

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 9y ago
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?

seattle_spring 9y ago

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.

chipotle_coyote 9y ago

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 9y ago
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.
- davezatch 9y ago
  That's nice when possible, but of course when something breaks you never know if it will be one hour or 30, and even then, I think there are a lot of cases where "let the developer know there's an issue" is still worth it, especially if the alternative is "drop it and say nothing because it's too much of a hassle."

kodablah 9y ago

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 9y ago
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.

alistproducer2 9y ago

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.

dewiz 9y ago

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?

dewiz 9y ago

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?

jontro 9y ago

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

dang 9y ago
Added.

botskonet 9y ago

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.

tehabe 9y ago

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.

_e 9y ago

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.

shadowfiend 9y ago

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.

franciscop 9y ago

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.

dragonwriter 9y ago

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.

skybrian 9y ago

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

graphememes 9y ago

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?

smoyer 9y ago

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.

notacoward 9y ago

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.

sergiotapia 9y ago

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.

aaronbrethorst 9y ago

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.

mrout 9y ago

>This isn't a rigorous statistic, but I'm pretty sure these are 99% of the issues on Github. Total rubbish

rpdillon 9y ago

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.

chriswarbo 9y ago

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.

nebabyte 9y ago

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)

vatotemking 9y ago

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.

draw_down 9y ago

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

mosselman 9y ago

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.

gbrown_ 9y ago

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.

jaimehrubiks 9y ago

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/

ansible 9y ago

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.