Update README.md

README.md

@@ -1,15 +1,10 @@
 # FLIPs (Flow Improvement Proposals)
 
-The purpose of a FLIP is to engage the Flow community in development
-by leveraging the collective ideas, insights, and experience of contributors and experts
-while also communicating design changes broadly.
+Flow Improvement Proposals (FLIPs) serve as a platform for engaging the Flow community in development, harnessing the collective ideas, insights, and expertise of contributors and experts while ensuring widespread communication of design changes.
 
-Each FLIP describes a protocol change, governance change, or application level standard meant to improve the Flow protocol or ecosystem.
-Proposals can be submitted by anyone, and should follow the process below, as well as the [TDB] style guide for each category.
+Each FLIP delineates a proposed alteration to the Flow protocol, governance, or application-level standards with the objective of enhancing the Flow ecosystem and protocol. These proposals are open to submission by anyone and are subject to the FLIP process described below.
 
-This repository will hold FLIPs to separate them from the [onflow/flow](https://github.com/onflow/flow/tree/master/flips) repository.
-This is currently a work in progress, and legacy FLIPs are all in the [flips directory](https://github.com/onflow/flips/tree/main/flips).
-These FLIPs will be moved into the appropriate sub-directories over time.
+To differentiate FLIPs from the [onflow/flow](https://github.com/onflow/flow/tree/master/flips) repository, a separate repository has been created to house them. Currently, the legacy FLIPs reside in the [flips directory](https://github.com/onflow/flips/tree/main/flips) and will be gradually relocated to their appropriate sub-directories.
 
 ## Application
 Application FLIPs are standards for applications built on top of FLOW. This could be token standards, contract interface standards, common design patterns that can benefit from social consensus etc. Application standards should not create protocol changes in themselves, and if they rely on any new protocol features that feature should be written up in its own protocol flip.
@@ -71,10 +66,9 @@ Cadence changes will currently fall under Protocol FLIPs because they are tightl
 
 Everyone is welcome to propose and provide feedback on a FLIP.
 
-A **FLIP author** writes a FLIP and is committed to championing it through the process.
+A **FLIP author** writes and champions the proposal through the process.
 
-A **FLIP sponsor** is any maintainer who sponsors the FLIP and will shepherd it
-through the FLIP review process.
+A **FLIP sponsor** who is a maintainer, supports the FLIP and shepherds it through the review process.
 
 A **review committee** is a group of maintainers who are responsible for the strategic direction of components, subcomponents, and public APIs.
 They have the responsibility to accept or reject the adoption of the FLIP via a community vote.
@@ -86,25 +80,26 @@ will solve it. Specifically, the FLIP will:
 
 * be formatted according to the FLIP template
 * be submitted as a pull request
-* be subject to discussion and a review meeting prior to acceptance
+* be subject to thorough community discussion and review prior to acceptance or rejection
 
 ## FLIP process
 
-Before submitting a new FLIP, check for prior proposals, the [Flow community forum](https://forum.onflow.org/) and ask in the [Discord server](https://discord.gg/flow).
-The idea may have been proposed before or may be in active discussion. Consider contributing or giving feedback to existing proposals.
+### Pre-FLIP Ideation
+1. Before submitting a new FLIP, check for prior proposals, the [Flow community forum](https://forum.onflow.org/) and ask in the [Discord server](https://discord.gg/flow). The idea may have been proposed before or may be in active discussion. Consider contributing or giving feedback to existing proposals.
+2. If a new proposal is appropriate, propose a rough sketch of the idea in the forum [Flow community forum](https://forum.onflow.org/) and engage in discussion with the community, project contributors, and maintainers, to get early feedback.
 
-If a new proposal is appropriate, propose a rough sketch of the idea in the forum [Flow community forum](https://forum.onflow.org/)
-and engage in discussion with the community, project contributors, and maintainers, to get early feedback.
-Continue to expand the rough sketch into a draft using the FLIP template and further refine the proposal on the forums.
+### Authoring the FLIP
 
-After writing the FLIP draft, gather feedback from project contributors and maintainers before submitting it.
+1. Continue to expand the rough sketch into a draft using the FLIP template and further refine the proposal on the forums.
+2. After writing the FLIP draft, gather feedback from project contributors and maintainers before submitting it.
+
+## Submitting the FLIP 
 
 Once the FLIP is ready for review:
 
 1. _(Optional)_ Recruit a sponsor from the maintainers of the project for which your FLIP concerns.
 
-   You are not required to recruit a sponsor; this step is entirely optional.
-   However, a sponsor acts as a valuable resource who can streamline the review process and increase the likelihood of your FLIP being accepted.
+   You are not required to recruit a sponsor; this step is entirely optional. However, a sponsor acts as a valuable resource who    can streamline the review process and increase the likelihood of your FLIP being accepted.
 
    If you do recruit a sponsor, identify them in the FLIP before posting the PR in step 2.
 
@@ -126,20 +121,26 @@ Once the FLIP is ready for review:
 3. Send a message to the #developers channel on [Discord](https://discord.gg/flow)
    with a brief description, and a link to the PR and a request for review.
 
-4. The sponsor may request a review committee meeting after sufficient discussion has taken place.
+### Managing Community Discussion
+
+1. The FLIP author and sponsor should actively engage in community discussions, providing thorough responses to inquiries and addressing any concerns raised by community members in a timely and respectful manner.
+
+2. The sponsor may request a review committee meeting after sufficient discussion has taken place.
    This meeting will include the FLIP author, core contributors and interested community members.
    If discussion is lively, wait until it has settled before going to review.
    The goal of the review meeting is to resolve minor issues;
    consensus should be reached on major issues beforehand.
 
-5. The meeting may approve the FLIP, reject it, or require changes before it can be considered again.
-   FLIPs will be merged into this repository ([`onflow/flips`](https://github.com/onflow/flips))
-   with the outcome of the review process (approval, rejection).
+### Post-FLIP
+
+1. Community may approve the FLIP, reject it, or require changes before it can be considered again.
+   FLIPs will be merged into this repository ([`onflow/flips`](https://github.com/onflow/flips)),
+   stating the outcome of the review process (approval, rejection), once known.
 
-6. Implementations of a successful FLIP should reference it in their documentation,
+4. Implementations of a successful FLIP should reference it in their documentation,
    and work with the sponsor to successfully land the code.
 
-While implementation code is not necessary to start the FLIP process,
+Note that While implementation code is not necessary to start the FLIP process,
 its existence in full or part may help the design discussion.
 
 If in any doubt about this process, feel free to ask on [Discord](https://discord.gg/flow),
@@ -162,7 +163,7 @@ Community members should:
 
 * provide feedback as soon as possible to allow adequate time for consideration
 * read FLIPs thoroughly before providing feedback
-* be civil and constructive (see [Code of Conduct](CODE_OF_CONDUCT.md))
+* be civil and constructive
 
 ## Review committees