GitHub, I You

But you've got some issues. And I want to help you fix them.

Ruby came from Japan. Lua came from Brazil. Python came from the Netherlands.

You have nearly 3,000,000 people using your service, and host meetups all over the world. Every major organization has the responsibility to provide easy entry to services for speakers of any language. Quite simply, you should localize the site. Because of his or her language, spoken or programming, no one should be denied to learn how to code, or use git, or share an idea.

Here's what GitHub Localized might look like:

Recently, you introduced support for providing guidelines for contributions. This lowers the barrier for pull requests, and also ensures that every new submission to a repo is consistent, clean, and at a high standard.

You should provide a way for organizations to manage their Contributor License Agreement. Too often, CLAs are handled by users "signing" and emailing PDFs to a repo organizer, who then adds their name to a spreadsheet. Contributors are harangued about whether "they've signed the CLA yet." Sometimes, submitters that send in a top-notch pull request drop off the face of the earth, leaving the code unmerged (and in a legal quagmire!).

Administrators of organizations should be visually notified within the pull request whether the submitter has signed a CLA. The user making the pull request should know that as part of the pull request process, they're abiding by the CLA.

I've complained about the old notification system before. The new update simplifies everything, and lets you keep track of every contribution made by other developers.

There's just one problem: any time you click on a notification, it's instantly marked as read, and tucked away into an "All notifications" black hole.

If I need to refer to a notification I already read, I can't find it easily. I can't search through my notifications. I can't tag my notifications the same way I can tag my issues. Heck, if an issue is tagged, and I'm being notified about it, the tags don't even show up in my Notifications Center.

Notifications should be more like email. If I click on a notification, it shouldn't disappear. It should go away when I tell it to — just like archiving it. If I want to sort my notifications by labels, let me do so. (Tangentially, documentation shouldn't only reside in blog posts!)

The Network Graph of forks is really awesome. It can be useful to see what other contributions developers have made to a code base. chjj's marked module, a JavaScript implementation of the GFM, is a good example of the usefulness of the Network Graph.

Let's say a user wants definition list support, similar to PHP Markdown Extra. But chjj doesn't want to implement that. That's completely fine; another user forks his project and implements the change. Others can then browse the forks and decide which feature they want and use those implementations. It's a wonderful example of open-source development.

There are just a few usability issues with the graphs, and managing forks or "third-party updates" in general.

  • Consider highlighting commits or forks that implement features the main repository does not want. For example, if #31 automatically links to a repo's issue #31, perhaps some other format could link to a forked repo (and highlight it on the original repo).
  • Get rid of useless "+1" comments by adding a "thumbs up" counter. Or, generalize Stars from the "repo-level" to the "issue-level."
  • Allow for the ability to completely close threads; if the author doesn't want to implement the feature, it should be made abundantly clear. Don't make authors endlessly justify their programming decisions or having to assuage the frustrations of their userbase. Otherwise, you end up with a wall of memes discussing semicolon omission in JavaScript.
  • Navigation on the Network Graph is a painful experience, the least problematic of which being that the up-and-down arrow keys often interfere with the browser's scroll bar. For a quick improvement, you should show committed changes on a per-file basis. That way, if I already know the file that needs modification, I can see any changes made to it — sort of like a universal git blame.

You're using Ace to provide inline edits to files. Terrific! Ace is an incredible online code editor. (Disclaimer: I contribute to Ace.)

However, what is up with the way that it's being used?

A horrendous white-on-black with minimal highlighting is truly unappealing. Why not provide the ability to set the themes? Also, the Ace editor is capable of so much more. Multiple cursors. A command line. Live linting. And at a minimum, you could improve the "Find" feature off of its default pop-up dialog.

You're a social coding site, and your contributions to open-source development and discovery cannot be stressed enough.

Why not go the extra step and provide a map of nearby developers? You know which languages I like to work in most; you can also know my location (if I choose to tell you). Perhaps you should also suggest nearby hu-mans for collaborative hacking?

I'm not proposing you pivot into Facebook for Nerds. But if me and three other people have forked the same repository, and we've all made pull requests for it, it'd be nice to have the opportunity to hash out some more ideas in person.

Documentation, you neglected necessity of open-source. How everyone marvels at your wonders, how few contribute to your success.

It's tremendously easy to generate wikis and GitHub pages. You should also make it tremendously easy to create API documentation. Nothing too fancy; just click a button, parse my repository, and provide a list of public classes and members. If I, the developer, want to provide further improvements, then it's my responsibility to do so. But if I just don't have the time, it becomes incredibly useful for anyone stumbling around to get a quick understanding of what my code can do.

For some reason, the newsfeed does not allow for infinite scrolling.

Most sites have infinite scrolling for homepage content. It's just one of those "neat-o" web niceties circa 2008.

Why does this website exist? Because I want to help make GitHub awesomer.

I, like many others, spend my entire working day (and some of my nights and weekends) looking at and working with GitHub. There are few ways outside of social campaigns to get opinions heard. I'm not Linus Torvalds; my rants will not change websites.

I'm absolutely thrilled that every time you contact GitHub Support, you're connected with a real person that responds, unscripted! But bothering them with these ideas didn't seem like the right approach. Through this website, I hope to make contact with a real life human being.

I'd also love to see GitHub make more things "open source" — list your planned features, list your bugs, open up more documentation.

In case you're hiring, here's my resume. I wasn't kidding about wanting to make you better, together. (/◔ ◡ ◔)/