Not necessarily. There are extensions to set up, proxies to set up if you're behind a firewall, etc.
> [Local email] You need to decide a bunch of things on setup
That may apply in a few special cases, but every time I set up Thunderbird or any other MUA, the only things I have to enter are the SMTP and IMAP servers along with my credentials. Thunderbird will even auto-detect those settings (other than one's credentials) for the more common set ups.
Then it's just a matter of waiting for all the messages to download and populate the folders. Because of IMAP preserving the flags that I set on messages from my old client, the new client can already tell if I've read certain messages, marked them as important, etc.
> The deletion model -- what happens when you delete a local message (and how to push local "deletions" to the server) -- is not at all obvious and confusing to configure.
I've never had that problem using the default configuration that Thunderbird comes with for IMAP. When you delete a message, it's marked with the expunge flag, IIRC and will be deleted when you end the IMAP session. Some servers will allow you to recover those messages if you mistakenly delete them. If you're using POP (and not many people use that AFIAK, at least compared to IMAP), then there's an option as to whether to delete messages from the server when you download them.
> Sure. And projects should strive to make these steps easier too. I have helped folks (not just new programmers, mind you) get involved in open source, and the rest of these steps are fine for them, but needed lots of help with the mail client setup for contributing to the mailing list.
I think there's just a fundamental difference in opinion here. Many people, including myself, learned a lot of what they know by experimenting, reading documentation/articles, asking around, etc. They didn't need to have somoene guide them step-by-step in order to complete a task. They would read guides and then expand their knowledge based on what they read.
> Yes, but if ports are blocked, you're hosed.
In the case of email, that would just include port 25 which is unsecured SMTP. No one should be transmitting their credentials in plain text over an unsecured connection. Ports for secure transports (SMTP, IMAP, etc.) aren't typically blocked by residential ISPs. They may be blocked in a company's corporate network, but that doesn't mean they can't compose their messages at work and then send them off once they get home and can use their home network connection.
> It really shouldn't be hard for a hybrid approach here.
I agree. One can use git format-patch and git send-email to actually send patches to the email list (and CC any maintainers who wrote the code they're modifying). They can participate in a review discussion via their preferred way of accessing their email. If they need to post a follow up patch series, they will need to access the message-id of the original message (unless the idea of generating and retrieving the message-id I mentioned above is implemented) and use git format-patch and git send-email to send the follow up series.
> Then again, I find email-based reviews to be very lacking compared to what can be done directly on github or the review tools folks integrate with it.
I've found Github, in particular, to be rather lacking in terms of code review. For example, it has collapsed comments made on lines of code that happened to change, but not in a way related to the comments made on them. It doesn't have a way to thread comments (meaning that you cannot automatically associate a reply with its parent comment that happens to be several comments away from the most recent one made on a PR. There's no way to know whether your review has been addressed without having to scroll all over the PR page to find your comment (which may disappear if someone does a git force push to push up an amended commit or rebased branch).
With email, it's pretty easy to see whether a thread has new messages, whether someone has replied to a message, or that there are messages you haven't replied to. Also, given the thread overview pane that a MUA has, it's far easier to have a more extensive discussion without requiring an excessive amount of scolling/paging. In a github PR, it starts to get rather unwieldy and require a lot of scrolling once you get beyond 10 to 15 comments.
Some review tools like gerrit, phabricator, reviewboard, and others do address these issues to some degree, but they themselves take more time to learn, install and configure compared to an email client and configuring the git email related utilities.
> Not necessarily. There are extensions to set up, proxies to set up if you're behind a firewall, etc.
Default, basic workflow is the same though. For email, this doesn't map well, since everyone has a different workflow; there's not really a "default". And most if not all web-based contribution workflows don't force you to switch browsers (sometimes you may have a couple improvement features on other browsers, but that's not prohibitive), so this discussion is moot anyway.
Proxies are much easier to set up for browsers as I mentioned earlier.
> When you delete a message, it's marked with the expunge flag, IIRC and will be deleted when you end the IMAP session.
Right, but I also don't want to store all my emails locally, just the recent ones, and it's unclear how to do that without getting them deleted. Thunderbird in particular gets very confusing about this (the OSX Mail app is clearer). The first time I set up Thunderbird it synced everything. I didn't want that (I realized that it was going to download my gigabytes of email after it started syncing); but was too afraid to delete the older messages. I eventually went with deleting the profile dir and starting over. This is not just me, multiple people I know have been through similar confusions when setting up.
And, again, none of this is obvious.
"I've never had that problem" misses the point; the point is not that it works a certain way, it's that it's confusing and nonobvious and very easily can turn people off contributing that way.
> I think there's just a fundamental difference in opinion here. Many people, including myself, learned a lot of what they know by experimenting, reading documentation/articles, asking around, etc. They didn't need to have somoene guide them step-by-step in order to complete a task. They would read guides and then expand their knowledge based on what they read.
This is how I learn as well. I too am self-taught. But there are many people who do not have the time to learn things by blundering along. Reducing friction wherever possible is something I care about deeply. Not everyone does, but I do try to convince others to strive for the same.
> Ports for secure transports (SMTP, IMAP, etc.) aren't typically blocked by residential ISPs.
Yes, but people live in universities, or other large shared NAT networks, which often blanket port block. I'm not saying that these policies are reasonable, I'm just pointing out the reality of the situation.
And SMTP is what you need to use git send-email, which is what the original discussion was about.
> Default, basic workflow is the same though. For email, this doesn't map well, since everyone has a different workflow; there's not really a "default".
While that is true, I don't see it as an issue. Project documentation can suggest a workflow, but people who regularly contribute can optimize/change it for their convenience. What really matters is what works for the project maintainers and core contributors.
For example, at my current job, we have an established workflow for implementing changes in our code base, reviewing those changes and deploying them to our production systems. If I were to switch jobs, I would have to adapt to the workflow at my new job. I wouldn't try to shoehorn in the workflow used at my current job into my new job. But I would try to suggest improvements to the workflow based on my experience and see if I can get others to adopt them. But if they don't change, then I either have to deal wit it, or find another job. Similarly, if a potential contributor isn't willing to deal with the established workflow of a given project, they're free to contribute to a project that has a workflow more to their liking.
> Right, but I also don't want to store all my emails locally, just the recent ones, and it's unclear how to do that without getting them deleted.
I don't really see it as a problem. I have an email account that was provisioned roughly 8 years ago and the total folder size is around 1.2 GB (which is pretty insignificant in terms of disk space these days). I don't typically delete emails and can easily find messages sent to me from that long ago if I so wish using the search features of my MUA.
But getting to your other point about not wanting to sync the entire set of emails, it's not something that I have to deal with more often than I end up setting up a new computer (which has been twice in the last 5 years or so).
> it's confusing and nonobvious and very easily can turn people off contributing that way.
There are certain expectations that each project has in terms of contributing and I have seen a lot of complaints over the years where people post code, but never follow up with the maintainer. Perhaps having an email based process forces those who are willing to be more involved in the process, and discourages those who just want to drop code off and be done with it (without ever following up).
> But there are many people who do not have the time to learn things by blundering along.
I wouldn't call it "blundering". It's a learning experience. If someone isn't willing to to put the time into independently learning (with assistance as needed) something, then perhaps it's not really worth their time (or yours). I'm much more willing to work with people who, after showing them the basics, come back to me and actually show me something that I didn't know about as opposed to the person who appears to be burdened by the fact that I'm teaching them the basics and has no time to go further in their learning process. The same applies to project maintainers.
> Yes, but people live in universities, or other large shared NAT networks, which often blanket port block.
The only time I've encountered this problem is at my current job where they block access to external email services when connected to the corporate network. I don't bother logging into my personal email accounts at work though. People, if they're motivated enough can get around those restrictions. Perhaps, if there's a blanket port block, they could submit things by connecting to their email server via their cell phone/mobile connection.
> Project documentation can suggest a workflow, but people who regularly contribute can optimize/change it for their convenience. What really matters is what works for the project maintainers and core contributors.
Workflow for interacting with a project is different from workflow for interacting with email, a central tool to the rest of our lives. Git workflow is malleable. If I have to change my email workflow to contribute to your project, I probably just won't contribute, or contribute less. I'm a committer to gdb, but this is one of the reasons I dread putting up patches and often procrastinate. I have an unsynced MUA locally which I do use, but I still don't like it.
Like I said, you can make it so that you only use the mail client for patch contributions, but that feels heavyweight. I've tried that (indeed, it's what I currently do), and it's really annoying.
> I don't really see it as a problem. I have an email account that was provisioned roughly 8 years ago and the total folder size is around 1.2 GB
That's just you, though. Mine is 7GB. On my current laptop that doesn't matter. I used to be on an older laptop that didn't have much space, was partitioned and dual booted, and regularly ran out of space. 7GB was a lot.
> it's not something that I have to deal with more often than I end up setting up a new computer
But we are talking about setup. We are talking about the setup time for contributing to a project for people who don't already use MUAs.
> Perhaps having an email based process forces those who are willing to be more involved in the process, and discourages those who just want to drop code off and be done with it (without ever following up).
I think this attitude does more harm than good. I've been involved with projects with more explicit mentoring, and this has always been a net positive -- for every contributor who drive-by drops a patch, we have many more new contributors who start off clueless but end up being valuable members of the community.
> I wouldn't call it "blundering". It's a learning experience. If someone isn't willing to to put the time into independently learning (with assistance as needed) something
Not everyone can afford to sink unlimited time into things. Making it easier to use things helps these people get involved.
Besides, folks don't always approach open source project with the singular goal of contributing to that particular project. Sometimes they just want to do some open source stuff in the field of their choice to learn. If your project is annoying to get involved in, they will choose a different one -- they're still motivated, just not for your project in particular. Your project doesn't exist in a vacuum.
This is a fundamental disagreement of opinion we seem to have here -- you don't particularly care about such contributors, I do, and I think that such projects (which try hard to keep it easy to contribute) I've been involved in have benefitted tremendously from this. To each to their own, I guess.
Not necessarily. There are extensions to set up, proxies to set up if you're behind a firewall, etc.
> [Local email] You need to decide a bunch of things on setup
That may apply in a few special cases, but every time I set up Thunderbird or any other MUA, the only things I have to enter are the SMTP and IMAP servers along with my credentials. Thunderbird will even auto-detect those settings (other than one's credentials) for the more common set ups.
Then it's just a matter of waiting for all the messages to download and populate the folders. Because of IMAP preserving the flags that I set on messages from my old client, the new client can already tell if I've read certain messages, marked them as important, etc.
> The deletion model -- what happens when you delete a local message (and how to push local "deletions" to the server) -- is not at all obvious and confusing to configure.
I've never had that problem using the default configuration that Thunderbird comes with for IMAP. When you delete a message, it's marked with the expunge flag, IIRC and will be deleted when you end the IMAP session. Some servers will allow you to recover those messages if you mistakenly delete them. If you're using POP (and not many people use that AFIAK, at least compared to IMAP), then there's an option as to whether to delete messages from the server when you download them.
> Sure. And projects should strive to make these steps easier too. I have helped folks (not just new programmers, mind you) get involved in open source, and the rest of these steps are fine for them, but needed lots of help with the mail client setup for contributing to the mailing list.
I think there's just a fundamental difference in opinion here. Many people, including myself, learned a lot of what they know by experimenting, reading documentation/articles, asking around, etc. They didn't need to have somoene guide them step-by-step in order to complete a task. They would read guides and then expand their knowledge based on what they read.
> Yes, but if ports are blocked, you're hosed.
In the case of email, that would just include port 25 which is unsecured SMTP. No one should be transmitting their credentials in plain text over an unsecured connection. Ports for secure transports (SMTP, IMAP, etc.) aren't typically blocked by residential ISPs. They may be blocked in a company's corporate network, but that doesn't mean they can't compose their messages at work and then send them off once they get home and can use their home network connection.
> It really shouldn't be hard for a hybrid approach here.
I agree. One can use git format-patch and git send-email to actually send patches to the email list (and CC any maintainers who wrote the code they're modifying). They can participate in a review discussion via their preferred way of accessing their email. If they need to post a follow up patch series, they will need to access the message-id of the original message (unless the idea of generating and retrieving the message-id I mentioned above is implemented) and use git format-patch and git send-email to send the follow up series.
> Then again, I find email-based reviews to be very lacking compared to what can be done directly on github or the review tools folks integrate with it.
I've found Github, in particular, to be rather lacking in terms of code review. For example, it has collapsed comments made on lines of code that happened to change, but not in a way related to the comments made on them. It doesn't have a way to thread comments (meaning that you cannot automatically associate a reply with its parent comment that happens to be several comments away from the most recent one made on a PR. There's no way to know whether your review has been addressed without having to scroll all over the PR page to find your comment (which may disappear if someone does a git force push to push up an amended commit or rebased branch).
With email, it's pretty easy to see whether a thread has new messages, whether someone has replied to a message, or that there are messages you haven't replied to. Also, given the thread overview pane that a MUA has, it's far easier to have a more extensive discussion without requiring an excessive amount of scolling/paging. In a github PR, it starts to get rather unwieldy and require a lot of scrolling once you get beyond 10 to 15 comments.
Some review tools like gerrit, phabricator, reviewboard, and others do address these issues to some degree, but they themselves take more time to learn, install and configure compared to an email client and configuring the git email related utilities.