This is not the only argument in this piece — I'd even argue that it's a minor one. It hardly makes sense to discredit the author and this article based on this GitHub misconception.
The free floating anxiety and dislike of the article is a symptom of an architectural/mgmt mistake in the article.
OK so there's a new long complicated extremely labor intensive elaborate detailed process. "Surely there had to be a better alternative?" Yes, yes there is. Unfortunately there are many options.
Now the correct answer would have been simplicate and add lightness. Agile manifesto "Individuals and interactions over processes and tools".
Instead, they found an overwhelmingly clunky and complex (their words not mine) tool to automate the complexity, or at least temporarily abstract it away, or at the very least replace one pile of complexity with another (larger?) pile of complexity.
Lets try a less controversial topic. Getting a pencil. All workplaces have different policies for office supplies. Order your own just like you buy your own clothes. Here's your annual office max gift certificate buy whatever you want. Here's a key to a supply closet. But here, we implemented a 15 page process involving teams of employees reviewing and documenting each individual request for a pencil in meetings. That's the bad news. The good news, is we replaced the original 15 page process with a 5 page process by installing an IBM mainframe, DB2, CICS, and writing a simple COBOL app that allows end users with newly installed 3270 terminals to request a pencil, and now we're better off than "ever before". Now most people would have handed out GCs, given out supply closet keys, or just trusted the employees, so you're going to get all kinds of semi-off topic blowback about how the COBOL program should have been the flavor of the month CRUD web JS framework, or instead of DB2 they really should have used nosql on the cloud so they can scale office supply request to all 100 employees not just a small team. But the real problem that everyone is squirming about is they're doin' it all wrong.
My main point here is that on GitHub, making a pull request is super easy. There's even a cool pop-up if you visit the main page of a repo after pushing to a branch that asks if you'd like to make a pull request.
Saying that this is somehow more complex than updating a single commit and learning a whole new tool doesn't change that if you want to convince me, you at least need to correctly identify what's going wrong.
Perhaps if the author had specifically called out their perceived failings of the very latest GitHub pull request changes I'd have given the article more time. But unfortunately the justification given for switching was really shallow.
OK so there's a new long complicated extremely labor intensive elaborate detailed process. "Surely there had to be a better alternative?" Yes, yes there is. Unfortunately there are many options.
Now the correct answer would have been simplicate and add lightness. Agile manifesto "Individuals and interactions over processes and tools".
Instead, they found an overwhelmingly clunky and complex (their words not mine) tool to automate the complexity, or at least temporarily abstract it away, or at the very least replace one pile of complexity with another (larger?) pile of complexity.
Lets try a less controversial topic. Getting a pencil. All workplaces have different policies for office supplies. Order your own just like you buy your own clothes. Here's your annual office max gift certificate buy whatever you want. Here's a key to a supply closet. But here, we implemented a 15 page process involving teams of employees reviewing and documenting each individual request for a pencil in meetings. That's the bad news. The good news, is we replaced the original 15 page process with a 5 page process by installing an IBM mainframe, DB2, CICS, and writing a simple COBOL app that allows end users with newly installed 3270 terminals to request a pencil, and now we're better off than "ever before". Now most people would have handed out GCs, given out supply closet keys, or just trusted the employees, so you're going to get all kinds of semi-off topic blowback about how the COBOL program should have been the flavor of the month CRUD web JS framework, or instead of DB2 they really should have used nosql on the cloud so they can scale office supply request to all 100 employees not just a small team. But the real problem that everyone is squirming about is they're doin' it all wrong.