The author is obviously entitled to whatever workflow he chooses to use, and he isn't proselytizing here, but by choosing to sidestep industry standards he is ultimately just putting obstacles in front of other coders who might like to contribute.
Unless you're really into git and email, it's just tiresome and a time sink having to work all this out.
Fwiw I've used putty in the past and appreciate his efforts, if not his obscurantist tendencies.
> ultimately just putting obstacles in front of other coders who might like to contribute
Saying it is just that after reading the full text seems rather reductive and unfair.
That is certainly a likely side effect, of course. It may even be a desirable one, avoiding, or at least reducing, several classes of time wasting contributions (like the glut of single typo fixing pull requests that resulted from an ill-conceived contribution based competition a while back), especially for "open source but not open contribution" projects.
Some projects are not wanting to optimise for the number of contributors above other considerations.
The regular forges have just as many obstacles. You have to register an account, figure out whether the button you need is 'Pull Request' or 'Merge Request', and what the exact flow is.
The only reason things appeared simple in the past is because of GitHub's monopoly. As soon as you want to get rid of that, life gets more complicated. That is just another tradeoff you have to make.
Unless you're really into git and email, it's just tiresome and a time sink having to work all this out.
Fwiw I've used putty in the past and appreciate his efforts, if not his obscurantist tendencies.