GitHub has become an essential part of my daily workflow. I've been a big fan of GitHub as a product and as a company since its inception. It's the reason I'm an avid git user, an open source contributor, and overall a better developer.

Over the years, I've discovered a few areas of GitHub that could use some improvement. I've submitted these ideas to GitHub, but haven't seen them addressed. If I worked at GitHub, this is what I would build.

Searchable wiki pages

GitHub wikis are a really useful tool for documentation. In the past, I've used GitHub wikis to document not only what goes on in a repo, but also to document internal processes to reduce the bus factor of a given project.

Wiki navigation, however, is completely your responsibility. It's up to you to choose good page names, interlink across pages, and create a table of contents. The only navigation GitHub provides you with is a list of pages that exist in your wiki.

GitHub already has a great code search and issue search from a single search field above each repo. Wiki pages, however, are not included in these search results. A wiki is just a repo of Markdown files, so it can be treated like a code repo using the same indexing process for search. The gains in productivity for writing documentation and finding answers within documentation would be huge.

If you've collaborated on an open source project on GitHub, you've likely come across "+1" comments and folks that get angry about them. While they may not contribute much more than clutter to a thread, I would argue there is still a need to show support for a specific issue or pull request, even if you have nothing to add to the conversation.

Many have been quick to suggest adding a "+1" button to issues and pull requests to replace these sorts of comments, but I'm not convinced this is the best solution. The suggested alternative is to "Subscribe" to an issue for updates, which is what I've started doing to issues that I want to show my support for. My support, however, isn't visible to anyone else.

If the number of subscribers for each issue and pull request were exposed and sortable, they could take the place of "+1" comments and act much like Google Code's stars feature. By subscribing to an issue, you're required to at least be aware of the conversation (via notifications) if not be a participant. And to take it further, I'd probably show a tip, warning, or confirmation when trying to comment with only "+1", suggesting the "Subscribe" feature instead.

Smarter email notifications

When participating in several active projects, notifications can get a bit unwieldy. Before being an active contributor on GitHub, I cherished each email notification - it usually meant someone had reviewed my pull request or had feedback on an issue I was concerned about. As my contributions grew, so did the frequency of notifications. Now I rarely read the email notifications I get via GitHub as most of my notifications come through HipChat, Slack, or GitHub itself. I'd love to get back to the way things were.

GitHub is already clever about recognizing your acknowledgement of a notification when seeing it via email (assuming you have images enabled) and removing it from your notifications inbox. But there's room for improvement.

Email is a slow, asynchronous form of communication. Unlike SMS and push notifications, people don't expect to receive, see, and reply to email within seconds. Therefore, there's no need for email notifications to be realtime.

By waiting five minutes between creating a notification and firing off an email notification, only sending unacknowledged notifications, GitHub could greatly reduce the email sent to active GitHub users.

I'd love to get notified for new releases of projects that I'm interested in, use, or contribute to. GitHub publishes an RSS feed for releases, but a UI element to expose this feed to subscribe either through their own email system or through an external RSS-to-email service would be great.

Better history for navigating pull requests

When working with pull requests, particularly ones with large diffs ("Files changed" tab), I find browser navigation can be a bit cumbersome. This is due to the nature of the tabbed navigation within pull requests.

Open up a pull request and you'll arrive at the "Conversations" tab. Click over to to the "Files changed" tab and scroll through the code a bit. Now hit your back button (or swipe to go back). At this point, I would expect to be taken back to the "Conversations" tab, but I'm further back in my history to the last page I visited before that pull request. Hit your forward button and you're back to the file diff again, instead of the "Conversations" tab.

GitHub is using the browser history to change the URL to match the tab of the pull request I'm looking at (which is great!), but I would argue that a better experience is using history.pushState instead of history.replaceState (or location.replace ).

If anyone at GitHub could make these things happen, please get in touch and let me buy you a beer!