[alfra]

An archive isn't a good tool to onboard people.

The knowledge you get at school or college is a kind "onboarding" new members. But it doesn't make you read every single piece that was ever written. You get a summary of both events and outcome, and most importantly the current state.

That's also how Wikipedia works: Articles don't get longer and longer, you can also summarize and put stuff into perspective. That's why there is a way to delete stuff (with version control, of course).

Moreover, onboarding new people (or maintaining the collective memory) isn't the only form of communication that happens in a team. Maybe it's not even the most important.

What about coordination? On the smaller stuff, on the daily stuff, but also on the bigger picture?

[ChuckMcM]

I don't disagree with your assessment but note that in 'school' the subject is taught from a text book which is a distilled version of the knowledge. Those text books get periodically rewritten. In an engineering organization it would be difficult to justify the expense (although it might be worth it!) to hire a writer to distill all of the learning that happened and the history of that learning into a text that could be handed to new members to bring them up to speed. As a result it is simpler and more cost effective to have a mailing list archive that can be reviewed.

Now it you want to create a product/company out of that practice, then you would build a system that would let people reviewing messages be able to 'vote them up' based on their importance to the over all work product. That sort of 'auto curation' would then let you scan just the list with a 'curation threshold' and just read the important bits rather than everything in the list.

That might be a good compromise between a dedicated historian/textbook writer and a list which had all the data but it was inter spersed with the occasional "lets gets the group together for a movie / which movie" discussion.

[alfra]

When I look at, for example, technical updates from the Facebook Engineering teams, it's really a little textbook, a distilled version of the knowledge at that point in time.

Same if you bring new team members up to speed by talking to that person.

There is typically no single "historical" document that does the job. Old documents (e-mails, descriptions, comments, ...) tend to be outdated. New documents tend to be increments, so they don't really make sense if you don't know what is written in the old documents.

I expect that in the near future, automatic summaries based on NLP would be able to do all the heavy lifting, so the head of engineering (or whoever is in charge) will only edit the doc, not write it from scratch.