Move release checklists to issue templates

ccao-data · Jul 11, 2023 · 1acdb41 · 1acdb41
1 parent 02bd4df
commit 1acdb41
Show file tree

Hide file tree

Showing 4 changed files with 77 additions and 139 deletions.
diff --git a/.github/ISSUE_TEMPLATE/release-database.md b/.github/ISSUE_TEMPLATE/release-database.md
@@ -0,0 +1,29 @@
+---
+name: Release checklist (database)
+about: Steps to take before releasing a new PTAXSIM database version
+title: "Database release [VERSION]"
+labels: release
+---
+
+# Database Release Checklist
+
+- [ ] Make your code updates and commit them in a branch
+- [ ] Make any necessary updates to the raw data. If necessary, force add the raw data files if they are ignored by git. Be sure to update `.gitattributes` such that the raw data files are tracked by git LFS
+- [ ] Run the raw data scripts (anything in `data-raw/`) that prepare and clean the data. These scripts will save the cleaned data to a staging area in S3. Ensure that the relevant S3 keys in the PTAXSIM bucket are updated using the AWS console or API
+- [ ] Inside `data-raw/create_db.R`, increment the `db_version` variable following the [schema outlined above](#schema)
+- [ ] If necessary, also increment the `requires_pkg_version` variable in `data-raw/create_db.R`
+- [ ] Increment the database versions in `DESCRIPTION` file:
+  - `Config/Requires_DB_Version`: This is the minimum database version required for this version of the package. It should be incremented whenever there is a breaking change
+  - `Config/Wants_DB_Version`: This is the maximum database version required for this version of the package. It is the version of the database pulled from S3 during CI/testing on GitHub
+- [ ] If necessary, be sure to update the SQL statements in `data-raw/create_db.sql`. These statements define the structure of the database
+- [ ] Run the database generation script `data-raw/create_db.R`. This will create the SQLite database file by pulling data from S3. The file will be generated in a temporary directory (usually `/tmp/Rtmp...`), then compressed using `pbzip2` (required for this script)
+- [ ] Using the command line, grab the final compressed database file from the temporary directory (found at `db_path` after running `data-raw/create_db.R`) and move it to the project directory. Rename the file `ptaxsim-<TAX_YEAR>.<MAJOR VERSION>.<MINOR VERSION>.db.bz2`
+- [ ] Decompress the database file for local testing using `pbzip2`. The typical command will be something like `pbzip2 -d -k ptaxsim-2021.0.2.db.bz2`
+- [ ] Rename the decompressed local database file to `ptaxsim.db` for local testing. This is the file name that the unit tests and vignettes expect
+- [ ] Restart R. Then run the unit tests (`devtools::test()` in the console) and vignettes (`pkgdown::build_site()` in the console) locally
+- [ ] Knit the `README.Rmd` file to update the database link at the top of the README. The link is pulled from the `ptaxsim.db` file's `metadata` table
+- [ ] If necessary, update the database diagrams in the README with any new fields or tables
+- [ ] Move the compressed database file to S3 for public distribution. The typical command will be something like `aws s3 mv ptaxsim-2021.0.2.db.bz2 s3://ccao-data-public-us-east-1/ptaxsim/ptaxsim-2021.0.2.db.bz2`
+- [ ] Use the S3 console (or API) to make the database file public via an ACL
+- [ ] Push the code updates on GitHub. Wait for the resulting CI pipeline to finish
+- [ ] If there are no pipeline errors, merge the branch to master
diff --git a/.github/ISSUE_TEMPLATE/release-package.md b/.github/ISSUE_TEMPLATE/release-package.md
@@ -0,0 +1,24 @@
+---
+name: Release checklist (package)
+about: Steps to take before releasing a new PTAXSIM package version
+title: "Package release [VERSION]"
+labels: release
+---
+
+# Package Release Checklist
+
+- [ ] Make your code updates and commit them in a branch
+- [ ] Make sure your code updates meet styling and linting requirements:
+  - *Styling*: Run `styler::style_pkg()` in the console
+  - *Linting*: Run `lintr::lint_package()` in the console
+- [ ] Build any documentation updates by running `devtools::document()` in the console
+- [ ] Run the build and test processes locally to check for errors:
+  - *Build*: In RStudio, go to the **Build** tab, then hit **Check**
+  - *Test*: In RStudio, go to the **Build** tab, then hit **Test** OR `devtools::test()` in the console
+- [ ] Check the vignettes by building them locally. Run `pkgdown::build_site()` in the console
+- [ ] Rebuild the README manually. Knit `README.Rmd` from within RStudio
+- [ ] Increment the package version in the `DESCRIPTION` file appropriately, following the schema laid out in the README
+- [ ] If the code updates were so substantial that the current database also needs to be updated, follow the database release checklist issue template
+- [ ] Push the code updates to GitHub. Wait for the resulting CI pipeline to finish
+- [ ] If there are no pipeline errors, merge the branch to master
+- [ ] Wait for the merge CI pipeline to finish. If there are no errors, cut a new release from master. Create a new git tag with the version number and title the release with the same version number. Be sure to add a changelog detailing what you updated
diff --git a/README.Rmd b/README.Rmd
@@ -1,6 +1,6 @@
 ---
 title: "Table of Contents"
-output: 
+output:
   github_document:
     toc: true
     toc_depth: 3
@@ -78,11 +78,11 @@ Additionally, an increased assessed value does not necessarily result in an incr
 
 *No.* Even if you know your property’s final assessed value with certainty, precisely predicting a future tax bill in Cook County is difficult because tax rates stem from multiple agencies (and the numbers they produce each year). These agencies include various taxing districts (typically 10 to 14 per property, including school districts, municipal/township/city governments, and Cook County), multiple Cook County property tax offices (Assessor, Board of Review, and Clerk), and the Illinois Department of Revenue (IDOR).
 
-It is true, however, that PTAXSIM is technically capable of predicting bills. To do this, you must have technical competency in the R programming language, and must make explicit predictions for each of the numeric inputs listed in the table below.  
+It is true, however, that PTAXSIM is technically capable of predicting bills. To do this, you must have technical competency in the R programming language, and must make explicit predictions for each of the numeric inputs listed in the table below.
 
 **Q: I can code in R. What other numbers, besides assessed value, do I need to input into PTAXSIM to generate predictions?**
 
-To predict next year’s bill for one property (PIN), you must predict the PIN's taxable value (EAV), as well as what will happen to the individual levies and tax bases of all taxing districts associated with the PIN. The table below lists each input, along with some complications and options: 
+To predict next year’s bill for one property (PIN), you must predict the PIN's taxable value (EAV), as well as what will happen to the individual levies and tax bases of all taxing districts associated with the PIN. The table below lists each input, along with some complications and options:
 
 |       Input                                                                                                                     |                                                                                   What this means                                                                                   |                                                                                                                                                                                                            Complications and possible implementation option(s)                                                                                                                                                                                                                  |
 |:-------------------------------------------------------------------------------------------------------------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
@@ -192,7 +192,7 @@ multiple_years_summ <- multiple_years %>%
       )
     )
   )
