initial thoughts on statements around data processing principles

[walteck]

Would appreciate some additional input / discussion here to ensure an appropriate statement of how teams should be operating.
@andyblundell and @iw-ezequiel - any thoughts?

[iw-ezequiel]

Hi Chris, thanks for picking this up. I think this point is very relevant - what I'm wondering is how we generally go about these principles, do we have the right list and are they at the right level. I took a stab at rationalising some of the points in #158 but that's still work in progress. Might be worth a separate discussion? (or maybe I'm overthinking this, that's very possible too!)

[andyblundell]

Hi @walteck defo agree this is a really good thing to include. I think the section on secrets mentions data too, so there might be some joining up to do - and I think there is a vague reference to tools like Macie which could potentially be used to find bad things after the event (obviously not as good as not having the problem in the first place)

[andyblundell]

How about we relocate the new section to everything-as-code, to sit alongside the guidance around code hygiene etc, and we include the high-level principle in section 2 (build quality in) rather than as a new section 8 (to stick with the 7 lean chapters).

"Protect code quality to keep code easy to maintain." could be changed with "and separate code from data" maybe - or there could be a line of its own in section 2?

Happy to discuss obviously :)