2
2
rfc : 2
3
3
title : RFC template
4
4
author :
Harald van Dijk <[email protected] >
5
- status : draft
6
- ---
7
-
8
- ``` text
9
- ---
10
- rfc: <REQUIRED: RFC number>
11
- title: <REQUIRED: RFC title>
12
- author: <REQUIRED: list of authors' names and optionally, email addresses>
13
- sponsor: <name of sponsor>
14
- status: <REQUIRED: draft | active | accepted | rejected | withdrawn | final>
5
+ status : active
15
6
---
16
7
17
8
<details markdown =" 1 " >
@@ -22,50 +13,67 @@ status: <REQUIRED: draft | active | accepted | rejected | withdrawn | final>
22
13
23
14
# Abstract
24
15
25
- [A short (~200 word) description of the technical issue being addressed.]
16
+ This RFC provides a boilerplate or sample template for creating your own
17
+ Markdown RFCs. In conjunction with the content guidelines in
18
+ [ RFC 1] [ rfc-0001 ] , this should make it easy for you to conform your own RFCs
19
+ to the format outlined below.
26
20
27
- # Motivation
21
+ Note: if you are reading this RFC via the web, you should first grab the textr
22
+ (Markdown) source of this RFC in order to complete the steps below. DO NOT USE
23
+ THE HTML FILE AS YOUR TEMPLATE!
28
24
29
- [Clearly explain why the existing language specification is inadequate to address the problem that the RFC solves.]
25
+ The source for this (or any) RFC can be found in the [ ` rfcs ` branch of the
26
+ oneAPI Construction Kit repository] [ ock-rfcs ] .
30
27
31
28
# Rationale
32
29
33
- [Describe why particular design decisions were made.]
34
-
35
- # Specification
36
-
37
- [Describe the syntax and semantics of any new language feature.]
38
-
39
- # Backwards Compatibility
40
-
41
- [Describe potential impact and severity on pre-existing code.]
42
-
43
- # Security Implications
44
-
45
- [How could a malicious user take advantage of this new feature?]
46
-
47
- # How to Teach This
30
+ If you intend to submit a RFC, you MUST use this template, in conjunction with
31
+ the format guidelines below, to ensure that your RFC submission won't get
32
+ automatically rejected because of form.
33
+
34
+ Markdown provides PEP authors with useful functionality and expressivity, while
35
+ maintaining easy readability in the source text. The processed HTML form makes
36
+ the functionality accessible to readers: live hyperlinks, styled text, tables,
37
+ images, and automatic tables of contents, among other advantages.
38
+
39
+ # How to Use This Template
40
+
41
+ - Make a copy of [ ` rfc-0002/rfc-NNNN.md ` ] [ rfc-nnnn ] (the ` .md ` file, ** not** the
42
+ HTML!) and perform the following edits. Name the new file ` rfc-NNNN.md ` , using
43
+ the next available number (not used by a published or in-PR RFC).
44
+ - Replace the "rfc" header with "rfc: NNNN", matching the file name. Note that
45
+ the file name should be padded with zeros (eg ` rfc-0002.md ` ), but the header
46
+ should not (` rfc: 2 ` ).
47
+ - Change the title header to the title of your RFC.
48
+ - Change the author header to include your name, and optionally your email
49
+ address. Be sure to follow the format carefully: your name must appear first,
50
+ and it must not be contained in parentheses. Your email address may appear
51
+ second (or it can be omitted) and if it appears, it must appear in angle
52
+ brackets. It is okay to obfuscate your email address.
53
+ - If none of the authors are core developers, include a Sponsor header with the
54
+ name of the core developer sponsoring your RFC.
55
+ - Add the direct URL of the RFC's canonical discussion thread (on e.g. GitHub
56
+ Discussions) under the discussions-to header. If the thread will be created
57
+ after the RFC is submitted as an official draft, it is okay to just list the
58
+ venue name initially, but remember to update the RFC with the URL as soon as
59
+ the RFC is successfully merged to the ` rfcs ` branch and you create the
60
+ corresponding discussion thread. See [ RFC 1] [ rfc-0001 ] for more details.
61
+ - Change the status header to "draft".
62
+ - Now write your Abstract, Rationale, and other content for your RFC, replacing
63
+ placeholders with your own text.
64
+ - Update your Footnotes section, listing any footnotes and non-inline link
65
+ targets referenced by the text.
66
+ - Create a pull request against the [ ` rfcs ` branch] [ ock-rfcs ] .
48
67
49
- [How to teach users, new and experienced, how to apply the RFC to their work.]
50
-
51
- # Reference Implementation
52
-
53
- [Link to any existing implementation and details about its state, e.g. proof-of-concept.]
54
-
55
- # Rejected Ideas
56
-
57
- [Why certain ideas that were brought while discussing this RFC were not ultimately pursued.]
58
-
59
- # Open Issues
60
-
61
- [Any points that are still being decided/discussed.]
62
-
63
- # Footnotes
68
+ ``` text
69
+ {% include_relative rfc-0002/rfc-NNNN.md %}
70
+ ```
64
71
65
- [A collection of footnotes cited in the RFC, and a place to list non-inline hyperlink targets.]
72
+ [ ock-rfcs ] : https://github.com/uxlfoundation/oneapi-construction-kit/tree/rfcs
73
+ [ rfc-0001 ] : rfc-0001.md
74
+ [ rfc-nnnn ] : https://github.com/uxlfoundation/oneapi-construction-kit/blob/rfcs/rfc-0002/rfc-NNNN.md
66
75
67
76
# Copyright
68
77
69
78
This document is placed in the public domain or under the
70
79
CC0-1.0-Universal license, whichever is more permissive.
71
- ```
0 commit comments