Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 32 additions & 7 deletions _episodes/02-make-it-public.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,21 +58,46 @@ on this topic, and other advice on starting an open source project, check out th
- This file is automatically displayed on the front page of your repository
- It has important information about your project

To format the contents of this file you will use Markdown syntax. If you want to know more about it you can use this [cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) or this [short guide](https://guides.github.com/features/mastering-markdown/)


The '.md' extension indicates that the file is written in Markdown language, which uses plain text formatting syntax that can be converted into web output format. Markdown syntax is basically plain text with a few non-alphabetic characters such as * or # for bold, italics, headings, etc. to style test. For example, you can make some text bold by adding two asterisks \** before and after the text:

```
**This text is bold**
```
will appear as:

**This text is bold**

It is also possible to create lists, insert images, tables, web links and more.

We will see now some basic writing and formatting syntax by following this [short guide](https://guides.github.com/features/mastering-markdown/). This [cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) also provides useful guidance.

> ## Challenge: Improve the README
>
> The README.md file that GitHub generated when we created the project is quite
> boring. Add some more content using some of the Markdown syntax introduced
> above. You could add a few sentences about the purpose of your software, some
> above (if you don't remember a Markdown command you can refer to the
> [cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) mentioned above).
> You could add a few sentences about the purpose of your software, some
> details of the author(s) and their affiliation(s), or anything else that you
> think is important.

{: .challenge}

In addition to the README.md file, a good software project should include other "recommended community health files". What other files should you include in your project? You may find insights on health files to include in your project (to ensure that it meets the recommended community standards) in the Community Profile of the public repository hosting your project. Indeed, a public repository Community Profile provides rules and best practices on how to help grow a community and support contributors in using and contributing to your project. If your project is hosted on GitHub, you may refer to the [GitHub Community Profile](https://github.com/SoftDev4Research/4OSS-lesson/community), which can be accessed following [these instructions](https://help.github.com/en/articles/accessing-a-projects-community-profile) and where you can find a checklist that can be used to see if your project includes community health files recommended by GitHub.
These include a project DESCRIPTION file, a README file and a CODE_OF_CONDUCT, which contains standards on how to engage in the community. Furthermore, a project should have a CONTRIBUTING file (for details see episode on "Define clear and transparent contribution, governance and communication processes") outlining guidance for contributing to the project, and a LICENCE file that states how the code can be used. You should have a good idea of what is the appropriate license for your project after the [next episode](https://softdev4research.github.io/4OSS-lesson/03-use-license/index.html). Templates for GitHub issues and pull requests are also required for a complete community profile (see the [Software Carpentry lesson on Version Control with Git](http://swcarpentry.github.io/git-novice/) to learn about GitHub issues and pull requests).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
These include a project DESCRIPTION file, a README file and a CODE_OF_CONDUCT, which contains standards on how to engage in the community. Furthermore, a project should have a CONTRIBUTING file (for details see episode on "Define clear and transparent contribution, governance and communication processes") outlining guidance for contributing to the project, and a LICENCE file that states how the code can be used. You should have a good idea of what is the appropriate license for your project after the [next episode](https://softdev4research.github.io/4OSS-lesson/03-use-license/index.html). Templates for GitHub issues and pull requests are also required for a complete community profile (see the [Software Carpentry lesson on Version Control with Git](http://swcarpentry.github.io/git-novice/) to learn about GitHub issues and pull requests).
These include a project DESCRIPTION file, a README file and a CODE_OF_CONDUCT, which contains standards on how to engage in the community. Furthermore, a project should have a CONTRIBUTING file (for details see episode on "Define clear and transparent contribution, governance and communication processes") outlining guidance for contributing to the project, and a LICENCE file that states how the code can be used. You should have a good idea of what is the appropriate license for your project after the [next episode](03-use-license.md). Templates for GitHub issues and pull requests are also required for a complete community profile (see the [Software Carpentry lesson on Version Control with Git](http://swcarpentry.github.io/git-novice/) to learn about GitHub issues and pull requests).


You might also want to add details of how to correctly cite the software after publication. This can be done by adding a file called CITATION.cff in the root of your repository (where other health files are stored). The .cff (Citation File Format) is a machine-readble and human-readble and -writable format providing citation information for research software.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You might also want to add details of how to correctly cite the software after publication. This can be done by adding a file called CITATION.cff in the root of your repository (where other health files are stored). The .cff (Citation File Format) is a machine-readble and human-readble and -writable format providing citation information for research software.
You should also add description on how others can correctly cite the software. This can be done by adding a file called CITATION.cff in the root of your repository (where other health files are stored). The .cff (Citation File Format) is a machine-readble and human-readble and -writable format providing citation information for research software.

You may also add a `paper.md` file if the software is published via the Journal of Open Source Software (JOSS).
Notice that you, as a research/scientific software developer, need recognition for software you develop and this will not happen if there is no way to cite your software.

> ## Challenge: Add a CITATION.cff file to your repository
> You can use the example provided [here](https://citation-file-format.github.io) to create a CITATION.cff
> file for your software and add it to your repository. It is not relevant to use real information for this exercise.
> It is important that you see how to write a .cff file and to include it in your repository.

{: .challenge}

- In addition to the README & LICENSE (.md) files, a good software project might include guidance for contributing to the project (CONTRIBUTING.md - see lesson on contributions, governance, and communication), details of how to correctly cite the software after publication (CITATION.md - see later in this lesson), or even a `paper.md` file if the software is published via the Journal of Open Source Software (JOSS)
- You should have a good idea of what is the appropriate license for your project after the [next lesson](https://softdev4research.github.io/4OSS-lesson/03-use-license/index.html) but, if you need help choosing an license, you can also click on the "info" button next to the "add a license" dropdown, which will take you to https://choosealicense.com/
- Making the project public at the start is not enough! See the [Software Carpentry lesson on Version Control with Git](http://swcarpentry.github.io/git-novice/) for advice on best practice in software version control.
You will find more about how to publish your software later in this episode. Other health files will be described in detail in relevant sections.

> ## Discussion: How does version control help your project?
> #### 5 minutes
Expand Down