19 ms·

Investigate switching away from GitHub

498 points by kristiandupont 11y ago

makecheck 11y ago
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?
- dozzie 11y ago
  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.
  - oldmanjay 11y ago
    "It takes a long time to understand" is synonymous with "can be improved."
    - pklausler 11y ago
      Counterexample: the universe.
      - astrange 11y ago
        I think the universe has a long list of outstanding feature requests.
        davidhowlett 11y ago
        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.
    - gkya 11y ago
      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.
  - oldmanjay 11y ago
    "It takes a long time to understand" is synonymous with "can be improved."
  - qwertyuiop924 11y ago
    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.
    - dozzie 11y ago
      > 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.
  - efes 11y ago
    > 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.
    - dozzie 11y ago
      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.
  - mitm2mitm 11y ago
    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.
- dominotw 11y ago
  If there is no central server like github. What do you map origin to?
  - ossreality 11y ago
    You can't be serious...
  - cyphar 11y ago
    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.
    - dominotw 11y ago
      But which one does the team deploy if everyone is sending patches to each other.
- mbrock 11y ago
  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.
  - qwertyuiop924 11y ago
    I was about to post this, but less eloquently, and without the obvious metaphor.
  - makecheck 11y ago
    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.
    - jasode 11y ago
      >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.
- volaski 11y ago
  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.
- exolymph 11y ago
  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-df99079f0086#.ib4qa0nyw https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df990...
- jotux 11y ago
  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?
- emmelaich 11y ago
  You could use a distributed bug tracker like http://www.bugseverywhere.org/ 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: ..."
bluetidepro 11y ago
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 https://github.com/dear-github/dear-github
- goddammit 11y ago
  +1
dudul 11y ago
I didn't know about phabricator, looks pretty interesting.
bphogan 11y ago
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.
- joshmanders 11y ago
  > 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.
  - bphogan 11y ago
    Yup. My students are always asking how they can get involved in open source....
    - joshmanders 11y ago
      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.
mchahn 11y ago
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.
gionn 11y ago
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?
- dominotw 11y ago
  i usually dislike bots like those but gordontheturtle is very helpful i must say.
- deleted 11y ago
  [deleted]
sylvinus 11y ago
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?
- bphogan 11y ago
  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. :)
  - scrollaway 11y ago
    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.
    - bphogan 11y ago
      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.
      - epistasis 11y ago
        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.
wildpeaks 11y ago
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 :/
- spike021 11y ago
  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.
  - bsimpson 11y ago
    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.
  - roryokane 11y ago
    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.
hoodoof 11y ago
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.
- 0xffff2 11y ago
  "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?
  - hoodoof 11y ago
    I guess they are busy working out how to maximise their venture capital?
- timv 11y ago
  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.
Kinnard 11y ago
GitTorrent? https://github.com/cjb/GitTorrent https://github.com/cjb/GitTorrent
- XorNot 11y ago
  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.
  - ossreality 11y ago
    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....
  - NotUsingLinux 11y ago
    Yes absolutely, I think self hosted conted and hash addressed binares would be a great thing to investigate!
jcoffland 11y ago
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.
- derefr 11y ago
  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.
  - op00to 11y ago
    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".
CSDude 11y ago
Phabricator is really nice, recommended.
phasmantistes 11y ago
> 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.
- kleinsch 11y ago
  Did you read the article? https://github.com/dear-github/dear-github 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...
  - phasmantistes 11y ago
    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.
- 11y ago
programminggeek 11y ago
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.
hartator 11y ago
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.
potch 11y ago
In my experience, hosting code/issues off of GitHub reduces triage time maintenance burden by reducing the number of contributors.
Sleaker 11y ago
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.
- mcguire 11y ago
  What is GitLab's issue tracking like?
  - Sleaker 11y ago
    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.
    - tomjakubowski 11y ago
      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.
      - sytse 11y ago
        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_3670049 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/ https://about.gitlab.com/jobs/ I hope your problems are solved when you upgrade to GitLab 8.4.
op00to 11y ago
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.
bch 11y ago
> 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 http://www.fossil-scm.org [1] http://fossil-scm.org/index.html/doc/trunk/www/bugtheory.wiki http://fossil-scm.org/index.html/doc/trunk/www/bugtheory.wik... [2] http://fossil-scm.org/index.html/doc/trunk/www/wikitheory.wiki http://fossil-scm.org/index.html/doc/trunk/www/wikitheory.wi... [3] http://fossil-scm.org/index.html/doc/trunk/www/event.wiki http://fossil-scm.org/index.html/doc/trunk/www/event.wiki
spatten 11y ago
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 https://github.com/ansible/ansible/issues/6112 They have more info here: https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.md https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.m...
musha68k 11y ago
ghilint bot for eslint anyone?
jvehent 11y ago
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.
mayank 11y ago
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/ https://developer.github.com/v3/issues/
robbiemitchell 11y ago
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.
dhagz 11y ago
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.
sorpaas 11y ago
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?
tomcam 11y ago
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?
andrewchambers 11y ago
It is funny how the issue is about low quality issue tracking and then it instantly gets spammed by garbage. Good on them.
DannoHung 11y ago
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.
astrostl 11y ago
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.
benhamner 11y ago
It's surprising just how silent GitHub is on these issues. Most of their engineers probably read Hacker News, yet none of them respond.
- astrodust 11y ago
  Wanting to respond and being able to respond, which has the effect of making you an unofficial spokesperson, are two different things.
