Fix some template formatting (#209)

Author: benbrandt

docs/rfds/TEMPLATE.md renamed to docs/rfds/TEMPLATE.mdx

@@ -1,3 +1,7 @@
+---
+title: "INSERT RFD TITLE HERE"
+---
+
 <!--
 
 Instructions:
@@ -10,23 +14,19 @@ Instructions:
 
 -->
 
----
-
-## title: "RFD TITLE"
-
-# Elevator pitch
+## Elevator pitch
 
 > What are you proposing to change?
 
 <!--
     Give a brief, high-level overview of what you plan to do and what problem you are solving. Feel free to use bullet points to help clarify the structure.
 -->
 
-# Status quo
+## Status quo
 
 > How do things work today and what problems does this cause? Why would we change things?
 
-# What we propose to do about it
+## What we propose to do about it
 
 > What are you proposing to improve the situation?
 
@@ -38,7 +38,7 @@ Instructions:
     You can also include multiple variants if you have different ideas of how to approach the problem, though these should be narrowed down as the RFD progresses.
 -->
 
-# Shiny future
+## Shiny future
 
 > How will things will play out once this feature exists?
 
@@ -49,7 +49,7 @@ Instructions:
     Note: This section is OPTIONAL when RFDs are first opened.
 -->
 
-# Implementation details and plan
+## Implementation details and plan
 
 > Tell me more about your implementation. What is your detailed implementation plan?
 
@@ -59,20 +59,20 @@ Instructions:
     Note: This section is OPTIONAL and NOT RECOMMENDED when RFDs are first opened. It can distract from the discussion of the problem.
 -->
 
-# Frequently asked questions
+## Frequently asked questions
 
 > What questions have arisen over the course of authoring this document or during subsequent discussions?
 
 <!--
     Keep this section up-to-date as discussion proceeds. The goal is to capture major points that came up on a PR or in a discussion forum -- and if they reoccur, to point people to the FAQ so that we can start the dialog from a more informed place.
 -->
 
-## What alternative approaches did you consider, and why did you settle on this one?
+### What alternative approaches did you consider, and why did you settle on this one?
 
 None. The idea came to me fully formed, like Athena springing from Zeus's head.
 
 <!-- You...may want to adjust this. -->
 
-# Revision history
+## Revision history
 
 <!-- If there have been major updates to this RFD, you can include the git revisions and a summary of the changes. -->

docs/rfds/introduce-rfd-process.mdx

@@ -2,78 +2,78 @@
 title: "Introduce RFD Process"
 ---
 
-# Elevator pitch
+## Elevator pitch
 
 > What are you proposing to change? Bullet points welcome.
 
 Introduce a "Request for Dialog" (RFD) process to replace ad-hoc design discussions with structured, community-friendly design documents that track features from conception to completion.
 
-# Status quo
+## Status quo
 
 > How do things work today and what problems does this cause? Why would we change things?
 
 Currently all development is being done primarily by the Zed team tracking requests and proposals from multiple teams. The goal is to create a process that helps to keep files organized and which can scale to participation by an emerging community.
 
-# Shiny future
+## Shiny future
 
 > How will things will play out once this feature exists?
 
-## Project licensing
+### Project licensing
 
 All code and RFDs are licensed under an Apache 2.0 license. The project is intended to remain open source and freely available in perpetuity.
 
-## Decision making
+### Decision making
 
 For the initial phase, the project shall have a "design team" that consists of the Zed team acting in "BDFL" capacity. The expectation is that the project will setup a more structure governance structure as it grows. The design team makes all decisions regarding RFDs and sets overall project direction.
 
-## RFD lifecycle
+### RFD lifecycle
 
-### RFDs are proposed by opening a PR
+#### RFDs are proposed by opening a PR
 
 An RFD begins as a PR adding a new file into the "Draft" section. The RFD can start minimal - just an elevator pitch and status quo are enough to begin dialog. Pull requests become the discussion forum where ideas get refined through collaborative iteration.
 
 As discussion proceeds, the FAQ of the RFD should be extended. If discussion has been going long enough, the PR should be closed, feedback summarized, and then re-opened with a link to the original PR.
 
-### The PR is merged into "draft" once a core team member decides to champion it
+#### The PR is merged into "draft" once a core team member decides to champion it
 
 RFD proposals are merged into the "draft" section if a core team member decides to champion them. The champion is then the point-of-contact for that proposal going forward and they will work with the proposal authors and others to make it reality. Core team members do not need to seek consensus to merge a proposal into the draft, but they should listen carefully to concerns from other core team members, as it will be difficult to move the RFD forward if those concerns are not ultimately addressed.
 
 Once a proposal is moved to draft, code and implementation may begin to land into the PR. This work needs to be properly feature gated and marked with the name of the RFD.
 
 Further discussion on the RFD can take place on Slack if needed.
 
-### Moving to the "preview" section
+#### Moving to the "preview" section
 
 Once the champion feels the RFD is ready for others to check it out, they can open a PR to move the file to the preview section. This is a signal to the community (and particularly other core team members) to check out the proposal and see what they think. The PR should stay open for "a few days" to give people an opportunity to leave feedback. The champion is empowered to decide whether to land the PR. As ever, all new feedback should be recorded in the FAQ section.
 
-### Deciding to accept an RFD
+#### Deciding to accept an RFD
 
 When they feel the RFD is ready to be completed, the champion requests review by the team. The team can raise concerns and notes during discussion. Final decision on an RFD is made by the core team lead.
 
-### Implementation of an RFD
+#### Implementation of an RFD
 
 Once accepted, RFDs become living documents that track implementation progress. Status badges in design documentation link back to the relevant RFD, creating a clear connection between "why we're building this" and "how it works." When building code with an agent, agents should read RFDs during implementation to understand design rationale and update them with implementation progress.
 
-## Moderating and managing RFD discussions
+### Moderating and managing RFD discussions
 
 Moving RFDs between points in the cycle involve opening PRs. Those PRs will be places to hold dialog and discussion -- but not the only place, we expect more detailed discussions to take place on Slack or other communication channels. RFD owners and champions should actively "curate" discussions by collecting questions that come up and ensuring they are covered in the FAQ. Duplicate questions can be directed to the FAQ.
 
 If the discussion on the PR gets to the point where Github begins to hide comments, the PR should typically be closed, feedback collected, and then re-opened.
 
-# Implementation plan
+## Implementation plan
 
 > What is your implementation plan?
 
 - ✅ Create RFD infrastructure (about, TEMPLATE, navigation setup)
 - ✅ Establish lifecycle: Draft → Preview → Accepted → Completed
 - ⏳ Write RFDs for major in-progress features
 
-# Frequently asked questions
+## Frequently asked questions
 
-## Why "Request for Dialog" and not "Request for Comment"?
+### Why "Request for Dialog" and not "Request for Comment"?
 
 Well, partly because "dialog" emphasizes conversation and exploration rather than just collecting feedback on a predetermined design. We also shamelessly stole this process from [Niko Matsakis and the Symposium project](https://symposium-dev.github.io/symposium/rfds/index.html) (with permission) so that we could benefit from their experience.
 
-# Revision history
+## Revision history
 
 - 2025-10-28: Initial version, created alongside RFD infrastructure