From 6fc763702b1661e7d24cf5e4183a25666517521e Mon Sep 17 00:00:00 2001 From: Matt Small Date: Mon, 11 Dec 2023 13:03:59 -0800 Subject: [PATCH 1/8] template --- rfcs/0005-rfc-governance.md | 67 +++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 rfcs/0005-rfc-governance.md diff --git a/rfcs/0005-rfc-governance.md b/rfcs/0005-rfc-governance.md new file mode 100644 index 0000000..7612573 --- /dev/null +++ b/rfcs/0005-rfc-governance.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 necessary? 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? From e232780ade871b9f33dbd355b83f88ad341c34d2 Mon Sep 17 00:00:00 2001 From: Matt Small Date: Mon, 11 Dec 2023 16:10:50 -0800 Subject: [PATCH 2/8] draft of the text --- rfcs/0005-rfc-governance.md | 230 +++++++++++++++++++++++++++++++++++- 1 file changed, 225 insertions(+), 5 deletions(-) diff --git a/rfcs/0005-rfc-governance.md b/rfcs/0005-rfc-governance.md index 7612573..74bb66f 100644 --- a/rfcs/0005-rfc-governance.md +++ b/rfcs/0005-rfc-governance.md @@ -1,30 +1,250 @@ --- Status: Active -Champions: {{ your_github_username }} +Champions: smalls PR: {{ update_with_pr_number }} --- -# {{ TITLE }} +# Governance -Brief summary paragraph describing the RFC. +Update & clarify Lit's governance mode ## Objective -What is the RFC trying to accomplish? +The Lit project works toward a better, lower-friction web platform by promoting +interoperable standards for existing and emergent developer needs, and +fostering an open and healthy ecosystem around these standards. + +We'd like to apply these same values to our project. In this RFC, we propose +updating the Lit governance model (documented primarily in a new file, +`GOVERNANCE.md`) to make it clear that our community members have an important +role in deciding the future of Lit. While Google owns and operates the Lit +project repo, project roles are open to all contributors. ### Goals - Specific goals of the RFC +TODO + ### Non-Goals - Specific non-goals of the RFC +TODO + ## Motivation Why is the RFC necessary? What background information is needed to understand why? +TODO + ## Detailed Design -Describe the change in detail. Include API changes and usage examples. Add your own sub-headings as necessary. +If this RFC is accepted, we will propose a PR for further iteration, using the +language here as a starting point. This RFC also includes initial lists of +Members and Maintainers (which will become `MEMBERS.md` and `MAINTAINERS.md` in +the PR). + +### GOVERNANCE.md + +### Mission, Vision, Values + +We seek to build a better, lower-friction web platform by promoting +interoperable standards for existing and emergent developer needs. Whereas most +web frameworks ask "how might we best solve this developer need in userspace?", +on the Lit project we ask "how might this need be met by a new interoperable +standard, either as a new web platform feature or as a shared protocol +implementable by any framework?" As a corollary, our library development is +very tightly linked to developments in browser standards/implementation, +building on long-term relationships with Chrome, the W3C, community groups, +etc. + +A key tenent of our decision-making framework involves applying this "ethos" of +standards-based interoperability to questions of features, roadmap, and +prioritization – and this tenent is both a core value and a key differentiator +of Lit. Decisions at all levels (from release planning to approving new +features) are judged through this lens. + +We strive for transparency in our decision making and regularly look to the +project community for feedback. The Lit project repo is currently owned and +managed by Google; however project membership and Maintainer status is open to +all contributors of the project. Project roles and responsibilities are given +to the people, not their employer. This includes members of the Lit team at +Google; not all members of the team will be project Members or Maintainers, and +they will go through the process outlined here to achieve additional roles. + +### How We Work + +Lit strives to operate in the open, with full transparency to all members of +our community. + +#### Issues and Tasks + +These are tracked in Github and visible to all. We hold weekly engineering (see +our [calendar](https://lit.dev/community-calendar/) meetings where Members and +Maintainers review progress and discuss open topics. + +#### Features / Substantial Changes + +Lit uses a Request for Comment process (RFC) to evaluate substantial changes to +the project, including governance. Any community member may open an RFC, and +we welcome input from all. Approval of them is limited to Maintainers; an RFC +is approved when more than half of all Maintainers vote to approve the RFC. + +#### Releases + +The project uses a monorepo that is generally in a state such that it can be +released at any time. Releases are typically done at ad-hoc intervals based on +the need/desire to publish specific fixes and features. Major version changes +are rare and are done with large community awareness and outreach. + +The release process is driven by the Maintainers of Lit. + +#### Communication + +Github is our “source of truth” for project discussions and decisions. At times +when a quick answer is needed, we have a Discord available for chat. We +recognize that chat is ephemeral and therefore you may be asked to create an +issue or RFC for the question you raise. This is so that all in the community +are able to be involved in the discussion, and decisions are not made in silos, +and so we have durable records of the discussions and decisions reached. + +### Contributors + +In order to facilitate contributions at different levels, we have set up +different project roles at various levels of involvement. Community members +generally start at the first levels of the "ladder" and advance up it as their +responsibilities grow. A key attribute of contributors at each level is helping +others in the community - reviewing their code, helping them to use Lit, +recognizing when their contributions warrant a new role in the project. + +We value transparency and openness in the Lit project, and as a result on the +rare occasion that exceptions must be made to this incremental progression +(e.g., a new maintainer is urgently needed or a new sub-project is accepted) we +will still follow the open process for joining at the required level. + +We do not expect this to be a static list of roles - as Lit continues to +evolve, so will our project needs. We will leverage our RFC process to document +these changes. + +#### User + +Our users are the most important role of Lit - without users, Lit is not +useful. Anyone can be a user and there are no special requirements. + +We do encourage our users to interact with our broader community. Feedback +about successes is wonderful, as is hearing about how Lit could do better. Some +other ways that Users can support the project: By trying pre-releases and +giving us feedback Discussing Lit by word of mouth, in your communities, and +your projects Supporting others in the community By making new components, and +sharing them with the community Showing off apps that are built with Lit + +We love to hear how our users are being successful with Lit. We have a special +[Showcase](https://discord.com/channels/1012791295170859069/1014310579852300439) +Discord channel especially for this purpose. + +We ask that all of our users follow our [Code of +Conduct](https://github.com/lit/lit/blob/main/CODE_OF_CONDUCT.md) when +interacting with the project. + +#### Contributor + +A Contributor contributes directly to the project in some way. These +contributions don’t have to be code, but they can be - commenting on PRs, +filing issues, presenting at a community event are all contributions. Github +tracks code Contributors on a [contributors +list](https://github.com/lit/lit/graphs/contributors), but please keep in mind +this is not the exhaustive list of project contributors. + +When making a contribution, please follow our [Contribution +Guide](https://github.com/lit/lit/blob/main/CONTRIBUTING.md). + +#### Member + +A Member of the Lit project is a Contributor with recognized, consistent +contributions to the project. They are actively pushing to the project, and +have enhanced permissions to enable this. They are likely to have an area of +focus (eg expertise with a Lit subsystem, our docs/lit.dev site, etc), or they +may have general expertise across the Lit codebase. + +Members are eligible for enhanced GitHub permissions (GitHub Write and +[CODEOWNERS](https://github.com/lit/lit/blob/main/.github/CODEOWNERS)) for +their area of focus. + +We ask that our Members continue to support and mentor our Contributors, to +help them grow into Members as well. This includes prioritizing reviews, and +providing good feedback on those reviews. When a Member believes that an +individual is ready to join the Members list, they should nominate them (by +creating a PR to amend `MEMBERS.md`); a majority of all Members is required to +approve that PR. + + +#### Maintainer + +Maintainers are very established contributors who are responsible for the +entire project. + +They have the ability to approve PRs against any area of the project, and are +expected to participate in making decisions about the strategy and priorities +of the project. Maintainers are responsible for voting on RFCs, and may have +enhanced GitHub permissions (like GitHub Maintain) if needed. + +We ask that our Maintainers support and mentor our Contributors and Members, to +help them grow into Maintainers as well. This includes prioritizing reviews, +and providing good feedback on proposals and RFCs. When a Member believes that +an individual is ready to join the Maintainers list, they should nominate them +(by creating a PR to amend `MAINTAINERS.md`). A majority of all Maintainers are +required to approve the PR adding the new Maintainer. + +#### Stepping Down / Removal + +If and when a Member or Maintainer’s commitment levels change, they can +consider stepping down (moving down the contributor ladder) or moving to +emeritus status (completely stepping away from the project). + +Contact the Maintainers about changing to Emeritus status, or reducing your +contributor level. + +#### Involuntary Removal or Demotion + +Involuntary removal/demotion of a contributor happens when responsibilities and +requirements aren't being met. This may include repeated patterns of +inactivity, extended period of inactivity, a period of failing to meet the +requirements of your role, and/or a violation of the Code of Conduct. This +process is important because it protects the community and its deliverables +while also opens up opportunities for new contributors to step in. + +Involuntary removal or demotion is handled through a vote by a majority of the +current Maintainers. + +### Proposed `MEMBERS.md` + +43081j +bencbradshaw +benjamind +bennypowers + +### Proposed `MAINTAINERS.md` + +AndrewJakubowicz +augustjk +bicknellr +dfreedm +e111077 +graynorton +justinfagnani +kevinpschaaf +rictic +usergenic +sorvell + +END END +END END +END END +END END +END END +END END +END END +END END +END END ## Implementation Considerations From 5649defdac85844acda365a594266b6fce63bc95 Mon Sep 17 00:00:00 2001 From: Matt Small Date: Mon, 11 Dec 2023 16:22:28 -0800 Subject: [PATCH 3/8] update remaining sections, fix heading nesting level (hopefully) --- rfcs/0005-rfc-governance.md | 73 ++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 42 deletions(-) diff --git a/rfcs/0005-rfc-governance.md b/rfcs/0005-rfc-governance.md index 74bb66f..e110b3f 100644 --- a/rfcs/0005-rfc-governance.md +++ b/rfcs/0005-rfc-governance.md @@ -6,7 +6,7 @@ PR: {{ update_with_pr_number }} # Governance -Update & clarify Lit's governance mode +Update & clarify Lit's governance model ## Objective @@ -21,20 +21,17 @@ role in deciding the future of Lit. While Google owns and operates the Lit project repo, project roles are open to all contributors. ### Goals -- Specific goals of the RFC -TODO +To codify and document Lit's governance model ### Non-Goals -- Specific non-goals of the RFC -TODO +Anything beyond that scope -## Motivation -Why is the RFC necessary? What background information is needed to understand why? +## Motivation -TODO +See [#Objective](Objective). ## Detailed Design @@ -45,7 +42,7 @@ the PR). ### GOVERNANCE.md -### Mission, Vision, Values +#### Mission, Vision, Values We seek to build a better, lower-friction web platform by promoting interoperable standards for existing and emergent developer needs. Whereas most @@ -71,25 +68,25 @@ to the people, not their employer. This includes members of the Lit team at Google; not all members of the team will be project Members or Maintainers, and they will go through the process outlined here to achieve additional roles. -### How We Work +#### How We Work Lit strives to operate in the open, with full transparency to all members of our community. -#### Issues and Tasks +##### Issues and Tasks These are tracked in Github and visible to all. We hold weekly engineering (see our [calendar](https://lit.dev/community-calendar/) meetings where Members and Maintainers review progress and discuss open topics. -#### Features / Substantial Changes +##### Features / Substantial Changes Lit uses a Request for Comment process (RFC) to evaluate substantial changes to the project, including governance. Any community member may open an RFC, and we welcome input from all. Approval of them is limited to Maintainers; an RFC is approved when more than half of all Maintainers vote to approve the RFC. -#### Releases +##### Releases The project uses a monorepo that is generally in a state such that it can be released at any time. Releases are typically done at ad-hoc intervals based on @@ -98,7 +95,7 @@ are rare and are done with large community awareness and outreach. The release process is driven by the Maintainers of Lit. -#### Communication +##### Communication Github is our “source of truth” for project discussions and decisions. At times when a quick answer is needed, we have a Discord available for chat. We @@ -107,7 +104,7 @@ issue or RFC for the question you raise. This is so that all in the community are able to be involved in the discussion, and decisions are not made in silos, and so we have durable records of the discussions and decisions reached. -### Contributors +#### Contributors In order to facilitate contributions at different levels, we have set up different project roles at various levels of involvement. Community members @@ -125,7 +122,7 @@ We do not expect this to be a static list of roles - as Lit continues to evolve, so will our project needs. We will leverage our RFC process to document these changes. -#### User +##### User Our users are the most important role of Lit - without users, Lit is not useful. Anyone can be a user and there are no special requirements. @@ -145,7 +142,7 @@ We ask that all of our users follow our [Code of Conduct](https://github.com/lit/lit/blob/main/CODE_OF_CONDUCT.md) when interacting with the project. -#### Contributor +##### Contributor A Contributor contributes directly to the project in some way. These contributions don’t have to be code, but they can be - commenting on PRs, @@ -157,7 +154,7 @@ this is not the exhaustive list of project contributors. When making a contribution, please follow our [Contribution Guide](https://github.com/lit/lit/blob/main/CONTRIBUTING.md). -#### Member +##### Member A Member of the Lit project is a Contributor with recognized, consistent contributions to the project. They are actively pushing to the project, and @@ -177,7 +174,7 @@ creating a PR to amend `MEMBERS.md`); a majority of all Members is required to approve that PR. -#### Maintainer +##### Maintainer Maintainers are very established contributors who are responsible for the entire project. @@ -194,7 +191,7 @@ an individual is ready to join the Maintainers list, they should nominate them (by creating a PR to amend `MAINTAINERS.md`). A majority of all Maintainers are required to approve the PR adding the new Maintainer. -#### Stepping Down / Removal +##### Stepping Down / Removal If and when a Member or Maintainer’s commitment levels change, they can consider stepping down (moving down the contributor ladder) or moving to @@ -203,7 +200,7 @@ emeritus status (completely stepping away from the project). Contact the Maintainers about changing to Emeritus status, or reducing your contributor level. -#### Involuntary Removal or Demotion +##### Involuntary Removal or Demotion Involuntary removal/demotion of a contributor happens when responsibilities and requirements aren't being met. This may include repeated patterns of @@ -236,52 +233,44 @@ rictic usergenic sorvell -END END -END END -END END -END END -END END -END END -END END -END END -END END - ## 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? +The core of this change will be a single PR to the main Lit repository. + +Other aspects will involve gradual changes in our processes - as more community +members join our Maintainers, the project will evolve to accomodate them. ### Backward Compatibility -Backwards compatibility is extremely important to Lit, especially in the core libraries. Does this proposal break backwards compatibility? Are there workarounds? +There are no backwards compatibility concerns. ### Testing Plan -How will this proposal be tested? Are unit tests sufficient, or do we need integration tests? Is any unique testing infrastructure required? +This proposal will be tested live. ### 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? +None. ### 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)? +N/A ### 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. +N/A ### 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? +No documentation needs to be added ## Downsides -Many proposals involve trade-offs. What are they for this proposal and what are the downsides of this approach? +We don't believe there are any downsides to this plan. ## Alternatives -What alternatives were considered and rejected? Why? +The obvious alternative would be to leave governance as it is today. However, we believe +that this change is positive - see [#Objective](Objective) for the motivation. From d92d3d8eb264a8c20ddb2a43ca4e83bb38146ac6 Mon Sep 17 00:00:00 2001 From: Matt Small Date: Fri, 15 Dec 2023 12:54:27 -0800 Subject: [PATCH 4/8] small updates - language around voting, etc --- rfcs/0005-rfc-governance.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/rfcs/0005-rfc-governance.md b/rfcs/0005-rfc-governance.md index e110b3f..3632005 100644 --- a/rfcs/0005-rfc-governance.md +++ b/rfcs/0005-rfc-governance.md @@ -170,7 +170,7 @@ We ask that our Members continue to support and mentor our Contributors, to help them grow into Members as well. This includes prioritizing reviews, and providing good feedback on those reviews. When a Member believes that an individual is ready to join the Members list, they should nominate them (by -creating a PR to amend `MEMBERS.md`); a majority of all Members is required to +creating a PR to amend `MEMBERS.md`); a majority Maintainers are required to approve that PR. @@ -218,19 +218,19 @@ current Maintainers. bencbradshaw benjamind bennypowers +bicknellr +usergenic ### Proposed `MAINTAINERS.md` AndrewJakubowicz augustjk -bicknellr dfreedm e111077 graynorton justinfagnani kevinpschaaf rictic -usergenic sorvell ## Implementation Considerations @@ -240,7 +240,8 @@ sorvell The core of this change will be a single PR to the main Lit repository. Other aspects will involve gradual changes in our processes - as more community -members join our Maintainers, the project will evolve to accomodate them. +members join our Maintainers, and as we gather feedback from these new +Maintainers, the project will grow and evolve to accomodate them. ### Backward Compatibility From 909a9894970c97e060ec79abed801f041b8bb568 Mon Sep 17 00:00:00 2001 From: Matt Small Date: Fri, 15 Dec 2023 14:53:12 -0800 Subject: [PATCH 5/8] editing pass --- rfcs/0005-rfc-governance.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/rfcs/0005-rfc-governance.md b/rfcs/0005-rfc-governance.md index 3632005..731e684 100644 --- a/rfcs/0005-rfc-governance.md +++ b/rfcs/0005-rfc-governance.md @@ -22,12 +22,11 @@ project repo, project roles are open to all contributors. ### Goals -To codify and document Lit's governance model +To codify and document Lit's governance model. ### Non-Goals -Anything beyond that scope - +Anything outside of that scope. ## Motivation @@ -35,12 +34,13 @@ See [#Objective](Objective). ## Detailed Design -If this RFC is accepted, we will propose a PR for further iteration, using the +If this RFC is accepted, we will propose a PR in the main +[https://github.com/lit/lit](Lit repo) for further iteration, using the language here as a starting point. This RFC also includes initial lists of -Members and Maintainers (which will become `MEMBERS.md` and `MAINTAINERS.md` in -the PR). +Members and Maintainers which will become `MEMBERS.md` and `MAINTAINERS.md` in +the PR. -### GOVERNANCE.md +### GOVERNANCE.md Contents #### Mission, Vision, Values @@ -76,7 +76,7 @@ our community. ##### Issues and Tasks These are tracked in Github and visible to all. We hold weekly engineering (see -our [calendar](https://lit.dev/community-calendar/) meetings where Members and +our [calendar](https://lit.dev/community-calendar/)) meetings where Members and Maintainers review progress and discuss open topics. ##### Features / Substantial Changes @@ -240,8 +240,8 @@ sorvell The core of this change will be a single PR to the main Lit repository. Other aspects will involve gradual changes in our processes - as more community -members join our Maintainers, and as we gather feedback from these new -Maintainers, the project will grow and evolve to accomodate them. +members join our Maintainers, and as we gather feedback from these new Members +and Maintainers, the project will grow and evolve to accomodate them. ### Backward Compatibility @@ -265,7 +265,7 @@ N/A ### Documentation Plan -No documentation needs to be added +No documentation needs to be added. ## Downsides From a3aae4dd9af1b3bee915f357b1953bfbcadb1f6f Mon Sep 17 00:00:00 2001 From: Matt Small Date: Fri, 15 Dec 2023 14:53:42 -0800 Subject: [PATCH 6/8] rename to drop RFC number --- rfcs/{0005-rfc-governance.md => NNNN-governance.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfcs/{0005-rfc-governance.md => NNNN-governance.md} (100%) diff --git a/rfcs/0005-rfc-governance.md b/rfcs/NNNN-governance.md similarity index 100% rename from rfcs/0005-rfc-governance.md rename to rfcs/NNNN-governance.md From 392450f822e72b891df6b11cc09b3a9826c17d00 Mon Sep 17 00:00:00 2001 From: Matt Small Date: Mon, 18 Dec 2023 16:18:19 -0800 Subject: [PATCH 7/8] add Al --- rfcs/NNNN-governance.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/NNNN-governance.md b/rfcs/NNNN-governance.md index 731e684..380bb72 100644 --- a/rfcs/NNNN-governance.md +++ b/rfcs/NNNN-governance.md @@ -115,11 +115,11 @@ recognizing when their contributions warrant a new role in the project. We value transparency and openness in the Lit project, and as a result on the rare occasion that exceptions must be made to this incremental progression -(e.g., a new maintainer is urgently needed or a new sub-project is accepted) we +(e.g., a new Maintainer is urgently needed or a new sub-project is accepted) we will still follow the open process for joining at the required level. We do not expect this to be a static list of roles - as Lit continues to -evolve, so will our project needs. We will leverage our RFC process to document +evolve, so will our project needs. We will leverage our RFC process to propose these changes. ##### User @@ -173,7 +173,6 @@ individual is ready to join the Members list, they should nominate them (by creating a PR to amend `MEMBERS.md`); a majority Maintainers are required to approve that PR. - ##### Maintainer Maintainers are very established contributors who are responsible for the @@ -223,6 +222,7 @@ usergenic ### Proposed `MAINTAINERS.md` +aomarks AndrewJakubowicz augustjk dfreedm From ab5b16b40c41f7605eca284af5d31e53ba41df8d Mon Sep 17 00:00:00 2001 From: Matt Small Date: Fri, 5 Apr 2024 10:33:33 -0700 Subject: [PATCH 8/8] Add a Technical Steering Committee --- rfcs/NNNN-governance.md | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/rfcs/NNNN-governance.md b/rfcs/NNNN-governance.md index 380bb72..9d995a1 100644 --- a/rfcs/NNNN-governance.md +++ b/rfcs/NNNN-governance.md @@ -211,6 +211,22 @@ while also opens up opportunities for new contributors to step in. Involuntary removal or demotion is handled through a vote by a majority of the current Maintainers. +# Technical Steering Committee +To gather needs, prioritization, and insight from our key partners and +large-scale users, Lit will form a Technical Steering Committee (TSC). This +will be a parallel organization to our User, Contributor, Member, Maintainer +ladder specified [above](#Contributor). + +Members of the TSC will join quarterly sessions with the Maintainers where +we’ll review what the team has accomplished, discuss new initiatives, and +overall project strategy. The Maintainers (or other project Members) may also +ask for advice from one or more of the TSC members, or as a second opinion if +there are technical or strategic decisions that must be made. + +As the day-to-day responsibilities rest with the Maintainers, approving new +members of the TSC is done by a majority of Maintainers, as are involuntary +removal or demotion (if needed). + ### Proposed `MEMBERS.md` 43081j @@ -273,5 +289,6 @@ We don't believe there are any downsides to this plan. ## Alternatives -The obvious alternative would be to leave governance as it is today. However, we believe -that this change is positive - see [#Objective](Objective) for the motivation. +The obvious alternative would be to leave governance as it is today. However, +we believe that this change is positive - see [#Objective](Objective) for the +motivation.