
Investigate switching away from GitHub - kristiandupont
https://github.com/eslint/eslint/issues/5205
======
bphogan
Seems like the issue is... issues. Some projects get so popular that it's a
full time job just to respond to issues that lack information.

I've been in software for a long time. There's no tool that solves this
problem. People who don't know your software don't know how to report issues.
They don't know the keywords or nomenclature to search for pre-existing error
messages either.

Switching to another tool won't solve this problem they're having. Typical
engineers - they think issue templates will help. No. I'll just fill in
whatever gets me past the validation cos I'm frustrated.

This might be unpopular, but you're under no obligation to answer those issues
or even have a public issue tracker at all. Turn the issue tracker off if it's
frustrating, and use a private issue tracker for the core team. Or find some
students that want to break into open source and have them be 1st level triage
for your issues. It's a people problem, not a technology problem.

Too many developers forget that software development, even open-source, is 20%
code and 80% people. Documentation and support are a huge part of software.
And software only goes so far to solving that in my experience.

~~~
onlyrealcuzzo
In fairness, he makes a lot of points that GitHub is particularly awful at,
specifically things that aren't very relevant to enterprises (who pay their
bills) and therefore aren't priorities for GitHub.

You're totally right about software being more about people than about code.
That being said, I think maybe you're underestimating just how many issues
ESLint receives and how willing people are to volunteer time to the project.
They've received almost 2500 issues and have essentially 5 active developers.

Yes, you're one hundred percent correct that issues are the problem here.
That's a lot of issues for five people. Period. You're being a little lenient
on GitHub's behalf by not weighting how poorly it does issue tracking which
expounds their problem a great deal.

They're not "typical dumb engineers". They mention nowhere that they'll
somehow end up with less bugs if they leave GitHub. But they believe they'll
be able to more accurately assess issues and turn them around faster by using
a different platform--which if you're familiar with the alternatives, it isn't
the completely facetious assumption you cut it out to be.

Sorry if that comes off aggressive. Not intended. You make great points. Just
wanted to reiterate that GitHub has __some __blame here...

~~~
bphogan
I didn't say typical dumb engineers. I said typical engineers. Looking for
technical solutions when the problems are not technical. That's pretty typical
in my experience.

I'm not underestimating the issues they get. I looked at it before I wrote
what I wrote. It's a lot. But I'm not going to feel bad for them. They have a
massively successful open source project. And only 5 people. Despite lots of
use. I wonder why more people aren't getting involved to triage the issues
instead of looking for a technical solution?

I'm not being lenient on Github either. Their issue tracker is incredibly
limited. It always was. I remember when they launched it and they were very
clear about its simple limitations. Simple is good. Until you're a massive
opensource project using it as a catch-all bin for troubleshooting issues.

~~~
gbhn
There's an API for the github issue tracker. I'm kind of surprised that with
all the other tooling built around github that there aren't really nice issue
trackers that would provide better management and triage workflows and would
then condense to github issues that would work well with dev workflows and
conventions.

~~~
TarpitCarnivore
There are. One off the top of my head is waffle.

------
phasmantistes
> If we move off GitHub, we will immediately eliminate the random noise we get
> through issues.

> At the same time, we'll eliminate drive-by pull requests that also need
> reviewing.

I don't think these are good reasons to move away from GitHub. If your project
is _truly_ popular, then the people who are filing these issues will follow
you to your new home. You'll get a short period of respite, and then you'll be
back where you were before. If your project is only popular _because_ you're
on GitHub... then moving off will not only give you a respite, it will also
destroy your user base.

This is why full-time software engineering teams have PMs. They act as an API
for the engineers: helping others understand what sorts of requests can be
made, what kinds of responses can be expected, and turning away
abusive/malformed traffic.

It simply sounds like this project is popular enough (and >5000 issues in just
over 2 years certainly qualifies as popular in my book) that it needs non-
engineering attention. Get someone to join the team who wants to fill in a PM
role.

