1. 58
  1.  

  2. 21

    This is from 2010, but “Free Software Needs Free Tools” is just as relevant today if not more so: https://mako.cc/writing/hill-free_tools.html

    1. 24

      With respect to email, don’t forget that pull requests were once intimidating too - as anyone who frequently works with onboarding new developers to its workflow can attest. To help make onboarding users with email easier, I wrote this tutorial:

      https://git-send-email.io

      I also wrote a rebase guide which applies to both workflows for making your changes more consistent and easier to review:

      https://git-rebase.io

      1. 26

        https://git-send-email.io

        That nicely outlines how to send patches, but I think people have far more difficulty receiving patches via email. Not everyone uses mutt, aerc, or runs a patchwork instance. Many mail clients, that people are otherwise generally fairly happy using, are just super not great at handling emailed patches. Emailed patches also generally don’t show a CI status that you can view ahead of time (I have heard of some, but I don’t ever remember seeing it firsthand in the wild).

        It’s great that it (an email patch workflow) works well with your workflows and tooling, but for some people it just… doesn’t work as well.

        1. 3

          I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion. And testing your patches against SourceHut CI is pretty easy, before or after it’s sent.

          1. 26

            I think one issue is that for most of us, sending and receiving patches is a very small part of what we do with email, so choosing a mail client on that basis doesn’t make sense.

            1. 1

              But we aren’t forced to use only one mail client. I use several depending on context / the task at hand.

              1. 1

                I am curious about your multiclient workflow. Do you use multiple addresses, or use filters and one shared address? Or just all the mail in all of them?

                1. 3

                  Whether you use local maildir or imap, mail stores are designed for concurrent access. How many people check email on their phone and not their phone?

                  1. 1

                    Sure, but my question was specifically about their workflow with it.

                  2. 2

                    As it happens I do use multiple accounts for multiple “hats”, but that’s slightly orthogonal to multiple clients, which I use even for a single account. My daily driver is mutt; I use thunderbird for rare occasions when I need to see rendered html properly or perform a search (still haven’t got mairix or not much etc set up) and I often use ios mail app but mostly read only.

                    At work we use Gmail. I do check that from ios mail app too. I recently started configuring mutt to read my work mail too but it’s a work in progress so I still regularly open the Gmail website.

              2. 23

                I mean, those people who don’t have such a mail client are missing out. It’s like arguing that we should use SVN because not everyone has git installed, in my opinion.

                To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.
                Well…maybe.. I do find it unlikely that is going to convince very many people who weren’t already riding them, or weren’t already inclined to do so. Even if it is amazing.

                Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find that oddly humorous.

                Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                1. 6

                  To me it sounds a bit more like arguing “anyone who doesn’t ride a penny-farthing to work every day is totally missing out”.

                  I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                  Sidenote1: I may be wrong, but it even appears that Mutt itself uses gitlab instead of email based patches. If true, I find the humorous.

                  Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                  Sidenote2: I have nothing against email based patch flows, and if I am going to contribute to a project, I generally contribute in whatever form a project requires (within reason). But for my own projects, I do not desire an emailed patches based workflow (EPBW), nor do I desire to run/manage/admin/moderate(remove spam) a mailing list. That’s just me though.

                  That’s why Sourcehut can do it for you.

                  1. 9

                    I don’t really like this take. Having sunk thousands of hours into the GitHub, Gerrit, and email-driven workflows, I can confidently assert that the email-driven workflow, even setting aside the many respects in which it is politically and technically superior, is simply the most efficient for both contributors and maintainers. The penny farthing comparison is unfair.

                    A bit of an “Ipse dixit”, but I’ll take it at face value anyway. To be clear, my comment was in response to your statement:

                    I mean, those people who don’t have such a mail client are missing out.

                    Which is what I made the comparison against. You have now pulled in other concerns in your response, and attributed them to the comment I made. I find that a bit uncharitable. I guess at this point we can just agree to disagree.

                    Mutt uses Gitlab and mailing lists and Sourcehut, actually. The dominant avenue of contributions to mutt is through its hosted mailing list. They use Sourcehut CI, however.

                    That’s odd. I looked through the last 2 months of their mutt-dev mailing list, and saw no mailed patches, but several gitlab PRs. Maybe I saw the wrong mailing list? Maybe I didn’t go back far enough? Overlooked it?
                    It doesn’t really matter, and I’ll take your word for it that they predominantly use emailed patches.

                    1. 1

                      The last 2 months have only seen one patch on Gitlab:

                      https://gitlab.com/muttmua/mutt/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

                      After reviewing it myself I have to correct myself, I reckon that Gitlab and the mailing lists are at about an even pace these days.

                      1. 2

                        Do note: that was merged PRs. There were a couple of more (not many though!) in All which is what I looked at.

                2. 5

                  Not everyone is productive using such mail client. Personally, I just plainly cannot remember more than a few shortcuts, which is already a massive roadblock for effectively using CLI tools as for most of them rely on shortcuts to increase productivity, they also do not provide me with options of what I can do, and I cannot for my life remember what can I do for all the possible contexts, cause of course options on what you can do are dependent on the context which you are currently in. Some people just aren’t productive using CLI tools, and saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                  1. 2

                    saying that they “are missing out” because they plainly cannot effectively use the tool is simply gatekeeping.

                    This is absurd. If a mechanic decides that he “is not a ratchet person” and will only ever use open-end wrenches, then I will question his professionalism just as I would question a software developer that “is not a CLI person” and will not learn to use a CLI mail client.

                    He doesn’t need to use the CLI mail client for his day-to-day email, but he should be capable of learning how to use it to handle the occasional emailed patches.

                    1. 5

                      Or this person will work with whatever, when paid for (professionals are paid for their work by definition!), but will only work with tools he/she finds enjoyable when doing charity. Thus FLOSS projects forcing inconvenient, last century methods with arrogant communication are missing contribution.

                      I thing the FLOSS community should focus on this kind of openness more, instead of CoCs.

                      1. 2

                        Good point. For work I’ll use whatever tools get the job done, no matter how gruesome. But for FOSS contributions, I agree that if the tool is difficult or simply frustrating to use, then it may as well not exist.

                      2. 1

                        Wrong assumption. Difference between using GUI and CLI clients is not like between open-end and ratcheted wrenches. Using those wrenches is basically the same. Meanwhile the experience between using CLI and GUI mail client is a lot bigger. I’d compare it to using automatic and manual wood planes. You can work with higher precision and similar speed with manual hand plane, but most carpenters would choose automatic hand plane, as it “just works” and doesn’t require that much skill and learning to do.

                        And why should you care what kind of wrench does your car mechanic uses, if he does the job well? This isn’t a problem not using better tools, but a problem of tool abilities. The tools that an average developer uses does not represent the tools that are created for that workflow. And that is a problem.

                        1. 1

                          I’ll entertain the analogy to a wood plane, though I’m unfamiliar with the devices. You say it yourself: the manual wood plane is useful in certain circumstances but requires skill. So does the CLI mail client. Use the automatic wood plane where it fits, but at least learn the skill to use the manual wood plane where the higher precision is necessary.

                          A developer that refuses to acquire a skill is simply not professional.

                          1. 1

                            It’s not like it requires much skill. It is the basically the same skill. The difference is, you need to move the manual wood plane along the plank 10 times, while with automatic you only need to move it once and the motor does its job. Some people just don’t have the patience and/or physical stamina to use manual wood plane. Manual hand plane is in fact more configurable, and can be used in more specialized scenarios. So enthusiasts use hand planes. Your average carpenter does not.

                            1. 1

                              The analogy was not mine.

                      3. -1

                        Consider acme?

                        1. 2

                          I am unable to find such email client. And the point is, for a workflow to be usable by a wide range of people, it should require as little new tools that do the same as the ones they use. And in case of email clients, most people probably like their current email client, and they do not want to change it. So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                          1. 3

                            acme is a text editor which can be easily coaxed into being a mail client.

                            Consider as well that you needn’t discard your daily mail client in order to adopt another. What difference does it make if some technology is backed by email or by some other protocol? Just because you already have an HTTP client (e.g. your web browser) doesn’t mean another isn’t useful (e.g. curl).

                            1. 7

                              Acme does not seem like general user friendly. My colleagues all use JetBrains IDE’s and use Thunderbird as their mail client. And acme would be a downgrade for their experience. I might use it, but they wouldn’t. If I cannot offer them a good GUI email interface, there is no way they would switch to email-based workflow.

                              1. -1

                                I was recommending acme particularly for you, given the following:

                                I just plainly cannot remember more than a few shortcuts

                                If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software. A bicycle is easier to use than a car but it’s not going to get you to the other end of town in time for the movie.

                                1. 14

                                  If your colleagues won’t join you I consider your colleagues to be in the wrong, not the software.

                                  Don’t you think peace within a team is more important than any particular software or workflow? Or, to put it another way, the feelings of people are more important than any workflow, so if a large group of people reject a workflow, it’s better to conclude that the workflow is wrong for those people than to say that those people are wrong.

                                  1. 7

                                    My colleagues wouldn’t join me because the workflow is bad, but because there is no tooling suitable for them and the workflow. If tooling for a specific workflow just isn’t comfortable for me, I’m just not going to use it.

                                    1. -10

                                      Then you ought to be coding in basic. Good things often require effort.

                                      Edit: this comment seems to be being misinterpreted, so a clarification: I’m not earnestly suggesting that he should use basic. I’m extending his logic to an incorrect conclusion to demonstrate the flaw in his argument. Most languages are harder than Basic, therefore Basic is more comfortable, therefore why ever learn anything else? Obviously it doesn’t make sense.

                                      1. 18

                                        You are literally making the exact same argument that @ignaloidas’ colleagues are. The only difference is that the tooling you find suitable and the tooling they find suitable is a null set. They want to be in JetBrains’ IDEs, you want to be in email. You built tooling that demands email-based workflow because it’s what you want and then tell them they have to change; they’ve got tooling that demands GitHub (or a workalike) and then tell their colleagues that they have to change.

                                        As an aside, I pay for and generally enjoy using Sourcehut, and I respect your diehard allegiance to email, but you’ve got to quit acting like this in the threads. I get that you love an email-based workflow, and find it superior for your use cases. Having used Git and Mercurial since, what, early 2006 I guess—certainly before GitHub and Bitbucket existed—I disagree (especially when your workflow starts to involve binary assets, so most websites, games, mobile apps, and so on), but I’m also comfy in that workflow, and happy to support an SCM that fully supports that flow. But if you insist that people who do not use your workflow are wrong, and do so in this offensive manner, you’re going to start losing customers.

                                        And as an aside to that aside, you need to do what you want with Sourcehut, but the fighting against this on principles to me, as a former SCM lead, looks a bit forced: looking at this whole thread, and thinking back to a very early comment, all you’d have to do to satisfy him is to make temporary branch names that can be pulled in some mechanism based on the patch series. That’s it. It’s not trivial, but it’s also not that difficult, since you’re already doing 90% of that with the patch view. If you don’t want to do it, that’s fine, but it seems like that’d still mandate patch-accessible workflows, while also meeting the PR crowd a bit.

                                        1. 2

                                          Note about the JetBrains’ IDEs. It’s not like they are incompatible with with email driven workflow, they just have tools that are better suited for pull-request workflow. I gave JetBrains IDEs as an example of what an “average” developer as I know it uses from day to day, as it seems that many bloggers have a distorted view of “average” developer. Average developer actually doesn’t want to fiddle with settings and try 10 different variants before deciding to use one. They want tools that “just work” without massive setup. Average carpenter wants a table saw that simply does the job they want to, they do not fiddle around it to make it the best saw for them.

                                        2. 14

                                          Hi this is not a very nice tone, please try to argue in good faith.

                                          1. 13

                                            Is insulting prospective customers really the best way to grow your business?

                                            1. -1

                                              That was no insult, it was a logical extension of his logic. I didn’t mean it sincerely, I was using it to explain his error.

                                            2. 2

                                              Ok, in simpler terms. I would probably still use an SUV instead of Smart even if Smart can go through some shorter paths, because I feel cramped when driving it. Same with software. Some software is in fact more useful than other, but is harder/inconvenient to use for some than software which doesn’t have those fancy features.

                                              1. -6

                                                This isn’t such a case. This is a case where you (or your colleagues, I’m not sure at this point) are refusing to try unfamiliar things and, being ignorant of the experience, asserting it’s worse.

                                                1. 3

                                                  It is. The thing is, I have tried mutt and aerc, and the problem is that I just plainly am not comfortable using bigger CLI programs, that is, those, whose scope goes out of pipes and command line rguments. About the only programs that of such style that I can use is nano and htop, only because they have a handy shortcut guide in the bottom at all times. Acme is also not the kind of editor I would like to use casually. It is easy to blame the people that don’t use it, without understanding the reasons why they don’t use it.

                                                  1. -1

                                                    You didn’t know anything of acme not even 2 hours ago. You’ve evaluated it in that time?

                                                    Herein lies my point. I have a vision and I must at some point exercise my creative authority over the project to secure that vision. Yes, it’s different from what you’re used to. You can construct reasons to excuse this away, but I fundamentally believe that being unwilling to learn something new is the underlying problem. As evidence, I submit that there’s no way you could have given acme a fair evaluation since my suggestion of it. I don’t consider this sort of behavior acceptable cause for changing my system’s design to accomodate.

                                                    1. 12

                                                      As someone who used Acme for two years, @ignaloidas does not sound like someone for whom Acme would even be worth trying. It’s great, but incredibly dependent on how you want to use your editor. You can’t disable word wrap, or use any shortcut to move the cursor down a column, for Christ’s sake. It’s really not for everybody (perhaps not even most people).

                                    2. 1

                                      So they, in turn, do not want to switch to this new workflow, which, while potentially increases productivity, requires them to switch to tools they do not like.

                                      What happened to using the right tool for the job?

                                      1. 1

                                        The question here is not about “the right tool for the job” but about the usability of those tools for the wider audience. Currently I do not see the majority of the developers switching to email-based workflow purely because of the usability of tools. “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                        1. 1

                                          “Rockstar developers” think that CLI’s are very usable and productive, but that is not the case for the average programmer.

                                          Good to know that we were all rockstars for decades without realizing it!

                                          This is probably just an age thing but I don’t know any professional programmers who aren’t comfortable with CLIs.

                                          1. 3

                                            There is CLI, and there is CLI application. Git is used through CLI. Vim is a CLI application. Surely you know at least one professional programmer that isn’t comfortable with Vim and alike.

                                2. 3

                                  I am not particularly experienced at using git with email. One problem I have had in the past is when I want to pull in a patchset from a mailinglist archive, where either I am not subscribed to the mailinglist, or wasn’t subscribed at the time when the patches were sent. Can these mail clients help me with this problem? (By contrast, I find it very easy to add a branch / PR as a remote and pull or cherry-pick commits that way)

                                  1. 2

                                    lists.sr.ht, the sourcehut web archive for mailing lists, has a little copy+paste command line thing you can use to import any patch (or patchset) into your local git repo. Here’s an example:

                                    https://lists.sr.ht/~sircmpwn/aerc/patches/7471

                                    On the right, expand the “how do I use this” box and a short command is given there.

                                    Integration directly with your mail client would require more development but isn’t necessarily out of the question.

                                    1. 3

                                      That’s good to see, but presumably doesn’t help for non-sourcehut mailinglists?

                                      1. 2

                                        No, I’m afraid that there are fewer good solutions for non-sourcehut mailing lists. Patchworks has a similar feature, if the list in question has that set up. You could also ask someone else for a copy of the mail. I don’t think this damns the idea, it just shows that we need better software to support the idea - which is what sourcehut tries to be.

                              2. 2

                                I am still trying to find some time to check out Sourcehut. My only concern is how to configure it to run CI builds on mailing list patches as I couldn’t find it anywhere in the docs.

                                1. 1

                                  This hasn’t been implemented yet, but it will be soon.

                                  1. 1

                                    Great. If that happens I will think about migrating some of my personal projects to the Sourcehut as it seems pretty as a pretty nice solution.

                              3. 13

                                Federated Gitea (or even better, some sort of open federated git protocol) would be very interesting.

                                1. 3

                                  This really piqued my interest as well. Does anyone know more about the current state of federated gitea and what the future plans are?

                                  1. 3

                                    I’m reminded of git-ssb, which at first glance seems to be what you want.

                                    1. 5

                                      Another similar project is http://www.radicle.xyz (but I agree, P2P not federated).

                                      1. 5

                                        Federation isn’t P2P. They’re similar in some ways, and quite unlike in others.

                                        1. 1

                                          Yeah, git-ssb is a neat project! I checked it out a few years ago and I remember having some kind of issue with it. Maybe cross-device identity or something? I suppose I should revisit it.

                                          1. 1

                                            SSB in general doesn’t support cross-device identity at all, but leaves the problem of identifying two different public keys as the same “identity” to higher level applications. There are several solutions in the roadmap, but nothing definite for now.

                                      2. 11

                                        I don’t think we should allow these people into open source spaces and I don’t want a company that works with them to profit off of my work.

                                        It doesn’t work that way, for very good reason. See the FSF on censorship envy and licensing.

                                        1. 14

                                          I find that unconvincing. FSF finds it difficult to draw a line, but that doesn’t mean the line shouldn’t exist at all. This problem doesn’t exist for an individual, who can decide exactly for themselves who they’re going to support.

                                          1. 3

                                            I tended to do so too, but Stallman’s argument:

                                            A condition against torture would not work, because enforcement of any free software license is done through the state. A state that wants to carry out torture will ignore the license. When victims of US torture try suing the US government, courts dismiss the cases on the grounds that their treatment is a national security secret.

                                            is pretty convincing to me. If your software doesn’t directly interface with users, or if work has been put into hiding it, it one might often not even realize that one is running enclosed software.

                                            Anyways, since the free software movement when it comes to the fundamental question opposed to copyright and intellectual property, they wouldn’t want to have to extend it further than necesary, as argued here:

                                            It is not clear these [conditions] would be enforcible. Free software licenses are based on copyright law, and trying to impose usage conditions that way is stretching what copyright law permits, stretching it in a dangerous way. Would you like books to carry license conditions about how you can use the information in them?

                                            In the end you can choose to oppose those you don’t want to help in all other ways: don’t help them with issues, ban them from mailing lists, etc. but starting to limit who can and cannot use certain software, can only lead down a rabbit hole of less software for everyone to use, and a even worse/abusable legal situation – it should be obvious that this isn’t the goal of free software, but if this is a higher priority, then nobody is forcing software to be free…

                                          2. 6

                                            Those arguments make sense in the context of a license, but they don’t apply here. The FSF itself is one of the best examples of condemning and refusing to do business with companies like Microsoft, even if the GPL doesn’t prevent Microsoft from using their code.

                                            1. 6

                                              I don’t understand what this article about including politics in software licensing has to do with people boycotting businesses they believe engage in acts of evil.

                                              1. 2

                                                I strongly disagree with the FSF on this issue. We don’t have to, and should not, treat all things the same regardless of ideology. Good things are good and bad things are bad, and we should treat them accordingly. I think that a free software movement that doesn’t take a stance on moral issues outside of software licensing is hollow at best. The first amendment doesn’t apply to open source projects so we’re all perfectly free to not allow Palantir to participate, though I agree that licenses aren’t a good way to enforce this as it’s a social rather than legal problem.

                                              2. 5

                                                Host your own? You can use cgit if you want a web interface onto the repositories.

                                                1. 5

                                                  They’re currently hosting their own instance of Gitea.

                                                  1. 2

                                                    Yeah to clarify I mean making a directory for all your git repos and pointing git-daemon at it, don’t think this option was mentioned in the article, and it’s arguably much simpler.

                                                  2. 2

                                                    I have started to use cgit myself, and was blown away by the possibility it opens. They have a filters mechanisms which allows for easily extending the set of features of the software. Besides, even though the use of <table> everywhere does constrain the CSS one can write (at least, it constrains me), it remains fairly easy to come up with a nice custom theme.

                                                  3. 4

                                                    We need a truly distributed DVCS. Something that does not require every user to buy domains, or run a server, or be tied to a specific instance. And with the ability to search for repositories globally.

                                                    git-ssb[1] is a baby step in the right direction (but uses an append-only blockchain and js, urgh).

                                                    [1] https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256

                                                    1. 3

                                                      Well, ssb doesn’t really do much Blockchain™ bullshit, it just does hash chained history like… uh… git :)

                                                    2. 7

                                                      As soon as you have an ssh server running somewhere, you have a fully functional git hosting.

                                                      Having a pretty website to promote / browse your code and a social media to argue about your code with the community is another story though.

                                                      Now what? Mailing lists? Fine! I saw some saying “no thanks”, maybe they will be better off with GitTea or alike. Or maybe just finding someone hosting a ML&co for them.

                                                      After all, that is how software communities build up: common facilities to deal with development.

                                                      1. 3

                                                        There was a post here about 2 months ago about trying to extend the ActivityPub spec to include Git commands: ForgeFed. This could include issues, pull requests, and other things. As with any other federated protocol, I think it tends to gravitate back to centralization, but it sounds the closest to what you want.

                                                        On the P2P side, both git-ssb and radicle have been mentioned already. I can not say anything about radicle, as I have not tried it. git-ssb might be the most mature, since it’s being used already as a way to build SSB itself—most of the main repos of the SSB community live inside git-ssb. As with all things in SSB though, it still has a lot of rough edges and it’s deeply tied to the node ecosystem.

                                                        1. 3

                                                          I’m running git+cgit on a CentOS VPS and it works great: https://www.tuxed.net/fkooman/blog/git_server_centos.html

                                                          1. 3

                                                            In terms of self hosting I found Phabricator to be nicer than gittea, even if I did have to spend a little more for the server to run it. Have all the tools to manage a project right in one place was a huge benefit and the underlying git still worked just as well.

                                                            1. 1

                                                              It’s a different workflow, but it’s great. There’s a lot of tooling available (e.g. Mozilla is IMO overdoing it with the automation that requires some secret metadata that manual diffs do not have) but typically you can use it in a completely ad-hoc way: for FreeBSD, sometimes I do git diff just on the index with some set of directories, sometimes it’s between branches, sometimes git show instead. I just upload it through the web form and it’s great. Reviewers/committers apply it with plain patch and commit to SVN. No branches to keep around and delete, no mail bullshit, just a nice webapp for reviews.

                                                            2. 2

                                                              Just a little heads up about Keybase, where you can host and share (encrypted) git repositories.

                                                              1. 2

                                                                For Gitea, I can recommend setting up OAuth2 for GitHub and GitLab, it’s not that complicated though needs some fiddling in some edge cases, but it’s worth it IMO. GitLab always feels a bit heavy, no matter what I want to deploy it for… there is just too much stuff crammed in (and I’m not against any of the stuff in particular).

                                                                I would advice against Sourcehut, since the author seems to have some personal vendetta against making their software accessible to a wide audience of developers/users.

                                                                1. 1

                                                                  Also for self-hosted there’s https://rhodecode.com CE which has similar source distribution like Gitlab (Free CE vs Paid EE editions)

                                                                  1. 1

                                                                    There’s a free (as in freedom) fork of it too: https://kallithea-scm.org/

                                                                  2. -5

                                                                    This is a meta comment.

                                                                    People complaining about the email-driven workflow and how ‘un-intuitive’ it is have never used it. They complain about the software not supporting it and that you have to integrate into existing tools. Wide audiences aren’t going to switch for a 5-10% improvement. They need atleast 30% improvement to be convinced of convert, which is what the email driven workflow offers. Yes, it’s different, but don’t fall for the https://en.wikipedia.org/wiki/Imprinting_(psychology)#Baby_duck_syndrome . I personally find GitHub’s pull request model horrible. Also, not every software is made for everybody, not everybody is a developer and not every developer is a good developer. The people that will use it and like it will spread the word about its benefits. Changes begin at the edge and move towards the center, that’s how culture works. Stop bitching.

                                                                    1. 10

                                                                      This rude and condescending comment has not made me rethink my position.

                                                                      1. -2

                                                                        If you read the first sentence of the comment you’ll figure out that this comment wasn’t meant directly for your blog post. After reading your post, I see that it applies pretty well to what you said.

                                                                        but personally I find the email workflow extremely intimidating and I think a lot of potential contributers will as well

                                                                        This is your personal feeling on the subject. You have no experience with email driven workflow, so you took an a priori position without seeing how it works. This is because you’ve ingrained in yourself the pull request driven model. This is exactly what my comment states.

                                                                        but I think it’s ultimately a friendlier system

                                                                        You took an a priori position and used it to justify your conclusion. ‘A is worse, and because A is worse, B is better’. Cool man. Whatever, I couldn’t care less, but learn to construct a non-lazi argument. Or maybe you were just trying to fill in the amount words. You don’t have to post watered down content for upboats you know.

                                                                        I don’t see any condescention in my comment, and you’re the one projecting that onto my words. There is 1 word that could be considered ‘rude’, but hey. Feel free to discard it.

                                                                      2. 7

                                                                        People complaining about the email-driven workflow and how ‘un-intuitive’ it is have never used it.

                                                                        This is at best cherry-picking, and at least a hasty generalization.

                                                                        Wide audiences aren’t going to switch for a 5-10% improvement. They need atleast 30% improvement to be convinced of convert, which is what the email driven workflow offers.

                                                                        If email-driven workflow works well for you then great, but inventing faux-statistical figures as an attempt to coerce a discussion of experience into a quantitative argument isn’t helping anyone. You’ll learn much more by exploring the idea that people experience computers in different ways.

                                                                        Stop bitching

                                                                        Back off with the hostile and gendered attacks.

                                                                        1. -4

                                                                          This is at best cherry-picking, and at least a hasty generalization.

                                                                          No, it’s not, look at the comments and you’ll see that nobody has worked with the email driven workflow. Nobody shared their ‘experience’.

                                                                          If email-driven workflow works well for you then great, but inventing faux-statistical figures as an attempt to coerce a discussion of experience into a quantitative argument isn’t helping anyone.

                                                                          You’re missing my point and you’re being obnoxious. People do not adopt a different behaviour because of minimal improvements. Behavioural change is more costly than a 5% improvement. I’m using these numbers because they illustrate better than ‘very small’ or ‘medium’.

                                                                          You’ll learn much more by exploring the idea that people experience computers in different ways.

                                                                          This is a very high gravity sentence.

                                                                          Back off with the hostile and gendered attacks.

                                                                          Woof woof.

                                                                        2. 1

                                                                          I agree – this is how culture changes. I think what we are seeing now (the bitching) is a response to the proliferation of tech options over the last two decades. When there was less viable, useful options, it made more sense to dive deep, to explore, to spend time learning something – even if at the end you decided “neat, but not for me”.

                                                                          Now more and more people feel overwhelmed, too many choices, too many editors, too much everything! So they commit hard to things (reinforcing baby duck syndrome) to simplify. I can see the logic in this – the cost in time to explore various ways of working is non-trivial, and while you might miss out on the 30% boost – you also miss out on spending time on all the 0% boosts that aren’t for you. Many workplaces are not friendly to sharpening your tools – you got PRs to move, which compounds this feeling of “who has time to learn!”.

                                                                          That said, I think more and more – the time spent to learn, the time spent finding/building better tools is what separates tiers of developers. The skill that has to be learned is how to quickly and reasonably determine if a tool/method is for you.

                                                                          1. 3

                                                                            The skill that has to be learned is how to quickly and reasonably determine if a tool/method is for you.

                                                                            And that’s exactly why the parent comment is rude and insulting – this developer did reasonably determine that this method wasn’t for them, and then this other person comes in and says “stop bitching”.

                                                                            Personally, after 21 years in programming, I’ve really grown to like GitLab’s workflow better than I ever have email. And I was around when email was the only workflow for distributed FLOSS. No, the technology has not gotten “better”, it’s only changed. Change is not always better (and is also not always worse). It’s just different.

                                                                            1. 0

                                                                              I agree that the flood of information is too much. I think it’s perhaps our sampling rate that causing the FOMO anxiety. Once I’ve moved away from news / feeds for a while and came back to it, re-examined what was still discussed, I get a better handle on what has value and what hasn’t.