Update contribution docs (#461)

* Minor updates to README and contributing guide

* Update contributing guide more

* update readme

* More updates to contributing guide

.github/CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 This outlines how to propose a change to dccvalidator.
 
-### Fixing typos
+### Fixing Typos
 
 Small typos or grammatical errors in documentation may be edited directly using
 the GitHub web interface, so long as the changes are made in the _source_ file.
@@ -13,41 +13,56 @@ the GitHub web interface, so long as the changes are made in the _source_ file.
 ### Prerequisites
 
 Before you make a substantial pull request, you should always file an issue and
-make sure someone from the team agrees that it’s a problem. If you’ve found a
+make sure someone from the team agrees that it’s a problem or desired feature. If you’ve found a
 bug, create an associated issue and illustrate the bug with a minimal 
 [reprex](https://www.tidyverse.org/help/#reprex).
 
-### Pull request process
+Once an issue exists, indicate that you plan on working on the update by commenting in the issue and, if able, assigning the issue to yourself.
+
+### Contribution Process
+
+All updates are done via pull request. We require that you create a Git branch for each pull request (PR). If you are unable to create a branch in the main repo, please see the section on forked repos below.  There is a default template for all pull requests, subject to change.
+
+- **Fixes #:** Put the number of the issue (e.g. Fixes #123).
+- **Changes proposed**: List the changes made.
+- **Confirmation checklist**: This checklist is both a reminder and a verification that related items were done. If the item is relevant to the changes being made, then be sure to do the task associated. When the pull request includes the item, check the box by adding an 'x' (e.g. `- [x] `) if marking upon pull request creation or by clicking on the checkbox for existing pull requests. If the item is irrelevant to the changes being made, leave the checkbox unchecked. If the maintainers believe the item is relevant to the change, they will request an update to the pull request.
+
+#### Guidelines
+
+There are a few guidelines to make note of. Please see the Local Development section for more information, as well.
 
-*  We recommend that you create a Git branch for each pull request (PR).  
-*  Look at the Travis build status before and after making changes. The `README`
-should contain badges for any continuous integration services used
-by the package.  
 *  New code should follow the tidyverse [style guide](http://style.tidyverse.org).
-You can use the [styler](https://CRAN.R-project.org/package=styler) package to
-apply these styles, but please don't restyle code that has nothing to do with 
-your PR.  
+   You can use the [styler](https://CRAN.R-project.org/package=styler) package to
+   apply these styles, but please don't restyle code that has nothing to do with 
+   your PR.  
 *  We use [roxygen2](https://cran.r-project.org/package=roxygen2), with
-[Markdown syntax](https://cran.r-project.org/web/packages/roxygen2/vignettes/markdown.html), 
-for documentation.  
+   [Markdown syntax](https://cran.r-project.org/web/packages/roxygen2/vignettes/markdown.html), 
+   for documentation. 
 *  We use [testthat](https://cran.r-project.org/package=testthat). Contributions
-with test cases included are easier to accept.  
+   with test cases included are easier to accept.
+*  If adding or updating features, be aware that the maintainers may suggest breaking up a complicated function into two or more smaller, testable functions. This helps with testing, debugging, and reusability.
+
+#### Forked Repos
+
+If you do not have write access to the repo, please create a fork in your own account. Note that a pull request from a forked branch will fail the GitHub Actions tests due to not having the required secrets. Since the maintainers will need to spend extra time vetting the update, pull requests from forked repositories will take longer to process.
 
-### Local development
+### Local Development
+
+#### pre-commit hooks
 
 `dccvalidator` uses pre-commit hooks to check for common issues, such as code
 style (which should conform to [tidyverse style](https://style.tidyverse.org/)),
 code parsability, and up-to-date .Rd documentation. To use, you will need to
 install [pre-commit](https://pre-commit.com/#intro). If on a Mac, I recommend
 using [homebrew](https://brew.sh/):
 
-```
+```R
 brew install pre-commit
 ```
 
 Then, within this git repo, run:
 
-```
+```R
 pre-commit install
 ```
 
@@ -58,6 +73,34 @@ you can run `git commit --no-verify` to skip all checks. Or, you can skip
 certain hooks by their ID (as shown in the file `.pre-commit-config.yaml`), e.g.
 `SKIP=roxygenize git commit -m "foo"`.
 
+#### Manual checks
+
+While pre-commit hooks are recommended, it's possible to verify that the update follows our standards.
+
+##### Package Check
+
+Install the `devtools` package and run the `check()` function. All checks should pass, including tests.
+
+```R
+devtools::check()
+```
+
+##### Style
+
+As mentioned above, this package follows the [tidyverse style guide](http://style.tidyverse.org). Sticking to a single style helps with readability and allows for focusing on the code itself. Your code can be updated to the proper style by installing the `styler` package and running one of the styling functions on your code, such as `style_dir()`.
+
+```R
+styler::style_dir(file_type = "r")
+```
+
+Additionally, we also follow linting guidelines. While `styler` will enforce some of these guidelines, it is also useful to install `lintr` and run one of the linting functions, such as `lint_file()` or `lint_package()`. If there are linting errors, this will generate a list of problems to be fixed.
+
+```
+lintr::lint_package()
+```
+
+_Note: Only commit style and lint changes related to your own code. If there are style and lint changes unrelated to your code, these can be ignored._
+
 ### Code of Conduct
 
 Please note that the dccvalidator project is released with a [Contributor Code of Conduct](https://sage-bionetworks.github.io/dccvalidator/CODE_OF_CONDUCT).

README.Rmd

@@ -47,7 +47,7 @@ want to use the default Python installation on your machine. Whichever Python
 installation you choose should have synapseclient installed.
 
 Because dccvalidator uses reticulate, it is not compatible with the
-[synapser](https://r-docs.synapse.org/) package..
+[synapser](https://r-docs.synapse.org/) package.
 
 ## Check data
 
@@ -62,7 +62,7 @@ issues:
   are also present in another)
 - Check that identifiers are unique within a file
 
-# Data submission validation
+## Data submission validation
 
 This package contains a Shiny app to validate manifests and metadata for AMP-AD
 studies. It uses the dccvalidator package to check for common data quality
@@ -77,3 +77,14 @@ See the [customizing dccvalidator](https://sage-bionetworks.github.io/dccvalidat
 vignette for information on how to spin up a customized version of the
 application
 
+## Requesting New Features or Bug Fixes
+
+For new feature requests or bug fixes, please create an issue to let the maintainers know. If you’ve found a bug, create an associated issue and illustrate the bug with a minimal 
+[reprex](https://www.tidyverse.org/help/#reprex). If there is agreement that the problem exists or that a new feature is desired, then the issue will be triaged for future development based on priority.
+
+Please note that the dccvalidator project is released with a [Contributor Code of Conduct](https://sage-bionetworks.github.io/dccvalidator/CODE_OF_CONDUCT).
+By contributing to this project via issue creation, comment, or pull request, you agree to abide by its terms.
+
+## Contributing
+
+See the [Contributing Guide](https://github.com/Sage-Bionetworks/dccvalidator/blob/master/.github/CONTRIBUTING.md) to see how you can get involved in the development of this application.

README.md

@@ -35,7 +35,7 @@ Whichever Python installation you choose should have synapseclient
 installed.
 
 Because dccvalidator uses reticulate, it is not compatible with the
-[synapser](https://r-docs.synapse.org/) package..
+[synapser](https://r-docs.synapse.org/) package.
 
 ## Check data
 
@@ -50,7 +50,7 @@ quality issues:
     in one file are also present in another)
   - Check that identifiers are unique within a file
 
-# Data submission validation
+## Data submission validation
 
 This package contains a Shiny app to validate manifests and metadata for
 AMP-AD studies. It uses the dccvalidator package to check for common
@@ -66,3 +66,24 @@ See the [customizing
 dccvalidator](https://sage-bionetworks.github.io/dccvalidator/articles/customizing-dccvalidator.html)
 vignette for information on how to spin up a customized version of the
 application
+
+## Requesting New Features or Bug Fixes
+
+For new feature requests or bug fixes, please create an issue to let the
+maintainers know. If you’ve found a bug, create an associated issue and
+illustrate the bug with a minimal
+[reprex](https://www.tidyverse.org/help/#reprex). If there is agreement
+that the problem exists or that a new feature is desired, then the issue
+will be triaged for future development based on priority.
+
+Please note that the dccvalidator project is released with a
+[Contributor Code of
+Conduct](https://sage-bionetworks.github.io/dccvalidator/CODE_OF_CONDUCT).
+By contributing to this project via issue creation, comment, or pull
+request, you agree to abide by its terms.
+
+## Contributing
+
+See the [Contributing
+Guide](https://github.com/Sage-Bionetworks/dccvalidator/blob/master/.github/CONTRIBUTING.md)
+to see how you can get involved in the development of this application.