3 ms·
Something that Steve touched on but didn't dive into is that there's a difference between measuring facts, like the number of changes in a period of time, and m
by infogulch 7y ago
Something that Steve touched on but didn't dive into is that there's a difference between measuring facts, like the number of changes in a period of time, and measuring the cognitive impact of those changes. I'm sorry in advance for how rambly this post is.
`const fn` is a nice example, because it's a large number, but the cognitive impact could be neatly summarized for the general rust userbase by "neat, but I don't really care". The cognitive impact is directly proportional to how easily we can abstract the changes into a coherent story. Does it matter that there were exactly 138 "this fn is now const" changes in 1.33? No, because you already forgot that there were actually only 125. What's the actual difference between 13 extra `const fn` changes and a list of 13 other completely independent changes? 13 arbitrary library changes sound like a lot when they're not neatly bounded by a pre-existing frame of reference. In this case, "this fn is now const" * X where X is 'a big number' doesn't change in cognitive impact when X is replaced with X * 1.1.
I think that Kubernetes release notes are another interesting example. There's typically a huge number of changes due to the distributed nature of the project's development. The vast vast majority of the changes would have little to no effect on your k8s deployment, but there may be some nugget in there that does have a big impact on you. The problem is that that nugget is different for everyone.
So it seems like the key to communicating change may be to present the change in conjunction with a carefully selected frame of reference that enables the audience to easily conceptualize the bounds of the effects of the change in relation to their own experience, before being inundated with the details of the change that would only be useful to people occupying a different frame of reference. The problem is that everyone's experience is different and the impact a change will have will greatly depend on who's reading.
Maybe release posts need old school newspaper-like front pages where changes are scoped and summarized, and details are hidden unless the user wants more. Or maybe there should be multiple posts from the perspective of different user personas. But these ideas aren't cheap to implement, and the problem seems to approach something like "the fundamental difficulty of communication" which is way beyond my scope of understanding.
- Rusky 7y ago> The cognitive impact is directly proportional to how easily we can abstract the changes into a coherent story. Exactly! This is how language and API changes are usually designed, and announcing them the same way is a great idea.