Refine distinction between UI and web interface

1 files changed, 6 insertions, 6 deletions

diff --git a/docs/realgit.md b/docs/realgit.md
index e6eb487..584c675 100644
--- a/docs/realgit.md
+++ b/docs/realgit.md
@@ -6,7 +6,7 @@ For too long have I held the incorrect belief that we needed a GitHub alternativ
 
 ## Interface
 
-Ask yourself: is a web app the only way to do issues/tickets, pull requests/merge requests, etc? Golden Krishna, in his book *The Best Interface is No interface*, sharply criticizes how people take it for granted that a good product deserves a good UI. It would be a no-brainer for them to "Slap an Interface on it". Over the course of GitHub's "success", shiny tabs labeled "issues" and "pull requests" gain ubiquity on other VCS frontends. It disrupted the industry. 
+Ask yourself: is a web app the only way to do issues/tickets, pull requests/merge requests, etc? Hear me out: people take it for granted that a good product deserves a shiny dashboard. Over the course of GitHub's "success", shiny tabs labeled "issues" and "pull requests" gain ubiquity on other VCS frontends. It disrupted the industry. 
 
 How did developers contribute to FOSS projects back when GitHub wasn't a thing? Well, before StackOverflow, we had forums. Similarly, before GitHub, we had mailing lists. It has been long known to me that the Linux kernel is developed on a mailing list, where contributors would submit patches and receive a *Wish You Were Never Born, Dumbass* Certificate from Linus. However I, along with many others had no idea how it's *actually* done. Check out [the PR page of the Linux repo on GitHub](https://github.com/torvalds/linux/pulls). *Too many* people have mistaken a web UI, if not limited to GitHub, for *the* development platform for *anything*. Well, it's definitely not how Linux is developed.
 
@@ -16,7 +16,7 @@ You notice a clear distinction between "coders" and "developers": it's like huma
 
 ## The Real Git
 
-I will use [sourcehut](https://sourcehut.org/), aka sr.ht as an example. I stumbled upon it a while ago, but it wasn't until yesterday that I tried it out for its simplicity. Simple as in no bloat, not in being for dummies. For starters, there's no JavaScript. Really, you should check out its interface. Or not. It doesn't matter, something else does, and I sincerely regret having overlooked this "selling point": the absence of selling points. The UI does not only *look* simple, it *is* simple. You can't do pretty much anything with it. For this reason, I refuse to call it "Git on steroids"; instead, it's "Git without hurdles", hurdles scattered in your dev work every single day. OK, listen carefully: all the interactions I used to assume to be web-only, happen on mailing lists. To submit a patch (retro version of "pull request" - remember that?), you simply commit your changes locally, run this command: `git send-email --to="~user/repo@lists.sr.ht" HEAD~`, and your patch is out there waiting for review. Of course, a shitload of configuration has to be done ahead, which is partly why this email-driven development hasn't really taken off in the younger demographic.
+I will use [sourcehut](https://sourcehut.org/), aka sr.ht as an example. I stumbled upon it a while ago, but it wasn't until yesterday that I tried it out for its simplicity. Simple as in no bloat, not in being for dummies. For starters, there's no JavaScript. Really, you should check out its interface. Or not. It doesn't matter, something else does, and I sincerely regret having overlooked this "selling point": the absence of selling points. The web design does not only *look* simple, it *is* simple. Almost read-only, you can't do pretty much anything with it. For this reason, I refuse to call it "Git on steroids"; instead, it's "Git without hurdles", hurdles scattered in your dev work every single day. OK, listen carefully: all the interactions I used to assume to be web-only, happen on mailing lists. To submit a patch (retro version of "pull request" - remember that?), you simply commit your changes locally, run this command: `git send-email --to="~user/list@lists.sr.ht" HEAD~`, and your patch is out there waiting for review. Of course, a shitload of configuration has to be done ahead, which is partly why this email-driven development hasn't really taken off in the younger demographic.
 
 Despite its drawbacks, I find it superior to web apps. First of all it obviously saves bandwidth as well as time, since no time is wasted on the UI; the terminal plus an email client satisfy all needs. Second is because it's *dank as shit*. With the right configuration, you can set up a TUI email client, which enables you to combine the entirety of your workflow in the terminal. Finally, and the **most importantly**: it does *not* require an account for contributors to submit a patch. All it takes is your email address as your identity, and an email containing your patch. And *this*, is how Git is supposed to work. Read more on @OTheB's blogpost, the one that had me sold: [how to use git](https://boxin.space/post/how-to-use-git) (with fancy screenshots I'm too lazy to take). I'm not asking you to stop using web UI's; I'm reasoning how the alternative is more efficient, and should be considered as a solid option.
 
@@ -28,7 +28,7 @@ Under what circumstance should you try this? When you're in a (probably small in
 
 ### Email
 
-With any given Git hosting platform with a fancy UI, you very likely use your email to login. After that, you only occasionally receive notifications in your mailbox. Stuff happens over HTTP mainly, so it doesn't matter if you're using a shitty webmail interface like GMail. Let's say you ditched GitHub and went all in on email-driven development. Now email becomes a crucial part of your web-free workflow, and you can't just use another web interface while expecting to be a 10x dev. Furthermore, the email address is no longer *part* of your identity; it *is* your identity. Your patches are submitted through it, PGP key generated under it. So it is utterly critical to get this right before you even start.
+With any given Git hosting platform with a fancy web interface, you very likely use your email to login. After that, you only occasionally receive notifications in your mailbox. Stuff happens over HTTP mainly, so it doesn't matter if you're using a shitty webmail interface like GMail. Let's say you ditched GitHub and went all in on email-driven development. Now email becomes a crucial part of your web-free workflow, and you can't just use another web interface while expecting to be a 10x dev. Furthermore, the email address is no longer *part* of your identity; it *is* your identity. Your patches are submitted through it, PGP key generated under it. So it is utterly critical to get this right before you even start.
 
 #### Provider
 
@@ -64,8 +64,8 @@ A lot. While beginners tend to wet their hands in a web environment they're fami
 
 ## TL;DR
 
- Many people believed the GitHub-like UI is the way all FOSS is developed. They are wrong. A web UI is not the only nor the original way to use git; you could use [git-send-email](https://git-send-email.io) to submit patches in mailing lists, and as maintainers you can merge them using git's stock utilities. Some people have never heard of the latter because they were never told about it; meanwhile, the web UI has hijacked their mindset. [Sourcehut](https://sourcehut.org/) is an example of email-driven development with a minimalistic web frontend. In such development scheme you will find your workflow more efficient, especially if you are used to a terminal. The obvious pain in the neck is a good mailbox as your identity and a local client that doesn't suck. I hope you're experienced enough to figure those out. Then it's the low public exposure of a mailing list. Perhaps maintain a mirror on a UI-driven site as a portfolio.
+Many people believed the GitHub-like UI is the way all FOSS is developed. They are wrong. A web UI is not the only nor the original way to use git; you could use [git-send-email](https://git-send-email.io) to submit patches in mailing lists, and as maintainers you can merge them using git's stock utilities. Some people have never heard of the latter because they were never told about it; meanwhile, the web UI has hijacked their mindset. [Sourcehut](https://sourcehut.org/) is an example of email-driven development with a minimalistic web frontend. In such development scheme you will find your workflow more efficient, especially if you are used to a terminal. The obvious pain in the neck is a good mailbox as your identity and a local client that doesn't suck. I hope you're experienced enough to figure those out. Then it's the low public exposure of a mailing list. Perhaps maintain a mirror on a UI-driven site as a portfolio.
  
- The reason why I had never heard of such a thing before is no one told me the exact thing I needed to know. Also GitHub formed the stereotype of a git forge. There are certainly other young people suffering, unaware of email-driven development being an option. Tell them this thing has been around for 15 years.
+The reason why I had never heard of such a thing before is no one told me the exact thing I needed to know. Also GitHub formed the stereotype of a git forge. There are certainly other young people suffering, unaware of email-driven development being an option. Tell them this thing has been around for 15 years.
 
-Last updated: 2020-04-23
+Last updated: 2020-05-02