docs: update contributing information [skip release] (#1011)

* docs: update CONTRIBUTING.md

* docs:  use db instead of database for more space

* docs: update CONTRIBUTING.md

* docs: update PR template

* docs: add note about skipping a release

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,10 +7,8 @@ this project (found in the CODE_OF_CONDUCT.md file).
 Also, please make sure you're familiar with and follow the instructions in the
 contributing guidelines (found in the CONTRIBUTING.md file).
 
-Note before creating the Pull Request. Even though the CONTRIBUTONG.md tells otherwise, we ask you to use the `canary` branch as base for your PR. We are tranistioning to a new structure, and the CONTRIBUTONG.md file has not been updated yet. Thank you!
-
 If you're new to contributing to open source projects, you might find this free
-video course helpful: http://kcd.im/pull-request
+video course helpful: https://kcd.im/pull-request
 
 Please fill out the information below to expedite the review and (hopefully)
 merge of your pull request!

CONTRIBUTING.md

@@ -8,48 +8,26 @@ Please see the [Code of Conduct](CODE_OF_CONDUCT.md) and follow any templates co
 
 Please raise any significant new functionality or breaking change an issue for discussion before raising a Pull Request for it.
 
-## Pull Requests
+## For contributors
 
-* The latest changes are always in `main` 
-* Pull Requests should be raised for larger changes
-* Pull Requests do not need approval before merging for those with contributor access (it's just helpful to have them to track changes)
-* Rebasing in Pull Requests is preferred to keep a clean commit history (see below)
-* Running `npm run lint:fix` before committing can make resolving conflicts easier, but is not required
-* Merge commits (and pushing merge commits to `main`) are disabled in this repo, but commits in PR can be squashed so this is not a blocker
-* Pushing directly to main should ideally be reserved for minor updates (e.g. correcting typos) or small single-commit fixes
-
-## Rebasing
-
-*If you don't rebase and end up with merge commits in a PR then it's not a blocker, we can always squash the commits when merging!*
-
-If you create a branch and there are conflicting updates in the `main` branch, you can resolve them by rebasing from a check out of your branch:
-
-    git fetch
-    git rebase origin/main
-
-If there are any conflicts, you can resolve them and stage the files, then run:
-
-    git rebase --continue
+Anyone can be a contributor. Either you found a typo, or you have an awesome feature request you could implement, we encourage you to create a Pull Request.
+### Pull Requests
 
-*If there are a lot of changes you may be prompted to step more than once.*
-
-When the rebase is complete (i.e. there are no more conflicts) you should push your changes to your branch before doing anything else:
-
-   git push --force-with-lease
-
-You should see that any conflicts in your PR are now resolved. You can review changes to make sure it contains changes you intended to make.
-
-*If you accidentally sync before pushing, it will trigger a merge. You can use `git merge --abort` to undo the merge.*
-
-You can use `npm run lint:fix` to automatically apply Standard JS rules to resolve formatting differences (tabs vs spaces, line endings, etc).
+* The latest changes are always in `canary`, so please make your Pull Request against that branch.
+* Pull Requests should be raised for any changes
+* Pull Requests need approval of a [core contributor](https://next-auth.js.org/contributors#core-team) before merging
+* Rebasing in Pull Requests is preferred to keep a clean commit history (see below)
+* Running `npm run lint:fix` before committing can make resolving conflicts easier
+* We encourage you to test your changes, and if you have the opportunity, please make those tests part of the Pull Request
+* If you add new functionality, please provide the corresponding documentation as well and make it part of the Pull Request
 
-## Setting up local environment
+### Setting up local environment
 
 A quick and dirty guide on how to setup *next-auth* locally to work on it and test out any changes:
 
 1. Clone the repo:
 
-       git clone git@github.com:iaincollins/next-auth.git
+       git clone git@github.com:nextauthjs/next-auth.git
        cd next-auth/
 
 2. Install packages and run the build command:
@@ -75,7 +53,7 @@ Notes: You may need to repeat both `npm link` steps if you install / update addi
 
 If you need an example project to link to, you can use [next-auth-example](https://github.com/iaincollins/next-auth-example).
 
-### Hot reloading
+#### Hot reloading
 
 You might find it helpful to use the `npm run watch` command in the next-auth project, which will automatically (and silently) rebuild JS and CSS files as you edit them.
 
@@ -104,19 +82,19 @@ module.exports = {
 }
 ```
 
-### Databases
+#### Databases
 
 Included is a Docker Compose file that starts up MySQL, Postgres, and MongoDB databases on localhost.
 
-It will use port 3306, 5432, and 27017 on localhost respectively; it will not work if are running existing databases on localhost.
+It will use port `3306`, `5432`, and `27017` on localhost respectively; please make sure those ports are not used by other services on localhost.
 
 You can start them with `npm run db:start` and stop them with `npm run db:stop`.
 
 You will need Docker installed to be able to start / stop the databases.
 
 When stopping the databases, it will reset their contents.
 
-### Testing
+#### Testing
 
 Tests can be run with `npm run test`.
 
@@ -125,3 +103,39 @@ Automated tests are currently crude and limited in functionality, but improvemen
 Currently, to run tests you need to first have started local test databases (e.g. using `npm run db:start`).
 
 The databases can take a few seconds to start up, so you might need to give it a minute before running the tests.
+
+## For maintainers
+
+We use [semantic-release](https://github.com/semantic-release/semantic-release) together with [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) to automate releases. This makes the maintainenance process easier and less error-prone to human error. Please study the "Conventional Commits" site to understand how to write a good commit message.
+
+When accepting Pull Requests, make sure the following:
+
+* Use "Squash and merge"
+* Make sure you merge contributor PRs into `canary`
+* Rewrite the commit message to conform to the `Conventional Commits` style. Check the "Recommended Scopes" section for further advice.
+* Optionally link issues the PR will resolve (You can add "close" in front of the issue numbers to close the issues automatically, when the PR is merged. `semantic-release` will also comment back to connected issues and PRs, notifying the users that a feature is added/bug fixed, etc.)
+
+### Recommended Scopes
+
+A typical conventional commit looks like this:
+```
+type(scope): title
+
+body
+```
+
+Scope is the part that will help groupping the different commit types in the release notes.
+
+Some recommened scopes are:
+
+- **provider** - Provider related changes. (eg.: "feat(provider): add X provider", "docs(provider): fix typo in X documentation"
+- **adapter** - Adapter related changes. (eg.: "feat(adapter): add X provider", "docs(provider): fix typo in X documentation"
+- **db** - Database related changes. (eg.: "feat(db): add X database", "docs(db): fix typo in X documentation"
+- **deps** - Adding/removing/updating a dependency (eg.: "chore(deps): add X")
+
+> NOTE: If you are not sure which scope to use, you can simply ignore it. (eg.: "feat: add something"). Adding the correct type already helps a lot when analyzing the commit messages.
+
+
+### Skipping a release
+
+Every commits that contains [skip release] or [release skip] in their message will be excluded from the commit analysis and won't participate in the release type determination. This is useful, if the PR being merged should not trigger a new `npm` release.