Updated readme around “healthcheck” endpoint.
I added some titles to the readme on my pet project: https://github.com/nulpunkt/yesql-php
Easy one to do 
Finally got around to filing out all of the pending details on one of projects.
Updated the readme for some environment setup that was missing in one of our projects. The setup experience will be much smoother than before.
I updated my pet project README, here is the final diff if you would like to check it out! There is still room for improvements, but I loved the progress done within only 20mins.
Tip: I used https://stackedit.io/app, a free web app markdown editor, I really like it.
A future project will be to bring our Docker environment up-to-date, (I don’t think anyone’s actually using it) 
We’re distributed, so a network share isn’t going to work. We’re using Dropbox links at the moment, but that’s not ideal either. I guess we could set up FTP somewhere.
FTP is a well-understood, solid transfer protocol which is much easier to integrate into any automation process than the fancy new things like Dropbox
1 Like
Updated the readme for my blog: https://github.com/pzelnip/www.codependentcodr.com/pull/97
Was definitely out of date.
As a second stab at this I updated the readme of one of the public projects that my company owns as well: https://github.com/bambora/na-payment-apis-demo/pull/62
One of the things I did as part of this was add a .markdownlint.json file to enforce some linting rules around the markdown in the readme.
A few thoughts here:
- mixed feelings about including animated gifs! Quite a few people use plain text editors which can cope with markdown, but not with more ‘modern’ (read: post-1990s) multimedia content…
- having a link to the project documentation (example: your readthedocs page) can be a nice addition to the README template provided
- the license under which open source code gets published is really important - whilst many other details can be copied and pasted from the README template, the license that you select should be chosen carefully. This maybe deserves a warning or caveat emptor in the Day 1 introductory text…
Nice exercise - and kudos to Billie Thompson for the great README template!
I “cleaned up” my README by changing it from the boilerplate create by running the mix phx.new command (this is a phoenix project).
This also showed me that my setup script didn’t check if chromedriver was installed, and was using the wrong command to setup the database.
I finally got around to adding a README to my newer project (WP Health, a WordPress monitor).
On my previous projects, I used a CONTRIBUTING.MD in GitHub which used to (still does (?)) show a banner with link to them when users opened issues/pull requests and I liked to it from the README. However, no one ever seemed to read it. But, including all the info in the README makes it really long causing people to not read all of it.
So, question is: Should the info for creating issues/pull requests be in the README or in a separate CONTRIBUTING file?
I’ve tended to have the CONTRIBUTING file contain the info for creating PRs/issues, and then in the readme have a line to the effect of “Before contributing new issues or PR’s, please do consult the CONTRIBUTING.md file” with a link to the contributing file.
1 Like