Investigate switching away from GitHub | Hacker News Reader

Investigate switching away from GitHub

github.com

498 pointskristiandupont245 comments

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.

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

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.

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

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

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?

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.

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.

    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)

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.

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.

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

The crazy part is that this is absolutely a solved problem.

I'm not sure if everyone misses this due to Linus-worship, holding him up as an example of how to run an OSS project (which... he isn't a good one), but most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here.

I'd love to see everyone:

(1) Buy their nearest PM an appreciative beer, thanking them for keeping this off you at your day job.

(2) Recruit somebody with this experience to your project. It's unreasonable to expect that OSS is a developer-only world, when closed-source software doesn't function that way. Changing the culture of OSS to involve PMs when projects hit a significant size and respect their contributions would be excellent.

> most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here

Good PMs are hard to find, and the problem is far from solved. Some PMs add to the problem by adding more forms with even more mandatory fields that have very little to do with actual development and a lot to do with feeding into their "Project Reports". So, don't buy that beer too hastily.

> Good PMs are hard to find

I'd take this further -- I think finding good PM's is harder than finding good dev's. I'm not sure why exactly. I bet you'd find a lot of dev's who think their PM does the opposite of their job (that is, creates more work for them).

Beacuse you can't judge a PM's work as easily in an interview. For all the difficulty we have hiring people to write code, either your fiz buzzes or it doesn't.

A long term bad-quality PM knows the vernacular and can talk a good game. And thats all you have, really. Not even that fizz buzz level of pass or fail

Product managers's job is not to reduce work for developers (it could be a nice side effect), is to help avoid building unnecessary things and build the right things without waste as much as possible.

PMs end up doing a lot of stuff that's not necessarily their job to keep the wheels turning, and it's the right attitude to a degree (sometimes it allows dangerous sloppiness to survive past its due date) but the job you have in mind should be performed by a good QA person.

> most of the engineers flailing around here work with PMs in their day job, whose job it is to do what isn't getting done here.

That sure would be nice. Almost every PM I've work with has actually just been a source of busywork who seemed to view their job as to ensure that the engineers spent as much time on issue management as possible. The only one which actually tried to do it himself had a habit of closing actionable bug reports because the reporter didn't bother giving the useless extra info that the PM asked for, while sending all the useless ones on to the developers.

Closed-source and open-source software is different in many ways. One little example is that open source software doesn't need to constantly grow features, it can live on with a slow rate of change for decades and be useful. (examples: bash, zsh, rsync, tar, ssh, vim, emacs, awk, sed, gnu screen ... the list is quite long)

When you make a statement like "(which... he isn't a good one)" it would be good to qualify why. Especially when its objectively clear that the Linux project is probably one of the most successful human enterprises to date.

And when you then continue on to claim that PM's is the panacea that will "fix OSS culture" I feel I have to point out that "OSS culture" is what built the technological world we live in today. And while its not perfect, I respectfully suggest that you don't fuxor with things that are not broken, given that the OSS world's track record of delivering world changing software is unrivalled.

To put it more succinctly: https://www.youtube.com/watch?v=CDGuPp1np4o

Except that it IS broken. That's why we're having this discussion. The "Dear Github" post is trying to say "the process of making OSS is broken" but is asking for a software solution to a human problem.

Linus' approach to project management is to chase away everyone by being a "gentleman sausage". He has the sheer technical competence to succeed in spite of this, but it's not a successful approach for most people, and dudes attempting to emulate Linus chase out the decent human beings.

Making the process of making OSS sustainable for mere mortals will go a long way to making more OSS.

Not so. The "Dear Github" post is all about bug tracking facilities in github, nothing more. Previous versions of Github had a more functional issue tracker - it went largely ignored and github wisely removed the unwanted cruft from their code base. Github is not JIRA. OSS projects are free to use whatever bug-tracking facilities they choose. Just like everyone else. I would like to see better API's from github to support this.

On to Linus. There are 12000 contributors to the linux kernel, If Linus sucks at anything, it would be his ability to "chase away everyone". You seem to be of the opinion that if there were more than 12k Linux would somehow be "better". This is entirely conjecture on your part, and many would argue that Linus is fact too lenient as it stands.

I'm a PM and it's disturbing to read how many people think our role is to do QA.

What is "Pls"?

Linus also delegates to his kernel "lieutenants" to scale Linux development.

A typo (now fixed).

Recruit somebody instead of automating it by more smart tool than GitHub? Really? Are you programmer after that? :)

Automating processes involving people from outside your project is just a very hard problem. The trade-off here is investing a possibly small amount of time into recruiting a PM vs. investing a possibly ridiculous amount of time into building a magical issue triaging AI.

When tool have simple fields like "affected versions", "OS", "steps to reproduce", users use them and greatly decrease amount of needed time to classify issue. It's not smart AI, just fields.

> Or find some students that want to break into open source and have them be 1st level triage for your issues.

