Wider Handbook Vision

[chedburgh]

This is to kick start a discussion on the wider vision of the handbook and its use.

We need to think about:

• Level, I e. What level of engineering detail do we need to go into here?
• Maintenance. How do we maintain technical pages where tools and methods are changing fast?
• Duplication. Are we just duplicating stack exchange?
• Can some details live in The Knowledge?
• Audience. Who is this aimed at? It's a public repo, so partially it's a reveal about us and how we work

Why? Past experience shows technical company wikis are often outdated and badly maintained longer term. Engineers often turn to the internet as the source of current technical know how.

If we nail down a vison and how it will be maintained early on, the handbook will have a better quality longer term.

One idea is to limit and curate the details to higher level practice and process, understanding of the engineer roles and function and engineering policies. Move everything else into the knowledge

[PsypherPunk]

I think we've now 3 diverging things:

1. The Knowledge was intended as a repository of our tech. opinions (evidenced, natch).
2. The Handbook was intended as a guide on our policies and practices.
3. we seem to now have a 3rd need for how-to guides (which doesn't neatly fit into either of the above; arguably this should go in a "handbook" but that's not quite what our Handbook™ is for.)

[gvee-uk]

I keep forgetting that TheKnowledge exists! We probably need to promote that, or link to it from within the handbook somewhere.

Perhaps a section to signpost to it will suffice, and then any suggested commit that doesn't fit the "policies and practices" part should be shuffled over there instead?