nodejs · avivkeller · Jun 22, 2025
diff --git a/CHARTER.md b/CHARTER.md
@@ -0,0 +1,73 @@
+# Node.js Web Team Charter
+
+## Section 1. Guiding Principle
+
+The Node.js Web Team is part of the Node.js project under the OpenJS Foundation. The Web Team operates transparently, openly, collaboratively, and ethically. The team's work, proposals, timelines, and status must not merely be open, but also easily visible to the broader Node.js community and the public.
+
+## Section 2. Relation to Node.js Governance
+
+The Node.js Web Team operates under the oversight of the Node.js Technical Steering Committee (TSC). While the Web Team has autonomy in making decisions related to the Node.js web properties and documentation, it functions within the broader governance structure of the Node.js project and the OpenJS Foundation.
+
+TSC approval, where required in this charter, consists of at least one TSC member's explicit approval with no objections from any TSC members. This endorsement may be secured through either:
+- Pinging `@nodejs/tsc` in a GitHub issue or pull request
+- Sending an email to `tsc@iojs.org`
+
+This charter can only be amended with the approval of the TSC.
+
+## Section 3. Establishment of the Web Team
+
+All Web Team members are equal and have equal voting rights. Web Team memberships are not time-limited. There is no maximum size of the Web Team. The Web Team must have at least three members.
+
+There is no specific set of requirements or qualifications for Web Team membership beyond these rules. 
+
+The Web Team is organized into subteams with specific focus areas. While all Web Team members are equal in terms of voting rights for overall Web Team matters, each subteam may maintain its own collaborator guide that includes specific nomination guidelines, rules, and operational procedures. The subteam-specific guides supplement but do not override this charter.
+
+## Section 4. Responsibilities of the Web Team
+
+Subject to such policies as may be set by the TSC, the Web Team is responsible for all aspects of the Node.js project's web presence, including:
+
+* The Node.js website (nodejs.org)
+* Web infrastructure and hosting
+* Website design and user experience
+
+## Section 5. Web Team Operations
+
+Each subteam within the Web Team may maintain its own collaborator guide that details specific operational procedures, nomination processes, and other guidelines relevant to that subteam's focus area. These subteam-specific guides must align with the principles laid out in this charter.
+
+The Web Team and the entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy.
+
+## Section 6. Voting
+
+For internal project decisions, Collaborators shall operate under Lazy Consensus. Lazy Consensus is defined as follows:
+
+1. A proposal is made and shared in the appropriate communication channel
+2. If no objection is raised within 72 hours, the proposal is considered accepted
+3. If an objection is raised, the proposal must be discussed and voted on
+
+The Web Team follows a [Consensus Seeking][] decision making model. When an agenda item has appeared to reach a consensus, the moderator will ask "Does anyone object?" as a final call for dissent from the consensus. Consensus is defined as general agreement among Web Team members with no sustained objections.
+
+For all votes, the winning candidate option is the one that wins a simple majority of all Web Team members in every head-to-head election against each of the other candidates. A Web Team member may choose to participate in any vote through abstention. As long as a vote is open, Web Team members' choices must not be disclosed, to avoid influencing other voting members. All votes must remain open for at least 48 hours to allow all members to participate regardless of time zone.
+
+All changes to this charter must be approved by the TSC as defined in Section 2.
+
+## Section 7. Project Roles
+
+The Node.js web repositories are maintained by the Web Team and additional Collaborators who are added by the Web Team on an ongoing basis.
+
+Individuals making significant and valuable contributions are made Collaborators and given commit access to the project. These individuals are identified by the Web Team and their addition as Collaborators is discussed during a Web Team meeting. Modifications of the contents of the web repositories are made on a collaborative basis as defined in the development process.
+
+Collaborators may opt to elevate significant or controversial modifications, or modifications that have not found consensus to the Web Team for discussion by assigning the `website-agenda` tag to a pull request or issue. When consensus cannot be reached, the Web Team should serve as the final arbiter by casting a vote. The Web Team will maintain and publish [a list of current Collaborators](./MEMBERS.md), as well as a [development process guide for Collaborators and Contributors](https://github.com/nodejs/nodejs.org/blob/main/CONTRIBUTING.md) looking to participate in the development effort.
+
+## Section 8. Definitions
+
+* **Contributors**: contribute code, design, content, or other artifacts, but do not have the right to commit to the code base. Contributors work with the project's Collaborators to have contributions committed to the code base. A Contributor may be promoted to a Collaborator by the Web Team.
+
+* **Collaborators**: individuals who have been given commit access to one or more Web Team repositories. Collaborators are expected to follow the development process guidelines established by the Web Team.
+
+* **Web Projects**: technical collaboration efforts related to Node.js web properties, e.g., a subsystem, documentation section, or feature, that is organized through the project creation process and approved by the Web Team.
+
+* **Standard Web Team Motion**: a formal proposal made by a Web Team member that requires explicit voting by Web Team members and a two-thirds majority to pass.
+
+* **Subteams**: specialized groups within the Web Team focused on specific aspects of Node.js web properties. Each subteam maintains its own collaborator guide for specific processes while adhering to the overall Web Team charter.
+
+[Consensus Seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
@@ -84,11 +84,66 @@ The current list of all Web Team members across all subteams is maintained in [M
 
 ## Governance
 
-### TSC Oversight
+### Relationship with the TSC
 
-Any website change that expresses a position about a global event or group of people requires explicit [TSC](https://github.com/nodejs/TSC/blob/main/TSC-Charter.md#section-4-responsibilities-of-the-tsc) approval through one of these methods:
-- Pinging `@nodejs/tsc` and receiving no objections after seven days
-- Emailing `tsc@iojs.org` and receiving at least one approval with no objections after seven days
+The Website Team operates with significant autonomy for most website decisions, but must recognize the TSC's ultimate authority on matters affecting Node.js project representation, branding, and strategic partnerships.
+
+#### Decision Authority Hierarchy
+
+1. **Website Team Authority**
+
+   - Technical implementation details
+   - User interface and experience design
+   - Content organization and information architecture
+   - Day-to-day maintenance and updates
+
+2. **TSC Authority**
+   - Project-wide policies and governance
+   - Strategic partnerships and representation
+   - Major structural or navigational changes
+   - Content that affects Node.js project positioning
+
+#### Content Requiring TSC Approval
+
+- **Statements on Sociopolitical Issues**: Any content expressing positions on political, social, cultural, or humanitarian matters
+- **Commercial Relationships and Endorsements**: Any content establishing or promoting commercial partnerships, vendor preferences, or paid services related to Node.js
+
+Website changes falling under these categories require **formal TSC endorsement** as outlined in the [TSC Charter](https://github.com/nodejs/TSC/blob/main/TSC-Charter.md#section-4-responsibilities-of-the-tsc). Valid approval consists of at least one TSC member's explicit approval with no objections from any TSC members. This endorsement may be secured through either:
+
+- Pinging `@nodejs/tsc` OR
+- Sending an email to `tsc@iojs.org`
+
+#### Handling TSC Feedback and Concerns
+
+When TSC members express concerns about proposed changes:
+
+1. **Documentation Requirement**: Document all TSC feedback in the relevant issue or PR
+2. **Hold Period**: Pause implementation until concerns are addressed
+3. **Resolution Process**:
+   - Seek clarification on specific concerns
+   - Propose compromise solutions
+   - Document resolution attempts and outcomes
+
+#### Dispute Resolution Process
+
+If disagreements arise between the Website Team and TSC regarding website changes:
+
+1. **Escalation Path**:
+
+   - First attempt: Direct discussion on the PR/issue
+   - Second attempt: Scheduled discussion in TSC meeting
+   - Final resolution: Formal TSC vote if needed
+
+2. **Implementation Requirements**:
+
+   - Changes with unresolved TSC objections must not proceed without formal TSC approval
+   - When in doubt about approval status, seek explicit confirmation
+   - Document the resolution and approval in the PR before merging
+
+3. **Documentation Standard**:
+   - All significant disagreements and their resolutions must be documented
+   - TSC approvals should be explicit and documented in writing
+   - Approval pathways should be clear to all current and future contributors
 
 ### Team Meetings