When I initially saw this posted here, I was irritated. The tone grates with me, and yes - I would prefer a much drier, concise explanation if I were to receive

When I initially saw this posted here, I was irritated. The tone grates with me, and yes - I would prefer a much drier, concise explanation if I were to receive such a pull request for my projects. I kept this to myself though, and had a look at the comments here, and I've had time to mull on why I think this is potentially dangerous behaviour. The tone and humour in that post requires a large amount of confidence in the changes being made, in order to write about the humorously, but also in the author themselves to actually present their work in such a tone. vmg is perfectly entitled to do both of these; the pull request is detailed, shows clear motivation and research, and vmg seems to know his stuff. The problem is that GitHub encourages networking. The damage comes when other people who are less experienced, or frankly, less knowledgeable, copy his style and do produce noise. I worry about a risk of imitation of this culture, but missing the crucial underlying detail and explanation that's hidden in vmg's writing. I worry reasoning with this people will be difficult because they have trained themselves to have such arrogance in their work. I prefer a dry report not only because it is succinct, not only because it makes my life easier to understand, but also because it encourages a disciplined state of mind. If you aren't able to write about something in a mature dry tone and back it up (that is, not cover up with humour), then you should doubt your work until you can amply support it. Yes, life is short, but it's also so short that I would like to get things done; rather than have to potentially argue past people to get important points across. Lets put this creativity into making great stuff, not making great pull request comments, eh? Finally, all of this stuff builds a record for the project. A succinct, yet detailed, pull request is much more accessible a year down the line to understand the changes in more detail. Of course, this detail should be in the commit messages (and I do criticise vmg on poor commit messages here), but every bit of writing contributes towards project documentation, at some level. The more we can create a habit to create mature, if somewhat monotonous, technical writing, I do think the better. So no, it's not just a "I HATE HIS FUN" argument; there are more reaching concerns, no matter how exaggerated you might think they are.