Address the review feedback

rfcs/README.md

@@ -2,11 +2,11 @@
 
 The Request for Comments (RFC) process intends to:
 
-- Propose and discuss ideas for the library evolution
-- Communicate anticipated library-wide changes
-- Collect feedback before implementation
-- Increase transparency in decision-making 
-- Align different teams involved in the library development
+- Propose and discuss ideas for the library evolution.
+- Communicate anticipated library-wide changes.
+- Collect feedback before implementation.
+- Increase transparency in decision-making.
+- Align different teams involved in the library development.
 
 Most modifications or new features will naturally start as a part of a 
 GitHub issue or discussion. Small changes do not require a formal RFC. 
@@ -29,7 +29,7 @@ in a subdirectory under an `rfcs/<state>` directory. The possible states are:
 4. Archived
 
 The `rfcs/proposed` directory contains RFCs for approved proposals
-that yet need to be implemented. These documents describe the overall design
+that need to be implemented. These documents describe the overall design
 and API for the proposed functionality.
 
 The `rfcs/experimental` directory contains RFCs for experimental library features.
@@ -66,7 +66,7 @@ The "RFC" label can be used to mark PRs containing RFC/design proposals.
 
 The RFC approval process generally follows the guidelines in the [UXL Foundation Operational Procedures](
 https://github.com/uxlfoundation/uxl_operational_procedures/blob/release/Process_Documents/Organization_Operational_Process.md#review--approval-process).
-Once at least two maintainers approve the PR, it is merged into the main branch
+Once two or more maintainers approve the PR, it is merged into the main branch
 as an RFC proposed for implementation.
 
 As the RFC moves to different states, use new PRs to update the RFC document

rfcs/experimental/README.md

@@ -9,19 +9,18 @@ An experimental feature does not yet appear as part of the oneDPL
 specification. Therefore, the interface and design can change.
 There is no commitment to backward compatibility for experimental features.
 
-The documents in this directory 
-should include a list of the exit conditions that need to be met to move from
-experimental to fully supported. These conditions might include demonstrated
-performance improvements, demonstrated interest from the community,
+The documents in this directory should include a list of the exit conditions
+that need to be met to move the functionality from experimental to fully supported.
+These conditions might include demonstrated performance improvements, 
+demonstrated interest from the community,
 acceptance of the required specification changes, etc. 
 
 For features that require specification changes, the document might
 include wording for those changes or a link to any PRs opened
 against the specification.
 
-Proposals should not remain in the experimental directory forever.
-It should move either to the
-supported folder when they become fully supported or the archived 
-folder if the corresponding feature is not finally accepted but removed.
-It should be highly unusual for 
-a proposal to stay in the experimental folder for longer than a year or two.
+Proposals in the `rfcs/experimental` directory do not remain there indefinitely.
+They should move either to `rfcs/supported` when they become fully supported
+or to `rfcs/archived` if the corresponding feature is not finally accepted but removed.
+As a general rule, a proposal should not stay in the experimental folder
+for longer than a year or two.

rfcs/supported/README.md

@@ -5,8 +5,8 @@ released as fully supported features of the library. A fully supported feature
 has a high-quality implementation, is regularly tested and properly documented.
 
 If the proposal impacted the public API of the library, it should usually involve
-changes in the oneDPL specification. The RFC document should in that case have a link
-to the formal wording in the specification.
+changes in the oneDPL specification. The RFC document should, in that case,
+have a link to the formal wording in the specification.
 
 Proposals that appear in `rfcs/supported` may be retained indefinitely to
 provide insight into the design of existing features.

rfcs/template.md

@@ -5,7 +5,7 @@
 Replace the text in this section with a short description of the proposed idea.
 
 Explain the motivation for a proposal, such as:
-- Improved users experience for API changes and extensions. Code snippets to
+- Improved user experience for API changes and extensions. Code snippets to
   showcase the benefits would be nice here.
 - Performance improvements.
 - Improved engineering practices.
@@ -23,18 +23,19 @@ Depending on the kind of the proposal, the description should cover:
 
 - New use cases supported by the extension.
 - The expected performance benefit for a modification, supported with the data, if available.
-- The interface of extensions including class definitions or function declarations.
+- The API of extensions such as class definitions and function declarations.
 
 A proposal should clearly outline the alternatives that were considered, 
 along with their pros and cons. Each alternative should be clearly separated 
-to make discussions easier to follow.
+to make discussions easier to follow. Or, if you prefer, list all the alternatives
+first (perhaps as subsections), and then have a dedicated section with the discussion.
 
 Pay close attention to the following aspects of the library:
 - API and ABI backward compatibility. The library follows semantic versioning
   so if any of those interfaces are to be broken, the RFC needs to state that
   explicitly.
 - Performance implications, as performance is one of the main goals of the library.
-- Dependencies and supported platforms: does the proposal bring any new
+- Dependencies and supported platforms. Does the proposal bring any new
   dependencies or affect the supported configurations?
 
 Include short explanation and links to the related proposals, if any.
@@ -43,9 +44,6 @@ not mandatory. If the related change is insignificant or doesn't make any sense
 without the original proposal, describe it in the main RFC.
 
 Some other common subsections could be:
-- Discussion: some people like to list all the options first (as separate
-  subsections), and then have a dedicated section with the discussion.
-- Synopsis: the list of the proposed API.
 - Usage examples.
 - Testing aspects.
 - Execution plan (next steps), if approved.