Devs complain GitHub's become slow to fix bugs, is easily gamed

More than 1,100 maintainers of GitHub projects have put their names to an open letter expressing frustration that the famous software hub is ignoring them. Their letter, here, centres on what they say is inadequate support. “We’ve gone through the only support channel that you have given us either to receive an empty response …

[Anonymous Coward]

Anger management

Is it just me, or is it actually odd that 1100 angry maintainers can't find a way to reach the Github people directly, and must instead use that ineffective channel? Is Github really a corporate-style brick wall?

[Charlie Clark]

I sometimes wonder what goes on in the heads of people using VC-funded services. Where does the sense of entitlement come from?

Github is currently making a very successful land grab (and gathering lots of valuable personal data at the same time). It will continue to do so as long as there is no real pushback with people prepared to switch to alternative vendors. It's not as if they're aren't alternatives.

[Anonymous Coward]

I wonder how many of these 1,100 complainants have paid accounts on github?

If they want to work on an open-source self-hosted alternative, there is gitlab.

[Tomato42]

People pay for hosting their private repos on github because their open source repos are already on github. If the OSS moves elsewhere, the paying customers will too.

[Anonymous Curd]

"Where does the sense of entitlement come from?"

Paying for accounts, probably.

Compared to Atlassian, Github Support has been terrible in recent years, and substantial new features few and far between.

[wikkity]

I concur

I have a number of private projects and the customer support is pretty bad and very slow, you need to do lot of chasing up. That said it doesn't cost much and so far I've had no show stoppers, if I do then git is trivial to switch elsewhere.

[Quortney Fortensplibe]

Re: I concur

"...I have a number of private projects..."

Just out of interest, why do you [and others] pay to host private projects on Github, when Bibucket offers unlimited private repos free?

[Quortney Fortensplibe]

Re: I concur

Godammit!

%s/Bibucket/Bitbucket

[thames]

Nothing Special

I've got an open source project on Github, having moved there from Sourceforge (who were reasonably good once, but are going down the drain). I've had no complaints, but in terms of features and ease of use, it has nothing to recommend it over the other alternatives. The only thing it has going for it is that large numbers of other people are also on Github. If Github goes the way of Sourceforge, I would have no problems with moving to some other place instead.

I read the complaint the devs have, and the problem seems to revolve around Github's bug tracker not being very good at filtering signal from noise for popular projects that get a lot of messages. Most messages on big open projects tend to be spam, trolls, or just people vaguely saying "this sucks" when they have PEBKAC problems. Traditional closed source companies often have humans acting as filters between developers and customers. Projects based on services like Github on the other hand expect the bug tracker software to be sophisticated enough to automate the filtering. Without some sort of automated filtering, the genuine problem reports get drowned by the PEBKAC/spam/troll ones.

I haven't had any issues along those lines, but that's mainly because my software tends to have a much narrower and more specialised audience.

[Anonymous Coward]

Re: Nothing Special

Is it feasible for Github to upgrade their filtering? If so, what would be the cost to do so? What about possible disruption of the system overall when they upgrade filtering?

I don't know the answers, but those seem like difficult issues. Maybe the Github people are just ignoring the problem in the hope it will go away?

[thames]

Re: Nothing Special

The problem is basically the design and configuration of the bug tracking system itself. "Filtering" is a very generic term that I used to cover a lot of UI and process ground.

The bug tracker should be guiding the users to enter useful information while also providing a way for people to enter "me too" responses in a way which is obviously just a "me too". A "me too" response is useful in gauging how many users are affected in order to prioritise fixes, but not if people have to read and summarise everything themselves.

The actual letter is linked in the story, and there are three short bullet points listing what they want addressed.

Issues are often missing crucial information such as what the version is or how to reproduce the problem. The developers want Github to let them add custom fields and mandatory templates to ensure the user fills out all the fields.

For just simple "me too" responses they want a voting system so that users can up vote an existing issue rather than adding another comment with no real information.

They also want individual project contribution guidelines to be made more obvious to people making pull requests.

I suspect that the first two are the most important, since in my own experience getting useful information out of users can be like pulling teeth if they are not familiar with how to make a bug report that can be turned into actionable items.