From 9abea43fbf7fb49b5003059abd0029ecc1bd1391 Mon Sep 17 00:00:00 2001 From: "Boyarinov, Konstantin" Date: Mon, 6 Jan 2025 04:31:59 -0800 Subject: [PATCH] Remove whitespace changes --- rfcs/README.md | 58 ++++++++++++++++++------------------- rfcs/experimental/README.md | 12 ++++---- rfcs/template.md | 10 +++---- 3 files changed, 40 insertions(+), 40 deletions(-) diff --git a/rfcs/README.md b/rfcs/README.md index 831c60d00d..15995290bd 100644 --- a/rfcs/README.md +++ b/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 `_`. 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/_`. +The design documents are stored in the `rfcs` directory, and each RFC is placed +in its subdirectory under `rfcs/proposed/_`. -- 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. diff --git a/rfcs/experimental/README.md b/rfcs/experimental/README.md index 9dcd233aee..612e69f032 100644 --- a/rfcs/experimental/README.md +++ b/rfcs/experimental/README.md @@ -5,16 +5,16 @@ 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 @@ -22,7 +22,7 @@ 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. diff --git a/rfcs/template.md b/rfcs/template.md index 9c589e60b9..834840a5ea 100644 --- a/rfcs/template.md +++ b/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: