> 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

> 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.