Please fix typo in commit message (trival).

@practicalswift Please note that we don't have the resources to deal with "fix typo introduced yesterday" every couple of days.

Don't get me wrong, fixing typos is useful, but please try to keep the fixes at a reasonable frequency (maybe bunch them up every couple of weeks)

Agree with @MarcoFalke . In principle it is good to fix comment typos, but my preference too would be to either catch them at the source (review the PR and find them) so that they never get merged in the first place or bunch them up into something like a "fix typos" pull every few weeks.

I'm pro the first suggestion.

The second one does not work for different reporters... The solution there is to quickly merge the typo reported/PRed.

I'm pro the first suggestion.

Absolutely.

The second one does not work for different reporters... The solution there is to quickly merge the typo reported/PRed.

That's just not going to work. Quickly merging encourages bombarding even more of these. We just don't have the resources to handle this, and the overhead for a github PR is too large, they are supposed to be for major, self-contained changes.

What we could do is create a tracking PR:

• Assign one person as "typo fixer", and have them open a "report typos here!" PR

• People can report typos, or patches fixing a typo in that PR.

• The typo-fixer pulls these suggested changes (or any typos they find themselves) into their PR.

Then once in [some period of time] this pull is merged.
This allows live cooperation on fixing typos without involving the maintainers at every step.

Sorry, but I do not see how e.g. this PR had "too large overhead" (modulo typo in the commit message 8). It was merged within 3 hours after its opening. This is perfect!

We already tried your suggestion but it didn't work. The management burden of it is too large for one person. And we can't teach newcomers to report/PR the typo fix elsewhere. This is not how it works.

You can argue but do realize that @MarcoFalke and me are the only two maintainers that merge these kind of patches at all. And we agree on this. You can assume that we know what we're talking about. In a critical project like this a certain amount of care has to be taken for merging each PR, we can't blindly merge everything with "typo" in the name. So yes there is an overhead per PR.

If you don't want to change your workflow, then a result may be that these go completely unheeded at some point.

The management burden of it is too large for one person.

Then coordinate it with multiple people? It doesn't have to be one person doing all the work.
You're also contradicting yourself: before you said managing typos has hardly any overhead, why do you here suddenly say it does when you have to do it yourself?

It is surely not about me... In the past, we have tried it in @theuni's tree. Closing PRs here, opening them in his own tree, rebasing, PRing the complete batch etc. This is a lot of work for one person. I was talking about this overhead.

Much easier to do that here because people will do that here anyway (reading source code/forking is so easy in github...). Yes, there is some overhead for your two. I can't help with merging but I try to help with reviewing such PRs because I understand it slows down your work elsewhere.