[trivial] Fix typo in rpc/protocol.h #9962

1. 
   practicalswift commented at 9:19 am on March 9, 2017: contributor

   The typo was introduced in commit 338bf065a454fee76d9dfa9c7a36161cac72309f, which was merged yesterday.

   Changes summarized to facilitate reviewing:

   • exampled → example
2. [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06

   The typo was introduced in commit 338bf065a454fee76d9dfa9c7a36161cac72309f, which was merged yesterday.
   
   Changes summarized to facilitate reviewing:
   * exampled → example

   9ea249014a
3. 
   paveljanik commented at 10:04 am on March 9, 2017: contributor

   Please fix typo in commit message (trival).
4. MarcoFalke renamed this:
   [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06
   [trivial] Fix typo in rpc/protocol.h
   on Mar 9, 2017
5. MarcoFalke merged this on Mar 9, 2017
6. MarcoFalke closed this on Mar 9, 2017

   ---

7. MarcoFalke referenced this in commit 5703dff093 on Mar 9, 2017
8. 
   MarcoFalke commented at 11:35 am on March 9, 2017: member

   @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)

9. 
   laanwj commented at 11:58 am on March 9, 2017: member

   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.
10. 
    paveljanik commented at 12:00 pm on March 9, 2017: contributor

    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.

11. 
    laanwj commented at 12:08 pm on March 9, 2017: member

    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.

12. 
    paveljanik commented at 1:56 pm on March 9, 2017: contributor

    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.

13. 
    laanwj commented at 3:51 pm on March 9, 2017: member

    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?

14. 
    paveljanik commented at 6:03 pm on March 9, 2017: contributor

    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.

15. PastaPastaPasta referenced this in commit 914b5f5e21 on Jan 2, 2019
16. PastaPastaPasta referenced this in commit 80762b1b2c on Jan 2, 2019
17. PastaPastaPasta referenced this in commit d60e8b176f on Jan 2, 2019
18. PastaPastaPasta referenced this in commit 9902a4926f on Jan 3, 2019
19. PastaPastaPasta referenced this in commit 59b622d8b9 on Jan 21, 2019
20. PastaPastaPasta referenced this in commit 520f9f3e53 on Jan 27, 2019
21. PastaPastaPasta referenced this in commit fabb0fe3c8 on Jan 29, 2019
22. PastaPastaPasta referenced this in commit c75d7dc832 on Feb 26, 2019
23. UdjinM6 referenced this in commit b2883c431d on Mar 9, 2019
24. PastaPastaPasta referenced this in commit c2df90e923 on Mar 10, 2019
25. practicalswift deleted the branch on Apr 10, 2021
26. DrahtBot locked this on Aug 16, 2022

Contributors
practicalswift paveljanik MarcoFalke laanwj