7 ms·

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

nightpool 11y ago
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)
- cdcarter 11y ago
  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.
  - nightpool 11y ago
    Sure, but again, that's a difference in the projects—not something inherent in the way Github handles issues.
    - cdcarter 11y ago
      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.
      - mcguire 11y ago
        That isn't really true. The more "resources" you have, the more stress you put on your communications mechanisms, like issue tracking.
- kibwen 11y ago
  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 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 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).
  - steveklabnik 11y ago
    (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.)
    - kibwen 11y ago
      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_community_happy_with_github_issues/ https://www.reddit.com/r/rust/comments/45fsbe/is_the_rust_co... ).
  - nightpool 11y ago

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)

cdcarter 11y ago
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.
- nightpool 11y ago
  Sure, but again, that's a difference in the projects—not something inherent in the way Github handles issues.
  - cdcarter 11y ago
    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.
    - mcguire 11y ago
      That isn't really true. The more "resources" you have, the more stress you put on your communications mechanisms, like issue tracking.
kibwen 11y ago
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 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 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).
- steveklabnik 11y ago
  (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.)
  - kibwen 11y ago
    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_community_happy_with_github_issues/ https://www.reddit.com/r/rust/comments/45fsbe/is_the_rust_co... ).
- nightpool 11y ago