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