~~~
jarek
> Get someone to join the team who wants to fill in a PM role.

That sounds simple. You're volunteering, then?

~~~
daok
I never understood that kind of comment. It's not because someone is
suggesting something that he must fill the position. Same thing about bug,
it's not because something is wrong that it means that the one who report it
must go in the source and fix it. Your comment doesn't provide values at all.

~~~
jarek
No, I'm not actually suggesting that he should volunteer.

But saying "surely someone can just volunteer" is pointless in the absence of
evidence that someone actually _wants_ to volunteer. If anything the evidence
points to not enough volunteer triage PMs - the OSS world is not short on
projects that could use a triager.

~~~
phasmantistes
Oh, that's absolutely true. There are far too few people stepping forward to
fill non-technical roles in OSS. And that's a shame, because I think it would
really help get some projects off the group, and help others keep their
communities together.

But I didn't say "surely someone can just volunteer". I said that they should
"get someone to join". There are a lot of ways to do that, and many of them
involve the current team members being proactive about going out and trying to
recruit someone to fill that role. The OSS communities can't just rely on the
"if you build it they will come" philosophy -- if you really want your project
to grow, you have to be willing to put yourself forward and actively get
people to help you.

~~~
jarek
> There are a lot of ways to do that, and many of them involve the current
> team members being proactive about going out and trying to recruit someone
> to fill that role.

Orrrr the current team members can be proactive and do something that will
reduce the number of bad bug reports they get.

Without Github Issues you might miss out on useful input such as
[https://github.com/kennethreitz/records/issues/10](https://github.com/kennethreitz/records/issues/10)
though.

------
sylvinus
I can't understand why GitHub isn't responding to the "Dear GitHub" people.
They are not requesting huge political changes, it just boils down to a
CONTRIBUTING.md and a basic voting system that many alternatives already have.
It might take a couple weeks/months to spec and develop but they should at
least send some kind of acknowledgement?

Do they actually want all those large open source projects to leave?

~~~
bphogan
For the same reason that the open-source projects don't say yes to all the
feature requests they get... because once you make a new feature, you now own
it. It's so easy to ask. So much harder to support it forever and ever
afterward.

I find it ironic that open-source maintainers sent the same kind of ranting
letter "demanding" certain features in the same "entitled" manner that their
users do to them. :)

~~~
scrollaway
Github is neither open source nor volunteer-based. They are a product which a
lot of people pay for, including most of those who signed the letter.

~~~
bphogan
And I paid for this Mac. Apple doesn't care about my feedback. :)

Just because you pay for something doesn't change the rules. New code has to
be supported. And if it's a business, you have to pay people to support that
new code.

~~~
epistasis
The point is that GitHub, as a fairly new company, is still establishing its
reputation.

By being unresponsive, they are establishing precedent. They can establish the
precedent they want, but it's also ok for people to question which way they're
going to go.

~~~
icey
Heya, random GitHubber here -- I can't provide any information about things
that are in-progress, but we see these threads and are paying attention to
them. The "Dear GitHub" letter, etc all get sent around here, show up in chat
rooms, and get talked about quite a lot internally. We value feedback from all
our users -- GitHub.com users, Open Source maintainers, and our Enterprise
users. There's a lot for us to do to make GitHub better for everybody, and
everyone's feedback is valuable. While it's true that we've put a lot of
effort into getting GitHub Enterprise into the shape we wanted it, it's
important to note that a lot of enterprises use GitHub because of the millions
of people on GitHub.com -- they see how powerful open-source style development
is and want to emulate it internally. It would be utterly disastrous for us to
ignore the feedback of all the users who got us to where we are today.

~~~
crazypyro
I know you are trying to provide some comfort to people and doubt you have
very much impact/authority w.r.t community relations, but this is literally
just another "we value feedback, you're important to us" without any actual
plan to fix the issues or even acknowledgement that they are being worked
on...

