-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[Docs] Explain how to propose an extension in Clang #130803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Docs] Explain how to propose an extension in Clang #130803
Conversation
We have a list of criteria for proposing an extension in Clang, but we do not have any documentation about how to propose an extension. This adds some basic documentation about how we run RFCs in Clang, as well as adds a list of Clang Area Team members in support of the process. It could be argued that this should be documented for the entire LLVM Project, however, other parts of the project have different rules for proposing extensions. (Extending libc++ is a different proposition than extending LLVM, than extending MLIR, than extending Clang, etc.) We may want to introduce high-level documentation for the LLVM Project, but that is a bigger project and we already have the documentation in Clang about criteria for extensions. So it seems reasonable to add some lightweight documentation specific to Clang until we determine what to do at the whole project level.
This is more similar to how it is presented in the maintainers list and also gives Discourse, GitHub, and Discord handles in addition to email.
@llvm/pr-subscribers-clang Author: Aaron Ballman (AaronBallman) ChangesWe have a list of criteria for proposing an extension in Clang, but we do not have any documentation about how to propose an extension. This adds some basic documentation about how we run RFCs in Clang, as well as adds a list of Clang Area Team members in support of the process. It could be argued that this should be documented for the entire LLVM Project, however, other parts of the project have different rules for proposing extensions. (Extending libc++ is a different proposition than extending LLVM, than extending MLIR, than extending Clang, etc.) We may want to introduce high-level documentation for the LLVM Project, but that is a bigger project and we already have the documentation in Clang about criteria for extensions. So it seems reasonable to add some lightweight documentation specific to Clang until we determine what to do at the whole project level. Full diff: https://github.com/llvm/llvm-project/pull/130803.diff 2 Files Affected:
diff --git a/clang/AreaTeamMembers.txt b/clang/AreaTeamMembers.txt
new file mode 100644
index 0000000000000..964d11e79f694
--- /dev/null
+++ b/clang/AreaTeamMembers.txt
@@ -0,0 +1,17 @@
+This is a list of the current Clang Area Team members.
+
+Chair
+-----
+Aaron Ballman
+[email protected] (email), AaronBallman (Discourse), AaronBallman (GitHub), AaronBallman (Discord)
+
+Secretary
+---------
+Reid Kleckner
+[email protected] (email), rnk (Discourse), rnk (GitHub), rnk (Discord)
+
+Other Members
+-------------
+Eli Friedman
+[email protected]> (email), efriedma-quic (Discourse), efriedma-quic (GitHub)
+
diff --git a/clang/www/get_involved.html b/clang/www/get_involved.html
index 99fa03abb6234..1939289463f3d 100755
--- a/clang/www/get_involved.html
+++ b/clang/www/get_involved.html
@@ -83,7 +83,7 @@ <h2 id="criteria">Contributing Extensions to Clang</h2>
for Clang. The benefits of the extension need to be evaluated against
these costs. The Clang project uses the following criteria for this
evaluation:</p>
-
+<p>
<ol>
<li>Evidence of a significant user community: This is based on a number of
factors, including an existing user community, the perceived likelihood that
@@ -133,7 +133,36 @@ <h2 id="criteria">Contributing Extensions to Clang</h2>
support the extension and what level of support is expected. The impacted
project communities need to agree with that plan.</li>
</ol>
-
+</p>
+<p>
+The Clang community uses an RFC process to evaluate potential extensions for
+inclusion in the tool. First, write a post in the <code>Clang Frontend</code>
+category of <a href="https://discourse.llvm.org/c/clang/6">Discourse</a>. The
+title should include <code>[RFC]</code> so it is clear that it is a proposed
+change. The post should have detailed information about the change itself, the
+motivation for needing the change, how it addresses the criteria listed above,
+and any other relevant details the community should be aware of.
+</p>
+<p>
+The community will discuss the proposal in Discourse, asking questions about
+the proposal to improve their understanding and giving support or dissent for
+the idea. Eventually, consensus will be determined as to whether the proposal
+should proceed or be rejected. If a proposal receives little or no feedback,
+that typically means that the proposal is rejected due to lack of interest.
+</p>
+<p>
+Sometimes, a consensus position is unclear and the proposal author will need
+additional guidance on what next steps to take. In such a case, the Clang Area
+Team may get involved. The Clang Area Team secretary will proactively look for
+RFCs that appear to not have a clear path forward to add them to the team's
+agenda. If anyone would like to put an RFC onto the team's agenda explicitly,
+they can tag any one of the <a href="https://github.com/llvm/llvm-project/blob/main/clang/AreaTeamMembers.txt">
+Clang Area Team</a> members in a comment on the RFC to get their attention. The
+area team will host a meeting to discuss the RFC and determine next steps for
+the proposal. In the event no clear community consensus position seems likely
+to ever form, the Clang Area Team will make a final judgement call on whether
+the RFC will proceed or not. <!-- TODO: link to area team processes -->
+</p>
</div>
</body>
</html>
|
Eventually, I expect we'll add documentation about the Clang Area Team to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me - thanks for writing it up! (could wait for other folks to chime in too, but seems pretty harmless to launch/iterate/etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds right on; thanks for working on this.
We have a list of criteria for proposing an extension in Clang, but we do not have any documentation about how to propose an extension. This adds some basic documentation about how we run RFCs in Clang, as well as adds a list of Clang Area Team members in support of the process. It could be argued that this should be documented for the entire LLVM Project, however, other parts of the project have different rules for proposing extensions. (Extending libc++ is a different proposition than extending LLVM, than extending MLIR, than extending Clang, etc.) We may want to introduce high-level documentation for the LLVM Project, but that is a bigger project and we already have the documentation in Clang about criteria for extensions. So it seems reasonable to add some lightweight documentation specific to Clang until we determine what to do at the whole project level.
We have a list of criteria for proposing an extension in Clang, but we do not have any documentation about how to propose an extension. This adds some basic documentation about how we run RFCs in Clang, as well as adds a list of Clang Area Team members in support of the process.
It could be argued that this should be documented for the entire LLVM Project, however, other parts of the project have different rules for proposing extensions. (Extending libc++ is a different proposition than extending LLVM, than extending MLIR, than extending Clang, etc.) We may want to introduce high-level documentation for the LLVM Project, but that is a bigger project and we already have the documentation in Clang about criteria for extensions. So it seems reasonable to add some lightweight documentation specific to Clang until we determine what to do at the whole project level.