img/staging-area-diff.dot

+digraph {
+    node [shape = "box", style = "filled,rounded"]
+
+    workdir[label = "working directory\n(changes not staged for commit)", color = lightskyblue]
+    stage[label = "staging area\n(changes to be committed)", color = orchid]
+    repo[label = "repository\n(tracked content)", color = limegreen]
+
+    workdir -> stage [label = "git diff"]
+    stage -> repo [label = "git diff --staged"]
+}

img/staging-area.dot

@@ -10,10 +10,10 @@ digraph {
     # untracked -> stage [label = "git add"]
     # stage -> untracked [label = "git unstage"]
 
-    workdir -> stage [label = "git stage file"]
-    stage -> workdir [label = "git unstage file"]
+    workdir:sw -> stage:w [label = "git stage file"]
+    stage:e -> workdir:se [xlabel = "git unstage file"]
 
-    # workdir -> discard [label = "git checkout"]
+    # workdir -> discard [label = "git restore"]
     # untracked -> discard [label = "rm"]
 
     stage -> repo [label = "git commit"]

pandoc-cheat-sheet @ 2346a002

+Subproject commit 2346a002289757ee612bfd4b56b57db53e0c751b

pandoc-papers.md

-% pandoc papers
-% Christian Krause
+---
+title: pandoc papers
+subtitle: a future proof way to write
+author:
+- Christian Krause
+...
 
-# intro
+intro
+=====
 
-## goals
+## motivation #1
 
-- focus on content/writing
-- version control
-- next generation communication
+![](img/motivation-draft-mess-half-size.png)
+
+## motivation #2
+
+- **focus** on content/writing
+- **communication**
   - avoid emails with attachments, right?
-  - reviews!
-- automated publishing
+  - early and frequent reviews
+- get rid of MS Word, Google Docs, Dropbox, etc.
+
+## motivation #3
+
+- use **version control** with all its benefits
+- **automated**
+  - spell checking
   - high quality typesetting
+  - publishing
+- **future proof** way of doing things, meaning
+  - tools are open source
+  - tools are replaceable or optional
+  - all content is plain text
 
-# tools
+## agenda
 
-## pandoc
+- short presentation including demo
+- learn tools and workflows
+- establish community
+
+
+tools
+=====
+
+## pandoc -- Swiss Army Knife of Text Conversion
 
 ### source: markup
 
 - usually **Markdown**
-- less powerful than LaTeX, but inline LaTeX can be used
+- less powerful than \LaTeX, but inline \LaTeX\ can be used
 
 ### target**s**
 
-- high quality PDF via LaTeX
-- others: html, epub, docx, odt
+- high quality PDF via \LaTeX
+- others: HTML web page, EPUB, Office documents
 
 ### templates
 
 - different journals
 - iDiv branding
-- draft branding
 
 ## Markdown
 
-### rendered
-
-- **easy to learn**, read and write
-- no distractions to *procrastinate*
-- inline LaTeX if needed: $a^2 + b^2 = c^2$
-
 ### source
 
 ```
 - **easy to learn**, read and write
-- no distractions to *procrastinate*
-- inline LaTeX if needed: $a^2 + b^2 = c^2$
+- ~~no~~ fewer distractions to *procrastinate*
+- inline \LaTeX\ if needed \rightarrow\ $a^2 + b^2 = c^2$
 ```
 
+### rendered
+
+- **easy to learn**, read and write
+- ~~no~~ fewer distractions to *procrastinate*
+- inline \LaTeX\ if needed \rightarrow\ $a^2 + b^2 = c^2$
+
 ## git & GitLab
 
 ### git
@@ -60,6 +86,7 @@
 
 - self-hosted, full access control
 - communication: discussion and reviews
+- continuous integration i.e. spell checking
 - continuous deployment to e.g. cloud storage
 
 ## visualization
@@ -68,124 +95,124 @@
 
 - graph visualization language
 - define flowcharts with code
-- **dot** handles rendering
-- use **make** to build
+- **dot** handles rendering to **SVG**
 
-### R scripts
+### plotting
 
-- add results as CSV to repository
-- visualize data in CSV to charts
-- use **make** to build
+- any *programming language* can be used
+- add results as **CSV** to repository
+- plot data to **SVG** e.g. using **R** with **ggplot2** and **svglite**
 
-## make
+## build tool
 
-### simple build tool
+### make
 
 - glues everything together
-- automated build
+- automates build
   - render images from **dot** and **CSV** sources
   - build PDF
+  - run spell check
+
 
-# workflow
+workflow
+========
 
 ## workflow #1
 
-### project
+### [set up new project in GitLab](https://git.idiv.de/projects/new)
 
-- set up project in GitLab
-  - use **pandoc papers** project template
-  - project template is managed by our community
-  - contains Makefile, README, themes, CD, etc.
-- add contributors / collaborators
+- use project template
+- template is managed by our community
+- contains Makefile, README, CI/CD, ~~themes~~, visualization examples, etc.
 
 ### writing
 
 - start writing the main document in Markdown
-- use good text editor you're comfortable with
+- use text editor you're comfortable with
 
 ## workflow #2
 
 ### communication
 
+- invite contributors / collaborators to GitLab project
 - use GitLab project as main communication platform
 - discuss and review in
   - commit comments
   - issues
   - merge requests
-- invite collaborators: send link to GitLab project
 
 ## workflow #3
 
 ### continuous deployment
 
+- some parts are done automatically with the project template
 - deploy PDF to cloud storage:
   [https://portal.idiv.de/nextcloud/](https://portal.idiv.de/nextcloud/)
-- use template with **DRAFT** watermark if commit not tagged
+- (uses **DRAFT** watermark ~~if commit not tagged~~)
 
-### templates
+## demo
 
-- manage templates in our community
-- keep in separate git repository
-- use git sub-module to include
-- share with all@idiv / world
+(demo here only if all tools are already installed)
 
-# misc
 
-## helpful commands
+your turn
+=========
 
-```bash
-# better diff command for text
-git diff -w --ignore-blank-lines --word-diff
+## discussion
 
-# watch source and build if changes
-watchexec -w paper.md -- make paper.pdf
-```
+- Which tools do you currently use?
+  - Anyone know **pandoc-scholar**?
+  - Anyone know **authorea**?
+- What are your workflows?
+- How do you communicate, collaborate and review?
+- What annoys you the most? (i.e. how can we improve)
+
+## let's get started
+
+### create new project
 
-## community #1
+- https://git.idiv.de/projects/new
+- **create from template** \rightarrow\ **instance** \rightarrow\ **pandoc**
+- install tools from `README.md`
+- set up Nextcloud share and CD
 
-### pandoc paper project template
+### editor: Atom
 
-- `README.md` with instructions how to build
-- `Makefile` with general build instructions
-- include pandoc LaTeX themes via sub-module
-- CD pipeline instructions
-- `main.md` with hello world document using includes for chapters
-- example **dot** file for flowchart
-- example **CSV** and **R script** to generate charts
-- `.gitignore` with default products
+- **atom-latex** for bib syntax highlighting
+- **graphviz-preview-plus** for dot syntax highlighting and preview
+- **hard-wrap** for wrapping paragraphs
+- **language-pfm** for pandoc flavored Markdown
+- **language-r** for R
 
-## community #2
+## issues
 
 ### prose diff tool
 
+- hard wrap vs soft wrap
 - these issues might help:
   [gitlab-ce#25650](https://gitlab.com/gitlab-org/gitlab-ce/issues/25650),
   [gitlab-ce#26804](https://gitlab.com/gitlab-org/gitlab-ce/issues/26804)
 - [https://github.blog/2014-02-14-rendered-prose-diffs/](https://github.blog/2014-02-14-rendered-prose-diffs/)
 
-### continuous deployment
-
-- we don't have solid CD yet
-- can CD deploy to Nextcloud share?
+### spell checking
 
-### others
+- integrate editor spell checking with **mdspell**
+- per project editor integration
+- needs additional ignores, e.g. links, \LaTeX\ and citations
 
-- repository with LaTeX templates for pandoc
-- **review-able** PDF template with link to join discussion at every paragraph
 
-# your turn
-
-## discussion
+community
+=========
 
-- Which tools do you currently use?
-- What are your workflows?
-- How do you communicate, collaborate and review?
-- What annoys you the most? (i.e. how can we improve)
+## contributing
 
-## let's use it
+### [https://git.idiv.de/publishing](https://git.idiv.de/publishing)
 
-- install tools
-- install editor
-- set up git project
-- convert existing documents to Markdown
-- build with pandoc
+- contribute to **project template** about build / workflow related issues
+  - e.g. if you need more packages for plotting
+- contribute to **bibliography** about new references
+  - we may even import/sync an existing publication database
+- contribute to **pandoc templates**
+  - had no need for them yet
+  - we might add some iDiv corporate identity (talk with PR)
+  - **review-able** template with link to join discussion at every paragraph

rdm.html

+<!DOCTYPE html>
+<html>
+  <head>
+    <title>git@rdm</title>
+    <link rel="stylesheet" href="reveal.js/dist/reveal.css">
+    <link rel="stylesheet" href="reveal.js/dist/theme/black.css">
+    <link rel="stylesheet" href="css/company-logo.css" />
+    <link rel="stylesheet" href="css/ribbon.css" />
+    <link rel="stylesheet" href="css/crawl.css" />
+  </head>
+
+  <body>
+    <div class="reveal">
+      <div class="slides">
+
+        <!---------------------------------------------------------------------
+        <!-- intro
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="title" data-markdown>
+            # git and rdm
+            ## (... and reproducibility)
+
+            notes:
+            - `make -B` to create images, then reload
+          </section>
+
+          <section id="intro-objectives" data-markdown>
+            ## objectives
+
+            - show how git relates to RDM
+            - ... and reproducibility
+          </section>
+
+          <section id="intro-agenda" data-markdown>
+            ## agenda
+
+            1.  motivation
+            1.  ~~teach ***how*** to use git/GitHub/GitLab~~
+            1.  use cases
+            1.  anti-patterns
+            1.  platforms
+            1.  Q & A
+
+            notes:
+            - feel free to interrupt with immediate questions
+            - more involved detailed discussion as part of Q & A
+          </section>
+
+          <section id="intro-version-control" data-markdown>
+            ## about version control
+
+            > records changes
+
+            what who when (why)
+
+            notes:
+            - the **why** (aka context) is optional
+              - you have to do this
+              - you have to care about it
+          </section>
+
+          <section id="intro-about-git" data-markdown>
+            ## about git
+
+            ### best tool for the job
+
+            - simple by design
+            - powerful if needed
+            - documentation / community
+            - industry standard
+
+            notes:
+            - git name: "the stupid content tracker"
+            - doc: finding answers with web searches
+          </section>
+
+          <section id="intro-about-me" data-markdown>
+            ## about me
+
+            - scientific computing support @ iDiv since 2014
+            - satisfied git user since 2010
+
+            > There will never be a better version control system than git.
+            >
+            > -- Christian Krause, 2017
+          </section>
+
+          <section id="intro-about-you" data-markdown>
+            ## about you
+
+            ![people](img/people.jpg)
+
+            notes:
+            - who has never used any VCS before?
+            - who actively maintains a VCS repository?
+          </section>
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- motivation
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="motivation" data-markdown>
+            # motivation
+
+            > Why should I use version control?
+
+            notes:
+            - motivation chapter is about the concept of version control
+            - git is just a tool to do it
+          </section>
+
+          <section id="motivation-avoid-mess" data-markdown>
+            ## motivation #1
+            ### avoid mess
+
+            ![blah](img/motivation-draft-mess.png)
+
+            notes:
+            - who has seen such a mess?
+            - who has contributed to such a mess?
+            - who has created such a mess?
+          </section>
+
+          <section id="motivation-want-structure" data-markdown>
+            ## motivation #1
+            ### want structure
+
+            ![blah](img/motivation-structure.svg)
+
+            notes:
+            - structure: who, when
+            - why is hidden (only shows message header, not body)
+            - ability to inspect old versions and their diff
+            - ability to revert/undo a change
+          </section>
+
+          <section id="motivation-playground" data-markdown>
+            ## motivation #2
+            ### throw-away playgrounds
+
+            ![playground](img/motivation-throwaway-playground.svg)
+
+            notes:
+            - test stuff without interfering
+              - throw away if garbage
+              - integrate if good
+            - switch back and forth without pain
+          </section>
+
+          <section id="motivation-collaboration-1" data-markdown>
+            ## motivation #c
+            ### collaboration made easy
+
+            <!-- do not fix this typo, it is here on purpose to show collab -->
+            > This text cntains a typo.
+
+            notes:
+            - demo GitLab (change **target branch** to create merge request)
+            - this is how you can do reviews of drafts
+              - discuss this slide/chapter/section link
+          </section>
+
+          <section id="motivation-collaboration-2" data-markdown>
+            ## motivation #c
+
+            ![typo-pr](https://pbs.twimg.com/media/EDsklbLUEAMdusJ.png)
+
+            notes:
+            - might not seem like much
+            - but you are still making the world a better place
+            - and it is not too much effort
+          </section>
+
+          <section id="motivation-automation" data-markdown>
+            ## motivation #a
+            ### automation
+
+            - ***quality***
+              - **code analysis**
+              - **spell check**
+              - **software testing**
+              - enforce **style guide**
+            - ***deployment*** (app store, web server)
+
+            notes:
+            - basically, everything you can script
+            - refresh presentation before next slide
+          </section>
+
+          <section class="star-wars" id="motivation-wars">
+            <div class="crawl">
+              <div class="title">
+                <h1>motivation #wars</h1>
+              </div>
+
+              <div data-markdown>
+                1.  view the ***history*** of changes
+
+                1.  know ***why*** someone changed it
+
+                1.  ***revert*** a bad change
+
+                1.  maintain ***multiple versions***
+
+                1.  see the ***diff*** of two versions
+
+                1.  find commit ***that broke*** something
+
+                1.  have free ***backup***
+
+                1.  have ***non-interfering*** playgrounds
+
+                1.  have ***automated*** testing
+
+                1.  have ***automated*** deployment
+
+                1.  ***contribute*** to a project
+
+                1.  ***share*** your code
+
+                1.  let other people do the work ***for you***
+              </div>
+
+              <img src="http://i.giphy.com/90F8aUepslB84.gif" />
+            </div>
+          </section>
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- use cases
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="use-cases" data-markdown>
+            # use cases
+            ##### for
+            ### version control system (vcs)
+            ##### aka
+            ### source code management (scm)
+          </section>
+
+          <section id="use-case-software" data-markdown>
+            ## software
+
+            - generic (as in parameterized)
+            - (ideally) tested
+
+            notes:
+            - e.g. R package
+          </section>
+
+          <section id="use-case-scripting" data-markdown>
+            ## scripting
+            ##### aka
+            ### how to run `$software`
+
+            - ... in `$environment`
+            - digital lab notes
+            - **reproducibility** !!1!
+            - execution scalability
+
+            notes:
+            - separate software from scripting
+            - `$enviroment`: multiple scripts/configurations for different
+              environments:
+              - EasyBuild, conda, singularity
+              - RStudio server, HPC cluster
+            - execution scalability: running software or script without having
+              to change it
+            - keep failed attempts in branches
+              - e.g. highly parameterized software, make a record of bad
+                parameter sets
+          </section>
+
+          <section id="use-case-publishing" data-markdown>
+            # publishing
+            ### (markdown (with some tex))
+
+            - paper / thesis / book
+            - presentation
+            - documentation
+            - blog
+
+            notes:
+            - who is using markdown?
+            - who is using tex?
+            - who is using word? why?
+            - markdown with tex
+              - git.idiv.de/help
+              - search for markdown
+              - search for math
+              - show example
+          </section>
+
+          <section id="use-case-integrated-1" data-markdown>
+            ## integration
+
+            ![run `make` to generate the image](img/rdm-use-cases-a.svg)
+
+            notes:
+            - software A: tried and tested, reference to compare to
+            - software B: your experimental better version
+          </section>
+
+          <section id="use-case-integrated-2" data-markdown>
+            ## integration
+
+            ![run `make` to generate the image](img/rdm-use-cases-b.svg)
+          </section>
+
+          <section id="use-case-integrated-3" data-markdown>
+            ## integration
+
+            ![run `make` to generate the image](img/rdm-use-cases.svg)
+          </section>
+
+          <section id="use-case-integrated-data" data-markdown>
+            ## integration
+
+            ![run `make` to generate the image](img/rdm-use-case-data.svg)
+          </section>
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- anti patterns
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="anti-patterns" data-markdown>
+            # anti-patterns
+
+            ![unlimited power](img/unlimited-power.jpg)
+
+            notes:
+            - does anyone know what an anti-pattern is?
+          </section>
+
+          <section id="anti-patterns-def" data-markdown>
+            # anti-patterns
+
+            > An anti-pattern is a common response to a recurring problem that
+            is usually ineffective and risks being highly counterproductive.
+
+            notes:
+            - most anti-patterns about how to use git
+            - focus here is on these relating to RDM and reproducibility
+          </section>
+
+          <section id="anti-pattern-binary" data-markdown>
+            # binary files
+            ### (aka non-text)
+
+            - no diff with binary
+            - use textual representation
+            - convert with automation
+
+            notes:
+            - can someone give me an example of text file?
+              - markdown
+              - source code, scripts (R, shell)
+              - XSV
+            - can someone give me an example of binary file?
+              - compiled programs
+              - MS word excel
+              - PDF PS
+            - don't just put everything in the repo, use *ignore
+          </section>
+
+          <section id="anti-pattern-big-data" data-markdown>
+            # data in git
+            ## (scientific/big data)
+
+            - version control for data is **DIFF**erent !!1!
+            - git is VCS for text, not for data
+
+            notes:
+            - do you release data with every script change? no, too expensive
+            - you don't ever put data files in a git repository
+            - not even with LFS
+            - big ball of mud, no metadata
+          </section>
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- platforms
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="platforms-list" data-markdown>
+            # platforms
+
+            - GitHub
+              - https://github.com/idiv-biodiversity (cloud)
+            - GitLab
+              - https://gitlab.com (cloud)
+              - https://git.idiv.de (self-hosted @ iDiv)
+          </section>
+
+          <section id="platforms-purpose" data-markdown>
+            # platforms
+
+            - enable collaboration
+              - bug tracker / feature requests
+              - documentation / wiki
+            - project management tools
+              - issue boards, milestones, gantt
+            - trigger automation
+            - publish/download releases
+          </section>
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- q & a
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="q-n-a" data-markdown>
+            # Q & A
+
+            notes:
+            - walk through examples of software/script/publishing
+            - walk through one of your use cases
+              - demo consulting
+          </section>
+
+          <section id="consulting" data-markdown>
+            # consulting
+
+            [christian.krause@idiv.de](mailto:christian.krause@idiv.de)
+          </section>
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- eof
+        <!-------------------------------------------------------------------->
+
+        <section id="eof" data-background="img/trex.png" data-markdown>
+          ### thanks for listening
+          # EOF
+        </section>
+
+        <!---------------------------------------------------------------------
+        <!-- backup
+        <!-------------------------------------------------------------------->
+
+        <section>
+          <section id="backup" data-markdown>
+            # backup slides
+          </section>
+
+          <section id="empty" data-markdown>
+          </section>
+        </section>
+      </div>
+    </div>
+
+    <!-------------------------------------------------------------------------
+    <!-- css/js
+    <!------------------------------------------------------------------------>
+
+    <!-- company logo -->
+
+    <div class="logo-wrapper">
+      <a href="https://www.idiv.de/">
+        <img src="img/company-logo-small.png" />
+      </a>
+    </div>
+
+    <!-- ribbon -->
+
+    <div class="ribbon-wrapper right">
+      <div class="ribbon">
+        <a href="https://git.idiv.de/sc/edu/git-seminar/edit/main/rdm.html"
+            target="_blank">
+          edit
+        </a>
+      </div>
+    </div>
+
+    <!-- reveal.stuff -->
+
+    <script src="reveal.js/dist/reveal.js"></script>
+    <script src="reveal.js/plugin/highlight/highlight.js"></script>
+    <script src="reveal.js/plugin/markdown/markdown.js"></script>
+    <script src="reveal.js/plugin/notes/notes.js"></script>
+
+    <script>
+      Reveal.initialize({
+          hash: true,
+          plugins: [RevealHighlight, RevealMarkdown, RevealNotes]
+      });
+    </script>
+  </body>
+</html>

rdm.md

+git for RDM and reproducibility
+===============================
+
+checklist
+---------
+
+- **software** (a generic tool to do *something*)
+  - [ ] use separate git repo for software
+  - [ ] tag versions for reproducibility
+  - [ ] keep software as generic as possible
+- **scripts** (*how* to use *software*)
+  - [ ] use separate git repo for scripts
+  - [ ] tag versions for reproducibility
+  - [ ] software is configured here
+  - [ ] reference used software tag
+- **data management**
+  - [ ] publish dataset(s) to scientific data archive system
+  - [ ] always attach proper metadata
+  - [ ] get DOI for each version of the dataset(s) for reproducibility
+  - [ ] reference used scripts tag
+- **publishing**
+  - [ ] use separate git repo for paper/thesis/...
+  - [ ] tag versions for draft/review/final
+  - [ ] convert text/source to (binary) products
+  - [ ] reference used scripts tag
+  - [ ] reference used data DOI
+- **platforms** (GitLab, GitHub)
+  - [ ] use platforms (GitLab, GitHub) for collaboration
+  - [ ] review commits / merge requests
+  - [ ] utilize project management tools
+  - [ ] utilize automation for testing and publishing
+
+
+intro
+-----
+
+- version control system (VCS) records changes (what, who, when, why)
+- use platforms (GitLab, GitHub) for collaboration
+
+
+git use cases
+-------------
+
+### software
+
+- keep software as generic as possible
+- turn configuration/parameters into arguments, e.g. `myapp --seed=42`
+- this avoids having to rewrite software for parameter changes
+- use software testing to verify software does what it's supposed to do
+- tag versions to enable **reproducibility**
+
+### scripting
+
+- separate scripting from software
+  - software: generic
+  - scripting: software called with specific configuration/arguments
+- scripting means **how** to run the software
+  - i.e. here is where the parameters/arguments go
+  - think of it as digital lab notes
+  - this enables **reproducibility**
+- specialized script variants for different environments, e.g.
+  - laptop
+  - RStudio / terminal server
+  - HPC cluster
+- think about *execution scalability*, i.e. not having to change software and
+  scripting when you want to change parameters
+- keep failed attempts in branches to keep history of what you tried and why it
+  didn't work in commit message
+
+### publishing
+
+- for paper, thesis, book, presentation, documentation, blog posts
+  - use *programming languages* code/scripts for plots, flowcharts, etc.
+  - write text/paragraphs in markup language (e.g. markdown)
+- use automation workflows to
+  - generate plot/flowchart code to image files
+  - convert text with pandoc to PDF/PS/HTML/ebup
+- use platforms for review process
+
+## integration of use cases for reproducibility
+
+![](img/rdm-use-case-merged.svg)
+
+
+anti patterns
+-------------
+
+> An anti-pattern is a common response to a recurring problem that is usually
+> ineffective and risks being highly counterproductive.
+
+- most git anti-patterns are about *how* to use git
+- focus here is on these relating to RDM and reproducibility
+
+### binary files
+
+- git as VCS only good for text files
+  - markdown
+  - source code, scripts
+  - (small) CSV
+- binary files can't be diff'ed, e.g.
+  - compiled programs
+  - MS word, excel
+  - PDF, PS
+  - JPEG, PNG
+- use textual representation, e.g.
+  - graphviz dot for flowcharts
+  - R ggplot and CSV for plots
+- use automation to convert textual representation to e.g. images
+- use gitignore to never add binary products to the repo
+
+### scientific data in git repos
+
+- data is often binary
+- git repo should be small, data blows it up, even if text
+- data has different release cycles than code
+- even git lfs (large file storage) is bad because still big ball of mud
+  - scientific datasets need metadata!
+- use proper archive system for data
+
+
+platforms
+---------
+
+- enable collaboration
+  - bug tracker / feature requests
+  - documentation / wiki
+- project management tools
+  - issue boards, milestones, gantt
+- trigger automation
+- publish/download releases
+- go to https://git.idiv.de log in and create new projects!

rdm.yml

+---
+# these are not shown in the document, they are just for metadata
+title: git RDM reproducibility check list cheat sheet
+author: Christian Krause
+lang: en
+keywords:
+  - git
+  - RDM
+  - resource data management
+  - reproducibility
+
+# highlighting increases readability
+linkcolor: blue
+
+# these LaTeX variables fit as much content on as few pages as possible
+documentclass: scrartcl
+pagestyle: empty
+papersize: a4paper
+geometry:
+  - a4paper
+  - left=1cm
+  - right=1cm
+  - top=1cm
+  - bottom=1cm
+# you can also add "landscape" to geometry if you want more than 2 columns
+
+# fiddle with these to increase readability
+columns: 2
+fontsize: 9pt
+
+# this essentially disables justification, which can increase readability
+ragged: yes
+
+# color for header background
+sectionbg: BurntOrange
+subsectionbg: Apricot
+...

reveal.js @ a4b7f9df

-Subproject commit 65bdccd5807b6dfecad6eb3ea38872436d291e81
+Subproject commit a4b7f9dff7ef360afdb6d0cb53fd89063cbe0b66