diff --git a/_posts/2019/10/2019-10-29-Blog-Post-Features.md b/_posts/2019/10/2019-10-29-Blog-Post-Features.md
new file mode 100644
index 0000000000000000000000000000000000000000..ee9b5de86dd5fb9e54c91937b5db34dbc011a18c
--- /dev/null
+++ b/_posts/2019/10/2019-10-29-Blog-Post-Features.md
@@ -0,0 +1,419 @@
+---
+title: Example Blog Post Template
+date: 2019-10-29
+authors:
+ - hueser
+ - erxleben
+layout: blogpost
+title_image: default
+categories:
+ - blog
+tags:
+ - example
+ - template
+ - markdown
+additional_js:
+ - mathjax.js
+excerpt:
+ This post will give you an overview of all the features you can use in your
+ very own HIFIS Software blog post.
+---
+
+# Blog Post Metadata
+
+This post will give you an overview of all the features you can use in your
+very own HIFIS Software blog post.
+
+## The Frontmatter
+
+At the top of your blog post you need to enter the so called _Jekyll_
+_frontmatter_ which defines the meta-information about your blog post.
+
+Note that the frontmatter is placed at the very top of your markdown file
+and begins and ends with `---`.
+
+For example:
+```
+---
+title: A Sample Blog Post Title
+date: 2019-12-31
+authors:
+ - example_author_id
+layout: blogpost
+title_image: default
+excerpt_separator: <!--more-->
+categories:
+ - hifis
+tags:
+ - draft
+additional_css:
+ - my_own.css
+additional_js:
+ - mathjax.js
+---
+```
+
+Here is an overview over all the variables that can appear in your frontmatter:
+
+| Variable | Mandatory | Default Value |
+|-----------------------|:---------:|:-------------:|
+| **title** | Yes | - |
+| **date** | Yes | - |
+| **authors** | Yes | - |
+| **layout** | Yes | blogpost |
+| **title_image** | No | default |
+| **excerpt_separator** | No | `<!--more-->` |
+| **categories** | No | - |
+| **tags** | No | - |
+| **additional_css** | No | - |
+
+## Variables Explained in Depth
+
+If you do not want to set any of the optional variables it is safe to leave
+them out completely.
+
+### title
+
+Set the title of the blog post.
+Prefer a short, on-point version, it has to fit in the pages' header among other
+things.
+
+### date
+
+Set the publication date of the blog post.
+Please use a date format according to this example given:
+`YYYY-MM-DD`, e.g. `2019-10-29`.
+
+### authors
+
+Give a list of author IDs in YAML syntax.
+You can find your author ID in the YAML-file `_data/hifis_team.yml`.
+If your name is not contained you can add it by editing the hifis_team.yml file
+or opening an issue with the _add team member_ template in GitLab.
+
+### layout
+
+Set the layout of the blog post.
+Usually it is not wanted to create and specify your own blog post
+layout. In order to create your own styling we might want to
+provide additional CSS via variable "additional_css" as stated below.
+
+### title_image
+
+Set the title_image to use.
+A good blog post will have an appealing title image.
+It is recommended to create a sub-folder of the images folder
+`{{ site.directory.images }}` per blog post which should be named
+like this: `posts/2019-10-29-my-blog-post-name/`.
+If you place your _title_image_ there, providing the sub-folder and
+name of the image (with extension) will be sufficient.
+In this case you need to set the variable _title_image_ accordingly,
+e.g. `posts/2019-10-29-my-blog-post-name/my-title_image.png`.
+You can also use the value **default** for the website default
+image.
+If you omit the variable completely the background will fall back to
+Helmholtz-blue.
+
+### excerpt_separator
+
+Separator to be used to indicate end of excerpt.
+
+### categories
+
+Set list of categories for your blog post.
+The URL will contain these categories.
+
+### tags
+
+Set a list of tags for your blog post.
+
+### additional_css
+
+You can provide your own CSS file for your blog post.
+You can name a CSS-file which provides custom styling to be used within your
+blog post.
+It is supposed to reside in `assets/css/`.
+Providing the file name (including extension) is enough.
+
+---
+
+# Blog Post Markdown Examples
+
+## Excerpt Separator
+
+Use the excerpt separator stated in the frontmatter to provide a short
+excerpt of the blog post and cut off the remaining text in the blog
+post on the overview / preview page of the blog posts:
+
+ Excerpt text as a preview to the blog post. Please keep this short
+ and meaningful.
+ <!--more-->
+ Remaining text of the blog post. Go into details here.
+
+## Headlines
+
+Headlines and sub-headlines can be defined with leading hashes (#).
+
+ # This is a Headline
+ ## This is a Sub-Headline
+ ### This is a Sub-Sub-Headline
+
+## List Items
+
+Bullet points can be added by asterisks (*), while numberings are done
+by a number followed by a dot (1.).
+
+Examples:
+
+ * item one
+ * item two
+ 1. first item
+ 2. second item
+
+* item one
+* item two
+1. first item
+2. second item
+
+Sub-lists can be achieved by indentation:
+
+ * item one
+ * item two
+ * sub-item one
+
+* item one
+* item two
+ * sub-item one
+
+## Task Lists
+
+You can define checkboxes by squared brackets, e.g.
+
+ * [ ] First task list item
+ * [X] Second task list item (checked)
+ 1. [ ] First numbered task list item
+ 2. [X] Second numbered task list item (checked)
+
+* [ ] First task list item
+* [X] Second task list item (checked)
+1. [ ] First numbered task list item
+2. [X] Second numbered task list item (checked)
+
+## Font Formatting
+
+For italic characters embed them in underscores
+(like this `_my italic text_` which results in _my italic text_).
+For bold characters embed them in double asterisks
+(like this `**my bold text**` which results in **my bold text**).
+
+## Math
+
+There is syntax for inline math as well as math on separate lines.
+
+These are two examples:
+
+This is an inline math snippet `$$ a^2+b^2=c^2 $$`: $$ a^2+b^2=c^2 $$
+
+Math on a separate line can be implemented like this:
+
+ $$
+ \begin{align*}
+ & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
+ = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
+ & (x_1, \ldots, x_n) \left( \begin{array}{ccc}
+ \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
+ \vdots & \ddots & \vdots \\
+ \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
+ \end{array} \right)
+ \left( \begin{array}{c}
+ y_1 \\
+ \vdots \\
+ y_n
+ \end{array} \right)
+ \end{align*}
+ $$
+
+$$
+\begin{align*}
+ & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
+ = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
+ & (x_1, \ldots, x_n) \left( \begin{array}{ccc}
+ \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
+ \vdots & \ddots & \vdots \\
+ \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
+ \end{array} \right)
+ \left( \begin{array}{c}
+ y_1 \\
+ \vdots \\
+ y_n
+ \end{array} \right)
+\end{align*}
+$$
+
+## Quotes
+
+Use block-quotes to highlight quotes like this:
+
+For one-line quotes put a "greater than"-sign (`>`) infront of the quote:
+
+ > This is a one-line quote.
+
+> This is a one-line quote.
+
+For multi-line quotes put "greater than"-signs (`>`) above and
+below the quote, one per qutation level:
+
+ >
+ This is a multi-line quote:
+ Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
+ sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
+ aliquyam erat, sed diam voluptua.
+ >> There can be second level quotes.
+ >
+
+>
+This is a multi-line quote:
+Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
+sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
+aliquyam erat, sed diam voluptua.
+>> There can be second level quotes.
+>
+
+The same look is achieved with HTML `blockquote` tags.
+
+## Code
+
+Use inline code with single back-tics:
+
+ `$ apt-get update`
+
+`$ apt-get update`
+
+Use three back-tics and specify the language (```shell)
+to mark code snippets on separate lines:
+
+ ```shell
+ $ apt-get update
+ ```
+
+```shell
+$ apt-get update
+```
+
+## Images
+
+Images can be included by stating URL, title and alternative text
+like so:
+
+ 
+
+
+
+Likewise to the `title_image` variable in the _frontmatter_ it is
+recommended to create a sub-folder of the images folder
+`{{ site.directory.images }}` per blog post.
+It should be named in the form `posts/YYYY-MM-DD-my-blog-post-name/`.
+If you consequently put your images into the sub-folder
+`{{ site.directory.images }}posts/2019-10-29-my-blog-post-name/`,
+you need to provide the full relative path to these images using the
+_Jekyll Liquid_ variable `site.directory.images`.
+For example:
+
+`{% raw %}{{ site.directory.images | relative_url }}{% endraw %}posts/2019-10-29-my-blog-post-name/my-blog-post-image.png`.
+
+## Links
+
+If you would like to give a link for your references you need to
+specify a link text, the URL as well as link title, e.g.
+
+ [Text for link to google.com](https://www.google.com "Link to Google!")
+
+[Text for link to google.com](https://www.google.com "Link to Google!")
+
+## Tables
+
+Tables are a bit more complicated.
+You need to give headers for your columns embedded in pipe-characters
+(|), a separator row with dashes (-) and the cells with your content
+embedded in pipe-characters (|) again:
+
+ | column 1 | column 2 |
+ |---|---|
+ | row 1 | row 1 |
+ | row 2 | row 2 |
+
+| column 1 | column 2 |
+|---|---|
+| row 1 | row 1 |
+| row 2 | row 2 |
+
+## Custom CSS Styles for Paragraphs
+
+To add custom CSS classes to your paragraph put a colon followed by dot and CSS
+class name in curly braces.
+You can use all classes from the _bootstrap 4.0_ framework, _fontawesome-solid_,
+your own classes provided by the _additional_css_ variable and a couple of
+custom built-in CSS classes:
+
+### summary
+
+Puts a blue border around the paragraph.
+
+ {:.summary}
+ This is text which appears in a box with blue border.
+
+{:.summary}
+This is text which appears in a box with blue border.
+
+### treat-as-figure
+
+This is a workaround for Markdowns shortcoming regarding figure environments.
+It styles text within the following paragraph as if it were an image caption.
+This is usually combined with an image, table or other figures.
+For the image URL you should use _Jekyll Liquid_ variables
+`site.url` and `site.directory.images` instead of hard-coding the URL.
+
+### float-left
+
+Floats the paragraph to the left side of the page and reduce its maximum width
+to 30%. Useful for small images, it can be combined with `treat-as-figure`.
+
+Example:
+
+ My paragraph above image which is treated as normal text.
+
+ {:.treat-as-figure}
+ {:.float-left}
+ My text above the image which is interpreted as caption.
+ 
+
+ My paragraph below image which is treated as normal text …
+
+My paragraph above image which is treated as normal text.
+
+{:.treat-as-figure}
+{:.float-left}
+My text above the image which is interpreted as caption.
+
+
+My paragraph below image which is treated as normal text. It flows around the
+image. Even though this is a rather hackish approach to getting more advanced
+styling into Markdown it is incredibly powerful and versatile, especially when
+combined with custom CSS.
+
+Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod
+tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At
+vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren,
+no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit
+amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut
+labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam
+et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata
+sanctus est Lorem ipsum dolor sit amet.
+
+# References
+
+For more detailed explanations of GitLab and Kramdown Markdown Syntax
+take a look here:
+
+* [GitLab Markdown Syntax Explained](https://docs.gitlab.com/ce/user/markdown.html "GitLab Markdown Syntax Documentation")
+* [Kramdown Markup Syntax Explained](https://kramdown.gettalong.org/syntax.html "Kramdown Markdown Syntax Documentation")
diff --git a/_posts/2019/11/2019-11-22-How-to-Create-a-new-Blog-Post.md b/_posts/2019/11/2019-11-22-How-to-Create-a-new-Blog-Post.md
new file mode 100644
index 0000000000000000000000000000000000000000..9e38188b5df0a2cf0f117a8df06d571e4d2e23cc
--- /dev/null
+++ b/_posts/2019/11/2019-11-22-How-to-Create-a-new-Blog-Post.md
@@ -0,0 +1,287 @@
+---
+title: How to Create a New Blog Post?
+date: 2019-11-22
+authors:
+ - hueser
+layout: blogpost
+title_image: default
+categories: [tutorials]
+tags: [startblogging, guidedtour]
+additional_css:
+ - 2019-11-22-Workflow-to-Create-a-new-Blog-Post/create_blog_post.css
+excerpt:
+ Nice project web page, how can I contribute with my own blog post?
+ This is what this blog post is about.
+ I will explain the workflow of “how to create a new blog post” and
+ thereby illustrate how to use the tools Git, GitLab and Jekyll
+ for these purposes.
+---
+
+## TL;DR
+
+{:.summary}
+_Nice project web page, how can I contribute with my own blog post?_
+This is what this blog post is about.
+I will explain the workflow of "how to create a new blog post" and
+thereby illustrate how to use the tools _Git_, _GitLab_ and _Jekyll_
+for these purposes.
+
+There are minimal requirements for a blogger to add a new blog post
+while a proper review process is still essential for the quality of
+the blog posts.
+So let us jump into it.
+
+Note:
+In case you are interested to know how to contribute
+to _HIFIS Software_ web-page in general besides writing blog posts
+you can find more information in the Contribution Guide
+<sup>[[1]](https://gitlab.hzdr.de/hifis/software.hifis.net/blob/master/CONTRIBUTING.md "Contribution Guide")</sup>.
+
+## Tools explained
+
+First, I would like to introduce three tools which are very helpful
+if you are going to write a blog post.
+
+**Version Control System _Git_**
+
+_Git_
+<sup>[[2]](https://en.wikipedia.org/wiki/Git "Git (Wikipedia)")</sup>
+is a decentralized version control system which lets you
+store all files of your project and all snapshots / versions
+of your changes.
+It lets you track back the complete history
+with your log messages given.
+Decentralized means the whole repository resides as a copy on your
+local computer.
+
+**Version Management Platform _GitLab_**
+
+_GitLab_
+<sup>[[3]](https://en.wikipedia.org/wiki/GitLab "GitLab (Wikipedia)")</sup>
+provides you with user interfaces for several actions which can be
+done on the remote server without downloading the whole repository
+onto your local computer.
+There is also an issue tracker included.
+On top, there is a full _Web IDE_ available which also let you review
+changes by your colleagues.
+Even if you are new to _Git_, the _GitLab Web IDE_ offers an easy
+interface which can be employed for most of your Use Cases.
+There is no need to install _Git_, download the _Git_ repository to
+your local machine and set up your own IDE
+to contribute with your blog posts.
+
+**Static Web Site Generator _Jekyll_**
+
+_Jekyll_
+<sup>[[4]](https://en.wikipedia.org/wiki/Jekyll_(software) "Jekyll (Wikipedia)")</sup>
+is a static web site generator.
+You only write _Markdown_ text files and _Jekyll_ takes care of the
+rest and generates a static web site containing only HTML and CSS
+according to your templates and layouts given.
+
+## Workflow in a Nutshell
+
+Now that we know more about the tools used, I would like to introduce
+the steps I took to create this blog post.
+You can stick to these steps if you are writing your own blog post:
+
+1. Share, discuss or pick a post idea
+2. Write and share your post
+3. The review process
+4. Your post is online
+
+By agreeing to this process we put you into the position of a
+fully authorized and equitable team member who is able to actually
+easily contribute with your own work to this web page.
+
+On closer inspection, there are the following persuasive arguments
+to use _Git_, _GitLab_ and _Jekyll_:
+
+* You can collaborate with different authors and reviewers using a
+decentralized version control system like _Git_.
+* There is a full traceback and logging functionality included in _Git_.
+* _GitLab_ lets you review, discuss and improve what you write in
+a well thought-out review process called _Merge Request_.
+* _GitLab Web IDE_ is actually a surrogate for a local IDE with
+_Git_ integration.
+* _GitLab CI Pipelines_ make sure and check that all is still
+working as expected.
+* With _Jekyll_ you just need to know very few syntactic markdown
+features, there is no need to write your own HTML and CSS.
+
+Finally, to make a clear statement ...
+**_you don't end up in a mess with multiple versions of
+a document floating around on local computers of
+several contributors._**
+
+## Going into Details - a Step-by-step Guided Tour
+
+**1. Share, Discuss or Pick a Post Idea**
+
+First of all, you need some sound ideas regarding the topic you would
+like to blog about.
+
+Open a new issue in the _GitLab UI_.
+In order to do so, you need an account in GitLab of HZDR
+<sup>[[5]](https://gitlab.hzdr.de "HZDR GitLab Instance")</sup>
+and being added as member to the respective GitLab project.
+Opening an issue is explained in the _GitLab Docs_
+<sup>[[6](https://docs.gitlab.com/ce/user/project/issues/managing_issues.html "Managing GitLab Issues")</sup>.
+It is essential to give it a comprehensive _title_ and _description_
+which reflects the basic idea of the topic.
+It is recommended to use the predefined _Issue Template_ "_blog-post_"
+which guides you through the important questions that need to be
+answered in order to start a fruitful discussion.
+By doing so you let us know what you would like to write about.
+Assign this issue to the main blog author (which usually is
+yourself).
+If you use the template this will be done automatically for you.
+The images below show such a blog-post issue as well as the
+pre-defined description text and questions to answer.
+
+{:.blog_post_template_image}
+
+{:.blog_post_template_image}
+
+**2. Write and Share your Post**
+
+The next step is to create a Feature Branch based on branch _master_
+and give it a meaningful name like `<issue_number>-<branch_name>`.
+This can be done within the _GitLab User-Interfaces_
+<sup>[[7]](https://docs.gitlab.com/ce/user/project/repository/web_editor.html#create-a-new-branch "Create a new Branch in GitLab")</sup>.
+
+Navigate into this branch in _GitLab_ and open _GitLab Web IDE_
+<sup>[[8]](https://docs.gitlab.com/ce/user/project/web_ide/#open-the-web-ide "Open GitLab Web IDE")</sup>.
+_GitLab Web IDE_ is the preferred tool to contribute if you are
+unfamiliar with _Git_.
+
+Notice the file system tree on the left hand side of the _Web IDE UI_.
+You can find a template for your blog post in folder `_posts/<year>/<month>`.
+The file name is _2019-10-29-Blog-Post-Template.md_.
+Feel free to copy it, give it a name according to the pattern
+`YYYY-MM-DD-My-post-title.md`, put your new file into folder `_posts/<year>/<month>`,
+and use it for your own purposes.
+The template explains the so called _Frontmatter_ which contains
+variables like `title`, `date`, `authors`, etc.
+Additionally, the most important markdown is explained by example
+within the template as well.
+Of course you want to remove the explanations and examples except for
+the _Frontmatter_ at the top of your markdown file.
+
+Another helpful feature of the _GitLab Web IDE_ is the
+_Preview Markdown_ pane.
+You can check that everything you wrote is displayed as intended.
+
+Now you are ready to start writing your _Markdown_ file following the specific
+syntax of _Markdown_ files
+<sup>[[9]](https://docs.gitlab.com/ce/user/markdown.html "GitLab Markdown")</sup>.
+
+Once you are done with your editing you would like to _stage_ and _commit_
+your changes
+<sup>[[10]](https://docs.gitlab.com/ce/user/project/web_ide/#stage-and-commit-changes "Stage and Commit Changes in GitLab Web IDE")</sup>
+giving it a meaningful message explaining your changes.
+There is a blog post
+<sup>[[11]](https://chris.beams.io/posts/git-commit/ "Best Practice of Git Commit Messages")</sup>
+about best practices for writing _Git_ commit messages.
+The more verbose your messages are, the easier it is for others
+to understand your changes.
+
+**3. The Review Process**
+
+After some effort and a few commits, let us assume your blog post
+is in a state where you consider it ready to see the light of day.
+What you want to do at this point is to open a _Merge Request_
+<sup>[[12]](https://docs.gitlab.com/ce/user/project/merge_requests/ "Merge Request")</sup>.
+_GitLab's User-Interface_ lets you open _Merge Requests_
+<sup>[[13]](https://docs.gitlab.com/ce/user/project/merge_requests/creating_merge_requests.html "Creating a Merge Request in GitLab")</sup>.
+Give it a meaningful title and description and mention the
+original issue as well (e.g. by stating `Closes #<issue_number>.` in
+the description).
+
+Assign your _Merge Request_ to one or multiple persons you would
+like to review the blog post.
+This is an important quality gate.
+Do not rely on reviewing your own work.
+Please select at least one other reviewer.
+
+In order to make the review process as easy as possible GitLab
+offers a feature called _Review Apps_ to inspect your branch.
+This enables the blog post authors as well as reviewers to preview
+the page in a test environment.
+As soon as your your branch is pushed onto the remote
+repository and the _GitLab CI Pipeline_ responsible for
+deploying your branch finished successfully,
+you can inspect your latest deployments of your branch
+by clicking the button _View app_ in the User-Interface of your
+Merge Request.
+
+{:.review_apps_button}
+
+To access these pages you need to authenticate.
+The credentials are as follows:
+Username: `hifis`, Password: `HIFISReview!`.
+
+As soon as someone reviews your blog post, all comments on your
+_Merge Request_ appear as separate discussion threads which need
+to be resolved by the reviewers before they can actually merge your
+changes into branch _master_.
+This means that you first discuss and integrate the suggestions into
+your post as well as secondly add and commit changes to your branch.
+
+All opened discussion threads need to be resolved and closed manually
+in GitLab before the final merge can take place by the reviewer.
+
+Now, the reviewer finds a button "_Merge_" in that _Merge Request_ in
+_GitLab_.
+This tells _GitLab_ to integrate your changes into branch _master_.
+
+By clicking that button a _GitLab CI (Continuous Integration) Pipeline_
+<sup>[[14]](https://docs.gitlab.com/ce/ci/introduction/index.html "GitLab CI (Continuous Integration) Pipeline")</sup>
+is started and makes checks whether _Jekyll_ can still build the
+whole project.
+In case all is fine, this is indicated by a success icon.
+
+If the original issue has been referenced by `Closes #<issue-number>.`
+the mentioned issue will be closed now.
+Likewise, if the corresponding checkbox
+"_Delete source branch when merge request is accepted._"
+has been checked on creation of the _Merge Request_ in the
+_GitLab User-Interface_ the source branch will be deleted as well.
+Finally, the _Merge Request_ will be closed and marked as _merged_.
+
+**4. Your Post is Online**
+
+Now your post is integrated and online.
+Well done!
+
+That was fairly easy.
+Wasn't it?
+You have all the advantages of _Git_, _GitLab_ and _Jekyll_
+at your disposal for quickly creating markdown-based blog posts
+of the highest quality.
+
+If you are looking for a good _Git_ tutorial I would like to suggest
+the one from the _Software Carpentry_ group
+<sup>[[15]](http://swcarpentry.github.io/git-novice/ "Software Carpentry Git Lessons")</sup>.
+
+_So what are the topics you would like to talk about today?_
+Give it a try and let us know what your thoughts are which
+you would like to share with us.
+
+## References
+
+* [[1]](https://gitlab.hzdr.de/hifis/software.hifis.net/blob/master/CONTRIBUTING.md "Contribution Guide") Contribution Guide
+* [[2]](https://en.wikipedia.org/wiki/Git "Git (Wikipedia)") Git (Wikipedia)
+* [[3]](https://en.wikipedia.org/wiki/GitLab "GitLab (Wikipedia)") GitLab (Wikipedia)
+* [[4]](https://en.wikipedia.org/wiki/Jekyll_(software) "Jekyll (Wikipedia)") Jekyll (Wikipedia)
+* [[5]](https://gitlab.hzdr.de "HZDR GitLab Instance") HZDR GitLab Instance
+* [[6]](https://docs.gitlab.com/ce/user/project/issues/managing_issues.html "Managing GitLab Issues") Managing GitLab Issues
+* [[7]](https://docs.gitlab.com/ce/user/project/repository/web_editor.html#create-a-new-branch "Create a new Branch in GitLab") Create a new Branch in GitLab
+* [[8]](hhttps://docs.gitlab.com/ce/user/project/web_ide/#open-the-web-ide "Open GitLab Web IDE") Open GitLab Web IDE
+* [[9]](https://docs.gitlab.com/ce/user/markdown.html "GitLab Markdown") GitLab Markdown
+* [[10]](https://docs.gitlab.com/ce/user/project/web_ide/#stage-and-commit-changes "Stage and Commit Changes in GitLab Web IDE") Stage and Commit Changes in GitLab Web IDE
+* [[11]](https://chris.beams.io/posts/git-commit/ "Best Practice of Git Commit Messages") Best Practice of Git Commit Messages
+* [[12]](https://docs.gitlab.com/ce/user/project/merge_requests/ "Merge Request") Merge Request
+* [[13]](https://docs.gitlab.com/ce/user/project/merge_requests/creating_merge_requests.html "Creating a Merge Request in GitLab") Creating a Merge Request in GitLab
+* [[14]](https://docs.gitlab.com/ce/ci/introduction/index.html "GitLab CI (Continuous Integration) Pipeline") GitLab CI (Continuous Integration) Pipeline
+* [[15]](http://swcarpentry.github.io/git-novice/ "Software Carpentry Git Lessons") Software Carpentry Git Lessons
diff --git a/_posts/2019/12/2019-12-11-SWC-Workshop-at-GFZ.md b/_posts/2019/12/2019-12-11-SWC-Workshop-at-GFZ.md
new file mode 100755
index 0000000000000000000000000000000000000000..5dee7f66b4e352a0c6c71fb8255bc8f9f0168863
--- /dev/null
+++ b/_posts/2019/12/2019-12-11-SWC-Workshop-at-GFZ.md
@@ -0,0 +1,96 @@
+---
+title: SWC workshop at GFZ-Potsdam
+date: 2019-12-11
+authors:
+ - dolling
+layout: blogpost
+title_image: default
+excerpt_separator: <!--more-->
+categories:
+ - report
+tags:
+ - workshop
+ - carpentries
+additional_js:
+ - mathjax.js
+excerpt:
+ In November the first HIFIS related Software Carpentry Workshop was held.
+ <em>How hard could it be?</em>
+---
+
+# The First Workshop
+
+### TLDR
+
+{:.treat-as-figure}
+
+Taken from [https://xkcd.com/1658/](https://xkcd.com/1658/) and licensed under
+[<i class="fab fa-creative-commons fa-lg"></i>
+<i class="fab fa-creative-commons-nc-eu fa-lg"></i>
+<i class="fab fa-creative-commons-by fa-lg"></i>](https://creativecommons.org/licenses/by-nc/2.5/
+"Creative Commons Attribution-NonCommercial 2.5 License").
+
+In November 2019 the first HIFIS related Software Carpentry Workshop was held.
+_How hard could it be?_
+
+When I first took a look into [The Carpentries](https://carpentries.org/),
+I thought: "Organizing a workshop about stuff I know - how hard can it be?"
+But because the whole _The Carpentries_ idea was new to me, I wanted to
+get some more information.
+Luckily we had some previous workshops at the Telegrafenberg, so I
+reached out to organizers and instructors of the previous ones.
+In summary they told me that it takes a lot of time to organize one and prepare properly.
+Okay — if you say so — I had no clue.
+
+My colleague and I started by finding a date and a room.
+Due to Christmas and the AGU conference we already realized that we had only
+two months to do it. Everything seemed fine.
+We met with the people that organized the workshops before to learn from their experience and get advice.
+Even after that, we where pretty confident: _that's a piece of cake_.
+
+Oh wow, were we wrong:
+* The possible instructors and helpers were volunteers[^1], have commitments and thus were partially available only.
+* The decision which lessons to teach depend on the availablility of instructors, so the dates, and finally available rooms.
+* However, even finding a room that works best took way longer than expected, and
+* The joint agreement of the lessons to teach and how to share the work load wasn't straight forward.
+
+Finally, we started registrations around three weeks before the workshop began - which, surprisingly, has been quite enough time in advance since the workshop was overbooked within a few days.
+
+[^1]: Thank you!
+
+Fortunately we had about 35 registrations for 30 seats.
+Lessons, staff and attendees were set a week before the workshop — _PHEW!_
+We expected issues cropping up days and hours before;
+They happend, but nothing to worry about.
+Somehow we maneuvered ourselfs pretty well in between the pitfalls.
+
+The only mentionable issue was, that quite a few registered people did not
+participate due to different reasons: Some of them canceled a few days and hours before
+because of other short-term commitments and others
+were not able to submit a SINGLE slide to introduce themselves and their work
+in a 60 seconds lightning talk - which has been the ticket to particpate in the workshop.
+I have seen all the slides, and many of them looked like they spend less than
+five minutes to quickly throw together generic pictures and five words, which
+we expected and totally suited for the purpose of the slide.
+However, some researchers were not able to invest these _five minutes_ for a free
+_two-days_ workshop. Instead others, people from the waiting list, got the opportunity and
+got the slides done on the same day they received the seat confirmation.
+
+## On the Workshop Itself
+
+In general, it was a great experience for all of us - the organizers, instructors,
+helpers, and importantly the participants.
+The lessons went well, some timing issues occured, but summarised everything was more or less
+as planned.
+From the feedback we got, the participants were happy and some of them even
+thanked us afterwards because they learned what they needed.
+One thing that we want to do better next time is staff planning.
+This time, we were overstaffed with helpers. All the time we were at least two instructors,
+plus two organizers and additionally three helpers, which is what we had in mind for approx. 30 participants.
+Unfortunately there were 18 participants only in the end.
+So somemetimes it felt like the helpers were circling around the participants in the hope of occurring problems.
+First of all, the people rarely had issues, considering all the new software
+and things to learn.
+
+I am looking forward to our next workshop in April 2020!
+
diff --git a/_posts/2019/12/2019-12-20-Welcome-Post.md b/_posts/2019/12/2019-12-20-Welcome-Post.md
new file mode 100644
index 0000000000000000000000000000000000000000..fcdc44ff9660ef68690886b3c79dab880ff7e0d7
--- /dev/null
+++ b/_posts/2019/12/2019-12-20-Welcome-Post.md
@@ -0,0 +1,117 @@
+---
+title: Welcome to HIFIS Software
+date: 2019-12-20
+authors:
+ - huste
+ - leinweber
+layout: blogpost
+title_image: photo-of-open-signage-2763246.jpg
+excerpt:
+ "We are very happy to announce the initial release of software.hifis.net:
+ the central platform for distributing information, promoting events and
+ offering tutorials and content concerning scientific software development
+ within Helmholtz."
+categories:
+ - blog
+tags:
+ - general
+---
+
+# Welcome to HIFIS Software
+We are very happy to announce the initial release of **software.hifis.net**:
+The central platform for distributing information, promoting events and
+offering tutorials and content concerning scientific software development
+within Helmholtz.
+
+## Who are we?
+HIFIS or Helmholtz Federated IT Services is one of 5 platforms initiated by
+the [Helmholtz Incubator][incubator] besides
+
+* [HIDA - the Helmholtz Information & Data Science Academy][hida-link],
+* [Helmholtz AI][haicu-link],
+* [HMC - the Helmholtz Metadata Collaboration Platform][hmc-link] and
+* [HIP - the Helmholtz Imaging Platform][hmc-link].
+
+HIFIS aims to install a secure and user-friendly collaborative environment
+offering information and communication technology services that are accessible
+from anywhere.
+The platform also supports the development of high-quality, secure, and sustainable
+research software.
+
+These objectives are implemented through three competence clusters:
+
+- The [Cloud Services Cluster][cloud-link] providing a federated platform for proven,
+ first-class cloud services,
+- A [Backbone Services Cluster][backbone-link] providing a powerful and reliable network
+ infrastructure with uniform basic services and
+- Us, the Software Services Cluster providing a platform, training, and support
+ for high-quality, sustainable software development.
+
+Our mission is to empower scientists of any domain to implement and to
+perpetuate modern scientific software development principles in order to make
+research software engineering more sustainable. Our core team is located in 5
+different Helmholtz Centers:
+
+- [DLR - German Aerospace Center][dlr]
+- [DKFZ - German Cancer Research Center][dkfz]
+- [GFZ - German Research Centre for Geosciences][gfz]
+- [HZDR - Helmholtz-Zentrum Dresden-Rossendorf][hzdr]
+- [UFZ - Helmholtz Centre for Environmental Research][ufz]
+
+Have a look into our [team page]({{ '/team' | relative_url }}).
+You will find an interactive map to see how we are spread over Germany.
+Since we aim to provide services for the **whole** Helmholtz Association,
+we would be more than happy, if **you** would like to act
+as our [contact person](#contact-us) in **your** Helmholtz center.
+Help us spread the word to make research software development more sustainable.
+
+## What are we going to offer?
+
+Please find that information on our [services page]({{ '/services/' | relative_url }}).
+
+Stay tuned! The first training events, services and materials
+will be announced there in early 2020.
+
+## How to get involved?
+
+Distributing information about services offered, upcoming training events or
+building Helmholtz-wide communities requires us to have **you** as a
+motivated contact person in your research center or research group who is
+willing to help in communicating and spreading the word about sustainable
+software development and HIFIS.
+
+By using a clearly defined version control workflow contributing is made easy for everyone.
+Therefore, you can [contribute to this website][gitlab-project].
+If your software project was improved by a HIFIS-provided training or advice,
+or want to share an interesting solution or use case,
+please feel free to write or re-blog a short post about it here.
+You can even add yourself to our team page as an associate.
+Our [Contribution Guide][contributing] explains how to contribute to *software.hifis.net*.
+
+You are also welcome to [tell us](#contact-us) your interest and we will keep you up-to-date about upcoming
+trainings, events and services in 2020 and forward.
+
+<div class="alert alert-success">
+ <h2 id="contact-us"><i class="fas fa-info-circle"></i> Contact us</h2>
+ <p>
+ Send a mail to
+ <strong>
+ <a href="mailto:{{ site.contact_mail }}">{{ site.contact_mail }}</a>.
+ </strong>
+ </p>
+</div>
+
+[incubator]: https://www.helmholtz.de/en/research/information-data-science/helmholtz-incubator/
+[hida-link]: https://www.helmholtz-hida.de/
+[haicu-link]: http://www.helmholtz.ai/
+[hmc-link]: https://www.helmholtz.de/en/research/information-data-science/helmholtz-metadata-collaboration-plattform-hmc/
+[hip-link]: https://www.helmholtz.de/en/research/information-data-science/helmholtz-imaging-platform-hip/
+[dlr]: https://dlr.de/sc
+[dkfz]: https://www.dkfz.de/
+[gfz]: https://www.gfz-potsdam.de/zentrum/escience-zentrum/ueberblick/
+[hzdr]: https://www.hzdr.de/
+[ufz]: https://www.ufz.de/
+[contributing]: https://gitlab.hzdr.de/hifis/software.hifis.net/blob/master/CONTRIBUTING.md
+[cloud-link]: https://www.hifis.net/mission/cluster-cloud.html
+[backbone-link]: https://www.hifis.net/mission/cluster-backbone.html
+[gitlab-project]: https://gitlab.hzdr.de/hifis/software.hifis.net