[Ready for review] RDM chapter

[pherterich]

Summary

Just making the RDM chapter draft more visible so others can edit on top.

Fixes #179

List of changes proposed in this PR (pull-request)

First proper draft!!!

What should a reviewer concentrate their feedback on?

• Mainly high level comments, anything more substantial please add those comments to Write the chapter on Research Data Management #179 for a next round of editing or someone else to pick up.

I will do some proper linking of the ToC later - it shouldn't be too long to read I hope.

Acknowledging contributors

By submitting this pull request I confirm that:

• all contributors to this pull request who wish to be included are named in humans.md.

[r-j-arnold]

Don't know if this link may be useful (it's creative commons) https://programminghistorian.org/en/lessons/intro-to-linked-data

[alexmorley]

I did like a "golden rules for data management" at a training day last year. I was wondering whether for the Summary we could do something like that (but modified to fit in with the content you already have) and then point to the subsections for the details. The one below was made quite specifically for neuroscientists but maybe it could be useful:

1. Don't Touch the Raw Data - back it up and keep read-only copy.

2. Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted BEFORE you start collecting it.

3. Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!

4. Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how yours should look.

5. Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be better in the long run even if you think there's a better solution.