There's been no official communication in a _month_ , so I don't think its
unreasonable that projects are starting to look at alternatives and start to
believe that github is unresponsive to their problems.

~~~
icey
Mostly it's about letting folks know we're paying attention. I'm not in a
community function at all (I'm a developer turned salesperson -- I just happen
to be a long-time HN user and thought I'd mention that this stuff isn't
falling on deaf ears). A challenge is that we get thousands of feature
requests all over the board; and no matter what we do, we'll miss something
that people want. That doesn't mean it's not coming, it may just mean that
it's not ready (although to be fair, we are pretty unlikely to ever build
everything people want). It's useful to us to see this feedback (truly), and I
just wanted to mention that we see it. A quick glance at Pulse for the main
GitHub repository shows that there have been over 200 Pull Requests merged
(and shipped) and over 50 issues closed just in the past 7 days -- these are
things that somebody somewhere wanted, even if it's not everything that's on
one specific person's list. That's just in one repository -- there are
similarly active repos with a similar number of ships in the past week.

Can we be better? Absolutely, yes. This is the most "care hard" company I've
ever worked at, and we really want to do things to the best of our abilities.
I know this doesn't help you if there's something you've asked for, or
something you legitimately _need_ and don't have yet; what I hope _will_ help
is knowing that these requests aren't being ignored.

~~~
ossreality
This just doesn't mean anything to us given that these issues have been talked
about for much, much, much longer than a single month. Why is a random
GitHubber telling us this and not someone in a more authoritative position? It
seems painfully obvious to tell people you're working on it, and I think it's
perfectly reasonable to worry when you hear literally /nothing/.

------
makecheck
One of the most ironic things about GitHub is how it seems to have spawned
centrist systems despite being named after a distributed system.

Much like key servers allow people to determine authenticity in a somewhat-
decentralized way, there ought to be a similar way of determining the
“authentic” sites for various projects/people or the official places to log
issues, etc. Then, the whole _network_ can figure out where to find things,
whether or not GitHub or something like it exists, and we can stop asking or
expecting GitHub to provide every feature that we need.

As one commenter on the page put it, GitHub is a place for posting a sort of
software résumé and is an “expected” way to determine what people have
contributed to. Why? Git _itself_ is decentralized; the whole point was
supposed to be that somebody's code might be almost anywhere...and yet, an
ecosystem of centralization emerged.

Similarly, when GitHub went down awhile back, all these things were affected.
Why? Why did people set up systems that depended on the ability to download
from GitHub, for instance?

~~~
dozzie
Quite simple. People in IT (and hobbyst programmers) tend to not learn the
tooling, its features and properties, and reasons behind the tooling itself.
It's all rage about writing things, never mind that somebody had it already
implemented and way, way better.

Look for instance at how programmers deploy their applications (which are
mostly web applications). Are those applications tied to operating system
version somehow? Mostly. Are those programmers using this operating system's
tools for software installation? Hardly. And why? Because it's not sexy
enough, npm or gem are way sexier (despite apt-get or yum being much more
mature and robust).

It really takes a long time to feel how and why the OS works and to work
_with_ the system instead of _against_ it. Don't expect programmers with vast
three years experience to understand their surroundings.

~~~
oldmanjay
"It takes a long time to understand" is synonymous with "can be improved."

~~~
pklausler
Counterexample: the universe.

~~~
astrange
I think the universe has a long list of outstanding feature requests.

