-
-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adopt Standard Readme Style Spec #12
Comments
I like this idea. Thanks for thinking of it, @davidak! |
Hey @davidak, thanks for opening the issue. I was aware of Standard Readme when I made this site, but I didn't make it a point of emphasis. My intention was to create an accessible resource that is primarily targeted towards people who are relatively new to writing READMEs (or who just haven't put that much thought into it before). I had my own ideas for what content goes into good READMEs, and I also didn't want to be rigid about it. As I noted in the FAQ: "Not all of the suggestions here will make sense for every project, so it's really up to the developers what information should be included in the README." I should add a link to Standard Readme there, but from what I can tell, it's pretty far from becoming a true standard in terms of adoption. I'd prefer to hold off on making compliance with it a goal until the linked issue gets more traction. |
The last days i thought about how we can help projects to create better readmes. It's great when a community comes up with a standard and adopt it, like the JS community and the IPFS project does with the linked spec, but for me, my company and many more small projects, the spec is too verbose. I actually don't care if my readme is compliant to any spec. This site is much more accessible, so the chance people consider using it is much higher. So i close this issue, but i will open others too discuss using sections and section order from the spec. |
Have you considered adopting the Standard Readme Style Spec by @RichardLitt?
Practical that would mean having the required sections in your editable template. (see minimal-readme.md) Add your example content again.
After that, explain each section like here https://github.com/RichardLitt/standard-readme/blob/master/spec.md#sections
You can mention that it follows the Spec (with link) that members of the open source community has worked out and that one can add the badge if one follows it.
Your sections and their order are already very similar to the Standard Readme Style Spec, so this might not be too complicated. You have some additional, optional sections that make sense to me, like Visuals, Support, Roadmap and Project status, so you would need to collaborate with the other project to find consent to add them or remove them.
Would you like going this way? I could propose a Pull Request.
I opened a similar issue on their repo. (RichardLitt/standard-readme#82)
The text was updated successfully, but these errors were encountered: