|
2 | 2 |
|
3 | 3 | The Node.js Web Team (@nodejs/web) is a team in the Node.js Project that is composed by a set of subteams. Each containing specific responsibilities and goals. |
4 | 4 |
|
5 | | -### TSC Oversight |
| 5 | +## Relationship with the TSC |
6 | 6 |
|
7 | | -Any website change that expresses a position about a global event or group of people requires explicit |
8 | | -[TSC](https://github.com/nodejs/TSC/blob/main/TSC-Charter.md#section-4-responsibilities-of-the-tsc) |
9 | | -approval. This can be obtained by pinging `@nodejs/tsc` and receive no objections after seven days, |
10 | | -or by sending an email to `tsc@iojs.org` and receive at least one approval and no objections after seven days. |
| 7 | +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. |
| 8 | + |
| 9 | +### Decision Authority Hierarchy |
| 10 | + |
| 11 | +1. **Website Team Authority** |
| 12 | + |
| 13 | + - Technical implementation details |
| 14 | + - User interface and experience design |
| 15 | + - Content organization and information architecture |
| 16 | + - Day-to-day maintenance and updates |
| 17 | + |
| 18 | +2. **TSC Authority** |
| 19 | + - Project-wide policies and governance |
| 20 | + - Strategic partnerships and representation |
| 21 | + - Major structural or navigational changes |
| 22 | + - Content that affects Node.js project positioning |
| 23 | + |
| 24 | +### Content Requiring TSC Approval |
| 25 | + |
| 26 | +- **Statements on Sociopolitical Issues**: Any content expressing positions on political, social, cultural, or humanitarian matters |
| 27 | +- **Commercial Relationships and Endorsements**: Any content establishing or promoting commercial partnerships, vendor preferences, or paid services related to Node.js |
| 28 | + |
| 29 | +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: |
| 30 | + |
| 31 | +- Pinging `@nodejs/tsc` OR |
| 32 | +- Sending an email to `tsc@iojs.org` |
| 33 | + |
| 34 | +### Handling TSC Feedback and Concerns |
| 35 | + |
| 36 | +When TSC members express concerns about proposed changes: |
| 37 | + |
| 38 | +1. **Documentation Requirement**: Document all TSC feedback in the relevant issue or PR |
| 39 | +2. **Hold Period**: Pause implementation until concerns are addressed |
| 40 | +3. **Resolution Process**: |
| 41 | + - Seek clarification on specific concerns |
| 42 | + - Propose compromise solutions |
| 43 | + - Document resolution attempts and outcomes |
| 44 | + |
| 45 | +### Dispute Resolution Process |
| 46 | + |
| 47 | +If disagreements arise between the Website Team and TSC regarding website changes: |
| 48 | + |
| 49 | +1. **Escalation Path**: |
| 50 | + |
| 51 | + - First attempt: Direct discussion on the PR/issue |
| 52 | + - Second attempt: Scheduled discussion in TSC meeting |
| 53 | + - Final resolution: Formal TSC vote if needed |
| 54 | + |
| 55 | +2. **Implementation Requirements**: |
| 56 | + |
| 57 | + - Changes with unresolved TSC objections must not proceed without formal TSC approval |
| 58 | + - When in doubt about approval status, seek explicit confirmation |
| 59 | + - Document the resolution and approval in the PR before merging |
| 60 | + |
| 61 | +3. **Documentation Standard**: |
| 62 | + - All significant disagreements and their resolutions must be documented |
| 63 | + - TSC approvals should be explicit and documented in writing |
| 64 | + - Approval pathways should be clear to all current and future contributors |
11 | 65 |
|
12 | 66 | ### Node.js Website Team (`@nodejs/nodejs-website`) |
13 | 67 |
|
|
0 commit comments