[RFCs] Add Flow Graph try_put_and_wait RFC

rfcs/README.md

@@ -0,0 +1,81 @@
+# oneTBB Design Documents/RFCs
+
+The RFC process intends to:
+
+- Communicate library-wide changes
+- Collect feedback before implementation
+- Increase transparency in decision-making 
+- Align different teams involved in oneTBB development
+
+This directory contains design documents (RFCs) approved 
+or rejected for implementation in oneTBB.
+
+The possible RFC states are:
+
+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. 
+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 
+to the `rfcs/proposed` directory. The RFC contains a more detailed description
+and design for the feature.
+
+## General Process
+
+A template for RFCs is available as [template.md](template.md). Place the modified
+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 
+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. 
+
+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 
+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 
+formal wording.
+
+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>`. 
+
+- 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 
+  formulas, and sub-proposals / sub-RFCs.
+  - 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.
+    template file for writing RFCs. However, it is strongly recommended to use
+    text-based file format that can be rendered by GitHub to allow for easy
+    collaboration using PR comments. Even so, files such as pdfs may be
+    acceptable.
+- For the markdown-written RFC, keep the text width within
+  80 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 
+general writing style and required elements.

rfcs/archived/README.md

@@ -0,0 +1,14 @@
+# Archived Design Documents
+
+Documents may appear in the `rfcs/archived` directory for one of 
+two reasons:
+
+1. The document describes a feature or extension that has been deprecated and 
+then removed.
+2. The document describes a proposed feature or extension that have
+not (ultimately) become a fully supported feature. 
+
+Design documents that appear in the `rfcs/archived` folder should describe a 
+reason for archiving.  Documents may 
+remain in this folder indefinitely to serve as a source of information about
+previous proposals and features.

rfcs/experimental/README.md

@@ -0,0 +1,28 @@
+# Design Documents for Experimental Features
+
+Experimental proposals describe extensions that are implemented and
+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 
+specification. Therefore, the interface and design can change.
+There is no commitment to backward compatibility for a preview
+feature.
+
+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. 
+
+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. The 
+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 
+two.