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.
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'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.
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.
Just reinventing the StackOverflow experience.
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.
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.
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.
* 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.
They mention nowhere that they'll somehow end up with less bugs if they leave GitHub
Making stackoverflow the path of least resistance for everyone else will ony serve to make everyone's lives easier.
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.
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.
"Excluding merges, 12 authors have pushed 20 commits to master and 28 commits to all branches. On master, 113 files have changed and there have been 2,178 additions and 625 deletions."
Rust, also on github, 2/4 - 2/11:
"Excluding merges, 34 authors have pushed 123 commits to master and 139 commits to all branches. On master, 335 files have changed and there have been 7,587 additions and 5,722 deletions."
I'm not sure that github is the problem.
There's no way you can draw any conclusions based on these numbers, aside from that they are different projects with different rates of code activity.
I was actually the one to file the issue discussing migration, back in 2012: https://github.com/rust-lang/rust/issues/2865 .
We've generally come to terms with using Github Issues (not terrible, not great, Just Okay). We do have to spend a lot of effort on triage, but that's true of any bug tracker (fortunately we also have Steve Klabnik, the unstoppable titan of bug triage).
> We do have to spend a lot of effort on triage, but that's true of any bug tracker
It seems like people are looking for a magical way to get out of doing triage, dealing with bad issues, and moderating comment threads. It just isn't something that's going to happen. Bugzilla has voting, for example, but "me too" comments are still a problem on bugs that get shared outside of the community, 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.
: https://bugzilla.mozilla.org/show_bug.cgi?id=923590 was shared in a bunch of different places, and there were a lot of +1 and "me too" comments.
> Sure, sorry if I came off like I was using you guys as a
> political football or something.
There's no silver bullet to triage, but assistance from the platform can help in small ways that add up over time. For a project like Rust, for instance, we need a test case with each bug report, without which reproduction, triage, and regression testing is impossible. An issue template that suggests a test case would go a long way.
Another example, from a different project I've worked on: Dungeon Crawl Stone Soup is a roguelike game that recently switched its canonical repo to Github, but was unable to switch its issue tracker to Github Issues because they rely on users being able to attach savegames with crash reports. Github Issues only allows images to be attached, so unless they expect users to steganograph their savegame into an image macro then GI is simply a non-starter.
Rust 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.
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.
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.
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).
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
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.
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.
And when you then continue on to claim that PM's is the panacea that will "fix OSS culture" I feel I have to point out that "OSS culture" is what built the technological world we live in today. And while its not perfect, I respectfully suggest that you don't fuxor with things that are not broken, given that the OSS world's track record of delivering world changing software is unrivalled.
To put it more succinctly:
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.
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.
Linus also delegates to his kernel "lieutenants" to scale Linux development.
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.
Number that attempt to get involved is unknown.
I require 1st semester students to push final projects to Github public repositories so they learn Git.
Biggest problem is that they can't program very well yet but want to contribute. So any low-hanging fruit is welcome, really.
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.
1st level triage for issues could be done by developer in the Phillipines on Upwork for like $5-10/hr.
The problem really is they've hit a scale where they need a human CSR to handle their 1st level triage but they don't have the cash to pay one.
Volunteers find the work mind numbing enough they refuse to do it for long generally.
All the people making money on books about ES6 could kick in. All the folks making screencasts could kick in.
All the companies making money on open-source could kick in.
And volunteers? They should cycle out and move up into more interesting work, making room for new people to do that. That's what I was thinking.
Not that I'm saying that volunteers are better -- they asked, no one stepped up, which means to me that volunteers are a non-starter.
BTW I also commented in the issue https://github.com/eslint/eslint/issues/5205#issuecomment-18...
Whether this is a bug or a feature is left as an exercise to the reader.
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.
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)
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).
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.
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.
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.
and a log was copied to your clipboard so you could paste it in...
Users won't read:
GitHub doesn't need to become jira, but just promoting the tag system to a custom field system would help.
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.
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.
Edit: my bad, 143 is only "open" issues. Nearly 3,000 total.
Not sure what determines an onslaught, but just so the numbers are clear.
> 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.
Of course, I can't find the book online now. I thought it was a Microsoft Press book by Steve McConnell or Steve Maguire.
Or maybe it was Steve McConnell's you recommend?:
Software Project Survival Guide (Microsoft, 1997)
That sounds simple. You're volunteering, then?
But saying "surely someone can just volunteer" is pointless in the absence of evidence that someone actually wants to volunteer. If anything the evidence points to not enough volunteer triage PMs - the OSS world is not short on projects that could use a triager.
But I didn't say "surely someone can just volunteer". I said that they should "get someone to join". There are a lot of ways to do that, and many of them involve the current team members being proactive about going out and trying to recruit someone to fill that role. The OSS communities can't just rely on the "if you build it they will come" philosophy -- if you really want your project to grow, you have to be willing to put yourself forward and actively get people to help you.
Orrrr the current team members can be proactive and do something that will reduce the number of bad bug reports they get.
Without Github Issues you might miss out on useful input such as https://github.com/kennethreitz/records/issues/10 though.
It's a canned response that people roll out whenever anything is raised about an open source project.
"Find a volunteer" is a useless suggestion to make to a volunteer organization.
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...
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.
Do they actually want all those large open source projects to leave?
> Issue ordering and voting were used by an incredibly small number of users and we made the decision to drop them. Leaving features in that only ten people use is how to create Jira, not GitHub.
Obviously, that was a while ago and things might be different now.
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. :)
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.
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.
There's been no official communication in a month, so I don't think its unreasonable that projects are starting to look at alternatives and start to believe that github is unresponsive to their problems.
Can we be better? Absolutely, yes. This is the most "care hard" company I've ever worked at, and we really want to do things to the best of our abilities. I know this doesn't help you if there's something you've asked for, or something you legitimately _need_ and don't have yet; what I hope will help is knowing that these requests aren't being ignored.
Some personal examples:
For years I've worked with Microsoft products. The company I worked for paid big bucks for Microsoft enterprise support. Tried to use many times, always same results. "We'll send this to engineering." Never a response.
Same with Apple. Bought an iMac that repeatedly ejected USB disks. Known issue. Apple support forums have hundreds of unanswered, unresolved threads on this issue. Yet Apple support had "never heard of it." Same "we'll send your logs to engineering and get back to you." And never heard back.
Local cable companies call you constantly to get you to sign up for services. Then when there's a problem they'll come out and fix when they feel like it.
Got a problem with your Google Apps account you pay for? Good luck.
Sell something on Ebay and someone screws you over? Ebay still keeps their cut of course.
Paid $1500 for Google Glass, found out explorer project was shutting down through Twitter and The Verge, rather than Google.
Had a Digital Ocean box disappear for no reason. Response from them was "sorry." Saw a recent article where someone else had that problem too.
Had a similar issue with a Linode box. Same results.
So maybe I just have terrible luck.
But I'm willing to bet that there's way more money in sales and marketing than there is in supporting existing customers.
Forking over money to a company provides zero benefits other than the use of the product or service, in my experience. You get no say in how things work there, and you're lucky to get someone who is actually empowered to help you.
Seems far fetched, but might just make sense given who pays their bills..
A "Fuck off and die, you don't pay our bills" response is going to provoke outrage and maybe even action. It would certainly provide reinforcement for those of us who don't really like github for various reasons.
Not responding at all leaves things vague and doesn't provoke action.
Want github to respond? Start moving some famous projects off of github and onto something else. A couple big name projects that start making some other service look like the "default" winner and github will get REAL responsive.
Until people start moving projects (like this one), github doesn't have to care.
Edit: for bad grammar.
From an outsider perspective, it looks like they're preoccupied with putting out fires.
The flat organizational structure, absent strong leadership, has allowed some bad actors to manipulate there way into positions of power/influence within the organization. The CEO and driving force of the organization from its outset has been ejected after making the mistake of fraternizing with his employees. The new CEO lacks the leadership and strong personality required to take up the reigns with the current structure. A culture that was established to be inclusive is being leveraged by a malicious outspoken minority to achieve the opposite; which is causing a lot of backlash internally and externally. The public perception of the company is in free fall. Most, if not all of these issues present a legal and/or financial threat to the future of the company.
In short, GitHub's open and informal culture has become a liability.
It takes an established record of misbehavior to legally justify firing bad employees. Especially, those who will use their 'protected' status and public support to attack GitHub after being fired. I'd be willing to bet that their lack of organizational structure has left them without justification/protection and they're scrambling to make up for it.
To protect their investment, the wise thing to do would be to build some management hierarchy; which they're doing by pulling in all of the leadership from remote positions. They need to shield the current CEO from any more mishaps. They'll follow by establishing a record of poor performance for the outspoken assholes. Eventually, when they've established sufficient justification they'll eject the toxic individuals from the organization.
GitHub will emerge a mature and stable but less friendly/open organization. Hopefully, this doesn't negatively impact GitHub's willingness to support OSS.
"Do they actually want all those large open source projects to leave?"
Absolutely not. To ensure GitHub has a future, they have to fix the present.
What we may be witnessing is the hastening recovery of an organization that experienced a systematic failure.
They'll survive... Not before shedding some blood.
Too busy firing white males and hiring minorities to please the diversity committee.
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?
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.
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.
>Indeed, we had this, in the form of NNTP and older news servers;
You're focusing on the technical aspects. The other forces are social and economics. Both of those lead to centralization.
Take your example of Usenet news groups. Yes, in a technical sense, it's decentralized but once you get economics/money involved, what happens? My ISP like Verizon doesn't carry all newsgroups (e.g. exclude newsgroups with large binaries.) Or another ISP may carry more newsgroups but the retention is 1 month instead of 1 year.
So the economics converges to an central entity like Deja News that emphasizes the archival of usenet posts. Then Google buys them (Google Groups). Google Groups is now "centralized" for finding very old usenet posts. Conceivably, any of us besides DejaNews could have archived the posts but we didn't spend the money on harddrives to store it whereas DejaNews did. Hence, we end up with a centralized archive.
When I had Verizon, their newsgroups feed was very poor. I therefore paid $10 extra to GigaNews because they had everything with multi-year retention. That's another "centralized" hub driven by economics.
Looking only at the usenet RFC technical specs for distributing news posts doesn't reveal how the economics makes centralization emerge.
As for github's centralization...
A lot of us want to host a public git repository. Hmmmm... if github didn't exist, what do we do? Pay for a VPS for $9/month plan and host git on that? What about extra bandwidth costs if it's a popular repo and lots of people are cloning it? That's a lot of ugly financial bookkeeping that we don't want to do since we'd rather just concentrate on programming. Wait -- there's an ABC company out there that lets me conveniently host a git repo there? For free? Sign me up!
That "ABC company" by way of economics and social dynamics has turned out to be Github and BitBucket. And since Github has been winning the mindshare, you get centralization. There is no irony in git-the-tool being distributed and github-the-focal-point being centralized.
I'm really interested in the future of distributed code collaboration. I just think it's not so trivial, and so it's very understandable that people have gravitated towards a semi-centralized model that already works.
Perhaps having something akin to a private NNTP server that requires authentication to post for each open source project, but is publicly viewable. These news servers could be configured to send IHAVE <article> to other news servers to increase visibility. There could be a newserver like gmane to aggregate the feeds from each of those private news servers.
If you could get an authentication system that could work across those news servers, then you could have a decent system for keeping up with and contributing to open source projects.
'Moderated' means that all postings to the newsgroup go to a mail
address (e.g. email@example.com) instead of appearing
in the newsgroup directly. The postings are then forwarded via
email to a moderator, or group of moderators, or even an automated
program, who decides whether to actually inject the article into
the newsgroup or to reject it as not meeting guidelines spelled
out in the group's charter.
Proper moderation for anything important would require cryptographic signatures and a solid federated PKI. Maybe the world is ready, this time. :)
As long as you have an actual living conversation, then an open model of development can work... which means it doesn't have to be perfect from the start, and you don't need a beautiful landing page, because you want to attract the hackers and crazy people.
You also want to encourage lots of forks and independent implementations, because if it turns into some big mega-repository with some big bloated thing that includes Scala, Erlang, Babel, Bootstrap, and who knows what other ungodly monsters, then it's just going to become a boring monstrosity.
So you'd start with inviting a few people and then encourage them to use their own servers and clients. Make sure everyone understands that the protocols are in flux because you're trying to figure out together what will work.
The conceptual simplicity of Git would be an inspiration. There are different implementations of Git... but we could be even more obviously amenable to that, by using standardized messaging formats for example.
I think plain text messages, as on Usenet and mailing lists, are the best. You don't have to agree on a Markdown/whatever complex thing. Attachments if you want to send other documents. Hacker News developed consensus formatting for links and footnotes, and we seem to get on fine without inline images and tables and all the other fancy nonsense.
(Just some random thoughts...)
There's a lot of good stuff in XMPP, too. As well as some pre-discovered dead ends.
The distributed/federated stuff is still alive, maybe more than ever. Git is a fantastic example. I push and pull repositories between computers all the time. Often over ad-hoc WiFi, even.
Usenet and all that stuff is beautiful to reminisce about, but we should keep in mind also that it was largely sponsored by universities, corporations, militaries, and internet service providers...
IRC is a great inspiration too. Nowadays people look at it and think "ew, no Unicode" or "duh, it's not even JSON," but considering its resilience, its simplicity, its adoption, it's an enormous, staggering success.
These beautiful projects that started as tiny little seeds by clever obscure Scandinavian hackers...
It's just all about starting a little thing, getting your friends in on it, and keepin' it hella real.
Since the bandwidth funding model has now bubbled down to the consumer marketplace, it seems like the conditions are right for a huge variety of services. Actually that was starting to happen before the web swallowed all other services. Don't get me wrong, the web was/is a great thing, but it severely dumbs down the range of protocol expression. The state of websockets in 2016 is a weak imitation of IRC or MUD capabilities more than 20 years ago (never mind adoption problems).
I guess that's a curse of being "good enough". The better has an uphill battle.
What I like about news readers is how they track new threads / messages. I could pick up where I left off. It encouraged longer term, more elaborate discussions, as opposed to posts that fall off the first couple pages like most web forums.
It's amazing to me that git's power to easily manage distributed software development been lost/forgotten with Github. You don't need a web interface to contribute code. Linux is doing just fine.
You just need git and some sort of communication tool to distribute patches, email being the most powerful, flexible, and ubiquitous I've seen.
I would say that having a private NNTP server (one requiring an account to post) would also work in lieu of email. In fact, it would be better than email because it would allow new members to easily browse list archives. At least gmane already does something like that for some mailing lists.
>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?
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.
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.
> I don't use OS specific packaging because it was intentionally written to be
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.
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.
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.
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.
Personally, I use NPM because NPM does local versioning, so I will never end up in dll hell.
Also, NO, NEVER WRITE A PACKAGE THAT HAS EXPLICIT KNOWLEDGE OF A DISTRO PACKAGE MANAGER. If you do, you are being an asshole. If you want to depend on a distro specific package manager, document your dependencies, and just expect them to be there. Because not everybody uses your package manager.
People get so bizarrely bent out of shape over npm dependency quantity rather than ease of use.
The physicists are trying hard to reverse engineer it though.
"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: ..."
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.
A company I worked for has outsources some payments infrastructure to a third party. That third party had put in a very aggressive bid in order to win our business. We were to be their "big name customer" and they wanted to use that deal to gain credibility with other potential customers. It seemed like a rational business decision for them, and we took the deal.
But, the fact is, that deal wasn't commercially sustainable, and we both suffered from it. They lost money on everything they did for us, and because they were losing money they tried to do everything as quickly and cheaply as they could, which inevitably meant badly. We were never happy with their offering.
When the time came to renegotiate the deal, we went back out to market, and we invited them to participate in the tender process, but we were very clear - "This is the SLA we expect. These are the penalties we will apply if you miss the SLA. We intend to hold you to them. If you submit a bid, make sure it is commercially viable, and that you can afford to actually deliver on the SLA, or else you will end up losing a lot of money on this."
I think we ended up sticking with them for a bit longer (due to politics and inertia) and then eventually ditched them a few years later.
There are people who want to get things done in the upstream project, and they try... but they just don't have the resources, because most of the people on the project are busy doing their jobs.
Excluding corporate-support-contract-of-this-project employees from having contributor rights to the upstream project might work, but then you get the opposite problem: a downstream that's increasingly diverged from the upstream (because if the customers want a feature, but upstream won't take the patch, forking is pretty much necessary) where the "free core" of the upstream begins to stagnate because (in relative terms) nobody's eyes are on that code.
Low quality bug reports waste everyone's time: I don't know of any developer who would disagree (open source or not, paid work or volunteering). If the "user input" is low quality bug reports, then it is a burden. Complaining that Issues enables low-quality bug reports isn't hubris.
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 :/
But that still has the separate Issues issue.
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.
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).
* 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.
In the current version of GitLab you're able to add multiple labels, add a label while seeing the issue show page and the edit page should be faster.
We're working all the time to make GitLab faster and today we made the issue page load 3x faster on GitLab.com https://gitlab.com/gitlab-com/operations/issues/42#note_3670...
There should not be many markdown/css problems in the product as far as I know. There certainly is still room for improvement in the GitLab UX (especially on mobile), and we're not happy yet. We hired our second frontend engineer this week and we're looking for more on https://about.gitlab.com/jobs/
I hope your problems are solved when you upgrade to GitLab 8.4.
That's great news that I'm very glad to hear, thanks! Our ops folks are usually on top of GitLab upgrades, so I don't expect to wait too long :-)
For sake of interest I feel compelled to mention that fossil does have a fully-integrated ticket system (and more) 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.
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.
> 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 .
Though IPFS might be less of an impedance mismatch.
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....
They have more info here: https://github.com/ansible/ansible/blob/devel/CONTRIBUTING.m...
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...
> 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.
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.
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  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.
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.
"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.
ZenHub and auto-closing bots both seem like fine present-state improvements to me.
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.
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.