Hacker News Reader

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.

> I wonder why more people aren't getting involved to triage the issues instead of looking for a technical solution?

Its the same old Cathedral vs Bazaar argument. These issues existed even in the time of Richard Stallman and Linus Torvalds. Linus liked the bazaar style of development accepting patches and fixes from just about anyone, while RMS liked the cathedral style of sticking to a small group of chosen devs. But issues used to get solved despite the lack of github and a lack of a decent bug-tracker in those times! They used to get solved by using a simple mailing list, I think your earlier conclusion is right: its a people problem, not technical that is happening now.

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.

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

https://huboard.com/ is another one. Haven't used it but I know it used the Github API as well.

That's what the Joomla project did when faced with the same issue: https://github.com/joomla/jissues

Idea: crowd-sourced issue triaging across many open source projects that rewards issue triagers with reputation points.

stackoverflow.com

"This post is off topic because... "

Just reinventing the StackOverflow experience.

At my startup, I've dealt with ~4700 reports on my own over a few years. So to me I'd guess 2500 between 5 devs, even part-time, is manageable.

The #1 most absolutely key aspect of the way I deal with this volume of issues is: have clear, specific bug report guidelines, and instant-close without investigation any reports that don't follow it to the letter. The goal is to (somewhat ruthlessly) train users in to making useful reports. This does frustrate users sometimes, but it's actually in everyone's interest: if they make good reports their issue is more likely to be fixed, and as the developer I can't spend hours every day figuring out how to extract information from a relatively uncooperative non-technical user. In fact at a startup there's simply not the time.

That was your full time job. There's a difference when you're a volunteer, you have limited time and want to spend it on stuff that matters.

Well, in this case actually it's even more relevant. If there are clear and specific bug guidelines, and the end user can't follow these, then it's even more important to close the bug as soon as possible if it doesn't follow those guidelines.

If you don't do this, then unless you are a big project like Mozilla or LibreOffice, then you will quickly be overwhelmed with useless bug reports.

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

As someone who has managed teams at such enterprises that have used GitHub (and pay handsomely for it), I can confess that it is indeed an enterprise problem too. Everywhere I've worked with a team of > 10 people is paying for something other than GitHub to track issues because this solution is unworkable.

I think you're agreeing with the comment indirectly. I think the point was that enterprises are likely to pay for a different issues system, which isn't really a possibility for an open source project. OSS projects can use a different issue system, but they're unlikely to pay for one.

they can just request a bunch of licenses from Atlassian, they provide free software for open source projects.

https://www.atlassian.com/software/views/open-source-license...

If you're only using GitHub for version control, is there any particular reason you aren't using something else like GitLab? Is it integration with third party products?

Not sure why I get downvoted. I'm genuinely interested in an opinion. I've repeatedly evaluated GitHub and its competitors for various non-open-source projects and the costs simply never justified using it.

People discuss the drawbacks of moving off github in the linked discussion. The big one seems to be visibility.

The linked discussion is about an open source project. The GP was talking about (what sounds like) closed source projects. The requirements are very different, hence the question.

Probably a number of reasons:

* Inertia. GitHub is mostly good enough most of the time. Actually in many areas it's actually downright fantastic. The few really rough areas aren't enough to justify throwing everything else away. * Trust & Stability. They've done a great job of cementing their credibility when it comes to taking uptime, performance, and security seriously. * Design. GitLab in particular still looks like a cheap knock-off. Having worked a number of years for a company that cares about design I've come to appreciate that the lack of attention to detail in things like this. * Insufficient appeal elsewhere. No alternatives clearly do everything I currently do + the things I want an order of magnitude better to justify a switching cost. The alternatives last time I looked largely appear to have some feature parity, some bits missing, the occasional thing better. It nets out at same same.

    They mention nowhere that they'll somehow end up with less bugs if they leave GitHub

Thing is that is exactly what will happen. The whole "low barrier for contribution" called out in that thread recurrently, equates to "low barrier for logging an issue anytime you have a code problem". People with show stopping bugs will find a way to log an issue.

Making stackoverflow the path of least resistance for everyone else will ony serve to make everyone's lives easier.

Actually, how to handle issues is key for the enterprise, but Github doesn't invest in that feature because any serious development team uses something different (better) like JIRA. Most Apache projects also use JIRA and they seem to be doing just fine.

That's something of a confound, though - JIRA requires licenses and is preferred by big shops with a lot of resources, so you'd expect it to be better just by virtue of having more people paid to manage it.

I've seen plenty of JIRA projects full of the same mess of open issues, etc. as well, and that seemed to run exactly like GitHub: not enough people felt it was their job or had enough the time to spend on ticket gardening.

the problem with JIRA is that allow well intentioned but misguided teams to shoot themselves in the foot big time. A properly configured JIRA will work much better than Github's issues at its very best. It's kinda my specialty to take disorganized teams and help them perform better, and JIRA is one of the tools I use the most. It's very configurable (to dangerous extents) and can do pretty much anything.

Triaging is always a necessity, but the amount of work needed can be various orders of magnitude different depending on the quality of info provided. Making it TOO EASY to file bugs usually brings quality of the reports down quite a bit, too hard and it just discourages people. The amount your team can live with varies depending on the personalities involved, but Github is universally bad. As a manager every time I deal with a team that uses that system I KNOW I'n in for a lot of pain and I will need to bug a lot of people to get the gist of the situation.