Which I had offered as a solution in the thread, but was ultimately shot down with "It's 2016, we have bots that can do that."

Clearly the bots don't work if it's still a problem.

Do any students/newbies actually want to triage issues, or is it just something the old hands thought up and think might work nicely?

Many 1st semester students want to get involved and can't code yet. And I know they'd jump at this.

How many have you suggested volunteer, and what were their thoughts after a semester?

About 60 a semester.

Number that attempt to get involved is unknown.

I require 1st semester students to push final projects to Github public repositories so they learn Git.

Biggest problem is that they can't program very well yet but want to contribute. So any low-hanging fruit is welcome, really.

Debian has the how-can-i-help tool, which is aimed at helping people find low-hanging fruit:

https://wiki.debian.org/how-can-i-help

I've been working as a programmer for a few years and I can't program very well. I can get things done but it takes longer as I'm constantly distracting myself. I want to contribute as well, particularly with compiling binaries and easier stuff but I don't know where to start.

I triage where possible in projects that are important to me, because when I have a problem, I expect my issue to be triaged in return. I'm not a student/newbie, but I'm not a coder and still desire to contribute where I can.

Yup. My students are always asking how they can get involved in open source....

Lots of talk around the OSS world on how to "get involved with open source" and this is a great solution to both problems. Newbies can start getting involved by triaging issues, and projects can alleviate some of the pains by letting them do it. It's a win win.

As long as the newbie doesn't walk away feeling like they've been shunted into the kindergarten playpen. But so long as you get ahead of that expectation mis-match, it actually is a really good way to get to know both a project and its surrounding development culture.

