3 ms·

I have a hard time taking this seriously. Email is a pain to use compared to a dedicate feature UI. I think the real problem is the need for a standardized pul

I have a hard time taking this seriously. Email is a pain to use compared to a dedicate feature UI. I think the real problem is the need for a standardized pull request protocol that people can wrap. Then let people use email, a website, an API or whatever they want.

koluna 6y ago
100% this. I will take GitHub’s PR process over emailing diffs any day. It’s just a matter of improving user productivity.
- ddevault 6y ago
  Absolute nonsense. Emails are far more productive. I've made a video demonstrating the difference here: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
  - koluna 6y ago
    Literally nothing from what you showed is a pleasant customer experience. Overly complex workflow that can be simplified by what GitHub is doing. Think of a beginner developer who wants to learn how to contribute to an open source project. If they would be put through the process you showed, it will be a meat grinder that is going to be error prone. Zero need for that when GitHub has a great UX that focuses on getting shit done instead of fiddling with conventions from the 90s.
    - cnst 6y ago
      That's why there's shell completion, and history search; then with practice, keyboard shortcuts as well; all vastly improve productivity. I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it. But that's not the case at all. Moreover, GitHub has so many quirks, that most Enterprise shops don't use it internally for their own internal projects (unless they release said projects into OSS); so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company. Compare this with email. As the original article reveals, Linux and OpenBSD happen to have almost entirely identical workflows for patch submission, which is actually REALLY weird, considering that the two projects have entirely different histories, methodology, and use entirely different revision control systems, where OpenBSD still uses CVS, yet Linus Torvalds hated CVS so much, I recall that he refused to use it even before Git was ready and the licences for the predecessor system have already been withdrawn (I recall he hated CVS so much he simply used plain patches or tarballs).
      - algorithmsRcool 6y ago
        > I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it. For a lot of people, probably the large majority of people, GitHub's (or GitLab's) UI is simpler to work with than a terminal. The overwhelming success and popularity of GitHub has demonstrated the value of it's UI. I just don't see how you could convince the Atom/VSCode generation of developers to go back to mailing lists. > so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company. As far as I am concerned, the email workflow is just "another set of tools" too. Except no company I've worked with or worked for has used it.
        kasabali 6y ago
        > For a lot of people, probably the large majority of people, GitHub's (or GitLab's) UI is simpler to work with than a terminal. The topic isn't about majority of users. It is specifically about Linux kernel developers.
        algorithmsRcool 6y ago
        Fair point, I've strayed from the topic at hand.
  - algorithmsRcool 6y ago
    For what it is worth, I watched the video. I'm sorry, I just disagree. I think there are plenty of devs that agree with you, but I don't. Some points: - Working with the UI of GitHub is pretty painless to me. - On the other hand, I hate dealing with email and prefer tools like slack or even teams to checking and responding to emails. The thought of emailing patch diffs sounds crummy to me after being spoiled on the interactive UI flows of GH pull requests. - I think the big bifurcation is on the concept of staying in the terminal at all times. I don't develop that way. I also don't send emails from the terminal at all. I primarily work in C# and F# on Windows with VSCode and VS as my daily drivers for editing code. I use the IDE UI to switch branches, merge, rebase and commit most of the time. Perhaps I'm not your target audience. - I find Git's commands to be rather fiddly most of the time. And why bother remembering complex syntax when I can click familiar buttons. I prefer the ergonomics of the UI even if incurs a mental context switch. But really, that context switch doesn't hurt much compared to the cognitive load of my normal work. - The last point I'll make is discoverability. Just last week a friend of mine made her first contribution on GitHub in less than 10 minutes. Without needing to look up docs or google workflows. The GitHub UI made a complex concept such as Git branching and merging very simple for her. That alone is worth alot.

koluna 6y ago

100% this. I will take GitHub’s PR process over emailing diffs any day. It’s just a matter of improving user productivity.

ddevault 6y ago
Absolute nonsense. Emails are far more productive. I've made a video demonstrating the difference here: https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759 https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...
- koluna 6y ago
  Literally nothing from what you showed is a pleasant customer experience. Overly complex workflow that can be simplified by what GitHub is doing. Think of a beginner developer who wants to learn how to contribute to an open source project. If they would be put through the process you showed, it will be a meat grinder that is going to be error prone. Zero need for that when GitHub has a great UX that focuses on getting shit done instead of fiddling with conventions from the 90s.
  - cnst 6y ago
    That's why there's shell completion, and history search; then with practice, keyboard shortcuts as well; all vastly improve productivity. I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it. But that's not the case at all. Moreover, GitHub has so many quirks, that most Enterprise shops don't use it internally for their own internal projects (unless they release said projects into OSS); so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company. Compare this with email. As the original article reveals, Linux and OpenBSD happen to have almost entirely identical workflows for patch submission, which is actually REALLY weird, considering that the two projects have entirely different histories, methodology, and use entirely different revision control systems, where OpenBSD still uses CVS, yet Linus Torvalds hated CVS so much, I recall that he refused to use it even before Git was ready and the licences for the predecessor system have already been withdrawn (I recall he hated CVS so much he simply used plain patches or tarballs).
    - algorithmsRcool 6y ago
      > I think a lot of people wrongly assume that GitHub is so "easy" that you don't actually have to spend any time to learn how to use it. For a lot of people, probably the large majority of people, GitHub's (or GitLab's) UI is simpler to work with than a terminal. The overwhelming success and popularity of GitHub has demonstrated the value of it's UI. I just don't see how you could convince the Atom/VSCode generation of developers to go back to mailing lists. > so, when you work for any company that's not just a startup, you likely have to learn yet another set of tools. And again if you switch the company. As far as I am concerned, the email workflow is just "another set of tools" too. Except no company I've worked with or worked for has used it.
      - kasabali 6y ago
        > For a lot of people, probably the large majority of people, GitHub's (or GitLab's) UI is simpler to work with than a terminal. The topic isn't about majority of users. It is specifically about Linux kernel developers.
        algorithmsRcool 6y ago
        Fair point, I've strayed from the topic at hand.
- algorithmsRcool 6y ago
  For what it is worth, I watched the video. I'm sorry, I just disagree. I think there are plenty of devs that agree with you, but I don't. Some points: - Working with the UI of GitHub is pretty painless to me. - On the other hand, I hate dealing with email and prefer tools like slack or even teams to checking and responding to emails. The thought of emailing patch diffs sounds crummy to me after being spoiled on the interactive UI flows of GH pull requests. - I think the big bifurcation is on the concept of staying in the terminal at all times. I don't develop that way. I also don't send emails from the terminal at all. I primarily work in C# and F# on Windows with VSCode and VS as my daily drivers for editing code. I use the IDE UI to switch branches, merge, rebase and commit most of the time. Perhaps I'm not your target audience. - I find Git's commands to be rather fiddly most of the time. And why bother remembering complex syntax when I can click familiar buttons. I prefer the ergonomics of the UI even if incurs a mental context switch. But really, that context switch doesn't hurt much compared to the cognitive load of my normal work. - The last point I'll make is discoverability. Just last week a friend of mine made her first contribution on GitHub in less than 10 minutes. Without needing to look up docs or google workflows. The GitHub UI made a complex concept such as Git branching and merging very simple for her. That alone is worth alot.