petetnt 11y ago
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).
fibo 11y ago
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.
lazyjones 11y ago
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...
bluenose69 11y ago
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.
lips 11y ago
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.

498 points by kristiandupont 11y ago

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?

dozzie 11y ago
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.
- oldmanjay 11y ago
  "It takes a long time to understand" is synonymous with "can be improved."
  - pklausler 11y ago
    Counterexample: the universe.
    - astrange 11y ago
      I think the universe has a long list of outstanding feature requests.
      - davidhowlett 11y ago
        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.
  - gkya 11y ago
    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.
- oldmanjay 11y ago
  "It takes a long time to understand" is synonymous with "can be improved."
- qwertyuiop924 11y ago
  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.
  - dozzie 11y ago
    > 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.
- efes 11y ago
  > 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.
  - dozzie 11y ago
    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.
- mitm2mitm 11y ago
  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.
dominotw 11y ago
If there is no central server like github. What do you map origin to?
- ossreality 11y ago
  You can't be serious...
- cyphar 11y ago
  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.
  - dominotw 11y ago
    But which one does the team deploy if everyone is sending patches to each other.
mbrock 11y ago
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.
- qwertyuiop924 11y ago
  I was about to post this, but less eloquently, and without the obvious metaphor.
- makecheck 11y ago
  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.
  - jasode 11y ago
    >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.
volaski 11y ago
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.
exolymph 11y ago
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-df99079f0086#.ib4qa0nyw https://medium.com/@Exolymph/i-swear-i-m-not-a-statist-df990...
jotux 11y ago
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?
emmelaich 11y ago
You could use a distributed bug tracker like http://www.bugseverywhere.org/ 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: ..."

bluetidepro 11y ago

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 https://github.com/dear-github/dear-github

goddammit 11y ago
+1

dudul 11y ago

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

bphogan 11y ago

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.

joshmanders 11y ago
> 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.
- bphogan 11y ago
  Yup. My students are always asking how they can get involved in open source....
  - joshmanders 11y ago
    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.

mchahn 11y ago

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.

gionn 11y ago

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?

dominotw 11y ago
i usually dislike bots like those but gordontheturtle is very helpful i must say.
deleted 11y ago
[deleted]

sylvinus 11y ago

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?

bphogan 11y ago
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. :)
- scrollaway 11y ago
  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.
  - bphogan 11y ago
    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.
    - epistasis 11y ago
      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.

wildpeaks 11y ago

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

spike021 11y ago
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.
- bsimpson 11y ago
  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.
- roryokane 11y ago
  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.

hoodoof 11y ago

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.

0xffff2 11y ago
"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?
- hoodoof 11y ago
  I guess they are busy working out how to maximise their venture capital?
timv 11y ago
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.

Kinnard 11y ago

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

XorNot 11y ago
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.
- ossreality 11y ago
  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....
- NotUsingLinux 11y ago
  Yes absolutely, I think self hosted conted and hash addressed binares would be a great thing to investigate!

jcoffland 11y ago

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.

derefr 11y ago
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.
- op00to 11y ago
  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".

CSDude 11y ago

Phabricator is really nice, recommended.

phasmantistes 11y ago

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

kleinsch 11y ago
Did you read the article? https://github.com/dear-github/dear-github 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...
- phasmantistes 11y ago
  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.
11y ago

programminggeek 11y ago

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.

hartator 11y ago

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.

potch 11y ago

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

Sleaker 11y ago

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.

mcguire 11y ago
What is GitLab's issue tracking like?
- Sleaker 11y ago
  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.
  - tomjakubowski 11y ago
    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.
    - sytse 11y ago
      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_3670049 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/ https://about.gitlab.com/jobs/ I hope your problems are solved when you upgrade to GitLab 8.4.

op00to 11y ago

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.

bch 11y ago

> 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 http://www.fossil-scm.org [1] http://fossil-scm.org/index.html/doc/trunk/www/bugtheory.wiki http://fossil-scm.org/index.html/doc/trunk/www/bugtheory.wik... [2] http://fossil-scm.org/index.html/doc/trunk/www/wikitheory.wiki http://fossil-scm.org/index.html/doc/trunk/www/wikitheory.wi... [3] http://fossil-scm.org/index.html/doc/trunk/www/event.wiki http://fossil-scm.org/index.html/doc/trunk/www/event.wiki

spatten 11y ago

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 https://github.com/ansible/ansible/issues/6112 They have more info here: https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.md https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.m...

musha68k 11y ago

ghilint bot for eslint anyone?

jvehent 11y ago

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.

mayank 11y ago

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/ https://developer.github.com/v3/issues/

robbiemitchell 11y ago

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.

dhagz 11y ago

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.

sorpaas 11y ago

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?

tomcam 11y ago

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?

andrewchambers 11y ago

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

DannoHung 11y ago

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.

astrostl 11y ago

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.

benhamner 11y ago

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

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

petetnt 11y ago

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

fibo 11y ago

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.

lazyjones 11y ago

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

bluenose69 11y ago

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.

lips 11y ago

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.