
Dear GitHub - msvan
https://github.com/dear-github/dear-github
======
jonobacon
Hi Adam, Addy, Andreas, Ariya, Forbes, James, Henry, John-David, Juriy , Ken,
Nicholas, Pascal, Sam, Sindre,

My name is Jono and I started as Director of Community back in November at
GitHub. Obviously I am pretty new at GitHub, but I thought I would weigh in.

Firstly, thanks for your feedback. I think it is essential that GitHub always
has a good sense of not just what works well for our users, but also where the
pain points are. Constructive criticism is an important of doing great work. I
appreciate how specific and detailed you were in your feedback. Getting a good
sense of specific problems provides a more fruitful beginning to a
conversation than "it suxx0rs", so I appreciate that.

I am still figuring out how GitHub fits together as an organization but I am
happy to take a look into these issues and ensure they are considered in how
future work is planned. We have a growing product team at GitHub that I know
is passionate about solving the major pain points that rub up against our
users. Obviously I can't make any firm commitments as I am not on the product
team, but I can ensure the right eyeballs are on this. I also want to explore
with my colleagues how we can be a little clearer about future feature and
development plans to see if we can reduce some ambiguity.

As I say, I am pretty new, so I am still getting the lay of the land, but feel
free to reach out to me personally if you have any further questions or
concerns about this or any other issue. I am at jono@github.com.

~~~
krschultz
An open question is how the community should provide feedback. Trello provides
a decent example of how to do it well [1], but GitHub feels like a black box.
I've been on GitHub since 2008 and I have been paying every month for years,
but other than emailing support I have no idea how to vote for a feature
request.

My personal pet peeve is not being able to mark a public repo as 'deprecated'.
There are a lot of other people with the same frustration [2], but we have no
idea how to get that on GitHub's roadmap.

[1] [http://help.trello.com/article/724-submitting-feature-
reques...](http://help.trello.com/article/724-submitting-feature-requests-for-
trello) [2]
[https://github.com/isaacs/github/issues/144](https://github.com/isaacs/github/issues/144)

~~~
peterfpf
I normally put a big "[DEPRECATED]" notice at the beginning of the README.
This normally doesn't go unnoticed.

Another good example is harthur's "[UNMAINTAINED]" [1]

[1] [https://github.com/harthur/brain](https://github.com/harthur/brain)

~~~
simoncion
> I normally put a big "[DEPRECATED]" notice at the beginning of the README.

Aye. Some folks in the discussion linked to by krschultz complain that "People
sometimes don't read the README and -thus- don't notice deprecation
warnings.". To them I ask: "What makes you think that those sorts of people
will notice anything less than an overlay that _prevents_ them from
interacting with the Github UI for that particular repo?".

~~~
clinta
One concern would be around tools that fetch from github automatically. go get
for example would need some sort of structured metadata if it wanted to
surface an error to a user that a library is deprecated.

~~~
simoncion
> One concern would be around tools that fetch from github automatically.

Sure. But... like... git doesn't know _anything_ about deprecated repos.
AFAIK, that's not a feature of git's repo fetch machinery. Anything Github
would do to address this would _have_ to modify the contents of the repo,
right?

> ...go get for example would need some sort of structured metadata [to do
> reasonable repo deprecation warnings]

I mean, the JavaScript development community has -collectively- decided on a
_huge_ bundle of ad-hoc standards. I bet that it would be trivial for the
signatories of the open letter to decide on a tagging mechanism to use in
their README files to indicate repo deprecation. Do you disagree?

~~~
clinta
Go get does not start with a git clone. If you go get example.org/pkg/foo go
fetches [https://example.org/pkg/foo?go-get=1](https://example.org/pkg/foo?go-
get=1). So coordination between go and github could implement something for
deprecated repositories without changing anything in git.

More details here: [https://golang.org/cmd/go/#hdr-
Remote_import_paths](https://golang.org/cmd/go/#hdr-Remote_import_paths)

~~~
simoncion
> Go get does not start with a git clone.

Fair enough. (I don't use go, so I'm unaware of pretty much _all_ of its
internals.) [0]

> ...coordination between go and github could implement something for
> deprecated repositories without changing anything in git.

A couple of things:

* This only fixes things for Golang. It doesn't fix it for the couple-thousand other tools that pull things from Github.

* I never suggested changing things in git. That would be freaking nuts. :) EDIT: Or did you mean "without changing anything in the git repo"? If you meant that, then I strike this bullet point and apologise for the noise. :)

* Frankly, having a well-known file _in_ your Git repo that contains meaningful tags seems _far_ more compatible than changing git, or altering the $BUILD_TOOL<->GitHub integration... for one thing, the convention could be trivially adopted by non-git users. :)

[0] Thanks for the documentation link, BTW! :D

------
deathanatos
This, I feel, is the most important bug, even though it precedes the list:

> _We’ve gone through the only support channel that you have given us either
> to receive an empty response or even no response at all. We have no
> visibility into what has happened with our requests, or whether GitHub is
> working on them._

I'd like to call out that the GitHub user @isaacs maintains an _unofficial_
repository[1] where the issues are "Issues for GitHub". It's not much more
than a token of goodwill from a user to open a place like that to organize
bugs (GitHub: you are lucky you have such a userbase!), but it's the best
thing I know of for "has someone else thought of this?"[2]. Many of the issues
that have been filed there are excellent ideas.

