Move top-level markdown files into meta/docs folder (#12727)

* Moved meta files to a new folder

* doctoc POLICY

* fix versioning

* remove doctoc on versioning

packages/contracts-bedrock/README.md

@@ -66,22 +66,22 @@ See the [Optimism Developer Docs](https://docs.optimism.io/chain/addresses) for
 ### Contributing Guide
 
 Contributions to the OP Stack are always welcome.
-Please refer to the [CONTRIBUTING.md](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/CONTRIBUTING.md) for more information about how to contribute to the OP Stack smart contracts.
+Please refer to the [CONTRIBUTING.md](./meta/CONTRIBUTING.md) for more information about how to contribute to the OP Stack smart contracts.
 
 ### Style Guide
 
-OP Stack smart contracts should be written according to the [STYLE_GUIDE.md](./STYLE_GUIDE.md) found within this repository.
+OP Stack smart contracts should be written according to the [STYLE_GUIDE.md](./meta/STYLE_GUIDE.md) found within this repository.
 Maintaining a consistent code style makes code easier to review and maintain, ultimately making the development process safer.
 
 ### Contract Interfaces
 
 OP Stack smart contracts use contract interfaces in a relatively unique way. Please refer to
-[INTERFACES.md](./INTERFACES.md) to read more about how the OP Stack uses contract interfaces.
+[INTERFACES.md](./meta/INTERFACES.md) to read more about how the OP Stack uses contract interfaces.
 
 ### Solidity Versioning
 
 OP Stack smart contracts are designed to utilize a single, consistent Solidity version. Please
-refer to [SOLIDITY_UPGRADES.md](./SOLIDITY_UPGRADES.md) to understand the process for updating to
+refer to [SOLIDITY_UPGRADES.md](./meta/SOLIDITY_UPGRADES.md) to understand the process for updating to
 newer Solidity versions.
 
 ## Deployment

packages/contracts-bedrock/meta/POLICY.md

+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+**Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*
+
+- [Policy](#policy)
+  - [Contributing](#contributing)
+  - [Versioning Policy](#versioning-policy)
+  - [Upgrade Policy](#upgrade-policy)
+  - [Style Guide](#style-guide)
+  - [Revert Data](#revert-data)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+# Policy
+
+This document outlines upgrade policies regarding the OP Stack codebase.
+
+## Contributing
+
+For any policies on contributing, please see [CONTRIBUTING](./CONTRIBUTING.md)
+
+## Versioning Policy
+
+For our versioning policy, please see our policy on [VERSIONING](./VERSIONING.md)
+
+## Upgrade Policy
+
+For the solidity upgrade policy, please see our doc on [SOLIDITY UPGRADES](./SOLIDITY_UPGRADES.md)
+
+## Style Guide
+
+For an indepth review of the code style used in the OP Stack contracts, please see our [STYLE GUIDE](./STYLE_GUIDE.md)
+
+## Revert Data
+
+Revert data may be changed in the future, and is not a reliable interface for external consumers. Contracts should not depend on specific revert data returned by OP Stack contracts, which can be changed during any future OP Stack contract upgrades. Revert data includes both custom errors returned by contracts, as a well as revert strings.

packages/contracts-bedrock/VERSIONING.md → packages/contracts-bedrock/meta/VERSIONING.md

@@ -11,7 +11,6 @@ There are five parts to the versioning and release process:
 - [Release Process](#release-process): The process for deploying contracts, creating a governance proposal, and the required associated releases.
   - [Additional Release Candidates](#additional-release-candidates): How to handle additional release candidates after an initial `op-contracts/vX.Y.Z-rc.1` release.
   - [Merging Back to Develop After Governance Approval](#merging-back-to-develop-after-governance-approval): Explains how to choose the resulting contract versions when merging back into `develop`.
-- [Changelog](#changelog): A CHANGELOG for contract releases is maintained.
 
 > [!NOTE]
 > The rules described in this document must be enforced manually.
@@ -119,14 +118,3 @@ Now there are two scenarios for the PR that merges the release branch back into
     - In practice, this one unlikely to occur when using inheritance for feature development, as specified in [Smart Contract Feature Development](https://github.com/ethereum-optimism/design-docs/blob/main/smart-contract-feature-development.md) architecture. It's more likely that (1) is the case, and we merge the version change into the base contract.
 
 This flow also provides a dedicated branch for each release, making it easy to deploy a patch or bug fix, regardless of other changes that may have occurred on develop since the release.
-
-## Changelog
-
-Lastly, a CHANGELOG for contract releases must be maintained:
-
-- Each upcoming release will have a tracking issue that documents the new versions of each contract that will be included in the release, along with links to the PRs that made the changes.
-- Every contracts PR must have an accompanying changelog entry in a tracking issue once it is merged.
-- Tracking issue titles should be named based on the expected Upgrade number they will go to governance with, e.g. "op-contracts changelog: Upgrade 9".
-  - See [ethereum-optimism/optimism#10592](https://github.com/ethereum-optimism/optimism/issues/10592) for an example of what this tracking issue should look like.
-  - We do not include a version number in the issue because it may be hard to predict the final version number of a release until all PRs are merged.
-  - Using upgrade numbers also acts as a forcing function to ensure upgrade sequencing and the governance process is accounted for early in the development process.