On Wed, Feb 12, 2020 at 11:21:06AM +1100, NeilBrown wrote: > 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, Yes, I've been caught in email storms with hch before, where we're both firing off emails at the same time and not quite seeing each other's replies to the same thread. > > or because it is difficult for people to recall or even find > > discussions on prior revisions. Oh gosh yes, lore has been a useful tool for that, but we only got lore working for linux-xfs (and previous lists) recently. > > And so at times, I find myself puzzling > > a bit trying to extrapolate what the community as a whole really wants. The bigger problem here is that there are multiple reviewers, each building slightly different conceptions about a problem and how to solve that problem, and that's how an author ends up ping-ponging between reviewers. Sometimes you can appeal to the maintainer to decide if integrating the proposed patches are better than not having them, but sometimes the maintainer is trapped in the M***can standoff. > 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. The "community as a whole" is not a person and does not have a totally uniform concrete practice, just like we don't collectively have identical opinions. Given a problem description, different people will choose and reject different high level structures based on their own experience and biases to solve the problem. That is how we end up in the pickle. > 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. Our design pattern language changes over time. For example, we used to sprinkle indirect function calls everywhere, then I***l screwed us all over and now those are going away. > 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. Counterpoint: "DAX". (Allison: I will continue working my way through the rest of your reply tomorrow morning.) --D > 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