~~~
davidhowlett
I wanted to add a few feature requests so I went looking for god on github. I
found god but unfortunately most of the universe has not been open sourced yet
:-(

The physicists are trying hard to reverse engineer it though.

------
jcoffland
I find it really sad when projects grow enough that they start seeing user
input as a burden. It's usually the beginning of the end and a sign of the
hubris that tends to grow out of popularity. Both the author and GitHub itself
are guilty of this. Docker is another good example. They've stopped listening
because they have become too smart for users. When your userbase grows you
need to evolve your methods not make it harder for users to communicate their
needs.

~~~
derefr
They've stopped listening because now they have two classes of users: multi-
million dollar enterprise contracts, and everyone else. I guarantee you that
they're very responsive to the "users" in the former class.

And really, I don't think there's a good solution to this problem: almost all
SaaS businesses are built on the premise that all the free users who join in
the beginning are a loss-leader on the path to acquiring the enterprise
contracts. Even bootstrapped companies are not immune. The pool of non-
enterprise users just can't support engineers' salaries on their own.

The only real way to avoid the eventuality of a SaaS service focusing its
resources on its enterprise customers, is to just avoid using SaaS services.
Maybe use FOSS projects like Gitlab instead.

Though, even then, the people who build themselves up as experts on that FOSS
project will—with nearly the same inevitability—be hired as employees by some
company that wants to sell support contracts _for_ that FOSS project _to_
enterprises. I work at such a company; we're just as enterprise-focused as
anyone else, and we've basically sucked our FOSS ecosystem dry of developers
who would be heavy user-focused contributors, redirecting their attention (via
their salaries) to the enterprise needs.

So, really, I'm not sure if there's any viable solution for most projects.
_Some_ projects, with enough reach, can thrive off having multiple competing
corporate sponsors—that's when you see committees like WHATWG or Khronos
forming, so all the corporate contributors with conflicting enterprise needs
can tug at one-another. But nearly nothing has that level of reach.

~~~
op00to
This happens when you don't keep a strong firewall between upstream and
downstream. When the enterprise development team is also the upstream team,
it's a lot harder to say "no, we don't like this shitty idea that $bigCompany
asked for".

~~~
derefr
Our company (which runs an ASF project you probably have heard of as SaaS for
enterprise customers) is pretty well-separated. Separate bug trackers with
dual tickets, separate mailing lists, etc. The problem is that our corporate
developers make up about 80% of the developers on the upstream ASF project. We
took the ASF developers and hired them.

There are people who want to get things done in the upstream project, and they
try... but they just don't have the resources, because most of the people on
the project are busy doing their jobs.

Excluding corporate-support-contract-of-this-project employees from having
contributor rights to the upstream project might work, but then you get the
opposite problem: a downstream that's increasingly diverged from the upstream
(because if the customers want a feature, but upstream won't take the patch,
forking is pretty much necessary) where the "free core" of the upstream begins
to stagnate because (in relative terms) nobody's eyes are on that code.

------
wildpeaks
My main gripe with Github isn't so much Issues, it's that repos can't be
grouped (the closest would be creating a different account per group of repos,
but then each repo has a separated Issues and Wiki) unlike at Codebase.

And even more importantly, the pricing per repo instead of storage size makes
modular projects too expensive.

Which is too bad because other than those two points, I used to be very happy
hosting at Github :/

~~~
spike021
Seems like an organization does what you're thinking of. It holds several
repositories and several people have access.

But that still has the separate Issues issue.

~~~
bsimpson
I think OP's point is this: Consider Google. Google has many projects on
Github, including Chrome, Polymer, and Angular. Some of those projects have
sub projects (like Chrome Dev Tools or the Polymer Paper Elements). It would
be way easier to browse those repos if there was some hierarchy or tagging
mechanism to them. Instead, there is only the org.

Therefore, you end up with a single large company or project balkanizing
itself into many orgs simply for organization's sake. This, in turn, makes
administration and anything else that crosses org boundaries cumbersome.

To be fair, it's not a problem that most Github projects (or even most popular
ones) have. But, I think the issue the OP is raising is that orgs only let you
group projects at a single level, which makes things hard to organize in a
world that's moving to lots of tiny repos for what may have once been a single
codebase.

