Hacker News new | ask | show | jobs
by mpdehaan2 3814 days ago
Posting this right after some good suggestions for the service was given feels like this is saying it is wrong to make suggestions for GitHub because they have done good things.

This to me, itself, is wrong.

The GitHub issue tracker does need to change. While it's great for OSS that projects can get a leg up SOONER, GitHub does introduce it's own problems by having some watered down tooling in some areas.

I'm STILL at odds with how it has shifted the equation from discuss to throw code at the problem, which generates extra code review and often, angry committers when their patches are not immediately merged or unwanted, or have to be reworked.

GitHub has done some GREAT things because it has built up critical mass, but because it has gotten critical mass and has become a defacto standard, does have some obligation to keep up with demand.

This seems passive aggressive to me.

2 comments

> The GitHub issue tracker does need to change.

Does anyone like any bugtracker?

That's a serious question. I've never used one that was a joy to use as a submitter (GH's issue tracker is one of the better ones, as it's so simple) or as a maintainer. As a maintainer I've found them really frustrating in general; JIRA has been one of the better ones for me.

Any consensus on 'decent' trackers?

> I've never used [a bug tracker] that was a joy to use as a submitter [...]

And it shouldn't be. If it is, people submit stupid bugs. When you get a notification of a bug, and you go read the bug, and try to reproduce it, you'll spend at least about five-ten minutes. The submitter then is obliged to spend at least about that much to report a proper bug report to an open source project where even the licence revokes the responsibility of the maintainer to respond to the submitter. And if good will and conventions can't force this, the bug tracker should.

> And it shouldn't be. If it is, people submit stupid bugs.

I strongly disagree. You're conflating easy to enter a bug with a pleasure to use. There's no reason to throw both out.

Also, you're thinking of a public tracker. Where it's used within a team, having it easy and a joy to report issues is hugely beneficial, so they get logged without nagging and moaning.

A repro steps field is a must. If I was a contributor (and I am!) then I would look at the thousands of bugs coming through and focus on only those with those that have that filled in.
> The GitHub issue tracker does need to change.

Popular bug trackers suffer particularly from a curse all popular software faces: a constant barrage of criticism from a variety of user bases with disparate needs.

Appeasing any one of these alleviates a tiny portion of that pressure, while permanently ratcheting up complexity, which leads to accusations of bloat, steep learning curves, and eventual abandonment. Faced with that fact, it's understandable why GitHub wouldn't just throw in new feature requests wantonly.

I think if they communicated that consistently and clearly, people would be disappointed, but they would understand. After all, Github's users are developers who probably struggle with these same product trade-offs. The biggest problem is the lack of transparency or feedback in the product process.