[wip] update contrib

contrib/CODE_REVIEW_DOCS.md

@@ -1,25 +1,4 @@
 # Code Review
-### Conceptual Review
-
-A review can be a conceptual review, where the reviewer leaves a comment
- * `Concept (N)ACK`, meaning "I do (not) agree with the general goal of this pull
-   request",
- * `Approach (N)ACK`, meaning `Concept ACK`, but "I do (not) agree with the
-   approach of this change".
-
-A `NACK` needs to include a rationale why the change is not worthwhile.
-NACKs without accompanying reasoning may be disregarded.
-After conceptual agreement on the change, code review can be provided. A review
-begins with `ACK BRANCH_COMMIT`, where `BRANCH_COMMIT` is the top of the PR
-branch, followed by a description of how the reviewer did the review. The
-following language is used within pull request comments:
-
-  - "I have tested the code", involving change-specific manual testing in
-    addition to running the unit, functional, or fuzz tests, and in case it is
-    not obvious how the manual testing was done, it should be described;
-  - "I have not tested the code, but I have reviewed it and it looks
-    OK, I agree it can be merged";
-  - A "nit" refers to a trivial, often non-blocking issue.
 
 ### Code Review
 Project maintainers reserve the right to weigh the opinions of peer reviewers
@@ -40,33 +19,11 @@ a worthwhile change based on the judgement of the maintainers.
 
 ### Finding Reviewers
 
-As most reviewers are themselves developers with their own projects, the review
-process can be quite lengthy, and some amount of patience is required. If you find
-that you've been waiting for a pull request to be given attention for several
-months, there may be a number of reasons for this, some of which you can do something
-about:
+Add `Cortex` to the reviewers of your PR. If you are unable to add this group (as can happen with
+forks), you can directly add the maintainers: [basfroman](https://github.com/basfroman), 
+[thewhaleking](https://github.com/thewhaleking), and [ibraheem-abe](https://github.com/ibraheem-abe).
 
-  - It may be because of a feature freeze due to an upcoming release. During this time,
-    only bug fixes are taken into consideration. If your pull request is a new feature,
-    it will not be prioritized until after the release. Wait for the release.
-  - It may be because the changes you are suggesting do not appeal to people. Rather than
-    nits and critique, which require effort and means they care enough to spend time on your
-    contribution, thundering silence is a good sign of widespread (mild) dislike of a given change
-    (because people don't assume *others* won't actually like the proposal). Don't take
-    that personally, though! Instead, take another critical look at what you are suggesting
-    and see if it: changes too much, is too broad, doesn't adhere to the
-    [developer notes](DEVELOPMENT_WORKFLOW.md), is dangerous or insecure, is messily written, etc.
-    Identify and address any of the issues you find. Then ask e.g. on IRC if someone could give
-    their opinion on the concept itself.
-  - It may be because your code is too complex for all but a few people, and those people
-    may not have realized your pull request even exists. A great way to find people who
-    are qualified and care about the code you are touching is the
-    [Git Blame feature](https://docs.github.com/en/github/managing-files-in-a-repository/managing-files-on-github/tracking-changes-in-a-file). Simply
-    look up who last modified the code you are changing and see if you can find
-    them and give them a nudge. Don't be incessant about the nudging, though.
-  - Finally, if all else fails, ask on IRC or elsewhere for someone to give your pull request
-    a look. If you think you've been waiting for an unreasonably long time (say,
-    more than a month) for no particular reason (a few lines changed, etc.),
-    this is totally fine. Try to return the favor when someone else is asking
-    for feedback on their code, and the universe balances out.
-  - Remember that the best thing you can do while waiting is give review to others!
+The maintainers generally try to commit at least a small portion of time each day to reviewing community PRs. 
+However, in some cases, new PRs can be missed. If your PR has been sitting in an unreviewed status for longer 
+than a few business days (Monday - Friday), feel free to tag us on the [Church of Rao](https://discord.gg/brRAeVCmzM) 
+[#btcli-btsdk](https://discord.com/channels/1120750674595024897/1242999357436071956) Discord channel.