The pull request I have seen were changing "how to install" into "how to easily install" and such. They were not fixing typos or even making sentences better. They were just meaningless changes.
Not sure why the downvotes... the takeaway is it’s extremely easy for maintainers to tell a well intentioned docs change from the crap referenced in this article
Yes. It is easy to tell them apart. But some people are getting over 50 of these in a day, so even if it is easy to tell, it gets annoying and requires you to deal with spam.
That is the thing with spam in general - you can tell it from legitimate mail easily, but is it still annoying and requires you to deal with it.
That is why I still prefer old-style patch submissions via mailing lists - the bar is higher, so it usually weeds out exactly this kind of trash.
Of course, if a company started offering free t-shirts for mailing list submissions and some foolish (but well-meaning) youtuber would publish a tutorial on how to subscribe and post to a mailing list, I have no doubts that there would be a deluge regardless of this higher bar. :)
As a drive-by contributor to plenty of projects it raises the bar uncomfortably high though. A PR I can rebase and rework based on feedback that can be given right there on the line of code it pertains to. Easy as pie with GitLab or GitHub. Really bothersome with mailing-lists, and excruciatingly painful if they don't even use a modern DVCS like git.
(EDIT: I didn't mean to say that mailing lists are much better in every respect than GitHub/GitLab/etc, just that they don't deserve the hate they seem to get in every discussion about tools for collaborative development.)
As someone who has been contributing to Linux for a few years now, which uses mailing lists exclusively for all development (and not only do they use Git, they wrote it) I've found that mail-based workflows are in some ways better to GitHub/GitLab/etc:
1. You can review individual patches, you cannot do this in GitHub at all (commenting at the bottom of a commit doesn't count because it's not tied to the PR and the comment is lost to ether on force-push). GitHub also defaults to you reviewing the full diff and make reviewing individual commits kind of frustrating (you're just dropped into the commit history view rather than a proper review view).
2. All code reviews end up being line-based because the patch is the main body of the email. Design discussion happens as replies to the cover letter of the patch set, meaning you can easily tell which kind of discussion is happening. You can also directly comment on the git commit message, which the kernel community values a lot more than most projects.
3. You can far more easily be notified on patches sent to sections of the tree (though this is slightly tied to Linux's development workflow with subsystem maintainers). GitHub only lets you watch a repository and get the firehouse of events -- which is about as useful as subscribing to the main LKML and trying to keep up with the notifications.
As for difficulty, honestly the bar to entry to send a patch to a mailing list if you're using Git is just:
$ git send-email --to ... --cc ... origin/master
I would suggest doing "git format-patch" with --cover-letter and then checking the patch contents first, but you can do it one command for simple patches. Git was designed to make this mailing list approach work, so it shouldn't be surprising that it's actually pretty simple to use.
A code mirror and mailing list is a perfectly fine DVCS for the purposes of contributing code to an open-source project, and it doesn't lock a whole ecosystem into a monoculture walled garden.
> feedback that can be given right there on the line of code it pertains to
Done easily with a mailing list, and you can be sure that the comment won't just magically disappear because GitHub decided it was fixed even when it wasn't.
> excruciatingly painful if they don't even use a modern DVCS like git.
As far as local development is concerned, there's no reason you can't use all the git tools to manage your changes.
I don't want the walled garden — I don't care if its GitLab or GitHub or some other tool — as long as I can do stuff like rebase and squash easily and discuss the patch without having to subscribe to a mailing-list, set up inbox filters, prepare the patch for emailing, participate until the patch is in, then not forget to unsubscribe.
Comments about a patch are fleeting and should be gone after the patch lands — and should be treated as such. Any relevant comments will be in the source code.
GitLab (and several others) can be self-hosted for free; and the walled garden (GitHub?) is tolerable enough. And as long as you keep your software development practices sensible (centred around git, not GitHub), there hardly is a wall really.
> As far as local development is concerned, there's no reason you can't use all the git tools to manage your changes.
Certainly possible, but I didn't manage to get git-svn working the last time I wanted to contribute to a SVN repo. In the end I just created a local git repo in-place and generated the patch with git format-patch.
