[aDyslecticCrow]

> No. We could not assume that contributors would engage in such discussion, in the past; nor has this been inverted today.

If the author experience a shift in the nature of PR and discussions, then at the very least it's been inverted in the projects they maintain. Even if there were contributors that did so in the past, if the ratio increased it's an issue worth discussing.

> Code "discusses itself" with you as write it

Perhaps (though i lean towards disagreement), but that discussion is not with the maintainer or rest of the team. "I thought about it and this is the best approach trust me bro" is not a great push request. All those questions the contributor answered and "discussed" are un-resolved for everyone else, and the burden of proof should be on the contributor.

If you have to think it through in front of an IDE to think about it properly, script it out in some quick python and return to the issue thread to discuss the approach. Perhaps post the python prototype even.

[einpoklum]

> ... is not a great push request.

indeed, but that is no different now that it was before.

> If you have to think it through in front of an IDE to think about it properly, script it out in some quick python

Again, that is not possible; or rather, it is meaningless. It's like telling an author to sketch out a few chapters ahead. It doesn't work like that: The story has its own life and nature - even if, to an extent, drawn out from the author's psyche and unconscious - which develops through the process of writing. The sketches are very often just not what the story works itself out to be. In fact, not unlike literature - sometimes, truths reveal themselves only on the first or second rewrite.

[saghm]

> Perhaps (though i lean towards disagreement), but that discussion is not with the maintainer or rest of the team. "I thought about it and this is the best approach trust me bro" is not a great push request. All those questions the contributor answered and "discussed" are un-resolved for everyone else, and the burden of proof should be on the contributor.

I'm not sure what I'm missing, but that sounds very similar to the idea that the parent comment says about reflection happening before, during, and after writing the code. It's not at all uncommon for me to explain some code I pushed for review with something like "Originally, I planned to use approach X, but then I ran into complication Y, so I switched to approach Z to handle that". At least to me, this fits the pattern of reflecting beforehand (selecting an initial approach), during (deciding on how to handle a complication during the process of development), and after (literally the explanation itself to describe how the final state was reached), but it doesn't sound anywhere close to "trust me bro".

I don't read the parent comment as arguing against these sorts of explanations, just against the idea that the explanation could be sufficiently written entirely up front before any of the code was written.