Dear GitHub - <AUTHOR> https://github.com/dear-github/dear-github <comment><USER3> Hi Adam, Addy, Andreas, Ariya, Forbes, James, Henry, John-David, Juriy , Ken, Nicholas, Pascal, Sam, Sindre,

My name is Jono and I started as Director of Community back in November at GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in.

Firstly, thanks for your feedback. I think it is essential that GitHub always has a good sense of not just what works well for our users, but also where the pain points are. Constructive criticism is an important of doing great work. I appreciate how specific and detailed you were in your feedback. Getting a good sense of specific problems provides a more fruitful beginning to a conversation than "it suxx0rs", so I appreciate that.

I am still figuring out how GitHub fits together as an organization but I am happy to take a look into these issues and ensure they are considered in how future work is planned. We have a growing product team at GitHub that I know is passionate about solving the major pain points that rub up against our users. Obviously I can't make any firm commitments as I am not on the product team, but I can ensure the right eyeballs are on this. I also want to explore with my colleagues how we can be a little clearer about future feature and development plans to see if we can reduce some ambiguity.

As I say, I am pretty new, so I am still getting the lay of the land, but feel free to reach out to me personally if you have any further questions or concerns about this or any other issue. I am at firstname.lastname@example.com.

<comment><USER4> An open question is how the community should provide feedback. Trello provides a decent example of how to do it well [1], but GitHub feels like a black box. I've been on GitHub since 2008 and I have been paying every month for years, but other than emailing support I have no idea how to vote for a feature request.

My personal pet peeve is not being able to mark a public repo as 'deprecated'. There are a lot of other people with the same frustration [2], but we have no idea how to get that on GitHub's roadmap.

