What's the core reason why the NAObservatory currently doesn't provide that data?

Good question!

For wastewater the reason is that the municipal treatment plants which provide samples for us have very little to gain and a lot to lose from publicity, so they generally want things like pre-review before publishing data. This means that getting to where the'd be ok with us making the data (or derived data, like variant tracking) public on an ongoing basis is a bit tricky. I do think we can make progress here, but it also hasn't been a priority.

For nasal swabs the reason is that we are currently doing very little sampling and sequencing: (a) we're redoing our IRB approval after spinning out from MIT and it's going slowly, (b) we don't yet have a protocol that is giving good results, and (c) we aren't yet sampling anywhere near the number of people you'd need to know what diseases are going around.

when in the future would you expect that kind of data to be easily accessible from the NAObservatory website?

The nasal swab sampling data we do have is linked from https://data.securebio.org/sampling-metadata/ as raw reads. The raw wastewater data may or may not be available to researchers depending on how what you want to do interacts with what our partners need: https://naobservatory.org/data

Here's another one: HN

In this case, it looks like a security lockout, where the poster has 2fa enabled with a phone number they migrated away from in 2022.

Fixed! It should have read "We are sequencing"

In general, at any given level of child maturity and parental risk tolerance, devices like this watch let children have more independence.

What has changed over the last few decades is primarily a large decrease in parental risk tolerance. I don't know what's driving this, but it's probably downstream from increasing wealth, lower child mortality, and the demographic transition.

Interesting to read through! Thoughts:

• I really don't like the no-semicolons JS style. I've seen the arguments that it's more elegant, but a combination of "it looks wrong" and "you can get very surprising bugs in cases where the insertion algorithm doesn't quite match our intuitions" is too much.

• What's the advantage of making alreadyClicked a set instead of keeping it as a property of the things it's clicking on?

• In this case I'm not at all worried about memory leaks, since the tab will only exist for a couple seconds.

• The getExpandableComments simplification is nice!

• I haven't tested it, but I think your collectComments has a bug in it where it will include replies as if they are top level comments in addition to including them as replies to the appropriate top level comments.

mostly my suggestions will be minor refactors at best ... post it as a pull request

I'm happy to look at a PR, but I think I'm unlikely to merge one that's minor refactors: I've evaluated the current code through manual testing, and if I were going to make changes to it I'd need another round of manual testing to verify it still worked. Which isn't that much work, but the benefit is also small.

One general suggestion I have is to write some test code that can notify you when something breaks

It's reasonably fast for me to evaluate it manually: pick a post that should have some comments (including nested ones) and verify that it does in fact gather them. Each time it runs it tells me the number of comments it found (via the title bar) and this is usually enough for me to tell if it is working.

I think this is an unusually poor fit for automated tests? I don't need to keep the code functional while people other than the original author work on it, writing tests won't keep dependencies from breaking it, the operation is simple enough for manual evaluation, the stakes are low, and it's quite hard to make a realistic test environment.

Sharing the code in case others are curious, but if you have suggestions on how to do it better I'd be curious to hear them!

Done; thanks!

Say more?

I tried to find an official pronoun policy for LessWrong, LessOnline, EA Global, etc, and couldn't.

The EA Forum has an explicit policy that you need to use the pronouns the people you're talking about prefer. EAG(x) doesn't explicitly include this in the code of conduct but it's short and I expect is interpreted by people who would consider non-accidental misgendering to be a special case of "offensive, disruptive, or discriminatory actions or communication.". I vaguely remember seeing someone get a warning on LW for misgendering, but I'm not finding anything now.