I'm a student, I don't think it would feel like that at all (as long as the attitude of other team members didn't make it so).

There have been days where I've actively searched for some OSS project that is accessible enough for me to work on - because usually the ideas I have myself are things I'm not capable of! Or I just need to think more about how to get started, and when in this mood I'd rather just get hacking on someone else's project's issue.

My point is, issue triaging could be a great way to learn the ropes of a project (and get to know the team a bit), and you'd probably find yourself occasionally (then gradually more often) thinking "hey, actually I reckon I can have a crack at this myself". That'd be really satisfying for a never-contributed-before fresher.

To be honest, this is a problem that has to be solved by cash/donations.

1st level triage for issues could be done by developer in the Phillipines on Upwork for like $5-10/hr.

The problem really is they've hit a scale where they need a human CSR to handle their 1st level triage but they don't have the cash to pay one.

Volunteers find the work mind numbing enough they refuse to do it for long generally.

Yes. I agree. Cash would solve this.

All the people making money on books about ES6 could kick in. All the folks making screencasts could kick in.

All the companies making money on open-source could kick in.

And volunteers? They should cycle out and move up into more interesting work, making room for new people to do that. That's what I was thinking.

All these folks could kick in, but will they?

Not that I'm saying that volunteers are better -- they asked, no one stepped up, which means to me that volunteers are a non-starter.

It's in their best interest to. If the cow you milk dies through neglect, you have to find another.

That might encourage false reports to keep the work available. It is a good idea though.

No tool will completely solve it, but there are a lot of changes you can make to an issue tracker to deal with increasing popularity. For example allowing people to add emoji's so that you don't get an email with a +1 comment helps a lot. For the rest of the things we did at GitLab please see our 'Dear open source maintainers' letter https://about.gitlab.com/2016/01/15/making-gitlab-better-for...

BTW I also commented in the issue https://github.com/eslint/eslint/issues/5205#issuecomment-18...

"Switching to another tool won't solve this problem they're having." It will if those users don't follow them from GitHub.

Whether this is a bug or a feature is left as an exercise to the reader.

I would say feature.

If you have to sign up to file a bug, the bug is going to be important to you. You're likely to put a bit more effort into making sure the report is well-written.

If you already have a github account, you will probably simply do a drive-by bug report on anything that looks like a bug.

Bug reports are the lowest level of "contributions", and losing some people filing them isn't a big loss.

> If you have to sign up to file a bug, the bug is going to be important to you.

This. That's the reason why bugzillas rock! Visit the GNOME bugzilla, Red Hat bugzilla and even Mozilla bugzilla for instance and have a look. Its always organized, focused and in problem-solving mode. Unlike Github issues, people don't stampede there to just say "Hi" or "How may I use this thingy?", they bring their actual problems in all seriousness (because they have to register, verify their emails and then login just for the sake of posting an issue)

Bugzilla is a little too unfriendly, the search can be a pain so its hard to know sometimes whether you're submtting a dupe.

And of course even with the best of intentions, most issues raised will still be NotBugs or other time wasters. (I'm guilty of that myself, just yesterday I reported what I thought was a bug in Firefox but turned out to be chrome and IE not implementing the spec and us using their incorrrect behaviour).

> just yesterday I reported what I thought was a bug in Firefox but turned out to be chrome and IE not implementing the spec and us using their incorrrect behaviour

That's still loads better than the average issue reporter on Github issues. Though it was not a bug in your case, your effort was genuine and deserved some real attention. If this were the github tracker, your genunie question would have been piled and lost under tons of useless ones.

> Bug reports are the lowest level of "contributions", and losing some people filing them isn't a big loss.

No, spelling fixes are the lowest level of contributions. Bug reports are actually useful. Yes, there's lots of noise, and reducing that noise is great. But without bug reports, all of our free software would be crap. It would only work for us.

> I've been in software for a long time. There's no tool that solves this problem.

There's not a generic tool, but there's often a lot that can be done one the client side to gather relevant information for a bug report. This is why, e.g., many linux distributions have a built-in bug reporting tool -- it will also hoover up non-personal information that might be relevant to the bug you are filing -- packages installed, error stats, etc.

Imagine running eslint --itbroke

and a log was copied to your clipboard so you could paste it in...

Imagine that command making an API call to an improved GitHub issue system with facilities to organize and accommodate more structured submissions.

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

Users won't read:

http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

Users don’t even read the error messages, let alone the documentation.

~closed as Incomplete. Please complete the form properly :^)

You make a few fair points, but at least having a mandatory "version" field for a bug report feels like a sensible requirement for any issue tracker with a large backlog covering many versions. Solving what can be done by a form validator with paid staff just doesn't sound right.

GitHub doesn't need to become jira, but just promoting the tag system to a custom field system would help.

There are two solutions to this I think they can use a really distributed version control including tickets and wiki as part of the repository as it is done in fossil scm (http://www.fossil-scm.org/) or just use trac with ticket triage like its being done with http://code.djangoproject.com/

My personal suggestion is to get out of github as the platform is not open source and there are no community process to enhance or change it. Its just another sourceforge with flashy interface.

Disagree - GitHub is the Facebook of open source which is good - but its popularity sets the bar low for adding an issue (especially a dupe or something that isn't even a bug) - go try to create a issue for Linux one of the Apache projects not hosted on GitHub (not taking about mirrors) and you will see it is considerably harder - that leads to attrition which leads to less "fake" issues

"Turn off public issues tracker" it's the most effective way to kill your product. See Opera as example.

Issue templates, no. An issue spam filter, on the other hand—especially one the submitting user knows exists...

The issue is very simple IMHO: The low number of maintainers per user. To solve this, you can start ignoring issues, recruit more maintainers or make maintainers more effective. They are trying the latter, which seems like a good compromise.

Should issue management be complicated for most projects?

I suppose the polar opposite of guthub issues is something like bugzilla or jira. Both of which I've seen cause enough friction that to stymie projects.

Damn users!

143 issues over 2 years is an "onslaught"?

Edit: my bad, 143 is only "open" issues. Nearly 3,000 total.

147 open, 2915 closed. First page of issues is 25 in past 8 days.

Not sure what determines an onslaught, but just so the numbers are clear.

The "onslaught" is very relative to how many time you can afford to spend on the project at all. If you can afford to spend one hour per week, then triaging 25 issues per week might eat all of that. If you can afford to spend one hour per day, then issue triaging will only be a small part of your daily routine.

2,915 have already been closed. Averages out to 4 new issues a day.

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

Never heard the analogy of PMs to APIs, but that's the kind of thing that immediately gets stuck in your brain. Nicely put.

There was a book about "team APIs" that provided a framework for negotiating how teams will interact with each other.

Of course, I can't find the book online now. I thought it was a Microsoft Press book by Steve McConnell or Steve Maguire.

Perhaps this: Steve Maguire: Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams (1994)

http://www.amazon.com/Debugging-Development-Process-Practica...

edit: Or maybe it was Steve McConnell's you recommend?:

Software Project Survival Guide (Microsoft, 1997)

http://www.amazon.com/Software-Project-Survival-Developer-Pr...

"I'm a people person, dammit. I have people skills. What the hell is WRONG WITH YOU PEOPLE!"

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

That sounds simple. You're volunteering, then?

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.

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.

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.

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

It's the old "OH you have a problem or a request with some open source project? Then how about YOU write the code/solve the problem! It's open source you know!"

It's a canned response that people roll out whenever anything is raised about an open source project.

"Just find a volunteer" is the canned non-solution people roll out whetnever they are unsatisfied with work they've been given for free.

"Find a volunteer" is a useless suggestion to make to a volunteer organization.

Believe it or not, there are professional PMs who are just as interested in open source in their free time as some professional software engineers are. I'm not one of them -- I'm an engineer -- but I know some.

How many of the PMs you know have you contacted suggesting that they volunteer in such a capacity? What were their reactions?

It would be a good opportunity for people who would like to contribute to an open source project who might have less technical experience or time. Mozilla has many indispensable volunteers who help triage and "groom" Firefox bugs in Bugzilla. They are a huge help. :)

http://www.codetriage.com/

Did you read the article? https://github.com/dear-github/dear-github

Github issues is missing features that would vastly reduce the amount of work they'd have to do. So they can either switch to another issue system or find someone willing to do all that manual grunt work for free. One of those seems easier than the other...

Yes, I've read both the full comment thread in the OP and the dear-github letter.

GitHub adding those features would be a huge boon for teams like this. And honestly, it may be that switching to a different system is the best move for this team. If their motivation is "we need features which GitHub has been unwilling or unable to provide", that's a great reason to move.

But, as I quoted, they also say that they want to move to another system because it will put up artificial walls and isolate them from the people that are currently inundating them with issues. I think that's a bad reason to move. Both because I think it will be ineffective, and because I think it represents bad faith towards their users and community.

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?

Since I haven't noticed anyone mention it directly while advocating for voting functionality: GitHub issues originally had voting. The feature was removed with the release of Issues 2.0. Back when the GitHub blog had comments, the Issues 2.0 announcement's comments included this one from pjhyett (https://web.archive.org/web/20110412131836/https://github.co...)

> Issue ordering and voting were used by an incredibly small number of users and we made the decision to drop them. Leaving features in that only ten people use is how to create Jira, not GitHub.

Obviously, that was a while ago and things might be different now.

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

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.

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.

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.

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.

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.

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.

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

You'll probably be surprised to know most companies do care about your feedback. Even Apple. The thing is, companies are out to make profit. If your power users all go leave and use a competitors product where do you think all the companies who they work for are going to end up? Yea at the competitor.

I would very much be surprised.

Some personal examples:

For years I've worked with Microsoft products. The company I worked for paid big bucks for Microsoft enterprise support. Tried to use many times, always same results. "We'll send this to engineering." Never a response.

Same with Apple. Bought an iMac that repeatedly ejected USB disks. Known issue. Apple support forums have hundreds of unanswered, unresolved threads on this issue. Yet Apple support had "never heard of it." Same "we'll send your logs to engineering and get back to you." And never heard back.

Local cable companies call you constantly to get you to sign up for services. Then when there's a problem they'll come out and fix when they feel like it.

Got a problem with your Google Apps account you pay for? Good luck.

Sell something on Ebay and someone screws you over? Ebay still keeps their cut of course.

Paid $1500 for Google Glass, found out explorer project was shutting down through Twitter and The Verge, rather than Google.

Had a Digital Ocean box disappear for no reason. Response from them was "sorry." Saw a recent article where someone else had that problem too.

Had a similar issue with a Linode box. Same results.

So maybe I just have terrible luck.

But I'm willing to bet that there's way more money in sales and marketing than there is in supporting existing customers.

Forking over money to a company provides zero benefits other than the use of the product or service, in my experience. You get no say in how things work there, and you're lucky to get someone who is actually empowered to help you.

Pretty sure improving the Issues system is a wontfix. :)

Perhaps is a matter of principle? I would think that if you add those changes, problems would go away. But you could also make the argument that once you show everyone that complaining /boycotting/etc works against you, more people will go for it?

Seems far fetched, but might just make sense given who pays their bills..

That's still not really a reason for GitHub to not respond. They don't have to agree or promise anything one way or another, but a response from GitHub outlining their position would at least give everyone a clear baseline for what to expect from GitHub in the future.

> a response from GitHub outlining their position would at least give everyone a clear baseline for what to expect from GitHub in the future.

Um, exactly?

A "Fuck off and die, you don't pay our bills" response is going to provoke outrage and maybe even action. It would certainly provide reinforcement for those of us who don't really like github for various reasons.

Not responding at all leaves things vague and doesn't provoke action.

Want github to respond? Start moving some famous projects off of github and onto something else. A couple big name projects that start making some other service look like the "default" winner and github will get REAL responsive.

Until people start moving projects (like this one), github doesn't have to care.

Edit: for bad grammar.

I just feel the risk of major projects moving (increasingly likely) seems much higher than the complexity of adding the couple very small features, that probably don't go against anything they might be doing Enterprise-side.

I'm probably alone in this opinion but I think the OSS community should be patient and supportive of the organization that has supported our OSS projects all along.

From an outsider perspective, it looks like they're preoccupied with putting out fires.

The flat organizational structure, absent strong leadership, has allowed some bad actors to manipulate there way into positions of power/influence within the organization. The CEO and driving force of the organization from its outset has been ejected after making the mistake of fraternizing with his employees. The new CEO lacks the leadership and strong personality required to take up the reigns with the current structure. A culture that was established to be inclusive is being leveraged by a malicious outspoken minority to achieve the opposite; which is causing a lot of backlash internally and externally. The public perception of the company is in free fall. Most, if not all of these issues present a legal and/or financial threat to the future of the company.

In short, GitHub's open and informal culture has become a liability.

It takes an established record of misbehavior to legally justify firing bad employees. Especially, those who will use their 'protected' status and public support to attack GitHub after being fired. I'd be willing to bet that their lack of organizational structure has left them without justification/protection and they're scrambling to make up for it.

To protect their investment, the wise thing to do would be to build some management hierarchy; which they're doing by pulling in all of the leadership from remote positions. They need to shield the current CEO from any more mishaps. They'll follow by establishing a record of poor performance for the outspoken assholes. Eventually, when they've established sufficient justification they'll eject the toxic individuals from the organization.

GitHub will emerge a mature and stable but less friendly/open organization. Hopefully, this doesn't negatively impact GitHub's willingness to support OSS.

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

Absolutely not. To ensure GitHub has a future, they have to fix the present.

-----

What we may be witnessing is the hastening recovery of an organization that experienced a systematic failure.

They'll survive... Not before shedding some blood.

That would require them to hire HR and CR people who know something about software as opposed to constructing political narratives.

I wonder what distribution their income from private users vs orgs vs enterprise looks like. It feels like they don't care overmuch about the two former.

>I can't understand why GitHub isn't responding to the "Dear GitHub" people.

Too busy firing white males and hiring minorities to please the diversity committee.

"Dear GitHub" lives matter.

lol

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?

Why do we all rely on communicating through news.ycombinator.com? Because it's useful to have a central hub. It's a very easy system to understand and use.

There's no obvious alternative right now. Someone should build one. It's not super easy. There are big and interesting political and technical questions... which GitHub conveniently sidesteps by just being a central server.

A central-hub choice of implementation shouldn't be confused with a centralization requirement however. It is possible for distributed systems to still converge on things (indeed, entire papers have been written on the problem of distributed “agreement”), it's just that they must work in a very different way.

Indeed, we had this, in the form of NNTP and older news servers; those servers essentially exchanged copies of whatever was posted from around the Internet. If there were no news.ycombinator.com, there could still be a wide variety of servers that constitute “hacker news” around the world, that come to a general agreement on what the collection of posts should be. At any instant in time, not all servers will be 100% identical but for all practical purposes they would be.

>A central-hub choice of implementation shouldn't be confused with a centralization requirement however.

>Indeed, we had this, in the form of NNTP and older news servers;

You're focusing on the technical aspects. The other forces are social and economics. Both of those lead to centralization.

Take your example of Usenet news groups. Yes, in a technical sense, it's decentralized but once you get economics/money involved, what happens? My ISP like Verizon doesn't carry all newsgroups (e.g. exclude newsgroups with large binaries.) Or another ISP may carry more newsgroups but the retention is 1 month instead of 1 year.

So the economics converges to an central entity like Deja News that emphasizes the archival of usenet posts. Then Google buys them (Google Groups). Google Groups is now "centralized" for finding very old usenet posts. Conceivably, any of us besides DejaNews could have archived the posts but we didn't spend the money on harddrives to store it whereas DejaNews did. Hence, we end up with a centralized archive.

When I had Verizon, their newsgroups feed was very poor. I therefore paid $10 extra to GigaNews because they had everything with multi-year retention. That's another "centralized" hub driven by economics.

Looking only at the usenet RFC technical specs for distributing news posts doesn't reveal how the economics makes centralization emerge.

As for github's centralization...

A lot of us want to host a public git repository. Hmmmm... if github didn't exist, what do we do? Pay for a VPS for $9/month plan and host git on that? What about extra bandwidth costs if it's a popular repo and lots of people are cloning it? That's a lot of ugly financial bookkeeping that we don't want to do since we'd rather just concentrate on programming. Wait -- there's an ABC company out there that lets me conveniently host a git repo there? For free? Sign me up!

That "ABC company" by way of economics and social dynamics has turned out to be Github and BitBucket. And since Github has been winning the mindshare, you get centralization. There is no irony in git-the-tool being distributed and github-the-focal-point being centralized.

I agree that NNTP was a nicely federated system, and just a couple of days ago I was pondering the use of NNTP to publish Git pushes. Git's support for signed commits and content addressed objects is a great start for distributed, trustworthy collaboration. I still can't envision exactly how it would all function. There are lots of benefits to the GitHub model. They're a semi-trusted and well-funded entity who guarantee a highly available and fast synchronization. Sure, when it goes down everybody has a problem for a while... but with more distributed models you can get way more complicated failures, like "this object isn't seeded by a connected peer right now" or "this federated shard doesn't carry this repository" or whatever it may be.

I'm really interested in the future of distributed code collaboration. I just think it's not so trivial, and so it's very understandable that people have gravitated towards a semi-centralized model that already works.

> I agree that NNTP was a nicely federated system, and just a couple of days ago I was pondering the use of NNTP to publish Git pushes. Git's support for signed commits and content addressed objects is a great start for distributed, trustworthy collaboration. I still can't envision exactly how it would all function.

Perhaps having something akin to a private NNTP server that requires authentication to post for each open source project, but is publicly viewable. These news servers could be configured to send IHAVE <article> to other news servers to increase visibility. There could be a newserver like gmane to aggregate the feeds from each of those private news servers.

If you could get an authentication system that could work across those news servers, then you could have a decent system for keeping up with and contributing to open source projects.

Sadly, most people have forgotten about Usenet... or never knew it existed. The typical web forum is vastly inferior to most news clients.

Well, Usenet had basically no way of doing moderation, right? That's a pretty big missing feature from the perspective of forum administrators.

There are moderated groups. The NetNews Moderator's Handbook[1] has technical details (and more) but basically:

    'Moderated' means that all postings to the newsgroup go to a mail
    address (e.g. comp.std.unix@uunet.uu.net) instead of appearing
    in the newsgroup directly. The postings are then forwarded via
    email to a moderator, or group of moderators, or even an automated
    program, who decides whether to actually inject the article into
    the newsgroup or to reject it as not meeting guidelines spelled
    out in the group's charter.

1: https://www.eyrie.org/~eagle/usefor/other/moderators-handboo...

Notably, though, USENET moderation was managed entirely by the addition of a single, unverified, header to the message ("Approved: cuzisayso"). This allowed for simple distribution, but equally simple circumvention.

Proper moderation for anything important would require cryptographic signatures and a solid federated PKI. Maybe the world is ready, this time. :)

I think the world is ready for someone to make an actual implementation and start using it for some actual conversation!

As long as you have an actual living conversation, then an open model of development can work... which means it doesn't have to be perfect from the start, and you don't need a beautiful landing page, because you want to attract the hackers and crazy people.

You also want to encourage lots of forks and independent implementations, because if it turns into some big mega-repository with some big bloated thing that includes Scala, Erlang, Babel, Bootstrap, and who knows what other ungodly monsters, then it's just going to become a boring monstrosity.

So you'd start with inviting a few people and then encourage them to use their own servers and clients. Make sure everyone understands that the protocols are in flux because you're trying to figure out together what will work.

The conceptual simplicity of Git would be an inspiration. There are different implementations of Git... but we could be even more obviously amenable to that, by using standardized messaging formats for example.

I think plain text messages, as on Usenet and mailing lists, are the best. You don't have to agree on a Markdown/whatever complex thing. Attachments if you want to send other documents. Hacker News developed consensus formatting for links and footnotes, and we seem to get on fine without inline images and tables and all the other fancy nonsense.

(Just some random thoughts...)

I agree. It'd be great fun to build something incorporating everything we knew about distributed and federated systems in the days before their incompatibility with business models became an issue.

There's a lot of good stuff in XMPP, too. As well as some pre-discovered dead ends.

Yeah. From a hacker's perspective, a business model is just some way to keep a thing up and running. If it doesn't create a bunch of jobs at some office somewhere or lead to an IPO, well, that's just worldly affairs, right?

The distributed/federated stuff is still alive, maybe more than ever. Git is a fantastic example. I push and pull repositories between computers all the time. Often over ad-hoc WiFi, even.

Usenet and all that stuff is beautiful to reminisce about, but we should keep in mind also that it was largely sponsored by universities, corporations, militaries, and internet service providers...

IRC is a great inspiration too. Nowadays people look at it and think "ew, no Unicode" or "duh, it's not even JSON," but considering its resilience, its simplicity, its adoption, it's an enormous, staggering success.

These beautiful projects that started as tiny little seeds by clever obscure Scandinavian hackers...

It's just all about starting a little thing, getting your friends in on it, and keepin' it hella real.

True, although keep in mind that while USENET's bandwidth was definitely sponsored, the technology (above the TCP layer) was built by hackers as a side project. At some point Larry Wall (e.g.) got a job just being himself, but for a long time he had unrelated professional responsibilities.

Since the bandwidth funding model has now bubbled down to the consumer marketplace, it seems like the conditions are right for a huge variety of services. Actually that was starting to happen before the web swallowed all other services. Don't get me wrong, the web was/is a great thing, but it severely dumbs down the range of protocol expression. The state of websockets in 2016 is a weak imitation of IRC or MUD capabilities more than 20 years ago (never mind adoption problems).

I guess that's a curse of being "good enough". The better has an uphill battle.

And there was one group, alt.hackers, that was moderated, but had no moderator, by design. It kept the signal-to-noise ratio pretty high.

You could "kill file" a user, which meant you wouldn't see any of their posts, but other people still could.

What I like about news readers is how they track new threads / messages. I could pick up where I left off. It encouraged longer term, more elaborate discussions, as opposed to posts that fall off the first couple pages like most web forums.

The obvious alternative is using git through a mailing group like Linux has been doing for years. I say obvious because it's the workflow for which git was built in the first place. ;)

It's amazing to me that git's power to easily manage distributed software development been lost/forgotten with Github. You don't need a web interface to contribute code. Linux is doing just fine.

You just need git and some sort of communication tool to distribute patches, email being the most powerful, flexible, and ubiquitous I've seen.

> You just need git and some sort of communication tool to distribute patches, email being the most powerful, flexible, and ubiquitous I've seen.

I would say that having a private NNTP server (one requiring an account to post) would also work in lieu of email. In fact, it would be better than email because it would allow new members to easily browse list archives. At least gmane already does something like that for some mailing lists.

Yeah, Git over email is really neat. But GitHub also has a role in hosting repositories for cloning and pulling...

Git can do that as well with a --bare repo on any $5 virtual server. The whole setup only takes a few minutes, and Github's doing that in the backend anyway. :)

Sure, but those servers will have much worse availability than GitHub, on average...

Then up it to $10 and host identical copies across EC2 and Linode or Digital Ocean. Set up a git hook to automatically push from your primary to your secondary server, keeping both up to date. You now have better uptime than Github (100%, more or less) for less money than Github charges and greater control.

Yeah, but GitHub does this for, like, a hundred thousand projects. That's a lot of repeated effort if every project is going to do this themselves. For private repositories, sure, but I'm thinking of GitHub as an infrastructure provider.

I was about to post this, but less eloquently, and without the obvious metaphor.

I really don't understand your argument. Git is for decentralized development but there has always been a need for a central server to host the repo and github made a business out of providing that along with additional services (pages, wiki, issues). The dear-github complaints are overwhelmingly about the secondary services github provides for project management.

>Why did people set up systems that depended on the ability to download from GitHub, for instance?

Because if they didn't rely on github they'd have to rely on some other server subject to similar downtime?

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.

> Are those programmers using this operating system's tools for software installation? Hardly. And why?

Because this is a bizarre argument. I accidentally make dependencies on specific variants of libraries because I don't immediately need to support other variants and lack examples and/or time to worry about theoretical portability.

I don't use OS specific packaging because it was intentionally written to be non-portable. My learning it is an irrational commitment to keep using an OS at the neglect of all others and even if its distributor changes (or can no longer honor) the conditions of our deal.

Your dynamic website (often called a webapplication) is very probably OS-specific anyway. I've seen websited that can run only on Ubuntu. Most often you could as well settle with what OS provides to deploy it, especially that you won't need another instance on the same server. Even more so if it's not a hobbyst project, but a professional one.

> I don't use OS specific packaging because it was intentionally written to be non-portable.

Only if you use it mindlessly. It's not really different to build a package for Debian, Red Hat, Slackware, or Gentoo (been there, done all of these). All it takes is to properly separate downloading sources and building things, which is a good engineering on its own. And guess what you get in exchange? Easy dependency installation, both for development and for deployment.

So you can link your Github profile to recruiters and add "Creator of project X" in your CV.

I hate the amount of garbage and noise created by this. But how many of the good tools we have today wouldn't have existed if people didn't just started coding?

It's full circle to your first phrase since if nobody was using nobody would write redundant/worse tools. Man I miss the time programming was only my hobby.

there are legitimate technical reasons for using NPM (disk is cheap, project local packages ftw, etc.). gem, less so. I can, however, tell you the primary reasons for using npm or gem: I need a dependency, my os hasn't packaged it, and it's the path of least resistance.

Also, I am a hobbyist programmer. I also know that git was created by Linus Torvalds, it's a DVCS (although Torvalds calls it an SCM), and it's based on a DAG (directed acrylic graph), which is a directed graph with no directed cycles, and excellent for modelling causal relations. I can explain to you the difference between a rebase and a merge. I know that git uses SHA-1 hashes to identify check-ins internally, as a data security feature. I know that checkins and other objects are stored in the .git folder at the repository's root directory. I know that these objects are garbage collected, although the frequency at which they are escapes me. I know that, despite common belief, git commits are immutable, but also that the git history is not. I know that git was inspired by BitKeeper, after the incident that caused the linux source to be moved away from that system, because Linux got fed up with tarballs and patches, and hates CVS with a fanatical passion. I know that git had three design goals: distributed, fast, and guarantees that you get the same bits out that you put in. And I've have several years of causal experience with git, using probably one tenth of its functionality.

I may not be able to recite git's internals at you, but I know it's features (to an extent), I know the tools, and I know the reasoning. And the functionality sure as heck isn't magic.

> I need a dependency, my os hasn't packaged it, and it's the path of least resistance.

What I tell you back: you probably don't need it, you're just being very, very lazy, which will cost later in bugs in those dependencies, and it's not that easy to fix a bug in a dependency.

Additionally, it's not that difficult to make a package with that dependency. I routinely do so, both for things other people wrote and for my code. Sure, it's not as easy as adding a line in package.json, but there should be some friction in adding a library to a project, so the library would justify itself. Keeping many dependencies is very expensive in the long run, but short-term is somewhat beneficial. Look at how it works for Node.js and gems and Python packages: every library needs its own `map()' function implementation (or anything else similarly trivial), so typcial application requires few dozens of other libraries.

Hey, I was just saying that that's the common idea, not that I think that way.

Personally, I use NPM because NPM does local versioning, so I will never end up in dll hell.

Also, NO, NEVER WRITE A PACKAGE THAT HAS EXPLICIT KNOWLEDGE OF A DISTRO PACKAGE MANAGER. If you do, you are being an asshole. If you want to depend on a distro specific package manager, document your dependencies, and just expect them to be there. Because not everybody uses your package manager.

If you have proper package building rules (not this currently popular fpm nonsense, which produces broken RPMs and DEBs unless one puts much effort in using it), tearing building procedure apart and adjusting it for other package managers will be really easy. No, you're not being an asshole. And if you want to be it even less, write a proper makefile and call that from package build rules (RPM spec, debian/rules, ebuild, or anything else).

You should be writing Makefiles, or Scons, or whatever your build system is.

Writing yet another map implementation is not solving any problems.

People get so bizarrely bent out of shape over npm dependency quantity rather than ease of use.

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

I add this to my list of epic non-sequiturs. While it is not necessarily wrong completely, it is not correct for all the cases. It takes a long time to understand how it's ok to do without the latest version of the software. It takes long time to understand that old is not a synonyme for obsolete. And to have this understandings one needs experience, and for experience you need time, which cannot be substituted. There are some things that one only learns by rediscovering them, and this is one of them: who settles is happy.

Counterexample: the universe.

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

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.

You could use a distributed bug tracker like http://www.bugseverywhere.org/

    "Bugs Everywhere is a “distributed bugtracker”, designed
    to complement distributed revision control systems.
    By using distributed revision control as a backend for
    bug state, we gain several convenient features: ..."

Centralization happens naturally. There's a reason why we see it again and again. https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df990...

It's nothing new or ironic because that's exactly the definition of centralization. Here's the definition: "concentrate (control of an activity or organization) under a single authority." There has been and will always be systems that try to centralize already existing distributed entities.

If there is no central server like github. What do you map origin to?

That's not how git works... Yes, you can have remotes where you pull your initial state. You can have many remotes -- any git repo you've cloned can be used to host the repo publicly. But after that, you can merge patches that people send you over email (or heck, even via carrier pigeon), do everything you need without a host. In fact some people have made a github-like hosting solution that is decentralised called GitTorrent.

But which one does the team deploy if everyone is sending patches to each other.

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.

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.

It's no just "free users" that can suffer from this.

A company I worked for has outsources some payments infrastructure to a third party. That third party had put in a very aggressive bid in order to win our business. We were to be their "big name customer" and they wanted to use that deal to gain credibility with other potential customers. It seemed like a rational business decision for them, and we took the deal.

But, the fact is, that deal wasn't commercially sustainable, and we both suffered from it. They lost money on everything they did for us, and because they were losing money they tried to do everything as quickly and cheaply as they could, which inevitably meant badly. We were never happy with their offering.

When the time came to renegotiate the deal, we went back out to market, and we invited them to participate in the tender process, but we were very clear - "This is the SLA we expect. These are the penalties we will apply if you miss the SLA. We intend to hold you to them. If you submit a bid, make sure it is commercially viable, and that you can afford to actually deliver on the SLA, or else you will end up losing a lot of money on this."

I think we ended up sticking with them for a bit longer (due to politics and inertia) and then eventually ditched them a few years later.

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

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.

It's worth noting that both GitLab (with GitLab Enterprise customers) and Phabricator (with Facebook) are themselves both prone to this problem.

Facebook has had essentially no involvement in Phabricator for several years.

> I find it really sad when projects grow enough that they start seeing user input as a burden

Low quality bug reports waste everyone's time: I don't know of any developer who would disagree (open source or not, paid work or volunteering). If the "user input" is low quality bug reports, then it is a burden. Complaining that Issues enables low-quality bug reports isn't hubris.

Yes users have to be trained and you need guys who's sole job is issue triage.

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 :/

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.

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.

The separate Issues problem could be worked around by disabling Issues on all repos, then creating a new “our-org/our-project-issues” repo that contains no code, but has Issues enabled.

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?

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

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

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.

What is GitLab's issue tracking like?

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.

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.

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

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/

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

> 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 :-)

Awesome!

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.

> 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

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

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

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

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.

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/

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.

GitTorrent? https://github.com/cjb/GitTorrent

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.

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

Yes, this!

NixOS is great, but if someone pulls the repos for the source packages of somethings in NixOS... you're just completely out of luck.

But if you know the hash, and someone in IPFS still has it available....

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

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

They have more info here: https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.m...

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

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.

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.

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.

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.

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.

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?

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.

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

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

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

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

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.

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.

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.

Phabricator is really nice, recommended.

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

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?

ghilint bot for eslint anyone?

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.

"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?

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

Github has been aware of the gripes for a long time. The "Dear GitHub" letter came after many months of trying to get GitHub to respond through other channels.

The "6 months" timer doesn't reset every time you ask.

If GitHub wanted to do something, it shouldn't have required the "Dear GitHub" letter, and once it got to that they should have responded promptly. That they haven't ever responded official (to my knowledge) is a sign that they have no interest in dealing with the issues.

Reply on news.ycombinator.com