Back in August
(https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-August/002342.html),
I posted something about how we should engage on this list, because we
fell into one of the classic traps:
So, what happened is what always happens on mailing lists -- I put out
a multi-page writeup reflecting hundreds of hours of research and
incorporating years of discussion, and 99% of the discussion was a
too-loud, back-and-forth thread on a relatively uninteresting corner
case on the subject of whatever happened to be the first
strongly-stated opinion.
And that this common phenomena has a bad side-effect -- it crowds out
valuable discussion:
The result is that we didn't have a substantive discussion on the
other 99% of the proposal, and some folks may even have been
intimidated by the back-and-forth (see, for example, Tagir's comment:
https://twitter.com/tagir_valeev/status/1293931093066997761) and held
back on their feedback. I would be very unhappy if we missed out on
Tagir's feedback because we had made the environment inhospitable
because of a long back-and-forth on a less important topic.
So I proposed some guidelines:
Let me reiterate some guidelines for discussion, that hopefully will
keep us from finding ourselves in this corner too frequently. I've
said all this before, but its good to repeat once in a while.
- Be aware that syntax discussions always suck up the oxygen. Once
the syntax discussion starts, it is unlikely any substantive
discussion on the more important issues will take root. (With the
right model, the right syntax can be found later; the wrong model
can't be saved even with the best of syntax.) So please, save these
until you're confident that you -- and everyone else -- have said what
have to say about goals, models, success metrics, and the like first.
- Be mindful the shape of the reply chain. The best discussions
usually have wide but shallow trees, where many people comment, but no
reply-chain goes too long. The worst are usually long and narrow.
- Lead with uncertainty. Things usually start on the wrong foot if
we lead with "X is wrong" or "You should do it Y way instead." Better
to ask rather than tell; there's a good chance that the proposal
author has already spent a lot of time thinking about the problem and
may already have considered X or Y, or there may be bigger-picture
issues that have motivated the proposed direction.
- The trivial crowds out the substantial. We all have a tendency to
"I'll just reply quickly with the trivial stuff", because that's easy
and we're busy. But very often these things tend to dominate the
discussion. Probably best to try to cover everything in your first
draft (or ask questions if you're stuck) rather than send the trivial
comments first.
Unfortunately, this current thread is bordering on ticking all these boxes.
We're now deep in a sub-thread on translation (which I even asked we not
talk about now), which isn't really even about translation, but really
seems to be about lobbying for a preferred form of expression in the
user model:
pattern method decompose itself nicely to tuples + two new keywords match and
no-match.
So please (everyone, not just Remi): can we just start again here? This
document reflects a deep statement about the role of pattern matching in
the language. There will be ample time to discuss how it is surfaced,
but until we have a shared understanding of the model and where we're
going, I don't think it makes sense to talk about how it is expressed or
implemented. (Trust me, I've thought about these things too.) There's
a method to my madness here; this is a big topic, and I want to nail
down where we're going before we talk about how we get there. Shared
understanding first.
If you think this direction is all wrong and this direction is complete
garbage, it's OK to say that (constructively), but otherwise, please,
we're off the trail, and I would like to get back on -- and get ALL of
us on together.
