#29 stared standards chapter, added links in other chapters to allow …

…for linking to anchors

_quarto.yml

@@ -28,6 +28,7 @@ book:
     - wdlconfig.qmd
     - docker.qmd
     - conventions.qmd
+    - standards.qmd
   site-url: https://getwilds.org/guide/
 
 bibliography: references.bib

maintenance.qmd

@@ -12,7 +12,7 @@ All software (R, Python, etc.) in the WILDS should by default use the [MIT licen
 
 If there are circumstances which prevent using MIT, please do discuss with Sean or Scott.
 
-### R
+### R {#sec-license-r}
 
 In R, you can add the MIT license to your repository with the following code:
 
@@ -25,12 +25,12 @@ usethis::use_mit_license()
 
 Note that `usethis::use_mit_license` adds two files to your repository (`LICENSE` and `LICENSE.md`, and adds entries to the `.Rbuildignore` file so that `R CMD CHECK` doesn't complain).
 
-### Python
+### Python {#sec-license-python}
 
 There's no widely accepted single tool for dealing with licenses in Python similar to the above for R. For Python packages, simply include the license type (e.g., `MIT`) in your setup.py, setup.cfg, pyproject.toml, etc., and include the text of the license in a `LICENSE` file in the root of your repository.
 
 
-## Package versioning
+## Package versioning {#sec-versioning}
 
 There is a detailed discussion of versioning R packages in the [lifecycle][] chapter of the [R Packages book][rpkgs] by Hadley Wickham and Jenny Bryan. Please follow that chapter in general for versioning of R and Python packages within the WILDS. To make it easier to grok, below are some of the highlights, and some exceptions to that chapter.
 
@@ -58,7 +58,7 @@ Following the [Tidyverse package version conventions](https://r-pkgs.org/lifecyc
 
 We are not following or enforcing any rules about changes at the function/class/etc level below the package level. For example, the R Packages book [talks about][funcx] using the `lifecycle` package to deal with function changes.
 
-## Package releases
+## Package releases {#sec-releases}
 
 In general follow the [Releasing to CRAN chapter](https://r-pkgs.org/release.html) in the book [R Packages][rpkgs] for R, and the [Releasing and versioning chapter](https://py-pkgs.org/07-releasing-versioning) in the book [Python Packages][pypkgs] for Python. Those chapters don't have to be followed to the letter, but in general they provide really good guidance.
 

packagedocs.qmd

@@ -2,7 +2,7 @@
 
 All formally supported WILDS R and Python packages should have package documentation.
 
-## R
+## R {#sec-docs-r}
 
 We use the [pkgdown][] package to create documentation for R packages, and host it on [GitHub Pages][ghpages]. To get started with `pkgdown`, in R within the root of your package run [usethis::use_pkgdown_github_pages()](https://usethis.r-lib.org/reference/use_pkgdown.html) - it will set up a `_pkgdown.yml` file in the root of your repo used to configure `pkgdown`, and add a `.github/workflows/publish.yml` file to build the package documentation on each push, pull request, or release. See [pkgdown documentation][pkgdown] for details on configuring documentation.
 
@@ -21,7 +21,7 @@ template:
 
 For now just use the default theme that `pkgdown` provides.
 
-## Python
+## Python {#sec-docs-python}
 
 Just like there's a variety of ways to do packing in Python there's a variety of documentation options. Two of the well known options are:
 

standards.qmd

@@ -0,0 +1,50 @@
+# Standards {{< iconify fa6-solid scale-balanced >}} {#sec-standards}
+
+::: {.callout-note}
+These are living standards. Have a question/concern/suggestion? [Let's chat](https://github.com/getwilds/guide/issues/new).
+:::
+
+Standards for each repository type ...
+
+In order to keep the standards easily digestable, for each repo type below we keep each standard short and simple and link out to other sections of the book for more information.
+
+## R
+
+Each R package in WILDS should follow the following standards:
+
+- Use package `pkgdown` to create package documentation (see @sec-docs-r)
+- Use an open source license; in most cases that means MIT (see @sec-license-r)
+- Follow our package versioning guidelines (see @sec-versioning)
+- Follow our package releases guidelines (see @sec-releases)
+- Follow all conventions in @sec-conventions
+
+## Python
+
+Each Python package in WILDS should follow the following standards:
+
+- Maintain package documentation (see @sec-docs-python)
+- Use an open source license; in most cases that means MIT (see @sec-license-python)
+- Follow our package versioning guidelines (see @sec-versioning)
+- Follow our package releases guidelines (see @sec-releases)
+- Follow all conventions in @sec-conventions
+
+## Docker
+
+Coming soon!
+
+## Research Compendia
+
+Coming soon!
+
+## WDL
+
+Coming soon!
+
+## NextFlow
+
+Coming soon!
+
+## Compliance with standards
+
+We're not sure how this will be done exactly. For now, we'll do compliance manually. Ideally the end state will be completely automated.
+

style.qmd

@@ -29,7 +29,7 @@ See the [R languageserver][languageserver] GitHub repository for more informatio
 
 In the [getwilds/makefiles repo](https://github.com/getwilds/makefiles) we have an R package Makefile template with [three make targets](https://github.com/getwilds/makefiles/blob/main/R/Makefile#L31-L40) for styling package code: `lint_package`, `style_file`, and `style_package`. With that Makefile in the root of your package you can run `lint_package` to check for any problems, and run `style_file` or `style_package` to fix any problems. You can also just run the R code in those make targets in a terminal or within R.
 
-### GitHub Actions
+### GitHub Actions {#sec-style-actions}
 
 To get setup with GitHub Actions and `lintr` and `styler`, first install `lintr` if you don't have it: