Skip to content

Commit

Permalink
Update links and markdown
Browse files Browse the repository at this point in the history
  • Loading branch information
vivienlacourba committed Jan 9, 2025
1 parent bb63702 commit 493a609
Show file tree
Hide file tree
Showing 3 changed files with 59 additions and 51 deletions.
38 changes: 20 additions & 18 deletions process/tilt/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,33 +4,35 @@ toc: yes
---
The mission of the TiLT is to make technical team decisions described in the W3C Process.

TiLT authority comes from [delegation by the CEO](https://www.w3.org/Consortium/Process/#Team).
TiLT authority comes from [delegation by the CEO](https://www.w3.org/policies/process/#Team).

## Scope {#scope}

The Technical issues Lead Team is meant to handle all verifications requests for:

1. Group charters approvals, before and after AC review
2. Chairs appointments
3. Group extensions
4. Member submissions
5. Workshops([1](#note1))
6. Patent Advisory Groups (PAGs)
7. Start of Councils
8. Transition requests([2](#note2))
9. Anything related to the operational management of developing W3C specs

(1) Those requests still need W3C Management approval in parallel.
- Group charters approvals, before and after AC review
- Chairs appointments
- Group extensions
- Member submissions
- Workshops ([1](#note1))
- Patent Advisory Groups (PAGs)
- Start of Councils
- Transition requests ([2](#note2))
- Anything related to the operational management of developing W3C specs

*(1) Those requests still need W3C Management approval in parallel.*
{:#note1}

(2) TiLT delegates its authority for transition requests
*(2) TiLT delegates its authority for transition requests.*
{:#note2}

### Out of Scope {#out}

1. The TiLT is “internal to the Team”; it does not have Membership- or community-facing activities. Generally speaking, project management and strategy roles carry out these Membership-and community-facing activities. However, asking approval from TiLT is a signal that can be exposed to the outside.
2. TiLT does not replace the Strategy Function (e.g., what Workshops W3C should organize). Note, however, that the TiLT does play a role for related decisions (e.g., Workshop approval).
3. TiLT does not replace Board of Directors nor W3C Management functions. For example, the TiLT does not establish a budget, but through its decisions (e.g., Workshop approval), there are likely to be budgetary impacts (e.g., Workshop costs, human resources for Team Contacts, etc.). Thus, TiLT may be asked to provide input to budget discussions.
The TiLT is “internal to the Team”; it does not have Membership- or community-facing activities. Generally speaking, project management and strategy roles carry out these Membership-and community-facing activities. However, asking approval from TiLT is a signal that can be exposed to the outside.

TiLT does not replace the Strategy Function (e.g., what Workshops W3C should organize). Note, however, that the TiLT does play a role for related decisions (e.g., Workshop approval).

TiLT does not replace Board of Directors nor W3C Management functions. For example, the TiLT does not establish a budget, but through its decisions (e.g., Workshop approval), there are likely to be budgetary impacts (e.g., Workshop costs, human resources for Team Contacts, etc.). Thus, TiLT may be asked to provide input to budget discussions.

## Composition {#composition}

Expand Down Expand Up @@ -63,13 +65,13 @@ This composition is reflected in the Github team [@w3c/tilt](https://github.com/

## Meetings {#meetings}

The W3C Technical Lead Team (TiLT) decides whether to meet synchronously. Currently, TiLT meets every Monday, at 9am Boston time (IRC: &tilt).
The W3C Technical Lead Team (TiLT) decides whether to meet synchronously. Currently, TiLT meets every Monday, at 9am Boston time (IRC: &tilt).

The entire W3C team has an open invitation to observe the discussion, including attending calls. (contact plh for that)

## Requesting approval from TiLT {#request}

For transition requests, TiLT delegates its authority to [@w3c/transitions](https://github.com/orgs/w3c/teams/transitions). Follow [Organize a Technical Report Transition](https://www.w3.org/Guide/transitions).
For transition requests, TiLT delegates its authority to [@w3c/transitions](https://github.com/orgs/w3c/teams/transitions). Follow [Organize a Technical Report Transition](../../transitions/).

Other requests for approvals MUST be sent as an [open issue](https://github.com/w3c/tilt-private/issues/new/choose) to tilt-private. There are templates for each type of decision request. Each request receives the label “agenda” and remains open until a decision has been reached.

Expand Down
62 changes: 34 additions & 28 deletions process/tilt/normative-references.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ toc: true

Normative references between specifications are typically references to established standards previously published by recognized groups or to work in parallel in W3C. As a W3C specification progresses toward Recommendation such normative references rarely raise concern provided the referenced specification is stable and has licensing terms that are consistent with royalty-free implementation of W3C Recommendations, or the parallel W3C work is proceeding on a similar schedule. Borderline cases arise when a specification contains a normative reference to another specification that is not yet an established standard or that has licensing restrictions that may interfere with the intended use of a W3C Recommendation.

This document explains considerations the Team take into account when evaluating normative references from W3C documents at transitions on the [W3C Recommendation track](https://www.w3.org/Consortium/Process/#Reports). These considerations may be used by the Working Group while evaluating the risk associated with specific design choices during the group’s deliberations. The Team may refer to this document when a transition request is being decided.
This document explains considerations the Team take into account when evaluating normative references from W3C documents at transitions on the [W3C Recommendation track](https://www.w3.org/policies/process/#Reports). These considerations may be used by the Working Group while evaluating the risk associated with specific design choices during the group’s deliberations. The Team may refer to this document when a transition request is being decided.

At a high level, when a W3C specification has normative references to other documents the Team considers 3 factors: stability, schedule and licensing. Any of the factors described in this document are fodder for Team consideration. No single factor is decisive. Different cases will involve different combinations of these factors. The Team may consider other factors not listed in this document as well; e.g. the likelihood that W3C may wish to submit the Recommendation to ISO and the PAS criteria for normative references.

Expand All @@ -22,22 +22,24 @@ There are several factors that the Team needs to consider as part of a stability
Who produced the document?

1. Is it produced by a group that the Team believes follows the [OpenStand principles](http://open-stand.org/principles/)?
2. Is the normative version of the referenced document available in English? If not, is there an English translation?
3. Is the referenced document available on the Web at no cost and without limitation?
1. Is the normative version of the referenced document available in English? If not, is there an English translation?
1. Is the referenced document available on the Web at no cost and without limitation?

### 2.2 Stability of the referenced document {#whole}

What is the stability of the referenced document as a whole?

1. What stability claims do the organization and group who published the referenced document make about that document?

**For example**, *in the case of a reference to a W3C document, is that document not yet a Proposed Recommendation?*
**For example**, *in the case of a reference to a W3C document, is that document not yet a Proposed Recommendation?*

**For example**, *does the document have an explicit and clear stability statement readily apparent to its readers and near to the start of the document?*
2. Is the referenced document subject to change, how often, and to what degree? Are there specific dated and/or versioned references?
**For example**, *does the document have an explicit and clear stability statement readily apparent to its readers and near to the start of the document?*

1. Is the referenced document subject to change, how often, and to what degree? Are there specific dated and/or versioned references?

**For example**, *in the case of a document that has both stable and unstable sections, is each section clearly labeled as "stable" vs. "in progress" vs "proposal"*.
3. What is the change control policy for the referenced document?

1. What is the change control policy for the referenced document?

### 2.3 Stability of the referenced part(s) {#parts}

Expand All @@ -46,55 +48,59 @@ What is the stability of the referenced part(s)?
1. How specific is the reference? Finer grained precise references are easier to evaluate.

**For example**, *in the case of a document that has clearly identified stable and unstable sections, do the stable sections have fragment identifiers such that a normative reference could choose to refer only to those stable sections?*
2. Was the referenced part previously published in a W3C Recommendation or other standard?

1. Was the referenced part previously published in a W3C Recommendation or other standard?

**For example**, *the name of the `Document` interface in DOM4 is also in the DOM Level 3 Core Recommendation.
3. Have the organization and group who published the referenced document reviewed and approved the way the referenced part is used and referenced?*

1. Have the organization and group who published the referenced document reviewed and approved the way the referenced part is used and referenced?*

### 2.4 Nature of the dependency {#nature}

What is the nature of the dependency on the referenced part(s)?

1. How is the referenced part used?

1. Is the reference to the name of a interface or to a definition without relying on details? (so that any changes would have no impact on the source of the reference)
2. Who is impacted by the referenced part?
Is the reference to the name of an interface or to a definition without relying on details? (so that any changes would have no impact on the source of the reference)

1. Who is impacted by the referenced part?

1. Is the reference to something that is normative to implementors of the specification or normative to users of implementations of the specification?
Is the reference to something that is normative to implementors of the specification or normative to users of implementations of the specification?

**For example**, *if the referenced document changes:*
**For example**, *if the referenced document changes:*

- *Will implementers of the W3C specification need to change an implementation of an algorithm specified in the referenced document? Users may be affected as a result of changes in the implementation. (eg an encryption algorithm)*
- *Will the text of the W3C specification need to be revised to follow a new grammar from a referenced document? Implementers and users may be affected if the grammar is exposed (eg change in lexical representations of XML Schema datatypes).*
- *How will implementors and users be impacted if a term used in a W3C specification is defined in a referenced document and the definition changes? The W3C specification may be independent of the details of the definition; however, implementers and users may be impacted by the change. (eg URL, well-formed XML)*
3. If a change impacts deployed resources, what will be the recovery strategy?
- *Will implementers of the W3C specification need to change an implementation of an algorithm specified in the referenced document? Users may be affected as a result of changes in the implementation. (eg an encryption algorithm)*
- *Will the text of the W3C specification need to be revised to follow a new grammar from a referenced document? Implementers and users may be affected if the grammar is exposed (eg change in lexical representations of XML Schema datatypes).*
- *How will implementors and users be impacted if a term used in a W3C specification is defined in a referenced document and the definition changes? The W3C specification may be independent of the details of the definition; however, implementers and users may be impacted by the change. (eg URL, well-formed XML)*

1. If a change impacts deployed resources, what will be the recovery strategy?

### 2.5 Status of implementations {#impls}

What is the status of the implementation of the referenced part(s)?

1. What is the deployment of the referenced part(s)?
2. Are there tests and test results for the referenced part(s)?
1. Are there tests and test results for the referenced part(s)?

## 3. Schedule {#schedule}

What are the agreed milestones for the W3C specification?

1. What opportunities will be missed if the transition must be postponed due to questions about a normative reference?
2. What would be the costs of delaying the transition?
1. What would be the costs of delaying the transition?

## 4. Licensing {#licensing}

W3C seeks to issue Recommendations that can be implemented on a [Royalty-Free](/policies/patent-policy/#sec-Requirements) basis.
W3C seeks to issue Recommendations that can be implemented on a [Royalty-Free](https://www.w3.org/policies/patent-policy/#sec-Requirements) basis.

What are the licensing terms of the referenced documents?

1. Are the technologies in the referenced parts available under terms that are compatible with the [W3C Royalty-Free licensing requirements](/policies/patent-policy/#sec-Requirements)?
2. What are the risks that the referenced part(s) may be encumbered by patent(s)?
3. What are the policies identifying the rights and obligations of implementors of the referenced document that apply to implementors of the W3C specification?
4. Does the reference conform to the normative referencing policy of the organization who published the referenced document?
5. What normative references are made by the referenced document and are the licensing terms of those technologies compatible with 1‒3 above?
6. In the case of W3C documents, is there an open exclusion opportunity on the referenced document?
1. Are the technologies in the referenced parts available under terms that are compatible with the [W3C Royalty-Free licensing requirements](https://www.w3.org/policies/patent-policy/#sec-Requirements)?
1. What are the risks that the referenced part(s) may be encumbered by patent(s)?
1. What are the policies identifying the rights and obligations of implementors of the referenced document that apply to implementors of the W3C specification?
1. Does the reference conform to the normative referencing policy of the organization who published the referenced document?
1. What normative references are made by the referenced document and are the licensing terms of those technologies compatible with 1‒3 above?
1. In the case of W3C documents, is there an open exclusion opportunity on the referenced document?

**Note:** The experimental [normative references checker](https://labs.w3.org/normative-references/) can be used to identify which references are or should be normative in your document.

Expand All @@ -103,7 +109,7 @@ What are the licensing terms of the referenced documents?
The guidelines in [section 2](#stability) are evaluated for references from W3C specifications to the WHATWG HTML and DOM Living Standards as follows:

- The factors listed in sections 2.1 and 2.2 are deemed to have been met.
- The factors in sections 2.3, 2.4, and 2.5 will be deemed to have been met for specific features when implementation experience has been demonstrated per [W3C Process section 6.2.4](https://www.w3.org/Consortium/Process/#implementation-experience) for each referenced feature.
- The factors in sections 2.3, 2.4, and 2.5 will be deemed to have been met for specific features when implementation experience has been demonstrated per [W3C Process section 6.2.4](https://www.w3.org/policies/process/#implementation-experience) for each referenced feature.

For HTML Recommendations produced jointly by WHATWG and W3C, the DOM Living Standard is normatively referenceable.

Expand All @@ -118,4 +124,4 @@ For DOM Recommendations produced jointly by WHATWG and W3C, the HTML Living Stan
- **2018-02-07**: Added a note about the normative reference checker.
- **2014-09-11**: Update W3C Recommendation track citation to the 2014 version.
- **2015-04-06**: Added a second example in 2.2.1, and an example in 2.2.2 and in 2.3.1.
- **2013-10-18**: Distributed to the W3C Advisory Committee and Chairs for comment on 18 October 2013.
- **2013-10-18**: Distributed to the W3C Advisory Committee and Chairs for comment on 18 October 2013.
Loading

0 comments on commit 493a609

Please sign in to comment.