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