[1]: [https://github.com/isaacs/github](https://github.com/isaacs/github)

[2]: though I'd say if you also think about it, you should _also_ go through
the official channel, even if just to spam them so they know people want that
feature.

------
Osiris
The author mentions that if GitHub was open source, they would implement these
features themselves.

Gitlab[1] is an open source repository manager that supports local installs as
well as public hosting at gitlab.com. If author appreciates open source,
perhaps they should put their efforts into improving an existing open source
option rather than relying on a proprietary solution.

[1] [https://gitlab.com/gitlab-org/gitlab-
ce/tree/master](https://gitlab.com/gitlab-org/gitlab-ce/tree/master)

~~~
zanny
This. When you are tired of github, start using gitlab, and realize your
mistake going forward and stop making it, over[1], and over[2], and over[3].

[1] [http://sourceforge.net/](http://sourceforge.net/)

[2] [https://code.google.com/](https://code.google.com/)

[3] [https://bitbucket.org/](https://bitbucket.org/)

~~~
chei0aiV
Sourceforge runs Apache Allura, which is open source.

~~~
tcdent
What's realistic timing for getting a feature you contribute (and receive
approval) deployed and available for use?

~~~
sytse
The length of the merge request cycle depends on the complexity of the
feature. Simple fixes get merged in days, average features take weeks and
sometimes the review suggestions take multiple months to implement. After
merge it will release in weeks so since we're on a monthly rel cycle.

------
jballanc
It's 2016, and GitHub is stagnant.

GitHub used to bill itself as "Social Coding", but the "Network" graph has not
seen _ANY_ updates since its original introduction in April of _2008_. Issues
has seen _very_ few updates. Even the OSS projects that GitHub uses
_internally_ have grown stagnant as GitHub runs on private, internal forks and
maintainership passes to non-GitHub-employed individuals (e.g.
[https://github.com/resque/resque/issues/1372](https://github.com/resque/resque/issues/1372)).

The word "Social" no longer appears on GitHub's landing page. They're chasing
some other goal...whatever it is.

~~~
dominotw
> They're chasing some other goal...whatever it is.

I've been puzzled for a while with what github is doing hiring so many social
impact employees.

[https://twitter.com/agelender](https://twitter.com/agelender)

[https://twitter.com/_danilo](https://twitter.com/_danilo)

[https://twitter.com/rachelmyers](https://twitter.com/rachelmyers)

[https://twitter.com/nmsanchez](https://twitter.com/nmsanchez)

[https://twitter.com/BiancaCreating](https://twitter.com/BiancaCreating)

[https://twitter.com/ammeep](https://twitter.com/ammeep)

[https://twitter.com/davystevenson](https://twitter.com/davystevenson)

Maybe something more noble than a social coding site?

~~~
Estragon

      Maybe something more noble than a social coding site?
    

I doubt it. Github has a reputation problem. I wouldn't put anything sensitive
on there, given the attitude github leadership showed about privacy ethics in
the Julie Horvath incident.

~~~
pekk
Even if you don't have anything against Github relating to the Horvath
incident, there are other things like Github shutting down people's projects
because they wrote a doc containing the word "retard." In other words, now
they are in the business of regulating the _content_ of open source projects
(beyond obvious precautions like not hosting stolen credit card databases,
child porn, etc.)

They seem to think they're too big to fail.

~~~
avinassh
They also removed [0] C Plus Equality [1] project twice. Even Bitbucket [2]
and Google [3] also removed it.

[0] - [https://github.com/FeministSoftwareFoundation/C-plus-
Equalit...](https://github.com/FeministSoftwareFoundation/C-plus-Equality)

[1] -
[https://github.com/ErisBlastar/cplusequality](https://github.com/ErisBlastar/cplusequality)

[2] - [https://bitbucket.org/FeministSoftwareFoundation/c-plus-
equa...](https://bitbucket.org/FeministSoftwareFoundation/c-plus-equality/)

[3] - [https://code.google.com/p/c-plus-
equality/](https://code.google.com/p/c-plus-equality/)

~~~
int_handler
What was the story behind this anyway? I am having a hard time determining
whether this was actually serious or were trying to parody feminist activism.

~~~
sotojuan
It was a joke by 4chan's technology board, made to see if people would take it
seriously (some did and even agreed with it!).

------
zzzeek
We need world class, modern, distributed bug tracking now. If you google
around for this technology, a lot of nice ideas, many using git itself as
transport, were poking around, and around 2009 they started falling silent.
Why? Because GitHub started up and everyone just buzzed over to it like so
many moths to a flame, having learned nothing from places like Sourceforge
about what happens when 90% of the open source world trusts their issue
trackers, which is really a huge part of a project's documentation, to a for-
profit, closed source platform that does not provide very good
interoperability.

If GitHub is kicking back and sitting on their huge valuations, then it's time
to pick up this work again. If issue tracking and code reviews were based on a
common, distributed system like git itself, then all these companies could
compete evenly for features and UX on top of such a system, without ever
having the advantage of "locking in" its users with extremely high migration
costs.

~~~
hk__2
> We need world class, modern, distributed bug tracking now.

Why distributed? You need a central place to report bugs and track them to
ensure they’re not duplicated everywhere.

~~~
monkmartinez
I am not Michael Bayer (but I hope to be more like him someday)... that said,
what I think he means or could mean is that issues would be distributed along
with the repo. Maybe something like a git log for issues that are attached to
and/or part of the repo itself.

Thinking about it, something like this would be sweet. I would immediately
have a snap shot of things that might go boom when I run said software. eta:
Instead, I have to go dig through github itself, which is slow compared to
greping through a git log.

~~~
mintplant
You've described Fossil.

[http://fossil-scm.org/index.html/doc/trunk/www/index.wiki](http://fossil-
scm.org/index.html/doc/trunk/www/index.wiki)

~~~
zzzeek
yes, fossil, you need to get me past this:

[http://fossil-
scm.org/index.html/dir?ci=acbee54e8ba8a3bd&nam...](http://fossil-
scm.org/index.html/dir?ci=acbee54e8ba8a3bd&name=src)

I'm talking about a portable issue tracker format that ideally uses something
like git as its transport (but note: this does __not __mean that the issue
database would travel along with the application 's source code! That might be
nice as an option but not by design). command-line and web-based front ends
can then refer to it. Fossil, OTOH, looks like a huge monolithic web
application / version control system / issue tracker / kitchen sink written in
very hard-coded C.

Looking through some docs, Fossil is anti-git and it claims its own DVCS is a
great improvement over git: [http://fossil-
scm.org/index.html/doc/trunk/www/quotes.wiki](http://fossil-
scm.org/index.html/doc/trunk/www/quotes.wiki). Because Fossil has every
possible feature packed all into one monolithic executable, rather than
relying upon existing systems like diff, patch, etc. this means Fossil is "the
opposite of bloat": [http://fossil-
scm.org/index.html/doc/trunk/www/qandc.wiki](http://fossil-
scm.org/index.html/doc/trunk/www/qandc.wiki) (in fact that is the opposite of
the opposite of bloat....)

------
monkmartinez
I do not operate a popular OSS project, but I have experienced the +1 spam and
it sucks. The suggestions, in my opinion seem rational.

Interesting side note: With the exception of Selenium, most of signees are
maintainers of JS/HTML OSS projects. I wonder if we could objectively compare
JS to <lang> projects in terms of the problems mentioned in the document. For
example, there is a strong correlation between +1'ers and JS repos vs. Python
or vice versa. Perhaps, we could walk away with JS devs are more chatty than
CPP developers when discussing issues... I don't know, just a thought.

~~~
ketralnis
I think it's just monkey see->monkey do. As soon as one person said +1,
everyone that saw it thought that that's just how you voted for stuff. It's
the same reason you see comments on HN or reddit that just say "This." or that
if you leave your shoes by the door, everyone else will do the same. I doubt
these people keep doing it if you ask them not to.

~~~
maxaf
There's an old story about this man who stood quietly next to a closed door in
Moscow, said nothing to no one, and did nothing else of interest. Eventually
others joined him, and before long a queue has formed. No one knew what they
were standing in line for.

Monkey see - monkey do.

~~~
semi-extrinsic
One of Milgram's experiments (not the infamous one) tested this, using people
standing on the sidewalk looking up.

[https://youtu.be/P0e6zG8IbE8](https://youtu.be/P0e6zG8IbE8)

~~~
ars
He might think he's testing conformance, but he actually just tested
curiosity.

~~~
ywecur
Wouldn't they at least ask after a while if that was the case?

~~~
ars
What makes you think they didn't? I saw lots of people look up, check the
people around them and keep going.

------
Permit
This first request is the anti-thesis of GitHub's simple approach:

>Issues are often filed missing crucial information like reproduction steps or
version tested. We’d like issues to gain custom fields, along with a mechanism
(such as a mandatory issue template, perhaps powered by a newissue.md in root
as a likely-simple solution) for ensuring they are filled out in every issue.

Every checkbox, text-field and dropdown you add to a page adds cognitive
overhead to the process and GitHub has historically taken a pretty solid
stance against this.

From "How GitHub uses GitHub to Build GitHub"[1]:
[http://i.imgur.com/1yJx8CG.png](http://i.imgur.com/1yJx8CG.png)

There are tools like Jira and Bugzilla for people who prefer this style of
issue management. I hope GitHub resists the temptation to add whatever people
ask of them.

[1] [http://zachholman.com/talk/how-github-uses-github-to-
build-g...](http://zachholman.com/talk/how-github-uses-github-to-build-
github/)

~~~
jasode
_> adds cognitive overhead to the process _

Yes! The maintainers _deliberately want_ to add cognitive overhead so the
quality bar for creating issues is higher.

By having simple zero-friction forms, you haven't removed cognitive overhead.
You've simply _shifted_ the cognitive load into the followup messages asking
for clarification of "reproduction steps", "version tested". The issues'
threads therefore begin with "meta" type questions which _duplicate_ the
checkboxes and dropdowns you were trying to avoid.

The default can remain zero-friction but it seems very reasonable to offer
options for maintainers to gain some control over their inbox.

~~~
ams6110
So use a real issue tracker. Most of the big ones integrate with github. Why
should they reinvent this wheel?

~~~
jclulow
If not to be a hosted software lifecycle tool, what the hell is Github even
for?

~~~
ams6110
"Software lifecycle tool" is too vague for a product to have focus and open to
too many interpretations as to what it should include. Even limiting scope to
issue tracking, there are different points of view on how that should work and
several widely-used but rather different software alternatives to choose from.

And how many teams spend the first three months of a project building a custom
issue tracker because they don't like any of the off-the-shelf options? Trying
to get issue-tracking "right" is a black hole for a company like github. Which
is probably why they provide the bare minimum free-form issue and that's it.

------
jasode
The bullet points of complaints feel like a continuation of Linus Torvald's
refusal of github pull requests in May 2012.[1]

Taken all together, it seems like github is on a path of alienating their most
valuable members. Github was unresponsive to Linus' feature requests and it
turns out that theme continues almost 3 years later.

If github plans to evolve into a full-featured ALM[2] like MS Team Foundation
or JIRA instead of being relegated to being just a "dumb" disk backup node for
repositories, they have to get these UI workflow issues fixed.

[1][https://github.com/torvalds/linux/pull/17#issuecomment-56546...](https://github.com/torvalds/linux/pull/17#issuecomment-5654674)

[2][https://en.wikipedia.org/wiki/Application_lifecycle_manageme...](https://en.wikipedia.org/wiki/Application_lifecycle_management)

~~~
treve
I don't see anything wrong with going after the massive amount of smaller
project with simple needs, instead of the few large projects & popular
projects with very specific needs.

If github evolves to the projects you're mentioning, you'll surely alienate
the many more casual users. I personally hate working with the bloated
applications you mention.

------
bsder
Distributed revision control users whining about centralized repository
lacking features.

Ummm ... anybody getting the irony here?

And, from a GitHub business perspective, why do I hear Lily Tomlin: "We don't
care. We don't have to."

Everybody anointed GitHub as "the chosen one" over strenuous objections from
some of us that creating another monopoly for open source projects is a _bad
idea_.

Pardon me for enjoying some Schadenfreude now that GitHub leveraged the open-
source adoption into corporate contracts and now doesn't have to give two
shits about open source folks.

Lily Tomlin's Phone Company Sketch:
[https://www.youtube.com/watch?v=CHgUN_95UAw](https://www.youtube.com/watch?v=CHgUN_95UAw)

~~~
Perceptes
I'm an open source project maintainer and share many of the pain points
outlined in the document, but I also totally agree with you. Giving control of
your project to a company means losing control and having to resort to
desperate pleas like this. This is simply what happens when you can't fork it
yourself like you could with an open source project.

It's likely that GitHub will alleviate these pain points in time, but the
lesson is the same: let a company control your destiny and you can no longer
have what you want or need when their interests diverge from yours, even if
their system is the best there is and was radically better than everything
else at the time you switched to it.

------
asb
There's been no mention of phabricator yet so I thought I'd give it a shout
out. It's used by LLVM, FreeBSD, Blender, Wikimedia and others and I love it.
It's under very active development and even if it doesn't solve every issue in
this letter, by using an open source tool for development you of course have
the option to customize it to the needs of your community.

~~~
zzzeek
I'm looking very closely at Phabricator, it looks quite nice.

------
marknutter
Is this a case of the squeakiest wheels getting the grease? What if these
problems aren't representative of the overall user base? What if far more
people prefer a more simple, minimalistic interface than an ultra-
customizeable interface with myriad custom actions and events. I've always
appreciated software that deliberately keeps things simple (Basecamp and
Workflowly come to mind). It sounds like these people want a full blown
Jira/Stash installation.

------
AndyKelley
I don't like the general feel of these suggestions. It sounds like more
bureaucratic features, the lack of which is a big part of why GitHub is so
pleasant.

Making an issue or a pull request feels like having a casual chat with the
project maintainers. Adding fields and other hoops to jump through puts
distance between people.

~~~
lorenzfx
I guess for maintainers of popular projects, everybody's "casual chat" (by
people who did not read CONTRIBUTING.txt, do not supply the version of
relevant software they are using etc.) is not as fun as it is for you.

------
carapace
Wow, what a bunch of whiners. If you hate github so much why don't you just
fork it and fix-- Oh, right. It's not open source.

Well, there's your problem right there.

(I have sooooo much more in this vein but I'll spare you. ;-)

EDIT: No I won't. Fuck it. This is too ridiculous.

These guys (and they are all guys) chained themselves to github's metaphorical
car and now they're complaining that the ride is too bumpy and the wind is a
little much.

Don't whine about not getting to sit inside the car! Unchain yourself and go
catch one of the cars where the doors are unlocked and open and the driver and
other passengers are beckoning you to join them. (Apologies for the mangled
metaphor.)

These folks come off to me like masochistic babies.

~~~
santix
+1

Shouldn't we (the OSS community) have an open source, roll-your-own version of
something like GitHub? Like, the repo-management equivalent to a phpBB or a
Wiki or a Wordpress.

We do have the separate components, though maybe the hard part is to glue them
together. But still, it is something what would be worth the time and effort,
wouldn't it?

------
beshrkayali
I do like Github, and I understand how it makes the entire process of
maintaining a code repo a lot easier, but what I'd genuinely like to know is
why don't big projects just move to their own thing? I understand that there
isn't a single solution that exactly matches what Github has, and that
maintaining your own git server + git management/issues/etc.. app is a pain,
but I see it as the only real solution. Developing in the open can't be done
on platforms where restrictions apply, and they do apply. I'm saying this with
no intention of sounding like a jerk, but 18 project maintainers and/or
developer need to write an open letter to get Github to give'em a "me too"
button? I understand the issue, but i still find it rather silly.

The only aspect I could think of where Github has the pro is the community of
developers it has, but does it really matter that much? Especially for
established/big projects that probably don't care about the fork/stars
numbers, or the random look around-ers that pass by.

~~~
tyre
> I understand that there isn't a single solution that exactly matches what
> Github has, and that maintaining your own git server + git
> management/issues/etc.. app is a pain

You outlined exactly why people don't build their own or use another system.
Github is the best there is. That doesn't mean it doesn't have problems, but
if your company/project/expertise isn't focused in collaborative development
and/or version control, you're just distracting yourself by building your own.

The authors are not saying "we can build a better Github." They have
complaints and would like them resolved, but don't see a good way of having
that happen.

~~~
beshrkayali
> Github is the best there is.

Doesn't matter really as it's still a locked platform. The argument they're
making is that they're developing in the open and they'd like some sort of
expedited treatment because of the size of the project or because they're
doing OSS. I don't think those two can go hand in hand all the way.

------
anarchy8
I feel like there is a great opportunity right now for anyone to make a Github
replacement. Sounds like a lot of these features are sorely needed at the
moment. Why has Github been complacent?

~~~
ben174
By their very nature, git repos are one of the easiest things to migrate.
Simply point at a new remote and push, and that's really it. It means that,
unlike many other services, I could see GitHub being completely abandoned
almost over night. If something better came along.

~~~
mynewtb
You would lose the issues.

~~~
detaro
True, but thanks to the API and their relatively simple structure it's
reasonably easy to at least copy their contents as well. Linking them
correctly to user accounts on a new platform is probably the biggest issue.

~~~
johnmaguire2013
Users with public SSH keys would be easy:
[https://github.com/JohnMaguire.keys](https://github.com/JohnMaguire.keys)

When a new user signs up, ask them for their existing Github username and to
upload an SSH key that matches.

------
notabot
My company pays me to work on a fairly old-school free software project and we
run our own git service. Our workflow is email based so we won't ever consider
switching to GitHub.

That said, we do sometimes consider setting up an official mirror on GitHub.
Ideology aside (some team members might think we shouldn't promote a propriety
solution for free software project), the main thing that puts us off is that
there is no way to disable pull requests. Closing all pull requests by hand is
not appealing; leaving all pull requests open is not desirable. We can
probably write a bot to close pull requests, but that is just yet another
administrative burden.

Not sure if GitHub will ever consider allowing users to disable pull requests
though. That seems to go against GitHub's core interest.

~~~
justincormack
FreeBSD has worked out a means of accepting pull requests on their github
mirror, guessing using the API.

~~~
notabot
I myself don't really see any motive of doing that. It is administrative
burden (maintaining the service that bridge API and existing system, managing
GitHub accounts / tokens). Compare that to the number / quality of pull
requests received [0] [1] and I find RoI of doing that very low.

[0]
[https://github.com/freebsd/freebsd/pulls](https://github.com/freebsd/freebsd/pulls)
[1]
[https://github.com/torvalds/linux/pulls](https://github.com/torvalds/linux/pulls)

------
arasmussen
I work on a very relevant project called Product Pains.

React Native, the open source project, is using Product Pains instead of
GitHub issues for bug reports and feature requests. This is because there were
thousands of open issues and, just as this document mentions, it's impossible
to organize them. The comments are all "+1" and it's really hard to tell
what's important and what's just noise.

If you take a look at [https://productpains.com/product/react-
native?tab=top](https://productpains.com/product/react-native?tab=top) you'll
see the power of being able to vote on these issues.

So why's Product Pains relevant?

1\. It's a temporary alternative to GitHub issues. I'm guessing GitHub will
get to adding votes eventually. If you want to use Product Pains for
organizing issues for your open source project, go for it. I'll even give it
away to you for free.

2\. It's a community dedicated to improving products. This document is chock-
full of great, constructive, actionable feedback. Product Pains is a community
built for posting exactly this. You can post feedback publicly, about any
product, people can vote on it, and posts with a lot of votes create a social
responsibility for the company to respond.

3\. It's a way for your voice to be heard. Posting on Hacker News lasts a day
and will get your voice heard. If you post actionable, constructive feedback
on Product Pains, and 150 people vote on it, it lingers waiting for GitHub to
do something about it. Around 600 users on Product Pains are also React Native
developers. They'd probably be ecstatic to vote on constructive feedback for
GitHub.

For example, go make an account and vote here:
[https://productpains.com/post/github/implement-voting-for-
is...](https://productpains.com/post/github/implement-voting-for-issues/)

------
mplewis
Bitbucket kills GitHub issues with these two features:

\- Multiple assignees for an issue \- An "Approve" button so that maintainers
can stamp a PR with the seal of approval

~~~
diezge
Surprised I didn't see my personal favourite mentioned - the unlimited free
private repos!

~~~
minimaxir
To be fair, GitHub has to make _money_.

None of the complaints are about the GitHub business model, which is IMO
pretty fair.

~~~
diezge
True, I guess with Atlassian it's different as their actual flagship product
is Jira (and I assume the people who buy the paid-for BB packages are loyal to
BB due to things like the free repos so it evens itself out).

------
neilgrey
Yup, I love GH, use it every day, but issue management is the pits.

It'd be really nice if I could custom sort the queue of issues so that I know
what's next up in my queue of things to do; right now I've got 5 tags called
NextUp:1 -> NextUp:5 on each repo; this takes way more manual updating than a
simple drag/drop widget.

Like they mentioned, having a voting system would be super useful for knowing
what matters -- I cringe every time I leave a +1, so I've gotten into the
habit of at least adding a comment after it --- but the premise and the pain
are the same.

~~~
ma138
We created ZenHub - [https://www.zenhub.io/](https://www.zenhub.io/) \-
specifically to solve these problems.

The addition of a task board in the GitHub interface allows you to communicate
both the priority and progress of GitHub issues.

While adding a +1 button to comments allows feedback without clutter.

Best of all, it is free for Open Source :)

You can read more on why we created ZenHub here - [https://medium.com/axiom-
zen/introducing-zenhub-2-0-c352a12c...](https://medium.com/axiom-
zen/introducing-zenhub-2-0-c352a12c2ec2#.qd71ypvkl) and get in touch with us
via our public support repo here -
[https://github.com/zenhubio/support](https://github.com/zenhubio/support)

I hope we can help improve your GitHub experience!

------
rmchugh
A shame that GitHub aren't more responsive to the community that enables their
success when they make such a big deal of their openness. It is also our own
fault that we have allowed ourselves to become dependent on a single provider
of a relatively simple service.

That said, I'm extremely grateful to the platform for enabling collaboration
on open source and to the company for its work on Git, Resque etc.

GitHub's strategy is to open source everything except the business critical
stuff, but it seems to me that their business is in enterprise support rather
than in actual software. Perhaps they should just open source the whole
platform and count on their service business being enough to carry the
company?

------
jondubois
I like GitHub issues as they are. I wouldn't like to force people to adhere to
a particular format when reporting problems.

I find it strange that some project maintainers get annoyed when people use
the issues section to post questions. What's wrong with that? A question can
reveal design failures about your software... Maybe if your software was
better designed, people wouldn't be asking the question to begin with.

I do think there should be a +1/like button though.

~~~
joncalhoun
Have you ever tried to maintain a popular OS project on Github? Github issues
feel great until you start using them at scale, and then they start to fall
apart without some structure. This is especially pronounced in open source
where many issues come from people who aren't familiar with what information
you need in an issue to quickly resolve it.

I don't think the authors are requesting that this be made mandatory for all
repos, but instead they just want the option to set up rules for repos they
maintain. As someone giving up their free time to offer software for the rest
of us, it seems only fair to let them set the rules about what they need
before they can resolve an issue.

The biggest issue I see OSS maintainers running into is that they likely
aren't the voice that Github listens to most anymore. If they can get some
companies that pay for Github Enterprise to sign their letter as well that
would likely help prioritize these features.

~~~
jondubois
My project's main repo has 150 issues (only 7 still open) and it works out
pretty well. Usually contributors will answer each other's questions and help
close issues.

I suppose that could be a problem if you have 7000+ issues (as is the case for
Docker) - But those projects represent an extremely small percentage of all
OSS projects on GitHub. Also, these projects usually have a lot of
contributors, so maybe those contributors could help filter through and
tag/close issues as necessary?

------
athenot
I have mixed feelings about these requests. Yes it would be nice to have these
extra features in GitHub. Its issue handling has always been a bit light on
the workflow side—but IMHO has made up for it with a pleasant way to organize
conversation around issues. The simple and smooth UX is part of what makes
GitHub so great.

For the opposite side of the spectrum, there's the Bitbucket+Jira combo. It is
customizable to a PM's heart's content, and in the process can become a mess
of a tool.

~~~
alfonsodev
I have mixed feelings about custom fields, I'd like Github UI to become as
burden as Jira, but in the other hand 'reactions' as Slack or Facebook are
implementing would make much easier to follow a discussion without so much
scroll down.

------
aaron695
After the whole incident where they deleted forks of a project without notice,
due to their belief on what is and is not appropriate words to use in code
without an apology I think we really need to re-assess GitHub in general.

Their 'control' of code and lack of respect to the people running projects is
very disappointing and they seem to not want to move forward on the issues.

I'm surprised the open community is allowing this de-facto ownership of the
worlds code and how it's written to take place, I'm not so sure they are a
benevolent dictator.

[https://www.techdirt.com/articles/20150802/20330431831/githu...](https://www.techdirt.com/articles/20150802/20330431831/github-
nukes-repository-over-use-word-retard.shtml)

------
guessmyname
Interesting petition, and I agree with it; but I wonder why are all projects
mentioned in the _Signed by_ section based on JavaScript? I know there are
other languages involved in some of those projects like C++ and Java in
Selenium and PhantomJS but this specific thing in the document makes me
believe that only JavaScript developers _(at least the ones using GitHub)_ are
more prone to complain than other type of developers.

~~~
sotojuan
It's simple: This was made by a JS developer who shared it on Twitter and
whose followers/community friends are more likely to be JS developers.

------
pvorb
The problem is that GitHub has a monopoly and is considered _the_ current
standard for Open Source. But I think that once some of the major projects
move to alternatives like GitLab (which has many of the features described in
that letter) GitHub will have to obey its user base. Unfortunately no Open
Source project with a large user base will dare to do the first step.

~~~
sytse
There are some open source projects with a large user base taking the step to
us, for example
[https://gitlab.com/mailman/mailman](https://gitlab.com/mailman/mailman)

Regarding the three demands in the doc:

1\. GitLab has issue templates in EE and on GitLab.com
[https://gitlab.com/gitlab-org/gitlab-
ee/merge_requests/28](https://gitlab.com/gitlab-org/gitlab-
ee/merge_requests/28)

2\. GitLab has the award emoji function that doesn't spam and acts as a voting
system
[https://about.gitlab.com/2015/11/22/gitlab-8-2-released/](https://about.gitlab.com/2015/11/22/gitlab-8-2-released/)

3\. We're open to displaying CONTRIBUTING.md more prominently, please open an
issue on our public issue tracker that contains all our planned features
[https://gitlab.com/gitlab-org/gitlab-ce/issues](https://gitlab.com/gitlab-
org/gitlab-ce/issues)

I'll go sleep now but please ask any questions so I can respond tomorrow.

~~~
pvorb
Yes, I already saw some of these.

Unfortunately, there's no Travis CI integration yet, which I've been using on
GitHub a lot.

I'm evaluating GitLab CI right now. Am I right, that I have to host a runner
myself if I don't want to use a shared runner for my project?

> You can setup as many runners as you need. Runners can be placed on separate
> users, servers, and even on your local machine.

Does "local machine" really mean a non-public machine like my notebook?

Appreciating help from GitLab's CEO :)

~~~
sytse
We would love for Travis CI to offer support for GitLab, they can use our new
commit status API.

But you'll find that GitLab CI is a pretty complete replacement. If you don't
want to use a shared runner you indeed have to use a shared runner.

Running on your local machine can indeed include your notebook.

~~~
pvorb
Thanks for the answer.

~~~
sytse
Welcome. I see an error in my answer. If you don't want to use a shared runner
you indeed have to add one yourself. Please be informed that shared runners
can run Docker images and that we plan to add runner auto scaling with 8.4 to
reduce the queue.

------
rlaferla
Github needs two major features: 1. discussion groups for users vs. devs as
people use issues for it currently. and 2. A searchable "license" attribute
for all projects with standard license templates for MIT/Apache/GPL/etc...
When looking for a source code, you need to consider the platform, language
and license.

------
duncan_bayne
"It's the world's tiniest open source violin"

[https://xkcd.com/743/](https://xkcd.com/743/)

------
aesthetics1
Each and every suggestion is a sane and much needed improvement.

~~~
Royalaid
Especially the +1

~~~
maligree
+1. Fix this.

~~~
dtm5011
me too

------
sqs
At Sourcegraph, we're trying to help solve these problems for developers
everywhere ([https://sourcegraph.com](https://sourcegraph.com)), both in open
source and inside companies. GitHub’s commercial success and contributions to
the world of development are impressive (and I'm speaking as a GitHub user for
8 years), but they can’t build _everything_ developers need on their own.

We’re really pumped about improving dev team collaboration in the GitHub
ecosystem by (soon) letting anyone use Sourcegraph.com’s code intelligence
(semantic search/browsing), improved pull requests, flexible issue tracking
with Emoji reactions instead of +1s (example:
[https://src.sourcegraph.com/sourcegraph/.tracker/151](https://src.sourcegraph.com/sourcegraph/.tracker/151)),
etc.—all on their existing GitHub.com repositories.

All of Sourcegraph’s source code is public and hackable at
[https://src.sourcegraph.com/sourcegraph](https://src.sourcegraph.com/sourcegraph),
so it can grow over time to solve the changing needs of these projects. (It’s
licensed as Fair Source ([https://fair.io](https://fair.io)), not closed
source like GitHub or open source.)

Email me (sqs@sourcegraph.com) if you’re interested in beta-testing this on
your GitHub.com repositories.

~~~
alfonsodev
I think reactions as implemented in Facebook, Slack or Sourcegraph is a really
neat UX solution for the +1 spam problem.

------
fphilipe
My biggest gripe with GitHub has been the notification system. Personally I
can't use the web UI for notifications because they bundle multiple
notifications per issue. This leads to potentially missed notifications since
it is up to me to scan the issue/PR for new comments.

My workaround has been to use email notifications exclusively. I have a Gmail
filter that applies a label to all notifications and skips the inbox. Then in
my mail client I have a smart mailbox that only shows me unread notifications
with that label (or that folder, from an IMAP perspective). The smart mailbox
then shows me a counter of unread notifications. This way I don't oversee
comments when multiple ones are made in a PR.

Problem 1: No context in these notifications. It would be nice if these emails
could show the code in question for diff comments or the entire comments
thread.

Problem 2: Now what is really bad with these notification emails is that the
link "view it on GitHub" sometimes no longer links to the comment I'm being
notified of. This happens when the comment was made on a PR on a line of the
diff that no longer exists, as sometimes is the case when new commits are
pushed. I then have to go to the main PR page, expand all collapsed "foo
commented on an outdated diff" comments and manually search for the comment in
order to get the context and be able to reply.

By fixing problem 1, problem 2 would be automatically fixed with it and make
my workflow much more productive. Is there anyone else annoyed by this?

~~~
shurcooL
> Personally I can't use the web UI for notifications because they bundle
> multiple notifications per issue. This leads to potentially missed
> notifications since it is up to me to scan the issue/PR for new comments.

I think the bundling aspect is an awesome feature! I can read multiple new
comments all at once, with context in mind and less total context switches.

About being able to miss new comments - doesn't the link in the notifications
UI take you directly to the first unread comment?

------
felhr
I just created and maintain a little Android library (a very rewarding
experience by the way) so most of the complaints about Github doesnt really
apply to me because the size and reach of my project (I understand the point
perfectly though).

But I read some complaints about the users and the issues they tend to open
and I fully agree. They are a minority but I can't only imagine what people
with bigger projects have to deal with. This is what I've found:

\- People with little to zero experience in the language/framework that simply
state that my project doesn't work without providing more information and
sometimes they didn't reply to my "give me more info" inquiries.

\- Guys who just want to get their homework done and They are basically trying
to get it done using me as non-paid freelance.

\- And my favourite one, junior dev in a company, he needs to get their work
done with more pressure than the previous one so became anxious about their
problems and I feel it even via email. Eventually He gets the thing done but
He notices I changed the build system to Jitpack for better dependency
handling and and start to complain about Man in the middle attacks to his
company and black-hat hackers replacing my lib with a malicious one (I guess
it could happen but come on).

But it is a very rewarding experience besides these anecdotical cases

~~~
jitpack
Hi. your junior colleague might be interested in the security answer here
[https://jitpack.io/docs/FAQ/](https://jitpack.io/docs/FAQ/). It's an
important matter so will be happy to answer any more questions via
email/gitter.

You can also run JitPack on-premises and have full control over build
artifacts.

~~~
felhr
Fortunately not my junior colleague! just a junior dev using my lib in his
company's project. Thank you for the FAQ. I will forward it to him

------
runn1ng
All this problems seem to me like _good_ problems to have.

They all seem to stem from the fact that _github is too successful_. And too
many people are on github and too many people are using it, often in wrong
ways.

Of course github should solve them all. But still, it's still better to have
problems with too many people and too much interest, than have the opposite
problem - dying platform that people are leaving (see: sourceforge and Google
Code).

~~~
pvorb
It's not a good problem for the Open Source community after all.

------
dragonsh
Look at kallithea SCM at [http://kallithea-scm.org/](http://kallithea-
scm.org/), we have used it and in most cases it works well. Also it supports
both git and mercurial. Python should learn a lesson when they decided to move
their repository to closed source system like github. But obviously as people
use Facebook, developers use github for the same reason, network effect.

------
vmarsy
A lot of these points are fair and interesting, but I fail to grab some of the
points, especially that one:

    
    
      Ability to block users from an organization.
    

What does blocking users mean? Blocking from commenting/making PR/cloning?

Why blocking a whole organization from an _open source_ project? What would
prevent such users to use a personal account instead to do what they
organization counterpart is blocked from anyways?

~~~
jessaustin
A more plausible interpretation would be that a particular GitHub organization
might wish to block the inputs of a particular user across all its projects.
That is, the phrase "from an organization" is adverbial and clarifies "block"
rather than "users".

~~~
vmarsy
You're probably right! I don't use organization accounts so I'm not sure what
was the issue, it would be to prevent haters to troll on every project of a
particular company?

~~~
jessaustin
Yes that would make sense to me, but keep in mind that any user may create an
"organization", so this might just be a bunch of repos associated with e.g. a
particular framework rather a particular company.

------
some-guy
I work at a large company with a central GitHub Enterprise instance, and we
use GitHub as a code-reviewing and code-hosting platform. Everything else
(including build-automation) is integrated through web-hooks to Atlassian
tools for many of the reasons noted in this letter. It works for us, but I am
hopeful that GitHub will listen and maybe someday we can have everything on
there.

------
teen
I actually disagree with some of these suggestions, I find the simplicity of
Github issues is what makes it so great. I think this should be solved with
3rd party tools, such as waffle.io

------
mpdehaan2
While I don't maintain Ansible anymore, +9 billion on this. GitHub is hard at
scale.

GitHub is fantastic because everyone is on it, but the issue system has not
improved since inception - and I felt the UI changes have actually stepped
back.

We had to implement our own bot to comment on tickets that did not appear to
follow a template, and I would have given a kingdom for a template that let
people filter their own tickets into whether they were bugs or feature
requests or doc items.

We also had a repo of common replies we copy and pasted manually (this because
there was so much traffic and me replying quickly would likely tick someone
off - but this too could have been eliminated mostly with a good template
system). Having this built-in (maybe I could have picked a web extension)
would have also been helpful.

So many hours lost that could have been features or bugfixes - and by many, I
mean totally weeks, if not cumulative months.

GitHub does the world a great service, and I love it, but this would help
tons.

I always got a response when I filed a ticket - ALWAYS - but a lot of them
were in the "we'll take that under consideration" type vein.

I feel opening GitHub RFEs up to votes is probably not the answer to serve the
maintainer side of the equation, since users outnumber maintainers, but these
needs to be done and would greatly improve OSS just based on expediting
velocity.

If you don't use the GitHub tracker you lose out on a lot of useful tickets.
However, if you use it, you are pretty much using the most unsophisticated
tracker out there.

It's good because there's a low barrier to entry, but just having a template
system - a very very very basic one, would do wonders.

A final idea is that GitHub really should have a mailing list or discussion
system. Google Groups sucks for moderation, and I _THINK_ you could probably
make something awesome. Think about how Trac and the Wiki were integrated, for
instance, and how you could automatically hyperlink between threads and
tickets. The reason I say this is often GitHub creates a "throw code at
project" methodology, which is bound to upset both contributor and maintainer
- when often a "how should I do this" discussion first saves work. Yet joining
a Google Group is a lot of commitment for people, and they probably don't want
the email. Something to think about, perhaps.

Also think about StackOverflow. It's kind of a wasteland of questions, but if
there was a users-helping-users type area, it would reduce tickets that were
not really bugs, but really requests for help. These take time to triage, and
"please instead ask over here and join this list" causes people pain.

I love all the work to keep up site reliability, maybe I'd appreciate
more/better analytics, but I totally say this wearing a GitHub octocat shirt
at the moment.

------
thockingoog
I could rant for hours about all the things GitHub doesn't do (or does wrong)
for "real" software development.

+1 from the Kubernetes project

------
john2x
I wish Github would add a "Discussions" tab for repos, so projects don't need
to create a separate Google Group (which require a Google account!) for
questions-that-are-not-quite-issues.

------
chippy
There are three groups within GitHub, and this article is about the issues
faced by the first - big open source projects (a small number).

The main bread and butter of GitHub is from private or organizational projects
and do not have these issues

The majority of accounts on GitHub are folks like the majority of HN readers -
developers, coders, hackers and do not have these issues.

So all these complaints are in a sense not applicable to the vast majority of
both GitHubs revenue generating customers and the vast majority of GitHub
users.

------
bad_user
While I like to bitch and moan about stuff myself, I don't really agree with
the first point.

What I like about GitHub's issue tracking is that (compared with alternatives,
such as Redmine or Jira) it is free form. It doesn't force users to fill
information such as steps to reproduce and I don't think it should. And that's
because the needs of every project is slightly different. Consider how
different the "steps to reproduce" are for a web user interface, versus the
usage of some library. Yes, it can be painful for an issue to not provide all
the information required, but on the other hand GitHub does a better job than
alternatives at fostering conversations and keeping people in the loop. I've
even seen projects use the GitHub issues as some sort of mailing list.

On the second point, I do agree that GitHub needs a voting system for issues.
Given that GitHub has long turned into some sort of social network, adding a
voting system for issues is a no-brainer. But then a voting system doesn't
address the problem of people getting frustrated about issues taking too long
to get fixed. +1's are annoying, but sometimes that's a feature and I've been
on both sides of the barricade.

------
rahelzer
Do the undersigned send any money to github? It might be better to phrase your
demand in the form of a question, "how much can we pay you to do this work for
us?"

~~~
rmchugh
GitHub's success is based on its community. Simple fairness says the community
should be respected and listened to, simple business says if the community
doesn't get something back, it will get pissed and go somewhere else.

~~~
tomcam
Again... No thought of how all this gets paid for?

~~~
rmchugh
By GitHub obviously. Improving their platform to maintain their momentum as a
community hub is pretty much a no-brainer as far as I'm concerned.

------
iwwr
Is there an issue tracking system out there that works on top of the Github
issue system?

~~~
rohamg
We would love your thoughts on ZenHub.io [1] - fully integrated issue
tracking, +1, estimates, burndown charts, kanban boards, even a personal todo
list - a lot of the features asked for here, right within the GitHub interface
and presented a lot more cleanly than competing products.

Disclosure: I work on ZenHub :)

[1] [https://www.zenhub.io](https://www.zenhub.io)

~~~
iwwr
Looks nice. How do I add additional organizations after the first one? Can I
send an invite to other organization managers to make themselves available for
ZenHub?

Thanks!

~~~
Cassidy57
Each organization is treated separately, all you need to do is install the
extension and visit a repo of the other org. From there you'll start a 2 week
trial and you'll be able to invite your team members and managers :)

------
ssmoot
+1 to the notification spam. Being @sam on github sucks sometimes. And as far
as I can figure out there's no way to set watching/following/notifications to
opt-in only.

So every time someone who knows a "Sam" uses @sam incorrectly in an issue I
get notified, have to unsubscribe, ignore, and leave a polite message to let
them know they're doing it wrong.

It's really lame that they've never fixed this.

------
Karunamon
Most of this stuff seems pretty common sense and reasonable. I really only
have a couple of objections:

* Issue templating.

It's one thing to prefill the entry box, it's quite another to add fields that
everyone must fill out. I quite like that filling out something on Github is
totally the opposite of filling out something on Jira.

* Issues and pull requests are often created without any adherence to the CONTRIBUTING.md contribution guidelines

This is a people problem that has plagued open source from day one. You cannot
engineer your way around it in a manner that doesn't annoy your contributors.

There was a blurb in here about getting rid of the big green "new pull
request" button, but that was when this link went to a google doc. Good - if
someone doesn't want to take PR's, then they have almost no reason to be on
Github in the first place. Put another way, it's the mark of someone that
wants a repo as a signpost of sorts without actually interacting with its
community.

------
its2complicated
I think if these people have that many issues with GitHub, they should find a
replacement. That's what happened in the Node community and it led to a better
Node. That's a big list of complaints and GitHub doesn't have much incentive
to fix 'em except to silence a bunch of cry babies that are bitching about a
free tool.

------
orf
I've felt the same way. The worst bit is notifications, so I get a
notification that someone replied to an issue I opened. How do I get there?
It's not in my notification page, I have to go to the email and click the link
from there. Things get missed.

GitHub needs to step it up. They got to the top first, but can they stay
there?

------
zAy0LfpBZLC8mAC
What I don't get ... why do people building free software even consider
forcing their users and in particular their contributors to use proprietary
development tools such as github? (Or, for that matter, exclude people from
contributing to their projects who only use free software.)

Next, we'll see public complaints to Microsoft because MS Word doesn't
properly support the way they want to maintain their project's documentation?

I mean, sure, feel free to complain all you like, but how is this not exactly
what was to be expected from the beginning, and why do you expect them to care
in the future, given that you just seem to have realized that they didn't care
in the past, for obvious reasons, and given that their incentives haven't
changed, and there is no reason for them to change in the future?

------
transfire
Many times, I've asked GitHub to add icons for :test:, :doc:, :admin: and a
couple others. I use them in commit messages as it helps categorize the type
of commit. This has to be the easiest kind of improvement imaginable, but they
have never bothered.

------
danielsamuels
I know they've only recently released new permissions for organisations, but
they're still extremely lacking. As far as I can see, there's no way of
setting permissions at a group level.

As an example of how this would be used, we have a Github team within our
organisation which is used for non-technical people to post bugs. These people
have no reason to be able to see or push code to the repository, they only
need to be able to create issues. This applies to every repository in the
organisation. As far as I can see, and without manually adding every single
repository to the team, there's no way of setting global permissions
permissions for a team. This seems like a major oversight to me.

~~~
teen
I just create a single repo for all issues, cross repo, and manage it with
waffle.io. Works well for me, but ymmv

------
Jyaif
I suspect they are focusing on developing their enterprise offering.

Anyway, I found that [http://feathub.com/](http://feathub.com/) addressed my
frustration about the absence of a voting system.

------
kkoch986
I would just love if they could add target _blank on all the links in comments
and issues. I'm constantly navigating away from the issue to view links in
question and then realizing the tab with the issue is gone.

------
kiloreux
My experience with Github support is terrible, if not one of the worst, I once
had an issue and contacted their support and it took them 1 month to respond
to me (literally) I was really surprised by that.

~~~
daniel-levin
I had the opposite experience. I am on the free student plan for private
repos. It has to be renewed annually. It wasn't clear to my how to do so. I
asked, and Scott from Github support contacted me in under a minute and sorted
it out. I was very impressed.

------
shmerl
It's also annoying that Github sometimes is missing some basic features like
attachments to bug reports and comments for instsance. All mature bug trackers
have such feature.

------
itomato
Why do you want GitHub to solve the (very) specific problems of issue and
defect tracking?

They make a facility available as a nicety, but if your project has legitimate
Global impact, you should be looking at (or bootstrapping) a counterpart.

Don't have the revenue for JIRA? Apply for the Free license.

Don't have the stomach for Bugzilla? Turn out a Node/Go alternative.

Don't have the business alignment with Clearquest or Rally? Lower your
expectations to suit your Free (as in beer) SCM tool.

------
jarjoura
There's a lot of great feature requests for issues at the bottom of the
document. Not sure why the document highlights only 3 things above the
signatures.

Yet, I 100% agree with them. I do not understand why Github issues are so
basic. The only feature I feel was added in all of 2015 was making the logging
of every metadata change extremely verbose (read: maybe too noisy now?!).

"Person assigned to the issue"

"Person added label"

"Person removed label"

------
justplay
I personally experiencing this issue. i wrote about this in 2014, you can
check here [http://paritosh.passion8.co.in/post/96619506751/dear-
github-...](http://paritosh.passion8.co.in/post/96619506751/dear-github-its-
time-to-put-karma-in-user) although i am addressing the problem in different
way but the issue is same.

------
technion

         Don’t make it so easy to submit bad PRs
    

I recurrently refer to this[0] PR, and the subsequent discussion, as the
reason why, if any project of mine gets any bigger - it will not be accepting
Github pull requests.

[0]
[https://github.com/technion/maia_mailguard/pull/42](https://github.com/technion/maia_mailguard/pull/42)

~~~
placeybordeaux
Haha what a crazy final exchange.

> uh oh, someone is still sulking [...] We really don't care about the drama

Oh, okay buddy.

------
pekk
GitHub also does not allow deletion of bullshit issues.

------
ajsharp
I get that these are super frustrating issues for these people ( _cough_ guys)
that maintain these repos, but there's something telling about it that it's
all JS people. That last cute lil paragraph really sums it up for me:

> Hopefully none of these are a surprise to you as we’ve told you them before.
> We’ve waited years now for progress on any of them. If GitHub were open
> source itself, we would be implementing these things ourselves as a
> community—we’re very good at that!

LOL. I can't tell if this is "go-fuck-yourself"-level passive aggression, or
mindless hopefulness that there might actually be a universe in which Github
(or a company like it, with hundreds of millions of dollars of venture
funding) could be open source. If I worked at Github, my first thought after
reading this would be "mmmmm yeeeeaaaaaaa y'can g'fuck yr'self", while the
second thought would be "yea, you're not wrong". Generally, passive aggression
gets you nowhere when you're asking for something from someone/something who
owes you nothing (I know, I know, they "owe" their customers _everything_ ).

The Node/React/JS community is hilariously entitled, petulant and childish.
The tone of this whole letter is so god damned millennial, it's mind-boggling,
because they're not wrong about anything they're asking for. But it's _how_
they ask for it that leaves a dry, acid-y taste in your mouth.

~~~
Matachines
Interestingly most of these people are older than the millennial category

~~~
ajsharp
Fooled me ;)

------
dabernathy89
People often ask why WordPress doesn't use Github for its primary development
(they do have official read-only mirrors there), and it's not just because
they already had an SVN-based system in place when Github came to be. It's
because the tooling they already had was more sophisticated, especially
regarding issues.

------
cbr

        We’d like issues to gain a first-class voting system,
        and for content-less comments like “+1” or “:+1:” or
        “me too” to trigger a warning and instructions on how
        to use the voting mechanism.
    

Why bother users with a warning? Turn it into a vote, and then highlight the
vote icon so you can see what happened.

------
vjeux
A proposal for a better way to deal with github issues: a discussion tab.
[https://github.com/dear-github/dear-
github/issues/44](https://github.com/dear-github/dear-github/issues/44)

------
danpalmer
I'd settle for just a fix to the (minor) data-loss bug that I reported nearly
a year ago, and which still crops up once a month or so.

That, and something for code review. Pull Requests are terrible for code
review, and it wouldn't take that much to make them so much better.

~~~
piotrkaminski
I got frustrated waiting for improved PR code review, so I built
[https://reviewable.io](https://reviewable.io). It's best suited for private
repos (since there's a learning curve that make throw off potential open
source contributors) but it addresses a lot of the issues with PRs. Take a
look!

~~~
danpalmer
I've actually looked at Reviewable multiple times for use within our team, but
never decided to use it. From my usage of the demo, it feels complicated.
There are a lot of controls on the screen, and I struggle to tell what exactly
I'm looking at at any given time.

I also tried the demo, and was shocked to see that Reviewable had edited our
PR descriptions to include a big "Review on Reviewable" badge. We currently
make heavy use of PR descriptions in quite specific formats, and it felt like
Reviewable was forcing itself upon us.

To be clear, I'm really glad someone is looking at this problem, and
Reviewable looks like a step in the right direction. I'm just quite
opinionated on code review and developer tools, and I feel like it could be
much better.

~~~
piotrkaminski
Thanks for checking out Reviewable, and sorry it didn't work out for you. It's
definitely a more complex tool than plain PRs but you also get a lot more
functionality in return.

If you checked it out before I added the interactive onboarding (aka
butterflies) and on-demand help you might want to try (yet) again, since I've
been told it makes it a lot more approachable. Otherwise, and if you have the
time, I'd love to sit down with you (virtually or otherwise) to do a short
user study so I can better understand the UX pain points and maybe fix them.

As for the badge, it's actually mostly there to help developers find their way
to the review. In public repos, it's also the marketing payment for the
otherwise free service, but in private repos I can switch it off for you (the
flag doesn't have a UI yet).

I'm always looking to improve Reviewable, but in the end it's unabashedly
opinionated too, and sometimes those opinions will clash -- I'm OK with that.
I'd rather make a tool that some people will love than an enterprise monster
that everyone will love to hate. :)

------
billconan
One annoying issue I found with github is that it doesn't provide a discussion
board. a lot of times, I have a question to ask, it doesn't mean I found a bug
or anything needs progress tracking, but I have to go through the "github
issues".

------
qaq
To what degree a company has to not give a f$#% when maintainers of largest
projects on a platform can't get any feedback (compounded by a fact that some
of those maintainers are very prominent employees of largest github paying
customers)

------
kmfrk
Being a maintainer on a project with some minor community on GitHub is such a
garbage experience.

It’s pretty neat as a general user, but at least you get the impression with
BitBucket that they prioritize productivity and project management. And the
task system hasn't received any significant updates since their inception -
which is a shame, because tasks are an awesome invention, they just have to be
implemented awfully with issues.

I also remember that we recently had to move the entire decision-making
process to Slack instead where I suggested we just use the emoji voting system
to make our decisions with.

What really gets to me is how _adamantly_ GitHub has ignored all the people
who've gone on about this forever. Last time they seemed to care marginally
was when jacobian finally managed to twist their arm and get them to implement
the Close Issue feature, because one repo issue was a radioactive pit of abuse
and invective.

~~~
mpdehaan2
I wonder if the whole "managerless culture" is to blame and is unfixable? (In
other words, why hasn't SOMEONE had this thought about issues in N years? One
is they deem it not a problem, another could be that they think to optimize
for the filer, and the maintainer doesn't matter, or... there's no
organization at all?)

There could be (theoretically) no one to make anyone do anything, and perhaps
the issue tracker is either a quagmire of a codebase or something no one wants
to touch because something else is more exciting?

That's one theory.

My other theory is they spend a lot of time on scaling problems and/or GitHub
enterprise (which I haven't seen) -- and don't really do features anymore.

But it does feel there is no vision for changes to GitHub (maybe they think
it's "solved") and it's ceasing to evolve in noticeable ways in any direction.

Can't really be sure. But I find it interesting. Again, the core is good. It's
just curious to watch it so closely and not see the needle moving in any
perceptible way.

~~~
kmfrk
I like the theory of the flat-office culture or philosophy affecting this.

Then again, it could be the kind of anarchic Libertarian or laissez-faire bent
that we see with reddit that makes it exceedingly different to grant special
permissions and privileges, especially across subreddits/issues/users/orgs. Or
maybe user experience just doesn't matter for today's start-ups; maybe we've
passed the Overton window for start-ups deciding it's not worth caring about
their users.

A lot of the time, I feel like more of a user+ than a(n) (super)admin on my
own repos. I might as well have the permissions and tools to ruin my own
project - in the name of pure unadulterated freedom if for no other reason.

The dashboard and notification system have always been POS, too, so it might
just be that everything that basically isn't tethered to a GUI is on the
bottom of the totem pole.

------
nikolay
GitHub does certain things very well, other - not so much. I really think the
best way to get them to focus is to start contributing massively to GitLab.

Anyway, implementing just voting won't be a such a good idea in the time of
Emoji Reactions!

~~~
metasean
Actually, GitLab counts some emojis as votes - so you can have your :cake: and
eat it too ;-)

\-
[https://about.gitlab.com/2015/11/22/gitlab-8-2-released/](https://about.gitlab.com/2015/11/22/gitlab-8-2-released/)

\-
[https://github.com/gitlabhq/gitlabhq/pull/5724](https://github.com/gitlabhq/gitlabhq/pull/5724)

------
Zikes
Issue spam (in the literal sense) definitely needs addressed as well:
[https://pbs.twimg.com/media/CYI31g1UQAUXQbs.png](https://pbs.twimg.com/media/CYI31g1UQAUXQbs.png)

~~~
pekk
It's my project, why can't I just delete issues like any other bug tracker?

~~~
Zikes
The issues were deleted in fairly short order, but their notifications were
still sent out to all repository watchers and persisted beyond the issue
deletion. Also, most issues were generated mere seconds apart from accounts
less than a day old.

So the issue isn't that GitHub didn't let them clean up the issues after the
fact, but that there were no a) rate limiting options, b) user reputation
options, or c) issue submission filtering options.

Any one of those three would have reduced the impact significantly.

------
peterfpf
This resonated so much with me

PS, it was moved to [https://github.com/dear-github/dear-
github](https://github.com/dear-github/dear-github)

------
jessaustin
Please update the link to [https://github.com/dear-github/dear-
github](https://github.com/dear-github/dear-github)

~~~
colinbartlett
Thanks, I've been trying all day to open the original link on mobile and it
just brings my phone to its knees and never opens. Not even sure what is
behind that link other than perhaps a very large Google doc?

------
yingbo
Funny. It's like "Hi, you are rich. We like you. You should onate your money".

There are tradeoffs, so pick services you like.

------
petke
I guess I don't know how to use githib. You can send bug reports on a project.
But how do you send questions or ask for advice?

------
alexchamberlain
Totally agree with what has been said. However, I find it interesting that
most of the signatories displayed were for JS projects.

------
edem
gog.com has a great mechanic for this which might work here called a community
wishlist [1] where people can submit games whey wish to see and people can
vote on it and eventually they get things done when possible.

[1][http://www.gog.com/wishlist](http://www.gog.com/wishlist)

------
ChuckMcM
I am interested in understanding how much recurring revenue Github is
receiving for hosting these projects.

------
bl4ckdu5t
I've never seen any issues spammed with +1s like the TravisCI request for
Bitbucket support

------
lifeisstillgood
Can anyone post a précis/examples - apparently I do not have rights to see any
spreadsheets at all.

------
thewhitetulip
we maybe need a feature of hotness of a bug, "affects me too", that'll
prioritize issues out of a bucket load of issues, plus on github you first
raise an issue then it is sorted into feature request or bug, can be made
better

------
jp_sc
Classic JavaScripters reaction: throw more tooling at it

------
dang
Url changed from
[https://docs.google.com/document/d/14X72QaDT9g6bnWr0lopDYida...](https://docs.google.com/document/d/14X72QaDT9g6bnWr0lopDYidajTSzMn8WrwsSLFSr-
FU/preview?ts=5698049d), which points to this.

------
johnlbevan2
NB: Duplicate post:
[https://news.ycombinator.com/item?id=10904693](https://news.ycombinator.com/item?id=10904693)

~~~
dang
Since they're both near the top we might as well treat the later post (which
is the other one) as the duplicate.

~~~
minimaxir
The post with ~110 points was killed in favor of the ~50 point post at the
time. In that case using time as the tie breaker might not be the best since
people will have to upvote again.

~~~
dang
In general you're right, but this story was guaranteed not to lack for
upvotes. Indeed it went to #1 as soon as we buried the other one as a dupe.

I realize it's not a big deal, and it's actually a great sign about the HN
community that almost no one cares much about karma. But we do want to try
harder to give the original submitter credit, because then the incentive is
aligned with what's best for the community: finding good stories that haven't
been posted yet.

------
spellboots
:+1:

~~~
snickmy
ahahaha

------
wanstrocity
Chris Wanstrocity is an inept leader, social activists roam the halls in self
glory about their contributions to the world while Kakul spends money on
retreats and hires senior product people who have zero open source or dev ops
experience. This company needs intensive care with new leadership asap or they
will be doomed, Gitlab is salivating right now.

------
xpaulbettsx
While I applaud the initiative, it's also a pretty strong indictment of the
JavaScript / node.js community that there is not even a _single_ non-male OSS
maintainer on this list of important JS projects.

What is being done in the JS community by those who lead it to make progress
on this and who is leading that charge? If the answer is "Nobody", why is that
true?

~~~
arasmussen
Why did this get downvoted? Ugh.

~~~
qaq
Hmm what does this have to do a) with topic b) with node.js?

