Update CONTRIBUTING.md for archiving

Signed-off-by: Andrew Clayton <[email protected]>

Author: dwmcallister

CONTRIBUTING.md

@@ -1,94 +1,3 @@
-# Contributing Guidelines
-
-The following is a set of guidelines for contributing to NGINX Unit.  We do
-appreciate that you are considering contributing!
-
-## Table Of Contents
-
-- [Getting Started](#getting-started)
-- [Ask a Question](#ask-a-question)
-- [Contributing](#contributing)
-- [Git Style Guide](#git-style-guide)
-
-
-## Getting Started
-
-Check out the [Quick Installation](README.md#quick-installation) and
-[Howto](https://unit.nginx.org/howto/) guides to get NGINX Unit up and
-running.
-
-
-## Ask a Question
-
-Please open an [issue](https://github.com/nginx/unit/issues/new) on GitHub
-with the label `question`.  You can also ask a question on
-[GitHub Discussions](https://github.com/nginx/unit/discussions) or the NGINX
-Unit mailing list, [email protected] (subscribe
-[here](https://mailman.nginx.org/mailman3/lists/unit.nginx.org/)).
-
-
-## Contributing
-
-### Report a Bug
-
-Ensure the bug was not already reported by searching on GitHub under
-[Issues](https://github.com/nginx/unit/issues).
-
-If the bug is a potential security vulnerability, please report using our
-[security policy](https://unit.nginx.org/troubleshooting/#getting-support).
-
-To report a non-security bug, open an
-[issue](https://github.com/nginx/unit/issues/new) on GitHub with the label
-`bug`.  Be sure to include a title and clear description, as much relevant
-information as possible, and a code sample or an executable test case showing
-the expected behavior that doesn't occur.
-
-
-### Suggest an Enhancement
-
-To suggest an enhancement, open an
-[issue](https://github.com/nginx/unit/issues/new) on GitHub with the label
-`enhancement`.  Please do this before implementing a new feature to discuss
-the feature first.
-
-
-### Open a Pull Request
-
-Before submitting a PR, please read the NGINX Unit code guidelines to know
-more about coding conventions and benchmarks.  Fork the repo, create a branch,
-and submit a PR when your changes are tested and ready for review.  Again, if
-you'd like to implement a new feature, please consider creating a feature
-request issue first to start a discussion about the feature.
-
-
-## Git Style Guide
-
-- Create atomic commits.  A commit should do just one thing, i.e. you
-  shouldn't mix refactoring with functional code changes.  Do the
-  refactoring in one or more commits first.
-
-  Ideally you should rebase locally and force push new commits up.
-
-- In the subject line, use the imperative mood.  I.e. write the subject like
-  you're giving git a command, e.g. "Free memory before exiting". Do not
-  terminate the subject with a `.`
-
-- Try to limit the subject line to around 50 characters, but try not to
-  exceed 72.
-
-- Wrap the body of the commit message after 72 characters.
-
-- Use lowercase subject line prefixes for commits that affect a specific
-  portion of the code; examples include "tests:", "ci:", or "http:", and
-  also individual languages such as "python:" or "php:".  If multiple areas
-  are affected you can specify multiple prefixes, e.g. "auto, perl:"
-
-- If the commit fixes an open issue then you can use the "Closes:"
-  tag/trailer to reference it and have GitHub automatically close it once
-  it's been merged.  E.g.:
-
-  `Closes: https://github.com/nginx/unit/issues/9999`
-
-  That should go at the end of the commit message, separated by a blank line,
-  along with any other tags.
+## Note: This repository has been archived. There will likely be no further development at this repo, and security vulnerabilities may be unaddressed. No contributions are accepted; however, the repo may be forked and used in alignment with the license.
 
+If you have questions on this project as archived, please ask them on the [NGINX Community Forum](https://community.nginx.org).