The checklist:
- A readme following a good template
- A contributing.md with a code of conduct.
- A license
- Travis configuration
- A way for people to raise issues
- Link to it
Do you have a README(.md) that explains the following things?
- What the software is and does
- How to use the software
- How to the release process works
- How the dependencies that the software has
- How legally the software can be used
If your software is complicated this might need to be an index for other files.
A template for a README can be found here, or there is one more specialised to Docker here.
It's important people know the rules for contributing in the project. It's irritating for people trying to help when they are pushed back because they didn't follow some process that they didn't know existed. CONTRIBUTING(.md) is the place for these processes and it will lower the barrier to entry for contribution.
Secondly, this file should explicitly state that we will not discriminate against people on any grounds other than their code contributions, and make clear that behaviour that would be harmful to other people that may wish to contribute is not acceptable. This gives clear authority to remove people who are causing problems, and also sets a clear tone of inclusion. We achieve this by including a code of conduct in the CONTRIBUTING(.md) or as a seperate code_of_conduct(.md) file.
I would recommend the Contributor Covenant as the basis for your code of conduct. There is also an example CONTRIBUTING.md here
Will I be sued for using this in my project. People need to know this or it's hard to get professional organisations building on your work.
Personally I like the MIT license for this. Here is an example.
One of the key jobs of validating a pull request is running a series of tests to check that it won't break any existing work when merging in, and that the work that is does add actually... works. We can check this using a CI service.
Travis offers free CI for Open Source projects hosted on GitHub, and integrates into Pull Requests (putting a red dot next to none working branches). This allows people to know without having to wait for a team member to see if they have made any functional error in their code.
It can be made for both infrastructure and code templates.
Bugs happen. Not everyone has the technical skill to fix them, but a much wider set of people can report them. This should be easy process (documented in Contributing) and should leave the reporter feeling that they have contributed something useful back to the project.
You need to tell people. Not telling anyone is essentially the same as not open sourcing your work. Be proud, and even if the only place you have to put the link is your twitter account, go for it!