-```  
+```
 
 <details>
 
@@ -251,7 +251,7 @@ The PTAXSIM backend database contains cleaned data from the Cook County Clerk, T
 | tif_crosswalk    | Clerk             | Manually created from TIF summary and distribution reports               | [data-raw/tif/tif.R](data-raw/tif/tif.R)                         | Fix for data issue identified in #39                |
 | tif_distribution | Clerk             | [TIF Reports - Tax Increment Agency Distribution Reports](https://www.cookcountyclerkil.gov/property-taxes/tifs-tax-increment-financing/tif-reports) | [data-raw/tif/tif.R](data-raw/tif/tif.R)                         | TIF EAV, frozen EAV, and distribution percentage by tax code      |
 
-### Database diagram 
+### Database diagram
 
 <details>
 
@@ -339,7 +339,7 @@ erDiagram
     double  eq_factor_tentative
     double  eq_factor_final
   }
-  
+
   metadata {
     varchar db_version
     varchar requires_pkg_version
@@ -409,7 +409,7 @@ erDiagram
     int     first_year
     boolean cancelled_this_year
   }
-  
+
   tif_crosswalk {
     int     year
     varchar agency_num_dist
@@ -488,7 +488,7 @@ erDiagram
     double  eq_factor_tentative
     double  eq_factor_final
   }
-  
+
   metadata {
     varchar db_version
     varchar requires_pkg_version
@@ -501,7 +501,7 @@ erDiagram
     varchar pin                PK
     varchar class
   }
