doc: point to organization guidelines

Signed-off-by: Yuki Kishimoto <[email protected]>

Author: yukibtc

CODE_STYLE.md

@@ -1,20 +1,14 @@
-# Contributing to rust-nostr
+# Contributing
 
-## Contribution Workflow
+## Organization guidelines
 
-Before writing code, please read [our code style](./CODE_STYLE.md).
+This project follows the rust-nostr organization guidelines: https://github.com/rust-nostr/guidelines
 
-To contribute a patch:
+## Additional repository guidelines
 
-- Fork Repository 
-- Create topic branch 
-- Commit patches (PR, emails, ...)
+### Commit Style
 
-In general commits should be atomic and diffs **easy to read**.
-
-## Commit Style
-
-The commit **must** be formatted as following:
+The commit **must** be formatted as follows:
 
 ```
 <context>: <short descriptrion>
@@ -61,35 +55,8 @@ nwc: add `pay_multiple_invoices` support
 Closes https://<domain>.com/rust-nostr/nostr/issue/2222
 ```
 
-## Deprecation policy
-
-Where possible, breaking existing APIs should be avoided.
-Instead, add new APIs and use 
-[`#[deprecated]`](https://github.com/rust-lang/rfcs/blob/master/text/1270-deprecation.md)
-to discourage use of the old one.
-
-Deprecated APIs are typically maintained for one release cycle.
-In other words, an API that has been deprecated with the 0.10 release 
-can be expected to be removed in the 0.11 release.
-This allows for smoother upgrades without incurring too much technical debt inside this library.
-
-If you deprecated an API as part of a contribution, we encourage you to "own" that API
-and send a follow-up to remove it as part of the next release cycle.
-
-## Coding Conventions
+### Coding Conventions
 
 Install https://github.com/casey/just and use `just precommit` or `just check` 
 to format and check the code before committing.
-This is also enforced by the CI.
-
-### Terminology
-
-Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them.
-
-utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested them.
-
-tACK (tested ACK) - Reviewed the code changes and have verified the functionality or bug fix.
-
-ACK - A loose ACK can be confusing. It's best to avoid them unless it's a documentation/comment only change in which case there is nothing to test/verify; therefore the tested/untested distinction is not there.
-
-NACK - Disagree with the code changes/concept. Should be accompanied by an explanation.
+The CI also enforces this.

CONTRIBUTING.md

@@ -1,17 +1,3 @@
 # Reporting a Vulnerability
 
-To report security issues send an email to **[email protected]**
-
-The following keys may be used to communicate sensitive information to developers:
-
-| Name                | Fingerprint                                                                                                                |
-| ------------------- | -------------------------------------------------------------------------------------------------------------------------- |
-| Yuki Kishimoto      | 86F3 105A DFA8 AB58 7268  DCD7 8D3D CD04 2496 19D1                                                                         |
- 	
-You can import a key by running the following command with that individual’s fingerprint: 
-
-```
-gpg --keyserver hkps://keys.openpgp.org --recv-keys "<fingerprint>"
-``` 
-
-Ensure that you put quotes around fingerprints containing spaces.
+For security vulnerability reporting and our complete security policy, please see: https://github.com/rust-nostr/guidelines