Fix: edits to doc section from @SimonMolinsky

Author: lwasser

documentation/contributing-file.md

@@ -5,7 +5,7 @@ A healthy Python package repository (or any open source software repository) sho
 * Contributing.md file
 * A development guide (if possible)
 * A License file and 
-* A code of conduct file 
+* A CODE_OF_CONDUCT.md file 
 
 ## What a CONTRIBUTING.md file should contain
 
@@ -22,6 +22,7 @@ submitting issues or pull requests:
 * Any guidelines that you have in place for users submitting issues, pull requests or asking questions. 
 * A link to your code of conduct
 * A link to a development guide if you have one
+* A link to licensing information found in your README file. 
 
 ## What the development guide for your Python package should contain 
 
@@ -68,16 +69,17 @@ review. Some maintainers may also opt to include the development information in
 creating a contributing guide](https://mozillascience.github.io/working-open-workshop/contributing/)
 ```
 
-## Your repository should have a license file
+## Your repository should have a LICENSE.md file
 
-The root of your GitHub repository sshould also have a License.txt file. 
+The root of your GitHub repository should also have a LICENSE.txt file. 
 
-To be reviewed by pyOpenSci your project should use an open source software license that is approved 
+To be reviewed by pyOpenSci your project should use an open source 
+software license that is approved 
 by the Open Software Initiative (OSI). OSI's website has a 
 [list of popular licenses](https://opensource.org/licenses). GitHub also has a 
 [handy tool](https://choosealicense.com/) for choosing a license. 
 
-If you chose your license through GitHub, you can also automatically get a copy of the license file to add to your repository. 
+If you choose your license through GitHub, you can also automatically get a copy of the license file to add to your repository. 
 
 <!-- 
 pyOpenSci packages must:

documentation/readme-file-best-practices.md

@@ -5,12 +5,13 @@ install your package.
 
 The README.md file is the landing page of:
 
-* Your file on package manager landing pages like PyPI and Anaconda
+* Your package's landing page on a repository site such as PyPI or Anaconda
 * Your package's GitHub repository
 
-It is also used to measure:
-* community health by github
-* and included in package health landing pages such as snyk 
+Your README.md file is also used as a measure of package and community 
+health on sites such as:
+* [GitHub community health (available for all repositories - this link demonstrates movingpandas)](https://github.com/anitagraser/movingpandas/community), and
+* [snyk - moving pandas example)  
 
 
 ```{figure} ../images/pandera-python-package-readme-github.png
@@ -40,9 +41,9 @@ Your README file should have the following information:
 - [ ] Badges for the packages current published version, documentation and test suite build. (OPTIONAL: test coverage) 
 - [ ] Easy-to-understand explanation (2-4 sentences) of what your tool does
 - [ ] Context for how the tool fits into the broader ecosystem 
-- [ ] If it's your package is a wrapper, link to the package that it is wrapping and any associated documentation. (If you do'nt know what a wrapper is - this probably doesn't apply to you!)
-- [ ] A simple quickstart code example that a user can follow to provide a demonstration of what the package can do for them 
-- [ ] Links to your package documentation / website.
+- [ ] If your package "wraps" around another package, link to the package that it is wrapping and any associated documentation. *(HINT: If you don't know what a wrapper is, this probably doesn't apply to you!)*
+- [ ] A simple quick-start code example that a user can follow to provide a demonstration of what the package can do for them 
+- [ ] Links to your packages documentation / website.
 - [ ] A few descriptive links to any tutorials you've created for your package.
 ```
 ````
@@ -122,33 +123,41 @@ your README file.
 
 This description ideally includes a quick start vignette that provides a code sample demonstrating use of your package. 
 
-### ✔️ Descriptive links to package documentation, tutorials or vignettes.
+### ✔️ Descriptive links to package documentation, short tutorials
 
 Include descriptive links to:
 
 * The package's documentation page. 
-* Tutorials or vignettes that demonstrate application of your package. 
+* Short tutorials that demonstrate application of your package. 
 
 ```{tip}
-### TOO MUCH OF A GOOD thing
+### Too Much Of A Good Thing
 
-Try to avoid including several tutorials in the readme file itself. This too will overwhelm the user with information. 
+Try to avoid including several tutorials in the README.md file itself. This too will overwhelm the user with information. 
 
-A short quick-start vignette that shows a user how to use your package is plenty for the README file. All other tutorials and documentation should be presented as descriptive links. 
+A short quick-start tutorial that shows a user how to use your package 
+is plenty of content for the README file. All other tutorials and 
+documentation 
+should be presented as descriptive links. 
 ```
 
 ### ✔️ A Community Section with Links to Contributing Guide, Code of Conduct 
-In your readme file direct users to more information on:
-* contributing to your package 
-* development setup for more advanced technical contributors 
-* your code of conduct. 
 
-All of the above files are important for building community around your project.
+Use your README.md file to direct users to more information on:
+
+* Contributing to your package 
+* Development setup for more advanced technical contributors 
+* Your code of conduct
+* Licensing information
+
+All of the above files are important for building community around your 
+project.
 
 ### ✔️ Citation information
 
 Finally be sure to include instructions on how to cite your package. 
- 
+Citation should include the DOI that you want used when citing your package, 
+and any language that you'd like to see associated with the citation. 
 
 ```{tip}
 ### README Resources