[1] [http://help.trello.com/article/724-submitting-feature- reques...](http://help.trello.com/article/724-submitting-feature-requests-for- trello) [2] [https://github.com/isaacs/github/issues/144](https://github.com/isaacs/github/issues/144)

<comment><USER5> I normally put a big "[DEPRECATED]" notice at the beginning of the README. This normally doesn't go unnoticed.

Another good example is harthur's "[UNMAINTAINED]" [1]

[1] [https://github.com/harthur/brain](https://github.com/harthur/brain)

<comment><USER6> > I normally put a big "[DEPRECATED]" notice at the beginning of the README.

Aye. Some folks in the discussion linked to by krschultz complain that "People sometimes don't read the README and -thus- don't notice deprecation warnings.". To them I ask: "What makes you think that those sorts of people will notice anything less than an overlay that _prevents_ them from interacting with the Github UI for that particular repo?".

<comment><USER7> One concern would be around tools that fetch from github automatically. go get for example would need some sort of structured metadata if it wanted to surface an error to a user that a library is deprecated.

<comment><USER6> > One concern would be around tools that fetch from github automatically.

Sure. But... like... git doesn't know _anything_ about deprecated repos. AFAIK, that's not a feature of git's repo fetch machinery. Anything Github would do to address this would _have_ to modify the contents of the repo, right?

> ...go get for example would need some sort of structured metadata [to do > reasonable repo deprecation warnings]

I mean, the JavaScript development community has -collectively- decided on a _huge_ bundle of ad-hoc standards. I bet that it would be trivial for the signatories of the open letter to decide on a tagging mechanism to use in their README files to indicate repo deprecation. Do you disagree?

<comment><USER7> Go get does not start with a git clone. If you go get example.org/pkg/foo go fetches [https://example.org/pkg/foo?go-get=1](https://example.org/pkg/foo?go- get=1). So coordination between go and github could implement something for deprecated repositories without changing anything in git.

More details here: [https://golang.org/cmd/go/#hdr- Remote_import_paths](https://golang.org/cmd/go/#hdr-Remote_import_paths)

<comment><USER6> > Go get does not start with a git clone.

Fair enough. (I don't use go, so I'm unaware of pretty much _all_ of its internals.) [0]

> ...coordination between go and github could implement something for > deprecated repositories without changing anything in git.

A couple of things:

* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.

* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)

* Frankly, having a well-known file _in_ your Git repo that contains meaningful tags seems _far_ more compatible than changing git, or altering the $BUILD_TOOL<->GitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)

[0] Thanks for the documentation link, BTW! :D

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> This, I feel, is the most important bug, even though it precedes the list:

> _We've gone through the only support channel that you have given us either > to receive an empty response or even no response at all. We have no > visibility into what has happened with our requests, or whether GitHub is > working on them._

I'd like to call out that the GitHub user @isaacs maintains an _unofficial_ repository[1] where the issues are "Issues for GitHub". It's not much more than a token of goodwill from a user to open a place like that to organize bugs (GitHub: you are lucky you have such a userbase!), but it's the best thing I know of for "has someone else thought of this?"[2]. Many of the issues that have been filed there are excellent ideas.

[1]: [https://github.com/isaacs/github](https://github.com/isaacs/github)

[2]: though I'd say if you also think about it, you should _also_ go through the official channel, even if just to spam them so they know people want that feature.

</comment><comment><USER9> The author mentions that if GitHub was open source, they would implement these features themselves.

Gitlab[1] is an open source repository manager that supports local installs as well as public hosting at gitlab.com. If author appreciates open source, perhaps they should put their efforts into improving an existing open source option rather than relying on a proprietary solution.

[1] [https://gitlab.com/gitlab-org/gitlab- ce/tree/master](https://gitlab.com/gitlab-org/gitlab-ce/tree/master)

<comment><USER10> This. When you are tired of github, start using gitlab, and realize your mistake going forward and stop making it, over[1], and over[2], and over[3].

[1] [http://sourceforge.net/](http://sourceforge.net/)

[2] [https://code.google.com/](https://code.google.com/)

[3] [https://bitbucket.org/](https://bitbucket.org/)

<comment><USER11> Sourceforge runs Apache Allura, which is open source.

<comment><USER12> What's realistic timing for getting a feature you contribute (and receive approval) deployed and available for use?

<comment><USER13> The length of the merge request cycle depends on the complexity of the feature. Simple fixes get merged in days, average features take weeks and sometimes the review suggestions take multiple months to implement. After merge it will release in weeks so since we're on a monthly rel cycle.

</comment></comment></comment></comment></comment><comment><USER14> It's 2016, and GitHub is stagnant.

GitHub used to bill itself as "Social Coding", but the "Network" graph has not seen _ANY_ updates since its original introduction in April of _2008_. Issues has seen _very_ few updates. Even the OSS projects that GitHub uses _internally_ have grown stagnant as GitHub runs on private, internal forks and maintainership passes to non-GitHub-employed individuals (e.g. [https://github.com/resque/resque/issues/1372](https://github.com/resque/resque/issues/1372)).

The word "Social" no longer appears on GitHub's landing page. They're chasing some other goal...whatever it is.

<comment><USER15> > They're chasing some other goal...whatever it is.

I've been puzzled for a while with what github is doing hiring so many social impact employees.

[https://twitter.com/agelender](https://twitter.com/agelender)

[https://twitter.com/_danilo](https://twitter.com/_danilo)

[https://twitter.com/rachelmyers](https://twitter.com/rachelmyers)

[https://twitter.com/nmsanchez](https://twitter.com/nmsanchez)

[https://twitter.com/BiancaCreating](https://twitter.com/BiancaCreating)

[https://twitter.com/ammeep](https://twitter.com/ammeep)

[https://twitter.com/davystevenson](https://twitter.com/davystevenson)

Maybe something more noble than a social coding site?

<comment><USER16>
      Maybe something more noble than a social coding site?

I doubt it. Github has a reputation problem. I wouldn't put anything sensitive on there, given the attitude github leadership showed about privacy ethics in the Julie Horvath incident.

<comment><USER17> Even if you don't have anything against Github relating to the Horvath incident, there are other things like Github shutting down people's projects because they wrote a doc containing the word "retard." In other words, now they are in the business of regulating the _content_ of open source projects (beyond obvious precautions like not hosting stolen credit card databases, child porn, etc.)

They seem to think they're too big to fail.

<comment><USER18> They also removed [0] C Plus Equality [1] project twice. Even Bitbucket [2] and Google [3] also removed it.

[0] - [https://github.com/FeministSoftwareFoundation/C-plus- Equalit...](https://github.com/FeministSoftwareFoundation/C-plus-Equality)

[1] - [https://github.com/ErisBlastar/cplusequality](https://github.com/ErisBlastar/cplusequality)

[2] - [https://bitbucket.org/FeministSoftwareFoundation/c-plus- equa...](https://bitbucket.org/FeministSoftwareFoundation/c-plus-equality/)

[3] - [https://code.google.com/p/c-plus- equality/](https://code.google.com/p/c-plus-equality/)

<comment><USER19> What was the story behind this anyway? I am having a hard time determining whether this was actually serious or were trying to parody feminist activism.

<comment><USER20> It was a joke by 4chan's technology board, made to see if people would take it seriously (some did and even agreed with it!).

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> We need world class, modern, distributed bug tracking now. If you google around for this technology, a lot of nice ideas, many using git itself as transport, were poking around, and around 2009 they started falling silent. Why? Because GitHub started up and everyone just buzzed over to it like so many moths to a flame, having learned nothing from places like Sourceforge about what happens when 90% of the open source world trusts their issue trackers, which is really a huge part of a project's documentation, to a for- profit, closed source platform that does not provide very good interoperability.

If GitHub is kicking back and sitting on their huge valuations, then it's time to pick up this work again. If issue tracking and code reviews were based on a common, distributed system like git itself, then all these companies could compete evenly for features and UX on top of such a system, without ever having the advantage of "locking in" its users with extremely high migration costs.

<comment><USER22> > We need world class, modern, distributed bug tracking now.

Why distributed? You need a central place to report bugs and track them to ensure they're not duplicated everywhere.

<comment><USER23> I am not Michael Bayer (but I hope to be more like him someday)... that said, what I think he means or could mean is that issues would be distributed along with the repo. Maybe something like a git log for issues that are attached to and/or part of the repo itself.

Thinking about it, something like this would be sweet. I would immediately have a snap shot of things that might go boom when I run said software. eta: Instead, I have to go dig through github itself, which is slow compared to greping through a git log.

<comment><USER24> You've described Fossil.

[http://fossil-scm.org/index.html/doc/trunk/www/index.wiki](http://fossil- scm.org/index.html/doc/trunk/www/index.wiki)

<comment><USER21> yes, fossil, you need to get me past this:

[http://fossil- scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...](http://fossil- scm.org/index.html/dir?ci=acbee54e8ba8a3bd&name=src)

I'm talking about a portable issue tracker format that ideally uses something like git as its transport (but note: this does __not __mean that the issue database would travel along with the application 's source code! That might be nice as an option but not by design). command-line and web-based front ends can then refer to it. Fossil, OTOH, looks like a huge monolithic web application / version control system / issue tracker / kitchen sink written in very hard-coded C.

Looking through some docs, Fossil is anti-git and it claims its own DVCS is a great improvement over git: [http://fossil- scm.org/index.html/doc/trunk/www/quotes.wiki](http://fossil- scm.org/index.html/doc/trunk/www/quotes.wiki). Because Fossil has every possible feature packed all into one monolithic executable, rather than relying upon existing systems like diff, patch, etc. this means Fossil is "the opposite of bloat": [http://fossil- scm.org/index.html/doc/trunk/www/qandc.wiki](http://fossil- scm.org/index.html/doc/trunk/www/qandc.wiki) (in fact that is the opposite of the opposite of bloat....)

</comment></comment></comment></comment></comment><comment><USER23> I do not operate a popular OSS project, but I have experienced the +1 spam and it sucks. The suggestions, in my opinion seem rational.

Interesting side note: With the exception of Selenium, most of signees are maintainers of JS/HTML OSS projects. I wonder if we could objectively compare JS to <lang> projects in terms of the problems mentioned in the document. For example, there is a strong correlation between +1'ers and JS repos vs. Python or vice versa. Perhaps, we could walk away with JS devs are more chatty than CPP developers when discussing issues... I don't know, just a thought.

<comment><USER25> I think it's just monkey see->monkey do. As soon as one person said +1, everyone that saw it thought that that's just how you voted for stuff. It's the same reason you see comments on HN or reddit that just say "This." or that if you leave your shoes by the door, everyone else will do the same. I doubt these people keep doing it if you ask them not to.

<comment><USER26> There's an old story about this man who stood quietly next to a closed door in Moscow, said nothing to no one, and did nothing else of interest. Eventually others joined him, and before long a queue has formed. No one knew what they were standing in line for.

Monkey see - monkey do.

<comment> semi-extrinsic One of Milgram's experiments (not the infamous one) tested this, using people standing on the sidewalk looking up.

[https://youtu.be/P0e6zG8IbE8](https://youtu.be/P0e6zG8IbE8)

<comment><USER27> He might think he's testing conformance, but he actually just tested curiosity.

<comment><USER28> Wouldn't they at least ask after a while if that was the case?

<comment><USER27> What makes you think they didn't? I saw lots of people look up, check the people around them and keep going.

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> This first request is the anti-thesis of GitHub's simple approach:

>Issues are often filed missing crucial information like reproduction steps or version tested. We'd like issues to gain custom fields, along with a mechanism (such as a mandatory issue template, perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.

Every checkbox, text-field and dropdown you add to a page adds cognitive overhead to the process and GitHub has historically taken a pretty solid stance against this.

From "How GitHub uses GitHub to Build GitHub"[1]: [http://i.imgur.com/1yJx8CG.png](http://i.imgur.com/1yJx8CG.png)

There are tools like Jira and Bugzilla for people who prefer this style of issue management. I hope GitHub resists the temptation to add whatever people ask of them.

[1] [http://zachholman.com/talk/how-github-uses-github-to- build-g...](http://zachholman.com/talk/how-github-uses-github-to-build- github/)

<comment><USER30> _> adds cognitive overhead to the process _

Yes! The maintainers _deliberately want_ to add cognitive overhead so the quality bar for creating issues is higher.

By having simple zero-friction forms, you haven't removed cognitive overhead. You've simply _shifted_ the cognitive load into the followup messages asking for clarification of "reproduction steps", "version tested". The issues' threads therefore begin with "meta" type questions which _duplicate_ the checkboxes and dropdowns you were trying to avoid.

The default can remain zero-friction but it seems very reasonable to offer options for maintainers to gain some control over their inbox.

<comment><USER31> So use a real issue tracker. Most of the big ones integrate with github. Why should they reinvent this wheel?

<comment><USER32> If not to be a hosted software lifecycle tool, what the hell is Github even for?

<comment><USER31> "Software lifecycle tool" is too vague for a product to have focus and open to too many interpretations as to what it should include. Even limiting scope to issue tracking, there are different points of view on how that should work and several widely-used but rather different software alternatives to choose from.

And how many teams spend the first three months of a project building a custom issue tracker because they don't like any of the off-the-shelf options? Trying to get issue-tracking "right" is a black hole for a company like github. Which is probably why they provide the bare minimum free-form issue and that's it.

</comment></comment></comment></comment></comment><comment><USER30> The bullet points of complaints feel like a continuation of Linus Torvald's refusal of github pull requests in May 2012.[1]

Taken all together, it seems like github is on a path of alienating their most valuable members. Github was unresponsive to Linus' feature requests and it turns out that theme continues almost 3 years later.

If github plans to evolve into a full-featured ALM[2] like MS Team Foundation or JIRA instead of being relegated to being just a "dumb" disk backup node for repositories, they have to get these UI workflow issues fixed.

[1][https://github.com/torvalds/linux/pull/17#issuecomment-56546...](https://github.com/torvalds/linux/pull/17#issuecomment-5654674)

[2][https://en.wikipedia.org/wiki/Application_lifecycle_manageme...](https://en.wikipedia.org/wiki/Application_lifecycle_management)

<comment><USER33> I don't see anything wrong with going after the massive amount of smaller project with simple needs, instead of the few large projects & popular projects with very specific needs.

If github evolves to the projects you're mentioning, you'll surely alienate the many more casual users. I personally hate working with the bloated applications you mention.

</comment></comment><comment><USER34> Distributed revision control users whining about centralized repository lacking features.

Ummm ... anybody getting the irony here?

And, from a GitHub business perspective, why do I hear Lily Tomlin: "We don't care. We don't have to."

Everybody anointed GitHub as "the chosen one" over strenuous objections from some of us that creating another monopoly for open source projects is a _bad idea_.

Pardon me for enjoying some Schadenfreude now that GitHub leveraged the open- source adoption into corporate contracts and now doesn't have to give two shits about open source folks.

Lily Tomlin's Phone Company Sketch: [https://www.youtube.com/watch?v=CHgUN_95UAw](https://www.youtube.com/watch?v=CHgUN_95UAw)

<comment><USER35> I'm an open source project maintainer and share many of the pain points outlined in the document, but I also totally agree with you. Giving control of your project to a company means losing control and having to resort to desperate pleas like this. This is simply what happens when you can't fork it yourself like you could with an open source project.

It's likely that GitHub will alleviate these pain points in time, but the lesson is the same: let a company control your destiny and you can no longer have what you want or need when their interests diverge from yours, even if their system is the best there is and was radically better than everything else at the time you switched to it.

</comment></comment><comment><USER36> There's been no mention of phabricator yet so I thought I'd give it a shout out. It's used by LLVM, FreeBSD, Blender, Wikimedia and others and I love it. It's under very active development and even if it doesn't solve every issue in this letter, by using an open source tool for development you of course have the option to customize it to the needs of your community.

<comment><USER21> I'm looking very closely at Phabricator, it looks quite nice.

</comment></comment><comment><USER37> Is this a case of the squeakiest wheels getting the grease? What if these problems aren't representative of the overall user base? What if far more people prefer a more simple, minimalistic interface than an ultra- customizeable interface with myriad custom actions and events. I've always appreciated software that deliberately keeps things simple (Basecamp and Workflowly come to mind). It sounds like these people want a full blown Jira/Stash installation.

</comment><comment><USER38> I don't like the general feel of these suggestions. It sounds like more bureaucratic features, the lack of which is a big part of why GitHub is so pleasant.

Making an issue or a pull request feels like having a casual chat with the project maintainers. Adding fields and other hoops to jump through puts distance between people.

<comment><USER39> I guess for maintainers of popular projects, everybody's "casual chat" (by people who did not read CONTRIBUTING.txt, do not supply the version of relevant software they are using etc.) is not as fun as it is for you.

</comment></comment><comment><USER40> Wow, what a bunch of whiners. If you hate github so much why don't you just fork it and fix-- Oh, right. It's not open source.

Well, there's your problem right there.

(I have sooooo much more in this vein but I'll spare you. ;-)

EDIT: No I won't. Fuck it. This is too ridiculous.

These guys (and they are all guys) chained themselves to github's metaphorical car and now they're complaining that the ride is too bumpy and the wind is a little much.

Don't whine about not getting to sit inside the car! Unchain yourself and go catch one of the cars where the doors are unlocked and open and the driver and other passengers are beckoning you to join them. (Apologies for the mangled metaphor.)

These folks come off to me like masochistic babies.

<comment><USER41> +1

Shouldn't we (the OSS community) have an open source, roll-your-own version of something like GitHub? Like, the repo-management equivalent to a phpBB or a Wiki or a Wordpress.

We do have the separate components, though maybe the hard part is to glue them together. But still, it is something what would be worth the time and effort, wouldn't it?

</comment></comment><comment><USER42> I do like Github, and I understand how it makes the entire process of maintaining a code repo a lot easier, but what I'd genuinely like to know is why don't big projects just move to their own thing? I understand that there isn't a single solution that exactly matches what Github has, and that maintaining your own git server + git management/issues/etc.. app is a pain, but I see it as the only real solution. Developing in the open can't be done on platforms where restrictions apply, and they do apply. I'm saying this with no intention of sounding like a jerk, but 18 project maintainers and/or developer need to write an open letter to get Github to give'em a "me too" button? I understand the issue, but i still find it rather silly.

The only aspect I could think of where Github has the pro is the community of developers it has, but does it really matter that much? Especially for established/big projects that probably don't care about the fork/stars numbers, or the random look around-ers that pass by.

<comment><USER43> > I understand that there isn't a single solution that exactly matches what > Github has, and that maintaining your own git server + git > management/issues/etc.. app is a pain

You outlined exactly why people don't build their own or use another system. Github is the best there is. That doesn't mean it doesn't have problems, but if your company/project/expertise isn't focused in collaborative development and/or version control, you're just distracting yourself by building your own.

The authors are not saying "we can build a better Github." They have complaints and would like them resolved, but don't see a good way of having that happen.

<comment><USER42> > Github is the best there is.

Doesn't matter really as it's still a locked platform. The argument they're making is that they're developing in the open and they'd like some sort of expedited treatment because of the size of the project or because they're doing OSS. I don't think those two can go hand in hand all the way.

</comment></comment></comment><comment><USER44> I feel like there is a great opportunity right now for anyone to make a Github replacement. Sounds like a lot of these features are sorely needed at the moment. Why has Github been complacent?

<comment><USER45> By their very nature, git repos are one of the easiest things to migrate. Simply point at a new remote and push, and that's really it. It means that, unlike many other services, I could see GitHub being completely abandoned almost over night. If something better came along.

<comment><USER46> You would lose the issues.

<comment><USER47> True, but thanks to the API and their relatively simple structure it's reasonably easy to at least copy their contents as well. Linking them correctly to user accounts on a new platform is probably the biggest issue.

<comment><USER48> Users with public SSH keys would be easy: [https://github.com/JohnMaguire.keys](https://github.com/JohnMaguire.keys)

When a new user signs up, ask them for their existing Github username and to upload an SSH key that matches.

</comment></comment></comment></comment></comment><comment><USER49> My company pays me to work on a fairly old-school free software project and we run our own git service. Our workflow is email based so we won't ever consider switching to GitHub.

That said, we do sometimes consider setting up an official mirror on GitHub. Ideology aside (some team members might think we shouldn't promote a propriety solution for free software project), the main thing that puts us off is that there is no way to disable pull requests. Closing all pull requests by hand is not appealing; leaving all pull requests open is not desirable. We can probably write a bot to close pull requests, but that is just yet another administrative burden.

Not sure if GitHub will ever consider allowing users to disable pull requests though. That seems to go against GitHub's core interest.

<comment><USER50> FreeBSD has worked out a means of accepting pull requests on their github mirror, guessing using the API.

<comment><USER49> I myself don't really see any motive of doing that. It is administrative burden (maintaining the service that bridge API and existing system, managing GitHub accounts / tokens). Compare that to the number / quality of pull requests received [0] [1] and I find RoI of doing that very low.

[0] [https://github.com/freebsd/freebsd/pulls](https://github.com/freebsd/freebsd/pulls) [1] [https://github.com/torvalds/linux/pulls](https://github.com/torvalds/linux/pulls)

</comment></comment></comment><comment><USER51> I work on a very relevant project called Product Pains.

React Native, the open source project, is using Product Pains instead of GitHub issues for bug reports and feature requests. This is because there were thousands of open issues and, just as this document mentions, it's impossible to organize them. The comments are all "+1" and it's really hard to tell what's important and what's just noise.

If you take a look at [https://productpains.com/product/react- native?tab=top](https://productpains.com/product/react-native?tab=top) you'll see the power of being able to vote on these issues.

So why's Product Pains relevant?

1\. It's a temporary alternative to GitHub issues. I'm guessing GitHub will get to adding votes eventually. If you want to use Product Pains for organizing issues for your open source project, go for it. I'll even give it away to you for free.

2\. It's a community dedicated to improving products. This document is chock- full of great, constructive, actionable feedback. Product Pains is a community built for posting exactly this. You can post feedback publicly, about any product, people can vote on it, and posts with a lot of votes create a social responsibility for the company to respond.

3\. It's a way for your voice to be heard. Posting on Hacker News lasts a day and will get your voice heard. If you post actionable, constructive feedback on Product Pains, and 150 people vote on it, it lingers waiting for GitHub to do something about it. Around 600 users on Product Pains are also React Native developers. They'd probably be ecstatic to vote on constructive feedback for GitHub.

For example, go make an account and vote here: [https://productpains.com/post/github/implement-voting-for- is...](https://productpains.com/post/github/implement-voting-for-issues/)

</comment><comment><USER52> Bitbucket kills GitHub issues with these two features:

\- Multiple assignees for an issue \- An "Approve" button so that maintainers can stamp a PR with the seal of approval

<comment><USER53> Surprised I didn't see my personal favourite mentioned - the unlimited free private repos!

<comment><USER54> To be fair, GitHub has to make _money_.

None of the complaints are about the GitHub business model, which is IMO pretty fair.

<comment><USER53> True, I guess with Atlassian it's different as their actual flagship product is Jira (and I assume the people who buy the paid-for BB packages are loyal to BB due to things like the free repos so it evens itself out).

</comment></comment></comment></comment><comment><USER55> Yup, I love GH, use it every day, but issue management is the pits.

It'd be really nice if I could custom sort the queue of issues so that I know what's next up in my queue of things to do; right now I've got 5 tags called NextUp:1 -> NextUp:5 on each repo; this takes way more manual updating than a simple drag/drop widget.

Like they mentioned, having a voting system would be super useful for knowing what matters -- I cringe every time I leave a +1, so I've gotten into the habit of at least adding a comment after it --- but the premise and the pain are the same.

<comment><USER56> We created ZenHub - [https://www.zenhub.io/](https://www.zenhub.io/) \- specifically to solve these problems.

The addition of a task board in the GitHub interface allows you to communicate both the priority and progress of GitHub issues.

While adding a +1 button to comments allows feedback without clutter.

Best of all, it is free for Open Source :)

You can read more on why we created ZenHub here - [https://medium.com/axiom- zen/introducing-zenhub-2-0-c352a12c...](https://medium.com/axiom- zen/introducing-zenhub-2-0-c352a12c2ec2#.qd71ypvkl) and get in touch with us via our public support repo here - [https://github.com/zenhubio/support](https://github.com/zenhubio/support)

I hope we can help improve your GitHub experience!

</comment></comment><comment><USER57> A shame that GitHub aren't more responsive to the community that enables their success when they make such a big deal of their openness. It is also our own fault that we have allowed ourselves to become dependent on a single provider of a relatively simple service.

That said, I'm extremely grateful to the platform for enabling collaboration on open source and to the company for its work on Git, Resque etc.

GitHub's strategy is to open source everything except the business critical stuff, but it seems to me that their business is in enterprise support rather than in actual software. Perhaps they should just open source the whole platform and count on their service business being enough to carry the company?

</comment><comment><USER58> I like GitHub issues as they are. I wouldn't like to force people to adhere to a particular format when reporting problems.

I find it strange that some project maintainers get annoyed when people use the issues section to post questions. What's wrong with that? A question can reveal design failures about your software... Maybe if your software was better designed, people wouldn't be asking the question to begin with.

I do think there should be a +1/like button though.

<comment><USER59> Have you ever tried to maintain a popular OS project on Github? Github issues feel great until you start using them at scale, and then they start to fall apart without some structure. This is especially pronounced in open source where many issues come from people who aren't familiar with what information you need in an issue to quickly resolve it.

I don't think the authors are requesting that this be made mandatory for all repos, but instead they just want the option to set up rules for repos they maintain. As someone giving up their free time to offer software for the rest of us, it seems only fair to let them set the rules about what they need before they can resolve an issue.

The biggest issue I see OSS maintainers running into is that they likely aren't the voice that Github listens to most anymore. If they can get some companies that pay for Github Enterprise to sign their letter as well that would likely help prioritize these features.

<comment><USER58> My project's main repo has 150 issues (only 7 still open) and it works out pretty well. Usually contributors will answer each other's questions and help close issues.

I suppose that could be a problem if you have 7000+ issues (as is the case for Docker) - But those projects represent an extremely small percentage of all OSS projects on GitHub. Also, these projects usually have a lot of contributors, so maybe those contributors could help filter through and tag/close issues as necessary?

</comment></comment></comment><comment><USER60> I have mixed feelings about these requests. Yes it would be nice to have these extra features in GitHub. Its issue handling has always been a bit light on the workflow side—but IMHO has made up for it with a pleasant way to organize conversation around issues. The simple and smooth UX is part of what makes GitHub so great.

For the opposite side of the spectrum, there's the Bitbucket+Jira combo. It is customizable to a PM's heart's content, and in the process can become a mess of a tool.

<comment><USER61> I have mixed feelings about custom fields, I'd like Github UI to become as burden as Jira, but in the other hand 'reactions' as Slack or Facebook are implementing would make much easier to follow a discussion without so much scroll down.

</comment></comment><comment><USER62> After the whole incident where they deleted forks of a project without notice, due to their belief on what is and is not appropriate words to use in code without an apology I think we really need to re-assess GitHub in general.

Their 'control' of code and lack of respect to the people running projects is very disappointing and they seem to not want to move forward on the issues.

I'm surprised the open community is allowing this de-facto ownership of the worlds code and how it's written to take place, I'm not so sure they are a benevolent dictator.

[https://www.techdirt.com/articles/20150802/20330431831/githu...](https://www.techdirt.com/articles/20150802/20330431831/github- nukes-repository-over-use-word-retard.shtml)

</comment><comment><USER63> Interesting petition, and I agree with it; but I wonder why are all projects mentioned in the _Signed by_ section based on JavaScript? I know there are other languages involved in some of those projects like C++ and Java in Selenium and PhantomJS but this specific thing in the document makes me believe that only JavaScript developers _(at least the ones using GitHub)_ are more prone to complain than other type of developers.

<comment><USER20> It's simple: This was made by a JS developer who shared it on Twitter and whose followers/community friends are more likely to be JS developers.

</comment></comment><comment><USER64> The problem is that GitHub has a monopoly and is considered _the_ current standard for Open Source. But I think that once some of the major projects move to alternatives like GitLab (which has many of the features described in that letter) GitHub will have to obey its user base. Unfortunately no Open Source project with a large user base will dare to do the first step.

<comment><USER13> There are some open source projects with a large user base taking the step to us, for example [https://gitlab.com/mailman/mailman](https://gitlab.com/mailman/mailman)

Regarding the three demands in the doc:

1\. GitLab has issue templates in EE and on GitLab.com [https://gitlab.com/gitlab-org/gitlab- ee/merge_requests/28](https://gitlab.com/gitlab-org/gitlab- ee/merge_requests/28)

2\. GitLab has the award emoji function that doesn't spam and acts as a voting system [https://about.gitlab.com/2015/11/22/gitlab-8-2-released/](https://about.gitlab.com/2015/11/22/gitlab-8-2-released/)

3\. We're open to displaying CONTRIBUTING.md more prominently, please open an issue on our public issue tracker that contains all our planned features [https://gitlab.com/gitlab-org/gitlab-ce/issues](https://gitlab.com/gitlab- org/gitlab-ce/issues)

I'll go sleep now but please ask any questions so I can respond tomorrow.

<comment><USER64> Yes, I already saw some of these.

Unfortunately, there's no Travis CI integration yet, which I've been using on GitHub a lot.

I'm evaluating GitLab CI right now. Am I right, that I have to host a runner myself if I don't want to use a shared runner for my project?

> You can setup as many runners as you need. Runners can be placed on separate > users, servers, and even on your local machine.

Does "local machine" really mean a non-public machine like my notebook?

Appreciating help from GitLab's CEO :)

<comment><USER13> We would love for Travis CI to offer support for GitLab, they can use our new commit status API.

But you'll find that GitLab CI is a pretty complete replacement. If you don't want to use a shared runner you indeed have to use a shared runner.

Running on your local machine can indeed include your notebook.

<comment><USER64> Thanks for the answer.

<comment><USER13> Welcome. I see an error in my answer. If you don't want to use a shared runner you indeed have to add one yourself. Please be informed that shared runners can run Docker images and that we plan to add runner auto scaling with 8.4 to reduce the queue.

</comment></comment></comment></comment></comment></comment><comment><USER65> Github needs two major features: 1. discussion groups for users vs. devs as people use issues for it currently. and 2. A searchable "license" attribute for all projects with standard license templates for MIT/Apache/GPL/etc... When looking for a source code, you need to consider the platform, language and license.

</comment><comment><USER66> "It's the world's tiniest open source violin"

[https://xkcd.com/743/](https://xkcd.com/743/)

</comment><comment><USER67> Each and every suggestion is a sane and much needed improvement.

<comment><USER68> Especially the +1

<comment><USER69> +1. Fix this.

<comment><USER70> me too

</comment></comment></comment></comment><comment><USER71> At Sourcegraph, we're trying to help solve these problems for developers everywhere ([https://sourcegraph.com](https://sourcegraph.com)), both in open source and inside companies. GitHub's commercial success and contributions to the world of development are impressive (and I'm speaking as a GitHub user for 8 years), but they can't build _everything_ developers need on their own.

We're really pumped about improving dev team collaboration in the GitHub ecosystem by (soon) letting anyone use Sourcegraph.com's code intelligence (semantic search/browsing), improved pull requests, flexible issue tracking with Emoji reactions instead of +1s (example: [https://src.sourcegraph.com/sourcegraph/.tracker/151](https://src.sourcegraph.com/sourcegraph/.tracker/151)), etc.—all on their existing GitHub.com repositories.

All of Sourcegraph's source code is public and hackable at [https://src.sourcegraph.com/sourcegraph](https://src.sourcegraph.com/sourcegraph), so it can grow over time to solve the changing needs of these projects. (It's licensed as Fair Source ([https://fair.io](https://fair.io)), not closed source like GitHub or open source.)

Email me (firstname.lastname@example.com) if you're interested in beta-testing this on your GitHub.com repositories.

<comment><USER61> I think reactions as implemented in Facebook, Slack or Sourcegraph is a really neat UX solution for the +1 spam problem.

</comment></comment><comment><USER72> My biggest gripe with GitHub has been the notification system. Personally I can't use the web UI for notifications because they bundle multiple notifications per issue. This leads to potentially missed notifications since it is up to me to scan the issue/PR for new comments.

My workaround has been to use email notifications exclusively. I have a Gmail filter that applies a label to all notifications and skips the inbox. Then in my mail client I have a smart mailbox that only shows me unread notifications with that label (or that folder, from an IMAP perspective). The smart mailbox then shows me a counter of unread notifications. This way I don't oversee comments when multiple ones are made in a PR.

Problem 1: No context in these notifications. It would be nice if these emails could show the code in question for diff comments or the entire comments thread.

Problem 2: Now what is really bad with these notification emails is that the link "view it on GitHub" sometimes no longer links to the comment I'm being notified of. This happens when the comment was made on a PR on a line of the diff that no longer exists, as sometimes is the case when new commits are pushed. I then have to go to the main PR page, expand all collapsed "foo commented on an outdated diff" comments and manually search for the comment in order to get the context and be able to reply.

By fixing problem 1, problem 2 would be automatically fixed with it and make my workflow much more productive. Is there anyone else annoyed by this?

<comment><USER73> > Personally I can't use the web UI for notifications because they bundle > multiple notifications per issue. This leads to potentially missed > notifications since it is up to me to scan the issue/PR for new comments.

I think the bundling aspect is an awesome feature! I can read multiple new comments all at once, with context in mind and less total context switches.

About being able to miss new comments - doesn't the link in the notifications UI take you directly to the first unread comment?

</comment></comment><comment><USER74> I just created and maintain a little Android library (a very rewarding experience by the way) so most of the complaints about Github doesnt really apply to me because the size and reach of my project (I understand the point perfectly though).

But I read some complaints about the users and the issues they tend to open and I fully agree. They are a minority but I can't only imagine what people with bigger projects have to deal with. This is what I've found:

\- People with little to zero experience in the language/framework that simply state that my project doesn't work without providing more information and sometimes they didn't reply to my "give me more info" inquiries.

\- Guys who just want to get their homework done and They are basically trying to get it done using me as non-paid freelance.

\- And my favourite one, junior dev in a company, he needs to get their work done with more pressure than the previous one so became anxious about their problems and I feel it even via email. Eventually He gets the thing done but He notices I changed the build system to Jitpack for better dependency handling and and start to complain about Man in the middle attacks to his company and black-hat hackers replacing my lib with a malicious one (I guess it could happen but come on).

But it is a very rewarding experience besides these anecdotical cases

<comment><USER75> Hi. your junior colleague might be interested in the security answer here [https://jitpack.io/docs/FAQ/](https://jitpack.io/docs/FAQ/). It's an important matter so will be happy to answer any more questions via email/gitter.

You can also run JitPack on-premises and have full control over build artifacts.

<comment><USER74> Fortunately not my junior colleague! just a junior dev using my lib in his company's project. Thank you for the FAQ. I will forward it to him

</comment></comment></comment><comment><USER76> All this problems seem to me like _good_ problems to have.

They all seem to stem from the fact that _github is too successful_. And too many people are on github and too many people are using it, often in wrong ways.

Of course github should solve them all. But still, it's still better to have problems with too many people and too much interest, than have the opposite problem - dying platform that people are leaving (see: sourceforge and Google Code).

<comment><USER64> It's not a good problem for the Open Source community after all.

</comment></comment><comment><USER77> Look at kallithea SCM at [http://kallithea-scm.org/](http://kallithea- scm.org/), we have used it and in most cases it works well. Also it supports both git and mercurial. Python should learn a lesson when they decided to move their repository to closed source system like github. But obviously as people use Facebook, developers use github for the same reason, network effect.

</comment><comment><USER78> A lot of these points are fair and interesting, but I fail to grab some of the points, especially that one:

      Ability to block users from an organization.

What does blocking users mean? Blocking from commenting/making PR/cloning?

Why blocking a whole organization from an _open source_ project? What would prevent such users to use a personal account instead to do what they organization counterpart is blocked from anyways?

<comment><USER79> A more plausible interpretation would be that a particular GitHub organization might wish to block the inputs of a particular user across all its projects. That is, the phrase "from an organization" is adverbial and clarifies "block" rather than "users".

<comment><USER78> You're probably right! I don't use organization accounts so I'm not sure what was the issue, it would be to prevent haters to troll on every project of a particular company?

<comment><USER79> Yes that would make sense to me, but keep in mind that any user may create an "organization", so this might just be a bunch of repos associated with e.g. a particular framework rather a particular company.

</comment></comment></comment></comment><comment> some-guy I work at a large company with a central GitHub Enterprise instance, and we use GitHub as a code-reviewing and code-hosting platform. Everything else (including build-automation) is integrated through web-hooks to Atlassian tools for many of the reasons noted in this letter. It works for us, but I am hopeful that GitHub will listen and maybe someday we can have everything on there.

</comment><comment><USER80> I actually disagree with some of these suggestions, I find the simplicity of Github issues is what makes it so great. I think this should be solved with 3rd party tools, such as waffle.io

</comment><comment><USER81> While I don't maintain Ansible anymore, +9 billion on this. GitHub is hard at scale.

GitHub is fantastic because everyone is on it, but the issue system has not improved since inception - and I felt the UI changes have actually stepped back.

We had to implement our own bot to comment on tickets that did not appear to follow a template, and I would have given a kingdom for a template that let people filter their own tickets into whether they were bugs or feature requests or doc items.

We also had a repo of common replies we copy and pasted manually (this because there was so much traffic and me replying quickly would likely tick someone off - but this too could have been eliminated mostly with a good template system). Having this built-in (maybe I could have picked a web extension) would have also been helpful.

So many hours lost that could have been features or bugfixes - and by many, I mean totally weeks, if not cumulative months.

GitHub does the world a great service, and I love it, but this would help tons.

I always got a response when I filed a ticket - ALWAYS - but a lot of them were in the "we'll take that under consideration" type vein.

I feel opening GitHub RFEs up to votes is probably not the answer to serve the maintainer side of the equation, since users outnumber maintainers, but these needs to be done and would greatly improve OSS just based on expediting velocity.

If you don't use the GitHub tracker you lose out on a lot of useful tickets. However, if you use it, you are pretty much using the most unsophisticated tracker out there.

It's good because there's a low barrier to entry, but just having a template system - a very very very basic one, would do wonders.

A final idea is that GitHub really should have a mailing list or discussion system. Google Groups sucks for moderation, and I _THINK_ you could probably make something awesome. Think about how Trac and the Wiki were integrated, for instance, and how you could automatically hyperlink between threads and tickets. The reason I say this is often GitHub creates a "throw code at project" methodology, which is bound to upset both contributor and maintainer - when often a "how should I do this" discussion first saves work. Yet joining a Google Group is a lot of commitment for people, and they probably don't want the email. Something to think about, perhaps.

Also think about StackOverflow. It's kind of a wasteland of questions, but if there was a users-helping-users type area, it would reduce tickets that were not really bugs, but really requests for help. These take time to triage, and "please instead ask over here and join this list" causes people pain.

I love all the work to keep up site reliability, maybe I'd appreciate more/better analytics, but I totally say this wearing a GitHub octocat shirt at the moment.

</comment><comment><USER82> I could rant for hours about all the things GitHub doesn't do (or does wrong) for "real" software development.

+1 from the Kubernetes project

</comment><comment><USER83> I wish Github would add a "Discussions" tab for repos, so projects don't need to create a separate Google Group (which require a Google account!) for questions-that-are-not-quite-issues.

</comment><comment><USER84> There are three groups within GitHub, and this article is about the issues faced by the first - big open source projects (a small number).

The main bread and butter of GitHub is from private or organizational projects and do not have these issues

The majority of accounts on GitHub are folks like the majority of HN readers - developers, coders, hackers and do not have these issues.

So all these complaints are in a sense not applicable to the vast majority of both GitHubs revenue generating customers and the vast majority of GitHub users.

</comment><comment><USER85> While I like to bitch and moan about stuff myself, I don't really agree with the first point.

What I like about GitHub's issue tracking is that (compared with alternatives, such as Redmine or Jira) it is free form. It doesn't force users to fill information such as steps to reproduce and I don't think it should. And that's because the needs of every project is slightly different. Consider how different the "steps to reproduce" are for a web user interface, versus the usage of some library. Yes, it can be painful for an issue to not provide all the information required, but on the other hand GitHub does a better job than alternatives at fostering conversations and keeping people in the loop. I've even seen projects use the GitHub issues as some sort of mailing list.

On the second point, I do agree that GitHub needs a voting system for issues. Given that GitHub has long turned into some sort of social network, adding a voting system for issues is a no-brainer. But then a voting system doesn't address the problem of people getting frustrated about issues taking too long to get fixed. +1's are annoying, but sometimes that's a feature and I've been on both sides of the barricade.

</comment><comment><USER86> Do the undersigned send any money to github? It might be better to phrase your demand in the form of a question, "how much can we pay you to do this work for us?"

<comment><USER57> GitHub's success is based on its community. Simple fairness says the community should be respected and listened to, simple business says if the community doesn't get something back, it will get pissed and go somewhere else.

<comment><USER87> Again... No thought of how all this gets paid for?

<comment><USER57> By GitHub obviously. Improving their platform to maintain their momentum as a community hub is pretty much a no-brainer as far as I'm concerned.

</comment></comment></comment></comment><comment><USER88> Is there an issue tracking system out there that works on top of the Github issue system?

<comment><USER89> We would love your thoughts on ZenHub.io [1] - fully integrated issue tracking, +1, estimates, burndown charts, kanban boards, even a personal todo list - a lot of the features asked for here, right within the GitHub interface and presented a lot more cleanly than competing products.

Disclosure: I work on ZenHub :)

[1] [https://www.zenhub.io](https://www.zenhub.io)

<comment><USER88> Looks nice. How do I add additional organizations after the first one? Can I send an invite to other organization managers to make themselves available for ZenHub?

Thanks!

<comment><USER90> Each organization is treated separately, all you need to do is install the extension and visit a repo of the other org. From there you'll start a 2 week trial and you'll be able to invite your team members and managers :)

</comment></comment></comment></comment><comment><USER91> +1 to the notification spam. Being @sam on github sucks sometimes. And as far as I can figure out there's no way to set watching/following/notifications to opt-in only.

So every time someone who knows a "Sam" uses @sam incorrectly in an issue I get notified, have to unsubscribe, ignore, and leave a polite message to let them know they're doing it wrong.

It's really lame that they've never fixed this.

</comment><comment><USER92> Most of this stuff seems pretty common sense and reasonable. I really only have a couple of objections:

* Issue templating.

It's one thing to prefill the entry box, it's quite another to add fields that everyone must fill out. I quite like that filling out something on Github is totally the opposite of filling out something on Jira.

* Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines

This is a people problem that has plagued open source from day one. You cannot engineer your way around it in a manner that doesn't annoy your contributors.

There was a blurb in here about getting rid of the big green "new pull request" button, but that was when this link went to a google doc. Good - <USER2> someone doesn't want to take PR's, then they have almost no reason to be on Github in the first place. Put another way, it's the mark of someone that wants a repo as a signpost of sorts without actually interacting with its community.

</comment><comment><USER93> I think if these people have that many issues with GitHub, they should find a replacement. That's what happened in the Node community and it led to a better Node. That's a big list of complaints and GitHub doesn't have much incentive to fix 'em except to silence a bunch of cry babies that are bitching about a free tool.

</comment><comment><USER94> I've felt the same way. The worst bit is notifications, so I get a notification that someone replied to an issue I opened. How do I get there? It's not in my notification page, I have to go to the email and click the link from there. Things get missed.

GitHub needs to step it up. They got to the top first, but can they stay there?

</comment><comment><USER95> What I don't get ... why do people building free software even consider forcing their users and in particular their contributors to use proprietary development tools such as github? (Or, for that matter, exclude people from contributing to their projects who only use free software.)

Next, we'll see public complaints to Microsoft because MS Word doesn't properly support the way they want to maintain their project's documentation?

I mean, sure, feel free to complain all you like, but how is this not exactly what was to be expected from the beginning, and why do you expect them to care in the future, given that you just seem to have realized that they didn't care in the past, for obvious reasons, and given that their incentives haven't changed, and there is no reason for them to change in the future?

</comment><comment><USER96> Many times, I've asked GitHub to add icons for :test:, :doc:, :admin: and a couple others. I use them in commit messages as it helps categorize the type of commit. This has to be the easiest kind of improvement imaginable, but they have never bothered.

</comment><comment><USER97> I know they've only recently released new permissions for organisations, but they're still extremely lacking. As far as I can see, there's no way of setting permissions at a group level.

As an example of how this would be used, we have a Github team within our organisation which is used for non-technical people to post bugs. These people have no reason to be able to see or push code to the repository, they only need to be able to create issues. This applies to every repository in the organisation. As far as I can see, and without manually adding every single repository to the team, there's no way of setting global permissions permissions for a team. This seems like a major oversight to me.

<comment><USER80> I just create a single repo for all issues, cross repo, and manage it with waffle.io. Works well for me, but ymmv

</comment></comment><comment><USER98> I suspect they are focusing on developing their enterprise offering.

Anyway, I found that [http://feathub.com/](http://feathub.com/) addressed my frustration about the absence of a voting system.

</comment><comment><USER99> I would just love if they could add target _blank on all the links in comments and issues. I'm constantly navigating away from the issue to view links in question and then realizing the tab with the issue is gone.

</comment><comment><USER100> My experience with Github support is terrible, if not one of the worst, I once had an issue and contacted their support and it took them 1 month to respond to me (literally) I was really surprised by that.

<comment> daniel-levin I had the opposite experience. I am on the free student plan for private repos. It has to be renewed annually. It wasn't clear to my how to do so. I asked, and Scott from Github support contacted me in under a minute and sorted it out. I was very impressed.

</comment></comment><comment><USER101> It's also annoying that Github sometimes is missing some basic features like attachments to bug reports and comments for instsance. All mature bug trackers have such feature.

</comment><comment><USER102> Why do you want GitHub to solve the (very) specific problems of issue and defect tracking?

They make a facility available as a nicety, but if your project has legitimate Global impact, you should be looking at (or bootstrapping) a counterpart.

Don't have the revenue for JIRA? Apply for the Free license.

Don't have the stomach for Bugzilla? Turn out a Node/Go alternative.

Don't have the business alignment with Clearquest or Rally? Lower your expectations to suit your Free (as in beer) SCM tool.

</comment><comment><USER103> There's a lot of great feature requests for issues at the bottom of the document. Not sure why the document highlights only 3 things above the signatures.

Yet, I 100% agree with them. I do not understand why Github issues are so basic. The only feature I feel was added in all of 2015 was making the logging of every metadata change extremely verbose (read: maybe too noisy now?!).

"Person assigned to the issue"

"Person added label"

"Person removed label"

</comment><comment><USER104> I personally experiencing this issue. i wrote about this in 2014, you can check here [http://paritosh.passion8.co.in/post/96619506751/dear- github-...](http://paritosh.passion8.co.in/post/96619506751/dear-github-its- time-to-put-karma-in-user) although i am addressing the problem in different way but the issue is same.

</comment><comment><USER105>
         Don't make it so easy to submit bad PRs

I recurrently refer to this[0] PR, and the subsequent discussion, as the reason why, if any project of mine gets any bigger - it will not be accepting Github pull requests.

[0] [https://github.com/technion/maia_mailguard/pull/42](https://github.com/technion/maia_mailguard/pull/42)

<comment><USER106> Haha what a crazy final exchange.

> uh oh, someone is still sulking [...] We really don't care about the drama

Oh, okay buddy.

</comment></comment><comment><USER17> GitHub also does not allow deletion of bullshit issues.

</comment><comment><USER107> I get that these are super frustrating issues for these people ( _cough_ guys) that maintain these repos, but there's something telling about it that it's all JS people. That last cute lil paragraph really sums it up for me:

> Hopefully none of these are a surprise to you as we've told you them before. > We've waited years now for progress on any of them. If GitHub were open > source itself, we would be implementing these things ourselves as a > community—we're very good at that!

LOL. I can't tell if this is "go-fuck-yourself"-level passive aggression, or mindless hopefulness that there might actually be a universe in which Github (or a company like it, with hundreds of millions of dollars of venture funding) could be open source. If I worked at Github, my first thought after reading this would be "mmmmm yeeeeaaaaaaa y'can g'fuck yr'self", while the second thought would be "yea, you're not wrong". Generally, passive aggression gets you nowhere when you're asking for something from someone/something who owes you nothing (I know, I know, they "owe" their customers _everything_ ).

The Node/React/JS community is hilariously entitled, petulant and childish. The tone of this whole letter is so god damned millennial, it's mind-boggling, because they're not wrong about anything they're asking for. But it's _how_ they ask for it that leaves a dry, acid-y taste in your mouth.

<comment><USER108> Interestingly most of these people are older than the millennial category

<comment><USER107> Fooled me ;)

</comment></comment></comment><comment><USER109> People often ask why WordPress doesn't use Github for its primary development (they do have official read-only mirrors there), and it's not just because they already had an SVN-based system in place when Github came to be. It's because the tooling they already had was more sophisticated, especially regarding issues.

</comment><comment><USER110>
        We'd like issues to gain a first-class voting system,
        and for content-less comments like "+1" or ":+1:" or
        "me too" to trigger a warning and instructions on how
        to use the voting mechanism.

Why bother users with a warning? Turn it into a vote, and then highlight the vote icon so you can see what happened.

</comment><comment><USER111> A proposal for a better way to deal with github issues: a discussion tab. [https://github.com/dear-github/dear- github/issues/44](https://github.com/dear-github/dear-github/issues/44)

</comment><comment><USER112> I'd settle for just a fix to the (minor) data-loss bug that I reported nearly a year ago, and which still crops up once a month or so.

That, and something for code review. Pull Requests are terrible for code review, and it wouldn't take that much to make them so much better.

<comment><USER113> I got frustrated waiting for improved PR code review, so I built [https://reviewable.io](https://reviewable.io). It's best suited for private repos (since there's a learning curve that make throw off potential open source contributors) but it addresses a lot of the issues with PRs. Take a look!

<comment><USER112> I've actually looked at Reviewable multiple times for use within our team, but never decided to use it. From my usage of the demo, it feels complicated. There are a lot of controls on the screen, and I struggle to tell what exactly I'm looking at at any given time.

I also tried the demo, and was shocked to see that Reviewable had edited our PR descriptions to include a big "Review on Reviewable" badge. We currently make heavy use of PR descriptions in quite specific formats, and it felt like Reviewable was forcing itself upon us.

To be clear, I'm really glad someone is looking at this problem, and Reviewable looks like a step in the right direction. I'm just quite opinionated on code review and developer tools, and I feel like it could be much better.

<comment><USER113> Thanks for checking out Reviewable, and sorry it didn't work out for you. It's definitely a more complex tool than plain PRs but you also get a lot more functionality in return.

If you checked it out before I added the interactive onboarding (aka butterflies) and on-demand help you might want to try (yet) again, since I've been told it makes it a lot more approachable. Otherwise, and if you have the time, I'd love to sit down with you (virtually or otherwise) to do a short user study so I can better understand the UX pain points and maybe fix them.

As for the badge, it's actually mostly there to help developers find their way to the review. In public repos, it's also the marketing payment for the otherwise free service, but in private repos I can switch it off for you (the flag doesn't have a UI yet).

I'm always looking to improve Reviewable, but in the end it's unabashedly opinionated too, and sometimes those opinions will clash -- I'm OK with that. I'd rather make a tool that some people will love than an enterprise monster that everyone will love to hate. :)

</comment></comment></comment></comment><comment><USER114> One annoying issue I found with github is that it doesn't provide a discussion board. a lot of times, I have a question to ask, it doesn't mean I found a bug or anything needs progress tracking, but I have to go through the "github issues".

</comment><comment><USER115> To what degree a company has to not give a f$#% when maintainers of largest projects on a platform can't get any feedback (compounded by a fact that some of those maintainers are very prominent employees of largest github paying customers)

</comment><comment><USER116> Being a maintainer on a project with some minor community on GitHub is such a garbage experience.

It's pretty neat as a general user, but at least you get the impression with BitBucket that they prioritize productivity and project management. And the task system hasn't received any significant updates since their inception - which is a shame, because tasks are an awesome invention, they just have to be implemented awfully with issues.

I also remember that we recently had to move the entire decision-making process to Slack instead where I suggested we just use the emoji voting system to make our decisions with.

What really gets to me is how _adamantly_ GitHub has ignored all the people who've gone on about this forever. Last time they seemed to care marginally was when jacobian finally managed to twist their arm and get them to implement the Close Issue feature, because one repo issue was a radioactive pit of abuse and invective.

<comment><USER81> I wonder if the whole "managerless culture" is to blame and is unfixable? (In other words, why hasn't SOMEONE had this thought about issues in N years? One is they deem it not a problem, another could be that they think to optimize for the filer, and the maintainer doesn't matter, or... there's no organization at all?)

There could be (theoretically) no one to make anyone do anything, and perhaps the issue tracker is either a quagmire of a codebase or something no one wants to touch because something else is more exciting?

That's one theory.

My other theory is they spend a lot of time on scaling problems and/or GitHub enterprise (which I haven't seen) -- and don't really do features anymore.

But it does feel there is no vision for changes to GitHub (maybe they think it's "solved") and it's ceasing to evolve in noticeable ways in any direction.

Can't really be sure. But I find it interesting. Again, the core is good. It's just curious to watch it so closely and not see the needle moving in any perceptible way.

<comment><USER116> I like the theory of the flat-office culture or philosophy affecting this.

Then again, it could be the kind of anarchic Libertarian or laissez-faire bent that we see with reddit that makes it exceedingly different to grant special permissions and privileges, especially across subreddits/issues/users/orgs. Or maybe user experience just doesn't matter for today's start-ups; maybe we've passed the Overton window for start-ups deciding it's not worth caring about their users.

A lot of the time, I feel like more of a user+ than a(n) (super)admin on my own repos. I might as well have the permissions and tools to ruin my own project - in the name of pure unadulterated freedom if for no other reason.

The dashboard and notification system have always been POS, too, so it might just be that everything that basically isn't tethered to a GUI is on the bottom of the totem pole.

</comment></comment></comment><comment><USER117> GitHub does certain things very well, other - not so much. I really think the best way to get them to focus is to start contributing massively to GitLab.

Anyway, implementing just voting won't be a such a good idea in the time of Emoji Reactions!

<comment><USER118> Actually, GitLab counts some emojis as votes - so you can have your :cake: and eat it too ;-)

\- [https://about.gitlab.com/2015/11/22/gitlab-8-2-released/](https://about.gitlab.com/2015/11/22/gitlab-8-2-released/)

\- [https://github.com/gitlabhq/gitlabhq/pull/5724](https://github.com/gitlabhq/gitlabhq/pull/5724)

</comment></comment><comment><USER119> Issue spam (in the literal sense) definitely needs addressed as well: [https://pbs.twimg.com/media/CYI31g1UQAUXQbs.png](https://pbs.twimg.com/media/CYI31g1UQAUXQbs.png)

<comment><USER17> It's my project, why can't I just delete issues like any other bug tracker?

<comment><USER119> The issues were deleted in fairly short order, but their notifications were still sent out to all repository watchers and persisted beyond the issue deletion. Also, most issues were generated mere seconds apart from accounts less than a day old.

So the issue isn't that GitHub didn't let them clean up the issues after the fact, but that there were no a) rate limiting options, b) user reputation options, or c) issue submission filtering options.

Any one of those three would have reduced the impact significantly.

</comment></comment></comment><comment><USER5> This resonated so much with me

PS, it was moved to [https://github.com/dear-github/dear- github](https://github.com/dear-github/dear-github)

</comment><comment><USER79> Please update the link to [https://github.com/dear-github/dear- github](https://github.com/dear-github/dear-github)

<comment><USER120> Thanks, I've been trying all day to open the original link on mobile and it just brings my phone to its knees and never opens. Not even sure what is behind that link other than perhaps a very large Google doc?

</comment></comment><comment><USER121> Funny. It's like "Hi, you are rich. We like you. You should onate your money".

There are tradeoffs, so pick services you like.

</comment><comment><USER122> I guess I don't know how to use githib. You can send bug reports on a project. But how do you send questions or ask for advice?

</comment><comment><USER123> Totally agree with what has been said. However, I find it interesting that most of the signatories displayed were for JS projects.

</comment><comment><USER124> gog.com has a great mechanic for this which might work here called a community wishlist [1] where people can submit games whey wish to see and people can vote on it and eventually they get things done when possible.

[1][http://www.gog.com/wishlist](http://www.gog.com/wishlist)

</comment><comment><USER125> I am interested in understanding how much recurring revenue Github is receiving for hosting these projects.

</comment><comment><USER126> I've never seen any issues spammed with +1s like the TravisCI request for Bitbucket support

</comment><comment><USER127> Can anyone post a précis/examples - apparently I do not have rights to see any spreadsheets at all.

</comment><comment><USER128> we maybe need a feature of hotness of a bug, "affects me too", that'll prioritize issues out of a bucket load of issues, plus on github you first raise an issue then it is sorted into feature request or bug, can be made better

</comment><comment><USER129> Classic JavaScripters reaction: throw more tooling at it

</comment><comment><USER130> Url changed from [https://docs.google.com/document/d/14X72QaDT9g6bnWr0lopDYida...](https://docs.google.com/document/d/14X72QaDT9g6bnWr0lopDYidajTSzMn8WrwsSLFSr- FU/preview?ts=5698049d), which points to this.

</comment><comment><USER131> NB: Duplicate post: [https://news.ycombinator.com/item?id=10904693](https://news.ycombinator.com/item?id=10904693)

<comment><USER130> Since they're both near the top we might as well treat the later post (which is the other one) as the duplicate.

<comment><USER54> The post with ~110 points was killed in favor of the ~50 point post at the time. In that case using time as the tie breaker might not be the best since people will have to upvote again.

<comment><USER130> In general you're right, but this story was guaranteed not to lack for upvotes. Indeed it went to #1 as soon as we buried the other one as a dupe.

I realize it's not a big deal, and it's actually a great sign about the HN community that almost no one cares much about karma. But we do want to try harder to give the original submitter credit, because then the incentive is aligned with what's best for the community: finding good stories that haven't been posted yet.

</comment></comment></comment></comment><comment><USER132> :+1:

<comment><USER133> ahahaha

</comment></comment><comment><USER134> Chris Wanstrocity is an inept leader, social activists roam the halls in self glory about their contributions to the world while Kakul spends money on retreats and hires senior product people who have zero open source or dev ops experience. This company needs intensive care with new leadership asap or they will be doomed, Gitlab is salivating right now.

</comment><comment><USER135> While I applaud the initiative, it's also a pretty strong indictment of the JavaScript / node.js community that there is not even a _single_ non-male OSS maintainer on this list of important JS projects.

What is being done in the JS community by those who lead it to make progress on this and who is leading that charge? If the answer is "Nobody", why is that true?

<comment><USER51> Why did this get downvoted? Ugh.

<comment><USER115> Hmm what does this have to do a) with topic b) with node.js?</comment></comment></comment>


Show HN: TribePulse – A brain for your remote team - <AUTHOR> https://www.tribepulse.com/ <comment><USER2> By description it looks like Twist[0] Not affiliated, just happy user

[https://twist.com/?lang=en](https://twist.com/?lang=en)

<comment><AUTHOR> TribePulse definitely shares similarities with Twist, especially around the choice to go with async communication. But whereas Twist focuses on communication and positions itself as a replacement for Slack, TribePulse doesn't seek to be a replacement for Slack and instead focuses more on surfacing key announcements (ensuring proper information dissemination in remote teams and companies), capturing longer-form, high-signal interactions (retaining institutional knowledge), and encouraging greater transparency in teams (announcements should be less like decrees and more like opportunities for discussion or feedback)

</comment></comment><comment><USER3> just sent an email. really hope we can get early access. As director of operations, i love all of your directives.

<comment><AUTHOR> Thank you! sent you a reply :)

</comment></comment><comment><USER4> i ve been seeing this startup doing the rounds in media. But what is it?

<comment><AUTHOR> Just out of curiosity, which media sources are you referring to?

One way to think about TribePulse would be a cross between an "internal blog" and "internal forum" for your company. In addition to some of the regular features you'd find in a blog or forum (we've tried to be selective here), we've also built in some additional features (e.g. tracking viewership, "surface and reply") that will make TribePulse highly effective for keeping remote teams in sync.</comment></comment>


Make it up as you go along - <AUTHOR> https://medium.com/thoughts-on-creativity/cae042ffb171 <comment><USER2> "It unlocked a part of my brain I didn't know I had". I've felt this way about games like D&D since I started playing in 8th grade. Yes they involve a game structure but the most fun I've ever had has been telling ridiculous collaborative stories.

It's imperative that we encourage creativity in kids. They're born with this amazing capacity to imagine incredible things, all we as parents have to do is manage not to kill that off. Telling stories together and playing games together are two of the best things.

<comment><USER3> The Steve Jackson game "Toon" is the best game to start kids around the age of 9 or 10. The first few chapters put the GM and the player through a very quick "boot camp" that gets a game circle up and running.

</comment></comment><comment><USER4> "Make it up as you go" may be fine for kids bedtime stories.... but when it's used in software development (which is often the case when "agile" is mis- implemented) it's a recipe for disaster. It ignores all the hard-learned lessons that history has proven about what does and doesn't work.

<comment><USER5> Indeed, I agree, although I'd argue that I do try to learn as much as possible from the experiences of others. I only very roughly covered what "make it up as you go along" might mean as far as agile is concerned, because so much has been written on the subject and I assumed some familiarity. Perhaps I could have emphasised that more!

</comment></comment><comment><USER6> Some times back, I stayed telling my kids a series of stories about a little old man. They were all of the cuff and spontaneous and I have the kids opportunities to suggest things in the narrative. The stories were always silly.

I think my kids probably have the best memories from those stories though. Imagination is a powerful thing to encourage in your children.

</comment><comment><USER7> My mother had "Yellow Jacket" stories which she would make up at bedtime. They always centered around fictional versions of us on a farm with work horses, Yellow Jacket being the name of the horse we would ride. I have tried doing the same for my kids, but I feel like my stories always end up really lame. Maybe I need to try again.

</comment><comment><USER8> Does anyone else ever have problems with Medium's pages not loading properly? I use Opera on both my phone and my tablet, which both run various versions of Android. I can see the picture splashed across the top of the page, but nothing else. It is very weird.

<comment><USER5> I saw a message when I went to write this post on Medium that it doesn't yet support mobile/tablets very well yet for writing, so they've disabled writing on those devices. I'm guessing there are similar issues with reading from time to time, then.</comment></comment>


How to Build a Discovery Feature for Course Platforms with PredictionIO - <AUTHOR> http://blog.prediction.io/build-discovery-feature-course-platforms-predictionio/#.Uji_7WAyWid.hackernews

<comment><AUTHOR> PredictionIO is an open source that you can download form github.</comment>


Readying Windows 8.1 for release - Suraj-Sun http://blogs.windows.com/windows/b/bloggingwindows/archive/2013/08/27/readying-windows-8-1-for-release.aspx

<comment><AUTHOR> What are they thinking? There are zero excuses not to release it early to MSDN/TechNet. There could be show stopper bugs that those folks can find.

Developer needs those builds the earliest as possible, not on the same day as the same day as the customers get it.</comment>


RockYou raises a $35 million round - <AUTHOR> http://news.cnet.com/8301-13577_3-9962923-36.html <comment><USER2> Google raised like $24 million, and that was 10 years ago. And, um, they actually needed tons of machines for what they were doing, so they actually could put millions of dollars to use.

This is just ridiculous.

Enjoy the silliness while it lasts, I guess.

</comment><comment><USER3> Wow $35 million for another round of useless FB apps.

<comment><USER4> my sentiments exactly jamongkad.

I think the key verbiage in the article is "and has done marketing campaigns for other companies like....."

If you write a great app then you wrote a great app and if you're lucky you might talk some funding source into paying or lending you $50k for it. If you hire a bunch of great marketing people and give them a crummy app they go out and get some funding source to fork out $35 million for some form of ownership right.

This fact of life has to be the greatest frustration there is in being an accomplished developer.

<comment><USER3> I mean $35 mil could have been easily distributed amongst the little startups that are actually doing something of value. But that's VC's for yah.</comment></comment></comment>


Software Defined Radio with HackRF - <AUTHOR> http://greatscottgadgets.com/sdr/

<comment><USER2> Anyone with one of these devices care to share their experiences? I've been looking for a way to get into SDR and DSP, but not sure if purchasing a HackRF would be a good first step considering its price tag ($300) and relative newness.

<comment><USER3> If you're looking for a good cheap kit to start out with, I suggest a cheap DVB-T card with a Realtek RTL2832U chip.

20 MHz - 2.2 GHz ~2.5 MS/s

Just google for RTLSDR.

You can get started for as little as 15-20 USD.

<comment><USER4> I second this, one of the links to a site selling the HackRF also sells a USB dongle. He explains in the first video that you will be able to do some of the lessons with this cheaper hardware. The welcome lesson about FM can definitely be done with a cheapo dongle.

[http://hackerwarehouse.com/product/dvb-t- usb2-0/](http://hackerwarehouse.com/product/dvb-t-usb2-0/)</comment></comment></comment>


Completely Silent Computer - <AUTHOR> https://tp69.blog/2018/04/17/completely-silent-computer/ <comment><USER2> Discussion from a couple of weeks ago - 489 comments.

[https://news.ycombinator.com/item?id=17075489](https://news.ycombinator.com/item?id=17075489)

Of course, if you want to add something new you can't do so there any more, so this is the place for new comments, ideas, thoughts, connections, _etc._</comment>


I'm Beating The NSA To The Punch By Spying On Myself - <AUTHOR> http://www.fastcolabs.com/3012908/tracking/im-beating-the-nsa-to-the-punch-by-spying-on-myself

<comment><USER2> Author here. Beating everyone here to the punch: yes, I know this is pretty basic. I'm new to data-mining. I will happily take suggestions about what else to look for and how to improve it. Also, if anyone wants to donate their own Google Voice data to improve the model, I'd love to see how accurate we can get on some classification (I'm thinking family or not family, but open to suggestions).

</comment><comment><USER3> I think the author's good intentions are taken a little bit too far here. As I understand it, it is claimed that the gender is "correct with 67% confidence", which I assume means "67% of all educated gender guesses are correct", with 50% standing for pure guesswork.

As is the case with any statistical data, a single value holds only very little information. The article does not do any analysis on how good these 67% are: could it be that changing the parameters changes it to 50%? There's a pretty large configuration space in question, and therefore I think giving out a simple number is very misleading.

What I also don't agree with is the conclusion, "Most importantly, if that's what I can do with a limited set of my own data, imagine what the NSA can do with the datasets it has access to." In the light of the previous paragraph, this draws the conclusion that the NSA can do pretty big things, but it's based on the wrong premise that the analysis of the "own data" has any statistical significance.

Note that I don't want to argue about the conclusion - data mining is very powerful, and so is statistics - but this kind of approach is _very_ easily abused, be it intentionally or unintentionally.

So, in short: be careful trusting statistics, even when you really really like the result.

<comment><USER4> Another problem is he doesn't include any sort of meaningful baseline. Maybe 67% of the people he talks to are male. In which case, he's not predicting anything. Just guessing randomly biased by his own calling habits.

[EDIT: I had some other criticisms that were incorrect and overly harsh anyway. I've removed them.]

<comment><USER2> Thanks for the feedback. As I'm fairly new to all of this, I'd love to hear how I can turn this into a more viable experiment.

Also, to defend myself a little: I think I'm at least being responsible by in no way claiming that it's statistically valid, and in fact making the point that it's not, and citing the reasons why, several times in the article.

I do stand by my point, however, that this helps the public understand the danger of metadata for data-mining, as well as introducing them to the pitfalls of statistics.

<comment><USER3> > As I'm fairly new to all of this, I'd love to hear how I can turn this into > a more viable experiment.

The most important thing is getting an estimate of how good your averages are. Try to modify a couple of things, for example how do the 67% change with sample size (verification)? How does the number turn out if you feed it biased data, e.g. only male phone numbers (falsification)?

<comment><USER2> Thanks. I solemnly swear to not abuse statistics, so I'll play around and update the piece.

The goal is to use this as a hook to get the public interested, then take them for the ride as I learn. That's why I tried to be really cautious about pointing out all the reasons why this particular model is bad.

<comment><USER3> I didn't mean to say you specifically were abusing statistics, it's just very easy to draw dubious conclusions. (Doing this intentionally would be the abuse I was talking about.)

<comment><USER2> I know, but I still want to take it seriously, and thank you for your criticism.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I think the basic flaw here is that author assumes that NSA does data-mining. I personally doubt it.

Rather (and here I'm going off on pure speculation myself) I think they can use the system to start with some off-line lead (say one of the Chechen bomber brothers) - and see who he was calling / emailing and then checking if there is anything valuable there.

Ie - how in the past FBI would do an investigation off-line and talk to people and piece things together - they are looking to be able to replicate it (possibly by going back in time) online.

<comment><USER2> "As part of K.D.D., an algorithm was applied to the broader data set in efforts to detect patterns of behavior fitting models that had been previously established as being indicative of the activities of a terrorist cell."

[http://m.vanityfair.com/online/eichenwald/2013/06/obama- veri...](http://m.vanityfair.com/online/eichenwald/2013/06/obama-verizon-cell- phone)

<comment><USER5> Thank you. But the next sentence reads " It is also run against a large set of what are known as "dirty numbers"—telephones linked to terrorists either through American signals intelligence or information provided by foreign services. Even the Libyans under Qaddafi turned over huge stacks of dirty numbers to us."

So that seems to correlate with what I am saying - they have some _flag_ generated offline that they use as a marker to find something online.

<comment><USER2> Oh, they definitely do both, I'm not disputing that.

</comment></comment></comment></comment><comment><USER6> I'd love to some of this myself but don't know Ruby.. I've used Google Voice since 2009 full time.

Anyone up for a Python Google Voice to csv script?</comment>


Keypress: A robust JavaScript library for capturing keyboard input - <AUTHOR> http://dmauro.github.io/Keypress/

<comment><USER2> A big problem I experience is the lack of web-safe keyboard shortcuts for complex web-apps. If looking for a safe key-combination, you have to consider the superset of OS and Browser combinations and that leaves almost nothing.

The gmail approach is for unmodified keys but that only works if you don't have focus in an editable field. The gdocs approach is for menu chords but that sucks for frequent actions and still generates weird dual handling of events by the browser.

I'd love a web/browser standards committee to preserve the universal utility of the keyboard. It could ring-fence some application specific shortcuts, give a semantic abstraction of some actions e.g. undo, and standardise mechanisms for os specific remappings.

As it is, as more tech comes along, the less usable keyboards become. I am still dumbfounded that the iPad lacks a tab button or any chord for one despite claiming to be usable for word-processing. This basically means no web-app can ever assume a keyboard has a tab key. Gah.

<comment><USER3> This is especially painful since sometimes browsers have different built-in shortcuts, and sometimes the in-browser shortcuts differ cross-platform.

Also, coming from Windows/Linux world, I was surprised how many physical keys are missing on a Mac keyboard.

</comment></comment><comment><USER4> Getting an error on that page in Chrome.

        Refused to execute script from 'https://rawgithub.com/dmauro/Keypress/master/keypress.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

EDIT: It's because Keypress is using rawgit.com instead of cdn.rawgit.com to host the actual keypress.js script.

Details here - [http://rawgit.com/dmauro/Keypress/master/keypress.js](http://rawgit.com/dmauro/Keypress/master/keypress.js)

Working script source - [http://cdn.rawgit.com/dmauro/Keypress/master/keypress.js](http://cdn.rawgit.com/dmauro/Keypress/master/keypress.js)

<comment><USER5> RawGit is refusing to send the page because you're not supposed to use it for production sites without using the cdn.rawgit.com link.

<comment><USER6> To be more precise: by looking at the response in Firebug's Net panel I see

Blacklisted for abuse

 This request has been blacklisted for sending too much traffic to rawgit.com. Please contact the owner of the site that sent you here and ask them to use cdn.rawgit.com instead, which has no traffic limit.

Nevertheless I wonder if this will work when Firefox's search as you type is enabled. I guess the browser should eat up all those events, but maybe I'm wrong. Can't check it because of the blacklisted script and no time to write my own test now.

<comment><USER7> Seems like they also deliver this with an HTTP 200 status. So Firefox actually tries to parse the error page as JavaScript.

</comment></comment></comment></comment><comment><USER8> Previous discussion [https://news.ycombinator.com/item?id=6464138](https://news.ycombinator.com/item?id=6464138)

        Keypress: A Javascript library for capturing input (dmauro.github.io)
        192 points by nsmalch 468 days ago | flag | cached | share | comments

<comment><USER9> I thought only one submission per url was possible

<comment><USER10> Per year, I think.

<comment><USER11> From the FAQ [1]:

"Are reposts ok?

If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok."

As with much of the HN system, that's intentionally vague, but in my interpretation, reposts can occur more frequently than once per year.

[1] [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)

</comment></comment></comment></comment><comment><USER12> An alternative is mouestrap: [http://craig.is/killing/mice](http://craig.is/killing/mice)

I've used it successfully in Marionette and Angular applications.

It is 29k unminified, vs 35k of keypress.js.

<comment><USER13> Plus one for Mousetrap. I have used it too...

Also, it has a better name. ;)

</comment></comment><comment><USER14> I'd like to see scoping added so it's possible to easily switch keyboard bindings based on the feature/context.

[https://github.com/madrobby/keymaster](https://github.com/madrobby/keymaster) does an OK job with this, and too bad it's not being actively maintained.

<comment><USER15> The first param of the constructor for the Listener is an element to be bound to so it will only listen for key events for that element.

</comment></comment><comment><USER16> More aimed at game developers, but for anyone who wants a super lightweight subset of this functionality.

[https://github.com/danprince/keystate](https://github.com/danprince/keystate)

</comment><comment><USER17> Now with Konami code!</comment>


Atom Split Into Two And Then Put Back Together Using Quantum Mechanics - <AUTHOR> http://planetsave.com/2012/06/05/atom-split-into-two-and-then-put-back-together-using-quantum-mechanics/

<comment><USER2> This is a really misleading article. What they're referring to is placing atoms (and molecules) into states of superposition where the state can be represented as 1/sqrt(2)|left> \+ 1/sqrt(2)|right>. This is an important first step towards quantum computers--being able to construct entangled systems of many q-bits, but this article is really quite poor in it's description. If you're really interested in this sort of stuff, I'd suggest reading Charles Seife's book entitled _Decoding the Universe_. It's about information theory and discusses quantum computing to a certain extent. I've also heard Seth Lloyd's book Programming the Universe is very good, but I have not read it.</comment>