------
gionn
Maybe the could just look on how other projects are doing, for example the
docker project has a smart bot to harass bug reporter not stating important
information in the issue.

Problem solved?

~~~
dominotw
i usually dislike bots like those but gordontheturtle is very helpful i must
say.

------
petetnt
People dislike JIRA because they spend so much time adding metadata so they
want a simpler format. They move to GitHub, which dislike because they want to
add metadata to their issues. So they move to Phabricator, so they can
properly add tons of metadata. People dislike Phabricator because they spend
so much time adding metadata...

Obviously the finding the common ground between the two extremities would be
optimal and obviously the both extremes can work for some. The simplicity of
GitHub has always been the major feature of it for me and the low barrier of
entry is always a huge plus. The added noise is inevitable but you can either
ignore it, address it (by adding people just for triaging issues) or try to
avoid it (by raising the barrier of entry).

------
Sleaker
GitLab seems like what they need based on all of their wants. I'm not sure why
more people aren't wanting to move over to gitlab, it's great.

~~~
mcguire
What is GitLab's issue tracking like?

~~~
Sleaker
It's similar to githubs, but it also includes custom weighting on issues. A
much better filtering UI. Ways to mass assign/change issues in one go. You can
view issues for a full group of projects, not just a single repository, along
with being able to have shared milestones across a groups projects. Someone
else also mentioned some of the new features such as Issue templating. Right
now it's just a single but there are plans for having multiple templates.

~~~
tomjakubowski
On the other hand, at least in the self-hosted version of GitLab I use at
work:

* Can't quickly create a whole bunch of new labels -- have to wait for a very slow form submit, which takes you back to the label list, where you have to click "New Label" again. * Can't quickly add labels to an issue -- have to jump off the issue discussion page and edit the issue. * New issue page is very slow to load, and submitting an issue takes almost 4 or 5 seconds (might be our problem). * Closing an issue does a full page reload (which is sloooow. again, might be our problem). * GitLab-flavored Markdown and the default CSS have lot of little problems.

And that's just issues with… issues.

GitLab has improved _quite a bit_ though since I joined the company a year
ago. Every GitLab upgrade we've done thus far has made me a lot happier using
it, so good on everyone working on GitLab for that. I'd still rather be using
GitHub, though I think there are better options that GitHub too.

~~~
sytse
Hi Tom,

In the current version of GitLab you're able to add multiple labels, add a
label while seeing the issue show page and the edit page should be faster.

