
Ask HN: How would you improve GitHub? - dineshp2
Github does web based repository hosting very well. There are still numerous changes that can be made to improve the overall experience of using the platform such as [1].<p>Most of the changes mentioned in [1], don&#x27;t fundamentally change the experience of using Github. It still is essentially a git repo hosting platform.<p>Is there anything you would like that can improve the process of collaborating on code (such as an irc like chat integrated into Github)?<p>Fundamentally, how would you improve the process of collaborating on projects, not being limited to repo hosting?<p>Do you feel that the developer experience of collaborating on code is broken as there are multiple tools that we <i>have</i> to use such as Github for repo hosting, irc for discussions, mailing lists, audio&#x2F;video chat when collaborating with a small team?<p>How can the the developer experience be improved with Github only being a part of the puzzle?<p>[1] https:&#x2F;&#x2F;github.com&#x2F;dear-github&#x2F;dear-github
======
sirn
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).

~~~
tedmiston
If it's any consolation, Jira's issue blocking feature is pretty broken too.

~~~
wingerlang
We added a column for "blocked" and I periodically check them out if I'm
assigned. Works pretty well.

~~~
tedmiston
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.

------
alexwebb2
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).

~~~
MaulingMonkey
I've taken to using seperate _Chrome_ users to split personal / work, which
might be a useful workaround.

~~~
ameister14
You can use multifox for the same purpose if you use Mozilla.

------
bluenose69
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.

~~~
SoMuchToGrok
Related: My favorite user style.

[https://userstyles.org/styles/37035/github-
dark](https://userstyles.org/styles/37035/github-dark)

------
zingBhavya
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.

------
ddorian43
Fire all the "diversity" employees. You know what I'm talking about.

------
Jemaclus
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.

~~~
tedmiston
What do you mean? Do you normally have pages and pages of pull requests at one
time?

~~~
Jemaclus
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.")

~~~
tedmiston
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.

~~~
jobvandervoort
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](https://gitlab.com/gitlab-org/gitlab-ce/issues/14103)

~~~
tedmiston
I stand corrected, in the best possible way. How exactly does GitLab define
"large diff" anyway?

~~~
jobvandervoort
A large diff has 100 files / 5000 lines in total. A single large file is
>=5KB.

------
MaulingMonkey
> 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.

------
tedmiston
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.

------
ellsworthless
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.

------
cdnsteve
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.

------
WorldMaker
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.

------
jaredsohn
Let me reply to non-code related PR comments in a thread.

------
martinni
\- Tab spacing config instead of having to append `ts=4`

\- Commenting on a PR while ignoring whitespace changes `w=1`

------
nojvek
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

------
ozten
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.

------
kzisme
More user code base visibility (ie: things they have written or contribute to)

------
tedmiston
An easy way to see _all_ contributors of a repo, not limited to the top 100.

------
devhead
repo tagging/grouping

~~~
kontulai
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...](http://blog.deveo.com/what-makes-deveo-different-from-github-
gitlab-and-bitbucket/) \- 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

------
sayelt
Make issues optional for projects that don't use it.

------
Fej
Open-source it, and maybe we'll get better answers.

------
mbrock
Responsive design for mobile resolutions.

~~~
tedmiston
Perhaps you could elaborate. The site already has a decent responsive mobile
interface.

~~~
mbrock
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.

------
meh2frdf
Navigation between orgs is borked.

