Ask HN: How would you improve GitHub?
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
40 comments
[ 5.6 ms ] story [ 113 ms ] threadIt would be nice if the github site permitted users to set themes, including some that are substantially thinned-out.
https://userstyles.org/styles/37035/github-dark
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
(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.")
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/14103
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).
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).
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.
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.
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.
- Commenting on a PR while ignoring whitespace changes `w=1`
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. 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.