-  
+
   pin_geometry {
     int     year
     varchar pin10
@@ -584,45 +584,7 @@ The PTAXSIM database is updated whenever [all the data necessary](#data-sources)
 
 ### Checklists
 
-The process of updating the package and/or database can be somewhat involved. As such, please follow the checklists below when creating new releases:
-
-#### Package
-
-- [ ] Make your code updates and commit them in a branch
-- [ ] Make sure your code updates meet styling and linting requirements:
-  - *Styling*: Run `styler::style_pkg()` in the console
-  - *Linting*: Run `lintr::lint_package()` in the console
-- [ ] Build any documentation updates by running `devtools::document()` in the console
-- [ ] Run the build and test processes locally to check for errors:
-  - *Build*: In RStudio, go to the **Build** tab, then hit **Check**
-  - *Test*: In RStudio, go to the **Build** tab, then hit **Test** OR `devtools::test()` in the console
-- [ ] Check the vignettes by building them locally. Run `pkgdown::build_site()` in the console
-- [ ] Rebuild the README manually. Knit `README.Rmd` from within RStudio
-- [ ] Increment the package version in the `DESCRIPTION` file appropriately, following the [schema](#schema) laid out above
-- [ ] If the code updates were so substantial that the current database also needs to be updated, follow the database release checklist below
-- [ ] Push the code updates to GitHub. Wait for the resulting CI pipeline to finish
-- [ ] If there are no pipeline errors, merge the branch to master
-- [ ] Wait for the merge CI pipeline to finish. If there are no errors, cut a new release from master. Create a new git tag with the version number and title the release with the same version number. Be sure to add a changelog detailing what you updated
-
-#### Database
-
-- [ ] Make your code updates and commit them in a branch
-- [ ] Make any necessary updates to the raw data. If necessary, force add the raw data files if they are ignored by git. Be sure to update `.gitattributes` such that the raw data files are tracked by git LFS
-- [ ] Run the raw data scripts (anything in `data-raw/`) that prepare and clean the data. These scripts will save the cleaned data to a staging area in S3. Ensure that the relevant S3 keys in the PTAXSIM bucket are updated using the AWS console or API
-- [ ] Inside `data-raw/create_db.R`, increment the `db_version` variable following the [schema outlined above](#schema)
-- [ ] If necessary, also increment the `requires_pkg_version` variable in `data-raw/create_db.R`
-- [ ] Increment the database versions in `DESCRIPTION` file:
-  - `Config/Requires_DB_Version`: This is the minimum database version required for this version of the package. It should be incremented whenever there is a breaking change
-  - `Config/Wants_DB_Version`: This is the maximum database version required for this version of the package. It is the version of the database pulled from S3 during CI/testing on GitHub
-- [ ] If necessary, be sure to update the SQL statements in `data-raw/create_db.sql`. These statements define the structure of the database
-- [ ] Run the database generation script `data-raw/create_db.R`. This will create the SQLite database file by pulling data from S3. The file will be generated in a temporary directory (usually `/tmp/Rtmp...`), then compressed using `pbzip2` (required for this script)
-- [ ] Using the command line, grab the final compressed database file from the temporary directory (found at `db_path` after running `data-raw/create_db.R`) and move it to the project directory. Rename the file `ptaxsim-<TAX_YEAR>.<MAJOR VERSION>.<MINOR VERSION>.db.bz2`
-- [ ] Decompress the database file for local testing using `pbzip2`. The typical command will be something like `pbzip2 -d -k ptaxsim-2021.0.2.db.bz2`
-- [ ] Rename the decompressed local database file to `ptaxsim.db` for local testing. This is the file name that the unit tests and vignettes expect
-- [ ] Restart R. Then run the unit tests (`devtools::test()` in the console) and vignettes (`pkgdown::build_site()` in the console) locally
-- [ ] Knit the `README.Rmd` file to update the database link at the top of the README. The link is pulled from the `ptaxsim.db` file's `metadata` table
-- [ ] If necessary, update the database diagrams in the README with any new fields or tables
-- [ ] Move the compressed database file to S3 for public distribution. The typical command will be something like `aws s3 mv ptaxsim-2021.0.2.db.bz2 s3://ccao-data-public-us-east-1/ptaxsim/ptaxsim-2021.0.2.db.bz2`
-- [ ] Use the S3 console (or API) to make the database file public via an ACL
-- [ ] Push the code updates on GitHub. Wait for the resulting CI pipeline to finish
-- [ ] If there are no pipeline errors, merge the branch to master
+The process of updating the package and/or database can be somewhat involved. As such, please use the following release checklists when creating a new version:
+
+- [Database release checklist](https://github.com/ccao-data/ptaxsim/issues/new?assignees=&labels=release&projects=&template=release-database.md&title=Database+release+%5BVERSION%5D)
+- [Package release checklist](https://github.com/ccao-data/ptaxsim/issues/new?assignees=&labels=release&projects=&template=release-package.md&title=Package+release+%5BVERSION%5D)