Ask HN: How would you improve GitHub?
40 comments
Add a way to manage blocking issues.
My company uses GitHub Enterprise and this was one of the major factors for us to migrate away from GitHub Issues to other platform (Phabricator). GitHub Issues works fine for tracking issues, but once the project has 30 people working on it, it's really hard to keep track of where things are.
Yes, you can just comment on the issue saying "Blocked by #123" but this is one way tracking (even when GitHub happily notify other issue that it was mentioned). Once #123 is closed, the issues blocked by it isn't becoming any more visible that it could now be worked on unless the person looking to work on the blocked issue also keep track of #123, or person closing #123 kind enough to notify the blocking task.
Having a proper blocking issue tracking also reduce the mental workload when someone ask "what's the status of this issue?" Trying to remember why an issue created 3 months ago couldn't be done isn't fun (even when you can re-read comments).
My company uses GitHub Enterprise and this was one of the major factors for us to migrate away from GitHub Issues to other platform (Phabricator). GitHub Issues works fine for tracking issues, but once the project has 30 people working on it, it's really hard to keep track of where things are.
Yes, you can just comment on the issue saying "Blocked by #123" but this is one way tracking (even when GitHub happily notify other issue that it was mentioned). Once #123 is closed, the issues blocked by it isn't becoming any more visible that it could now be worked on unless the person looking to work on the blocked issue also keep track of #123, or person closing #123 kind enough to notify the blocking task.
Having a proper blocking issue tracking also reduce the mental workload when someone ask "what's the status of this issue?" Trying to remember why an issue created 3 months ago couldn't be done isn't fun (even when you can re-read comments).
If it's any consolation, Jira's issue blocking feature is pretty broken too.
We added a column for "blocked" and I periodically check them out if I'm assigned. Works pretty well.
Our approach is similar (a red background label on the card), but it would be nice if completing a blocking story would automatically unblock those blocked by it. We do that manually and it gets out of sync due to humans.
Account switching, please - or at the very least, let me log in from the front page!
As it is now, if I'm on my personal account and go to open up a private work repo, it takes SIX navigation events:
1. Trying to hit the repo the first time
2. Clicking the logo to go to the main page
3. Logging out
4. Clicking the login button to go to the login page
5. Logging in
6. Going back to the repo I wanted to see in the first place
I'd like to see a Google-style account switcher, where I just click a menu in the upper right, choose the account, and it reloads the page under that account. A simple thing that would make the site much more usable to those of us with multiple accounts (which I expect is quite a few people).
As it is now, if I'm on my personal account and go to open up a private work repo, it takes SIX navigation events:
1. Trying to hit the repo the first time
2. Clicking the logo to go to the main page
3. Logging out
4. Clicking the login button to go to the login page
5. Logging in
6. Going back to the repo I wanted to see in the first place
I'd like to see a Google-style account switcher, where I just click a menu in the upper right, choose the account, and it reloads the page under that account. A simple thing that would make the site much more usable to those of us with multiple accounts (which I expect is quite a few people).
I've taken to using seperate Chrome users to split personal / work, which might be a useful workaround.
You can use multifox for the same purpose if you use Mozilla.
I'd like to see a more conventional bug-reporting scheme. The 'issue' mechanism is too confusing for typical users, because it presents all sorts of items that are unrelated to bug reporting, and it's ugly for developers, because so much of the browser screen area is taken up with whitespace and trivia.
It would be nice if the github site permitted users to set themes, including some that are substantially thinned-out.
It would be nice if the github site permitted users to set themes, including some that are substantially thinned-out.
Related: My favorite user style.
https://userstyles.org/styles/37035/github-dark
https://userstyles.org/styles/37035/github-dark
"User Reports"?
I don't even understand, why force-fit something and use it for what it is not for. Github is great for shared repository etc.,for devs to collaborate on code. I guess the issues feature is also great for open source repositories to be able to track issues that the devs know about etc, or raising a support issue. But, for internal teams doing dev, there are better tools out there which handle issue tracking well. They need not be linking to the code, but really for most of the issue tracking, there are other important things like to managing priorities, easy assignment, essentially you need a better filtering and a management system that not only devs, but every stakeholder involved can easily use. Github is for devs only (in my opinion). But, issue management involves every stakeholder, so it is best to have it outside of github.
Fire all the "diversity" employees. You know what I'm talking about.
Paginate pull requests. For the love of all that is holy, paginate pull requests. It's probably the main thing that frustrates the hell out of me when doing code reviews. Argh.
What do you mean? Do you normally have pages and pages of pull requests at one time?
If you have a lot of files or a lot of lines that get changed, eventually it just cuts off and says "Diff is too large" and won't show me the remaining files, so I have to do the diff manually at the command line. It sucks pretty bad.
(Note: our rules suggest small PRs, but occasionally, especially for large rewrites or large features, the PRs can be huge. Lack of pagination makes code reviews extremely difficult, since it just stops showing files, rather than saying "The rest of the files are on the next page.")
(Note: our rules suggest small PRs, but occasionally, especially for large rewrites or large features, the PRs can be huge. Lack of pagination makes code reviews extremely difficult, since it just stops showing files, rather than saying "The rest of the files are on the next page.")
Interesting. We use GitLab which doesn't seem to have this limitation that I'm aware of. I've used it [GitLab] for PRs up to a few thousand lines.
We actually do show this when the diff is too large, but we're improving this with GitLab 8.10. In 8.10 diffs become collapsible, so you can choose to hide / show very large diffs for performance reasons [0] or to make it easier to walk through diffs with many files.
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/14103
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/14103
I stand corrected, in the best possible way. How exactly does GitLab define "large diff" anyway?
A large diff has 100 files / 5000 lines in total. A single large file is >=5KB.
> Do you feel that the developer experience of collaborating on code is broken as there are multiple tools that we have to use such as Github for repo hosting, irc for discussions, mailing lists, audio/video chat when collaborating with a small team?
Not broken per se, but it's more friction and less tightly integrated. Although I'm not actually after better social tools myself - I'm more interested in CI integration.
I've tried travis in the past on github for C# projects - and immediately hit their mono installation not supporting even building my MSTest projects. Now I'm using gitlab for their CI integration - their runner model may be way simpler for the purposes of building (I just feed it shell scripts I write myself), and in practice requires me to admin my own servers for private on-windows CI builds, but I was going to have to do that anyways. (Also, several of them are just my workstations configured to run CI builds in the background.) And it works. Even better, the build status gets nicely integrated into the commit history.
Not broken per se, but it's more friction and less tightly integrated. Although I'm not actually after better social tools myself - I'm more interested in CI integration.
I've tried travis in the past on github for C# projects - and immediately hit their mono installation not supporting even building my MSTest projects. Now I'm using gitlab for their CI integration - their runner model may be way simpler for the purposes of building (I just feed it shell scripts I write myself), and in practice requires me to admin my own servers for private on-windows CI builds, but I was going to have to do that anyways. (Also, several of them are just my workstations configured to run CI builds in the background.) And it works. Even better, the build status gets nicely integrated into the commit history.
[deleted]
A way to see the SLOC for a repo.
It helps me realize how much time I might need to dive into and start understanding it. Some packages look deceptively large from boilerplate but really have just a couple hundred lines of real code. Others have everything in one or just a couple files but with many thousands of lines.
It helps me realize how much time I might need to dive into and start understanding it. Some packages look deceptively large from boilerplate but really have just a couple hundred lines of real code. Others have everything in one or just a couple files but with many thousands of lines.
I work in QA for a startup doing web development. My bosses seem to refuse using a better bug tracking/organizing system. There are some improvements I would suggest for organization.
1. The search function is abysmal. If I search for "cats", it will not also find "cat".
2. If someone leaves the company they are turned into "ghost". That wouldn't be an issue except that you can't search or sort by ghost which means that everything assigned to them now has to be manually searched for.
3. There isn't a good way to make a ticket "in dev" > "in testing" etc. without labels. The labels then inflate since we already have high low etc. Then there are the category labels like performance or customer issue. In the end we have nearly 25 labels and it's almost more of a hindrance.
4. When a new feature is created there are of course a number of issues to fix before it's ready. The best way we've dealt with this is numbering each comment with an issue in it and then having a checklist on the bottom of the ticket that gets checked off. There needs to be some sort of easily view-able checklist which can either be used to indicate completeness of parts of a feature or smaller bugs in the scope of the ticket. It becomes really hard to manage, read, and find reported problems when you have 50+ comments that have bugs in them and another 30 that aren't near their original comment but are related.
5. This might be related to 3 but milestones are also a little limiting. The process we have now is to put something into the current sprint milestone, after it's been validated on a local system we move it to another milestone while we wait for the rest of the tickets. I don't think this is a great way to do this and things should have a status within a milestone.
6. For the love of god do something about the caching. I can go to a ticket where I've made a new comment myself 5 minutes prior, go back to the issues list, and back into that issue and I'm missing several days of comments until I refresh.
1. The search function is abysmal. If I search for "cats", it will not also find "cat".
2. If someone leaves the company they are turned into "ghost". That wouldn't be an issue except that you can't search or sort by ghost which means that everything assigned to them now has to be manually searched for.
3. There isn't a good way to make a ticket "in dev" > "in testing" etc. without labels. The labels then inflate since we already have high low etc. Then there are the category labels like performance or customer issue. In the end we have nearly 25 labels and it's almost more of a hindrance.
4. When a new feature is created there are of course a number of issues to fix before it's ready. The best way we've dealt with this is numbering each comment with an issue in it and then having a checklist on the bottom of the ticket that gets checked off. There needs to be some sort of easily view-able checklist which can either be used to indicate completeness of parts of a feature or smaller bugs in the scope of the ticket. It becomes really hard to manage, read, and find reported problems when you have 50+ comments that have bugs in them and another 30 that aren't near their original comment but are related.
5. This might be related to 3 but milestones are also a little limiting. The process we have now is to put something into the current sprint milestone, after it's been validated on a local system we move it to another milestone while we wait for the rest of the tickets. I don't think this is a great way to do this and things should have a status within a milestone.
6. For the love of god do something about the caching. I can go to a ticket where I've made a new comment myself 5 minutes prior, go back to the issues list, and back into that issue and I'm missing several days of comments until I refresh.
Simple changes to improve the Wiki:
1. Allow image uploads by dragging images directly onto a wiki page that will then upload and link it. This happens currently in issues but isn't available via the wiki.
2. The Wiki page search. It only searches page titles, the top repo search does not search the wiki either. Not cool. You build great documentation but then can't later search it?
3. Give the Wiki it's own developer API. I don't see it anywhere in their current documentation.
1. Allow image uploads by dragging images directly onto a wiki page that will then upload and link it. This happens currently in issues but isn't available via the wiki.
2. The Wiki page search. It only searches page titles, the top repo search does not search the wiki either. Not cool. You build great documentation but then can't later search it?
3. Give the Wiki it's own developer API. I don't see it anywhere in their current documentation.
I think it would be nice to see some sort distributed issue tracker as a "first class" option. If Github's issue tracker could support optionally storing its data as branchable artifacts in git, that would be a nice to have for some projects. Especially if you can keep the general simplicity of the existing PR and Issue Tracker are so that people new to a project can still relatively easily contribute directly from the web.
Let me reply to non-code related PR comments in a thread.
- Tab spacing config instead of having to append `ts=4`
- Commenting on a PR while ignoring whitespace changes `w=1`
- Commenting on a PR while ignoring whitespace changes `w=1`
Be able to give issues priorities and sort them with user defined attributes like what release cycled they are planned for. The number of votes / +1s on different ideas e.t.c
It would be nice to be able to put specific issues into "moderated" mode. I want to approve comments on divisive issues before everyone is spammed with email.
More user code base visibility (ie: things they have written or contribute to)
An easy way to see _all_ contributors of a repo, not limited to the top 100.
repo tagging/grouping
We have solved this in Deveo by grouping repositories inside projects since it reflects more naturally how software is built outside the open source community. This has been our focus from the inception. In non-open-source projects, a project typically includes multiple repositories (such as backend and frontend at least), and they all share the same issue tracking and wiki functionalities.
We covered this topic and other differences between Deveo, GitLab and Bitbucket recently in a blog post. If you are interested to see an alternative viewpoint on things, check http://blog.deveo.com/what-makes-deveo-different-from-github... - I would love to hear feedback whether our approach is viable compared to GitHub's open-source approach on things.
Disclaimer: I work at Deveo
We covered this topic and other differences between Deveo, GitLab and Bitbucket recently in a blog post. If you are interested to see an alternative viewpoint on things, check http://blog.deveo.com/what-makes-deveo-different-from-github... - I would love to hear feedback whether our approach is viable compared to GitHub's open-source approach on things.
Disclaimer: I work at Deveo
Make issues optional for projects that don't use it.
Open-source it, and maybe we'll get better answers.
Responsive design for mobile resolutions.
Perhaps you could elaborate. The site already has a decent responsive mobile interface.
Sorry, I was confused. What I meant was actually responsive design on the "desktop" site, perhaps instead of a separate mobile variant.
I really prefer to zoom in on most website to get bigger text, and good responsive layouts often become less cluttered when you zoom. GitHub's widths are too static though so everything just overflows.
I kind of like using the mobile version but it's annoying to have to spoof the user agent and all features aren't available there.
I really prefer to zoom in on most website to get bigger text, and good responsive layouts often become less cluttered when you zoom. GitHub's widths are too static though so everything just overflows.
I kind of like using the mobile version but it's annoying to have to spoof the user agent and all features aren't available there.
Navigation between orgs is borked.
[deleted]
Most of the changes mentioned in [1], don't fundamentally change the experience of using Github. It still is essentially a git repo hosting platform.
Is there anything you would like that can improve the process of collaborating on code (such as an irc like chat integrated into Github)?
Fundamentally, how would you improve the process of collaborating on projects, not being limited to repo hosting?
Do you feel that the developer experience of collaborating on code is broken as there are multiple tools that we have to use such as Github for repo hosting, irc for discussions, mailing lists, audio/video chat when collaborating with a small team?
How can the the developer experience be improved with Github only being a part of the puzzle?
[1] https://github.com/dear-github/dear-github