📝 Break out PR checklist into its own doc.

docs/CONTRIBUTING.md

@@ -54,7 +54,7 @@ In short, since you are most likely a developer, **provide a ticket that you wou
 
 - **Review the documentation** before opening a new issue.
 
-- **Do not open a duplicate issue!** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
+- **Try not to open a duplicate issue** Search through existing issues to see if your issue has previously been reported. If your issue exists, comment with any additional information you have. You may simply note "I have this problem too", which helps prioritize the most common problems and requests. 
 
 - **Prefer using [reactions](https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)**, not comments, if you simply want to "+1" an existing issue.
 
@@ -80,8 +80,6 @@ You can triage issues which may include reproducing bug reports or asking for ad
 
 We **love** pull requests! Before [forking the repo](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) and [creating a pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/proposing-changes-to-your-work-with-pull-requests) for non-trivial changes, it is usually best to first open an issue to discuss the changes, or discuss your intended approach for solving the problem in the comments for an existing issue.
 
-For most contributions, after your first pull request is accepted and merged, you will be [invited to the project](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) and given **push access**. :tada:
-
 *Note: All contributions will be licensed under the project's license.*
 
 - **Smaller is better.** Submit **one** pull request per bug fix or feature. A pull request should contain isolated changes pertaining to a single bug fix or feature implementation. **Do not** refactor or reformat code that is unrelated to your change. It is better to **submit many small pull requests** rather than a single large one. Enormous pull requests will take enormous amounts of time to review, or may be rejected altogether. 
@@ -157,15 +155,7 @@ See also: #456, #789
 
 ## :white_check_mark: Pull Request Checklist
 
-Not all Pull Requests require these things, but here's a great list of things to check to see if it makes sense for your situation:
-
- - [ ] Are the changes complete?
- - [ ] Are there tests for the new functionality?
- - [ ] Are the changes passing the style checks?
- - [ ] Is there documentation for the new functionality?
- - [ ] Has the change been added to `Changelog.md`?
- - [ ] Has the change been added to `ReleaseNotes.md`?
- - [ ] Have new config options been added as defaults to the `project.yml` files?
+Not all Pull Requests require these things, but [here's a great list](CeedlingPullRequestChecklist.md) of things to check to see if it makes sense for your situation:
 
 ## :heart: Who Loves Emoji?
 

docs/CeedlingPullRequestChecklist.md

@@ -0,0 +1,22 @@
+# 🌱 Ceedling Pull-Request Checklist
+
+Hello lovely developers! We hear you're interested in submitting some work to our project. Thanks! We really appreciate it! 
+
+Below is a quick checklist of the things that need to be done before a full PR is merged to our project. Don't worry. You're not responsible for ALL of it. We'll accept your contribution however you are able to make it, with our thanks. But if you have some extra time and would like to maximize your contribution, here's a handy reference!
+
+### Documentation
+
+ - [ ] Has `CeedlingPacket.md` been updated? (if it provides a new or changed feature)
+ - [ ] Has `ReleaseNotes.md` been updated? (if it provides a new or changed feature)
+ - [ ] Has `Changelog.md` been updated? (if it fixes something or provides something new)
+ - [ ] Has `BreakingChanges.md` been updated? (if it changes compatibility with something that has existed before)
+
+ ### Software
+
+ - [ ] Does it follow our coding standards?
+ - [ ] Are all existing tests passing?
+ - [ ] Are there new tests added and passing?
+ - [ ] Have new config options been added as defaults to the `project.yml` files?
+ - [ ] Does the feature follow our "Logical Defaults" philosophy where possible?
+ - [ ] Has it passed a peer review?
+ - [ ] Does it pass CI (continuous integration) tests?

plugins/fff/README.md

@@ -1,6 +1,6 @@
 # A Fake Function Framework Plug-in for Ceedling
 
-This is a plug-in for [Ceedling](https://github.com/ThrowTheSwitch/Ceedling) to use the [Fake Function Framework](https://github.com/ElectronVector/fake_function_framework) for mocking instead of CMock.
+This is a plug-in for [Ceedling](https://github.com/ThrowTheSwitch/Ceedling) to use the [Fake Function Framework](https://github.com/meekrosoft/fff) for mocking instead of CMock.
 
 Using _fff_ provides less strict mocking than CMock, and can allow for more loosely-coupled tests.