Update contribution guidelines and add a pull request template

.github/pull_request_template.md

@@ -0,0 +1,38 @@
+# Pull request overview
+<!-- Please be sure to review the Developer Documentation before submitting a pull request -->
+<!-- https://github.com/pnnl/building-energy-standards-data/blob/develop/docs/DeveloperNotes.md -->
+
+## Description
+<!-- Provide a description of the pull request -->
+
+## Type of Change
+<!-- Mark with an "x" all that apply -->
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] Documentation update
+- [ ] Code refactor/cleanup
+- [ ] Performance improvement
+- [ ] Database schema change
+
+## Related Issues
+<!-- Link any related issues here -->
+<!-- Fixes #123, Closes #456, Relates to #789 -->
+
+## Testing
+<!-- Describe the tests that you ran to verify your changes -->
+<!-- Provide instructions so we can reproduce -->
+- [ ] Unit tests pass locally
+- [ ] Integration tests pass locally
+
+## Screenshots (if applicable)
+<!-- Add screenshots to help explain your changes -->
+
+## Items to complete before requesting a review
+- [ ] All unit tests pass and follow [Black](https://github.com/psf/black) formatting standards
+- [ ] New code includes unit tests (except database table additions)
+- [ ] Documentation updated if changes affect database structure or contribution process
+- [ ] Code is well-documented and thoroughly tested
+
+## Additional Notes
+<!-- Any additional information that reviewers should know -->

docs/DeveloperNotes.md

@@ -1,9 +1,11 @@
 # Notes for Developers
 ## Contribution Guidelines
+### How to contribute
+All contributions have to go through a pull request and be reviewed by the repository maintainers. One can contribute to the code base via a pull request by either forking the repository or by reaching out to the maintainers and getting added to the list of contributors. Issue reports are welcomed from anyone.
 ### Code Formatting
-Consistent code formatting is enforced by using the [Black Python code formatter](https://github.com/psf/black). Tests are run to make sure that any changes to the code is consistent with Black's formatting standards. Before creating a pull request and after installing Black, run `black -l 88 ./` to format all Python files within this directory.
+Consistent code formatting is enforced by using the [Black Python code formatter](https://github.com/psf/black). Tests are run to make sure that any changes to the code are consistent with Black's formatting standards. Before creating a pull request and after installing Black, run `black -l 88 ./` to format all Python files within this directory.
 ### Tests
-A small set of tests have been implemented, mostly to make sure that further edits to the data or database structure is valid, and that JSON and CSV files generated from the database include the same content. Tests are run using a GitHub action, see the workflow YAML file in `../../.github/workflow/openstudio_standards_database.yml`.
+A small set of tests have been implemented, mostly to make sure that further edits to the data or database structure are valid, and that JSON and CSV files generated from the database include the same content. Tests are run using a GitHub action, see the workflow YAML file in `../../.github/workflow/openstudio_standards_database.yml`.
 ## Expanding the Database
 Developers wishing to expand the database do not need advanced SQL knowledge to do so. The following tips should provide enough information to expand the database.
 ### Adding Tables and Data for a New Code Versions
@@ -49,8 +51,8 @@ Data can be provided either in CSV or in the  JSON file format. The best approac
 4) Add a new CSV of JSON file in the data folder corresponding to the `initial_data_directory` attribute in the new table class,
 5) Re-generate the database.
 #### Tests
-A small set of tests have been implemented, mostly to make sure that further edits to the data or database structure is valid, and that JSON and CSV files generated from the database include the same content. After modifying the database, it is good practice to run the tests locally to verify the integrity of the database. From the root directory one can run the following command:
+A small set of tests have been implemented, mostly to make sure that further edits to the data or database structure are valid, and that JSON and CSV files generated from the database include the same content. After modifying the database, it is good practice to run the tests locally to verify the integrity of the database. From the root directory one can run the following command:
 ```
 pytest test
 ```
-An error will be displayed if the tests failed.
+An error will be displayed if the tests failed.

docs/Structure.md

@@ -32,7 +32,7 @@ The schedules used in the database were determined based on the PNNL led *Develo
 Different groups of occupants may exhibit varying behaviors influenced by factors such as the type of space, cultural background, and social context. The occupant types database is designed to capture diverse behavioral patterns and create a representative dataset that enables users to improve the building energy modeling and advance research on dynamic occupant behavior. 
 
 #### Occupant Types Data Structure
-This database is insipried by a previous work led by Lawrence Berkeley National Laboratory (LBNL) [(Sun and Hong 2017)](https://www.sciencedirect.com/science/article/abs/pii/S0378778817302013), which established a framework categorizing occupant types into three primary categories: 
+This database is inspired by a previous work led by Lawrence Berkeley National Laboratory (LBNL) [(Sun and Hong 2017)](https://www.sciencedirect.com/science/article/abs/pii/S0378778817302013), which established a framework categorizing occupant types into three primary categories:
 - energy behavior (including actions related to thermostat and lighting),
 - physical characteristics of occupants (including clothing insulation, work efficiency, CO2 generation, and air velocity),
 - 24-hour occupant schedule. 
@@ -50,7 +50,7 @@ The energy behavior is further divided into three categories:
 For physical characteristics, the options that can be modified by the user include clothing insulation, work efficiency, CO2 generation rate, and air velocity. 
 
 #### Occupancy Schedule
-Occupancy density over 24 hours on weekdays and weekends is based on the analysis of the multiple years of the [American Time Use Survey](https://www.bls.gov/tus/). The clustering algorithm determined four optimal clusters: early birds, late owls, regular 8-hour workers, and night shift workers,the clustering result can be seen in following figure. Default values for each cluster are based on their respective ratios.
+Occupancy density over 24 hours on weekdays and weekends is based on the analysis of the multiple years of the [American Time Use Survey](https://www.bls.gov/tus/). The clustering algorithm determined four optimal clusters: early birds, late owls, regular 8-hour workers, and night shift workers, the clustering result can be seen in the following figure. Default values for each cluster are based on their respective ratios.
 
 ![Occupant schedule clustering](ATUS_schedule.drawio.png "Occupant schedule clustering")
 
@@ -67,4 +67,4 @@ The specific details of each subcategory of design occupant types are summarized
 <tr><td>CO<sub>2</sub> generation rate</td><td><a href="https://www.ashrae.org/technical-resources/standards-and-guidelines/read-only-versions-of-ashrae-standards">ANSI/ASHRAE Standard 62.1-2017 </td><td>A default metabolic rate of 1 met is assumed.</td><td></tr>
 </table>
 
-**Notice**: This initial design of the occupant types database focuses specifically on office space types and has not yet been integrated into simulation software. 
+**Notice**: This initial design of the occupant types database focuses specifically on office space types and has not yet been integrated into simulation software.