docs: update contribution docs (#2018)

.github/pull_request_template.md

@@ -33,7 +33,7 @@ _Ensure **all** of these are met:_
 - [ ] _The change has been tested to work (see above) and doesn't appear to break other things_
 - [ ] _Documentation has been updated if needed (`README.md`, help menu, docs, configs, etc.)_
 - [ ] _There are no merge conflicts_
-- [ ] _You have reviewed the changes first_
+- [ ] _You have reviewed your changes first_
 - [ ] _The pull request passes the provided CI pipeline_
 
 ## Other

CONTRIBUTING.md

@@ -15,19 +15,26 @@ Please fill out the [feature request template](https://github.com/ClementTsang/b
 
 ## Pull requests
 
-If you want to directly contribute documentation changes or code, follow this! The expected workflow for a pull request is:
+The expected workflow for a pull request is:
 
 1. Fork the project.
 2. Make your changes.
 3. Make any documentation changes if necessary - if you add a new feature, it'll probably need documentation changes. See [here](https://bottom.pages.dev/nightly/contribution/documentation/) for tips on documentation.
-4. Commit and create a pull request to merge into the `main` branch. **Please fill out the pull request template**.
+4. Commit and create a pull request to merge into the `main` branch. **Please fill out the pull request template and checklist**.
 5. Ask a maintainer to review your pull request.
    - Check if the CI workflow passes. These consist of clippy lints, rustfmt checks, and basic tests. If you are a
      first-time contributor, you may need to wait for a maintainer to let CI run.
    - If changes are suggested or any comments are made, they should probably be addressed.
-6. Once it looks good, it'll be merged! Note that _generally_, PRs are squashed to maintain repo cleanliness, though
+6. Once it looks good, it'll be merged! Note that generally, PRs are squashed to maintain repo cleanliness, though
    feel free to ask otherwise if that isn't preferable.
 
+Some other things related to making changes or pull requests:
+
+- Please review your code _yourself_ before you create the PR and ask for a review.
+  - I'm fine if you use AI to help with your change, but I expect you to still review the changes yourself.
+- If you are adding or changing any dependency, I expect a justification on why this is necessary.
+- Please ensure that any changes made are compatible with the license of bottom.
+
 For more details, see [here](https://bottom.pages.dev/nightly/contribution/issues-and-pull-requests/).
 
 ### Documentation

docs/content/contribution/issues-and-pull-requests.md

@@ -31,11 +31,12 @@ The expected workflow for a pull request is:
    - Check if the CI workflow passes. These consist of clippy lints, rustfmt checks, and basic tests. If you are a
      first-time contributor, you may need to wait for a maintainer to let CI run.
    - If changes are suggested or any comments are made, they should probably be addressed.
-6. Once it looks good, it'll be merged! Note that _generally_, PRs are squashed to maintain repo cleanliness, though
+6. Once it looks good, it'll be merged! Note that generally, PRs are squashed to maintain repo cleanliness, though
    feel free to ask otherwise if that isn't preferable.
 
 Some other things related to making changes or pull requests:
 
 - Please review your code _yourself_ before you create the PR and ask for a review.
-  - If you're using AI to help with your changes, fine, but I expect you to still review the code yourself.
+  - I'm fine if you use AI to help with your change, but I expect you to still review the changes yourself.
 - If you are adding or changing any dependency, I expect a justification on why this is necessary.
+- Please ensure that any changes made are compatible with the license of bottom.