oneapi-construction-kit

RFC template

RFC	2
Author	Harald van Dijk <harald.vandijk@codeplay.com>
Status	active

Table of Contents

• Abstract
• Rationale
• How to Use This Template
• Copyright

Abstract

This RFC provides a boilerplate or sample template for creating your own Markdown RFCs. In conjunction with the content guidelines in RFC 1, this should make it easy for you to conform your own RFCs to the format outlined below.

Note: if you are reading this RFC via the web, you should first grab the textr (Markdown) source of this RFC in order to complete the steps below. DO NOT USE THE HTML FILE AS YOUR TEMPLATE!

The source for this (or any) RFC can be found in the rfcs branch of the oneAPI Construction Kit repository.

Rationale

If you intend to submit a RFC, you MUST use this template, in conjunction with the format guidelines below, to ensure that your RFC submission won’t get automatically rejected because of form.

Markdown provides PEP authors with useful functionality and expressivity, while maintaining easy readability in the source text. The processed HTML form makes the functionality accessible to readers: live hyperlinks, styled text, tables, images, and automatic tables of contents, among other advantages.

How to Use This Template

• Make a copy of rfc-0002/rfc-NNNN.md (the .md file, not the HTML!) and perform the following edits. Name the new file rfc-NNNN.md, using the next available number (not used by a published or in-PR RFC).
• Replace the “rfc” header with “rfc: NNNN”, matching the file name. Note that the file name should be padded with zeros (eg rfc-0002.md), but the header should not (rfc: 2).
• Change the title header to the title of your RFC.
• Change the author header to include your name, and optionally your email address. Be sure to follow the format carefully: your name must appear first, and it must not be contained in parentheses. Your email address may appear second (or it can be omitted) and if it appears, it must appear in angle brackets. It is okay to obfuscate your email address.
• If none of the authors are core developers, include a Sponsor header with the name of the core developer sponsoring your RFC.
• Add the direct URL of the RFC’s canonical discussion thread (on e.g. GitHub Discussions) under the discussions-to header. If the thread will be created after the RFC is submitted as an official draft, it is okay to just list the venue name initially, but remember to update the RFC with the URL as soon as the RFC is successfully merged to the rfcs branch and you create the corresponding discussion thread. See RFC 1 for more details.
• Change the status header to “draft”.
• Now write your Abstract, Rationale, and other content for your RFC, replacing placeholders with your own text.
• Update your Footnotes section, listing any footnotes and non-inline link targets referenced by the text.
• Create a pull request against the rfcs branch.

---
rfc: <REQUIRED - RFC number>
title: <REQUIRED - RFC title>
author: <REQUIRED - list of authors' names and optionally, email addresses>
sponsor: <OPTIONAL - name of sponsor, remove if not applicable>
discussions-to: <REQUIRED - URL of current canonical discussion thread>
status: <REQUIRED - draft | active | accepted | rejected | withdrawn | final>
---

<details markdown="1">
<summary>Table of Contents</summary>
* Table of Contents
{:toc}
</details>

# Abstract

[A short (~200 word) description of the technical issue being addressed.]

# Motivation

[Clearly explain why the existing language specification is inadequate to address the problem that the RFC solves.]

# Rationale

[Describe why particular design decisions were made.]

# Specification

[Describe the syntax and semantics of any new language feature.]

# Backwards Compatibility

[Describe potential impact and severity on pre-existing code.]

# Security Implications

[How could a malicious user take advantage of this new feature?]

# How to Teach This

[How to teach users, new and experienced, how to apply the RFC to their work.]

# Reference Implementation

[Link to any existing implementation and details about its state, e.g. proof-of-concept.]

# Rejected Ideas

[Why certain ideas that were brought while discussing this RFC were not ultimately pursued.]

# Open Issues

[Any points that are still being decided/discussed.]

# Footnotes

[A collection of footnotes cited in the RFC, and a place to list non-inline hyperlink targets.]

# Copyright

This document is placed in the public domain or under the
CC0-1.0-Universal license, whichever is more permissive.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.

This site is open source. Improve this page.