Project Updates

.github/PULL_REQUEST_TEMPLATE.md

@@ -63,12 +63,13 @@
 
 
 ### Other:
+- [ ] I have read through and followed the Contributing Guidelines
 - [ ] I have searched through the GitHub pull requests to ensure this PR has not already been submitted
 - [ ] I have updated the Dynamoose documentation (if required) given the changes I made
 - [ ] I have added/updated the Dynamoose test cases (if required) given the changes I made
 - [ ] I have ensured the following commands are successful from the root of the project directory
   - [ ] `npm test`
   - [ ] `npm run lint`
-- [ ] I agree that all changes made in this pull request may be distributed and are made available in accordance with the [Dynamoose license](https://github.com/dynamoosejs/dynamoose/blob/master/LICENSE)
+- [ ] I agree that all changes made in this pull request may be distributed and are made available in accordance with the [Dynamoose license](https://github.com/dynamoose/dynamoose/blob/master/LICENSE)
 - [ ] All of my commits and commit messages are detailed, explain what changes were made, and are easy to follow and understand
 - [ ] I have filled out all fields above

.github/workflows/publish.yml

@@ -9,6 +9,7 @@ jobs:
     runs-on: ubuntu-latest
     outputs:
       npmtag: ${{ steps.data.outputs.npmtag }}
+      websites3bucket: ${{ steps.data.outputs.websites3bucket }}
     steps:
       - uses: actions/checkout@v2
       - run: npm i
@@ -31,7 +32,7 @@ jobs:
           TAG: ${{ needs.getinfo.outputs.npmtag }}
           NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
 
-  # TODO: I'm pretty sure this is failing because the package.json name is not scoped (ex. `@dynamoosejs/dynamoose`). We should maybe add a step in here to scope it just for publishing this one package.
+  # TODO: I'm pretty sure this is failing because the package.json name is not scoped (ex. `@dynamoose/dynamoose`). We should maybe add a step in here to scope it just for publishing this one package.
   # publish-gpr:
   #   needs: getinfo
   #   runs-on: ubuntu-latest
@@ -46,3 +47,31 @@ jobs:
   #       env:
   #         TAG: ${{ needs.getinfo.outputs.npmtag }}
   #         NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+  publishsite:
+    needs: getinfo
+    runs-on: ubuntu-latest
+    if: needs.getinfo.outputs.websites3bucket != ''
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v1
+      - run: npm run site:install
+      - run: npm run site:build
+      - uses: jakejarvis/s3-sync-action@v0.5.1
+        with:
+          args: --follow-symlinks --delete --cache-control 's-maxage=604800, max-age=0'
+        env:
+          AWS_S3_BUCKET: ${{ needs.getinfo.outputs.websites3bucket }}
+          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+          AWS_REGION: 'us-west-2'
+          SOURCE_DIR: 'docs/build'
+      - name: Purge Cloudflare Cache
+        run: |
+          curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" \
+            -H "Authorization: Bearer $TOKEN" \
+            -H "Content-Type: application/json" \
+            --data '{"purge_everything":true}'
+        env:
+          TOKEN: ${{ secrets.CLOUDFLARE_TOKEN }}
+          ZONE: ${{ secrets.CLOUDFLARE_ZONE }}

CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team [here](https://charlie.fish/contact). All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -0,0 +1,103 @@
+# Contributing to Dynamoose
+
+:+1::tada: **THANK YOU** for taking the time to contribute! :tada::+1:
+
+The following is a set of guidelines for contributing to Dynamoose and all projects in the [dynamoose Organization](https://github.com/dynamoose) on GitHub. Although these are strongly encouraged guidelines, nothing about this project is set in stone, if you believe something here should be edited, open a pull request to start a discussion about it.
+
+## Code of Conduct
+
+This project and everyone participating in it is governed by the [Dynamoose Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to the contact method in the [Code of Conduct](CODE_OF_CONDUCT.md).
+
+## What should I know before I get started?
+
+### Documentation
+
+All of the documentation for the project is housed within the `docs/docs` folder. The general website is housed within the `docs` folder. It is important while contributing to Dynamoose to ensure that the documentation is complete, up to date, and helpful.
+
+### Resources
+
+It is highly encouraged to read through the following resources before contributing.
+
+- [README](README.md)
+- [Website](https://dynamoosejs.com)
+
+## How Can I Contribute?
+
+### Reporting Bugs
+
+When reporting bugs please fill out the issue template with as much detail as possible. If you do not fill out the issue template with enough detail for us to debug your issue, your issue is at risk for being closed.
+
+#### Minimal, Complete and Verifiable Example (MCVE)
+
+One of the most important things when submitting an issue is to provide a *Minimal, Complete and Verifiable Example* (or MCVE for short). If you are reporting a bug it is important for us to be able to test and debug your code as quickly as possible.
+
+- *Minimal* – Use as little code as possible that still produces the same problem
+- *Complete* – Provide all parts needed to reproduce your problem
+- *Reproducible* – Test the code to make sure it reproduces the problem
+
+Without following these steps when creating code examples it is nearly impossible for us to debug your issue. Help us help you by putting time and care into code examples. Not following this guideline puts your issue at risk for being closed.
+
+### Submitting a Pull Request (PR)
+
+It is highly recommended (although not required) to follow the pattern below before submitting a pull request. Not every step below will be relevant to all pull requests.
+
+#### Before
+
+1. **Identify a need in the project** - This can be a bug, feature request, or other change.
+2. **Create a detailed issue to gauge interest** - Although most pull requests are merged, we don't want you to waste time creating a pull request that doesn't have the support of the community. This doesn't mean that even if the community supports an issue that the corosponding pull request will be merged, but it increases the chances with community support. *This step is highly encouraged for larger contributions, but not required. For smaller contributions (typos, adding tests, updating documentaion, minor code changes, etc.) it is not necessary to create a seperate issue.*
+3. **Read through the `package.json`** - The `package.json` file in the root of the repository has a **lot** of useful information about the project. Especially read through the `scripts` section, as a lot of those scripts can help speed up your development process when working in Dynamoose. There are scripts for running tests, building the website, debugging code, fixing lint issues, etc.
+
+#### During
+
+1. **Create a fork & branch** - Before contributing to Dynamoose you must create a fork of the [main repository](https://github.com/dynamoose/dynamoose) and create a branch on your fork. It is highly discouraged from using a primary branch (ex. `master` or `alpha`) to make your changes. This is due to the fact that if you enable `Allow edits from maintainers` option, maintainers might commit directly to your primary branch which could cause problems if others are using your fork in their applications.
+2. **Install dependencies** - Run `npm install` to install all the dependencies of the project.
+3. **Maintain consistency throughout** - While working in the project, we highly encourage you to maintain the same coding style that the rest of the project uses. This means looking around at similar code and trying to adopt the same style and conventions in your code.
+4. **Run tests & linter often** - It is highly encouraged to run `npm test` & `npm run lint` often to ensure you are conforming to the project guidelines. In order for a pull request to be merged all tests must pass, the linter must throw no errors, and test code coverage must not decrease.
+5. **Write tests** - While (or better yet, before) making changes you should write tests in the test suite to ensure things work as expected.
+	1. **Test Edge Cases** - While writing tests try to consider edge cases that might occur and write test for those edge cases. For example, what happens if you a user passes in no arguments, or what happens if the type passed in is not the type you expect.
+	2. **Code Coverage Must Not Decrease** - Your pull request will not be merged if it decreases the code coverage for tests, so it is important to write tests to ensure any code added or modified is covered by tests.
+	3. **No Log Output** - It is also important that your tests do not print any output to the console or logs, this includes `console.log`, UncaughtPromiseExceptions, etc. All logs printed should come directly from Mocha.
+	4. **One Test Must Fail Prior to Code Changes** - At *least* one test you write should fail without the code changes you have made.
+	5. **Self Contained and Static** - All tests should be self contained and should not rely on each other in order to pass. All tests must also be static and have no potiental of failing based on random or outside factors.
+	6. **Logic inside Mocha Blocks** - All test logic should take place within Mocha blocks (ex. `it`, `before`, `beforeEach`, `after` or `afterEach`). No interaction with Dynamoose or outside references should take place outside of those blocks (ex. you should not create models or schemas in the global or `describe` scope).
+6. **Update documentation** - For anything that effects users using Dynamoose, documentation should be added/deleted/modified to reflect the changes you have made. It is important to ensure the documentation you write is as clear as possible, giving examples, and attempting to answer as many relevent questions as possible.
+7. **Commit small & often** - Please commit changes often and keep commit size to a minimum. It is highly discouraged from creating one massive commit with all of your changes in it. Every commit should also aim to pass the linter and tests. Commit messages should also be detailed enough to give a good explaination of the change made. Commit messages such as `changes` or `did stuff` are considered **poor** commit messages.
+
+#### After
+
+1. **Submit the pull request** - When submitting the pull request it is important to fill out the complete pull request template. This ensures reviewers of your pull request can easily understand what is going on and make sure all guidelines and requirements have been met. It is also highly recommended to enable the `Allow edits from maintainers` option (be aware that enabling this option means that maintainers have the right to commit to your branch at any time, *we do use this ability*).
+2. **Be prepared for questions and suggestions** - As others review your pull request it is important to be available to answer questions and promptly respond to code suggestions. Stale pull requests run the risk of being closed, even if it's a large change or a lot of effort was put into it.
+3. **Ask others for reviews** - If you know someone who is anticipating your work, ask them to test your branch and leave a detailed review on the pull request.
+
+#### Release
+
+Dynamoose does not currently have a release schedule that we conform to. We atttempt to batch work into a release every so often. If you have a need that requires us releasing a version sooner, please notify us, and we will attempt to cut a new release earlier (however this is not guaranteed, and you are still welcome to point to a branch in NPM if we are unable to release on your timeline).
+
+## How do I become a project maintainer?
+
+At this time we are pretty strict in terms of who gets write/merge access to Dynamoose. The following are general guidelines we look for before granting those permissions, but other factors may apply depending on the situation.
+
+1. **Activity** - Likely the most important factor is we need to see you remain active on the project for an extended period of time. We want maintainers to be active and although we don't require maintainers to dedicated all their time to Dynamoose, we are looking for maintainers to be active in the community.
+2. **Contributions** - We are looking for project maintainers to be active in contributing feedback, features, bug fixes, documentation improvements, and more to the project. Short verison: we want project maintainers to show that they are dedicated to improving the project.
+
+In short, some starting tips towards becoming a project maintainer include:
+
+1. Submit pull requests to improve the project
+2. Answer questions in Slack or Stack Overflow
+3. Reply to issues on GitHub
+
+If you believe you have a case for becoming a project maintainer and feel as tho you meet those requirements [contact me](https://charlie.fish/contact) or reach out on Slack (Charlie Fish) and I'd be happy to discuss next steps with you.
+
+It is also important to note that if you become a project maintainer, and become inactive on the project, your project maintainer status may be revoked.
+
+---
+
+## What do project maintainers need to know?
+
+The following section is unlikely to be useful to general contributors to Dynamoose, and is reserved for project maintainers.
+
+### Release
+
+In order to release a version of Dynamoose you can kick off this process by running `node publish`. This will kick off the release process. Following the steps it guides you through should lead to a successful release. Please [contact me](https://charlie.fish/contact) or message me on the Dynamoose Slack (Charlie Fish) if you have questions or run into any issues.
+
+It is important to note that you must have write permissions to the `master` branch in order for this process to be successful.