XRPLF · sappenin · Apr 29, 2024 · Apr 12, 2023 · Jan 23, 2024 · Jan 23, 2024
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,78 +1,66 @@
 # CONTRIBUTING
 
-Contributions to this repo are free, open-source, and follow the process outlined below:
+The work of the [XRP Ledger](https://xrpl.org) community is open, collaborative, and welcoming of all contributors participating in good faith. Part of that effort involves standardization, and this document outlines how anyone can contribute to that process. 
 
-Any XRPL-Standards document can be referred to interchangeably as an "XLS", "XRPL Standard", or "document".
+## Licensing
+Any XRPL Standards document can be referred to interchangeably as an "XLS", "XRPL Standard", or "document".  Copyright on all content is subject to the terms of this [license](LICENSE), and all contributors grant everyone a royalty-free license to use their contributions, including the following grants: 
 
-## Summary
+- Copyright: a royalty-free license to anyone to use any contributions submitted to this repository.
+- Patent: a commitment to license on a royalty-free basis any essential patent claims relating to any contributions in this repository.
 
-Copyright on all content is subject to the terms of the [license](LICENSE).
+## Specification Process
 
-All contributors grant everyone:
+### 1. Start a Discussion & Gather Feedback
 
-Copyright: a royalty-free license to use the copyrights for their contributions.
-Patent: a commitment to license on a royalty-free basis their essential patent claims reading on their contributions.
+Before opening a PR with any kind of formal proposal, please first gather community input by starting a [Discussion](https://github.com/XRPLF/XRPL-Standards/discussions). Discussions are suitable for early work-in-progress: ask, suggest, add, and make sweeping changes. Collecting such feedback helps to refine your concept, and is required in order to move forward in the specification process.
 
-## Background
+#### Discussion Title
+When creating a new discussion for your idea, the discussion title should follow the naming convention `XLS-{0000}d {Title}`, where `{0000}` is a unique number for the XLS, `d` indicates that the document is a Draft (i.e., work in progress), and `{Title}` is a descriptive title for the proposed document.
 
-The work of the XRP Ledger community is open source, collaborative, and welcoming of all contributors participating in good faith. [Learn more about the XRP Ledger at XRPL.org](https://xrpl.org/).
+#### Specification Number
+Use the next number that has not yet been used. If a conflict occurs, it will be fixed by a maintainer or editor. Maintainers or editors also reserve the right to remove or re-number proposals as necessary. The number is important, as it will be used to reference features and ideas throughout the community.
 
+### 2. Closing Discussion
 
-## Process
+When a discussion has produced a well-refined standard, authors should post a comment to the discussion noting that the discussion will be closed in a few days. This allows time (for those engaged with the discussion) to submit final commentary. 
 
-The XRPL-Standards process attempts to be easy to use, but also rigorous enough that there are permalinks to revisions of documents for reference purposes.
+Once this waiting period has elapsed, the standard's author may close the discussion from further comment, and then move the discussion to a [**specification pull request**](#3.-specification-pull-requests) to add the standard into the repository as a markdown file (see below for specification formats).
 
-### Gathering Feedback Before Submitting
+Next, the discussion author should edit the discussion to include a link to the PR. The last comment on the discussion should also be a link to the PR.
 
-Please gather community input before opening a PR. Collecting such feedback helps to refine your concept. This step is required.
+The intention of this workflow is that the discussion be closed from further comments, with further comments instead being posted on the PR for fine-tuning and alignment with implementation or adoption, as appropriate.
 
-Start a [Discussion](https://github.com/XRPLF/XRPL-Standards/discussions) under this repo.
+### 3. Specification Pull Requests
 
-The title should follow the naming convention `XLS-0000d {Title}`, where `0000` is a unique number for the XLS, `d` indicates that the document is a Draft (in progress), and `{Title}` is a descriptive title for the proposed document.
+When opening a specification PR, there are two document types: *Drafts* and *Candidate Specifications*. The type and status of any particular document has no bearing on the priority of that document. Typically, the further along in the process, the more likely it is that any particular XLS will be implemented or adopted.
 
-Use the next number that has not yet been used. If a conflict occurs, it will be fixed by a maintainer or editor. Maintainers or editors also reserve the right to remove or re-number proposals as necessary.
-
-The number is important, as it will be used to reference features and ideas throughout the community.
-
-Discussions are suitable for early work-in-progress: ask, suggest, add, and make sweeping changes.
-
-When a discussion has produced a well-refined standard, authors should post a comment to the discussion noting that it will be closed in a few days. This allows time (for those engaged with the discussion) to submit any final commentary. 
-
-When the fair notice time has elapsed, the author should move from discussion to Draft by opening a PULL REQUEST.
-
-
-The standard's author must edit and replace the post with a summary and a link to the PR.
-
-The last comment on the discussion should also be a link to the PR.
-
-Finally, the discussion should be closed from further comments, with further comments instead being posted on the PR for fine-tuning and alignment with implementation or adoption (as appropriate).
-
-When opening a PR, there are two document types: *Drafts* and *Candidate Specifications*. The type and status of any particular document has no bearing on the priority of that document. Typically, the further along in the process, the more likely it is that any particular XLS will be implemented or adopted.
-
-### Drafts
+#### Drafts
 
 A _Draft_ is a document that proposes some new feature, protocol or idea related to the XRP Ledger. The criteria for getting the document merged is minimal: project maintainers will review the document to ensure style conformance and applicability, but will otherwise not require editorial fixes before allowing it to be published.
 
-A document does not need to have an implementation in order to become a Draft. A Draft may or may not have implementation(s) available; no code is required prior to the Draft being published.
+A document does not need to have an implementation in order to become a Draft. A Draft may or may not have implementation(s) available and no code is required prior to the Draft being published.
+
 A Draft is often stable enough for people to experiment with, but has not necessarily been endorsed by the entire community. When there are competing Drafts that address the same problem in different ways, all such Drafts can continue to be refined, promoted, and used independently, without any blocking. Implementors can create software to implement this type of standard into their codebase to explore how it works in a real world setting.
 
-Any, or all, competing Drafts may graduate into a Candidate Specification.
+Any, or all, competing Drafts _may_ graduate into a Candidate Specification.
 
 Notice that a Draft is not a [rubber-stamp](https://idioms.thefreedictionary.com/rubber-stamp) of the content in any particular document. Documents can still undergo significant changes and potentially be discarded all together.
 
-#### Publishing a Draft
+##### Publishing a Draft
+
+To publish a new Draft, submit a Pull Request to this repo with a new folder and a new Markdown file. The folder MUST follow the naming convention `XLS-{0000}d-{title}` where `{0000}` is the unique number referencing the XLS, `d` indicates that the document is a Draft, and `{title}` is a lower case title with spaces replaced by hyphens (`-`). The submission should have front-matter (similar to GitHub pages rendered from Markdown) specifying at least a `title` and `type`. The `type` MUST have the value `draft`.
 
-To publish a new Draft, submit a Pull Request to this repo with a new folder and a new Markdown file. The folder MUST follow the naming convention `XLS-0000d-{title}`, `0000` is the unique number referencing the XLS, `d` indicates that the document is a Draft, and `title` is a lower case title with spaces replaced by hyphens (`-`). The submission should have front-matter (similar to GitHub pages rendered from Markdown) specifying at least a `title` and `type`. The `type` MUST have the value `draft`.
+An example draft name is: `XLS-20d-non-fungible-token-support-native`
 
 Use the following template when creating the Markdown file: [xls-template.md](./xls-template.md)
 
 Assuming there is consensus to publish, one of the project maintainers will review the submission and confirm the document's XLS number, often making a follow-up commit to the PR which renames the file as appropriate.
 
-### Candidate Specifications
+#### Candidate Specifications
 
-A _Candidate Specification_ is a document that was previously a Draft that is considered stable enough by the community such that no further changes are required. Once an XLS becomes a Candidate Specification, no further substantive changes are allowed under the same XLS number.
+A _Candidate Specification_ is a document that was previously a Draft, but is considered stable enough by the community such that no further changes are required. Once an XLS becomes a Candidate Specification, no further substantive changes are allowed under the same XLS number.
 
-#### Publishing a Candidate Specification
+##### Publishing a Candidate Specification
 
 When a Draft is considered stable, there is a call for review from the community to publish the document as a Candidate Specification by making a PR to remove the `d` from the document folder name and update the `type` to `candidate-specification`.
 

diff --git a/README.md b/README.md
@@ -1,25 +1,11 @@
-# XRP Ledger Standards 
-### Standards implementation discussion, requests for comment
+# XRP Ledger Standards
 
-To ensure interoperability between XRP (Ledger) core protocol, ecosystem applications, tools, pursuing a great user experience, the community (developers, users, etc.) _should_ discuss and work towards agreement on certain implementation standards.
-
-# [Contributing](./CONTRIBUTING.md)
-
-Please see [CONTRIBUTING.md](./CONTRIBUTING.md)
-
-# Directory
-
-When a standard moves to a folder + file(s) in the Code section of this repository, it should be added to the `standards.toml` file:
-https://github.com/XRPLF/XRPL-Standards/blob/master/standards.toml
-
-# Numbering
+XRP Ledger Standards (XLSs) describe standards and specifications relating to the XRP Ledger ecosystem that help achieve the following goals:
 
-**Suggestions/Standards** must be **numbered** and referenced in the following format: XLS-# where # is a natural number (without left padded zeros), called the __Suggestion/Standard Number__.
-
-# Revisions
-
-If a suggestion/standard requires a substantive revision and using the same number would result in confusion, a separator '.' may be added, e.g. `XLS-1.1`.
-
-# Drafts
+* Ensure interoperability and compatibility between XRP Ledger core protocol, ecosystem applications, tools, and platforms.
+* Maintain a continued, excellent user experience around every application or system.
+* Drive alignment and agreement in the XRPL community (i.e., developers, users, operators, etc).
+
+# [Contributing](./CONTRIBUTING.md)
 
-A suggestion/standard may be marked as a draft e.g. `XLS-10d` or `XLS-1.2d` if the author/s expect further revisions in the near term. After sufficient time without change the suggestion/standard can be referred to without the draft indicator.
+The exact process for organizing and contributing to this repository is defined in [CONTRIBUTING.md](./CONTRIBUTING.md). If you would like to contribute, please read more there.