These are great, but they're bugfixes. You'd finish them in the first few months. Then what are you going to do? Stare at an aquarium all day? Here's what I would build if I worked at github:
* Github CI - simple CI for every language, integrating with:
* Github Deploy - deploy tooling for deploying runnable artifacts or artifact combinations to either your own infrastructure, or to aws/azure/google, or:
* Github Cloud - instances/containers as a service
and the 'fork' button would be a pulldown that would include the options 'fork', 'fork and test', 'fork, test and deploy'. Now that's a nice little 3-4 year career.
Non of the items in the author's list is a bugfix. They all are enhancements. A bugfix would fix a bug, which means something would not work as it is supposed to, fail, and that is not the case here.
Arguing semantics, maybe. But I think it is important to distinguish here. Polishing issues or enhancements or whatever you call it are things that do not need to be adressed, but they can. But bugs needs to be fixed. Choosing between what to do now is choosing between maintenance work and feature enhancement work, plumbing and UX.
I think it would be great if Github would hire and let him build these things, does not matter if he finishes in a month.
Of all the things I wish Github had, a mailing list service would be really amazing, and the kind of thing that wouldn't be done in the first few months. Sourceforge offers atrocious mailman-based email, larger foss projects on github suffer :(
Great minds... I was talking about this the other day with the other engineers at work, after learning about GitHub's most recent monstrous funding round. It seems like CI/a deployment service and something that competes in the crowded PaaS field is the next logical step.
AWS enables us to do some pretty slick things, but OpsWorks is a giant bag of suck that frequently finds a way to drain my time troubleshooting why something crazy or random has happened on the production server--behaviors I never saw in my previous role running a bare-metal LAMP stack for 4 years. A tighter integration between our GitHub repo and a testing/build server... Swoon.
A github CI would be awesome! I imagine it would get very costly for them though. I love Travis-CI and the easy integration, but it's too expensive for my non-open source projects.
All these are nice, but are not must-haves as they can be built outside of GitHub. The show-stopper for me is granular permissions - coming from the Gitolite [0] world, where I can permission even branches and do all kinds of checks and balances on the server, GitHub is a joke for a not-so-large enterprise! Another thing is the Wiki - why pages are based on Git and the Wiki is not?!
At some point in the last year or so Github rolled out a new search engine which drastically reduced it's usefulness. Any moderately complex search query now has all of the modifiers and key bits stripped out making your search results unnecessarily cluttered and somewhat useless. I consider it to be one of the worst parts of the site these days.
It seems like some of these (perhaps all of them other than fixing the "+1" problem) can be done via API clients instead of via GitHub itself implementing it. A third-party website can do wiki searches. A separate service can send you email notifications, and you can turn off built-in emails.
Even the +1 thing might be solvable with a bot that edits each bug report to add a clickable +1 badge (a la the CI build-passing badges) at the top; all you need is to give the bot ownership of your repository. The badge can display the current +n count, and the service can give you a sorted list of open issues by +n. For bonus points, have the bot also harvest and remove comments that consist of just "+1" or ":+1".
This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?
>This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?
Why would I build something for a centralized closed-source company?
The only thing I really, really want is paginated diffs for pull requests. C'mon. If I have 300 files, don't show me the first 15 and then say "well, this is too big, you'll just have to imagine what the rest of the diff looks like." Does Google return the first page and then say "the rest of the internet isn't available to you because we don't want to paginate things"? No, of course not. Just freaking paginate long diffs.
If today you see that a major repository has a fork with a lot of commits, you cannot know without looking through THEM ALL if they are just typo fixes or if the fork is really changing/improving things over the main repo.
One way that has served me as being a pretty good metric of what's what when it comes to forks looking at the number of stars the parent and child repos have. If a fork has started to usurp it's parent, it generally has a fair deal of its own stars.
The biggest thing I want from GitHub is the ability to search commits. GitHub are pretty good at search (their issue search is fantastic, and their code search is decent enough) - but the data I most want to search are the commit messages in my repo.
I understand this will be a huge amount of data (they must have hundreds of millions if not billions of commits by now). I'd be perfectly happy if this was only available for paid repositories.
The ability to then further facet and filter searches by author, file, directory etc would be unbelievably useful.
By far the biggest thing I wish github would do is change the text entry beside the file names. Right now, it shows the comment of the last push of edits to that file. That's great for members of the project.
However, for non-members it would be far more useful to know what the file is. Here, enabling a one-line description would be hugely helpful.
Since GH knows if you're a member of the project it can show you the right text--description or latest update. And presumably, a button would allow you to see the other text if you needed it.
I see people here posting issues of their own, but I'm amazed nobody has yet mentioned the lack of IPv6.
I've setup a few machines with IPv6-only network connections, and it makes pulling my dotfiles from github a pain since I need an IPv4-proxy/tunnel to access github.com
Great list, we're working on making something that makes +1's less noisey. If you want the possibility to contribute to the tools you use daily consider using our GitLab. It is open source and more than 800 people have contributed already.
code is read way more often than written. and on github website all you can do is read it. why the viewports don't take up the entire screen width i will never understand.
My biggest pet-peeve about GitHub is its issue tracker system. It's great for one-off issues or tracking a pull-request, but beyond that its design is super unwieldy. Such a missed opportunity to crush JIRA, et. al.
Personally, I'd like a nice GUI to pick and squash commits with new commit messages against them on creating a pull request. I don't enjoy using the CLI for this, and it would be nice to thread thoughts on the solution into the commits themselves rather than explaining solely in the PR description.
- No ability to store the tab size setting. While appending '?ts=2' to the url is ok, it's not convenient and usable on a daily basis. The same for omitting whitespace changes in a diff / pr ('?ws=1').
- No ability to step through history on a single file while in blob view, or blame view. In blame view, the commit link goes to the commit, not the blame of the file at that commit.
- Agree with OP that notifications need to be grouped / summarized better. Perhaps expandable summary items per repo per type. This is mostly useful for private, work-related repos. Pulse and notifications are basically the same thing.
- Stars cannot be tagged. This makes managing hundreds of stars difficult. There's apps like Astral, but even those are lacking.
Those are interesting suggestions, but my guess is that they are probably focusing on features to make github more enterprise friendly. If a16z invests $100 million in github, it doesn't seem like streamlining emails will have the ROI that investors expect.
Maybe github is focusing on creating a full software development lifecycle management (ALM) in the cloud. (Like Microsoft Team Foundation Server and JIRA.) A dashboard for sprints, defect fixes, issues tracking, etc. That's the type of "enterprisey" thing that attracts more business subscriptions. They use the storage of sourcecode repositories to open doors to other sw development related business.
These are just my guesses. I haven't seen any explicit roadmap from github.
I'm actually hoping they bring something into GH for business/enterprise that is better, or as good as TFS or JIRA... I like TFS, but non-VS projects are a pain... and JIRA is just well, not pleasant at all.
Once they have some sort of better issue tracking system, then migration tooling will become another big issue in that space.. getting from SVN+JIRA or TFS itself would be really useful to a lot of orgs, willing to pay. Something between TFS and Axosoft's OnTime would be pretty nice as an addition to GH.
Another area with a lot of potential would be a CI/CD toolset that uses your own cloud.. EX: you use api keys for Azure, GCE, AWS, DO etc, and then you can setup testing/limits and Github could just manage the provisioning of the test servers, and ease setup/deployment of test/stage/prod classes of servers for multiple languages.
GH wouldn't have to manage a huge infrastructure itself, just build/sell tooling that extends it's current product line.
Wiki search is #1 on my wish list for Github. I see others talking about cloning the wiki repo locally and searching it but for big projects this would be the equivalent of downloading something like the Python docs and searching them. It could be done but it would be a massive pain in the ass.
I have written most of the documentation for the project I contribute to the most and I organized the wiki like a two level tree where a top level page has links to category pages and each page on the wiki is linked to from one of those category pages. Then there are links interspersed among the pages like a normal wiki. This structure works okay but I know it can be better because sometimes I cannot even find information that I produced!
I feel one could have more ambitious goals. E.g. Could Github build a powerful developers careers site based on all the data they have? Could they provide more tools to help people program? (Could they automatically create programs? https://news.ycombinator.com/item?id=9973088)
[+] [-] felixgallo|10 years ago|reply
* Github CI - simple CI for every language, integrating with:
* Github Artifacts - repository for versioned deployable build packages (binaries, tar.gz files, ios builds, android builds...), integrating with:
* Github Deploy - deploy tooling for deploying runnable artifacts or artifact combinations to either your own infrastructure, or to aws/azure/google, or:
* Github Cloud - instances/containers as a service
and the 'fork' button would be a pulldown that would include the options 'fork', 'fork and test', 'fork, test and deploy'. Now that's a nice little 3-4 year career.
[+] [-] panic|10 years ago|reply
I bet you could work on small polish issues like this for a lifetime and never finish. There's always something to improve.
[+] [-] onli|10 years ago|reply
Arguing semantics, maybe. But I think it is important to distinguish here. Polishing issues or enhancements or whatever you call it are things that do not need to be adressed, but they can. But bugs needs to be fixed. Choosing between what to do now is choosing between maintenance work and feature enhancement work, plumbing and UX.
I think it would be great if Github would hire and let him build these things, does not matter if he finishes in a month.
[+] [-] scrollaway|10 years ago|reply
[+] [-] kelukelugames|10 years ago|reply
[+] [-] Eiriksmal|10 years ago|reply
AWS enables us to do some pretty slick things, but OpsWorks is a giant bag of suck that frequently finds a way to drain my time troubleshooting why something crazy or random has happened on the production server--behaviors I never saw in my previous role running a bare-metal LAMP stack for 4 years. A tighter integration between our GitHub repo and a testing/build server... Swoon.
[+] [-] critiq|10 years ago|reply
[+] [-] jxm262|10 years ago|reply
[+] [-] kolev|10 years ago|reply
[0] http://gitolite.com/
[+] [-] vezzy-fnord|10 years ago|reply
[+] [-] h43k3r|10 years ago|reply
After exploring Visual Studio Online (its free for 5 users), I am still not able to digest why there isn't a build and deploy system in GitHub.
There were great demos at Microsoft's BUILD15 for Automated Build and Release Management which demonstrates these features.
[+] [-] holic|10 years ago|reply
[+] [-] fideloper|10 years ago|reply
[+] [-] sinnet11|10 years ago|reply
Bugfixes are not feature enhancements.
Also this makes you sound like a pleasant person to work with.....a real go getter.
[+] [-] danielsamuels|10 years ago|reply
> GitHub already has a great code search
At some point in the last year or so Github rolled out a new search engine which drastically reduced it's usefulness. Any moderately complex search query now has all of the modifiers and key bits stripped out making your search results unnecessarily cluttered and somewhat useless. I consider it to be one of the worst parts of the site these days.
[+] [-] davidcelis|10 years ago|reply
[+] [-] jberryman|10 years ago|reply
[+] [-] justinhj|10 years ago|reply
[+] [-] anshukla|10 years ago|reply
[+] [-] johnbellone|10 years ago|reply
[+] [-] Buetol|10 years ago|reply
* Change the target branch of a pull request pull-requests
* Delete / remove an issue completely.
* Gist comments and mentions don't trigger notifications
* Add HTTPS support to Github Pages
* Add ability to follow organizations like a user
* Insert automatically generated table of contents TOC on rendered markdown files like README.md.
* pre { tab-size: 4 }
[+] [-] beltex|10 years ago|reply
This is technically already available, though not officially documented anywhere [1]. Example [2]
[1] https://github.com/isaacs/github/issues/156#issuecomment-377...
[2] https://beltex.github.io
[+] [-] geofft|10 years ago|reply
Even the +1 thing might be solvable with a bot that edits each bug report to add a clickable +1 badge (a la the CI build-passing badges) at the top; all you need is to give the bot ownership of your repository. The badge can display the current +n count, and the service can give you a sorted list of open issues by +n. For bonus points, have the bot also harvest and remove comments that consist of just "+1" or ":+1".
This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?
[+] [-] allendoerfer|10 years ago|reply
Why would I build something for a centralized closed-source company?
[+] [-] Jemaclus|10 years ago|reply
Gah.
[+] [-] fiatjaf|10 years ago|reply
If today you see that a major repository has a fork with a lot of commits, you cannot know without looking through THEM ALL if they are just typo fixes or if the fork is really changing/improving things over the main repo.
[+] [-] z1mm32m4n|10 years ago|reply
[+] [-] danieltillett|10 years ago|reply
[+] [-] simonw|10 years ago|reply
I understand this will be a huge amount of data (they must have hundreds of millions if not billions of commits by now). I'd be perfectly happy if this was only available for paid repositories.
The ability to then further facet and filter searches by author, file, directory etc would be unbelievably useful.
[+] [-] andrewbinstock|10 years ago|reply
However, for non-members it would be far more useful to know what the file is. Here, enabling a one-line description would be hugely helpful.
Since GH knows if you're a member of the project it can show you the right text--description or latest update. And presumably, a button would allow you to see the other text if you needed it.
[+] [-] kzhahou|10 years ago|reply
(Yes, by which I am saying their website has not improved much given their massive funding)
[+] [-] bqe|10 years ago|reply
What are they working on?
[+] [-] stevekemp|10 years ago|reply
I've setup a few machines with IPv6-only network connections, and it makes pulling my dotfiles from github a pain since I need an IPv4-proxy/tunnel to access github.com
[+] [-] justincormack|10 years ago|reply
[+] [-] sytse|10 years ago|reply
[+] [-] qmr|10 years ago|reply
[+] [-] foolfoolz|10 years ago|reply
code is read way more often than written. and on github website all you can do is read it. why the viewports don't take up the entire screen width i will never understand.
[+] [-] jarjoura|10 years ago|reply
[+] [-] anton_gogolev|10 years ago|reply
[+] [-] nickbauman|10 years ago|reply
[+] [-] anton_gogolev|10 years ago|reply
[+] [-] lhnz|10 years ago|reply
[+] [-] hlfcoding|10 years ago|reply
- No ability to store the tab size setting. While appending '?ts=2' to the url is ok, it's not convenient and usable on a daily basis. The same for omitting whitespace changes in a diff / pr ('?ws=1').
- No ability to step through history on a single file while in blob view, or blame view. In blame view, the commit link goes to the commit, not the blame of the file at that commit.
- Agree with OP that notifications need to be grouped / summarized better. Perhaps expandable summary items per repo per type. This is mostly useful for private, work-related repos. Pulse and notifications are basically the same thing.
- Stars cannot be tagged. This makes managing hundreds of stars difficult. There's apps like Astral, but even those are lacking.
[+] [-] jasode|10 years ago|reply
Maybe github is focusing on creating a full software development lifecycle management (ALM) in the cloud. (Like Microsoft Team Foundation Server and JIRA.) A dashboard for sprints, defect fixes, issues tracking, etc. That's the type of "enterprisey" thing that attracts more business subscriptions. They use the storage of sourcecode repositories to open doors to other sw development related business.
These are just my guesses. I haven't seen any explicit roadmap from github.
[+] [-] tracker1|10 years ago|reply
Once they have some sort of better issue tracking system, then migration tooling will become another big issue in that space.. getting from SVN+JIRA or TFS itself would be really useful to a lot of orgs, willing to pay. Something between TFS and Axosoft's OnTime would be pretty nice as an addition to GH.
Another area with a lot of potential would be a CI/CD toolset that uses your own cloud.. EX: you use api keys for Azure, GCE, AWS, DO etc, and then you can setup testing/limits and Github could just manage the provisioning of the test servers, and ease setup/deployment of test/stage/prod classes of servers for multiple languages.
GH wouldn't have to manage a huge infrastructure itself, just build/sell tooling that extends it's current product line.
[+] [-] epberry|10 years ago|reply
I have written most of the documentation for the project I contribute to the most and I organized the wiki like a two level tree where a top level page has links to category pages and each page on the wiki is linked to from one of those category pages. Then there are links interspersed among the pages like a normal wiki. This structure works okay but I know it can be better because sometimes I cannot even find information that I produced!
[+] [-] lochlan|10 years ago|reply
[+] [-] andrewchambers|10 years ago|reply
[+] [-] piotrkaminski|10 years ago|reply
[+] [-] arikrak|10 years ago|reply