I don't disagree that the GitHub issue tracker is too minimal. I would just be surprised if the situations where you've had problems also weren't situations where the development team would have neglected any issue tracker due to staffing or cultural problems.

Eslint, for 2/4 - 2/11:

"Excluding merges, 12 authors have pushed 20 commits to master and 28 commits to all branches. On master, 113 files have changed and there have been 2,178 additions and 625 deletions."

Rust, also on github, 2/4 - 2/11:

"Excluding merges, 34 authors have pushed 123 commits to master and 139 commits to all branches. On master, 335 files have changed and there have been 7,587 additions and 5,722 deletions."

I'm not sure that github is the problem.

While numbers may seem like they give empirical data, this kind of comparison has no benefit because it is out of context.

There's no way you can draw any conclusions based on these numbers, aside from that they are different projects with different rates of code activity.

I'm not sure what point you are trying to make. Can you elaborate?

Plenty of projects use github much more intensly then ESLint does, and haven't had the same problems. (Rust, for example, has an order of magnitude more github issues then ESlint, but I've never heard them complaining about github as an issue tracker)

ESLint: ESLint is an open source project originally created by Nicholas C. Zakas in June 2013. Its goal is to provide a pluggable linting utility for JavaScript.

Rust: Rust is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research.

One of these things is going to have a lot more resources than another.

Sure, but again, that's a difference in the projects—not something inherent in the way Github handles issues.

Not if you consider that a project with more resources can more easily make do with an inherently broken system. It is easier to triage bugs with each additional contributor.

That isn't really true. The more "resources" you have, the more stress you put on your communications mechanisms, like issue tracking.

Rust contributor here, we actually were thinking about migrating off of Github Issues a few years back in favor of Bugzilla, both due to greater features (it has basically everything from the Dear Github letter, and then some) and familiarity (Firefox uses Bugzilla, so all Mozilla employees are familiar with it, and we have to integrate with Bugzilla anyway because there are important Rust bugs tracked in Firefox's Bugzilla that relate to features necessary for Firefox integration (see the "Depends On" links at https://bugzilla.mozilla.org/show_bug.cgi?id=1135640 )).

I was actually the one to file the issue discussing migration, back in 2012: https://github.com/rust-lang/rust/issues/2865 .

We've generally come to terms with using Github Issues (not terrible, not great, Just Okay). We do have to spend a lot of effort on triage, but that's true of any bug tracker (fortunately we also have Steve Klabnik, the unstoppable titan of bug triage).

(I was and still very strongly am pro-GitHub issues. I do think they're Great, though there are obviously some minor things that could be improved, like anything. Bugzilla would have been a huge mis-step.)

I'm happy as well that we stuck with Github Issues, but it only ventures into Great if you happen to count its ability to effortlessly leverage Github's social graph. The rest of its technical issues drag it down pretty far: the search feature is completely useless (which is why I give my issues way-too-verbose titles like "Type inference fails to infer the type of a closure when calling a function with an argument bounded by a trait implemented for a closure which takes a reference argument", so that people have plenty of keywords to find it later through Google), and the permissions system actively user-hostile (as we were discussing today on https://www.reddit.com/r/rust/comments/45fsbe/is_the_rust_co... ).

Sure, sorry if I came off like I was using you guys as a political football or something. Obviously the particular bug tracker that's right for any one project is going to depend on team familiarity and experience. The main point I was trying to get across—which I think is being ignored by the dear github people—was actually what you said in your last paragraph:

> We do have to spend a lot of effort on triage, but that's true of any bug tracker

It seems like people are looking for a magical way to get out of doing triage, dealing with bad issues, and moderating comment threads. It just isn't something that's going to happen. Bugzilla has voting, for example, but "me too" comments are still a problem on bugs that get shared outside of the community[1], to the point where they're the first rule on the first section of the Bugzilla etiquette page.

Now, I'm not saying github implementing voting would be useless, or a bad idea. I'm just saying it isn't going to fix as many things as people seem to think it will.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=923590 was shared in a bunch of different places, and there were a lot of +1 and "me too" comments.

  > Sure, sorry if I came off like I was using you guys as a 
  > political football or something.

No problem. :)

There's no silver bullet to triage, but assistance from the platform can help in small ways that add up over time. For a project like Rust, for instance, we need a test case with each bug report, without which reproduction, triage, and regression testing is impossible. An issue template that suggests a test case would go a long way.

Another example, from a different project I've worked on: Dungeon Crawl Stone Soup is a roguelike game that recently switched its canonical repo to Github, but was unable to switch its issue tracker to Github Issues because they rely on users being able to attach savegames with crash reports. Github Issues only allows images to be attached, so unless they expect users to steganograph their savegame into an image macro then GI is simply a non-starter.

Would gists work? That's what I've seen most people do in similar situations.

> I'm not sure that github is the problem.

Agreed.

Quote from nzakas who suggested the move: "It's not just that the GitHub experience is suboptimal, it's that it aggressively undermines development. There's just no way we can keep up with the pace of issues anymore, especially when most of them lack enough information to be useful. The tooling isn't good enough for the onslaught we receive."

If they can't keep up with the pace of issues, that's not GitHub's problem. Sure, GitHub could help make the experience better, but it isn't the problem. That said, I feel for them. It's tough to have a popular project.