Ending documentation¶
Questions
- How can the user understand how to run your program and what it does?
Learning objectives of 'Documentation'
learners
- I know the most important sections for a full public README
- I can make citation info
- I know how to find instruction of going to more sophisticated documentation
Content
-
content of readme
- installation
- get started
- test
- citation
-
Revisit licence
-
Update a Doc Index
- View other possibilities
- Wiki
- GitHub pages/ReadTheDocs
- MkDocs/sphinx
Revisiting documentation¶
Documentation comes in different forms
- What is documentation?
- Tutorials: learning-oriented, allows the newcomer to get started
- How-to guides: goal-oriented, shows how to solve a specific problem
- Explanation: understanding-oriented, explains a concept
- Reference: information-oriented, describes the machinery
- In-code documentaion — docstrings Not to forget
- Project documentation:
- requirements: what is the goal of the software, risks, platforms
- the analysis: pseudocode and UML
- risk analysis
There is no one size fits all: often for small projects a README.md
or
README.rst
can be enough (more about these formats later).
Where are we?¶
DONE
- ☑ in-code documentation
- ☑ Project documentation:
- requirements: what is the goal of the software, risks, platforms
- the analysis: pseudocode and UML
- risk analysis
Finalize today
- ☐ README
- ☑ installation instruction
- ☐ Tutorial: get started
- ☐ citation
Further documentation for future projects
- ☐ License
- ☐ Tutorials: learning-oriented, allows the newcomer to get started
- ☐ How-to guides: goal-oriented, shows how to solve a specific problem
- ☐ Explanation: understanding-oriented, explains a concept
- ☐ Reference: information-oriented, describes the machinery
The README¶
Example content¶
- About
- Installation (with dependencies and testing)
- Get started
- Use cases
- Citation
About¶
- About the software
- What does it do?
- One (Punch-)line describing what it does.
- Also in GitHub in upper right corner!
- More information below below the first description
Install¶
- We covered this in last session
Get started¶
- This session can be "running some test data" to get an overview of what the program can perform.
- It may describe how to get test data
- Example: https://github.com/KamilSJaron/smudgeplot/tree/v0.3.0?tab=readme-ov-file#runing-this-version-on-sacharomyces-data
Use cases¶
-
This may sometimes be merged with the previous section
-
How-to guide: goal-oriented, shows how to solve a specific problem
- May be a sub-set of the most important commands, depending on how wide the program is.
- Example: https://github.com/KamilSJaron/smudgeplot/tree/v0.3.0?tab=readme-ov-file#runing-this-version-on-sacharomyces-data
would it be needed for your project?
Contributions¶
- How to contribute?
- Example: https://github.com/KamilSJaron/smudgeplot/tree/v0.3.0?tab=readme-ov-file#runing-this-version-on-sacharomyces-data
Acknowledgements¶
- Add references that inspired or added algorithms to your code
- Example: https://github.com/KamilSJaron/smudgeplot/tree/v0.3.0?tab=readme-ov-file#acknowledgements
References/Citation¶
- Think the same as for a scientific paper
Practical recommendations:
- Get a DOI using Zenodo or similar services.
- Open source license can't demand citation, but it is required by science ethics anyway.
- Make it as easy as possible! Clearly say what you want cited.
- Make it easy for scripts and tools, use the Citation File Format.
- GitHub now supports CITATION.cff files
This is an example of a simple CITATION.cff
file:
cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
- family-names: Druskat
given-names: Stephan
orcid: https://orcid.org/0000-0003-4925-7248
title: "My Research Software"
version: 2.0.4
doi: 10.5281/zenodo.1234
date-released: 2021-08-11
Recommended format for software citation is to ensure the following information is provided as part of the reference Katz, Chue Hong, Clark, 2021:
- Creator
- Title
- Publication venue
- Date
- Identifier
- Version
-
Type
-
Digital object identifiers (DOI) are the backbone of the academic reference and metrics system.
-
CodeRefinery has an exercise to see how to make a GitHub repository citable by archiving it on the Zenodo archiving service. If you are interested, have a look here
-
Example: https://github.com/KamilSJaron/smudgeplot/tree/v0.3.0?tab=readme-ov-file#reference
Example
- R: https://github.com/KamilSJaron/smudgeplot/tree/v0.3.0?tab=readme-ov-file#install-the-whole-thing
- Conda: https://github.com/biobakery/MetaPhlAn
- pip: https://github.com/deeptools/HiCExplorer
- pip: https://github.com/caleblareau/mgatk?tab=readme-ov-file
- binaries/executable: https://github.com/dougspeed/LDAK?tab=readme-ov-file#how-to-obtain-ldak
Exercise¶
Intro
- Revisit
README-ext.md
and update it with info after all our commits- About
- Citing
- Lastly, you may, if time allows, update the doc/index.md file that should describe the content
- Do a
git pull
to have the same version of your project repo locally!
Update your documentation in groups
- You can now work in GitHub directly
-
Do
git push
first from local command-line! -
We already have a file called
README.md
, that is used for information for the course participants. - Let's continue to work with the
README-EXT.md
we used in last session.
Group 1: Work together and formulate an 'About' section
Group 2: Work together and formulate 'Getting started' section
Group 3: Work together and formulate 'Citation' section
Discussion¶
Discussion: Describe what you've done and why?
Licensing¶
See also
Going further with documentation¶
See also
Wikis¶
- Popular solutions (but many others exist):
- Also on GitHub!
- About wikis
- Adding or editing wiki pages
- Example with WRF weather model
HTML static site generators¶
There are many tools that can turn RST or Markdown into beautiful HTML pages:
- Sphinx
- Generate HTML/PDF/LaTeX from RST and Markdown.
- Read the docs style
- HICexplorer documentation
- Jekyll
- Generates HTML from Markdown.
- GitHub supports this without adding extra build steps.
- MkDocs ← we will exercise this, this is how this lesson material is built
- Generates HTML from Markdown.
- Example: Programming formalisms course
There are many more ...
Deployment on servers¶
GitHub, GitLab, and Bitbucket make it possible to serve HTML pages:
- GitHub Pages (GH-pages) ← this is what we and many others use for course and tutorial material
- Bitbucket Pages
- GitLab Pages
- Read the docs ← this is what NBIS uses for some course material
- hosts public Sphinx documentation for free!
- Example: NBIS Introduction to Git
GitHub pages¶
- Easiest. Everything is local to GitHub
- This lesson material
Read the Docs¶
- Somewhat more possibilities, like having several versions of documentation to switch between.
What contributes to reusability?¶
What contributes to you being able to reuse stuff that others make, and others (or you) being able to reuse your stuff? When you find a repository with code you would like to reuse, you may look at the following things to determine its reusability:
Note
- Date of last code change
... is the project abandoned?
- Release history
... how about stability and backwards-compatibility?
- Versioning
... will it be painful to upgrade?
- Number of open pull requests and issues
... are they followed-up?
- Installation instructions
... will it be difficult to get it running?
- Example
... will it be difficult to get started?
- License
... am I allowed to use it?
- Contribution guide
... how to contribute and decision process?
- Code of conduct
... how to make clear which behaviors are unacceptable and discouraged? How violations of Code of conduct will be handled?
- Trust and community
... somebody you trust recommended it?
Parts to be covered!
- ☑ Source/version control
- Git
- We have a starting point!
- GitHub as remote backup
- Branches
- ☑ Planning
- ☑ Analysis
- ☑ Design
- ☑ Testing
- Different levels
- ☑ Collaboration
- GitHub
- pull requests
- ☑ Sharing
- ☑ open science
- ☑ citation
- ☑ licensing
- ☑ deploying
- ☑ Documentation
- ☑ in-code documentation
- ☑ finish documentation