Fix: review edits to documentation section w @Batalex

Update documentation/contributing-file.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/index.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/index.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/package-documentation-sphinx.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/readme-file-best-practices.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/readme-file-best-practices.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/readme-file-best-practices.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/readme-file-best-practices.md

Co-authored-by: Alexandre Batisse <[email protected]>

Update documentation/readme-file-best-practices.md

Co-authored-by: Alexandre Batisse <[email protected]>

Author: lwasser

documentation/contributing-file.md

@@ -33,7 +33,7 @@ technically proficient users how to:
 * Run the test suite 
 * Build documentation locally
 
-It's also helpful to specify the types of tests your request if a contributor submits a new feature or a change to an existing feature that will not be covered by your existing test suite. 
+It's also helpful to specify the types of tests you request if a contributor submits a new feature or a change to an existing feature that will not be covered by your existing test suite. 
 
 If you have time to document it, it's also helpful to document your maintainer workflow and release processes. 
 

documentation/index.md

@@ -16,9 +16,9 @@ explicit information about how to contribute is critical.
 In the pyOpenSci open peer review process we look for several files and elements
 when evaluating package documentation, including:
 
-1. [A clear and to the point **README.md** file](readme-files)
+1. [A clear and to the point **README.md** file](readme-file-best-practices)
 2. **User oriented package documentation** that helps users understand how to install, use and cite your package. 
-3. **Package API documentation.** Package API documentation refers to documentation for each class, function, method and attribute that is user-facing (*available for a user to see*) in your package. This mean that your package methods and classes should have [thoughtful docstrings](https://pandas.pydata.org/docs/development/contributing_docstring.html) that  describe both the purpose of the code element and each input and output. To help your users better understand how to use your package, you can include short code examples that demonstrate how to use the function or class in each docstring. If you don't know what API documentation means this section of the pyOpenSci Python packaging guide is for you! 
+3. **Package API documentation.** Package API documentation refers to documentation for each class, function, method and attribute that is user-facing (*available for a user to see*) in your package. This mean that your package methods and classes should have [thoughtful docstrings](https://pandas.pydata.org/docs/development/contributing_docstring.html) that describe both the purpose of the code element and each input and output. To help your users better understand how to use your package, you can include short code examples that demonstrate how to use the function or class in each docstring. If you don't know what API documentation means this section of the pyOpenSci Python packaging guide is for you! 
 4. A **CONTRIBUTING.md** file that outlines how others can contribute to your package. This file should also link to your development guide and code of conduct. A well-crafted contributing guide will make it much easier for the community to contribute to your project.
 5. A **CODE_OF_CONDUCT.md** file.  
 5. **LICENSE.txt file & Citation instructions:** A license file and instructions for citing your package. 

documentation/package-documentation-sphinx.md

@@ -99,7 +99,7 @@ have 4 elements on the home page of their documentation:
 
 * **Getting started:** This section should provide the user with a quick start for installing your package. A small example of how to use the package is good to have here as well. 
 * **About:** Describe your project, state project goals and what it does. 
-* **Community:** Instructions for ho to help and/or get involved. This section might include a development guide. 
+* **Community:** Instructions for how to help and/or get involved. This section might include a development guide. 
 * **Documentation:** The actual project documentation. You may have two sections of documentation - the user facing documentation and your API reference. 
 
 NOTE: in many cases you can include your **README** file and your **CONTRIBUTING** files 

documentation/readme-file-best-practices.md

@@ -42,8 +42,8 @@ Your README file should have the following information:
 - [ ] 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 packages documentation / website.
-- [ ] A few descriptive links to any tutorials you've created for your pacakge.
+- [ ] Links to your package documentation / website.
+- [ ] A few descriptive links to any tutorials you've created for your package.
 ```
 ````
 
@@ -60,7 +60,7 @@ self explanatory that name is, the better.
 Badges are a useful way to draw attention to the quality of your project. Badges 
 assure users that your package is well-designed, tested, and maintained. They 
 are also a useful maintenance tool to evaluate if things are building properly. 
-A great example of this is adding a readthedocs bade to your readme to quickly
+A great example of this is adding a readthedocs badge to your readme to quickly
 see when the build on that site fails. 
 
 It is common to provide a collection of badges towards the top of your 
@@ -113,18 +113,18 @@ the package on both PyPI and Conda be sure to include instructions for both.
 
 ### ✔️ Document any addition setup required
 
-Add any additional setup required such as authentication tokens,  to 
+Add any additional setup required such as authentication tokens, to 
 get started using your package. If setup is complex, consider linking to a 
 installation page in your online documentation here rather than over complicating
 your README file. 
 
 ### ✔️ Brief demonstration of how to use the package
 
-This description ideally includes a quick start vignette that provides a code sample demonstrating use of our package. 
+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.
 
-Include descriptive links to to:
+Include descriptive links to:
 
 * The package's documentation page. 
 * Tutorials or vignettes that demonstrate application of your package.