Remove whitespace changes

rfcs/README.md

@@ -4,28 +4,28 @@ The RFC process intends to:
 
 - Communicate library-wide changes
 - Collect feedback before implementation
-- Increase transparency in decision-making
+- Increase transparency in decision-making 
 - Align different teams involved in oneTBB development
 
-This directory contains design documents (RFCs) approved
+This directory contains design documents (RFCs) approved 
 or rejected for implementation in oneTBB.
 
 The possible RFC states are:
 
-1. Initial
+1. Initial 
 2. Proposed
 3. Experimental
 4. Supported
 5. Archived
 
-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.
-However, if the issue or discussion results in an idea for a significant
-change or new feature that affects the library's public API or architecture,
-we recommend opening a PR to add a new RFC to the `rfcs/proposed` directory.
+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. 
+However, if the issue or discussion results in an idea for a significant 
+change or new feature that affects the library's public API or architecture, 
+we recommend opening a PR to add a new RFC to the `rfcs/proposed` directory. 
 The RFC should provide a detailed description and design of the proposed feature.
-or new feature that significantly impacts the library's public API or
-architecture, it will be suggested that a PR be opened to add a new rfc
+or new feature that significantly impacts the library's public API or 
+architecture, it will be suggested that a PR be opened to add a new rfc 
 to the `rfcs/proposed` directory. The RFC contains a more detailed description
 and design for the feature.
 
@@ -35,43 +35,43 @@ A template for RFCs is available as [template.md](template.md). Place the modifi
 template in the subdirectory of the `rfcs/proposed` with a name
 of the form `<feature>_<extension_description>`. For example,
 a proposal for a new ``my_op`` flow graph node should be put into the
-`rfcs/proposed/flow_graph_my_op_node` directory. Use [template.md](template.md)
-to create the `README.md` file in that directory. The folder can
+`rfcs/proposed/flow_graph_my_op_node` directory. Use [template.md](template.md) 
+to create the `README.md` file in that directory. The folder can 
 contain other files referenced by the `README.md` file, such as figures.
 
 Once two maintainers approve the PR, it is merged into the `rfcs/proposed`
-directory. Update the RFC document with additional information as the RFC moves
-to different states.
+directory. Update the RFC document with additional information as the RFC moves 
+to different states. 
 
-A proposal that is subsequently implemented and released in oneTBB
+A proposal that is subsequently implemented and released in oneTBB 
 as a preview feature is moved into the `rfcs/experimental` folder. The
 RFC for a preview feature in `rfcs/experimental` should include a description
-of what is required to move from experimental to fully supported -- for
+of what is required to move from experimental to fully supported -- for 
 example, feedback from users, demonstrated performance improvements, etc.
 
-A proposal that is implemented, added to the oneTBB specification, and
-supported as a full feature appears in the `rfcs/supported` directory. An RFC
-for a fully supported feature in the `rfcs/supported` directory should
-have a link to the section in the oneTBB specification with its
+A proposal that is implemented, added to the oneTBB specification, and 
+supported as a full feature appears in the `rfcs/supported` directory. An RFC 
+for a fully supported feature in the `rfcs/supported` directory should 
+have a link to the section in the oneTBB specification with its 
 formal wording.
 
-A feature that is removed or a proposal that is abandoned or rejected will
+A feature that is removed or a proposal that is abandoned or rejected will 
 be moved to the `rfcs/archived` folder.
 
 ## Document Style
 
-The design documents are stored in the `rfcs` directory, and each RFC is placed
-in its subdirectory under `rfcs/proposed/<feature>_<extension_description>`.
+The design documents are stored in the `rfcs` directory, and each RFC is placed 
+in its subdirectory under `rfcs/proposed/<feature>_<extension_description>`. 
 
-- There must be a `README.md` file that contains the main RFC itself (or
+- There must be a `README.md` file that contains the main RFC itself (or 
 links to a file that contains it in the same directory).
-  - The RFC should follow the [template.md](template.md) structure.
-  - The directory can contain other supporting files, such as images, tex
+  - The RFC should follow the [template.md](template.md) structure. 
+  - The directory can contain other supporting files, such as images, tex 
   formulas, and sub-proposals / sub-RFCs.
-  - We highly recommend using a text-based file format like markdown for easy
+  - We highly recommend using a text-based file format like markdown for easy 
   collaboration on GitHub, but other formats like PDFs may also be acceptable.
 - For the markdown-written RFC, keep the text width within
-  100 characters, unless there is a reason to violate this rule, e.g.,
+  100 characters, unless there is a reason to violate this rule, e.g., 
   long links or wide tables.
-- It is also recommended to read through existing RFCs to better understand the
+- It is also recommended to read through existing RFCs to better understand the 
 general writing style and required elements.

rfcs/experimental/README.md

@@ -5,24 +5,24 @@ released as preview features in the oneTBB library. A preview
 feature is expected to have an implementation that is of comparable quality
 to a fully supported feature. Sufficient tests are required.
 
-An experimental feature does not yet appear as part of the oneTBB
+An experimental feature does not yet appear as part of the oneTBB 
 specification. Therefore, the interface and design can change.
 There is no commitment to backward compatibility for a preview
 feature.
 
-The documents in this directory
+The documents in this directory 
 should include a list of the exit conditions that need to be met to move from
 preview to fully supported. These conditions might include demonstrated
 performance improvements, demonstrated interest from the community,
-acceptance of the required oneTBB specification changes, etc.
+acceptance of the required oneTBB specification changes, etc. 
 
 For features that require oneTBB specification changes, the document might
 include wording for those changes or a link to any PRs that 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 they are not fully accepted. It should be highly unusual for
-a proposal to stay in the experimental folder for longer than a year or
+supported folder when they become fully supported or the archived 
+folder if they are not fully accepted. It should be highly unusual for 
+a proposal to stay in the experimental folder for longer than a year or 
 two.

rfcs/template.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-Short description of the idea proposed with explained motivation.
+Short description of the idea proposed with explained motivation. 
 
 The motivation could be:
 - Improved users experience for API changes and extensions. Code snippets to
@@ -21,12 +21,12 @@ A full and detailed description of the proposal with highlighted consequences.
 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.
-- The interface of extensions including class definitions or function
+- The expected performance benefit for a modification. 
+- The interface of extensions including class definitions or function 
 declarations.
 
-A proposal should clearly outline the alternatives that were considered,
-along with their pros and cons. Each alternative should be clearly separated
+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.
 
 Pay close attention to the following aspects of the library: