Redo initial RFC process commit (#2)

CODEOWNERS

@@ -0,0 +1,2 @@
+# These are the approvers for Lit RFCs
+* @graynorton @justinfagnani @kevinpschaaf @sorvell

README.md

@@ -1,2 +1,143 @@
-# rfcs
-RFCs for changes to Lit
+# Lit RFC Process
+
+The Lit RFC ("request for comment") process is a way for "substantial" changes to Lit to be proposed, discussed, designed, refined, and ultimately reach consensus before being implemented or merged into the Lit core libraries.
+
+## Objective
+
+### Goals
+
+* Bring increased visibility, community feedback, and deliberation to feature requests
+* Allow our community to better observe and participate in the Lit team design processes
+* Create more opportunities for community contributions: making and editing RFCs, feedback, implementation, etc.
+* Raise the quality of feature requests
+* Have a consistent and known process for evaluating feature requests
+* Create a public record of change discussions, especially rationale for accepting or rejecting a feature request
+* Raise the barrier _just a bit_ to making larger feature requests to help with volume, noise, and quality
+* Move large and likely longer-to-be-open feature requests out of issues, helping us maintain a smaller and cleaner issue backlog
+
+## What is an RFC?
+
+RFC refers to the IETF's [Request For Comments](https://en.wikipedia.org/wiki/Request_for_Comments) process. An RFC is a document or set of documents that describe a feature in detail, and go through a process of review and approval.
+
+For Lit, RFCs are markdown files in the lit/rfcs repository.
+
+RFCs have a structure as defined in the [RFC template](./rfcs/0000-rfc-template.md), including these metadata and sections:
+
+* Champion(s): The people making and maintaining the proposal. This can change over time.
+* Stage: Active, Implemented, Deprecated
+* Summary
+* Objective (goals and non-goals)
+* Motivation (background)
+* Detailed Design, including these recommended sections:
+    * Implementation Plan
+    * Backward Compatibility
+    * Testing Plan
+    * Performance and Code Size Impact
+    * Interoperability
+    * Security Impact
+    * Documentation Plan
+* Downsides
+* Alternatives
+
+Accepted RFCs are not a guarantee that a feature will be developed and included in Lit. They are an indication that the team has consensus on a feature and design, and is open to accepting PRs to implement it. Things can change, and new information such as implementation feedback may lead the team to deprecate an RFC.
+
+## When to use RFCs
+
+RFCs must be created for new and "substantial" changes. "Substantial" is somewhat subjective, but some clear signs are:
+
+* New packages
+* New modules, classes, directives, etc. in an existing package
+* Most new public-facing API
+* Breaking changes
+
+Changes that do _not_ require an RFC:
+
+* Internal implementation changes
+* Bug fixes
+* Most dev mode changes: warnings, etc.
+
+These criteria leave a category of small changes and experiments open to debate on whether they deserve or require an RFC. We do not wish to slow down development with too much process, so we will leave this area to the discretion of the core team. We will adjust the criteria for requiring RCFs over time.
+
+#### Relationship to Lit Labs
+
+The Lit project also has a labs process for pre-production experimentation and feedback. With the assumption that when we create a labs package we usually intend for it to eventually graduate, most labs packages should have (or be part of) an RFC.
+
+## RFC Process
+
+### Stages
+
+RFCs go through the following stages during their lifetime:
+
+* **Proposed** When an RFC is proposed in an open pull request and being reviewed and iterated on. This is not a state recorded in the RFC metadata, so all RFC PRs will start with a state of `Active`.
+* **Rejected** When an RFC is rejected and its PR closed.
+* **Active** When an RFC has been accepted, and its PR merged, but hasn't yet been implemented.
+* **Implemented** When an RFC has been implemented and its feature released.
+* **Withdrawn** When a *previously accepted* RFC has been rejected or withdrawn due to new information, such as implementation difficulty.
+* **Deprecated** When a *previously accepted*, and possibly implemented RFC has been superceded by a new RFC.
+
+### Before opening an RFC
+
+RFCs involve more work than an issue, both to open one and to review one. Before opening an RFC is it a good idea to get some indication of interest from the Lit core team or strong support from the community.
+
+You may get this indication in several ways, from informal to formal:
+
+* A feature request issue is closed with a request to open an RFC
+* A core team member directly invites you to open an RFC from a community or support channel like GitHub Discussions, Slack, or Twitter
+* You open a "[RRFC](https://github.com/lit/rfcs/issues/new)" (Requesting Request For Comment) issue in lit/rfcs and get positive feedback 
+
+### Opening an RFC
+
+1. Fork the lit/rfcs repo
+2. Draft the RFC
+    1. Add the RFC file to /rfcs in a markdown file named `NNNN-_descriptive-name_.md`
+        1. Note the `NNNN` is literal. RFCs will not have an assigned RFC number when first opened.
+3. Open an RFC pull request
+    1. Optionally share the draft on [GH discussions](https://github.com/lit/lit/discussions) or [Slack](https://lit.dev/slack-invite/) before opening a pull request
+    2. Once opened, update the RFC with a link to the RFC PR in the metadata. This allows readers of the RFCs to find the review discussions.
+
+### Discussion and Iteration
+
+RFCs must be discussed and reviewed by the relevant maintainers, Lit project leadership, and other stakeholders before being accepted or rejected.
+
+#### Reviewers
+
+RFCs must be reviewed by Lit project leadership and by project area maintainers. Lit project leadership who can approve RFCs are listed in the lit/rfcs repo's [CODEOWNERS](./CODEOWNERS) file. RFCs must be approved by leadership before moving to active stage and being merged. Area maintainers are sometimes identifiable by who is active on certain projects in the lit/lit monorepo, but the Lit team can add the appropriate people as reviews if it's unclear.
+
+#### Timeline
+
+Many RFC processes have a prescribed timeline for discussion. We aren't yet sure what timelines for feedback are both most productive and attainable. For the time being we aim to have initial feedback within about 7 days and an accepted or rejected decision within about 30 days.
+
+#### Acceptance
+
+Once accepted, RFCs are assigned an RFC number and pull requests are updated and merged. This means that all RFCs in lit/rfcs start as active. Rejected RFC pull requests are closed.
+
+#### RFC Meetings
+
+RFC stakeholders may decide that RFCs need or could benefit from live community discussion. They will be added to the RFC meetings agenda list and discussed at the next opportunity.
+
+### Updates and Amendments
+
+After being accepted and moved to the `Active` stage, RFCs are intended to stay _mostly_ unchanged. The *design* review and feedback will have taken place in the RFC PR review.
+
+However, it's often the case that designs must be chenged due to implementation feedback. In this case `Active` RFCs can be updated via additional PRs. Implementation PRs should note when they diverge from an RFC and create a parallel RFC update PR.
+
+Small changes to RFCs can be made to:
+
+* Add clarifications
+* Update metadata and other non-design text (examples, documentation)
+* Changes to implementation, possibly based on implementor feedback
+
+_Major_ changes proposed to an RFC, such as an alternative to the feature or very different public API and behavior should be done in a new RFC. If a new RFC deprecates a previous RFC, it must mark the previous RFC as deprecated with a link to the new RFC. Otherwise the new RFC should update the previous RFC with a link and callouts to the new RFCs in relevant places.
+
+### Implementation
+
+As RFCs are implemented, they should be updated to indicate so. The status is updated to *Implemented* and relevant PRs linked.
+
+## Other RFC Processes
+
+The projects have served as inspiration for our process:
+
+* [Ember](https://github.com/emberjs/rfcs)
+* [npm](https://github.com/npm/rfcs)
+* [Fuchsia](https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/contribute/governance/rfcs/rfc_process.md)
+* [Vue](https://github.com/vuejs/rfcs)

rfcs/0000-rfc-template.md

@@ -0,0 +1,67 @@
+---
+Status: Active
+Champions: {{ your_github_username }}
+PR: {{ update_with_pr_number }}
+---
+
+# {{ TITLE }}
+
+Brief summary paragraph describing the RFC.
+
+## Objective
+
+What is the RFC trying to accomplish?
+
+### Goals
+- Specific goals of the RFC
+
+### Non-Goals
+- Specific non-goals of the RFC
+
+## Motivation
+
+Why is the RFC neccessary? What background information is needed to understand why?
+
+## Detailed Design
+
+Describe the change in detail. Include API changes and usage examples. Add your own sub-headings as necessary.
+
+## Implementation Considerations
+
+### Implementation Plan
+
+Is there anything important to note about implementation plan? Can it be done in a single PR or will it need to be staged out across several?
+
+### Backward Compatibility
+
+Backwards compatibility is extremely important to Lit, especially in the core libraries. Does this proposal break backwards compatibility? Are there workarounds?
+
+### Testing Plan
+
+How will this proposal be tested? Are unit tests sufficient, or do we need integration tests? Is any unique testing infrastructure required?
+
+### Performance and Code Size Impact
+
+What impact will this proposal have on performance and code size? What benchmarks should we create to evaluate the proposal?
+
+### Interoperability
+
+Is this proposal for a feature that could be interoperable across web components not written in Lit? Does it create a tight coupling between components written in Lit? Could it be a [Web Components Community Group](https://github.com/w3c/webcomponents-cg) [Community Protocol](https://github.com/webcomponents-cg/community-protocols)?
+
+### Security Impact
+
+What impact will this proposal have on security? Does the proposal require a security review? (We have a security team available for reviews)
+
+We especially care about the handling of untrusted user input by library code so that we contnue to prevent XSS vectors.
+
+### Documentation Plan
+
+Do we need to create or update any documentation to complete this proposal? Does related documentation have a clear home in our docs outline? What playground examples or tutorials should be created?
+
+## Downsides
+
+Many proposals involve trade-offs. What are they for this proposal and what are the downsides of this approach?
+
+## Alternatives
+
+What alternatives were considered and rejected? Why?

rfcs/0001-rfc-process.md

@@ -0,0 +1,149 @@
+---
+Status: Accepted
+Champions: @justinfagnani
+PR:
+---
+
+# Lit RFC Process
+
+The Lit RFC ("request for comment") process is a way for "substantial" changes to Lit to be proposed, discussed, designed, refined, and ultimately reach consensus before being implemented or merged into the Lit core libraries.
+
+## Objective
+
+### Goals
+
+* Bring increased visibility, community feedback, and deliberation to feature requests
+* Allow our community to better observe and participate in the Lit team design processes
+* Create more opportunities for community contributions: making and editing RFCs, feedback, implementation, etc.
+* Raise the quality of feature requests
+* Have a consistent and known process for evaluating feature requests
+* Create a public record of change discussions, especially rationale for accepting or rejecting a feature request
+* Raise the barrier _just a bit_ to making larger feature requests to help with volume, noise, and quality
+* Move large and likely longer-to-be-open feature requests out of issues, helping us maintain a smaller and cleaner issue backlog
+
+## What is an RFC?
+
+RFC refers to the IETF's [Request For Comments](https://en.wikipedia.org/wiki/Request_for_Comments) process. An RFC is a document or set of documents that describe a feature in detail, and go through a process of review and approval.
+
+For Lit, RFCs are markdown files in the lit/rfcs repository.
+
+RFCs have a structure as defined in the [RFC template](./0000-rfc-template.md), including these metadata and sections:
+
+* Champion(s): The people making and maintaining the proposal. This can change over time.
+* Stage: Active, Implemented, Deprecated
+* Summary
+* Objective (goals and non-goals)
+* Motivation (background)
+* Detailed Design, including these recommended sections:
+    * Implementation Plan
+    * Backward Compatibility
+    * Testing Plan
+    * Performance and Code Size Impact
+    * Interoperability
+    * Security Impact
+    * Documentation Plan
+* Downsides
+* Alternatives
+
+Accepted RFCs are not a guarantee that a feature will be developed and included in Lit. They are an indication that the team has consensus on a feature and design, and is open to accepting PRs to implement it. Things can change, and new information such as implementation feedback may lead the team to deprecate an RFC.
+
+## When to use RFCs
+
+RFCs must be created for new and "substantial" changes. "Substantial" is somewhat subjective, but some clear signs are:
+
+* New packages
+* New modules, classes, directives, etc. in an existing package
+* Most new public-facing API
+* Breaking changes
+
+Changes that do _not_ require an RFC:
+
+* Internal implementation changes
+* Bug fixes
+* Most dev mode changes: warnings, etc.
+
+These criteria leave a category of small changes and experiments open to debate on whether they deserve or require an RFC. We do not wish to slow down development with too much process, so we will leave this area to the discretion of the core team. We will adjust the criteria for requiring RCFs over time.
+
+#### Relationship to Lit Labs
+
+The Lit project also has a labs process for pre-production experimentation and feedback. With the assumption that when we create a labs package we usually intend for it to eventually graduate, most labs packages should have (or be part of) an RFC.
+
+## RFC Process
+
+### Stages
+
+RFCs go through the following stages during their lifetime:
+
+* **Proposed** When an RFC is proposed in an open pull request and being reviewed and iterated on. This is not a state recorded in the RFC metadata, so all RFC PRs will start with a state of `Active`.
+* **Rejected** When an RFC is rejected and its PR closed.
+* **Active** When an RFC has been accepted, and its PR merged, but hasn't yet been implemented.
+* **Implemented** When an RFC has been implemented and its feature released.
+* **Withdrawn** When a *previously accepted* RFC has been rejected or withdrawn due to new information, such as implementation difficulty.
+* **Deprecated** When a *previously accepted*, and possibly implemented RFC has been superceded by a new RFC.
+
+### Before opening an RFC
+
+RFCs involve more work than an issue, both to open one and to review one. Before opening an RFC is it a good idea to get some indication of interest from the Lit core team or strong support from the community.
+
+You may get this indication in several ways, from informal to formal:
+
+* A feature request issue is closed with a request to open an RFC
+* A core team member directly invites you to open an RFC from a community or support channel like GitHub Discussions, Slack, or Twitter
+* You open a "[RRFC](https://github.com/lit/rfcs/issues/new)" (Requesting Request For Comment) issue in lit/rfcs and get positive feedback 
+
+### Opening an RFC
+
+1. Fork the lit/rfcs repo
+2. Draft the RFC
+    1. Add the RFC file to /rfcs in a markdown file named `NNNN-_descriptive-name_.md`
+        1. Note the `NNNN` is literal. RFCs will not have an assigned RFC number when first opened.
+3. Open an RFC pull request
+    1. Optionally share the draft on [GH discussions](https://github.com/lit/lit/discussions) or [Slack](https://lit.dev/slack-invite/) before opening a pull request
+    2. Once opened, update the RFC with a link to the RFC PR in the metadata. This allows readers of the RFCs to find the review discussions.
+
+### Discussion and Iteration
+
+RFCs must be discussed and reviewed by the relevant maintainers, Lit project leadership, and other stakeholders before being accepted or rejected.
+
+#### Reviewers
+
+RFCs must be reviewed by Lit project leadership and by project area maintainers. Lit project leadership who can approve RFCs are listed in the lit/rfcs repo's [CODEOWNERS](../CODEOWNERS) file. RFCs must be approved by leadership before moving to active stage and being merged. Area maintainers are sometimes identifiable by who is active on certain projects in the lit/lit monorepo, but the Lit team can add the appropriate people as reviews if it's unclear.
+
+#### Timeline
+
+Many RFC processes have a prescribed timeline for discussion. We aren't yet sure what timelines for feedback are both most productive and attainable. For the time being we aim to have initial feedback within about 7 days and an accepted or rejected decision within about 30 days.
+
+#### Acceptance
+
+Once accepted, RFCs are assigned an RFC number and pull requests are updated and merged. This means that all RFCs in lit/rfcs start as active. Rejected RFC pull requests are closed.
+
+#### RFC Meetings
+
+RFC stakeholders may decide that RFCs need or could benefit from live community discussion. They will be added to the RFC meetings agenda list and discussed at the next opportunity.
+
+### Updates and Amendments
+
+After being accepted and moved to the `Active` stage, RFCs are intended to stay _mostly_ unchanged. The *design* review and feedback will have taken place in the RFC PR review.
+
+However, it's often the case that designs must be chenged due to implementation feedback. In this case `Active` RFCs can be updated via additional PRs. Implementation PRs should note when they diverge from an RFC and create a parallel RFC update PR.
+
+Small changes to RFCs can be made to:
+
+* Add clarifications
+* Update metadata and other non-design text (examples, documentation)
+* Changes to implementation, possibly based on implementor feedback
+
+_Major_ changes proposed to an RFC, such as an alternative to the feature or very different public API and behavior should be done in a new RFC. If a new RFC deprecates a previous RFC, it must mark the previous RFC as deprecated with a link to the new RFC. Otherwise the new RFC should update the previous RFC with a link and callouts to the new RFCs in relevant places.
+
+### Implementation
+
+As RFCs are implemented, they should be updated to indicate so. The status is updated to *Implemented* and relevant PRs linked.
+
+## Other RFC Processes
+
+The projects have served as inspiration for our process:
+
+* [Ember](https://github.com/emberjs/rfcs)
+* [npm](https://github.com/npm/rfcs)
+* [Fuchsia](https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/docs/contribute/governance/rfcs/rfc_process.md)
+* [Vue](https://github.com/vuejs/rfcs)