Adapt ReadMe according to template

[MarionBWeinzierl]

ICCS ReadMe structure template:

Readme and Essential Repo Information

The Readme is a vital document as it is the first impression that users and potential developers get of a piece of code. There are lots of resources online that describe templates for GitHub repos. The following is a suggested structure. Note that while it is advised that the Readme covers each of these items it is possible to link out to other places in the software documentation.

• Overview of Software: This should be a statement of intent and answer the question "What is this software's purpose?" i.e. What does the software do.
• Project Status: Status of the software with respect to its development and release. I.e. Is the software in active development. Is the software released or pre-released. Are aspects of the software experimental.
• Requirements and Environment: List the requirements or dependencies of the software and detail the process of how to obtain/install them. If using containerisation then this should be described here. If the software is available from a package index or channel then include the details but also include details on how to install from source for development.
• Installation
• Usage/Quick start guide: Getting started with the software.
• Documentation and Support: Are there any of the following for the software;
  • User Guide: More extensive documentation on using the software and its features
  • Help or Discussion: How does a user seek help for the software. E.g. Should they raise an issue (tagged with a specific label), is there a GitHub discussions feature or an external system such as Slack.
  • Website: Is there a promotional website for the software (i.e. not a documentation site).
• Building: Including build options. For example if using CMake this might include a tabular description of Configure or target options.
• Contributing: Clear guidelines should be described on what the process is for contributing (see Contribution Guidelines section). This may include a code of conduct which describes expectations of behaviour.
• Authors and Acknowledgement: GitHub does a reasonable job of logging contributions (by line or commits) but acknowledgement section is a good place to highlight core contributors or funders. Ideally Any repository with contributions from ICCS should have an acknowledgement with a link back to our site. If the software has a paper or DOI that should be used for citations then it should be listed here. Ideally a CITATION.cff file should be used to provide citation metadata. A cff file will also play nicely with Zenodo for release DOIs.
• Licence: The code should have a licenced attached. There are many discussions about the best licence but assuming your code is to be open source, not copy-left and have permissible terms, MIT is a good choice. Note: Always confirm in writing from the PI or original author that they are happy with a licence before attaching it to code!

• Known Issues: Version specific issues should be noted in the release notes for specific versions. More general known issues and limitations can be included in the readme, possibly with links to issues where they are discussed. If there is external documentation then it can be appropriate to linked to this instead.

  There are other items that may be included in a readme such as development and release plans but these are not essential.

[MarionBWeinzierl]

I think that, in the current version, a large proportion of this is already covered by the readme, the contributing.md, etc

[MarionBWeinzierl]

Duplicate of #94