added software news posts 2020

_posts/2020/01/2020-01-07-contributing-in-4-simple-steps.md

+---
+title: Contributing in 4 Simple Steps
+date: 2020-01-07
+authors:
+  - erxleben
+layout: blogpost
+title_image: default
+categories:
+  - tutorial
+tags:
+  - example
+  - markdown
+excerpt:
+  Want to contribute? No time to read long tutorials?
+  Then this contribution quickstart guide is for <em>you</em>.
+additional_css:
+  - 2020-01-07-contributing-in-4-simple-steps/button-link.css
+---
+
+# What This Guide will (not) Cover
+
+This tutorial will teach you a quick way to get a basic blog post set up and
+published on [software.hifis.net](https://software.hifis.net).
+If you plan to write something bigger that might take several days to write up
+and refine, [Christian's Guide][ref1] is the better choice for you.
+
+The guide will not go into the details of fancy formatting and styling,
+however you might want to check the [Template Blog Post][ref2] for
+examples of common blogging tasks.
+Additionally, the [Kramdown Quick Reference][ref3] may prove helpful.
+
+_Okay, enough chit-chat, let's write a blog post!_
+
+# Step 1: Create an Issue
+
+By opening an issue you let the core team know what you are planning
+(which is a nice thing to do).
+It helps to gather the important information right from the start.
+
+{: .button-link}
+[Open a new issue on the HZDR Gitlab now][issue-link]
+
+Fill out the information as requested in the
+
+```
+>>>
+  Quotation blocks
+>>>
+```
+
+There is no need to set anything else, so you may now click the `Submit Issue`
+button.
+You will get redirected to the **issue page** that was just set up.
+Here you can lead a discussion with other contributors and the core team about
+your ideas or ask questions you have beforehand.
+It might be a good idea to bookmark it for later reference.
+Also note that your new issue has been assigned a unique **issue number** to
+identify it.
+
+On this **issue page** you will find the `Create merge request` button.
+Click it to continue to the next step.
+
+# Step 2: Set up the Basis
+
+_Gitlab_ now has set up a **merge request page** for you and — even more
+important — created a new _branch_ for your issue.
+
+> If you are not familiar with _git_ think of a _branch_ like your own version
+> of the project, where you can do whatever you like without worrying about
+> breaking anything on the live system.
+
+To avoid chaos and confusion, specific ordering and naming conventions have been
+established, dictating which files go into which folders.
+
+For that purpose you can click the `Open in Web IDE` button on the
+**merge request page**.
+This _Web IDE_ is like a small file browser and editor in one and all you need
+for the rest of the tutorial.
+
+## Everything in the Right Place
+
+Your blog post must be put into the folder `/_posts/YYYY/MM/` where `YYYY`
+is the 4-digit year, `MM` is the 2-digit month (and later we need `DD` for the
+2-digit day).
+If this path does not fully exist, you should now create it.
+
+{:.treat-as-figure}
+{: .float-left}
+![Dropdown Menu example]({{ site.directory.images | relative_url }}/posts/2020-01-07-contributing-in-4-simple-steps/create_folder.png)
+The dropdown-menu to create a new sub-folder becomes visible on hovering the
+parent folder.
+
+This is the folder in which your blog-post _per se_ will be located.
+If you want to include images, formulas or external resources a bit more has to
+be done.
+Please either refer to the [Blog post template][ref2] or ask
+`@software-hifis-net` for help in a comment on the **merge request page**.
+
+## Files
+
+Within your (probably newly created) folder you now create a file with your blog
+post.
+The file must be named after the pattern `YYYY-MM-DD-title-slug.md` where
+`YYYY`, `MM`, `DD` is the same as above and the `title-slug` is — surprise — a
+slugified version of your blog post title.
+
+> If you do not know, what _slugification_ is, do not despair: There is an
+> [online generator][slug-generator] that can do that for you.
+
+For comparison, the full path of this blog post looks like this:
+
+```
+/_posts/2020/01/2020-01-07-contributing-in-4-simple-steps.md
+```
+
+## Frontmatter
+
+When you select your newly created file in the _Web IDE_ it will instantly open.
+Copy the following block into the first lines and replace the parts in brackets.
+The lines with a leading `#` are comments and can safely be removed.
+
+```yml
+---
+title:  <Your post title as it appears on the website>
+date:   <Desired shown publication date as YYYY-MM-DD>
+authors:
+  - <Your team member ID (usually the last name in lower case)>
+# - <Repeat for each author>
+layout: blogpost
+title_image: default
+categories:
+  - <choose one of "blog", "announcement", "tutorial", "report">
+# You can come up with a new category if none of the above fits,
+# but please consult the team beforehand
+tags:
+  - <Short free text>
+# - <Repeat for each tag>
+excerpt:
+  <One or two lines that serve as a preview text in the blog post overview>
+---
+```
+
+This chunk of text is called the _frontmatter_ and helps our website backend to
+recognize the following text as a blog post and generate all the nice things
+around it.
+
+# Step 3: Add Content
+
+Leave an empty line behind the _frontmatter_ and then write to your heart's
+content.
+While the _gitlab_ _Web IDE_ only highlights the vanilla _Markdown_ syntax, our
+blog system actually understands the far mightier _Kramdown_ dialect, so you can
+use everything in [The Kramdown Quick Reference][ref3].
+
+Once you started to make changes the `Commit` button appears.
+If you click it, the view changes:
+
+* The _Unstaged Changes_ and _Staged Changes_ appear on the left side
+* A comparison view occupies the center and right side
+
+{: .float-left}
+{% include video.html
+    path="2020-01-07-contributing-in-4-simple-steps/commit_demo.webm"
+    caption="Making a <em>commit</em> on the WebIDE.<br/>
+    Note the two clicks on the <em>commit</em> button."
+%}
+
+1. Your file appears in the _unstaged changes_.
+2. Double click it to move it to _staged changes_
+(Double clicking it again will move it back to _unstaged changes_).
+3. Click `Commit` once more and enter a meaningful message what your last
+changes were.
+4. Click `Commit` a final time.
+
+Your changes are now stored as a _commit_ (think of it as a permanent checkpoint) on your _branch_ in the _repository_.
+
+### Side Notes
+
+> If you want to continue editing (or abort making a commit), you can switch
+> back to the _editing view_ with the button on the far left side under the
+> project logo.
+
+> The whole _staging changes_ mechanic seems a bit excessive if there is only
+> one file involved, but becomes a boon in more complex scenarios.
+> You can abbreviate the process a bit by leaving out step 2.
+> The button for step 3 then is called `Stage & Commit`.
+
+> Please end your document with one(!) empty line.
+> It will not show up in the final result, but makes a lot of tools involved in
+> the review process very happy.
+
+# Step 4: Get it Reviewed
+
+So you finished your work, and now it is time for it to be presented to the
+whole wide world.
+
+But wait! Have you missed anything? Is everything as it should be?
+
+To make sure, it is customary to have your blog post reviewed beforehand.
+You can start by going to the **merge request page**.
+
+The super-fast way of triggering the process is to simply leave the
+following magic comment:
+
+```
+@software-hifis-net: Review please.
+/label ~"Progress::Can review"
+/assign @software-hifis-net 
+/wip
+```
+
+Adding Emojis for accelerated response time is optional.
+
+A core team member will get back to you and start looking into the matter.
+They might suggest changes and will help getting the visual appearance right.
+Your blog post will soon see the light of day.
+
+Well done!
+
+[ref1]: {% post_url /2019/11/2019-11-22-How-to-Create-a-new-Blog-Post %}
+[ref2]: {% post_url /2019/10/2019-10-29-Blog-Post-Features %}
+[ref3]: https://kramdown.gettalong.org/quickref.html
+
+[issue-link]: https://gitlab.hzdr.de/hifis/software.hifis.net/issues/new?issuable_template=blog-post
+[slug-generator]: https://blog.tersmitten.nl/slugify/

_posts/2020/01/2020-01-28-software-policy-template.md

+---
+title: The Software Policy Template
+date: 2020-01-28
+authors:
+  - huste
+layout: blogpost
+title_image: mountains-nature-arrow-guide-66100.jpg
+excerpt:
+  <p>In a joint effort of the <em>Task Group Research Software</em> 
+  within the scope of the <em>Helmholtz Open Science Office</em> 
+  a software policy template was created.</p>
+  <p>This model policy should serve as a guideline and reusable blueprint for
+  the creation of regulations for a sustainable use and development of
+  research software in the individual Helmholtz centers.</p>
+categories:
+  - guidelines
+tags:
+  - general
+---
+
+In a joint effort of the [Task Group Research Software][taskgroup] within the
+scope of [Helmholtz Open Science][openscience] a
+[software policy template][policy][^1] was created and published.
+This model policy should serve as a guideline and reusable template for the
+creation of regulations for a sustainable use and development of research
+software in the individual Helmholtz centers.
+The template is accompanied by a [position paper][recommendations][^2] providing
+recommendations for the implementation of these guidelines for the treatment of
+research software at the Helmholtz centers.
+
+## How Do These Guidelines Help Me as a Researcher?
+The processing of research data and the acquisition of scientific knowledge
+require the development and use of high-quality and sustainable software
+solutions. 
+
+It is clear that the verifiability and reproducibility of scientific
+results can only be guaranteed if research software is treated under
+defined conditions.
+
+Such software is to be considered a central and independent scientific
+product. 
+It needs to be handled according to similar high-level standards that
+is already applied for other scientific methods.
+
+The software policy template is here to help your research center to define
+standards, guidelines, best practices as well as affirmative actions to give
+sustainable research software development the significance it deserves.
+At the same time it supports _you_ by defining guidelines and rules that you can
+rely upon.
+It also aids in promoting the use of software development best practices by
+providing you with the appreciation you deserve.
+
+## How Will HIFIS Support the Implementation of This Template?
+HIFIS will provide practical information for you, as a researcher, on how to
+implement the requirements in your research projects.
+At the same time, the educational program will also be aligned with the
+requirements defined in this template.
+HIFIS would also be happy to guide the individual centers in transforming the
+template into local guidelines.
+
+## Referenced Documents
+[^1]: The Software Policy Template;
+      [<i class="fas fa-file-pdf"></i> 10.2312/os.helmholtz.007][policy-doi]
+      (currently only available in German)
+
+[^2]: The position paper "Recommendations for the Implementation of Guidelines
+      for the Treatment of Research Software at the Helmholtz Centres";
+      [<i class="fas fa-file-pdf"></i> 10.2312/os.helmholtz.008][recommendations-doi]
+      (currently only available in German)
+
+[taskgroup]: https://os.helmholtz.de/de/open-science-in-der-helmholtz-gemeinschaft/akteure-und-ihre-rollen/arbeitskreis-open-science/task-group-forschungssoftware/
+[openscience]: https://os.helmholtz.de
+[policy]: https://os.helmholtz.de/index.php?id=3951
+[policy-doi]: https://doi.org/10.2312/os.helmholtz.007
+[recommendations]: https://os.helmholtz.de/index.php?id=3197
+[recommendations-doi]: https://doi.org/10.2312/os.helmholtz.008

_posts/2020/11/2020-11-07-survey-results-language-vcs.md

+---
+layout: blogpost
+title: "HIFIS Survey 2020: Programming, CI and VCS"
+date: 2020-11-27
+authors:
+    - erxleben
+title_image: default
+categories:
+    - report
+---
+
+## Introduction
+In the beginning of 2020 the HIFIS team conducted a survey among Helmholtz
+scientists with the goals of learning more about the current practices
+concerning research software development and identifying future challenges.
+
+This blog post will present a glimpse into the survey's results and our take
+on the gathered data.
+Specifically, we will take a look at the distribution of programming languages
+across the different research fields as well as the utilization of
+_Version Control Systems_ (VCS) in the same context.
+Last, a short insight into the prevalence of various
+_Continuous Integration_ (CI) systems will be given to round out this blog
+post.
+
+## Programming Languages
+
+We asked the survey participants which programming languages they regularly
+used for writing research software.
+The following heatmap displays the relative usage of the most predominant programming languages for each research field
+
+{:.treat-as-figure}
+![Plot: Languages by Research field]({{ site.directory.images | relative_url }}/posts/2020-11-07-survey-results-language-vcs/plot_language_by_field_normalized.svg)
+
+All presented numbers are the relative usage of a given language in a given
+field.
+They might not always add up to exactly 1.00 per field or per language due to
+multiple factors:
+
+* Some participants did not answer both questions.
+  These answers are not represented in the plot.
+* Languages that had not at least a _5%_ share in at least one field were
+  omitted to focus on the most prominent ones and make the graphic easier to
+  read.
+
+### What can We Learn?
+
+The first thing that catches the eye is that Python seems to be very dominant
+in every research field.
+We have to take this appearance with a slight grain of salt since the survey did
+not distinguish between the outdated, but generally popular, Python 2 and
+the current Python 3.
+The popularity of the language amongst researchers is not very surprising:
+They are well suited for quickly creating small scale scripts, combined with
+an extensive choice of libraries for many use cases.
+
+Consequently, our education and training efforts will continue to provide
+offers regarding programming in Python and create appropriate courses and
+materials to further the knowledge and best practices in this language amongst
+scientists and research software developers.
+
+Regarding consultations we expect the team to receive requests regarding the
+porting of older Python 2 applications to Python 3, as well as support
+requests for dealing with the variance of virtual environments and package
+management for this language.
+
+A second language often selected was C++ which often is a popular choice in
+high performance computing and larger applications.
+
+This indicates a potential demand for supporting this language in the future as
+well, especially in the context of training as well as consulting.
+
+Notable further mentions would be the the strong presence of the statistics
+language R in the _Health_ and _Earth and Environment_  research fields,
+which implies the opportunity for education and consulting being tailored and
+advertised more towards these areas.
+
+## Version Control systems
+
+Similarly to the question above, a second question was analyzed, concerning the
+usage of _Version Control Systems_ (VCS) amongst the participants related to
+specific fields of research.
+
+{:.treat-as-figure}
+![Plot: VCS Usage by Research field]({{ site.directory.images | relative_url }}/posts/2020-11-07-survey-results-language-vcs/plot_vcs_per_field.svg)
+
+The strong prevalence of Git is apparent at first glance.
+As a runner-up there are still some projects out there based on SVN for
+version control, which - together with a few mentions of CVS - might be an
+indicator for older, longer living projects.
+The amount of projects not using any version control at all is comparatively
+low, which points toward the usage of VCS being an established step in setting
+up projects across all research fields.
+
+From an education perspective it appears to be the right way to continue to
+focus on basic and advanced Git-courses and promote version control as one of
+the standard practices in every scientists toolbox.
+It can be expected that the consulting team might face requests for help with
+migrating projects from SVN or CVS to Git in the future.
+
+## Continuous Integration
+
+As a third question we wanted to know which _Continuous Integration_ (CI)
+services the participants use to automate tasks surrounding their projects.
+This, again, was a multiple choice question and the following plot shows the
+relative distribution of the given answers:
+
+{:.treat-as-figure}
+![Plot: Overall CI Usage]({{ site.directory.images | relative_url }}/posts/2020-11-07-survey-results-language-vcs/plot_ci_service_usage.svg)
+
+One very prominent outcome is that over half of the participants did claim to
+not use any CI at all.
+Several possible reasons for this finding come to mind:
+* The question was not clear enough and participants who actually use CI were
+  not aware of that fact.
+* Participants are not aware that CI exists.
+* Participants do not see any potential benefit of CI for their projects.
+* Participants do not know how to set up and use CI.
+
+Given that practically any project can benefit from employing
+_Continuous Integration_ services by automating at least the mundane management
+tasks like license checking, documentation generation, style checks, etc. all
+four given reasons can be assumed to be a lack in awareness and education.
+
+Further, the plot reveals that the currently used CI solutions are (in
+descending order of percentage) _GitLab CI_ which holds over a quarter of all
+shares, _Jenkins_ and _Travis CI_ with all other services being barely
+represented.
+
+Building on the insights from this analysis, three actions clearly stand out to
+improve CI usage across all projects:
+* The education team will have to increase their portfolio and offer more
+  courses centered around CI usage.
+* The popularity of _GitLab CI_ will likely increase the demand to migrate
+  other projects to this system. It will fall to the consulting branch to be
+  prepared to deal with such requests.
+* The technology team has already begun to offer pre-made recipes for CI
+  pipelines and has an incentive to grow the collection of ready-to-use solutions
+  for popular scenarios.
+
+## Conclusion
+
+Thanks to the participants of the HIFIS survey in 2020 it was possible to gain
+a first glimpse into the status quo of research software engineering within the
+Helmholtz centers. With this data, the needs of the scientists could be assessed
+from a birds-eye perspective and it is possible to determine concrete steps to
+offer better support for the scientists at Helmholtz.
+
+