On Sun, Feb 09 2020, Allison Collins wrote: > Well, I can see the response is meant to be encouraging, and you are > right that everyone needs to give to receive :-) > > I have thought a lot about this, and I do have some opinions about it > how the process is described to work vs how it ends up working though. > There has quite been a few times I get conflicting reviews from multiple > reviewers. I suspect either because reviewers are not seeing each others > reviews, or because it is difficult for people to recall or even find > discussions on prior revisions. And so at times, I find myself puzzling > a bit trying to extrapolate what the community as a whole really wants. The "community as a whole" is not a person and does not have a coherent opinion. You will never please everyone and as you've suggested below, it can be hard to tell how strongly people really hold the opinions they reveal. You need to give up trying to please "the community", but instead develop your own sense of taste that aligns with the concrete practice of the community, and then please yourself. Then when someone criticizes your code, you need to decide for yourself whether it is a useful criticism or not. This might involve hunting through the existing body of code to see what patterns are most common. The end result is that either you defend your code, or you change your opinion (both can be quite appropriate). If you change your opinion, then you probably change your code too. Your goal isn't to ensure everyone is happy, only to ensure that no-one is justifiably angry. NeilBrown > > For example: a reviewer may propose a minor change, perhaps a style > change, and as long as it's not terrible I assume this is just how > people are used to seeing things implemented. So I amend it, and in the > next revision someone expresses that they dislike it and makes a > different proposition. Generally I'll mention that this change was > requested, but if anyone feels particularly strongly about it, to please > chime in. Most of the time I don't hear anything, I suspect because > either the first reviewer isn't around, or they don't have time to > revisit it? Maybe they weren't strongly opinionated about it to begin > with? It could have been they were feeling pressure to generate > reviews, or maybe an employer is measuring their engagement? In any > case, if it goes around a third time, I'll usually start including links > to prior reviews to try and get people on the same page, but most of the > time I've found the result is that it just falls silent. > > At this point though it feels unclear to me if everyone is happy? Did > we have a constructive review? Maybe it's not a very big deal and I > should just move on. And in many scenarios like the one above, the > exact outcome appears to be of little concern to people in the greater > scheme of things. But this pattern does not always scale well in all > cases. Complex issues that persist over time generally do so because no > one yet has a clear idea of what a correct solution even looks like, or > perhaps cannot agree on one. In my experience, getting people to come > together on a common goal requires a sort of exploratory coding effort. > Like a prototype that people can look at, learn from, share ideas, and > then adapt the model from there. But for that to work, they need to > have been engaged with the history of it. They need the common > experience of seeing what has worked and what hasn't. It helps people > to let go of theories that have not performed well in practice, and > shift to alternate approaches that have. In a way, reviewers that have > been historically more involved with a particular effort start to become > a little integral to it as its reviewers. Which I *think* is what > Darrick may be eluding to in his initial proposition. People request > for certain reviewers, or perhaps the reviewers can volunteer to be sort > of assigned to it in an effort to provide more constructive reviews. In > this way, reviewers allocate their efforts where they are most > effective, and in doing so better distribute the work load as well. Did > I get that about right? Thoughts? > > Allison
Attachment:
signature.asc
Description: PGP signature