We're working all the time to make GitLab faster and today we made the issue
page load 3x faster on GitLab.com [https://gitlab.com/gitlab-
com/operations/issues/42#note_3670...](https://gitlab.com/gitlab-
com/operations/issues/42#note_3670049)

There should not be many markdown/css problems in the product as far as I
know. There certainly is still room for improvement in the GitLab UX
(especially on mobile), and we're not happy yet. We hired our second frontend
engineer this week and we're looking for more on
[https://about.gitlab.com/jobs/](https://about.gitlab.com/jobs/)

I hope your problems are solved when you upgrade to GitLab 8.4.

~~~
tomjakubowski
> In the current version of GitLab you're able to add multiple labels, add a
> label while seeing the issue show page and the edit page should be faster.

That's great news that I'm very glad to hear, thanks! Our ops folks are
usually on top of GitLab upgrades, so I don't expect to wait too long :-)

~~~
sytse
Awesome!

------
mchahn
If issues are your only problem then you don't need to leave github. You can
turn issues off on your repo and use a different tracker.

------
bch
> We strongly feel that the code and issue tracker need to live in the same
> location to make it easier to manage and give people one location to visit
> for all of their ESLint-related needs...

For sake of interest I feel compelled to mention that fossil[0] does have a
fully-integrated ticket system[1] (and more[2][3]) that allows code to
reference tickets, and tickets reference code. These tickets and full history
are first-class artifacts that are part of the repository, so are carried from
copy to copy, and updates are transmitted as part of synchronizing repos.

Of course there is more to project management than just tickets, but as a
happy fossil user for many years, I do really appreciate the integrated ticket
management.

[0] [http://www.fossil-scm.org](http://www.fossil-scm.org)

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

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

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

------
jvehent
Fine grained classification and management of issues is why Mozilla is so
reliant on Bugzilla.

Bugzilla is a beast, for sure, and it takes some time to learn how to use it
correctly, but few other systems come close in functionalities, and github is
certainly not one of them.

------
mayank
Only two of the six requirements listed don't seem to be well supported by
Github:

> Must have a way to setup issue templates prescribing what fields are
> required >Must have ways to organize issues other than labeling (milestones,
> priorities, etc.)

Sounds like fertile ground for someone using the Github Issues API [1].

[1]
[https://developer.github.com/v3/issues/](https://developer.github.com/v3/issues/)

------
dhagz
GitHub needs something like what BitBucket has: they have a "new issue
message" that displays to people making a new issue. You can make it say
anything you want, so it's a great place for telling users how to submit an
issue. Sure, it won't ensure everyone follows your idea of a good bug
report/issue, but it's better than nothing.

------
Kinnard
GitTorrent?
[https://github.com/cjb/GitTorrent](https://github.com/cjb/GitTorrent)

~~~
XorNot
Something like this is what we desperately need. Immutable repository SHA's we
can bake into dependencies.

Though IPFS might be less of an impedance mismatch.

~~~
NotUsingLinux
Yes absolutely, I think self hosted conted and hash addressed binares would be
a great thing to investigate!

------
potch
In my experience, hosting code/issues off of GitHub reduces triage time
maintenance burden by reducing the number of contributors.

------
spatten
Ansible has a nice workaround for this that might partially solve the problem
and be less work than migrating away from GitHub. When you submit a ticket it
forces you to fill in some required fields. Here's an example of a filled in
issue:

[https://github.com/ansible/ansible/issues/6112](https://github.com/ansible/ansible/issues/6112)

They have more info here:
[https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.m...](https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.md)

------
lazyjones
If they need some info from users filing issues, perhaps they should just
write a small shell script to prepare the info in a few lines and add it to
their code base, then process issues on github using a small script that moves
those lacking the info somewhere else?

What I find a bit discouraging these days is that all the tools developers
consider using for organization purposes are web-based (or, worse: e-mail-
based). Web UIs can be good, but not really great and fast, writing portable
clients with a good UI and a server is easier than ever before. Someone should
give it a try...

------
hartator
It's a bit of irony that they are using a GitHub issue in order to discuss
this while this won't eventually fit the issue template feature they want to
have:

> setup issue templates prescribing what fields are required [...] What
> versions are you using?

I feel this is can be solved easily by stating something:

> Please, provide version numbers, system details and steps to reproduce if
> you want us to take a look at your issue.

until GitHub move forward an official solution, but I am only managing small
GitHub repos, not with hundreds of contributors so I can't really relate.

------
programminggeek
People who were excited about GitHub years ago are slowly walking away.
Perhaps it's inevitable, perhaps it's tools, perhaps it's culture/policy.

I'm pretty sure there is some kind of weird tipping point happening where a
few start to leave, then many start to leave, then it disappears.

It seems ludicrous to say, but GitHub might be cable tv/mac/whatever, and a
new "switcher" movement might be starting. Not sure where people will go, but
I don't think they'll stay at GitHub.

------
DannoHung
GitHub really needs a per-project StackOverflow. Probably half the issues are
just people who need to ask a question of subject matter experts or are
confused by something.

------
bluenose69
The lack of issue templates has been clearly stated here and elsewhere. I
personally brought it up with GH support, quite a long back, and I imagine
others have done the same. It seems clear that GH does not want to change
this.

There's another issue that has received less discussion: people reporting
issues get an enormously complex webpage to look at. The top of the page has
about 10 ex spaces that is mostly blank, and the text that _is_ there is not
germane to issue-reporting.

GH is a for-profit company and it could benefit from dropping their adherence
to their overall UI [1] and set up a more modal UI for issues. That UI should
be clean, with a high ratio of text to whitespace, and it should show nothing
extraneous to the goal. And of course it should display the developer's _how
to submit an issue_ text ... that's just so obvious that everyone commenting
here (and in 'dear github' etc) has a right to feel insulted by GH.

------
op00to
Dealing with the community is hard. Rather than embrace the larger community
to scale, they want to insulate themselves from it. Once you start thinking
about how to exclude people (and that's EXACTLY what moving away from GitHub
would do), the community benefit is gone.

------
sorpaas
The thread mentioned that leaving Github would mean losing visibility /
discoverability. Just wonder why people rely so much on Github for that. Maybe
all we need is a a search engine / directory for open source projects?

------
robbiemitchell
As others have noted, Github has an issues API. Create a form that validates
against your requirements and creates issues. Create your own issue template
page and Oauth the users with Github.

------
dudul
I didn't know about phabricator, looks pretty interesting.

------
bluetidepro
I wonder if this becomes a more common trend for larger products to move away
from GitHub. Esp while GitHub fails to continue to iterate on their product in
ways the community is asking. This feels very related to the recent
discussions around the whole "Dear GitHub" letter: [https://github.com/dear-
github/dear-github](https://github.com/dear-github/dear-github)

~~~
goddammit
+1

------
benhamner
It's surprising just how silent GitHub is on these issues. Most of their
engineers probably read Hacker News, yet none of them respond.

~~~
astrodust
Wanting to respond and being able to respond, which has the effect of making
you an unofficial spokesperson, are two different things.

------
fibo
Don't move from GitHub as pointed out in other comments it will not solve the
human issue and it will also defragment the Big Community.

Change your support terms, use a chat like gitter for example for those who
think that a bug tracker is a chat.

Asking GitHub to enable the "open issue" permission or to moderate like
stackoverflow do, probably will not match their priorities.

------
lips
Seems funny that this discussion is going on without seeing comparisons of
data from comparable projects hosted elsewhere.

"Too many captains not enough soldiers, and far too few librarians." Always be
sure to offer recognition to those who are naturally drawn towards organizing,
cleaning, and making your project resources handy.

------
astrostl
These are the kind of things that make me wish for ubiquitous micropayments.
In the right space, you could ask for 0.000000001 BTC or whatever a comically
trivial amount would be. Something large enough to cause friction, but small
enough to not generate entitlement.

ZenHub and auto-closing bots both seem like fine present-state improvements to
me.

------
CSDude
Phabricator is really nice, recommended.

------
andrewchambers
It is funny how the issue is about low quality issue tracking and then it
instantly gets spammed by garbage. Good on them.

------
tomcam
Appears that the list of requirements is inexplicably missing "Free world-
class hosting and staggering amounts of bandwidth provided absolutely free" or
did I miss that bullet point?

------
musha68k
ghilint bot for eslint anyone?

------
hoodoof
Github hasn't had much time yet to respond to the various recent gripes about
unfixed stuff. You should first give them six months to get their act
together. You're making a rod for your own back if you go to all the trouble
of investigating moving your project now.

Why not just demand an update from Github about which of your issues they are
fixing? If you get no response then start investigating options.

~~~
0xffff2
"Respond" in what sense? If GitHub has any plans to address the issues
outlined in the "Dear GitHub" letter, there's nothing stopping them from
writing their own letter saying "We hear you, we're working on addressing the
following concerns, and it's going to take approximately this long before you
see results". Unless I've missed it, there's been no response _at all_ from
GitHub; if they care, why don't they say so?

~~~
hoodoof
I guess they are busy working out how to maximise their venture capital?

