Project organisation

[dblana]

I think it's time to make some folders for code, data, etc. Should we use the structure recommended in the guidebook? That would be three folders:

1. Inputs (data, metadata, definitions)
2. Methods (code + documentation)
3. Outputs (manuscript)

What do you all think?

[will-ball]

I'd be happy to go with that structure. There are lots of options, I guess it just depends on personal preference. Some kind of structure is definitely better than none.

To add to the discussion I'm going to suggest people take a look at this. It's an example directory of an 'executable compendium' which has reproducibility at it's heart. I think for this project it may not be a complete fit as the data will never be publicly accessible, but it's a neat idea.

compendium/ ├── CITATION ├── code │ ├── analyse_data.R │ └── clean_data.R ├── data_clean │ └── data_clean.csv ├── data_raw │ ├── datapackage.json │ └── data_raw.csv ├── Dockerfile ├── figures │ └── flow_chart.jpeg ├── LICENSE ├── Makefile ├── paper.Rmd └── README.md

It comes from a collection of books called 'The Turing Way' which is worth reading.

[BScheliga]

I like @will-ball suggestion in regards to having a more refined folder structure, especially respect of separating the raw data from the cleaned

[dblana]

So... do we want to update the guidebook? The inputs-methods-outputs structure is based on the same idea described in the Turing Way: separating methods, data and outputs. (By the way, if you look closely you'll see I'm one of The Turing Way contributors 😄) I'd rather we update the guidebook and use the recommended structure here, otherwise... what's the point of the guidebook? (But then that's a discussion to have over in the guidebook repo 😁)

[dblana]

☝️ Github is so smart, it knows I referred to this issue from the issue I started in the guidebook 😲