How are "Notable code and documentation changes" selected?

[Kixunil]

I don't see a better place to ask, hope this isn't too bothersome. I was surprised by recent inclusion of a Rust Bitcoin PR in the newsletter. It feels a bit random. How do you select which changes go into newsletter?

[harding]

@Kixunil no problem about asking here (you can also just reply to the from address on the newsletters).

I have a script that shows me the git log --topo-order -p for all commits added to each project we monitor since the last time I ran the script. I read the commit messages and skim the code for every commit. If it looks interesting, I paste details into my draft for the next week's newsletter. After that, I check the tags various projects have added to alert us to stuff they think are interesting, e.g. CLN, Eclair, and LDK. Then those PRs are summarized, either by me or by another Optech contributor (we have a rotating roster as part of cross-training for weeks when I'm not available).

I don't have a written list of criteria I use to select commits, but it's something like:

• Is it a major change that's cause for celebration (or despair)?
• Will it affect other users on the network, especially in a way that might be surprising? (E.g. P2P or LN networking changes)
• Does it represent significant progress towards a major goal (especially something we have a topic page for)
• Is it a significant user-visible change (e.g. a new RPC for applications, or a new method for libraries, that I think many users/devs will want to use)
• Does it potentially represent a template or best practice other software might want to adopt (e.g. we heavily highlighted the first software to add support for bech32m)
• Is there some other reason people will be interested or surprised to learn about this change
• On anti-criteria, we tend to ignore test changes, refactorings, minor bug fixes, and other stuff that can often be really important in the long term but which is not interesting in the short term

Re: Rust Bitcoin 1636, which is what I guess you're writing about, it fell into the "I think downstream users of RB will want to use this" and "maybe there's a template for a best practice here that non-Rust devs may want to use in their Bitcoin software".

I'd be curious myself to hear what surprised you about our selection of it. Did you think it should've been below our selection threshold, or are you surprised we wrote that up but recently missed some other more significant changes?

Thanks for reading, and thanks for your work on RB and other Bitcoin projects!

[Kixunil]

Thanks for explaining! I've created such label, will use it in the future if something comes up.

Yeah, 1636. It didn't feel like "rocket science", just a bunch of integer additions mostly. But looking from consumer perspective it is true it's more valuable than it seems because getting the computation right was not super-easy when I did it before in my own project (that's why I upstreamed it) - I got a bunch of bugs forgetting to add some items etc.

I think script refactoring was quite a massive change that falls under "Is it a significant user-visible change". But really, the next version will be one hell of a release (should come out around the end of February). :) The aggregate changes are insane. In one of my projects the upgrade diff adds 162 LOC and removes 265.