Or, at least, a title/acronym

It would be nice to do this quickly, we are entering the Open Access week.

Read;
https://blogs.openaire.eu/?p=2010

This file https://github.com/Pfern/OSODOS/blob/master/docs/ROADMAP/README.md needs to be written out to indicate the "need to know" sections for the different stakeholders.

I propose that we build a standalone list of instructional videos that can be found in Youtube.
It would be nice to group them by theme and rank them by level of depth. Even nicer is we could add a small legend to each of them, stressing a subject that may be well covered.

Unordered, need review:
https://youtu.be/yspZkJQ2KLE
https://youtu.be/yELZ3kbFj1w
https://youtu.be/3wPp-TjtN_U
https://youtu.be/gBysjCmeq40
https://youtu.be/GPYzY9I78CI

The static html for the gitbook website needs to be re-generated to fold in the latest changes (notably, the roadmap).

...do we get them via github pages? Or do we need to insert a google analytics widget?

SciHub may not survive the current war with well funded publishers.
But, in the scope of the 2017 panorama it plays an important role in transforming the methods of access.
Can we converge on a way to refer to it?

check out https://github.com/HullUni-bioinformatics/metaBEAT and see if this can be used as an exercise

Assuming the prose is finished, here's what needs to happen:

• make a gh-pages branch
• rename all the README.md to index.md
• add supporting files from https://github.com/NESCent/community-and-code/tree/gh-pages
• adjust supporting files: update navigation, add logos

Should we reference this paper? https://doi.org/10.1371/journal.pbio.2002173

i.e. point osodos.org to https://pfern.github.io/OSODOS/gitbook/

• exclude node.js dependencies from the git repo
• export the gitbook to an external repo (should be osodos.github.io)
• make it so that the domain name "sticks" instead of forwards
• remove the _config.yml files

Add "Expected outcomes" section to pages:

• Publishing,
• Data capture,
• Reproducibility,
• Data sharing,
• Data management

In addition:

• add exercises and/or activities section to all pages
• write out the roadmap for stakeholders, including professional societies

Graduate students
Lab technicians
Data scientists
Principal investigators
Publishers

Maybe we can add funding agents to this list.

The gitbook "quizzes" plugin needs to be tested / used for exercises.

• add cover art bitmaps to the repo
• combine them with institutional logos (maybe link to separate files in the same document?)
• lay out rest of the cover page

At various points in the prose we cite scientific publications. To keep this manageable among collaborators we adopted the following workflow:

1. We collected references using the Mendeley browser bookmarklet, which resulted in a public library. We then made sure in Mendeley Desktop that every reference has an author, year, title, journal, and doi. We also made sure that all authors only had initials in their first names.
2. We then exported the Mendeley library to a bibtex file
3. We ran a script that converts the bibtex file to a list of references in Markdown
4. We cited the references by their bibtex key, e.g. [Zhang2014](../REFERENCES#Zhang2014)

We want an index that links terms to the pages they occur on. From among those terms we pick the ones we want to give a definition, and this becomes the glossary.

• ShareLaTeX
• https://beta.mybinder.org/

While working out #27 and reading the opening of that paragraph

**containerisation** - a more lightweight solution for bundling tools that are
otherwise difficult to install is offered by "containerisation"

Although it is true, it is just a single use case, and may be not even that common or prominent reason in at least scientific computing. I have some experience (a Debian developer) with managing software dependencies, and overall systems administration etc., so I have no difficulty to install tools (as many others who use some good Linux distribution which comes with many packages available already). I do love containers for a variety of other reasons though

• experimentation -- so easy and fast to get into another (Linux) environment I would otherwise spend hours installing/configuring if it was a fully fledged virtual machine
• reproducible computing -- even having captured full provenance (in a provisioning script or alike), deploying it for real use is too tedious and fragile (services could go down, versions disappear etc). Having a container image - I can always get that environment (e.g. if I keep it also under version control system. if not -- success might vary ;-)).
• portable computing -- I can transfer container image to another HPC or into the cloud and perform necessary computing without demanding (re)configuring that environment for my needs
• collaboration -- we do use the same "computing" pieces while using different base OS

Virtualization is unnecessarily too heavy for any of those use cases, and thus in my world its use is greatly diminished.

So I think that this paragraph should be reword a little to reflect advantages of containers better.

http://sdwfrost.github.io/mevr/

for inspiration:
https://github.com/sdwfrost/mevr

See the book.json
See also the Glossary.md

Summary.md for the book structure
https://github.com/jonschlinkert/markdown-toc for the TOC (clickable)
Use

It would be good to have somewhat better releases for the next version. E.g.:

• make a PDF version and tag that as "the" release DOI
• attach other e-book versions and the source tree as dependent DOIs (you can do this in zenodo)

This way the DOI actually links to something useful for readers rather than the zipped repository, and we are in control of the PDF and e-book versions (rather than have these be dispersed by 3rd parties), so we can track downloads and such.

Announcing lime - Explaining the predictions of black-box models
http://www.data-imaginist.com/2017/Announcing-lime/

I think that this make big dents in model assessment and data science in general.

What do we want to do:

• describe learning objectives
• describe target learner and pre-requisites
• identify learning outcomes and scope (#2)
• decompose into subsections, e.g. re-runnability, data provenance, etc. (#2)
• develop exercises, at least one for each learning outcome, but actually very many
• collect readings https://www.mendeley.com/community/osodos/ (#10)
• prepare lectures
• plan documentation

Several opportunities are presenting themselves for diffusing these contents. To wit:

• As a standalone e-book advertised via the participating institutions, i.e. Gulbenkian & Naturalis
• ELIXIR via GOBLET
• The MSc course Methods of Biodiversity Analysis
• The Open Science MOOC
• Foster open science sprint (12-15 February, Hannover)

Following #3

• define our target audience and their needs (e.g. data management, research reproducibility)
• define our scope (around life science information)
• define our objectives
• come up with a course description

(Use https://github.com/TrainTheTrainer/EXCELERATE-TtT/tree/EXCELERATE-TtT_Oeiras_Jan_2017 for inspiration)