From a4f362eb4f73ba3c434f08f1fd8e7b53ce4be5e4 Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Wed, 20 Nov 2024 12:51:46 +0400 Subject: [PATCH 001/225] use W3C jekyll template --- Gemfile | 26 +++++++++++ Gemfile.lock | 107 +++++++++++++++++++++++++++++++++++++++++++ _config.yml | 20 ++++++++ _data/navigation.yml | 21 +++++++++ _data/subpath.yml | 3 ++ 5 files changed, 177 insertions(+) create mode 100644 Gemfile create mode 100644 Gemfile.lock create mode 100644 _config.yml create mode 100644 _data/navigation.yml create mode 100644 _data/subpath.yml diff --git a/Gemfile b/Gemfile new file mode 100644 index 000000000..c6bd8f848 --- /dev/null +++ b/Gemfile @@ -0,0 +1,26 @@ +source "https://rubygems.org" +# Hello! This is where you manage which Jekyll version is used to run. +# When you want to use a different version, change it below, save the +# file and run `bundle install`. Run Jekyll with `bundle exec`, like so: +# +# bundle exec jekyll serve +# +# This will help ensure the proper Jekyll version is running. +# Happy Jekylling! +gem "jekyll", "~> 4.1.0" +# If you want to use GitHub Pages, remove the "gem "jekyll"" above and +# uncomment the line below. To upgrade, run `bundle update github-pages`. +#gem "github-pages", group: :jekyll_plugins + +# our markdown files don't have frontmatter +group :jekyll_plugins do + gem 'jekyll-optional-front-matter' + gem "jekyll-readme-index" + gem "jekyll-titles-from-headings" + gem "jekyll-relative-links" + gem 'jekyll-commonmark-ghpages' + gem 'jekyll-remote-theme' + gem 'jekyll-toc' + gem 'webrick' +end + diff --git a/Gemfile.lock b/Gemfile.lock new file mode 100644 index 000000000..ed4b07668 --- /dev/null +++ b/Gemfile.lock @@ -0,0 +1,107 @@ +GEM + remote: https://rubygems.org/ + specs: + addressable (2.8.7) + public_suffix (>= 2.0.2, < 7.0) + colorator (1.1.0) + commonmarker (0.17.13) + ruby-enum (~> 0.5) + concurrent-ruby (1.3.4) + em-websocket (0.5.3) + eventmachine (>= 0.12.9) + http_parser.rb (~> 0) + eventmachine (1.2.7) + ffi (1.17.0-arm64-darwin) + forwardable-extended (2.6.0) + http_parser.rb (0.8.0) + i18n (1.14.6) + concurrent-ruby (~> 1.0) + jekyll (4.1.1) + addressable (~> 2.4) + colorator (~> 1.0) + em-websocket (~> 0.5) + i18n (~> 1.0) + jekyll-sass-converter (~> 2.0) + jekyll-watch (~> 2.0) + kramdown (~> 2.1) + kramdown-parser-gfm (~> 1.0) + liquid (~> 4.0) + mercenary (~> 0.4.0) + pathutil (~> 0.9) + rouge (~> 3.0) + safe_yaml (~> 1.0) + terminal-table (~> 1.8) + jekyll-commonmark (1.3.1) + commonmarker (~> 0.14) + jekyll (>= 3.7, < 5.0) + jekyll-commonmark-ghpages (0.1.6) + commonmarker (~> 0.17.6) + jekyll-commonmark (~> 1.2) + rouge (>= 2.0, < 4.0) + jekyll-optional-front-matter (0.3.2) + jekyll (>= 3.0, < 5.0) + jekyll-readme-index (0.3.0) + jekyll (>= 3.0, < 5.0) + jekyll-relative-links (0.7.0) + jekyll (>= 3.3, < 5.0) + jekyll-remote-theme (0.4.3) + addressable (~> 2.0) + jekyll (>= 3.5, < 5.0) + jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) + rubyzip (>= 1.3.0, < 3.0) + jekyll-sass-converter (2.2.0) + sassc (> 2.0.1, < 3.0) + jekyll-titles-from-headings (0.5.3) + jekyll (>= 3.3, < 5.0) + jekyll-toc (0.19.0) + jekyll (>= 3.9) + nokogiri (~> 1.12) + jekyll-watch (2.2.1) + listen (~> 3.0) + kramdown (2.5.1) + rexml (>= 3.3.9) + kramdown-parser-gfm (1.1.0) + kramdown (~> 2.0) + liquid (4.0.4) + listen (3.9.0) + rb-fsevent (~> 0.10, >= 0.10.3) + rb-inotify (~> 0.9, >= 0.9.10) + mercenary (0.4.0) + nokogiri (1.16.7-arm64-darwin) + racc (~> 1.4) + pathutil (0.16.2) + forwardable-extended (~> 2.6) + public_suffix (6.0.1) + racc (1.8.1) + rb-fsevent (0.11.2) + rb-inotify (0.11.1) + ffi (~> 1.0) + rexml (3.3.9) + rouge (3.30.0) + ruby-enum (0.9.0) + i18n + rubyzip (2.3.2) + safe_yaml (1.0.5) + sassc (2.4.0) + ffi (~> 1.9) + terminal-table (1.8.0) + unicode-display_width (~> 1.1, >= 1.1.1) + unicode-display_width (1.8.0) + webrick (1.9.0) + +PLATFORMS + arm64-darwin-23 + +DEPENDENCIES + jekyll (~> 4.1.0) + jekyll-commonmark-ghpages + jekyll-optional-front-matter + jekyll-readme-index + jekyll-relative-links + jekyll-remote-theme + jekyll-titles-from-headings + jekyll-toc + webrick + +BUNDLED WITH + 2.3.26 diff --git a/_config.yml b/_config.yml new file mode 100644 index 000000000..cc403bf6f --- /dev/null +++ b/_config.yml @@ -0,0 +1,20 @@ +markdown: CommonMarkGhPages +title: W3C Guidebook +baseurl: /guide +remote_theme: w3c/w3c-jekyll-theme +titles_from_headings: + enabled: true + strip_title: true + collections: false +defaults: + - + scope: + path: "" # an empty string here means all files in the project + values: + layout: "default" +optional_front_matter: + remove_originals: true +readme_index: + remove_originals: true +toc: + max_level: 3 diff --git a/_data/navigation.yml b/_data/navigation.yml new file mode 100644 index 000000000..a094d9b6d --- /dev/null +++ b/_data/navigation.yml @@ -0,0 +1,21 @@ +pages: + +- title: W3C Guidebook + url: /guide/ + html: / + +- title: Buddy System + url: /guide/chair/buddy.html + html: /chair/buddy.html + +- title: Document Review + url: /guide/documentreview/ + html: /documentreview/ + +- title: Manual of style + url: /guide/manual-of-style/ + html: /manual-of-style/ + +- title: Meetings + url: /guide/meetings/ + html: /meetings/ diff --git a/_data/subpath.yml b/_data/subpath.yml new file mode 100644 index 000000000..cee5bb20c --- /dev/null +++ b/_data/subpath.yml @@ -0,0 +1,3 @@ +path: + - title: Home + url: / From bb85ecee081b93189ce03b717877ef9881e5a639 Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Wed, 20 Nov 2024 12:51:57 +0400 Subject: [PATCH 002/225] redesign documentreview --- documentreview/createGitHubIssue.js | 5 +- documentreview/index.html | 380 ---------------------------- documentreview/index.md | 278 ++++++++++++++++++++ 3 files changed, 281 insertions(+), 382 deletions(-) delete mode 100644 documentreview/index.html create mode 100644 documentreview/index.md diff --git a/documentreview/createGitHubIssue.js b/documentreview/createGitHubIssue.js index 746189c1d..341509dc4 100644 --- a/documentreview/createGitHubIssue.js +++ b/documentreview/createGitHubIssue.js @@ -7,7 +7,8 @@ function addGitHubIssueButton() { } -function createGitHubIssue() { +function createGitHubIssue(event) { + event.preventDefault(); const value = document.getElementById('repository').value.trim(); const match = value.match(/github\.com\/(.*?)\/?$/); const repo = match ? match[1] : value; @@ -24,7 +25,7 @@ function createGitHubIssue() { function generateGitHubIssueBody() { - const dl = document.querySelector('#how_to_get_horizontal_review dl'); + const dl = document.querySelector('#how-to-get-horizontal-review ~ dl'); if (!dl) { console.error('Could not find right anchor in "How to get horizontal review" section'); } diff --git a/documentreview/index.html b/documentreview/index.html deleted file mode 100644 index aed2c0b40..000000000 --- a/documentreview/index.html +++ /dev/null @@ -1,380 +0,0 @@ - - - - - - -Document Review - - - - - - -

How to do Wide Review

-

Getting early and wide review of a document is very important, yet in practice it can be challenging. This document provides some best practices for getting document review; it does not define explicit mandatory steps.

-

This page is linked to from The Guide. See also the Wide Review section in the W3C Process document.

-

Feedback on this document is welcome, preferably by raising an issue or a pull request.

-
-

Contents

-
-
- - - -
-

When should wide review be requested?

-

A document is available for review from the moment it is first published. - Working Groups should formally - address any substantive review comment about a technical report in a - timely manner.

-

Wide review should or must be requested:

-
    -
  • After a First - Public Working Draft is published (for most documents). -

    Working Groups are often reluctant to make substantive changes to a mature - document, so reviewers should get a chance to send substantive technical - reviews as early as possible. This is especially important for horizontal reviews.

    -
  • -
  • Before a document gets advanced to Candidate - Recommendation, gets updated as a Candidate - Recommendation Snapshot, or gets updated as a Recommendation. -

    For those, the W3C - Process requires a Group to show that the specification has received wide - review.

    -
  • -
  • When a document is both reasonably stable and still flexible enough to - allow changes where issues are identified.
  • -
  • When new features are added after a document has already received wide - review (perhaps requesting a review limited to the new features).
  • -
-
- -
-

Who to ask for wide review?

- -

The objective is to ensure that the entire set of stakeholders of the Web - community, including the general public, have adequate notice of the progress - of the Working Group and are genuinely able to perform reviews of and provide - comments on the specification. When considering requests to advance the maturity - level of the document, the Team will consider who has been explicitly - offered a reasonable opportunity to review the document.

- -

You must publish an updated technical report, with the Status of the Document -indicating clearly that you're looking for wide review, before inviting -review from other stakeholders. Our tooling -monitors publications and propagates notifications to public-review-announce@w3.org -automatically (for example, Candidate -Recommendation Snapshot: Payment Request API (Call for Wide Review)).

- -

You should then inform, and request reviews from:

- -
    -
  • the groups listed in the WG's charter, especially those who manage -dependencies.
  • -
  • the groups jointly responsible for a particular document (if any).
  • -
  • the horizontal groups -using the method described below. -Note that sending an email to the public-review-announce list alone is not -sufficient to trigger horizontal reviews. You will still need to formally -request review from the Horizontal Groups, as described below
  • -
  • the general public, including Web developers, technology providers and -implementers, application developers, etc. Consider: -
      -
    • sending a dedicated announcement to public-review-announce@w3.org - if needed (in case the default notice sent to that list is not enough).
    • -
    • using blog posts, social media, or other ways of alerting the public to - your document and requesting feedback.
    • -
    -
  • - -
  • other groups, at your discretion, even if not in the WG charter, such as -other W3C groups, external organizations and SSOs working on related areas, -etc.
  • - -
- - - -

The reviews provided by the horizontal -groups, a subset of a full wide review, do receive special attention and -much of the rest of this document focuses on how and when to conduct horizontal -reviews.

- -
- -
-

How to get horizontal review

-

When you have published a First Public Working Draft, you should work through available "self-review" materials and request review of your results in at least the following areas. - Long enough before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review. - During the Last Call for Review of Proposed Amendment, you should also do the same. -

- -

The meaning of "Long enough" depends on how many changes there are, how clearly you have explained them, and how much discussion is needed to resolve issues. Pointing to 14 concise points for a small spec means a short time if they are simple fixes, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a long time to get review, and potentially a long time to also discuss and agree on how to solve the issues. If you have effectively identified issues for review during development and received feedback on them, the review time will probably be shorter. Horizontal review groups sometimes get bogged down; planning in advance is useful.

-
-
Accessibility
-
- Work through this questionnaire then - request a review via GitHub from APA -
-Show useful links - -
- - - -
Architecture
-
- Ask the TAG for review; see how to work with the TAG. - If you are developing javascript APIs you may also want to ask public-script-coord@w3.org, a technical discussion list shared by W3C and ECMA's TC 39. -
-Show useful links - -
-
- - - -
Internationalization
-
- Read the Request a review page, then - work through the Short Checklist, then - request a review via GitHub. -
-Show useful links - -
-
- -
Privacy
-
- Write a "Privacy Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, Mitigating Browser Fingerprinting in Web Specifications, and RFC6973 then - request a review via GitHub from the Privacy Interest Group. -
-Show useful links - -
-
- - - - -
Security
-
- Write a "Security Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, and attacks listed in RFC 3552 then - request a review via GitHub - -
-Show useful links - -
-
-
- -

You should familiarize yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work.

-

Recognize that horizontal review groups may be resource limited and may only be able to do one review or may have difficulty scheduling your review quickly. Give them as much time as you can, consistent with asking for review while it is still reasonable to change the technology to accommodate the issues they find.

-
- -
-

Working with Horizontal Review labels

- -

Applying these labels doesn't replace the need to schedule a review of your spec at an appropriate time. (See How to Get Horizontal Review above.) Horizontal groups participants can find detailed process information here. -

- -
-

Day-to-day use of labels

-

Apply the *-tracker label in your own repository to draw a horizontal review group’s attention to an issue in one of your own repositories. Horizontal review groups may also apply the label if they are interested in tracking a particular issue. Tooling will automatically notify the horizontal group that you attached the label. -

If you want some specific advice from the horizontal group, describe that request in the issue thread. -

Horizontal review groups may apply the *-needs-resolution label to issues they expect to be resolved before the specification moves to a new maturity level. Working Groups must not remove or add this label (not even when you close your issue). -

If the horizontal group believes that an issue with a *-tracker label needs to be resolved before a transition, they may apply a *-needs-resolution label to the issue. Automatic tooling will later remove the *-tracker label.

-

If you close an issue with a *-tracker or *-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.)

-

At the end of a review, and before attempting to transition the spec, you should clarify that a resolution is described for all of the issues with a *-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the *-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.)

-

Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (+) in the issue description, +*-tracker or +*-needs-resolution.

-
- -
-

What happens with *-needs-resolution issues at transition?

- -

When a Working Group requests a new Maturity level, the transition will not be approved if a horizontal group has an open *-needs-resolution issue showing on the tracker boards. Note that the tracker monitors the horizontal group's copy of the issue. Before requesting a new Maturity level, the Working Group is advised to review the tracker and contact the horizontal group to close any lingering issues.

- -
- - -
- -

What happens to unresolved issues marked *-needs-resolution?

- -

As lead technical architect, the W3C Council is tasked (among many things) to assess consensus within W3C for architectural issues and to decide on the outcome of Formal Objections. When a horizontal issue gets flagged as *-needs-resolution and a Group chooses to request a new Maturity level despite the lack of consensus with the horizontal group, it is the task of the W3C Team to assess the issue and the outcome of the request. A horizontal group MAY choose to elevate an horizontal issue as a Formal Objection to elevate further the importance of an issue per the W3C Process. -

In the case where an horizontal issue hasn’t been addressed and the document was allowed to move forward, it is recommended that the issue remains open in the horizontal group repository (it MAY get closed in the specification repository unless the W3C Team requests otherwise). Some issues may take years to get resolved, but that doesn’t mean those should be forgotten.

-
-
- - - - -
-

Issue trackers

-

The horizontal groups maintain repositories containing issues that track those raised in the WG repos. You can see a list of tracked issues on the tracker boards, one per horizontal area. -

Horizontal groups participants can find detailed process information here.

-
- - - - - -
-

FAQ

- -
-
Q: Is security and/or privacy review mandatory before a First Public Working Draft is published?
-
-
    -
  • A: It is strongly encouraged but not required. Resolving security and privacy issues can require significant changes in specs, so it helps to identify them early.
  • -
-
- -
Q: Does a group need to prove its documents have had wide review before proceeding to CR?
-
-
    -
  • A: Yes, since Process-2019.
  • -
-
- -
Q: How does a group prove its documents have had wide review before proceeding to CR?
-
  • A: Requests to the horizontal review groups will appear in Github, as above.
  • -
  • A: Keep a Disposition of Comments (DoC) Document showing comments received and a summary of their resolution.
- -
Q: Is there such a thing as too many reviews?
-
  • A: Not really
- -
Q: Is it possible to make too many requests for review?
-
  • A: Yes. To help the review groups, only request updated reviews when substantive changes have been made, and clearly identify the changes since the last review.
  • -
  • A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a spec…
  • -
  • A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.
-
-
- - -
-

Common mistakes when making a transition request

-
    -
  1. If you make substantive changes, you'll need to do a wide review for those - before you move forward to the next maturity stage.

    -
  2. -
  3. Never ever exclude some horizontal groups from your review requests - because you concluded it was irrelevant for them or they haven't responded to your last request.

    -

    Let them make the decision that something is irrelevant to their field of expertise instead. - You're welcome to time out if you don't hear back, and request to move forward anyway.

    -
  4. -
  5. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews.

    -

    It's better for a Group to miss the fact that you fixed an issue in your editor's draft - than the Team missing the fact you made an unreviewed substantive change in your editor's draft.

    -
  6. -
  7. Don't flag your issues with one of those - *-needs-resolution labels, - and don't remove one which has been applied (you can close the issue though, if it is resolved).

    -

    Those are intended solely to be used by horizontal groups to - bring special attention.

    -
  8. -
  9. -

    Don't assume that the horizontal group will be able to - schedule and complete a review within 2 weeks so that you can proceed to CR.

    -

    They may not even be able to find someone with availability to do the review in that time, - and then they need a week or two to discuss their response after the review, - and then they'll send you comments that may require you to make substantive changes.

    -
  10. -
-
- - -
-

Terminology and abbreviations

-
  • pre-CR - This is a version of a Working Draft that is created to get wide review. -
    • note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. Charles McCathie Nevile 11:18, 13 October 2014 (UTC)
-
  • requesting group - a group that is requesting a review
-

Abbreviations: -

-
  • BP = Best Practices
  • -
  • CR = Candidate Recommendation
  • -
  • RfC = Request for Comments (aka Review Request)
  • -
  • TR = Technical Report, i.e. a formal W3C publication.
  • -
  • WD = Working Draft
-
- - - - -
-

Enhancement Requests

-
  • See the Document Review Dashboard document for information about creating a dashboard type service to facilitate document reviews.
-
- - - - - - - - - - diff --git a/documentreview/index.md b/documentreview/index.md new file mode 100644 index 000000000..b1f03e44b --- /dev/null +++ b/documentreview/index.md @@ -0,0 +1,278 @@ +--- +title: Document Review +toc: true +--- + + + +## How to do Wide Review +Getting early and wide review of a document is very important, yet in practice it can be challenging. This document provides some best practices for getting document review; it does not define explicit mandatory steps. + +This page is linked to from [The Guide](https://www.w3.org/Guide/). See also the [Wide Review](https://www.w3.org/policies/process/#wide-review) section in the W3C Process document. + +Feedback on this document is welcome, preferably by [raising an issue](https://github.com/w3c/documentreview/issues) or a pull request. + +### When should wide review be requested? +A document is available for review from the moment it is first [published](https://www.w3.org/policies/process/#publishing). Working Groups should [formally address](https://www.w3.org/policies/process/#formally-addressed) any substantive review comment about a technical report in a timely manner. + +Wide review should or must be requested: +* After a [First Public Working Draft](https://www.w3.org/policies/process/#first-wd) is published (for most documents). + + Working Groups are often reluctant to make substantive changes to a mature + document, so reviewers should get a chance to send substantive technical + reviews as early as possible. This is especially important for horizontal reviews. +* Before a document gets advanced to [Candidate Recommendation](https://www.w3.org/policies/process/#transition-cr), gets updated as a [Candidate Recommendation Snapshot](https://www.w3.org/policies/process/#update-requests) or gets updated as a [Recommendation](https://www.w3.org/policies/process/20231103/#change-review). + + For those, the [W3C Process](https://www.w3.org/policies/process/) requires a Group to show that the specification has received wide review. +* When a document is both reasonably stable and still flexible enough to allow changes where issues are identified. +* When new features are added after a document has already received wide review (perhaps requesting a review limited to the new features). + +### Who to ask for wide review? + +The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have adequate notice of the progress of the Working Group and are genuinely able to perform reviews of and provide comments on the specification. When considering [requests to advance the maturity level of the document](https://www.w3.org/Guide/transitions), the Team will consider who has been explicitly offered a reasonable opportunity to review the document. + +You must publish an updated technical report, with the Status of the Document indicating clearly that you're looking for wide review, before inviting review from other stakeholders. Our tooling monitors publications and propagates notifications to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) automatically (for example, Candidate Recommendation Snapshot: Payment Request API (Call for Wide Review)). + +You should then inform, and request reviews from: + +* the groups listed in the WG's charter, especially those who manage +dependencies. +* the groups jointly responsible for a particular document (if any). +* the [horizontal groups](/Guide/process/horizontal-groups.html) using the [method described below](#how_to_get_horizontal_review). Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below +* the general public, including Web developers, technology providers and implementers, application developers, etc. Consider: + * sending a dedicated announcement to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) if needed (in case the default notice sent to that list is not enough). + * using blog posts, social media, or other ways of alerting the public to your document and requesting feedback. +* other groups, at your discretion, even if not in the WG charter, such as other W3C groups, external organizations and SSOs working on related areas, etc. + + +Tip: consider tracking your wide review progress using a GitHub issue, such as [issue #299 of the Sensors API](https://github.com/w3c/sensors/issues/299). You can then simply point the Team to the issue. + + + + +The reviews provided by the [horizontal groups](/Guide/process/horizontal-groups.html), a subset of a full wide review, do receive special attention and much of the rest of this document focuses on how and when to conduct horizontal reviews. + +### How to get horizontal review +When you have published a First Public Working Draft, you should work through available "self-review" materials and request review of your results in at least the following areas. + +Long enough before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review. During the [Last Call for Review of Proposed Amendment](https://www.w3.org/policies/process/#change-review), you should also do the same. + +The meaning of "Long enough" depends on how many changes there are, how clearly you have explained them, and how much discussion is needed to resolve issues. Pointing to 14 concise points for a small spec means a short time if they are simple fixes, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a long time to get review, and potentially a long time to also discuss and agree on how to solve the issues. If you have effectively identified issues for review during development and received feedback on them, the review time will probably be shorter. Horizontal review groups sometimes get bogged down; planning in advance is useful. + +
+
Accessibility
+
+ Work through this questionnaire then + request a review via GitHub from APA +
+Show useful links + +
+ + + +
Architecture
+
+ Ask the TAG for review; see how to work with the TAG. + If you are developing javascript APIs you may also want to ask public-script-coord@w3.org, a technical discussion list shared by W3C and ECMA's TC 39. +
+Show useful links + +
+
+ +
Internationalization
+
+ Read the Request a review page, then + work through the Short Checklist, then + request a review via GitHub. +
+Show useful links + +
+
+ +
Privacy
+
+ Write a "Privacy Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, Mitigating Browser Fingerprinting in Web Specifications, and RFC6973 then + request a review via GitHub from the Privacy Interest Group. +
+Show useful links + +
+
+ +
Security
+
+ Write a "Security Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, then + request a review via GitHub + +
+Show useful links + +
+
+
+ +You should familiarize yourself with the rest of this document. This section is just a quick reminder for when you are in the middle of doing the work. + +Recognize that horizontal review groups may be resource limited and may only be able to do one review or may have difficulty scheduling your review quickly. Give them as much time as you can, consistent with asking for review while it is still reasonable to change the technology to accommodate the issues they find. + +### Working with Horizontal Review labels + +Applying these labels doesn't replace the need to schedule a review of your spec at an appropriate time. (See [How to Get Horizontal Review](https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review) above.) Horizontal groups participants can find [detailed process information here](https://w3c.github.io/horizontal-issue-tracker/HOWTO). + +#### Day-to-day use of labels +Apply the *-tracker label in your own repository to draw a horizontal review group’s attention to an issue in one of your own repositories. Horizontal review groups may also apply the label if they are interested in tracking a particular issue. Tooling will automatically notify the horizontal group that you attached the label. + +If you want some specific advice from the horizontal group, describe that request in the issue thread. + +Horizontal review groups may apply the \*-needs-resolution label to issues they expect to be resolved before the specification moves to a new maturity level. Working Groups must not remove or add this label (not even when you close your issue). + +If the [horizontal group](/Guide/process/horizontal-groups.html) believes that an issue with a \*-tracker label needs to be resolved before a transition, they may apply a \*-needs-resolution label to the issue. Automatic tooling will later remove the \*-tracker label. + + If you close an issue with a \*-tracker or \*-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.) + + At the end of a review, and before attempting to transition the spec, you should clarify that a resolution is described for all of the issues with a \*-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the \*-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.) + + Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (+) in the issue description, +\*-tracker or +\*-needs-resolution. + +#### What happens with *-needs-resolution issues at transition? + +When a Working Group requests a new Maturity level, the transition will not be approved if a horizontal group has an open *-needs-resolution issue showing on the [tracker boards](https://www.w3.org/PM/horizontal/). Note that the tracker monitors the horizontal group's copy of the issue. Before requesting a new Maturity level, the Working Group is advised to review the tracker and contact the horizontal group to close any lingering issues. + +#### What happens to unresolved issues marked \*-needs-resolution? + +As lead technical architect, the W3C Council is tasked (among many things) to assess consensus within W3C for architectural issues and to decide on the outcome of [Formal Objections](https://www.w3.org/2019/Process-20190301/#FormalObjection). When a horizontal issue gets flagged as *-needs-resolution and a Group chooses to request a new Maturity level despite the lack of consensus with the horizontal group, it is the task of the W3C Team to assess the issue and the outcome of the request. A horizontal group MAY choose to elevate an horizontal issue as a Formal Objection to elevate further the importance of an issue per the W3C Process. + +In the case where an horizontal issue hasn’t been addressed and the document was allowed to move forward, it is recommended that the issue remains open in the horizontal group repository (it MAY get closed in the specification repository unless the W3C Team requests otherwise). Some issues may take years to get resolved, but that doesn’t mean those should be forgotten.

+ +### Issue trackers +The horizontal groups maintain repositories containing issues that track those raised in the WG repos. You can see a list of tracked issues on the [tracker boards](https://w3c.github.io/horizontal-issue-tracker/index), one per horizontal area. + +Horizontal groups participants can find [detailed process information here](https://w3c.github.io/horizontal-issue-tracker/HOWTO). + +### FAQ + +
+
Q: Is security and/or privacy review mandatory before a First Public Working Draft is published?
+
+
    +
  • A: It is strongly encouraged but not required. Resolving security and privacy issues can require significant changes in specs, so it helps to identify them early.
  • +
+
+ +
Q: Does a group need to prove its documents have had wide review before proceeding to CR?
+
+
    +
  • A: Yes, since Process-2019.
  • +
+
+ +
Q: How does a group prove its documents have had wide review before proceeding to CR?
+
  • A: Requests to the horizontal review groups will appear in Github, as above.
  • +
  • A: Keep a Disposition of Comments (DoC) Document showing comments received and a summary of their resolution.
+ +
Q: Is there such a thing as too many reviews?
+
  • A: Not really
+ +
Q: Is it possible to make too many requests for review?
+
  • A: Yes. To help the review groups, only request updated reviews when substantive changes have been made, and clearly identify the changes since the last review.
  • +
  • A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a spec…
  • +
  • A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.
+
+ +### Common mistakes when making a transition request + +1. If you make substantive changes, you'll need to do a wide review for those before you move forward to the [next maturity stage](https://www.w3.org/Guide/documentreview/#who_to_ask_for_review). +2. Never ever exclude some [horizontal groups](/Guide/process/horizontal-groups.html) from your review requests because you concluded it was irrelevant for them or they haven't responded to your last request. + + Let them make the decision that something is irrelevant to their field of expertise instead. You're welcome to time out if you don't hear back, and request to move forward anyway. +3. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews. + It's better for a Group to miss the fact that you fixed an issue in your editor's draft than the Team missing the fact you made an unreviewed substantive change in your editor's draft. +4. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you can close the issue though, if it is resolved). + + Those are intended solely to be used by [horizontal groups](/Guide/process/horizontal-groups.html) to [bring special attention](https://www.w3.org/Guide/documentreview/#What_happens_to_unresolved_issues_marked_needs-resolution). +5. Don't assume that the horizontal group will be able to schedule and complete a review within 2 weeks so that you can proceed to CR. + + They may not even be able to find someone with availability to do the review in that time, and then they need a week or two to discuss their response after the review, and then they'll send you comments that may require you to make substantive changes. + + +### Terminology and abbreviations +* pre-CR - This is a version of a Working Draft that is created to get wide review. + * note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [Charles McCathie Nevile](https://www.w3.org/wiki/User:Charles" title="User:Charles) 11:18, 13 October 2014 (UTC) +* requesting group - a group that is requesting a review + +Abbreviations: +* BP = Best Practices +* CR = Candidate Recommendation +* RfC = Request for Comments (aka Review Request) +* [TR](https://www.w3.org/TR/) = Technical Report, i.e. a formal W3C publication. +* WD = Working Draft + + +### Enhancement Requests +See the [Document Review Dashboard](https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard) document for information about creating a dashboard type service to facilitate document reviews. + +
See the [commit history](https://github.com/w3c/Guide/tree/main/documentreview).
+ + From 54f79bcf231fdfea23c1303161182127b0a012d2 Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Wed, 20 Nov 2024 13:04:55 +0400 Subject: [PATCH 003/225] add standards-track to the navigation --- _data/navigation.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/_data/navigation.yml b/_data/navigation.yml index a094d9b6d..0eed743e7 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -19,3 +19,7 @@ pages: - title: Meetings url: /guide/meetings/ html: /meetings/ + +- title: Standards track + url: /guide/standards-track/ + html: /standards-track/ From d25da896d4b88f15ac75db313ec41d0f1c0d0b37 Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Wed, 20 Nov 2024 13:05:08 +0400 Subject: [PATCH 004/225] redesign standards-track --- standards-track/index.html | 165 +++++++++++-------------------------- 1 file changed, 49 insertions(+), 116 deletions(-) diff --git a/standards-track/index.html b/standards-track/index.html index 850f08536..ad59bc412 100644 --- a/standards-track/index.html +++ b/standards-track/index.html @@ -1,94 +1,41 @@ - - - - - W3C Recommendation Track Readiness Best Practices - - - - - - - - - - - -
-

Also On This Page →

- -
- -
-

- Status -

-

October 2023: Document updated to account for changes in Process 2023, in particular the Director-free changes.

-

August 2016: This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

-

This document lives in Github, where changes can be tracked and pull requests are welcome. - Feedback and comments are welcome. Please use Github issues.

-

- Problem Statement -

-

The practices proposed in this document are intended to address some specific problems:

-

W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere

- -

- Overview of the Proposed Solution -

-

W3C should more tightly focus its +--- +title: W3C Recommendation Track Readiness Best Practices +toc: true +--- + +

Status

+

October 2023: Document updated to account for changes in Process 2023, in particular the Director-free changes.

+

August 2016: This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

+

This document lives in Github, where changes can be tracked and pull requests are welcome. + Feedback and comments are welcome. Please use Github issues.

+ +

Problem Statement

+

The practices proposed in this document are intended to address some specific problems:

+

W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere

+ +

Overview of the Proposed Solution

+

W3C should more tightly focus its formal standardization effors on specifications that are most likely to get consensus within the consortium and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD.

These are offered as guidelines, not a checklist of required items in every proposal. - Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by WGs and determination of W3C Decisions.

-

The target audience for this document includes:

    -
  • the Team and Advisory Committee, when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations;
  • -
  • working group Chairs, when determining whether to publish First Public Working Drafts of -specs that are in a group's chartered scope,
  • +
  • the Team and Advisory Committee, when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations;
  • +
  • working group Chairs, when determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope,

This document attempts to strike a balance between two classes of criteria:

    -
  • "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web
  • -
  • "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters
  • +
  • "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web
  • +
  • "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters

Discussion at the October 2015 Advisory Committee meeting @@ -98,38 +45,36 @@

Arguments raised in favor of mandatory incubation included:

    -
  • The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world.
  • -
  • Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation
  • -
  • The industry overall is moving toward more data-driven decision making
  • -
  • It's useful to identify what criteria are prerequisites for a Recommendation Track effort, but not to prescribe how those +
  • The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world.
  • +
  • Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation
  • +
  • The industry overall is moving toward more data-driven decision making
  • +
  • It's useful to identify what criteria are prerequisites for a Recommendation Track effort, but not to prescribe how those criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. - -
      -
    • The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities.
    • -
    • The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed get it to Recommendation and deployed on the real Web.
    • -
  • +
      +
    • The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities.
    • +
    • The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed get it to Recommendation and deployed on the real Web.
    • +
    +

Arguments against focused on mandating using W3C Community Groups to incubate proposals until they met empirical criteria included:

    -
  • Incubation isn't a silver bullet to be applied to every situation
  • -
  • If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate proponents to take it to a WG for broad review
  • -
  • Requiring external incubation in a venue that doesn't require broad consensus -could lead to key technical decisions being made in forums dominated by a few, -with "level playing field" discussion beginning only when implementation momentum makes change difficult.
  • -
  • There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG
  • -
  • It may be valuable for W3C team to help develop one or more proposals in the incubation stage
  • +
  • Incubation isn't a silver bullet to be applied to every situation
  • +
  • If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate proponents to take it to a WG for broad review
  • +
  • Requiring external incubation in a venue that doesn't require broad consensus + could lead to key technical decisions being made in forums dominated by a few, + with "level playing field" discussion beginning only when implementation momentum makes change difficult.
  • +
  • There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG
  • +
  • It may be valuable for W3C team to help develop one or more proposals in the incubation stage

The readiness criteria below outline best practices for finding an appropriate balance among these perspectives. They encourage all involved in advancing work to the Recommendation track to gather more evidence to drive the decision and to think carefully about how to interpret it. They do not mandate any one mode of gathering that evidence or an algorithm to assess it.

-

- Readiness Criteria -

+

Readiness Criteria

The criteria here are used to evaluate whether a technical specification development effort is ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids RFC 2119 "MUST" and "SHOULD" terminology, and should not be a taken @@ -192,8 +137,8 @@

Has the proposed spec been incubated to reasonable maturity?

Web Platform WG charter describes a one community's practice:

-

The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community -Group or another similar incubation phase.

+

The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community + Group or another similar incubation phase.

If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. @@ -265,11 +210,8 @@

Team Engagement?

Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see Team support for CGs), but CG participants are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track.

- -

- Process Considerations -

- +

Process Considerations

+

Discussion about these guidelines has generated a number of questions about how they relate to the W3C process and the Team's existing practices.
They are out of scope for this document, but they are listed for reference:

@@ -304,21 +246,12 @@

What to do when there is interest from users but not implementers?

and perhaps working in tandem with one or more Community Groups to develop credible technical proposals to address those use cases?

-

- Conclusion -

- -

The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions:

+

Conclusion

+ +

The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions:

    -
  • Does the work address a real un-met need or missed opportunity for the Web?
  • -
  • Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others?
  • -
  • Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful?
  • -
- -
-
-
Coralie Mercier for the W3C Team - Feedback and comments are welcome. Please use Github issues. -
- - +
  • Does the work address a real un-met need or missed opportunity for the Web?
  • +
  • Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others?
  • +
  • Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful?
  • + \ No newline at end of file From 95816599cf8ded0f1eeb720acbc28110df7478bd Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Fri, 29 Nov 2024 18:12:15 +0400 Subject: [PATCH 005/225] remove Gemfile.lock --- Gemfile.lock | 107 --------------------------------------------------- 1 file changed, 107 deletions(-) delete mode 100644 Gemfile.lock diff --git a/Gemfile.lock b/Gemfile.lock deleted file mode 100644 index ed4b07668..000000000 --- a/Gemfile.lock +++ /dev/null @@ -1,107 +0,0 @@ -GEM - remote: https://rubygems.org/ - specs: - addressable (2.8.7) - public_suffix (>= 2.0.2, < 7.0) - colorator (1.1.0) - commonmarker (0.17.13) - ruby-enum (~> 0.5) - concurrent-ruby (1.3.4) - em-websocket (0.5.3) - eventmachine (>= 0.12.9) - http_parser.rb (~> 0) - eventmachine (1.2.7) - ffi (1.17.0-arm64-darwin) - forwardable-extended (2.6.0) - http_parser.rb (0.8.0) - i18n (1.14.6) - concurrent-ruby (~> 1.0) - jekyll (4.1.1) - addressable (~> 2.4) - colorator (~> 1.0) - em-websocket (~> 0.5) - i18n (~> 1.0) - jekyll-sass-converter (~> 2.0) - jekyll-watch (~> 2.0) - kramdown (~> 2.1) - kramdown-parser-gfm (~> 1.0) - liquid (~> 4.0) - mercenary (~> 0.4.0) - pathutil (~> 0.9) - rouge (~> 3.0) - safe_yaml (~> 1.0) - terminal-table (~> 1.8) - jekyll-commonmark (1.3.1) - commonmarker (~> 0.14) - jekyll (>= 3.7, < 5.0) - jekyll-commonmark-ghpages (0.1.6) - commonmarker (~> 0.17.6) - jekyll-commonmark (~> 1.2) - rouge (>= 2.0, < 4.0) - jekyll-optional-front-matter (0.3.2) - jekyll (>= 3.0, < 5.0) - jekyll-readme-index (0.3.0) - jekyll (>= 3.0, < 5.0) - jekyll-relative-links (0.7.0) - jekyll (>= 3.3, < 5.0) - jekyll-remote-theme (0.4.3) - addressable (~> 2.0) - jekyll (>= 3.5, < 5.0) - jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0) - rubyzip (>= 1.3.0, < 3.0) - jekyll-sass-converter (2.2.0) - sassc (> 2.0.1, < 3.0) - jekyll-titles-from-headings (0.5.3) - jekyll (>= 3.3, < 5.0) - jekyll-toc (0.19.0) - jekyll (>= 3.9) - nokogiri (~> 1.12) - jekyll-watch (2.2.1) - listen (~> 3.0) - kramdown (2.5.1) - rexml (>= 3.3.9) - kramdown-parser-gfm (1.1.0) - kramdown (~> 2.0) - liquid (4.0.4) - listen (3.9.0) - rb-fsevent (~> 0.10, >= 0.10.3) - rb-inotify (~> 0.9, >= 0.9.10) - mercenary (0.4.0) - nokogiri (1.16.7-arm64-darwin) - racc (~> 1.4) - pathutil (0.16.2) - forwardable-extended (~> 2.6) - public_suffix (6.0.1) - racc (1.8.1) - rb-fsevent (0.11.2) - rb-inotify (0.11.1) - ffi (~> 1.0) - rexml (3.3.9) - rouge (3.30.0) - ruby-enum (0.9.0) - i18n - rubyzip (2.3.2) - safe_yaml (1.0.5) - sassc (2.4.0) - ffi (~> 1.9) - terminal-table (1.8.0) - unicode-display_width (~> 1.1, >= 1.1.1) - unicode-display_width (1.8.0) - webrick (1.9.0) - -PLATFORMS - arm64-darwin-23 - -DEPENDENCIES - jekyll (~> 4.1.0) - jekyll-commonmark-ghpages - jekyll-optional-front-matter - jekyll-readme-index - jekyll-relative-links - jekyll-remote-theme - jekyll-titles-from-headings - jekyll-toc - webrick - -BUNDLED WITH - 2.3.26 From d32d5b1b9dba789045a67e635fc1e1030602879f Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Fri, 29 Nov 2024 18:12:37 +0400 Subject: [PATCH 006/225] + gitignore --- .gitignore | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000000000..2994c7b01 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +Gemfile.lock +.jekyll-cache +.jekyll-metadata +_site From c5be3f70dd76406470822ab3ae5c7bb123b39521 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Fri, 29 Nov 2024 18:29:30 +0100 Subject: [PATCH 007/225] Remove unneeded assets --- documentreview/style.css | 121 --------------------------------------- documentreview/toc.js | 59 ------------------- 2 files changed, 180 deletions(-) delete mode 100644 documentreview/style.css delete mode 100644 documentreview/toc.js diff --git a/documentreview/style.css b/documentreview/style.css deleted file mode 100644 index 6deeed330..000000000 --- a/documentreview/style.css +++ /dev/null @@ -1,121 +0,0 @@ -@font-face { - font-family: 'RalewayWF'; - src: url('https://www.w3.org/International/style/fonts/raleway-regular-webfont.woff2') format('woff2'); - font-weight: normal; - font-style: normal; - } -@font-face { - font-family: 'RalewayWF'; - src: url('https://www.w3.org/International/style/fonts/raleway-bold-webfont.woff2') format('woff2'); - font-weight: bold; - font-style: normal; - } -@font-face { - font-family: 'RalewayWF'; - src: url('https://www.w3.org/International/style/fonts/raleway-italic-webfont.woff2') format('woff2'); - font-weight: normal; - font-style: italic; - } - - -body { - font-family: RalewayWF; - line-height: 1.6; - margin-inline: 3em; - margin-block: 0; - padding-inline: 4em; - padding-block: 2em; - } - -@media (max-width: 600px) { - body { - margin-inline: auto; - width: clamp(16rem, 95vw, 85rem); - padding-inline: clamp(1.4rem, 1.5rem, 2rem); - } - } - -h2 { - margin-top: 3em; - } -h3 { - margin-top: 2em; - } -#toc ol { - list-style-type: none; - line-height: 1.7; - } -summary { - font-style: italic; - cursor: pointer; - } -dt { - font-weight: bold; - } -#versionInfo { - margin-top: 4em; - } -h2 a { - text-decoration: none; - color: #005a9c; - } -#toc a { - text-decoration: none; - } -.toc1 { - margin-inline-start: 2em; - line-height: 1.7; - } -.toc2 { - margin-inline-start: 5em; - font-size: 90%; - } - -/* SELF LINKS */ -h2, h3, h4, h5, h6 { position: relative; } -.selflink { display: none; } -h2:hover > a.selflink::before, h3:hover > a.selflink::before, h4:hover > a.selflink::before, h5:hover > a.selflink::before, h6:hover > a.selflink::before { - content: "§"; - display: block; - } -h2 > a.selflink, h3 > a.selflink, h4 > a.selflink, h5 > a.selflink, h6 > a.selflink { - color: inherit; - font-size: 83%; - text-align: center; - background-color: transparent; - } -h2:hover > a.selflink, h3 > a.selflink, h4 > a.selflink, h5 > a.selflink, h6 > a.selflink { - border: none; - color: inherit; - font-size: 83%; - height: 2em; - left: -1.6em; - opacity: .5; - position: absolute; - text-align: start; - text-decoration: none; - top: 0; - transition: opacity .2s; - width: 2em; - display: block; - } - -#githubissue { - width: 70%; - margin: auto; - border-bottom: 3px solid #005A9C; - padding: 1em 1em; - background: #e2edfe; -} - -#githubissue input[type=text] { - width: 70%; - margin-bottom: 0.5em; -} - -.githublabel { - font-weight: bold; - border: 1px solid gray; - border-radius: .5em; - padding: 2px 5px; -} \ No newline at end of file diff --git a/documentreview/toc.js b/documentreview/toc.js deleted file mode 100644 index ad447b1ec..000000000 --- a/documentreview/toc.js +++ /dev/null @@ -1,59 +0,0 @@ -function createtoc (maxlevel) { - // creates a TOC and puts it in a div with id="toc" & creates a self-link - // expect to find the id on the heading markup, NOT the section, and NO a around the heading text - // works for h2 or h2+h3 (if maxlevel set to 3) - - var h2s = document.querySelectorAll('h2') - var toc = document.getElementById('toc') - var h2, h3, id, h, a - var toc = '' - - for (var i=0; i 2) { - // check for h3s - var h3s = h2s[i].parentNode.querySelectorAll('h3'); - for (var k=0; k'+heading+'' - } From 3887ad8d51e47b068d7f876e6194003419ad8897 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Fri, 29 Nov 2024 18:34:49 +0100 Subject: [PATCH 008/225] Rename createGitHubIssue.js in create-github-issue.js --- documentreview/{createGitHubIssue.js => create-github-issue.js} | 0 documentreview/index.md | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-) rename documentreview/{createGitHubIssue.js => create-github-issue.js} (100%) diff --git a/documentreview/createGitHubIssue.js b/documentreview/create-github-issue.js similarity index 100% rename from documentreview/createGitHubIssue.js rename to documentreview/create-github-issue.js diff --git a/documentreview/index.md b/documentreview/index.md index b1f03e44b..9b736ca79 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -275,4 +275,4 @@ See the [Document Review Dashboard](https://www.w3.org/wiki/Dashboard#Document_R
    See the [commit history](https://github.com/w3c/Guide/tree/main/documentreview).
    - + From bae4104b162165a8a9c87c8107a8be3d127b56d2 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Fri, 29 Nov 2024 19:27:16 +0100 Subject: [PATCH 009/225] unneeded (/Guide/Jigedit/ doc is still hosted in CVS) --- Jigedit/.htaccess | 7 ------- 1 file changed, 7 deletions(-) delete mode 100644 Jigedit/.htaccess diff --git a/Jigedit/.htaccess b/Jigedit/.htaccess deleted file mode 100644 index 7c6681cab..000000000 --- a/Jigedit/.htaccess +++ /dev/null @@ -1,7 +0,0 @@ -# -# $Id: .htaccess,v 1.1 2005/01/12 17:50:03 ylafon Exp $ -# - -ForceType 'text/html; charset=UTF-8' - - From bd30d1b57ab55c8bb95e2244bbba347651abe056 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 14:20:08 +0100 Subject: [PATCH 010/225] convert to markdown --- standards-track/index.html | 257 ------------------------------------- standards-track/index.md | 165 ++++++++++++++++++++++++ 2 files changed, 165 insertions(+), 257 deletions(-) delete mode 100644 standards-track/index.html create mode 100644 standards-track/index.md diff --git a/standards-track/index.html b/standards-track/index.html deleted file mode 100644 index ad59bc412..000000000 --- a/standards-track/index.html +++ /dev/null @@ -1,257 +0,0 @@ ---- -title: W3C Recommendation Track Readiness Best Practices -toc: true ---- - -

    Status

    -

    October 2023: Document updated to account for changes in Process 2023, in particular the Director-free changes.

    -

    August 2016: This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

    -

    This document lives in Github, where changes can be tracked and pull requests are welcome. - Feedback and comments are welcome. Please use Github issues.

    - -

    Problem Statement

    -

    The practices proposed in this document are intended to address some specific problems:

    -

    W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere

    - -

    Overview of the Proposed Solution

    -

    W3C should more tightly focus its -formal standardization effors on specifications that are most likely to get consensus within the consortium -and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work -to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD.

    - -

    These are offered as guidelines, not a checklist of required items in every proposal. -Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal -of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by -WGs and determination of W3C Decisions.

    - -

    The target audience for this document includes:

    - -
      -
    • the Team and Advisory Committee, when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations;
    • -
    • working group Chairs, when determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope,
    • -
    - -

    This document attempts to strike a balance between two classes of criteria:

    - -
      -
    • "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web
    • -
    • "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters
    • -
    - -

    Discussion at the October 2015 Advisory Committee meeting -indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being -put on the Recommendation track.

    - -

    Arguments raised in favor of mandatory incubation included:

    - -
      -
    • The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world.
    • -
    • Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation
    • -
    • The industry overall is moving toward more data-driven decision making
    • -
    • It's useful to identify what criteria are prerequisites for a Recommendation Track effort, but not to prescribe how those -criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. -
        -
      • The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities.
      • -
      • The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed get it to Recommendation and deployed on the real Web.
      • -
      -
    • -
    - -

    Arguments against focused on mandating using W3C Community Groups to incubate proposals until they -met empirical criteria included:

    - -
      -
    • Incubation isn't a silver bullet to be applied to every situation
    • -
    • If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate proponents to take it to a WG for broad review
    • -
    • Requiring external incubation in a venue that doesn't require broad consensus - could lead to key technical decisions being made in forums dominated by a few, - with "level playing field" discussion beginning only when implementation momentum makes change difficult.
    • -
    • There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG
    • -
    • It may be valuable for W3C team to help develop one or more proposals in the incubation stage
    • -
    - -

    The readiness criteria below outline best practices for finding an appropriate balance among these perspectives. -They encourage all involved in advancing work to the Recommendation track to gather more evidence to drive the decision and to think carefully -about how to interpret it. They do not mandate any one mode of gathering that evidence or an algorithm to assess it.

    - -

    Readiness Criteria

    - -

    The criteria here are used to evaluate whether a technical specification development effort is -ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids RFC 2119 "MUST" and "SHOULD" terminology, and should not be a taken -as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are -noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would -facilitate the W3C decision. Different cases will involve different combinations of these factors. In determining whether to -approve moving work to the Recommendation track, the Team may consider -other factors not listed in this document as well.

    - -

    Assessing whether proposed work is likely to fulfull the W3C mission to lead the web to its full potential -is the traditional criterion the Team and Advisory Committee use to evaluate whether to start a working group or advance -a specification. While this is "aspirational", it requires -judgment that balances the future potential of the Web alongside the need for real developers to make the Web work in practice. -This document seeks to make the factors that go into this judgment -more explicit and generally applicable.

    - -

    The "empirical" criteria are inspired largely by the experience of some open source browser projects -that use an intent to implement process -to build the case for shipping -a new feature. This document refines this approach to apply to Recommendation -Track transition decisions. -The Web Platform Incubator Community Group has adopted -something similar to determine when a spec under incubation is ready to propose to a -Working Group.

    - -

    Is there a clear problem statement?

    - -

    Strongly Recommended: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate.
    -What are web developers forced to do without this feature being available in a standardized way? -What fraction of web sites, hybrid applications, data publishers, etc. are using a similar capability in a non-standardized way? -How would users benefit from this feature if standardized?

    - -

    Are success criteria explicit?

    - -

    Strongly Recommended: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to -support the spec for it to be -successful, and indicate what degree of critical mass would be needed.
    -Is this spec serving a specialized community and only that community needs to implement and adopt it for it to be successful? -Or are there critical ecosystem dependencies, e.g. the spec must be deployed on both -the cloud/server and browser/client, -or must be supported both in products for producers and consumers of web content, to be really useful?

    - -

    Is there a well-socialized proposal to address the problem?

    - -

    Strongly Recommended: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app -developer, framework/took developer, and core technology implementers are represented. -The state of community consensus around the initial draft should be documented: Did potential users and key implementers actively participate -in the discussion? Are there any indications that social or economic pressure was applied to suppress dissent? Did the discussion generate sustained expressions of opposition or unwillingness to implement / use / make patent -commitments from key stakeholders? If there are indications that consensus in a WG will be difficult to achieve, proposers are well advised -to make a persuasive case for how the proposed Recommendation Track work can be successful.

    - -

    Has the proposed spec been incubated to reasonable maturity?

    - -

    Strongly Recommended: Charters do not list specs as deliverables, and WGs do not publish FWPDs, until there is -rough consensus across stakeholders that the spec solves a real problem, is likely to be implemented, and is likely to -be used on the Web. This consensus could emerge from an incubation phase in WICG or another CG, or in a WG that has an established -culture of taking and vetting suggestions from its public mailing list.

    - -

    The language in the -Web Platform WG charter describes a one community's practice:

    - -
    -

    The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community - Group or another similar incubation phase.

    -
    - -

    If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. -While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that -did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional W3C Community Group Charter Template contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point.

    - -

    The key word is "matured", and the key milestone is First Public Working Draft (FPWD). It may be inefficient to charter WGs that start with -a "blank sheet of paper" or multiple proposals with different use cases, but it hurts W3C's credibility to -publish a formal Technical Report that specifies a technology that does NOT meet clear user needs in a way that has a good chance to be implemented in products, tools, websites, -and web applications. However the incubation phase is done, and whichever of these criteria are applied before proposing standardization -or developing a charter,this document strongly recommends that only "mature" specs be published as FPWDs.

    - -

    Is it clear the proposers are not seeking a rubber stamp from W3C?

    - -

    Strongly Recommended: Proposers of Recommendation-track work should be prepared for the Working Group to -make substantive changes to the initial draft in response to feedback. A W3C Recommendation signifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need -and is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and -who interact with various levels of trust. Likewise, proposed Recommendation-track work should not promote - -

    Are there appropriate expressions of interest?

    - -

    The proposal points to statements of support from key stakeholders about the value proposition for the feature -it describes. Is there strong demand from potential users? Is there a critical mass of implementers tentatively interested in shipping this feature -if standardized? Are there prototype / polyfill implementations that are used in experimental apps / sites -that the target audience already finds useful?

    - -

    Is there actual evidence to back up the answers?

    - -

    The proposal describes what implementation and user experience is there to back up the points above. -What fraction of websites are implementing a similar feature in a non-standardized way? -How many users would potentially benefit from this feature if standardized? -Hard data is preferred, but estimates backed up by detailed explanations are acceptable.

    - -

    Risks?

    - -

    The proposal considers whether standardizing the spec could create more problems than it solves. -What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. -if broadly deployed? Are there scenarios under which we would regret standardizing this feature?

    - -

    Is the timing right?

    - -

    The optimal timing for a transition to the Recommendation Track can be described as:

    - -
      -
    • NO SOONER than the bulk of the criteria above are met.
    • -
    • NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites.
    • -
    - -

    If the answer “the ship has sailed”, proposers should explain how they propose to mitigate the situation without turning back the clock, -and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, -and getting broader patent commitments on the interoperable behavior arguably has value.

    - -

    Clear RF licensing commitments?

    - -

    W3C seeks to issue Recommendations that can be implemented and used on a -Royalty-Free basis.

    -
      -
    1. Are the technologies in the initial available under terms that are compatible with the -W3C Royalty-Free licensing requirements?
    2. -
    3. Have those who seem most likely to have relevant patents made commitments to license them on -royalty-free terms?
    4. -
    5. Is the provenance of substantive contributions to the draft reasonably clear?
    6. -
    - -

    Team Engagement?

    - -

    It is advisable for groups considering Recommendation Track work to consult with the W3C -Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal.

    - -

    Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see Team support for CGs), but CG participants are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track.

    - -

    Process Considerations

    - -

    Discussion about these guidelines has generated a number of questions about how they relate to the W3C process and the Team's existing practices.
    -They are out of scope for this document, but they are listed for reference:

    - -

    Granularity

    - -

    Should the considerations above be applied at at the specification level or the feature level?

    - -

    Charter Scopes and Deliverables

    - -

    When chartering a new WG, is it appropriate to put in scope a number of features that are mostly "aspirational" and put in the deliverables -section only those that meet most of the criteria above?

    - -

    When an incubator spec is ready to move to a WG, does it wait (possibly a couple of years) -to get into a WG Charter or are is the expectation that WGs would re-charter to take on incubated spec proposals?

    - -

    Or is the best practice to make the scope of charters broad enough to encompass work that may be incubated during -the charter's lifetime, and the WG would only take up an actual deliverable once it is incubated?

    - -

    Community Groups and the W3C Process

    - -

    How can we ensure that concerns raised at the TPAC 2015 AC meeting and the AC Forum thread on Mandatory Incubation are addressed -in the process or practice of W3C?

    - -

    Should the Process Document describe a role for CGs in getting specifications ready to be standardized? Should the Community -and Business Group Process say more about the importance of working by consensus, at least for specifications that -are to be proposed for the Recommendation Track?

    - -

    What to do when there is interest from users but not implementers?

    - -

    Raised in the AC discussions.
    -Should the Process Document do more to describe a role for Interest Groups in developing use cases for new Recommendations, -and perhaps working in tandem with one or more Community Groups to develop credible technical proposals to address those -use cases?

    - -

    Conclusion

    - -

    The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions:

    - -
      -
    • Does the work address a real un-met need or missed opportunity for the Web?
    • -
    • Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others?
    • -
    • Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful?
    • -
    \ No newline at end of file diff --git a/standards-track/index.md b/standards-track/index.md new file mode 100644 index 000000000..bb6e40807 --- /dev/null +++ b/standards-track/index.md @@ -0,0 +1,165 @@ +--- +title: W3C Recommendation Track Readiness Best Practices +toc: true +--- + +## Status + +October 2023: Document updated to account for [changes in Process 2023](https://www.w3.org/2023/Process-20230612/#changes-2021), in particular the Director-free changes. + +August 2016: This document was developed by a task force of the [W3C Advisory Board](https://www.w3.org/2002/ab/), socialised to the W3C Advisory Committee and W3C Team. + +This [document lives in Github](https://github.com/w3c/standards-track/blob/master/index.html), where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use [Github issues](https://github.com/w3c/standards-track/issues). + +## Problem Statement + +The practices proposed in this document are intended to address some specific problems: + +W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere + +## Overview of the Proposed Solution + +W3C should more tightly focus its formal standardization effors on specifications that are most likely to get consensus within the consortium and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD. + +These are offered as guidelines, not a checklist of required items in every proposal. Meeting all the guidelines will not guarantee the [W3C decision](https://www.w3.org/policies/process/#def-w3c-decision) for [approval of the charter](https://www.w3.org/policies/process/#cfp), or [advancement to FPWD](https://www.w3.org/policies/process/#maturity-stages), nor will failing to meet some block approval. *The goal of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by WGs and determination of W3C Decisions.* + +The target audience for this document includes: + +- the Team and Advisory Committee, when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations; +- working group Chairs, when determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope, + +This document attempts to strike a balance between two classes of criteria: + +- "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web +- "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters + +Discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2015/10/27-ac-minutes.html#item02) indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being put on the Recommendation track. + +Arguments raised in favor of mandatory incubation included: + +- The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world. +- Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation +- The industry overall is moving toward more data-driven decision making +- It's useful to identify *what* criteria are prerequisites for a Recommendation Track effort, but not to prescribe *how* those criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. + + - The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities. + - The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed get it to Recommendation and deployed on the real Web. + +Arguments against focused on mandating using W3C Community Groups to incubate proposals until they met empirical criteria included: + +- Incubation isn't a silver bullet to be applied to every situation +- If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate proponents to take it to a WG for broad review +- Requiring external incubation in a venue that doesn't require broad consensus could lead to key technical decisions being made in forums dominated by a few, with "level playing field" discussion beginning only when implementation momentum makes change difficult. +- There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG +- It may be valuable for W3C team to help develop one or more proposals in the incubation stage + +The readiness criteria below outline best practices for finding an appropriate balance among these perspectives. They encourage all involved in advancing work to the Recommendation track to gather more evidence to drive the decision and to think carefully about how to interpret it. They do not mandate any one mode of gathering that evidence or an algorithm to assess it. + +## Readiness Criteria + +The criteria here are used to evaluate whether a technical specification development effort is ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would facilitate the [W3C decision](https://www.w3.org/policies/process/#decision-types). Different cases will involve different combinations of these factors. In determining whether to approve moving work to the Recommendation track, the Team may consider other factors not listed in this document as well. + +Assessing whether proposed work is likely to fulfull the W3C mission to [lead the web to its full potential](http://www.w3.org/Consortium/mission) is the traditional criterion the Team and Advisory Committee use to evaluate whether to start a working group or advance a specification. While this is "aspirational", it requires judgment that balances the future potential of the Web alongside the need for real developers to make the Web work in practice. This document seeks to make the factors that go into this judgment more explicit and generally applicable. + +The "empirical" criteria are inspired largely by the experience of some open source browser projects that use an [intent to implement](https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit) process to build the case for shipping a new feature. This document refines this approach to apply to Recommendation Track transition decisions. The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted something similar to [determine when a spec under incubation is ready to propose to a Working Group](https://wicg.github.io/admin/intent-to-migrate.html). + +### Is there a clear problem statement? + +*Strongly Recommended*: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate. +What are web developers forced to do without this feature being available in a standardized way? What fraction of web sites, hybrid applications, data publishers, etc. are using a similar capability in a non-standardized way? How would users benefit from this feature if standardized? + +### Are success criteria explicit? + +*Strongly Recommended*: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be successful, and indicate what degree of critical mass would be needed. +Is this spec serving a specialized community and only that community needs to implement and adopt it for it to be successful? Or are there critical ecosystem dependencies, e.g. the spec must be deployed on both the cloud/server and browser/client, or must be supported both in products for producers and consumers of web content, to be really useful? + +### Is there a well-socialized proposal to address the problem? + +*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app developer, framework/took developer, and core technology implementers are represented. The state of community consensus around the initial draft should be documented: Did potential users and key implementers actively participate in the discussion? Are there any indications that social or economic pressure was applied to suppress dissent? Did the discussion generate sustained expressions of opposition or unwillingness to implement / use / make patent commitments from key stakeholders? If there are indications that consensus in a WG will be difficult to achieve, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work can be successful. + +### Has the proposed spec been incubated to reasonable maturity? + +*Strongly Recommended*: Charters do not list specs as deliverables, and WGs do not publish FWPDs, until there is rough consensus across stakeholders that the spec solves a real problem, is likely to be implemented, and is likely to be used on the Web. This consensus could emerge from an incubation phase in WICG or another CG, or in a WG that has an established culture of taking and vetting suggestions from its public mailing list. + +The language in the [Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) describes a one community's practice: + +> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. + +If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional [W3C Community Group Charter Template](https://github.com/w3c/cg-charter/blob/gh-pages/CGCharter.html) contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point. + +The key word is "matured", and the key milestone is First Public Working Draft (FPWD). It may be inefficient to charter WGs that start with a "blank sheet of paper" or multiple proposals with different use cases, but it hurts W3C's credibility to publish a formal Technical Report that specifies a technology that does NOT meet clear user needs in a way that has a good chance to be implemented in products, tools, websites, and web applications. However the incubation phase is done, and whichever of these criteria are applied before proposing standardization or developing a charter,this document strongly recommends that only "mature" specs be published as FPWDs. + +### Is it clear the proposers are not seeking a rubber stamp from W3C? + +*Strongly Recommended*: Proposers of Recommendation-track work should be prepared for the Working Group to make substantive changes to the initial draft in response to feedback. A W3C Recommendation signifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need *and* is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and who interact with various levels of trust. Likewise, proposed Recommendation-track work should not promote + +### Are there appropriate expressions of interest? + +The proposal points to statements of support from key stakeholders about the value proposition for the feature it describes. Is there strong demand from potential users? Is there a critical mass of implementers tentatively interested in shipping this feature if standardized? Are there prototype / polyfill implementations that are used in experimental apps / sites that the target audience already finds useful? + +### Is there actual evidence to back up the answers? + +The proposal describes what implementation and user experience is there to back up the points above. What fraction of websites are implementing a similar feature in a non-standardized way? How many users would potentially benefit from this feature if standardized? Hard data is preferred, but estimates backed up by detailed explanations are acceptable. + +### Risks? + +The proposal considers whether standardizing the spec could create more problems than it solves. What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. if broadly deployed? Are there scenarios under which we would regret standardizing this feature? + +### Is the timing right? + +The optimal timing for a transition to the Recommendation Track can be described as: + +- NO SOONER than the bulk of the criteria above are met. +- NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. + +If the answer “the ship has sailed”, proposers should explain how they propose to mitigate the situation without turning back the clock, and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, and getting broader patent commitments on the interoperable behavior arguably has value. + +### Clear RF licensing commitments? + +W3C seeks to issue Recommendations that can be implemented and used on a [Royalty-Free](http://www.w3.org/policies/patent-policy/#sec-Requirements) basis. + +1. Are the technologies in the initial available under terms that are compatible with the [W3C Royalty-Free licensing requirements](http://www.w3.org/policies/patent-policy/#sec-Requirements)? +2. Have those who seem most likely to have relevant patents made commitments to license them on royalty-free terms? +3. Is the provenance of substantive contributions to the draft reasonably clear? + +### Team Engagement? + +It is advisable for groups considering Recommendation Track work to consult with the W3C Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. + +Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see [Team support for CGs](https://www.w3.org/2016/04/cg-support/)), but CG participants are encouraged to reach out to the [W3C staff](http://www.w3.org/People/) well in advance of proposing a transition to the Recommendation Track. + +## Process Considerations + +Discussion about these guidelines has generated a number of questions about how they relate to the W3C process and the Team's existing practices. +They are out of scope for this document, but they are listed for reference: + +### Granularity + +Should the considerations above be applied at at the specification level or the feature level? + +### Charter Scopes and Deliverables + +When chartering a new WG, is it appropriate to put in scope a number of features that are mostly "aspirational" and put in the deliverables section only those that meet most of the criteria above? + +When an incubator spec is ready to move to a WG, does it wait (possibly a couple of years) to get into a WG Charter or are is the expectation that WGs would re-charter to take on incubated spec proposals? + +Or is the best practice to make the *scope* of charters broad enough to encompass work that may be incubated during the charter's lifetime, and the WG would only take up an actual deliverable once it is incubated? + +### Community Groups and the W3C Process + +How can we ensure that concerns raised at the TPAC 2015 AC meeting and the AC Forum thread on Mandatory Incubation are addressed in the process or practice of W3C? + +Should the Process Document describe a role for CGs in getting specifications ready to be standardized? Should the Community and Business Group Process say more about the importance of working by consensus, at least for specifications that are to be proposed for the Recommendation Track? + +### What to do when there is interest from users but not implementers? + +Raised in the [AC discussions](https://lists.w3.org/Archives/Member/w3c-ac-forum/2016JanMar/0013.html). +Should the Process Document do more to describe a role for Interest Groups in developing use cases for new Recommendations, and perhaps working in tandem with one or more Community Groups to develop credible technical proposals to address those use cases? + +## Conclusion + +The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: + +- Does the work address a real un-met need or missed opportunity for the Web? +- Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others? +- Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful? From f28df74ebb3a0ea75799bc8d87f247b889aaa3be Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Tue, 3 Dec 2024 17:46:25 +0400 Subject: [PATCH 011/225] add prefooter --- _includes/prefooter.html | 1 + 1 file changed, 1 insertion(+) create mode 100644 _includes/prefooter.html diff --git a/_includes/prefooter.html b/_includes/prefooter.html new file mode 100644 index 000000000..090763847 --- /dev/null +++ b/_includes/prefooter.html @@ -0,0 +1 @@ +

    This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.

    From 7953b855a1e472f31de28f49adb99f03f467faa5 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 14:34:24 +0100 Subject: [PATCH 012/225] rename --- manual-of-style/{index.html => index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename manual-of-style/{index.html => index.md} (100%) diff --git a/manual-of-style/index.html b/manual-of-style/index.md similarity index 100% rename from manual-of-style/index.html rename to manual-of-style/index.md From 97014680c40cadf412787eae8aa009a94feafdec Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 14:53:25 +0100 Subject: [PATCH 013/225] fix link --- _includes/prefooter.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/prefooter.html b/_includes/prefooter.html index 090763847..50d7c4ccb 100644 --- a/_includes/prefooter.html +++ b/_includes/prefooter.html @@ -1 +1 @@ -

    This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.

    +

    This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.

    From 7fbfd9926c93f1b36b4ee1cfcb57c3bc81c10aa6 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 15:55:48 +0100 Subject: [PATCH 014/225] Revert "rename" This reverts commit f9d189b3bdad5fcc007078b1d6f8aa87b7efe82d. --- manual-of-style/{index.md => index.html} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename manual-of-style/{index.md => index.html} (100%) diff --git a/manual-of-style/index.md b/manual-of-style/index.html similarity index 100% rename from manual-of-style/index.md rename to manual-of-style/index.html From b3c1d3b898aa7a65436c0d02d3c0b2d61341c2fa Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 17:10:09 +0100 Subject: [PATCH 015/225] renamed html into md --- .../elected-body-communication-guidelines.md | 115 ++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 other/elected-body-communication-guidelines.md diff --git a/other/elected-body-communication-guidelines.md b/other/elected-body-communication-guidelines.md new file mode 100644 index 000000000..d7d783de6 --- /dev/null +++ b/other/elected-body-communication-guidelines.md @@ -0,0 +1,115 @@ + + + + +Guidelines for communicating as a member of a W3C elected body + + + + + + + + + + +
    +

    Nearby

    + +
    + +
    +

    This document provides guidance for members of the W3C elected bodies: the Advisory Board (AB) and Technical Architecture Group (TAG).

    + +

    W3C elected bodies

    + +

    The AB and the TAG are defined in the W3C Process, as are the rules of participation for both groups.

    + +

    W3C values and behaviours

    + +

    Like all W3C participants, members of elected bodies are required to follow the W3C Code of Conduct. As leaders, members of elected bodies should also consider the ways in which they can demonstrate the Code of Conduct's expected behavior, and proactively respond to instances of unacceptable behavior.

    + +

    Communication guidelines

    + +

    As the W3C process says:

    + +
    Advisory Board and TAG participants have a special role within W3C. They are elected by the membership and appointed by the Team with the expectation that they will use their best judgement to find the best solutions for the web, not just for any network, technology, vendor, or user.
    + +

    As leaders within the W3C community, the opinions of members of elected bodies carry particular weight, whether they are expressed within our community or elsewhere.

    + +

    As a member of an elected body:

    +
      +
    • It is assumed you are speaking as an individual unless you state otherwise.
    • +
    • If you want to express the opinion of your organisation or a group you are affiliated with, make it clear before you state their view.
    • +
    • If you have multiple roles within the W3C community, for example you are a member of the AB and also a member of the Advisory Committee (AC), but your position as AB member is not the same as your position as AC representative, inform the other members of the group as a courtesy.
    • +
    • Do not use phrases like "on behalf of the AB" or "the TAG thinks that" unless the group has asked you to do so.
    • +
    • When you represent the elected body you are a member of, be clear that is what you are doing.
    • +
    • When not speaking for the elected body you are a member of, be aware that people will still be aware of your participation. You may decide to mention your participation anyway and should do so cautiously. Here are some examples: +
        +
      • If you are making a comment which has nothing to do with the business of the elected body you are a member of, there is no need to mention your participation.
      • +
      • If your comment is influenced by your participation in the elected body, you may want to mention it, for example "In my experience of being on the AB...".
      • +
      +
    • +
    • You will be held to a higher standard as a result of your elected status and in recognition of your leadership within the W3C community.
    • +
    + +

    Representing formal decisions

    + +

    When communicating a formal decision by the elected body you are a member of:

    +
      +
    • Express clearly what was decided and what was not decided.
    • +
    • Share the intended message with the rest of the elected body you are a member of, with time for them to review and comment on the message before it is released.
    • +
    • If time is limited because the elected body needs to respond urgently, a minimum review period of 24 hours plus review by the Chair(s) of the elected body is required.
    • +
    + +

    When discussing a decision made by the elected body you are a member of:

    +
      +
    • Be respectful about the decision, even if you did not support the consensus of the elected body.
    • +
    • Be respectful of all points of view, even those that did not gain consensus.
    • +
    + +

    When discussing a matter that has not reached a conclusion:

    +
      +
    • Be clear that the discussion is ongoing and has not reached a conclusion.
    • +
    • Make it clear when feedback and comments are wanted, and let people know how to do so.
    • +
    • Share the intended message with the rest of the elected body you are a member of before you send it.
    • +
    + +

    Revision History

    +
      +
    • 2020-09-03: Document becomes operational.
    • +
    • 2020-09-02: Document created.
    • +
    + +
    +
    +

    Feedback is to @w3c/guidebook + and is welcome on GitHub

    + + From 785f323f3d01f1b7e111dc3e3357f2e145c57453 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 17:10:30 +0100 Subject: [PATCH 016/225] renamed html into md --- ...elected-body-communication-guidelines.html | 115 ------------------ 1 file changed, 115 deletions(-) delete mode 100644 other/elected-body-communication-guidelines.html diff --git a/other/elected-body-communication-guidelines.html b/other/elected-body-communication-guidelines.html deleted file mode 100644 index d7d783de6..000000000 --- a/other/elected-body-communication-guidelines.html +++ /dev/null @@ -1,115 +0,0 @@ - - - - -Guidelines for communicating as a member of a W3C elected body - - - - - - - - - - -
    -

    Nearby

    - -
    - -
    -

    This document provides guidance for members of the W3C elected bodies: the Advisory Board (AB) and Technical Architecture Group (TAG).

    - -

    W3C elected bodies

    - -

    The AB and the TAG are defined in the W3C Process, as are the rules of participation for both groups.

    - -

    W3C values and behaviours

    - -

    Like all W3C participants, members of elected bodies are required to follow the W3C Code of Conduct. As leaders, members of elected bodies should also consider the ways in which they can demonstrate the Code of Conduct's expected behavior, and proactively respond to instances of unacceptable behavior.

    - -

    Communication guidelines

    - -

    As the W3C process says:

    - -
    Advisory Board and TAG participants have a special role within W3C. They are elected by the membership and appointed by the Team with the expectation that they will use their best judgement to find the best solutions for the web, not just for any network, technology, vendor, or user.
    - -

    As leaders within the W3C community, the opinions of members of elected bodies carry particular weight, whether they are expressed within our community or elsewhere.

    - -

    As a member of an elected body:

    -
      -
    • It is assumed you are speaking as an individual unless you state otherwise.
    • -
    • If you want to express the opinion of your organisation or a group you are affiliated with, make it clear before you state their view.
    • -
    • If you have multiple roles within the W3C community, for example you are a member of the AB and also a member of the Advisory Committee (AC), but your position as AB member is not the same as your position as AC representative, inform the other members of the group as a courtesy.
    • -
    • Do not use phrases like "on behalf of the AB" or "the TAG thinks that" unless the group has asked you to do so.
    • -
    • When you represent the elected body you are a member of, be clear that is what you are doing.
    • -
    • When not speaking for the elected body you are a member of, be aware that people will still be aware of your participation. You may decide to mention your participation anyway and should do so cautiously. Here are some examples: -
        -
      • If you are making a comment which has nothing to do with the business of the elected body you are a member of, there is no need to mention your participation.
      • -
      • If your comment is influenced by your participation in the elected body, you may want to mention it, for example "In my experience of being on the AB...".
      • -
      -
    • -
    • You will be held to a higher standard as a result of your elected status and in recognition of your leadership within the W3C community.
    • -
    - -

    Representing formal decisions

    - -

    When communicating a formal decision by the elected body you are a member of:

    -
      -
    • Express clearly what was decided and what was not decided.
    • -
    • Share the intended message with the rest of the elected body you are a member of, with time for them to review and comment on the message before it is released.
    • -
    • If time is limited because the elected body needs to respond urgently, a minimum review period of 24 hours plus review by the Chair(s) of the elected body is required.
    • -
    - -

    When discussing a decision made by the elected body you are a member of:

    -
      -
    • Be respectful about the decision, even if you did not support the consensus of the elected body.
    • -
    • Be respectful of all points of view, even those that did not gain consensus.
    • -
    - -

    When discussing a matter that has not reached a conclusion:

    -
      -
    • Be clear that the discussion is ongoing and has not reached a conclusion.
    • -
    • Make it clear when feedback and comments are wanted, and let people know how to do so.
    • -
    • Share the intended message with the rest of the elected body you are a member of before you send it.
    • -
    - -

    Revision History

    -
      -
    • 2020-09-03: Document becomes operational.
    • -
    • 2020-09-02: Document created.
    • -
    - -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - From 2fb8b16a641b6b49d1dc841c05c493f7a3f8c62c Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 3 Dec 2024 17:25:54 +0100 Subject: [PATCH 017/225] Convert to markdown --- .../elected-body-communication-guidelines.md | 174 ++++++------------ 1 file changed, 59 insertions(+), 115 deletions(-) diff --git a/other/elected-body-communication-guidelines.md b/other/elected-body-communication-guidelines.md index d7d783de6..5f47f9841 100644 --- a/other/elected-body-communication-guidelines.md +++ b/other/elected-body-communication-guidelines.md @@ -1,115 +1,59 @@ - - - - -Guidelines for communicating as a member of a W3C elected body - - - - - - - - - - -
    -

    Nearby

    - -
    - -
    -

    This document provides guidance for members of the W3C elected bodies: the Advisory Board (AB) and Technical Architecture Group (TAG).

    - -

    W3C elected bodies

    - -

    The AB and the TAG are defined in the W3C Process, as are the rules of participation for both groups.

    - -

    W3C values and behaviours

    - -

    Like all W3C participants, members of elected bodies are required to follow the W3C Code of Conduct. As leaders, members of elected bodies should also consider the ways in which they can demonstrate the Code of Conduct's expected behavior, and proactively respond to instances of unacceptable behavior.

    - -

    Communication guidelines

    - -

    As the W3C process says:

    - -
    Advisory Board and TAG participants have a special role within W3C. They are elected by the membership and appointed by the Team with the expectation that they will use their best judgement to find the best solutions for the web, not just for any network, technology, vendor, or user.
    - -

    As leaders within the W3C community, the opinions of members of elected bodies carry particular weight, whether they are expressed within our community or elsewhere.

    - -

    As a member of an elected body:

    -
      -
    • It is assumed you are speaking as an individual unless you state otherwise.
    • -
    • If you want to express the opinion of your organisation or a group you are affiliated with, make it clear before you state their view.
    • -
    • If you have multiple roles within the W3C community, for example you are a member of the AB and also a member of the Advisory Committee (AC), but your position as AB member is not the same as your position as AC representative, inform the other members of the group as a courtesy.
    • -
    • Do not use phrases like "on behalf of the AB" or "the TAG thinks that" unless the group has asked you to do so.
    • -
    • When you represent the elected body you are a member of, be clear that is what you are doing.
    • -
    • When not speaking for the elected body you are a member of, be aware that people will still be aware of your participation. You may decide to mention your participation anyway and should do so cautiously. Here are some examples: -
        -
      • If you are making a comment which has nothing to do with the business of the elected body you are a member of, there is no need to mention your participation.
      • -
      • If your comment is influenced by your participation in the elected body, you may want to mention it, for example "In my experience of being on the AB...".
      • -
      -
    • -
    • You will be held to a higher standard as a result of your elected status and in recognition of your leadership within the W3C community.
    • -
    - -

    Representing formal decisions

    - -

    When communicating a formal decision by the elected body you are a member of:

    -
      -
    • Express clearly what was decided and what was not decided.
    • -
    • Share the intended message with the rest of the elected body you are a member of, with time for them to review and comment on the message before it is released.
    • -
    • If time is limited because the elected body needs to respond urgently, a minimum review period of 24 hours plus review by the Chair(s) of the elected body is required.
    • -
    - -

    When discussing a decision made by the elected body you are a member of:

    -
      -
    • Be respectful about the decision, even if you did not support the consensus of the elected body.
    • -
    • Be respectful of all points of view, even those that did not gain consensus.
    • -
    - -

    When discussing a matter that has not reached a conclusion:

    -
      -
    • Be clear that the discussion is ongoing and has not reached a conclusion.
    • -
    • Make it clear when feedback and comments are wanted, and let people know how to do so.
    • -
    • Share the intended message with the rest of the elected body you are a member of before you send it.
    • -
    - -

    Revision History

    -
      -
    • 2020-09-03: Document becomes operational.
    • -
    • 2020-09-02: Document created.
    • -
    - -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +--- +title: Guidelines for communicating as a member of a W3C elected body +toc: true +--- + +This document provides guidance for members of the W3C elected bodies: the Advisory Board (AB) and Technical Architecture Group (TAG). + +## W3C elected bodies + +The [AB](/policies/process/#AB) and the [TAG](/policies/process/#TAG) are defined in the W3C Process, as are the [rules of participation](/policies/process/#AB-TAG-participation) for both groups. + +## W3C values and behaviours + +Like all W3C participants, members of elected bodies are required to follow the [W3C Code of Conduct](/policies/code-of-conduct/). As leaders, members of elected bodies should also consider the ways in which they can demonstrate the Code of Conduct's [expected behavior](/policies/code-of-conduct/#expected-behavior), and proactively respond to instances of [unacceptable behavior](/policies/code-of-conduct/#unacceptablebehavior). + +## Communication guidelines + +As the W3C process says: + +> Advisory Board and TAG participants have a special role within W3C. They are elected by the membership and [appointed by the Team](/policies/process/#TAG-appointments) with the expectation that they will use their best judgement to find the best solutions for the web, not just for any network, technology, vendor, or user. + +As leaders within the W3C community, the opinions of members of elected bodies carry particular weight, whether they are expressed within our community or elsewhere. + +As a member of an elected body: + +- It is assumed you are speaking as an individual unless you state otherwise. +- If you want to express the opinion of your organisation or a group you are affiliated with, make it clear before you state their view. +- If you have multiple roles within the W3C community, for example you are a member of the AB and also a member of the Advisory Committee (AC), but your position as AB member is not the same as your position as AC representative, inform the other members of the group as a courtesy. +- Do not use phrases like "on behalf of the AB" or "the TAG thinks that" unless the group has asked you to do so. +- When you represent the elected body you are a member of, be clear that is what you are doing. +- When not speaking for the elected body you are a member of, be aware that people will still be aware of your participation. You may decide to mention your participation anyway and should do so cautiously. Here are some examples: + + - If you are making a comment which has nothing to do with the business of the elected body you are a member of, there is no need to mention your participation. + - If your comment is influenced by your participation in the elected body, you may want to mention it, for example "In my experience of being on the AB...". +- You will be held to a higher standard as a result of your elected status and in recognition of your leadership within the W3C community. + +## Representing formal decisions + +When communicating a formal decision by the elected body you are a member of: + +- Express clearly what was decided and what was not decided. +- Share the intended message with the rest of the elected body you are a member of, with time for them to review and comment on the message before it is released. +- If time is limited because the elected body needs to respond urgently, a minimum review period of 24 hours plus review by the Chair(s) of the elected body is required. + +When discussing a decision made by the elected body you are a member of: + +- Be respectful about the decision, even if you did not support the consensus of the elected body. +- Be respectful of all points of view, even those that did not gain consensus. + +When discussing a matter that has not reached a conclusion: + +- Be clear that the discussion is ongoing and has not reached a conclusion. +- Make it clear when feedback and comments are wanted, and let people know how to do so. +- Share the intended message with the rest of the elected body you are a member of before you send it. + +### Revision History + +- 2020-09-03: Document becomes operational. +- 2020-09-02: Document created. From 21a8a9daada3c9b3b6ea4481740ee778850ebd80 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 10:46:01 +0100 Subject: [PATCH 018/225] rename .html to .md --- council/{council.html => council.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename council/{council.html => council.md} (100%) diff --git a/council/council.html b/council/council.md similarity index 100% rename from council/council.html rename to council/council.md From 0e958325516fe06418d3cadb47a16dcbdfab9f4f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 14:29:34 +0100 Subject: [PATCH 019/225] convert to md --- council/council.md | 511 ++++++++++++++------------------------------- 1 file changed, 153 insertions(+), 358 deletions(-) diff --git a/council/council.md b/council/council.md index 48dfa2c8d..2e9dcad90 100644 --- a/council/council.md +++ b/council/council.md @@ -1,359 +1,164 @@ - - - - -Formal Objections & W3C Council - - - - - - - - - - - - -
    -

    This document supplements the Process Document by providing best practices to resolve and decide Formal Objections.

    - -

    In this document, resolving a Formal Objection means finding a solution that has no objections. Deciding means +--- +title: Formal Objections & W3C Council +toc: true +--- + +This document supplements the Process Document by providing best practices to resolve and decide Formal Objections.

    + +

    In this document, resolving a Formal Objection means finding a solution that has no objections. Deciding means giving a yes/no answer to the question of whether an objection should be overruled (i.e., no) or sustained (i.e., yes). -

    +

    -

    Cases that warrant a W3C Council

    +## [Cases that warrant a W3C Council](#council) -

    W3C aims to make decisions by consensus. If there are differences of opinions, groups work to understand different points of view and reach agreement, - either by compromise, or by the force of some argument. When that is working well, Formal Objections are rare. -

    +W3C aims to make decisions by consensus. If there are differences of opinions, groups work to understand different points of view and reach agreement, either by compromise, or by the force of some argument. When that is working well, Formal Objections are rare. -

    W3C has substantial formal and informal processes to achieve consensus. The technical development process that results in W3C Recommendations requires that - raised issues be addressed by Working Groups. It is a rare event that an issue gets to the W3C Council's desk, and this only occurs after the relevant Working Group has thoroughly assessed all points of view. -

    - -

    Similarly, most Working Group Charters are openly developed in Github. Advance Notices inform the community when there is a new Charter to look at, - the Charter development process is open for people to raise issues and there is a fair effort to resolve issues prior to raising a Formal Objection. -

    +W3C has substantial formal and informal processes to achieve consensus. The technical development process that results in W3C Recommendations requires that raised issues be addressed by Working Groups. It is a rare event that an issue gets to the W3C Council's desk, and this only occurs after the relevant Working Group has thoroughly assessed all points of view. + +Similarly, most Working Group Charters are openly developed in Github. Advance Notices inform the community when there is a new Charter to look at, the Charter development process is open for people to raise issues and there is a fair effort to resolve issues prior to raising a Formal Objection. + +The fact that Formal Objections should be rare does not de-legitimize them. On some issues there are legitimate differences of opinion that require higher review. Some topics do not lend themselves to compromise, they are inherently yes/no decisions. It could be hard to find common ground. + +Nonetheless, the fact that the process is oriented towards consensus implies that before an objection gets higher review there already has been significant work on the issue. There is generally clarity on what the W3C decision was (that is being objected to). The objector, in trying to reverse the decision, has generally pulled together their best arguments and brought them to the group. The fact that so much work should be accomplished prior to higher review should make it easier to decide a Formal Objection. + +## [The Team, the W3C Council, and different types of objections](#objection-types) + +The Team has the responsibility to try to resolve a Formal Objection, or to come up with an analysis that might be used by the W3C Council in deciding a Formal Objection. The Team takes the early steps in processing Formal Objections. + +There are different types of Formal Objections and W3C needs to make sure they are all handled properly. Here are some interesting cases: + +1. There is a Formal Objection to a decision in a Working Group. The Team as a neutral bystander attempts to resolve the objection. If it succeeds, W3C takes the path recommended by the Team. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides. +2. The Team proposes a Charter to the W3C Advisory Committee and there are objections. The Team attempts to resolve the objection even though they are not a neutral bystander. If it succeeds, W3C takes the recommended path. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides. +3. The Advisory Board (AB) or Technical Architecture Group (TAG) make a decision (e.g., on a process issue, or in a Statement emanating from a TAG finding) and there are objections. + +It is important that even though the Team is an interested party in [case 2](#case-2), and the AB or TAG could be interested parties in [case 3](), the overall process must provide the objectivity and transparency to give the W3C Community the confidence that such cases are handled fairly. + +## [Processing of Formal Objections](#processing-of-formal-objections) + +All Formal Objections are made in response to a decision. Decisions are typically made by a Working Group as part of the Technical Report Development Process or by the Team as part of chartering a new group. + +Since W3C operates by consensus, it is always better if there can be a consensus between the group that made the original decision and the objector. The first step in processing a formal objection is for the Team to see if it can find a consensus. Even though that presumably has happened already in the Working Group, a new set of eyes might find new paths to resolution. If resolution succeeds, then that resolution becomes the new decision. If that is not successful, the Team prepares a detailed report with an analysis of the decision, objection, and its attempt to find a consensus. That report may also contain a recommendation to favor either the decision or the objection. + +This report is then sent to the W3C Council, to the deciders, and to the objectors. The W3C Council, like the Team before it, may try to find a consensus path forward. Otherwise, the W3C Council uses input from the report, the deciders, and objectors to either overrule the objection (in which case the original decision is in force), or to sustain the objection (in which case the original decision is vacated). The W3C Council also writes a report explaining their decision, which may be based on the Team's report. + +### [Team attempts to resolve Formal Objections](#team-fo) + +When a Formal Objection is raised, the Team assigns someone to attempt to resolve the Formal Objection. That assignee is expected to follow the best practices below. + +Within the bounds set by the Process, the Team decides how long the assignee has to attempt resolution and to write the report before the decision will be brought to a W3C Council. It is important that not too much time is spent in trying to resolve irreconcilable differences. Appropriate timing will depend on the complexity of the issue, and on the cooperation of the objector(s) and decider(s). + +The assignee should be well versed in the topic at hand. The assignee could be the Team Contact for the relevant Working Group, the person that drafted the Charter that is being objected to, or another member of the Team who has familiarity with the situation. It is important that the assignee be perceived as unbiased with respect to the decision under review, and it is extremely important that they execute this task in a way that is as neutral and transparent as possible. + +The assignee works with all parties to explore whether there is a way to resolve the Formal Objection. If the assignee believes that they have succeeded then the assignee needs ample documentation that the objection is resolved. Resolution requires both the satisfaction of the objectors and ensuring that the proposed resolution does not itself have objectors. Here are some examples: + +- If the objectors no longer object to the original decision, then there must be written documentation that they are withdrawing their objection. +- If the resolution causes a change in a technical document, then there must be a Working Group call for consensus on the revised document to which there are no objections. +- If the resolution causes a change in a proposed charter, then all participants in the AC review of that charter must have had an opportunity to review the revised proposed charter, and not objected. + +See also: [Ongoing Team Attempts](https://www.w3.org/Member/wiki/DirectorFOdashboard#Team_is_attempting_to_find_consensus_or_not_ready_to_ask_a_Council) + +### [Publishing formal objections](#publishing-fos) + +Formal objections must be made public using [public-review-comments](https://lists.w3.org/Archives/Public/public-review-comments/), no later than when the relevant council is initiated. The team should publish formal objections as soon as reasonable within the 90 days investigation and mediation period, with some considerations including: + +- all Formal Objections must be published, even those that are expected to be — or have already been — withdrawn. +- the Formal Objection ought to be made public as soon as it is received if it needs to be discussed by a [W3C Group](https://www.w3.org/groups/). +- to avoid unproductive attention on members who file formal objections on easily resolved matters such as charter durations and the like, the Team should anonymize such formal objections as a matter of routine. +- If there are multiple Formal Objections to the same decision or to the same AC Review, the Team should make them all public at the same time, to avoid attracting unwarranted unbalanced media attention to a single objector among several. For the same reason, if some formal objections are already public — for instance, if the objector made it public themselves — the Team should make any other formal objection to the same decision or to the same AC Review public without delay. + +To avoid leaving people wondering what happened, the Team should post a response to the announcement of the formal objection, indicating the resolution of the formal objection, such as overruled or withdrawn, and giving a quick summary as to why. + +## [Referral to W3C Council](#referral) -

    The fact that Formal Objections should be rare does not de-legitimize them. On some issues there are legitimate differences of opinion - that require higher review. Some topics do not lend themselves to compromise, they are inherently yes/no decisions. It could be hard to find common ground. -

    +If resolution is not possible in the allocated time frame, the assignee must refer the Formal Objection to the W3C Council for decision. The steps for that are as follows: + +- The assignee writes a report for the W3C Council summarizing the decision and the objection. -

    Nonetheless, the fact that the process is oriented towards consensus implies that before an objection gets higher review there already has been significant work on the issue. There is generally clarity on what the W3C decision was (that is being objected to). - The objector, in trying to reverse the decision, has generally pulled together their best arguments and brought them to the group. - The fact that so much work should be accomplished prior to higher review should make it easier to decide a Formal Objection. -

    - -

    The Team, the W3C Council, and different types of objections

    -

    The Team has the responsibility to try to resolve a Formal Objection, or to come up with an analysis that might be used by the W3C Council - in deciding a Formal Objection. The Team takes the early steps in processing Formal Objections. -

    -

    There are different types of Formal Objections and W3C needs to make sure they are all handled properly. - Here are some interesting cases: -

    -
      -
    1. There is a Formal Objection to a decision in a Working Group. - The Team as a neutral bystander attempts to resolve the objection. - If it succeeds, W3C takes the path recommended by the Team. - If it fails, the Team prepares a report for the W3C Council. - The W3C Council decides.

    2. -
    3. The Team proposes a Charter to the W3C Advisory Committee and there are objections. - The Team attempts to resolve the objection even though they are not a neutral bystander. - If it succeeds, W3C takes the recommended path. - If it fails, the Team prepares a report for the W3C Council. - The W3C Council decides.

    4. -
    5. The Advisory Board (AB) or Technical Architecture Group (TAG) make a decision (e.g., on a process issue, or in a Statement emanating from a TAG finding) and there are objections.

    6. -
    - -

    It is important that even though the Team is an interested party in case 2, and the AB or TAG could be interested parties in case 3, - the overall process must provide the objectivity and transparency to give the W3C Community the confidence that such cases are handled fairly.

    - - -

    Processing of Formal Objections

    -

    All Formal Objections are made in response to a decision. Decisions are typically made by a Working Group as part of the Technical Report Development Process or - by the Team as part of chartering a new group. -

    - -

    Since W3C operates by consensus, it is always better if there can be a consensus between the group that made the original decision and the objector. - The first step in processing a formal objection is for the Team to see if it can find a consensus. - Even though that presumably has happened already in the Working Group, a new set of eyes might find new paths to resolution. - If resolution succeeds, then that resolution becomes the new decision. - If that is not successful, the Team prepares a detailed report with an analysis of the decision, objection, and its attempt to find a consensus. - That report may also contain a recommendation to favor either the decision or the objection. -

    + - The document is typically public. + - If there are limited portions of the document which are confidential, there may be pointers to a separate confidential document. These may be summarized in the main document without compromising confidential information. + - The document should have a section in which both points of view are fairly expressed. + - The document should include a list of who the objectors are. If that list is confidential, it may be in the separate document. + - The document should list attempts to resolve the objection and why they failed. + - The document may include the assignee's recommendations and rationale whether to sustain or overrule the objection. +- The report should be available for review by the relevant groups and objectors. -

    This report is then sent to the W3C Council, to the deciders, and to the objectors. - The W3C Council, like the Team before it, may try to find a consensus path forward. - Otherwise, the W3C Council uses input from the report, the deciders, and objectors to either overrule the objection (in which case the original decision is in force), or - to sustain the objection (in which case the original decision is vacated). - The W3C Council also writes a report explaining their decision, which may be based on the Team's report. -

    - -

    Team attempts to resolve Formal Objections

    -

    When a Formal Objection is raised, the Team assigns someone to attempt to resolve the Formal Objection. - That assignee is expected to follow the best practices below. -

    - -

    Within the bounds set by the Process, the Team decides how long the assignee has to attempt resolution and to write the report before the decision will be brought to a W3C Council. - It is important that not too much time is spent in trying to resolve irreconcilable differences. - Appropriate timing will depend on the complexity of the issue, and on the cooperation of the objector(s) and decider(s). -

    + - If any participant feels that their viewpoint is not fairly represented, a limited time effort should be made to get all relevant information into the document. + - If at the end of the allocated time the Team determines that it is not possible to get agreement on the summary document, then the Team publishes their summary and notes which participants believe that it is not a fair summary. Those participants may write up their own viewpoints. + - The assignee should indicate an explicit team contact (which can be the assignee) for comments on the draft document. +- The W3C Council determines who will rule on this objection and who will chair the Council. -

    The assignee should be well versed in the topic at hand. The assignee could be the Team Contact for the relevant Working Group, the person that drafted the Charter - that is being objected to, or another member of the Team who has familiarity with the situation. - It is important that the assignee be perceived as unbiased with respect to the decision under review, and it is extremely important that they execute this task in a way that is - as neutral and transparent as possible. -

    + - See [Council Participation, Dismissal, and Renunciation](/policies/process/#council-participation) and [Council Chairing](/policies/process/#council-chairing). + - Every person serving on the W3C Council is expected to be sufficiently knowledgeable that they feel comfortable with the decision of the W3C Council. The breadth of the W3C Council membership, and therefore the participation of each of its members, is key to the Council’s ability to provide an appropriate balance of viewpoints. +- In extraordinary circumstances, the W3C Council may vote to [delegate](/policies/process/#council-delegation) or [short-circuit](/policies/process/#council-short-circuit) its decision. +- The W3C Council [deliberates and reaches a decision](/policies/process/#council-deliberations) to sustain or overrule the original decision. -

    The assignee works with all parties to explore whether there is a way to resolve the Formal Objection. - If the assignee believes that they have succeeded then the assignee needs ample documentation that the objection is resolved. - Resolution requires both the satisfaction of the objectors and ensuring that the proposed resolution does not itself have objectors. Here are some examples:

    - -
      -
    • If the objectors no longer object to the original decision, then there must be written documentation that they are withdrawing their objection.

    • -
    • If the resolution causes a change in a technical document, then there must be a Working Group call for consensus on the revised document to which there are no objections.

    • -
    • If the resolution causes a change in a proposed charter, then all participants in the AC review of that charter must have had an opportunity to review the revised proposed charter, and not objected.

    • -
    - -

    See also: Ongoing Team Attempts

    - -

    Publishing formal objections

    - -

    - Formal objections must be made public using public-review-comments, no later than when the - relevant council is initiated. The team should publish formal objections as soon as - reasonable within the 90 days investigation and mediation period, with some - considerations including: -

    -
      -
    • all Formal Objections must be published, even those that are expected to - be — or have already been — withdrawn. -
    • -
    • the Formal Objection ought to be made public as soon as it is - received if it needs to be discussed by a W3C Group. -
    • -
    • - to avoid unproductive attention on members who file formal objections - on easily resolved matters such as charter durations and the like, the Team should - anonymize such formal objections as a matter of routine. -
    • -
    • - If there are multiple Formal Objections to the same decision or to the same AC Review, - the Team should make them all public at the same time, to avoid attracting unwarranted - unbalanced media attention to a single objector among several. For the same reason, if - some formal objections are already public — for instance, if the objector made it - public themselves — the Team should make any other formal objection to the same decision or - to the same AC Review public without delay. -
    • -
    - -

    - To avoid leaving people wondering what happened, the Team should post a response to the - announcement of the formal objection, indicating the resolution of the formal objection, - such as overruled or withdrawn, and giving a quick summary as to why. -

    - -

    Referral to W3C Council

    - -

    If resolution is not possible in the allocated time frame, the assignee must refer the Formal Objection to the W3C Council for decision. The steps for that are as follows:

    -
      -
    • -

      The assignee writes a report for the W3C Council summarizing the decision and the objection.

      -
        -
      • The document is typically public.

      • -
      • If there are limited portions of the document which are confidential, there may be pointers to a separate confidential document. - These may be summarized in the main document without compromising confidential information.

      • -
      • The document should have a section in which both points of view are fairly expressed.

      • -
      • The document should include a list of who the objectors are. If that list is confidential, it may be in the separate document.

      • -
      • The document should list attempts to resolve the objection and why they failed.

      • -
      • The document may include the assignee's recommendations and rationale whether to sustain or overrule the objection.

      • -
      -
    • -
    • -

      The report should be available for review by the relevant groups and objectors.

      -
        -
      • If any participant feels that their viewpoint is not fairly represented, a limited time effort should be made to get all relevant information into the document.

      • -
      • If at the end of the allocated time the Team determines that it is not possible to get agreement on the summary document, then the Team publishes - their summary and notes which participants believe that it is not a fair summary. Those participants may write up their own viewpoints.

      • -
      • The assignee should indicate an explicit team contact (which can be the assignee) for comments on the draft document.

      • -
      -
    • -
    • -

      The W3C Council determines who will rule on this objection and who will chair the Council.

      -
        -
      • See Council Participation, Dismissal, and Renunciation and - Council Chairing.

      • -
      • Every person serving on the W3C Council is expected to be sufficiently knowledgeable that they feel comfortable with the decision of the W3C Council. - The breadth of the W3C Council membership, and therefore the participation of each of its members, is key to the Council’s ability to provide an appropriate - balance of viewpoints.

      • -
      -
    • -
    • -

      In extraordinary circumstances, the W3C Council may vote to delegate or - short-circuit its decision.

      -
    • -
    • -

      The W3C Council deliberates and reaches a decision to sustain or overrule the original decision.

      -
        -
      • If the W3C Council members deem that the written summaries are sufficient, they are not required to discuss with participants further, although they may - do so if they wish. They may consult with deciders and objectors if they wish. See thoroughness and fairness below.

      • -
      • Once consultations are completed, the Chair of the W3C Council assesses the consensus of the Council, or if consensus cannot be found, - calls for a vote of the W3C Council to sustain or overrule the Formal Objection.

      • -
      • If there is disagreement within the Council - about the meaning of those sections of the Process - that govern the Council itself, - in a way that interferes with its ability to discuss the substance of the case, - the Chair should try to resolve this by consensus, - and should seek advice from the Team contact on how to interpret the Process. - If consensus cannot be found, - the chair should make a determination, - possibly through a vote, - to allow the deliberations to move on. - Any such point of procedural contention should be covered - in the Council Report.

      • -
      • The W3C Council publishes its decision and its rationale.

      • -
      • Whether the decision is to sustain or overrule, the W3C Council may include additional guidance for any of the participants involved.

      • -
      • If the objection is sustained, the relevant group (i.e., Working Group, or Team developing a charter) may resume work to develop a different proposal for their document.

      • -
      -
    • -
    -

    See also: Ongoing Referrals to W3C Council

    - -

    The Nature of W3C Council deliberations

    - -

    I. Considerations

    - -

    Each Formal Objection referred to the W3C Council has unique aspects, and the W3C Council needs the flexibility to choose how it reaches a decision. - In studying a particular Formal Objection, the W3C Council should always balance several factors:

    -
      -
    • Making the correct decision for the Web.

    • -
    • Speed of decision making: that W3C does not get mired in objection processing.

    • -
    • Understanding and empathy for the objector(s).

    • -
    • Assuring that objection processing does not become a means for all decisions to be centralized at W3C.

    • -
    • Avoiding micromanagement.

    • -
    • Treating all objectors consistently irrespective of who the objector might be.

    • -
    • Workload. If processing each Formal Objection results in significant work for a very large Council, then - the Council will not have time to process the workload and the W3C Council design will not scale.

    • -
    - -

    II. Convincing the W3C Council

    - -

    The nature of a Formal Objection is that a Decision has been made and someone has raised a Formal Objection to that Decision. - The W3C Council is required by the Process to review the Decision, and choose whether to overrule the objection or sustain the objection. - This section addresses what information the Council has to consider.

    - -

    In any individual objection, the W3C Council is empowered to find any resolution to the objection. In addition, finding a consensus that is - supported by all is always preferred. Nothing in this discussion precludes such an approach or forces an adversarial judicial proceeding. - Nonetheless, there should be a clear expectation about the starting point for Council deliberations.

    - -

    Objectors should not be looking at the W3C Council to come up with new arguments to support their point of view. - For example, if objectors have vague arguments of the form ”this is bad for privacy” or “this is bad for business”, - they should not expect the Council to do the research to demonstrate whether their vague arguments are correct. - Rather, they need to bring forward arguments which explain why something is bad for privacy and/or business—and then the Council evaluates their claims. - The objector is responsible for making a compelling case to help the Council understand their concerns, and should provide evidence and references to that end.

    - -

    An important role for the Team assignee is to anticipate questions the W3C Council is likely to have during its - deliberations about the Decision and the Objection, and to work with the objector(s) and deciders to provide that information in the Team Report.

    - -

    Nevertheless, the W3C Council should not dismiss an Objection merely because the objector or the Team did not provide incontrovertible proof. - The objectors need to convince - the Council that, in the best interests of the Web, their objection should overturn the decision. - Still, it is imprudent for objectors or deciders to count on the Council doing their homework for them, as insufficient documentation can lead - to the Council failing to see the point.

    - -

    The W3C Council is responsible for fully understanding all sides of the argument and making an informed decision. - If the Council sees potential merit in the claims made on either side, but needs more information to be sure, it may investigate - (or ask the Team to investigate) until its members know enough to responsibly decide. During this thorough analysis, the Council may learn - new information, which might bear on the decision. - But that new information should be incidental to the analysis—the responsibility to make a convincing objection remains on the objectors.

    - -

    Placing the burden of convincing on the objectors is supported by several considerations:

    - -
      -
    • Speed. If the W3C Council begins to look for additional new arguments, they are likely to take longer in their assessment.

    • -
    • Avoiding centralization. If every objection results in the Council accepting the burden of convincing on themselves, inevitably - it will cause more stakeholders to bring topics to the Council and ultimately begin to centralize decisions.

    • -
    • Treating objectors consistently. If the Council begins to accept the burden of convincing on themselves for some Objections, - then to be consistent, they will need to accept the burden for all objectors. - That would be a tremendous expansion of scope for Formal Objections.

    • -
    • Workload. If the W3C Council begins to accept the burden of convincing on themselves, that would considerably add workload to the Council.

    • -
    - -

    III. W3C Council Reports

    -

    The W3C Council Decision Report section of the Process covers what information the Council is expected to provide in its report. Fundamentally, the Council needs to either:

    -
      -
    • Cleanly overrule the Objection and allow the Decision to stand.

    • -
    • Clearly sustain the Objection and require the responsible parties to address the Objection.

    • -
    - -

    - Overruling a Formal Objection does not imply that there is zero validity to the Objection, only that the claims are insufficient to overturn this decision. - To the extent that there is some validity to the claims of the objectors, a W3C Council decision to overrule the Objection does not give the deciders authority to - ignore these claims further in the development. It is therefore useful for the Council to distinguish between claims of the objector that they find to be - without merit, and those that are merely insufficient to justify overturning the decision but are nonetheless legitimate concerns that should be investigated - and potentially addressed later in the process. -

    + - If the W3C Council members deem that the written summaries are sufficient, they are not required to discuss with participants further, although they may do so if they wish. They may consult with deciders and objectors if they wish. See thoroughness and fairness below. + - Once consultations are completed, the Chair of the W3C Council assesses the consensus of the Council, or if consensus cannot be found, calls for a vote of the W3C Council to sustain or overrule the Formal Objection. + - If there is disagreement within the Council about the meaning of those sections of the Process that govern the Council itself, in a way that interferes with its ability to discuss the substance of the case, the Chair should try to resolve this by consensus, and should seek advice from the Team contact on how to interpret the Process. If consensus cannot be found, the chair should make a determination, possibly through a vote, to allow the deliberations to move on. Any such point of procedural contention should be covered in the Council Report. + - The W3C Council [publishes its decision and its rationale](/policies/process/#council-decision). + - Whether the decision is to sustain or overrule, the W3C Council may include additional guidance for any of the participants involved. + - If the objection is sustained, the relevant group (i.e., Working Group, or Team developing a charter) may resume work to develop a different proposal for their document. -

    - When an Objection is sustained, the W3C Council can suggest an approach that it believes could repair the Objection, but cannot make any dictates. - The W3C Council is not expected to write charters or technical reports; sustaining an Objection leaves the design of a new way forward to the responsible parties. -

    +See also: [Ongoing Referrals to W3C Council](https://www.w3.org/Guide/council/council#referral) -

    - While providing guidance beyond a simple sustain/overrule decision increases the workload of the W3C Council for an individual Objection, - helping the community avoid predictable pitfalls reduces the amount of wasted effort both for the community and for future W3C Councils. -

    +## [The Nature of W3C Council deliberations](#nature-of-council-deliberations) -

    +### [I. Considerations](#considerations) -

    - Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. -

    +Each Formal Objection referred to the W3C Council has unique aspects, and the W3C Council needs the flexibility to choose how it reaches a decision. In studying a particular Formal Objection, the W3C Council should always balance several factors: + +- Making the correct decision for the Web. +- Speed of decision making: that W3C does not get mired in objection processing. +- Understanding and empathy for the objector(s). +- Assuring that objection processing does not become a means for all decisions to be centralized at W3C. +- Avoiding micromanagement. +- Treating all objectors consistently irrespective of who the objector might be. +- Workload. If processing each Formal Objection results in significant work for a very large Council, then the Council will not have time to process the workload and the W3C Council design will not scale. + +### [II. Convincing the W3C Council](#convincing-the-council) + +The nature of a Formal Objection is that a Decision has been made and someone has raised a Formal Objection to that Decision. The W3C Council is required by the Process to review the Decision, and choose whether to overrule the objection or sustain the objection. This section addresses what information the Council has to consider. + +In any individual objection, the W3C Council is empowered to find any resolution to the objection. In addition, finding a consensus that is supported by all is always preferred. Nothing in this discussion precludes such an approach or forces an adversarial judicial proceeding. Nonetheless, there should be a clear expectation about the starting point for Council deliberations. + +Objectors should not be looking at the W3C Council to come up with new arguments to support their point of view. For example, if objectors have vague arguments of the form ”this is bad for privacy” or “this is bad for business”, they should not expect the Council to do the research to demonstrate whether their vague arguments are correct. Rather, they need to bring forward arguments which explain why something is bad for privacy and/or business—and then the Council evaluates their claims. The objector is responsible for making a compelling case to help the Council understand their concerns, and should provide evidence and references to that end. + +An important role for the Team assignee is to anticipate questions the W3C Council is likely to have during its deliberations about the Decision and the Objection, and to work with the objector(s) and deciders to provide that information in the Team Report. + +Nevertheless, the W3C Council should not dismiss an Objection merely because the objector or the Team did not provide incontrovertible proof. The objectors need to *convince the Council that, in the best interests of the Web, their objection should overturn the decision*. Still, it is imprudent for objectors or deciders to count on the Council doing their homework for them, as insufficient documentation can lead to the Council failing to see the point. + +The W3C Council is responsible for fully understanding all sides of the argument and making an informed decision. If the Council sees potential merit in the claims made on either side, but needs more information to be sure, it may investigate (or ask the Team to investigate) until its members know enough to responsibly decide. During this thorough analysis, the Council may learn new information, which might bear on the decision. But that new information should be incidental to the analysis—the responsibility to make a convincing objection remains on the objectors. + +Placing the burden of convincing on the objectors is supported by several considerations: -

    I. Thoroughness

    +- Speed. If the W3C Council begins to look for additional new arguments, they are likely to take longer in their assessment. +- Avoiding centralization. If every objection results in the Council accepting the burden of convincing on themselves, inevitably it will cause more stakeholders to bring topics to the Council and ultimately begin to centralize decisions. +- Treating objectors consistently. If the Council begins to accept the burden of convincing on themselves for some Objections, then to be consistent, they will need to accept the burden for all objectors. That would be a tremendous expansion of scope for Formal Objections. +- Workload. If the W3C Council begins to accept the burden of convincing on themselves, that would considerably add workload to the Council. -

    This includes:

    +### [III. W3C Council Reports](#council-report) + +The W3C Council Decision Report section of the Process covers what information the Council is expected to provide in its report. Fundamentally, the Council needs to either: + +- Cleanly overrule the Objection and allow the Decision to stand. +- Clearly sustain the Objection and require the responsible parties to address the Objection. + +Overruling a Formal Objection does not imply that there is zero validity to the Objection, only that the claims are insufficient to overturn this decision. To the extent that there is some validity to the claims of the objectors, a W3C Council decision to overrule the Objection does not give the deciders authority to ignore these claims further in the development. It is therefore useful for the Council to distinguish between claims of the objector that they find to be without merit, and those that are merely insufficient to justify overturning the decision but are nonetheless legitimate concerns that should be investigated and potentially addressed later in the process. + +When an Objection is sustained, the W3C Council can suggest an approach that it believes could repair the Objection, but cannot make any dictates. The W3C Council is not expected to write charters or technical reports; sustaining an Objection leaves the design of a new way forward to the responsible parties. + +While providing guidance beyond a simple sustain/overrule decision increases the workload of the W3C Council for an individual Objection, helping the community avoid predictable pitfalls reduces the amount of wasted effort both for the community and for future W3C Councils. + + +Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. + +## [Best Practices](#best-practices) + +Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. + +### [I. Thoroughness](#thoroughness) + +This includes:
    Understanding all sides of the argument
    @@ -373,8 +178,9 @@ wisdom of the W3C Group Chairs and other collaborators.

    legitimate points raised by the party that is not favored in the ruling, but explain why they are not decisive.

    -

    II. Fairness

    -

    This includes:

    +### [II. Fairness](#fairness) + +This includes:
    Balance and depth
    @@ -405,9 +211,9 @@ wisdom of the W3C Group Chairs and other collaborators.

    into consideration in terms of the best solution for the Web.

    -

    III. Communications

    +### [III. Communications](#communications) -

    This includes:

    +This includes:
    Publication of W3C Council decisions
    @@ -428,17 +234,6 @@ wisdom of the W3C Group Chairs and other collaborators.

    such communications take place and the process continues to move forward.

    +### Revision History -

    Revision History

    -
      -
    • 2023-03-30: Document created based on a draft by the AB.
    • -
    - -
    - -
    -

    Owned by @w3c/tilt - and feedback is welcome on GitHub

    - - - +- 2023-03-30: Document created based on a draft by the [AB](https://www.w3.org/2002/ab/). \ No newline at end of file From 623aa11afae1229ff5be9701408eb4860489b37a Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 15:34:34 +0100 Subject: [PATCH 020/225] Rename from .html to .md --- chair/{buddy.html => buddy.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename chair/{buddy.html => buddy.md} (100%) diff --git a/chair/buddy.html b/chair/buddy.md similarity index 100% rename from chair/buddy.html rename to chair/buddy.md From 80f25d623d04217c141e09d2a48b11e535f5d2a8 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 15:48:41 +0100 Subject: [PATCH 021/225] Convert to markdown --- chair/buddy.md | 134 +++++++++++++++++++------------------------------ 1 file changed, 51 insertions(+), 83 deletions(-) diff --git a/chair/buddy.md b/chair/buddy.md index 6ff7c05bc..af78b8434 100644 --- a/chair/buddy.md +++ b/chair/buddy.md @@ -1,85 +1,53 @@ - - - - -W3C Chair Buddy System - - - - - - +--- +title: W3C Chair Buddy System +toc: true +--- -
    -

    Related Resources

    - -
    +The [Working Group effectiveness Task Force](https://github.com/w3c/wg-effectiveness) helped establish a Chair Buddy System by which experienced Chairs can volunteer as buddy-mentors to help buddy-mentees Chairs. -

    The Working Group effectiveness Task Force helped establish a Chair Buddy System by which experienced Chairs can volunteer as buddy-mentors to help buddy-mentees Chairs.

    -

    Interested parties should subscribe to chairbuddies@w3.org (Member-only archive). Chairs have access to their contact information via the Chairs group.

    -

    Principles

    -
      -
    • This program is under the responsibility of the W3C Project Lead.
    • -
    • W3C Chairs self-declare as Mentors or Mentees by writing to chairbuddies@w3.org. - -
    • -
    • The W3C Project Lead proceeds to pairing those who request to have a buddy, with those who volunteer to be a buddy.
    • -
    -

    Buddy-Mentors

    -

    Thank-you for agreeing to be a W3C Chair Buddy! You should have been assigned your buddy-mentee and received their details from the W3C Team. If not, please ask the W3C Project Lead. Here are some resources and guidelines for helping you get started with being a buddy-mentor.

    -
      -
    • Email your buddy-mentee and introduce yourself! It helps if you give some details on your chair experience, some general W3C experience, and what groups you have interests in.
    • -
    • Arrange an initial meeting with your buddy-mentee. This can be a teleconference, or face-to-face if you're lucky to live in the same area or are participating in the same meeting.
    • -
    • Buddy meetings can be managed however you wish, some guidelines are given below: -
        -
      • Ask questions such as "how long have you been chairing?", "what is the size of your group?", "how many chairs are there?", "what are you group working practices?", "how do you manage and conduct meetings?", "how many documents and editors do you have?", "what are your document timelines?", "tell me about your editors / participants", "where are your participants based?".
      • -
      • Finding out as much as you can about your buddy-mentee will allow you to give the best advice!
      • -
      -
    • -
    • Try to speak to your buddy-mentee every quarter. The job of arranging meetings should be with the buddy-mentee, but it doesn't hurt to send them a quick email every so often!
    • -
    -

    Self-declared Buddy-Mentors:

    - -

    Buddy-Mentees

    -

    Thank-you for joining the W3C Chair Buddy system! As a buddy-mentee you should have received details of your buddy. If you have not please ask the W3C Project Lead. Here are some guidelines for being a buddy-mentee.

    -
      -
    • Email your buddy-mentor and introduce yourself! Give details on the group you chair, whether you have a co-chair, and some quick details on the specs you're working on and the size of your group.
    • -
    • Arrange an initial meeting with your buddy-mentor. This can be a teleconference, or face-to-face if you're lucky to live in the same area or are participating in the same meeting.
    • -
    • Buddy meetings can be managed however you wish, some guidelines are given below: -
        -
      • You should be giving your buddy-mentor as much information as possible about your current chairing situation, this will help them give you the best advice!
      • -
      • You should also bring with you a list of your own questions, here are some examples: "how do you manage consensus when one or few people are blocking?", "how do you manage meetings when participants are so distributed?", "how can I help my editors get to work?", etc.
      • -
      -
    • -
    • Try to speak to your buddy-mentor every quarter, but you may speak to them more infrequently or frequently depending on what works for you and your buddy-mentor. In yuor initial meeting try to discuss a schedule for meetings (even if you decide to do ad-hoc meetings) then arrange the meetings by sending calendar invites (or another method of your choosing).
    • -
    • It's up to you to arrange these meetings (buddy-mentors may have a few mentees, so it's best for buddy-mentees to arrange meetings).
    • -
    -

    Self-declared Buddy-Mentees:

    -
      -
    • Karen Coyle (now associated with Léonie Watson)
    • -
    • Wendy Reid
    • -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies@w3.org) ([Member-only archive](https://lists.w3.org/Archives/Member/member-chairbuddies/)[). Chairs have access to their contact information via the]() [Chairs group](https://www.w3.org/2000/09/dbwg/details?group=31972). + +## Principles + +- This program is under the responsibility of the [W3C Project Lead](https://www.w3.org/staff/project/). +- W3C Chairs self-declare as Mentors or Mentees by writing to [chairbuddies@w3.org](mailto:chairbuddies@w3.org). + + - Ideally, they add their names to this page by [editing it on GitHub](https://github.com/w3c/Guide/edit/main/chair/buddy.md). +- The W3C Project Lead proceeds to pairing those who request to have a buddy, with those who volunteer to be a buddy. + +## Buddy-Mentors + +Thank-you for agreeing to be a W3C Chair Buddy! You should have been assigned your buddy-mentee and received their details from the W3C Team. If not, please ask the W3C Project Lead. Here are some resources and guidelines for helping you get started with being a buddy-mentor. + +- Email your buddy-mentee and introduce yourself! It helps if you give some details on your chair experience, some general W3C experience, and what groups you have interests in. +- Arrange an initial meeting with your buddy-mentee. This can be a teleconference, or face-to-face if you're lucky to live in the same area or are participating in the same meeting. +- Buddy meetings can be managed however you wish, some guidelines are given below: + + - Ask questions such as "how long have you been chairing?", "what is the size of your group?", "how many chairs are there?", "what are you group working practices?", "how do you manage and conduct meetings?", "how many documents and editors do you have?", "what are your document timelines?", "tell me about your editors / participants", "where are your participants based?". + - Finding out as much as you can about your buddy-mentee will allow you to give the best advice! +- Try to speak to your buddy-mentee every quarter. The job of arranging meetings should be with the buddy-mentee, but it doesn't hurt to send them a quick email every so often! + +Self-declared Buddy-Mentors: + +- [Anssi Kostiainen](https://github.com/anssiko) +- [Léonie Watson](https://github.com/ljwatson) +- [Charles Nevile](https://github.com/chaals) +- [Nigel Megitt](https://github.com/nigelmegitt) + +## Buddy-Mentees + +Thank-you for joining the W3C Chair Buddy system! As a buddy-mentee you should have received details of your buddy. If you have not please ask the W3C Project Lead. Here are some guidelines for being a buddy-mentee. + +- Email your buddy-mentor and introduce yourself! Give details on the group you chair, whether you have a co-chair, and some quick details on the specs you're working on and the size of your group. +- Arrange an initial meeting with your buddy-mentor. This can be a teleconference, or face-to-face if you're lucky to live in the same area or are participating in the same meeting. +- Buddy meetings can be managed however you wish, some guidelines are given below: + + - You should be giving your buddy-mentor as much information as possible about your current chairing situation, this will help them give you the best advice! + - You should also bring with you a list of your own questions, here are some examples: "how do you manage consensus when one or few people are blocking?", "how do you manage meetings when participants are so distributed?", "how can I help my editors get to work?", etc. +- Try to speak to your buddy-mentor every quarter, but you may speak to them more infrequently or frequently depending on what works for you and your buddy-mentor. In yuor initial meeting try to discuss a schedule for meetings (even if you decide to do ad-hoc meetings) then arrange the meetings by sending calendar invites (or another method of your choosing). +- It's up to you to arrange these meetings (buddy-mentors may have a few mentees, so it's best for buddy-mentees to arrange meetings). + +Self-declared Buddy-Mentees: + +- Karen Coyle (now associated with Léonie Watson) +- Wendy Reid From ceb028410f00fef9bf3ee14ed4e8b45c95ea4cb6 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 15:58:11 +0100 Subject: [PATCH 022/225] Rename from .html to .md --- chair/{role.html => role.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename chair/{role.html => role.md} (100%) diff --git a/chair/role.html b/chair/role.md similarity index 100% rename from chair/role.html rename to chair/role.md From c3f6923e4c0b6bb7b24adf414810be093111ac9f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 16:04:26 +0100 Subject: [PATCH 023/225] Convert to markdown --- chair/role.md | 225 +++++++++++++++++--------------------------------- 1 file changed, 74 insertions(+), 151 deletions(-) diff --git a/chair/role.md b/chair/role.md index aac8c1b37..94b05a9a3 100644 --- a/chair/role.md +++ b/chair/role.md @@ -1,151 +1,74 @@ - - - - -Chair roles - - - - - - - -
    -

    Related Resources

    - -
    - -

    -The W3C Team appoints (or re-appoints) a Chair (or more than one co-Chair) for every Working -Group and Interest Group ("Group"). The Chair's primary role is to -facilitate consensus-building among Group members. The Chair works together with - the W3C Staff Contact. Key roles of the Group -Chair are listed below. Additional information on the role of the -Group Chair is in the W3C Process -Document. -

    Chair Buddy System

    -

    The Working Group effectiveness Task Force helped establish a Chair Buddy System by which experienced buddy-mentors help buddy-mentees.

    -

    Interested parties should subscribe to chairbuddies@w3.org (Member-only archive) and visit the dedicated Chair Buddy System page.

    -

    Role of the Group Chair

    -

    Creates Group charter and convenes Group

    -
      -
    • Develops Group charter together with the Staff -Contact.
    • -
    • Is familiar with the W3C -Process, the W3C Code of Conduct, - the Antitrust and competition policy, -and Guidebook.
    • -
    • Convenes Group and ensures Group members oriented to W3C Process with assistance of Staff -Contact.
    • -
    • Schedules deliverables and sets milestones towards completion -of deliverables.
    • -
    • Appoints document editors. (NOTE: Editors are responsible for -ensuring that Group decisions are correctly reflected in Group -documents, and for maintaining an issue list.)
    • -
    • Proposes invited experts with assistance of Staff Contact (W3C -staff must be involved in decisions regarding inclusion/exclusion -of participants).  Makes sure that all participants have -filled out a call for participation and have disclosed their IPR in -accordance with W3C process.
    • -
    • (If there is a Co-chair) Establishes clear and close -coordination with Co-chair.
    • -
    -

    Coordinates with W3C Team and other W3C Working Groups as -needed

    -
      -
    • Maintains close coordination with W3C Staff -Contact.
    • -
    • Maintains coordination with assigned liaisons from other W3C -working groups.
    • -
    • Participates in the Chairs mailing list (archive) and attends Chairs -meetings.
      -the team contact should make sure the chair is in the -chairs group (should be managed automatically)
    • -
    • Works with the Communications Team and Staff Contact in preparing press release.
    • -
    • Communicates with the press, when necessary and appropriate, -and with prior coordination with the communication team, on behalf -of the group.
    • -
    • Ensures all participants have proper access to Group -data with assistance from Staff Contact.
    • -
    -

    Maintains Group Process & Organization

    -
      -
    • Solicits drafts, encourages participation.
    • -
    • Judges items in or out of scope for the Group.
    • -
    • Generally stays neutral in discussion but can participate in -technical discussions if announces in advance that will remove their -chair "hat" at that time.
    • -
    • Keeps Group's charter compliant with W3C Process, and initiates -charter update as needed.
    • -
    • Ensures participants abide by the terms and spirit of the - W3C Code of Conduct
    • -
    • Find suitable time slots for distributed meeting where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC). (see - also Organizing a distributed meeting ) and revisit those time slots - on a regular basis. -
    • -
    • Announces calls, meetings, events with appropriate advance time -and through proper channels.
    • -
    • Ensures minutes are taken and posted in due time.
    • -
    • Defines meeting agendas.
    • -
    • Maintains home page of Group using W3C authoring guidelines -(receives access privileges for doing that).
    • -
    • If it is necessary to take a vote, supervises voting and announces results, with -assistance of Staff Contact.
    • -
    • Resolve issues that motivated "No" votes (facilitate reaching -consensus).
    • -
    • Revises deliverables timeline as needed.
    • -
    -

    What to look for when choosing a chair

    -

    The following bullets based on suggestions from Joseph - Reagle

    -
      -
    • Experience in chairing similar groups, committees, and/or -conferences;
    • -
    • Previous participation or technical contributions in related -communities;
    • -
    • Ability to satisfy the time commitment (from you and/or your -organization/management);
    • -
    • Familiarity or willingness to learn W3C Process and -document formatting rules;
    • -
    • Familiarity with the W3C - Code of Conduct;
    • -
    • Ability to keep the Working Group "in Charter", both for -technical and IPR issues;
    • -
    • Ability (both actual and perceived by the Working Group -- -including potential competitors) to forge consensus fairly and -without bias from your affiliation/employer and, sometimes, even -your own technical positions.
    • -
    -
    -

    The team contact should -arrange for the Chair and the W3C Team to meet (by phone if necessary) to make sure -they're on the same wavelength about things like:

    -
      -
    • where the group's work fits into Web Architecture
    • -
    • where does it fit with other groups
    • -
    • testing, test suites ... generating tests as you come to -each
    • -
    • responsibility not just to the group -- working toward consensus -of the whole community
    • -
    • cost of delaying wider consensus - negotiating your reviews and -really getting in touch with people - versus time to market and specification relevance
    • -
    • formal objections, i.e. the tricky bits of W3C process
    • -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +--- +title: W3C Working/Interest Group Chair +toc: true +--- + +The [W3C Team](https://www.w3.org/Process#ref-for-team%E2%91%A2%E2%91%A6) appoints (or re-appoints) a Chair (or more than one co-Chair) for every Working Group and Interest Group ("Group"). The Chair's primary role is to facilitate [consensus](/policies/process/#Consensus)-building among Group members. The Chair works together with the W3C [Staff Contact](../teamcontact/role.html). Key roles of the Group Chair are listed below. Additional information on the role of the Group Chair is in the [W3C Process Document](/policies/process/#general-requirements). + +## Chair Buddy System + +The [Working Group effectiveness Task Force](https://github.com/w3c/wg-effectiveness) helped establish a Chair Buddy System by which experienced buddy-mentors help buddy-mentees. + +Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies@w3.org) ([Member-only archive](https://lists.w3.org/Archives/Member/member-chairbuddies/)) and visit the dedicated [Chair Buddy System page](buddy.html). + +## Role of the Group Chair + +### Creates Group charter and convenes Group + +- [Develops Group charter](/policies/process/#WGCharterDevelopment) together with the Staff Contact. +- Is familiar with the [W3C Process](/policies/process/), the [W3C Code of Conduct](/policies/code-of-conduct/), the [Antitrust and competition policy](/policies/antitrust/), and [Guidebook](/Guide). +- Convenes Group and ensures Group members oriented to [W3C Process](/policies/process/) *with assistance of Staff Contact.* +- Schedules deliverables and sets milestones towards completion of deliverables. +- Appoints document editors. (NOTE: [Editors](https://www.w3.org/2003/Editors/) are responsible for ensuring that Group decisions are correctly reflected in Group documents, and for maintaining an issue list.) +- Proposes invited experts *with assistance of Staff Contact* (W3C staff must be involved in decisions regarding inclusion/exclusion of participants). Makes sure that all participants have filled out a call for participation and have disclosed their IPR in accordance with W3C process. +- (If there is a Co-chair) Establishes clear and close coordination with Co-chair. + +### Coordinates with W3C Team and other W3C Working Groups as needed + +- Maintains close coordination with W3C Staff Contact*.* +- Maintains coordination with assigned liaisons from other W3C working groups. +- Participates in the Chairs mailing list ([archive](https://lists.w3.org/Archives/Member/chairs/)) and attends Chairs meetings. + + *the team contact should make sure the chair is in the* [*chairs group*](/admin/othergroups/31972/show) (should be managed automatically) +- Works with the Communications Team and Staff Contact in preparing press release. +- Communicates with the press, when necessary and appropriate, and with prior coordination with the communication team, on behalf of the group. +- *Ensures* all participants have proper access to Group data *with assistance from Staff Contact.* + +### Maintains Group Process & Organization + +- Solicits drafts, encourages participation. +- Judges items in or out of scope for the Group. +- Generally stays neutral in discussion but can participate in technical discussions if announces in advance that will remove their chair "hat" at that time. +- Keeps Group's charter compliant with W3C Process, and initiates charter update as needed. +- Ensures participants abide by the terms and spirit of the [W3C Code of Conduct](/policies/code-of-conduct/) +- Find suitable time slots for distributed meeting where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC). (see also [Organizing a distributed meeting](../meetings/organize.html) ) and revisit those time slots on a regular basis. +- Announces calls, meetings, events with appropriate advance time and through proper channels. +- Ensures minutes are taken and posted in due time. +- Defines meeting agendas. +- Maintains home page of Group using W3C authoring guidelines (receives access privileges for doing that). +- If it is necessary to take a vote, supervises voting and announces results, *with assistance of Staff Contact.* +- Resolve issues that motivated "No" votes (facilitate reaching consensus). +- Revises deliverables timeline as needed. + +### What to look for when choosing a chair + +*The following bullets based on suggestions from [Joseph Reagle](https://www.w3.org/People/Reagle/)* + +- Experience in chairing similar groups, committees, and/or conferences; +- Previous participation or technical contributions in related communities; +- Ability to satisfy the time commitment (from you and/or your organization/management); +- Familiarity or willingness to learn W3C Process and document formatting rules; +- Familiarity with the [W3C Code of Conduct](/policies/code-of-conduct/); +- Ability to keep the Working Group "in Charter", both for technical and IPR issues; +- Ability (both actual and perceived by the Working Group -- including potential competitors) to forge consensus fairly and without bias from your affiliation/employer and, sometimes, even your own technical positions. + +* * * + +The team contact should arrange for the Chair and the [W3C Team](https://www.w3.org/Process#ref-for-team%E2%91%A2%E2%91%A6) to meet (by phone if necessary) to make sure they're on the same wavelength about things like: + +- where the group's work fits into [Web Architecture](/TR/webarch/) +- where does it fit with other groups +- testing, test suites ... generating tests as you come to each +- responsibility not just to the group -- working toward consensus of the whole community +- cost of delaying wider consensus - negotiating your reviews and really getting in touch with people - versus time to market and specification relevance +- formal objections, i.e. the tricky bits of W3C process \ No newline at end of file From c831be9b7583002dbd1d25eb6eccc572c71c848d Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 16:17:22 +0100 Subject: [PATCH 024/225] Rename from .html to .md --- chair/{meetings.html => meetings.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename chair/{meetings.html => meetings.md} (100%) diff --git a/chair/meetings.html b/chair/meetings.md similarity index 100% rename from chair/meetings.html rename to chair/meetings.md From 4acce51c2c8767e20661632958766e8eb984109e Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 4 Dec 2024 16:26:18 +0100 Subject: [PATCH 025/225] Convert to markdown --- chair/meetings.md | 51 +++++++++-------------------------------------- 1 file changed, 9 insertions(+), 42 deletions(-) diff --git a/chair/meetings.md b/chair/meetings.md index 057c2e401..c8bdc7829 100644 --- a/chair/meetings.md +++ b/chair/meetings.md @@ -1,35 +1,9 @@ - - - - - Chairs Meetings, Historical - - - - - - - +--- +title: Chairs Meetings +toc: false +--- -
    -

    Related Resources

    - -
    - -
    +

    I am overwhelmed by the level of talent and dedication in this group.

    -- Tim Berners-Lee, at @@ -37,12 +11,10 @@
    -

    We met originally in November 1997 to facilitate shared context among the -W3C Working Group Chairs and the W3C Team. We did a few more face-to-face -meetings and several teleconferences.

    +We met originally in November 1997 to facilitate shared context among the W3C Working Group Chairs and the W3C Team. We did a few more face-to-face meetings and several teleconferences. + +See also the [technical plenary history](../2002/09/TPOverview.html) -

    See also the technical plenary -history

    20 Nov 1997
    1st Working Group Chairs @@ -157,9 +129,4 @@ history

    agenda, minutes
    15 September 2022: TPAC 2022
    minutes
    -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - + From 1e42c8511b9d64baf27e224c7e2516a1da136252 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 9 Dec 2024 11:07:59 +0100 Subject: [PATCH 026/225] Rename from .html to .md --- teamcontact/{liaison-role.html => liaison-role.md} | 0 teamcontact/{RemoteMaintainers.html => remote-maintainers.md} | 0 teamcontact/{role.html => role.md} | 0 3 files changed, 0 insertions(+), 0 deletions(-) rename teamcontact/{liaison-role.html => liaison-role.md} (100%) rename teamcontact/{RemoteMaintainers.html => remote-maintainers.md} (100%) rename teamcontact/{role.html => role.md} (100%) diff --git a/teamcontact/liaison-role.html b/teamcontact/liaison-role.md similarity index 100% rename from teamcontact/liaison-role.html rename to teamcontact/liaison-role.md diff --git a/teamcontact/RemoteMaintainers.html b/teamcontact/remote-maintainers.md similarity index 100% rename from teamcontact/RemoteMaintainers.html rename to teamcontact/remote-maintainers.md diff --git a/teamcontact/role.html b/teamcontact/role.md similarity index 100% rename from teamcontact/role.html rename to teamcontact/role.md From c2e7adcdf6ca1416727f23b7074708ab8a4bc3c2 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 9 Dec 2024 11:58:50 +0100 Subject: [PATCH 027/225] Convert to markdown --- teamcontact/liaison-role.md | 106 +++----------- teamcontact/remote-maintainers.md | 182 ++++++++---------------- teamcontact/role.md | 229 +++++++++--------------------- 3 files changed, 150 insertions(+), 367 deletions(-) diff --git a/teamcontact/liaison-role.md b/teamcontact/liaison-role.md index 8d5c98671..f2f5acae9 100644 --- a/teamcontact/liaison-role.md +++ b/teamcontact/liaison-role.md @@ -1,94 +1,32 @@ - - - - - liaison-role - - -W3C -. Art of Consensus Guide -

    Role of Liaison

    +--- +title: Role of Liaison +toc: false +--- -

    The Staff Contact for a Working Group, with -the Chair's assistance, appoints a liaison as -needed where two groups have strong dependencies; -see the list of W3C liaisons. -The Liaison's primary -role is to facilitate resolution of the dependency between the two groups. +The [Staff Contact](staff-contact) for a Working Group, with the [Chair's](chairs-role) assistance, appoints a liaison as needed where two groups have strong dependencies; see the list of [W3C liaisons](/2001/11/StdLiaison). The Liaison's primary role is to facilitate resolution of the dependency between the two groups. -

    An overall question: is there always a "Group A" & "Group B," in -other words a "home" group that is having its requirements considered in -a "host" (or 'target'??) group, or is the liaisoning relationship sometimes -completely mutual? +An overall question: is there always a "Group A" & "Group B," in other words a "home" group that is having its requirements considered in a "host" (or 'target'??) group, or is the liaisoning relationship sometimes completely mutual? -


    -

    -Ensures adequate Dependency statement

    +## Ensures adequate Dependency statement -
      -
    • -Is familiar with W3C Process and Member -Guide.
    • +- Is familiar with [W3C Process](/policies/process/) and [Member Guide](../Guide). +- Reviews (hopefully) existing dependency statement, otherwise ensures that appropriate dependency statement is written. +- Contributes additional ideas to dependency statement as needed to update or make more accurate. -
    • -Reviews (hopefully) existing dependency statement, otherwise ensures that -appropriate dependency statement is written.
    • +## Monitors discussion in both Groups -
    • -Contributes additional ideas to dependency statement as needed to update -or make more accurate.
    • -
    +- Keeps current with discussion and document progress in both Group? (?Should a liaison have to fulfill active membership requirements in both groups? could be prohibitive) +- Monitors status of technical issues related to areas of dependency. +- Maintains coordination with Chairs of both Groups. -

    -Monitors discussion in both Groups

    +## Keep each Group informed of the other's requirements & timelines -
      -
    • -Keeps current with discussion and document progress in both Group? (?Should -a liaison have to fulfill active membership requirements in both groups? -could be prohibitive)
    • +- Notifies either group when dependency issues need discussion/negotiation. +- Explain, or ensures explanation of, technology or requirements of the other Group as needed (e.g., a tutorial, for instance of Group B's technology for Group A's requirements exploration) -
    • -Monitors status of technical issues related to areas of dependency.
    • +## Ensure resolution of dependencies -
    • -Maintains coordination with Chairs of both Groups.
    • -
    - -

    -Keep each Group informed of the other's requirements & timelines

    - -
      -
    • -Notifies either group when dependency issues need discussion/negotiation.
    • - -
    • -Explain, or ensures explanation of, technology or requirements of the other -Group as needed (e.g., a tutorial, for instance of Group B's technology -for Group A's requirements exploration)
    • -
    - -

    -Ensure resolution of dependencies

    - -
      -
    • -Ensures discussion and consensus in Group A on requirements to bring to -Group B
    • - -
    • -Represents requirements of Group A to Group B.
    • - -
    • -Assist in negotiating requirements of Group A with Group B with assistance -of Staff Contact, and Project Lead as needed.
    • - -
    • -Brings back follow-up items for discussion as needed...
    • -
    - -

    Feedback is to @w3c/guidebook - is welcome on GitHub

    - - - +- Ensures discussion and consensus in Group A on requirements to bring to Group B +- Represents requirements of Group A to Group B. +- Assist in negotiating requirements of Group A with Group B *with assistance of Staff Contact, and Project Lead as needed.* +- Brings back follow-up items for discussion as needed... \ No newline at end of file diff --git a/teamcontact/remote-maintainers.md b/teamcontact/remote-maintainers.md index 34bbade46..56c22dc64 100644 --- a/teamcontact/remote-maintainers.md +++ b/teamcontact/remote-maintainers.md @@ -1,131 +1,63 @@ - - - - -SmartList Remote Maintainers Guide - - - - - - - -
    -W3C -Guide -
    - -

    SmartList Remote Maintainers Guide

    - -

    W3C's mailing lists are managed using a customized version of -SmartList.

    - -

    E-mail command interface

    - -

    Many W3C lists allow people to sub and unsub using an e-mail command interface.

    - -

    Web interface

    - -

    The List admin tool -allows list maintainers to add or remove subscribers, view info about the -list's config, and view recent log entries.

    - -

    If you need more info about a list that is not provided by the list -admin tool, please contact <sysreq@w3.org>.

    - -

    Handling [Moderator Action] messages

    - -

    If your mailing list has posting restrictions enabled and a previously -unknown address sends mail to the list, you will receive a message with -[Moderator Action] prepended to the Subject, e.g.:

    - -
    -Subject: [Moderator Action] original subject -
    - -

    If this is a legitimate message for your list, you should approve it -through to the list using the Moderator action queue review web interface or your mail client's "bounce", "resend", or -"redirect" feature. Smartlist will remove the [Moderator Action] prefix and -the message will appear to come from the original sender (and not from -you). Some custom headers may be added to indicate you forwarded the mail, -for example Resent-From:.

    - -

    If a message was sent to multiple mailing lists, the easiest way to figure out which list(s) caused the moderator action, is to display / view the X-Envelope-To header.

    - -

    Here are some notes on how to handle these messages in various mail -clients:

    - -
      -
    • For Thunderbird you need this - extension. Although it doesn't allow you to edit the subject line, so - it will still say [Moderator Action] on the outward-going mail, as - pointed out above the W3C servers strip it off.
    • -
    • For Mac Mail, hit shift+cmd+e, or use the "Redirect" button that you can add to your Toolbar
    • -
    • Outlook - 2000
    • -
    • For Gmail, see Bouncing - a message from Gmail by Sam Ruby.
    • -
    • For mutt, type 'b' to bounce then enter the list's address. -
    - -

    Handling [Moderator Action (size limit exceeded)] messages

    - -

    You can find the size limit in the "configuration" information of a mailing list, available from the right-hand side after - searching it via the List admin tool.

    - -

    A message may be stuck because of an attachment that is too large, and the list moderator may not bypass a list's size limit. Here's how to proceed in this case:

    - -
      -
    1. Forward to an archive mailing list (see below for guidance)
    2. -
    3. Find the link of the attachment(s) in the list web archive
    4. -
    5. Go back to your mailer: -
        -
      1. strip the attachment(s) from the mail to moderate
      2. -
      3. type somewhere e.g., at the top, that the attachment(s) is/are archived elsewhere and paste the link
      4. -
      5. redirect
      6. -
      -
    6. -
    - -

    Guidance for which archive mailing list to choose depending on the confidentiality-level of the target list:

    - -
    +--- +title: SmartList Remote Maintainers Guide +toc: false +--- + +W3C's mailing lists are managed using a customized version of SmartList. + +## E-mail command interface + +Many W3C lists allow people to sub and unsub using an [e-mail command interface](https://www.w3.org/Mail/Request). + +## Web interface + +The [List admin tool](https://lists.w3.org/admin/manage) allows list maintainers to add or remove subscribers, view info about the list's config, and view recent log entries. + +If you need more info about a list that is not provided by the list admin tool, please contact <[sysreq@w3.org](mailto:sysreq@w3.org)>. + +## Handling \[Moderator Action] messages + +If your mailing list has posting restrictions enabled and a previously unknown address sends mail to the list, you will receive a message with \[Moderator Action] prepended to the Subject, e.g.: + +> `Subject: [Moderator Action] original subject` + +If this is a legitimate message for your list, you should approve it through to the list using the [Moderator action queue review](https://lists.w3.org/admin/moderate) web interface or your mail client's "bounce", "resend", or "redirect" feature. Smartlist will remove the \[Moderator Action] prefix and the message will appear to come from the original sender (and not from you). Some custom headers may be added to indicate you forwarded the mail, for example `Resent-From:`. + +If a message was sent to multiple mailing lists, the easiest way to figure out which list(s) caused the moderator action, is to display / view the `X-Envelope-To` header. + +Here are some notes on how to handle these messages in various mail clients: + +- For Thunderbird you need [this extension](https://addons.mozilla.org/en-US/thunderbird/addon/mailredirect/). Although it doesn't allow you to edit the subject line, so it will still say \[Moderator Action] on the outward-going mail, as pointed out above the W3C servers strip it off. +- For Mac Mail, hit shift+cmd+e, or use the "Redirect" button that you can add to your Toolbar +- [Outlook 2000](http://web.archive.org/web/20030720050852/spamassassin.taint.org/faq/index.cgi?req=show&file=faq03.003.htp) +- For Gmail, see [Bouncing a message from Gmail](http://intertwingly.net/blog/2011/04/03/Bouncing-a-message-from-Gmail) by Sam Ruby. +- For mutt, type 'b' to bounce then enter the list's address. + +## Handling \[Moderator Action (size limit exceeded)] messages + +You can find the size limit in the "configuration" information of a mailing list, available from the right-hand side after searching it via the [List admin tool](https://lists.w3.org/admin/manage). + +A message may be stuck because of an attachment that is too large, and the list moderator may not bypass a list's size limit. Here's how to proceed in this case: + +1. Forward to an archive mailing list (see below for guidance) +2. Find the link of the attachment(s) in the list web archive +3. Go back to your mailer: + + 1. strip the attachment(s) from the mail to moderate + 2. type somewhere e.g., at the top, that the attachment(s) is/are archived elsewhere and paste the link + 3. redirect + +Guidance for which archive mailing list to choose depending on the confidentiality-level of the target list: + +
    member-visible: w3c-archive@w3.org (indicative size limit: 25971520 bytes)
    cf. https://lists.w3.org/Archives/Member/w3c-archive/
    -
    team-only: w3t-archive@w3.org (indicative size limit: 41943040 bytes)
    cf. https://lists.w3.org/Archives/Team/w3t-archive/
    -
    public: www-archive@w3.org (indicative size limit: 41943040 bytes)
    cf. https://lists.w3.org/Archives/Public/www-archive/
    -
    - -

    If you have useful info not listed above, please contribute it by editing -this page or by sending email to sysreq@w3.org.

    - -

    If you would like someone to be able to post directly to a given list -without having their messages flagged for [Moderator action], -use the list admin tool to -add their email address to the "accept2" file for the list in question. -Future messages from their address will be distributed directly to the list -without needing to be moderated.

    - -
    -
    -Gerald Oskoboiny -
    - - +
    + +If you have useful info not listed above, please contribute it by [editing this page](https://github.com/w3c/Guide/blob/master/teamcontact/RemoteMaintainers.html) or by sending email to [sysreq@w3.org](mailto:sysreq@w3.org). + +If you would like someone to be able to post directly to a given list without having their messages flagged for `[Moderator action]`, use the [list admin tool](https://lists.w3.org/admin/manage) to add their email address to the "accept2" file for the list in question. Future messages from their address will be distributed directly to the list without needing to be moderated. \ No newline at end of file diff --git a/teamcontact/role.md b/teamcontact/role.md index add9c07c1..749239389 100644 --- a/teamcontact/role.md +++ b/teamcontact/role.md @@ -1,162 +1,75 @@ - - - - -Role of the Team Contact - - - - - --"W3C" . Art of Consensus Guide -

    Role of the Team Contact

    +--- +title: Role of the Team Contact +toc: false +--- -

    Note: W3C designates a Team Contact to monitor the progress of -every Submission request -and to write a Team Comment which is published as part of the Submission. -This document, however, discusses the Team Contact of a Working Group, rather than the Team Contact for a Submission.

    -

    W3C designates a Team Contact ("Contact") for every W3C Working -Group and Interest Group ("Group"). The Contact helps set the strategic -direction of the Group in the chartering phase. Many - of the Contact's tasks involve helping the Chair -complete his or her roles, -such as ensuring that the group runs smoothly, actively aiding consensus building, ensuring wide review of specifications, tracking feedback from implementors, and so forth. The Team Contact reports to the Project Lead.

    +*Note:* W3C designates a Team Contact to monitor the progress of every [Submission request](../Project/Submission) and to write a Team Comment which is published as part of the Submission. This document, however, discusses the Team Contact of a Working Group, rather than the Team Contact for a Submission. -

    Technical coordination

    -

    Coordination and communication is a primary role for the Team Contact, -who acts as the -interface between the Group Chair ("Chair"), Group Members, other Working Groups, -and the W3C Team:

    -

    The team contact role is largely one of communication. This -involves becoming as aware as possible of the technical -requirements and issues in the group, and simultaneously being -aware of the general architecture of the Web - as evolving in the -other work of W3C. This is of course a general responsibility of -the group - and the chair and group members have this duty too. The -staff contact has the benefit of being employed full time in W3C, -and having access to other team members. The team contact's -existence does not dilute in any way the group's obligation to -ensure the technology interoperates with that of other groups. -[TimBL 2001-09-11]

    -

    The Team Contact is also charged with representing the views of the Team to the Working group. Just as all Members do not have the same views, neither does all the Team. The Team Contact collects the various viewpoints and summarizes them so that the Working Group benefits from the widest range of inputs. Where the Team does not have a single position, it is inappropriate to merely abstain. Instead, the various points of view should be summarized. -For a good example of Team input where the Team did not have consensus, -see -Team response on the 'canvas' element.

    +W3C designates a Team Contact ("Contact") for every W3C Working Group and Interest Group ("Group"). The Contact helps set the strategic direction of the Group in the chartering phase. Many of the Contact's tasks involve helping the Chair complete his or her [roles](chair-roles.html), such as ensuring that the group runs smoothly, actively aiding consensus building, ensuring wide review of specifications, tracking feedback from implementors, and so forth. The Team Contact reports to the Project Lead. -

    Assist Group organizers in creating charter and convening -Group

    -
      -
    • Assist in creating the group charter. When rechartering, discuss the proposed charter with the existing Working group and with the Team. - See also the charter template and -ongoing charters.
    • -
    • Act as the charter shepherd. - If approved, the Team will -announce the creation of the group and ensures a call for -participation is announced.
    • -
    • Assist the organizers in understanding dependencies on -other groups, and act as coordinator when necessary.
    • -
    • Ensure that the Chair is familiar with key documents, -including: - +## Technical coordination + +Coordination and communication is a primary role for the Team Contact, who acts as the interface between the Group Chair ("Chair"), Group Members, other Working Groups, and the W3C Team: + +> The team contact role is largely one of communication. This involves becoming as aware as possible of the technical requirements and issues in the group, and simultaneously being aware of the general [architecture of the Web](/TR/webarch) as evolving in the other work of W3C. This is of course a general responsibility of the group - and the chair and group members have this duty too. The staff contact has the benefit of being employed full time in W3C, and having access to other team members. The team contact's existence does not dilute in any way the group's obligation to ensure the technology interoperates with that of other groups. \[*TimBL 2001-09-11*] + +The Team Contact is also charged with representing the views of the Team to the Working group. Just as all Members do not have the same views, neither does all the Team. The Team Contact collects the various viewpoints and summarizes them so that the Working Group benefits from the widest range of inputs. Where the Team does not have a single position, it is inappropriate to merely abstain. Instead, the various points of view should be summarized. For a good example of Team input where the Team did not have consensus, see [Team response on the 'canvas' element](https://lists.w3.org/Archives/Public/public-html/2007Nov/0449.html). + +## Assist Group organizers in creating charter and convening Group + +- *Assist* in creating the group charter. When rechartering, discuss the proposed charter with the existing Working group and with the Team. See also the [charter template](https://w3c.github.io/charter-drafts/charter-template.html) and [ongoing charters](https://github.com/w3c/strategy/issues?q=label%3Acharter). +- Act as the [charter shepherd](../process/charter.html#charter-shepherd). If approved, the Team will announce the creation of the group and ensures a call for participation is announced. +- *Assist* the organizers in understanding dependencies on other groups, and act as coordinator when necessary. +- *Ensure* that the Chair is familiar with key documents, including: + + - [The Process Document](/policies/process/) + + - [General Information about Groups](/policies/process/#GAGeneral) + - [Working Groups](/policies/process/#GroupsWG) + - [Interest Groups](/policies/process/#GroupsIG) + - [The Art of Consensus](../) + + - [Pubrules](/pubrules) + - [W3C Invited Experts](/invited-experts/) principles and review requirements + - [Archive of chairs@w3.org](https://lists.w3.org/Archives/Member/chairs/) (member-only) + - [Code of Conduct](/policies/code-of-conduct/) + - [Antitrust and competition policy](/policies/antitrust/) +- *Ensure* that Chair is marked as such (checkbox) in the [group's homepage](/groups/) (which subscribes him/her to [chairs@w3.org](mailto:chairs-request@w3.org)) +- *Ensure* that Group Members are oriented to W3C process and their roles when Group convenes or new Group Members join. +- *Ensure* that Group sets milestones for document development, charter renewals, etc. +- *Ensure* that Chair understands the different stages of document development (Editor's Drafts, Working Drafts, Candidate Recommendation, Proposed Recommendations, Recommendations), and confidentiality and status issues for each stage. +- *Assist* Chair in assessing need for charter renewal and/or closing of the Group. +- *Ensure* that previous Chair is removed in the [group's homepage](/groups/). + +## Monitor group participation and operations + +- \[*Active Role*] Monitor levels of active participation and address as needed. +- *Ensure* that attendance and minutes are kept. +- *Ensure* that Chair is aware of any problems and report these problems to W3M when they persist. +- *Assist* Chair in moderating disputes between participants. +- *Ensure* that Group page is up-to-date +- *Assist* in reservations for phone bridge as needed +- *Ensure* sufficient advance notice of meetings by proper channels +- *Ensure* agendas posted in timely fashion +- *Ensure* minutes posted in timely fashion + +## Serve as Contact with W3C Team + +- \[*Active Role*] Keep the Communications Team and Project lead informed of group events, face-to-face meetings, anticipated publication dates, etc. +- \[*Active Role*] Identify host and coordinate with host to organize logistics for face-to-face meetings, events, etc. +- *Assist* the Communications Team and Chair in soliciting testimonials for press releases. +- \[*Active Role*] Work with Communications Team to draft press releases and/or review for accuracy. +- \[*Active Role*] Coordinate the act of publishing documents with the Communications and Sys/Web Teams. +- \[Active Role] Follow communications with other W3C groups and functions to identify areas where coordination is needed. +- *Assist* Chair in coordinating with other W3C groups as needed. +- *Ensure* liaisons between Group and other W3C groups are assigned as needed. +- \[*Active Role*] Coordinate with the Systems Team to ensure that Chair and group Editors have appropriate access to the W3C site, and that their access works, e.g. GitHub. +- *Ensure* that Group editors understand how to use [GitHub at W3C](https://w3c.github.io/). +- *Ensure*, before publishing any Group document in W3C/TR space, that it is: -
    • -
    • Ensure that Chair is marked as such (checkbox) in the group's homepage (which -subscribes him/her to chairs@w3.org)
    • -
    • Ensure that Group Members are oriented to W3C process -and their roles when Group convenes or new Group Members join.
    • -
    • Ensure that Group sets milestones for document -development, charter renewals, etc.
    • -
    • Ensure that Chair understands the different stages of -document development (Editor's Drafts, Working Drafts, -Candidate Recommendation, Proposed Recommendations, Recommendations), and -confidentiality and status issues for each stage.
    • -
    • Assist Chair in assessing need for charter renewal -and/or closing of the Group.
    • -
    • Ensure that previous Chair is removed in the group's homepage.
    • -
    -

    Monitor group participation and operations

    -
      -
    • [Active Role] Monitor levels of active participation and -address as needed.
    • -
    • Ensure that attendance and minutes are kept.
    • -
    • Ensure that Chair is aware of any problems and report -these problems to W3M when they persist.
    • -
    • Assist Chair in moderating disputes between -participants.
    • -
    • Ensure that Group page is up-to-date
    • -
    • Assist in reservations for phone bridge as needed
    • -
    • Ensure sufficient advance notice of meetings by proper -channels
    • -
    • Ensure agendas posted in timely fashion
    • -
    • Ensure minutes posted in timely fashion
    • -
    -

    Serve as Contact with W3C Team

    -
      -
    • [Active Role] Keep the Communications Team and Project -lead informed of group events, face-to-face meetings, anticipated -publication dates, etc.
    • -
    • [Active Role] Identify host and coordinate with host to -organize logistics for face-to-face meetings, events, etc.
    • -
    • Assist the Communications Team and Chair in soliciting -testimonials for press releases.
    • -
    • [Active Role] Work with Communications Team to draft -press releases and/or review for accuracy.
    • -
    • [Active Role] Coordinate the act of publishing documents -with the Communications and Sys/Web Teams.
    • -
    • [Active Role] Follow communications with other W3C groups and -functions to identify areas where coordination is needed.
    • -
    • Assist Chair in coordinating with other W3C groups as -needed.
    • -
    • Ensure liaisons between Group and other W3C groups are -assigned as needed.
    • -
    • [Active Role] Coordinate with the Systems Team to ensure -that Chair and group Editors have appropriate access to the W3C -site, and that their access works, e.g. GitHub.
    • -
    • Ensure that Group editors understand how to use GitHub at W3C.
    • -
    • Ensure, before publishing any Group document in W3C/TR -space, that it is: -
        -
      1. Being published properly (see Pubrules).
      2. -
      3. Spell-checked
      4. -
      5. HTML validated (see, for example, the HTML validator service).
      6. -
      7. CSS validated (see, for example, the CSS validator).
      8. -
      9. Accessible (see Accessibility evaluation resources)
      10. -
      11. Published in the appropriate places, using Team conventions for -document status information, naming schemes, etc.
      12. -
      -
    • -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - + 1. Being published properly (see [Pubrules](/pubrules)). + 2. Spell-checked + 3. HTML validated (see, for example, the [HTML validator service](http://validator.w3.org/)). + 4. CSS validated (see, for example, the [CSS validator](http://jigsaw.w3.org/css-validator/)). + 5. Accessible (see [Accessibility evaluation resources](/WAI/eval/Overview.html)) + 6. Published in the appropriate places, using Team conventions for document status information, naming schemes, etc. \ No newline at end of file From bfe0a64bb18256a4206719e10f654a0cf246fe6b Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 9 Dec 2024 15:13:06 +0100 Subject: [PATCH 028/225] Rename from .html to .md --- transitions/{details.html => details.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename transitions/{details.html => details.md} (100%) diff --git a/transitions/details.html b/transitions/details.md similarity index 100% rename from transitions/details.html rename to transitions/details.md From d4c764e9cac3c280b8fe31df771fe4e642715a71 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 9 Dec 2024 15:46:16 +0100 Subject: [PATCH 029/225] Convert to markdown --- transitions/details.md | 241 +++++++++-------------------------------- 1 file changed, 49 insertions(+), 192 deletions(-) diff --git a/transitions/details.md b/transitions/details.md index 9403c0086..7535c897b 100644 --- a/transitions/details.md +++ b/transitions/details.md @@ -1,229 +1,86 @@ - - - - - Details of How to Organize a Recommendation Track Transition - - - - - - - - -
    -

    Also On This Page →

    - -
    - - - -

    -This document explains the processes W3C uses internally to prepare -and carry out a transition of a document on the Recommendation -Track. This document complements the version of "How to Organize a -Recommendation Track Transition". Please -refer to the latest version of "How to Organize a Recommendation Track -Transition" with this URI: -<https://www.w3.org/Guide/transitions>.

    - -

    This document does not address:

    - -
      -
    1. Requirements for documents themselves; see Technical Report Publication Policy -("pubrules") for this information. -
    2. - -
    3. What required information must be public; this is covered in -section 7.2 of the Process Document and in the governing patent -policy.
    4. - -
    5. Possible next steps after each transition; see the description -of the Recommendation Track -Process.
    6. - -
    7. The Comm Team's policy regarding in-place modification of W3C -Technical Reports.
    8. -
    - -

    Exceptions to these processes MAY be authorized by @w3c/transitions.

    - -

    The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL -NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described -in RFC -2119.

    - -

    Roles

    +--- +title: Organize a Recommendation Track Transition (Details) +toc: false +--- +This document explains the processes W3C uses internally to prepare and carry out a transition of a document on the Recommendation Track. This document complements the version of "How to Organize a Recommendation Track Transition". Please refer to the latest version of "How to Organize a Recommendation Track Transition" with this URI: ``. -
    +This document does not address: -
    Webmaster +1. Requirements for documents themselves; see [Technical Report Publication Policy](/pubrules/doc) ("pubrules") for this information. +2. What required information must be public; this is covered in [section 7.2](/policies/process/#requirements-and-definitions) of the Process Document and in the governing patent policy. +3. Possible next steps after each transition; see the description of the [Recommendation Track Process](/policies/process/#Reports). +4. The Comm Team's policy regarding [in-place modification of W3C Technical Reports](/2003/01/republishing/). + +Exceptions to these processes MAY be authorized by [@w3c/transitions](https://github.com/orgs/w3c/teams/transitions). + +The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.txt). -
    The Webmaster publishes documents.
    +## Roles ## -
    @w3c/transitions
    -
    Transition approvals are given by @w3c/transitions, +
    +
    Webmaster +
    The Webmaster publishes documents.
    + +
    @w3c/transitions
    +
    Transition approvals are given by @w3c/transitions, under the delegation from Technical issues Lead Team.
    Chair
    -
    Group Chair responsibilities may be carried out by either the Chair +
    Group Chair responsibilities may be carried out by either the Chair or Team Contact.
    -
    Document Contact
    -
    The Document Contact is +
    Document Contact
    +
    The Document Contact is either the Team Contact, the Chair, or the document editor of the Working Group or Interest Group requesting publication. If there is no Working Group nor Interest Group, the Maintainer Contact becomes the Document Contact. Consult the W3C Project Management Lead if you're not sure who is the relevant Document Contact.
    -
    Maintainer Contact
    -
    The Maintainer +
    Maintainer Contact
    +
    The Maintainer Contact is a designated individual tasked with requesting Team's approval in order to publish a Recommendation without a Working Group. Consult the W3C Project Management Lead if you're not sure who is the relevant Maintainer Contact. (Note: as of January 2018, the maintainer contact is plh)
    -
    - -

    See also the W3C Editor's Home Page -and Guidebook documentation of roles of W3C -participants, including the Chair's -role and the Team Contact's -role.

    - -

    Interactions with the W3C -Communications Team

    - -

    At various stages during the Recommendation Track process, the -W3C Communications Team assists Working Groups as follows:

    - -
      -
    • Organizing formal Advisory Committee reviews (including -scheduling and preparation of review forms).
    • - -
    • Issuing a press release around a First Public Working Draft, -Candidate Recommendation, Recommendation, or other transition (for -example, to announce completion of important work or to raise -awareness at a conference). The Communications Team generally begins work -on a draft press release several weeks in advance of an anticipated -release, soliciting review within the Team. The Communications -Team may also request Working Group review of a draft press -release. In general, the Communications Team strives to make press -releases available in English, French, Japanese and Chinese. The W3C Offices -translate W3C press releases into additional -languages.
    • - -
    • Soliciting testimonials in support of a document, usually more -than a month in advance of publication of a Recommendation.
    • - -
    • Announcing publication to Members and the press.
    • - -
    • Listing the publication on the W3C home page and in Member -publications. In general, the Communications Team -drafts home page announcements for publications (see -past news items). Input from Team Contacts -for announcements of First Public Working Drafts is appreciated.
    • - -
    • Writing speaking points for the press, generally with input -from the Working Group.
    • +
    -
  • Coordinating spokespeople to answer technical questions from -the press.
  • - +See also the [W3C Editor's Home Page](/Guide/editor/) and Guidebook documentation of [roles of W3C participants](#roles), including the [Chair's role](/Guide/chair/role) and the [Team Contact's role](/Guide/teamcontact/role). -

    Please contact the Communications Team at w3t-comm@w3.org -(cc'ing the group's Team Contact) if you have any general questions -regarding the publications process.

    +## Interactions with the W3C Communications Team -

    History of "How to Organize a Transition"

    +At various stages during the Recommendation Track process, the W3C Communications Team assists Working Groups as follows: -

    20240112: Moved to Github. For future history, see the github log.

    +- Organizing formal Advisory Committee reviews (including scheduling and preparation of review forms). +- Issuing a press release around a First Public Working Draft, Candidate Recommendation, Recommendation, or other transition (for example, to announce completion of important work or to raise awareness at a conference). The Communications Team generally begins work on a draft press release several weeks in advance of an anticipated release, soliciting review within the Team. The Communications Team may also request Working Group review of a draft press release. In general, the Communications Team strives to make press releases available in English, French, Japanese and Chinese. The W3C Offices translate [W3C press releases](/press-releases/) into additional languages. +- Soliciting testimonials in support of a document, usually more than a month in advance of publication of a Recommendation. +- Announcing publication to Members and the press. +- Listing the publication on the W3C home page and in Member publications. In general, the Communications Team drafts home page announcements for publications (see [past news items](/news/)). Input from Team Contacts for announcements of First Public Working Drafts is appreciated. +- Writing speaking points for the press, generally with input from the Working Group. +- Coordinating spokespeople to answer technical questions from the press. -

    20180416: Fixed broken fragments, updated links, general quality assurance and updates.

    +Please contact the Communications Team at w3t-comm@w3.org (cc'ing the group's Team Contact) if you have any general questions regarding the publications process. -

    20170301: Revised for transitions documentation for Process 2017.

    +## History of "How to Organize a Transition" -

    20161101: Updated for reorganization 2016

    +20240112: Moved to Github. For future history, see the [github log](https://github.com/w3c/transitions/commits/main/details.html). -

    20160804: Transitions 2005 and 2014 superseded by 2015.

    +20180416: Fixed broken fragments, updated links, general quality assurance and updates. -

    20151123: Revised for transitions documentation for Process 2015.

    +20170301: Revised for [transitions documentation for Process 2017](/Guide/transitions/). -

    20140801: Revised for transitions documentation for Process 2014.

    +20161101: Updated for reorganization 2016 -

    20060131: Revised for -release with pubrules. Released 31 January 2006 but created in August -2005.

    +20160804: Transitions 2005 and 2014 superseded by 2015. -

    20031201: Version sent for -review with 24 Dec 2003 Process Document.

    +20151123: Revised for [transitions documentation for Process 2015](/Guide/transitions/). -

    20030501: Version published -with June 2003 Process Document.

    +20140801: Revised for [transitions documentation for Process 2014](/Guide/transitions/). -
    -

    Feedback is to @w3c/transitions - and is welcome on GitHub

    +20060131: Revised for release with pubrules. [Released 31 January 2006](https://lists.w3.org/Archives/Member/chairs/2006JanMar/0026.html) but created in August 2005. - - +[20031201](/2003/12/01-transitions): Version sent for review with 24 Dec 2003 Process Document. +[20030501](/2003/05/Transitions): Version published with June 2003 Process Document. \ No newline at end of file From 4fe5aba07d3e34952f746aea9bacf267bd791911 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 9 Dec 2024 16:45:01 +0100 Subject: [PATCH 030/225] Rename from .html to .md --- editor/{role.html => role.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename editor/{role.html => role.md} (100%) diff --git a/editor/role.html b/editor/role.md similarity index 100% rename from editor/role.html rename to editor/role.md From b01b36fac23aa3f5fe097a4df91f7cbd0ac7e935 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 9 Dec 2024 16:49:06 +0100 Subject: [PATCH 031/225] Convert to markdown --- editor/role.md | 52 ++++++-------------------------------------------- 1 file changed, 6 insertions(+), 46 deletions(-) diff --git a/editor/role.md b/editor/role.md index 8c9add5f7..505200869 100644 --- a/editor/role.md +++ b/editor/role.md @@ -1,45 +1,11 @@ - - - - -W3C Specification Editor - - - - - - +--- +title: W3C Specification Editor +toc: false +--- - +The role of the editor is not that of author. They maintain the text of a current draft that the Group has agreed to and possibly to suggest concrete wording when none is forthcoming from the group. - -

    - The role of the editor is not that of author. They maintain the text of a current draft - that the Group has agreed to and possibly to suggest concrete wording when none is - forthcoming from the group. -

    -

    - Specification editors are appointed - by the Group Chair. -

    +Specification editors are [appointed by the Group Chair](https://www.w3.org/Guide/chair/role.html).

    Role of the editor

    @@ -109,9 +75,3 @@ change to a draft, before the proposed change is discussed.

    - -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - From 1ddc39a588802f6a753889f6ce9f57eaf776ab4a Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Tue, 10 Dec 2024 18:48:30 +0400 Subject: [PATCH 032/225] use commonmark to benefit from description lists --- Gemfile | 2 +- _config.yml | 1 - teamcontact/remote-maintainers.md | 19 ++++++++++--------- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Gemfile b/Gemfile index c6bd8f848..7e825bf9f 100644 --- a/Gemfile +++ b/Gemfile @@ -18,7 +18,7 @@ group :jekyll_plugins do gem "jekyll-readme-index" gem "jekyll-titles-from-headings" gem "jekyll-relative-links" - gem 'jekyll-commonmark-ghpages' + gem 'jekyll-commonmark' gem 'jekyll-remote-theme' gem 'jekyll-toc' gem 'webrick' diff --git a/_config.yml b/_config.yml index cc403bf6f..f2bf0161e 100644 --- a/_config.yml +++ b/_config.yml @@ -1,4 +1,3 @@ -markdown: CommonMarkGhPages title: W3C Guidebook baseurl: /guide remote_theme: w3c/w3c-jekyll-theme diff --git a/teamcontact/remote-maintainers.md b/teamcontact/remote-maintainers.md index 56c22dc64..3b297d080 100644 --- a/teamcontact/remote-maintainers.md +++ b/teamcontact/remote-maintainers.md @@ -49,15 +49,16 @@ A message may be stuck because of an attachment that is too large, and the list Guidance for which archive mailing list to choose depending on the confidentiality-level of the target list: -
    -
    member-visible: w3c-archive@w3.org (indicative size limit: 25971520 bytes)
    -
    cf. https://lists.w3.org/Archives/Member/w3c-archive/
    -
    team-only: w3t-archive@w3.org (indicative size limit: 41943040 bytes)
    -
    cf. https://lists.w3.org/Archives/Team/w3t-archive/
    -
    public: www-archive@w3.org (indicative size limit: 41943040 bytes)
    -
    cf. https://lists.w3.org/Archives/Public/www-archive/
    -
    + +member-visible: w3c-archive@w3.org (indicative size limit: 25971520 bytes) +: cf. [https://lists.w3.org/Archives/Member/w3c-archive/](https://lists.w3.org/Archives/Member/w3c-archive/) + +team-only: w3t-archive@w3.org (indicative size limit: 41943040 bytes) +: cf. [https://lists.w3.org/Archives/Team/w3t-archive/](https://lists.w3.org/Archives/Team/w3t-archive/) + +public: www-archive@w3.org (indicative size limit: 41943040 bytes) +: cf. [https://lists.w3.org/Archives/Public/www-archive/](https://lists.w3.org/Archives/Public/www-archive/) If you have useful info not listed above, please contribute it by [editing this page](https://github.com/w3c/Guide/blob/master/teamcontact/RemoteMaintainers.html) or by sending email to [sysreq@w3.org](mailto:sysreq@w3.org). -If you would like someone to be able to post directly to a given list without having their messages flagged for `[Moderator action]`, use the [list admin tool](https://lists.w3.org/admin/manage) to add their email address to the "accept2" file for the list in question. Future messages from their address will be distributed directly to the list without needing to be moderated. \ No newline at end of file +If you would like someone to be able to post directly to a given list without having their messages flagged for `[Moderator action]`, use the [list admin tool](https://lists.w3.org/admin/manage) to add their email address to the "accept2" file for the list in question. Future messages from their address will be distributed directly to the list without needing to be moderated. From afbac3229b3fd99400571789be046497ef69cddb Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 10 Dec 2024 16:22:47 +0100 Subject: [PATCH 033/225] Apply suggestions from code review Apply Denis' suggestions Co-authored-by: Denis Ah-Kang <1696128+deniak@users.noreply.github.com> --- chair/role.md | 2 +- council/council.md | 36 +++++++++++++++++------------------- editor/role.md | 2 +- teamcontact/liaison-role.md | 9 ++++++--- teamcontact/role.md | 2 +- transitions/details.md | 2 +- 6 files changed, 27 insertions(+), 26 deletions(-) diff --git a/chair/role.md b/chair/role.md index 94b05a9a3..d6ce398fa 100644 --- a/chair/role.md +++ b/chair/role.md @@ -34,7 +34,7 @@ Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies - Communicates with the press, when necessary and appropriate, and with prior coordination with the communication team, on behalf of the group. - *Ensures* all participants have proper access to Group data *with assistance from Staff Contact.* -### Maintains Group Process & Organization +### Maintains Group Process & Organization - Solicits drafts, encourages participation. - Judges items in or out of scope for the Group. diff --git a/council/council.md b/council/council.md index 2e9dcad90..7c933fac6 100644 --- a/council/council.md +++ b/council/council.md @@ -1,15 +1,13 @@ --- -title: Formal Objections & W3C Council +title: Formal Objections & W3C Council toc: true --- -This document supplements the Process Document by providing best practices to resolve and decide Formal Objections.

    +This document supplements the Process Document by providing best practices to resolve and decide Formal Objections. -

    In this document, resolving a Formal Objection means finding a solution that has no objections. Deciding means - giving a yes/no answer to the question of whether an objection should be overruled (i.e., no) or sustained (i.e., yes). -

    +In this document, resolving a Formal Objection means finding a solution that has no objections. Deciding means giving a yes/no answer to the question of whether an objection should be overruled (i.e., no) or sustained (i.e., yes). -## [Cases that warrant a W3C Council](#council) +## Cases that warrant a W3C Council W3C aims to make decisions by consensus. If there are differences of opinions, groups work to understand different points of view and reach agreement, either by compromise, or by the force of some argument. When that is working well, Formal Objections are rare. @@ -21,7 +19,7 @@ The fact that Formal Objections should be rare does not de-legitimize them. On s Nonetheless, the fact that the process is oriented towards consensus implies that before an objection gets higher review there already has been significant work on the issue. There is generally clarity on what the W3C decision was (that is being objected to). The objector, in trying to reverse the decision, has generally pulled together their best arguments and brought them to the group. The fact that so much work should be accomplished prior to higher review should make it easier to decide a Formal Objection. -## [The Team, the W3C Council, and different types of objections](#objection-types) +## The Team, the W3C Council, and different types of objections The Team has the responsibility to try to resolve a Formal Objection, or to come up with an analysis that might be used by the W3C Council in deciding a Formal Objection. The Team takes the early steps in processing Formal Objections. @@ -33,7 +31,7 @@ There are different types of Formal Objections and W3C needs to make sure they a It is important that even though the Team is an interested party in [case 2](#case-2), and the AB or TAG could be interested parties in [case 3](), the overall process must provide the objectivity and transparency to give the W3C Community the confidence that such cases are handled fairly. -## [Processing of Formal Objections](#processing-of-formal-objections) +## Processing of Formal Objections All Formal Objections are made in response to a decision. Decisions are typically made by a Working Group as part of the Technical Report Development Process or by the Team as part of chartering a new group. @@ -41,7 +39,7 @@ Since W3C operates by consensus, it is always better if there can be a consensus This report is then sent to the W3C Council, to the deciders, and to the objectors. The W3C Council, like the Team before it, may try to find a consensus path forward. Otherwise, the W3C Council uses input from the report, the deciders, and objectors to either overrule the objection (in which case the original decision is in force), or to sustain the objection (in which case the original decision is vacated). The W3C Council also writes a report explaining their decision, which may be based on the Team's report. -### [Team attempts to resolve Formal Objections](#team-fo) +### Team attempts to resolve Formal Objections When a Formal Objection is raised, the Team assigns someone to attempt to resolve the Formal Objection. That assignee is expected to follow the best practices below. @@ -57,7 +55,7 @@ The assignee works with all parties to explore whether there is a way to resolve See also: [Ongoing Team Attempts](https://www.w3.org/Member/wiki/DirectorFOdashboard#Team_is_attempting_to_find_consensus_or_not_ready_to_ask_a_Council) -### [Publishing formal objections](#publishing-fos) +### Publishing formal objections Formal objections must be made public using [public-review-comments](https://lists.w3.org/Archives/Public/public-review-comments/), no later than when the relevant council is initiated. The team should publish formal objections as soon as reasonable within the 90 days investigation and mediation period, with some considerations including: @@ -68,7 +66,7 @@ Formal objections must be made public using [public-review-comments](https://lis To avoid leaving people wondering what happened, the Team should post a response to the announcement of the formal objection, indicating the resolution of the formal objection, such as overruled or withdrawn, and giving a quick summary as to why. -## [Referral to W3C Council](#referral) +## Referral to W3C Council If resolution is not possible in the allocated time frame, the assignee must refer the Formal Objection to the W3C Council for decision. The steps for that are as follows: @@ -101,9 +99,9 @@ If resolution is not possible in the allocated time frame, the assignee must ref See also: [Ongoing Referrals to W3C Council](https://www.w3.org/Guide/council/council#referral) -## [The Nature of W3C Council deliberations](#nature-of-council-deliberations) +## The Nature of W3C Council deliberations -### [I. Considerations](#considerations) +### I. Considerations Each Formal Objection referred to the W3C Council has unique aspects, and the W3C Council needs the flexibility to choose how it reaches a decision. In studying a particular Formal Objection, the W3C Council should always balance several factors: @@ -115,7 +113,7 @@ Each Formal Objection referred to the W3C Council has unique aspects, and the W3 - Treating all objectors consistently irrespective of who the objector might be. - Workload. If processing each Formal Objection results in significant work for a very large Council, then the Council will not have time to process the workload and the W3C Council design will not scale. -### [II. Convincing the W3C Council](#convincing-the-council) +### II. Convincing the W3C Council The nature of a Formal Objection is that a Decision has been made and someone has raised a Formal Objection to that Decision. The W3C Council is required by the Process to review the Decision, and choose whether to overrule the objection or sustain the objection. This section addresses what information the Council has to consider. @@ -136,7 +134,7 @@ Placing the burden of convincing on the objectors is supported by several consid - Treating objectors consistently. If the Council begins to accept the burden of convincing on themselves for some Objections, then to be consistent, they will need to accept the burden for all objectors. That would be a tremendous expansion of scope for Formal Objections. - Workload. If the W3C Council begins to accept the burden of convincing on themselves, that would considerably add workload to the Council. -### [III. W3C Council Reports](#council-report) +### III. W3C Council Reports The W3C Council Decision Report section of the Process covers what information the Council is expected to provide in its report. Fundamentally, the Council needs to either: @@ -152,11 +150,11 @@ While providing guidance beyond a simple sustain/overrule decision increases the Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. -## [Best Practices](#best-practices) +## Best Practices Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. -### [I. Thoroughness](#thoroughness) +### I. Thoroughness This includes: @@ -178,7 +176,7 @@ This includes: legitimate points raised by the party that is not favored in the ruling, but explain why they are not decisive.

    -### [II. Fairness](#fairness) +### II. Fairness This includes: @@ -211,7 +209,7 @@ This includes: into consideration in terms of the best solution for the Web.

    -### [III. Communications](#communications) +### III. Communications This includes: diff --git a/editor/role.md b/editor/role.md index 505200869..0a6f5130e 100644 --- a/editor/role.md +++ b/editor/role.md @@ -5,7 +5,7 @@ toc: false The role of the editor is not that of author. They maintain the text of a current draft that the Group has agreed to and possibly to suggest concrete wording when none is forthcoming from the group. -Specification editors are [appointed by the Group Chair](https://www.w3.org/Guide/chair/role.html). +Specification editors are [appointed by the Group Chair](../chair/role.html).

    Role of the editor

    diff --git a/teamcontact/liaison-role.md b/teamcontact/liaison-role.md index f2f5acae9..c8459f46f 100644 --- a/teamcontact/liaison-role.md +++ b/teamcontact/liaison-role.md @@ -5,11 +5,13 @@ toc: false The [Staff Contact](staff-contact) for a Working Group, with the [Chair's](chairs-role) assistance, appoints a liaison as needed where two groups have strong dependencies; see the list of [W3C liaisons](/2001/11/StdLiaison). The Liaison's primary role is to facilitate resolution of the dependency between the two groups. -An overall question: is there always a "Group A" & "Group B," in other words a "home" group that is having its requirements considered in a "host" (or 'target'??) group, or is the liaisoning relationship sometimes completely mutual? +An overall question: is there always a "Group A" & "Group B," in other words a "home" group that is having its requirements considered in a "host" (or 'target'??) group, or is the liaisoning relationship sometimes completely mutual? + ## Ensures adequate Dependency statement -- Is familiar with [W3C Process](/policies/process/) and [Member Guide](../Guide). +- Is familiar with [W3C Process](/policies/process/) and [Member Guide](../). + - Reviews (hopefully) existing dependency statement, otherwise ensures that appropriate dependency statement is written. - Contributes additional ideas to dependency statement as needed to update or make more accurate. @@ -19,7 +21,8 @@ An overall question: is there always a "Group A" & "Group B," in other words - Monitors status of technical issues related to areas of dependency. - Maintains coordination with Chairs of both Groups. -## Keep each Group informed of the other's requirements & timelines +## Keep each Group informed of the other's requirements & timelines + - Notifies either group when dependency issues need discussion/negotiation. - Explain, or ensures explanation of, technology or requirements of the other Group as needed (e.g., a tutorial, for instance of Group B's technology for Group A's requirements exploration) diff --git a/teamcontact/role.md b/teamcontact/role.md index 749239389..f46b60f71 100644 --- a/teamcontact/role.md +++ b/teamcontact/role.md @@ -11,7 +11,7 @@ W3C designates a Team Contact ("Contact") for every W3C Working Group and Intere Coordination and communication is a primary role for the Team Contact, who acts as the interface between the Group Chair ("Chair"), Group Members, other Working Groups, and the W3C Team: -> The team contact role is largely one of communication. This involves becoming as aware as possible of the technical requirements and issues in the group, and simultaneously being aware of the general [architecture of the Web](/TR/webarch) as evolving in the other work of W3C. This is of course a general responsibility of the group - and the chair and group members have this duty too. The staff contact has the benefit of being employed full time in W3C, and having access to other team members. The team contact's existence does not dilute in any way the group's obligation to ensure the technology interoperates with that of other groups. \[*TimBL 2001-09-11*] +{% include quote.html content="The team contact role is largely one of communication. This involves becoming as aware as possible of the technical requirements and issues in the group, and simultaneously being aware of the general [architecture of the Web](/TR/webarch) as evolving in the other work of W3C. This is of course a general responsibility of the group - and the chair and group members have this duty too. The staff contact has the benefit of being employed full time in W3C, and having access to other team members. The team contact's existence does not dilute in any way the group's obligation to ensure the technology interoperates with that of other groups. " footer="TimBL 2001-09-11" %} The Team Contact is also charged with representing the views of the Team to the Working group. Just as all Members do not have the same views, neither does all the Team. The Team Contact collects the various viewpoints and summarizes them so that the Working Group benefits from the widest range of inputs. Where the Team does not have a single position, it is inappropriate to merely abstain. Instead, the various points of view should be summarized. For a good example of Team input where the Team did not have consensus, see [Team response on the 'canvas' element](https://lists.w3.org/Archives/Public/public-html/2007Nov/0449.html). diff --git a/transitions/details.md b/transitions/details.md index 7535c897b..645b95eba 100644 --- a/transitions/details.md +++ b/transitions/details.md @@ -15,7 +15,7 @@ Exceptions to these processes MAY be authorized by [@w3c/transitions](https://gi The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.txt). -## Roles ## +## Roles
    Webmaster From 57c072dd36da2188ef9cd1b288230aa244b04d73 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 16:45:29 +0100 Subject: [PATCH 034/225] Update chair/role.md Co-authored-by: Ted Thibodeau Jr --- chair/role.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/chair/role.md b/chair/role.md index d6ce398fa..2a080ee92 100644 --- a/chair/role.md +++ b/chair/role.md @@ -25,14 +25,13 @@ Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies ### Coordinates with W3C Team and other W3C Working Groups as needed -- Maintains close coordination with W3C Staff Contact*.* +- Maintains close coordination with W3C *Staff Contact.* - Maintains coordination with assigned liaisons from other W3C working groups. - Participates in the Chairs mailing list ([archive](https://lists.w3.org/Archives/Member/chairs/)) and attends Chairs meetings. - - *the team contact should make sure the chair is in the* [*chairs group*](/admin/othergroups/31972/show) (should be managed automatically) -- Works with the Communications Team and Staff Contact in preparing press release. + *the Team Contact should make sure the Chair is in the [Chairs group](/admin/othergroups/31972/show)* (should be managed automatically) +- Works with the Communications Team and Team Contact in preparing press release. - Communicates with the press, when necessary and appropriate, and with prior coordination with the communication team, on behalf of the group. -- *Ensures* all participants have proper access to Group data *with assistance from Staff Contact.* +- *Ensures all participants have proper access to Group data with assistance from Staff Contact.* ### Maintains Group Process & Organization From 9854682cf16022e0da069c4f44ac8ced9b3a6aba Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 16:57:48 +0100 Subject: [PATCH 035/225] Update Markdown for definitions list --- transitions/details.md | 45 ++++++++++++++---------------------------- 1 file changed, 15 insertions(+), 30 deletions(-) diff --git a/transitions/details.md b/transitions/details.md index 645b95eba..acbe79890 100644 --- a/transitions/details.md +++ b/transitions/details.md @@ -17,35 +17,20 @@ The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, ** ## Roles -
    -
    Webmaster -
    The Webmaster publishes documents.
    - -
    @w3c/transitions
    -
    Transition approvals are given by @w3c/transitions, - under the delegation from Technical issues Lead Team.
    - -
    Chair
    -
    Group Chair responsibilities may be carried out by either the Chair -or Team Contact.
    - -
    Document Contact
    -
    The Document Contact is -either the Team Contact, the Chair, or the -document editor of the Working Group or Interest Group requesting publication. If there is no Working Group nor Interest Group, -the Maintainer Contact becomes the Document Contact. Consult the W3C -Project Management Lead if you're not sure who is the relevant -Document Contact.
    - -
    Maintainer Contact
    -
    The Maintainer - Contact is a designated individual tasked with requesting - Team's approval in order to publish a - Recommendation without a Working Group. Consult the W3C - Project Management Lead if you're not sure who is the relevant - Maintainer Contact. (Note: as of January 2018, the maintainer - contact is plh)
    -
    +Webmaster +: The _Webmaster_ publishes documents. + +@w3c/transitions +: Transition approvals are given by [@w3c/transitions](https://github.com/orgs/w3c/teams/transitions), under the delegation from [Technical issues Lead Team](/Guide/process/tilt/). + +Chair +: Group Chair responsibilities may be carried out by either the Chair or Team Contact. + +Document Contact +: The _Document Contact_ is either the Team Contact, the Chair, or the document editor of the Working Group or Interest Group requesting publication. If there is no Working Group nor Interest Group, the [Maintainer Contact](#MaintainerContact) becomes the _Document Contact_. Consult the [W3C Project Management Lead](mailto:team-project@w3.org) if you're not sure who is the relevant Document Contact. + +Maintainer Contact +: The _Maintainer Contact_ is a designated individual tasked with requesting Team's approval in order to publish a Recommendation without a Working Group. Consult the [W3C Project Management Lead](mailto:team-project@w3.org) if you're not sure who is the relevant Maintainer Contact. (Note: as of January 2018, the maintainer contact is [plh](mailto:plh@w3.org)) See also the [W3C Editor's Home Page](/Guide/editor/) and Guidebook documentation of [roles of W3C participants](#roles), including the [Chair's role](/Guide/chair/role) and the [Team Contact's role](/Guide/teamcontact/role). @@ -83,4 +68,4 @@ Please contact the Communications Team at w3t-comm@w3.org (cc'ing the group's Te [20031201](/2003/12/01-transitions): Version sent for review with 24 Dec 2003 Process Document. -[20030501](/2003/05/Transitions): Version published with June 2003 Process Document. \ No newline at end of file +[20030501](/2003/05/Transitions): Version published with June 2003 Process Document. From df9eff8a0e7a10d0fa55e36c98fbde7359e9550c Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 10 Dec 2024 17:19:35 +0100 Subject: [PATCH 036/225] Update Markdown for definitions list --- council/council.md | 98 ++++++++++++++++++++++++---------------------- 1 file changed, 51 insertions(+), 47 deletions(-) diff --git a/council/council.md b/council/council.md index 7c933fac6..facc5fe5e 100644 --- a/council/council.md +++ b/council/council.md @@ -158,80 +158,84 @@ Above we described, qualitatively, how the W3C Council should deal with Objectio This includes: -
    -
    Understanding all sides of the argument
    -

    The Team assignee and W3C Council members should be fully comfortable that they understand all sides of the argument. +Understanding all sides of the argument +: The Team assignee and W3C Council members should be fully comfortable that they understand all sides of the argument. In particular, the Team assignee should not begin their resolution efforts before hearing and understanding the Objections (whether or not they agree with them). - The W3C Council should not decide on the Objection until each participant feels they understand all sides of the argument.

    -
    Consultation
    -

    The assignee and W3C Council have at their disposal any stakeholder who could reasonably inform the issue. + The W3C Council should not decide on the Objection until each participant feels they understand all sides of the argument. + +Consultation +: The assignee and W3C Council have at their disposal any stakeholder who could reasonably inform the issue. This includes Working Groups, Chairs, Members, Team, and the general public. - On technical issues the TAG might be particularly useful.

    -
    Attempt to find a consensus position
    -

    The assignee and W3C Council should explore any potential paths to consensus that seem to have been overlooked. - When consensus is not possible (at all, or in a reasonable amount of time), the assignee should at least understand and clearly document why.

    -
    Analysis of all arguments raised
    -

    Although the W3C Council's published decision should be clear, well explained, and unambiguous, it should nonetheless acknowledge - legitimate points raised by the party that is not favored in the ruling, but explain why they are not decisive.

    -
    + On technical issues the TAG might be particularly useful. + +Attempt to find a consensus position +: The assignee and W3C Council should explore any potential paths to consensus that seem to have been overlooked. + When consensus is not possible (at all, or in a reasonable amount of time), the assignee should at least understand and clearly document why. + +Analysis of all arguments raised +: Although the W3C Council's published decision should be clear, well explained, and unambiguous, it should nonetheless acknowledge + legitimate points raised by the party that is not favored in the ruling, but explain why they are not decisive. ### II. Fairness This includes: -
    -
    Balance and depth
    -

    The W3C Council will be fair to all parties not by attempting to excise all preconcieved opinions, but by bringing diverse, expert viewpoints +Balance and depth +: The W3C Council will be fair to all parties not by attempting to excise all preconcieved opinions, but by bringing diverse, expert viewpoints to the debate and weighing them responsibly. The design of the W3C Council therefore optimizes for the broadest engaged participation of its members, who represent the breadth and variety - of expertise in the W3C community.

    -
    Transparency
    -

    The assignee should inform all parties that potential resolution has been delegated to the assignee. + of expertise in the W3C community. + +Transparency +: The assignee should inform all parties that potential resolution has been delegated to the assignee. In this same spirit, if the issue is referred to the W3C Council for decision, all parties must be notified. - The report with the W3C Council's decision should include the names of the subset of the Council that participated in that decision.

    -
    Adequate access
    -

    It is important for the assignee to offer all parties the opportunity to elaborate on their point of view. + The report with the W3C Council's decision should include the names of the subset of the Council that participated in that decision. + +Adequate access +: It is important for the assignee to offer all parties the opportunity to elaborate on their point of view. For example, although the Objection is already available in written form, the assignee should at least offer an opportunity to the objector to have a 1:1 conversation. All parties should be invited to key meetings where the assignee assesses whether a possible resolution proposal can gain consensus. - If a decision goes to the W3C Council, all participants should see the assignee's report before it goes to the W3C Council.

    -
    Consideration of under-represented views
    -

    The assignee and W3C Council should recognize that often Objections come from Web stakeholders whose views might be - under-represented where the decision is taken. Accordingly, the assignee and the W3C Council must consider all views.

    -
    Gravitas
    -

    Notwithstanding “Consideration of under-represented views”, the assignee and W3C Council should assign appropriate gravitas - to a Working Group decision that was made by the consensus of the group and consistent with the W3C Process.

    -
    Adherence to the W3C Process
    -

    Occasionally Formal Objections arise when a decision was made which did not follow the “letter” of the W3C Process. + If a decision goes to the W3C Council, all participants should see the assignee's report before it goes to the W3C Council. + +Consideration of under-represented views +: The assignee and W3C Council should recognize that often Objections come from Web stakeholders whose views might be + under-represented where the decision is taken. Accordingly, the assignee and the W3C Council must consider all views. + +Gravitas +: Notwithstanding “Consideration of under-represented views”, the assignee and W3C Council should assign appropriate gravitas + to a Working Group decision that was made by the consensus of the group and consistent with the W3C Process. + +Adherence to the W3C Process +: Occasionally Formal Objections arise when a decision was made which did not follow the “letter” of the W3C Process. Such violations are quite serious and indeed could form a valid basis for a Formal Objection. However, the W3C Council is not required to always sustain such an objection—they need to take all factors - into consideration in terms of the best solution for the Web.

    -
    + into consideration in terms of the best solution for the Web. ### III. Communications This includes: -
    -
    Publication of W3C Council decisions
    -

    W3C Council decisions form an important part of the public record; especially since they represent the most difficult areas in which +Publication of W3C Council decisions +: W3C Council decisions form an important part of the public record; especially since they represent the most difficult areas in which stakeholders could not reach consensus and the Team could not resolve the impasse. Accordingly, it is important that W3C make available for the public record: the Team report, the W3C Council decision, and supporting documentation which explain the rationale of the W3C Council decision. - (See W3C Council public records.)

    -
    Perception
    -

    The W3C Council should clearly exhibit the qualities of fairness, transparency, and thoroughness described above. + (See W3C Council public records.) + +Perception +: The W3C Council should clearly exhibit the qualities of fairness, transparency, and thoroughness described above. Depending on the nature, publicity, and degree of controversy of the Formal Objection, special effort may - need to be made to explain how these best practices were achieved, e.g., to the public.

    -
    Ongoing communications
    -

    As the Formal Objection resolution process unfolds, all parties should be apprised of the status. + need to be made to explain how these best practices were achieved, e.g., to the public. + +Ongoing communications +: As the Formal Objection resolution process unfolds, all parties should be apprised of the status. There should be no ambiguity about who is responsible for the current step or what that next step is (e.g., the Team is writing a report, the Team is waiting for the Objector or deciders to respond to some question, the W3C Council is being convened, the W3C Council is in deliberations, etc.). The W3C Council Team Contact should ensure that - such communications take place and the process continues to move forward.

    -
    + such communications take place and the process continues to move forward. -### Revision History +## Revision History -- 2023-03-30: Document created based on a draft by the [AB](https://www.w3.org/2002/ab/). \ No newline at end of file +- 2023-03-30: Document created based on a draft by the [AB](https://www.w3.org/2002/ab/). From d0732d4e9a266f8d3be39b99786500265e8b39b3 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 17:14:29 +0100 Subject: [PATCH 037/225] Update Markdown for definitions list --- chair/meetings.md | 229 +++++++++++++++++++++++----------------------- 1 file changed, 114 insertions(+), 115 deletions(-) diff --git a/chair/meetings.md b/chair/meetings.md index c8bdc7829..1c4b599eb 100644 --- a/chair/meetings.md +++ b/chair/meetings.md @@ -15,118 +15,117 @@ We met originally in November 1997 to facilitate shared context among the W3C Wo See also the [technical plenary history](../2002/09/TPOverview.html) -
    -
    20 Nov 1997
    -
    1st Working Group Chairs - Meeting - -
    -
    13 Jul 1998
    -
    The Art of Consensus II
    -
    24 Sep 1998
    -
    3rd meeting record
    -
    1 Dec 1998
    -
    4th meeting record
    -
    2 Feb 1999
    -
    5th meeting record
    -
    6 Apr 1999
    -
    6th meeting record
    -
    8 June 1999
    -
    7th meeting record
    -
    7 Sep 1999
    -
    8th meeting record
    -
    16 Nov 1999
    -
    9th meeting record
    -
    15 Sep 2000
    -
    10th meeting record
    -
    -
    20 Nov 2000
    -
    11th meeting
    -
    29 Jan 2001
    -
    12th meeting
    - agenda - log @@summary
    -
    28 February 2001
    -
    Technical - Plenary (plenary day - agenda)
    -
    Feb 2002
    -
    Tech Plenary Feb - 25-March 1 2002
    - (announcement)
    -
    23 Apr 2002
    -
    Steve Bratt re-starts chairs meetings. IRC log.
    -
    formalized - record
    -
    25 Jul 2002
    -
    meeting - record. (50+ participants!)
    -
    21 Jan 2003
    -
    meeting record (6 - Feb from C. M. Sperberg-McQueen)
    -
    3-7 March 2003 in Cambridge, MA, USA
    -
    Tech Plenary
    -
    6 May 2003 Chairs meeting
    -
    minutes
    -
    30 October 2003 Chairs meeting
    -
    minutes, IRC log
    -
    3 March 2004
    -
    Technical Plenary (plenary day minutes, Chairs - Breakfast announcement)
    -
    2 September 2004
    -
    minutes
    -
    2 March 2005
    -
    Technical Plenary Week - 2005 in Boston (minutes)
    -
    2 March 2005
    -
    Technical Plenary 2006 - in Cannes-Mandelieu (minutes)
    -
    13 March 2007
    -
    Chairs Call Teleconference (minutes)
    -
    20 September 2007
    -
    Chairs Call Teleconference (minutes)
    -
    7 November 2007
    -
    TPAC 2007 in Boston (minutes)
    -
    17 April 2008
    -
    Agenda, - Minutes
    -
    1 October 2008
    -
    Agenda, - Minutes
    -
    22 October 2008: TPAC 2008
    -
    Agenda, Minutes
    -
    15 September 2009: Chairs teleconference
    -
    Agenda, Minutes
    -
    3 November 2010: TPAC 2010
    -
    agenda, minutes
    -
    2 November 2011: TPAC 2011
    -
    agenda, minutes and breakout minutes
    -
    7 November 2017: TPAC 2017
    -
    minutes
    -
    22 October 2020: TPAC 2020
    -
    minutes
    -
    agenda, minutes and breakout minutes
    -
    1 March 2022: TPAC 2022 Preparation
    -
    agenda, minutes
    -
    15 September 2022: TPAC 2022
    -
    minutes
    -
    +20 Nov 1997 +: [1st Working Group Chairs Meeting](../Member/9711/wg-chairs.html) +- [Press and Communications](../Member/Talks/971120Press) -- Sally's presentation +- [Organizing a W3C Meeting](../meetings/hosting.html) -- Susan's presentation +- [Tim Berners-Lee's Perspective](/Member/9711/wg-chairs-intro.html) +- [The Web: Sharing, Group Memory, and Communication](WebSharing.html) -- Dan's presentation + +13 Jul 1998 +: [The Art of Consensus II](/1998/07/chairs.html) + +24 Sep 1998 +: [3rd meeting record](/1998/09/24-chairs.html) + +1 Dec 1998 +: [4th meeting record](/1998/12/01-chairs.html) + +2 Feb 1999 +: [5th meeting record](/1999/02/02-chairs.html) + +6 Apr 1999 +: [6th meeting record](/1999/04/06-chairs.html) + +8 June 1999 +: [7th meeting record](/1999/06/08-chairs.html) + +7 Sep 1999 +: [8th meeting record](/1999/09/chairs56.html) + +16 Nov 1999 +: [9th meeting record](/1999/11/chairs298.html) + +15 Sep 2000 +: [10th meeting record](/2000/09/ch53) + +20 Nov 2000 +: [11th meeting](/2000/11/ch64.html) + +29 Jan 2001 +: 12th meeting [agenda](https://lists.w3.org/Archives/Member/chairs/2001JanMar/0041.html), [IRC log](/2001/01/29-chairs-irc) + +28 February 2001 +: [Technical Plenary](/2001/02/allgroupoverview.html#Agenda1) ([plenary day agenda](/2001/02/Plenary/Agenda.html)) + +Feb 2002 +: [Tech Plenary Feb 25-March 1 2002](https://www.w3.org/2001/07/allgroupoverview) ([announcement](https://lists.w3.org/Archives/Member/chairs/2001JulSep/0034.html)) + +23 Apr 2002 +: Steve Bratt re-starts chairs meetings. [IRC log](/2002/04/23-chairs-irc) + +25 Jul 2002 +: [meeting record](https://lists.w3.org/Archives/Member/chairs/2002JulSep/0047.html). (50+ participants!) + +21 Jan 2003 +: [meeting record](../2003/01/21-chairs-notes.html) ([6 Feb from C. M. Sperberg-McQueen](https://lists.w3.org/Archives/Member/chairs/2003JanMar/0032.html)) + +3-7 March 2003 in Cambridge, MA, USA +: [Tech Plenary](/2002/10/allgroupoverview.html) + +6 May 2003 Chairs meeting +: [minutes](https://www.w3.org/2003/05/06-chair-notes.html) + +30 October 2003 Chairs meeting +: [minutes](https://www.w3.org/2003/10/31-chair-notes.html), [IRC log](https://www.w3.org/2003/10/30-chair-irc) + +3 March 2004 +: [Technical Plenary](/2003/08/allgroupoverview.html) ([plenary day minutes](/2004/03/plenary-minutes), [Chairs Breakfast announcement](https://lists.w3.org/Archives/Member/chairs/2004JanMar/0075)) + +2 September 2004 +: [minutes](/2004/09/02-chair-minutes.html) + +2 March 2005 +: [Technical Plenary Week 2005](../2004/12/allgroupoverview.html) in Boston ([minutes](https://www.w3.org/2005/03/plenary-minutes)) + +2 March 2005 +: [Technical Plenary 2006](/2005/12/allgroupoverview.html) in Cannes-Mandelieu ([minutes](/2006/03/TP-minutes.html)) + +13 March 2007 +: Chairs Call Teleconference ([minutes](https://lists.w3.org/Archives/Member/chairs/2007JanMar/0128)) + +20 September 2007 +: Chairs Call Teleconference ([minutes](https://www.w3.org/2007/09/20-chairs-minutes.html)) + +7 November 2007 +: [TPAC 2007 in Boston](https://www.w3.org/2007/11/07-TechPlenAgenda.html) ([minutes](https://www.w3.org/2007/11/07-tp-minutes.html)) + +17 April 2008 +: [agenda](https://lists.w3.org/Archives/Member/chairs/2008AprJun/0022.html), [minutes](/2008/04/17-chairs-minutes.html) + +1 October 2008 +: [agenda](https://www.w3.org/2008/10/01-chairs-minutes.html), [minutes](https://www.w3.org/2008/10/01-chairs-minutes.html) + +22 October 2008: TPAC 2008 +: [agenda](https://www.w3.org/2008/10/TPAC/TPDay-Agenda.html), [minutes](/2008/10/22-tp-minutes.html) + +15 September 2009: Chairs teleconference +: [agenda](https://lists.w3.org/Archives/Member/chairs/2009JulSep/0044.html), [minutes](/2009/09/15-chairs-minutes) + +3 November 2010: TPAC 2010 +: [agenda](https://www.w3.org/2010/11/TPAC/PlenaryAgenda#details), [minutes](https://www.w3.org/2010/11/03-tpac-minutes) + +2 November 2011: TPAC 2011 +: [agenda](https://www.w3.org/wiki/TPAC2011), [minutes](https://www.w3.org/2011/11/02-tpac-minutes) and [breakout minutes](https://www.w3.org/wiki/TPAC2011#Session_Grid) + +7 November 2017: TPAC 2017 +: [minutes](https://www.w3.org/2017/11/07-chairs-minutes.html) + +22 October 2020: TPAC 2020 +: [minutes](https://www.w3.org/2020/10/22-chairs-minutes.html) + +1 March 2022: TPAC 2022 Preparation +: [agenda](https://lists.w3.org/Archives/Member/chairs/2022JanMar/0051.html), [minutes](https://www.w3.org/2022/03/01-chairs-minutes.html) + +15 September 2022: TPAC 2022 +: [minutes](https://www.w3.org/2022/09/15-chairs-minutes.html) From 95c8a23f6d5fe3d5283b628138826059af0fbeec Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 17:19:46 +0100 Subject: [PATCH 038/225] Use the quote component --- chair/meetings.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/chair/meetings.md b/chair/meetings.md index 1c4b599eb..1ccd0e2a0 100644 --- a/chair/meetings.md +++ b/chair/meetings.md @@ -3,13 +3,7 @@ title: Chairs Meetings toc: false --- -
    -

    I am overwhelmed by the level of talent and dedication in this group.

    -
    - -- Tim Berners-Lee, at - the Nov 97 WG chairs' meeting -
    -
    +{% include quote.html content="I am overwhelmed by the level of talent and dedication in this group." footer="[Tim Berners-Lee](https://www.w3.org/People/Berners-Lee), at the [Nov 97 WG chairs' meeting](../Member/9711/wg-chairs.html)" %} We met originally in November 1997 to facilitate shared context among the W3C Working Group Chairs and the W3C Team. We did a few more face-to-face meetings and several teleconferences. From 5d71921574d0ddf58433efd358a913f6aaba5a3d Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 17:43:24 +0100 Subject: [PATCH 039/225] Update Markdown for definitions list --- editor/role.md | 84 +++++++++++++------------------------------------- 1 file changed, 22 insertions(+), 62 deletions(-) diff --git a/editor/role.md b/editor/role.md index 0a6f5130e..49d4c38ab 100644 --- a/editor/role.md +++ b/editor/role.md @@ -2,76 +2,36 @@ title: W3C Specification Editor toc: false --- - The role of the editor is not that of author. They maintain the text of a current draft that the Group has agreed to and possibly to suggest concrete wording when none is forthcoming from the group. Specification editors are [appointed by the Group Chair](../chair/role.html). -
    -

    Role of the editor

    +## Role of the editor + +The specification editor have all the responsibilities of the author but none of the rights: + +- Must maintain the draft on behalf of the Group, since the intellectual responsibility for the specification should remain with the Group +- Need to be willing to write into the draft whatever the group decides, even if they personally would prefer something else. + +In practice, a specification editor will tend to have some leeway in matters which the Group does not explicitly decide, and it would be a very unusual editor who is not ipso facto an influential voice in Group deliberations. Editors need to practice egoless writing and draftsmanship in much the same way that some programming disciplines encourage egoless programming. + +## Workmode + +There are at least two ways to deal with the initial creation of a working draft for a spec or other document, which may be worth distinguishing. -

    The specification editor have all the responsibilities of the author - but none of the rights:

    +Text follows design decisions +: This approachs requires (or at least expects) that design decisions will be made **before** drafting the relevant sections of a spec. -
      -
    • Must maintain the draft on behalf of the Group, since the intellectual responsibility - for the specification should remain with the Group
    • -
    • Need to be willing to write into the draft whatever the group decides, even - if they personally would prefer something else.
    • -
    + It places more emphasis on design discussions **before** drafting, and requires more editorial deference to the Group. -

    In practice, a specification editor will tend to have some leeway in matters which - the Group does not explicitly decide, and it would be a very unusual editor who is not -ipso facto an influential voice in Group deliberations. Editors need to practice egoless -writing and draftsmanship in much the same way that some programming disciplines -encourage egoless programming.

    -
    +Text precedes design decisions +: This approach regards design decisions as best made in the form of revision, replacement, or approval of some existing text, and thus requires (or at least expects) that a draft text will be created **before** design decisions are made. -
    -

    Workmode

    + It places more responsibility and power in the editors' hands and insists less on editorial deference. -

    -There are at least two ways to deal with the initial creation of a -working draft for a spec or other document, which may be worth -distinguishing. -

    -
    -
    Text follows design decisions
    -
    -

    This approachs requires (or at least expects) that design -decisions will be made *before* drafting the relevant sections of a -spec.

    -

    It places more emphasis on design discussions *before* drafting, and -requires more editorial deference to the Group.

    -
    -
    Text precedes design decisions
    -
    -

    - This approach regards design decisions as best made in the form of -revision, replacement, or approval of some existing text, and thus -requires (or at least expects) that a draft text will be created -*before* design decisions are made. -

    -

    It places more responsibility -and power in the editors' hands and insists less on editorial -deference. -

    -

    -A specification editor may have proposed text for the draft: -

    -
      -
    • in a separate space (such as a pull request) and incorporate the text -once a Group decision has been made; -
    • -
    • or, in the specification draft itself and request Group decision to validate -it.
    • -
    + A specification editor may have proposed text for the draft: -

    Note that once a draft is complete, the two approaches tend to -converge, though views may differ over whether it's essential, or only -desirable, to provide specific replacement wording for any proposed -change to a draft, before the proposed change is discussed.

    + - in a separate space (such as a pull request) and incorporate the text once a Group decision has been made; + - or, in the specification draft itself and request Group decision to validate it. -
    -
    -
    + Note that once a draft is complete, the two approaches tend to converge, though views may differ over whether it's essential, or only desirable, to provide specific replacement wording for any proposed change to a draft, before the proposed change is discussed. From ce2e4338f568fa14e63cd3bce1dd818c86984c2d Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 18:06:29 +0100 Subject: [PATCH 040/225] Fix headings levels --- documentreview/index.md | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 9b736ca79..0246de43d 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -21,13 +21,13 @@ toc: true ## How to do Wide Review + Getting early and wide review of a document is very important, yet in practice it can be challenging. This document provides some best practices for getting document review; it does not define explicit mandatory steps. This page is linked to from [The Guide](https://www.w3.org/Guide/). See also the [Wide Review](https://www.w3.org/policies/process/#wide-review) section in the W3C Process document. -Feedback on this document is welcome, preferably by [raising an issue](https://github.com/w3c/documentreview/issues) or a pull request. +## When should wide review be requested? -### When should wide review be requested? A document is available for review from the moment it is first [published](https://www.w3.org/policies/process/#publishing). Working Groups should [formally address](https://www.w3.org/policies/process/#formally-addressed) any substantive review comment about a technical report in a timely manner. Wide review should or must be requested: @@ -43,7 +43,7 @@ Wide review should or must be requested: * When a document is both reasonably stable and still flexible enough to allow changes where issues are identified. * When new features are added after a document has already received wide review (perhaps requesting a review limited to the new features). -### Who to ask for wide review? +## Who to ask for wide review? The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have adequate notice of the progress of the Working Group and are genuinely able to perform reviews of and provide comments on the specification. When considering [requests to advance the maturity level of the document](https://www.w3.org/Guide/transitions), the Team will consider who has been explicitly offered a reasonable opportunity to review the document. @@ -79,7 +79,7 @@ dependencies. The reviews provided by the [horizontal groups](/Guide/process/horizontal-groups.html), a subset of a full wide review, do receive special attention and much of the rest of this document focuses on how and when to conduct horizontal reviews. -### How to get horizontal review +## How to get horizontal review When you have published a First Public Working Draft, you should work through available "self-review" materials and request review of your results in at least the following areas. Long enough before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review. During the [Last Call for Review of Proposed Amendment](https://www.w3.org/policies/process/#change-review), you should also do the same. @@ -101,8 +101,6 @@ The meaning of "Long enough" depends on how many changes there are, how clearly
  • Media Accessibility User Requirements; PFWG
  • - -
    Architecture
    Ask the TAG for review; see how to work with the TAG. @@ -177,11 +175,12 @@ You should familiarize yourself with the rest of this document. This section is Recognize that horizontal review groups may be resource limited and may only be able to do one review or may have difficulty scheduling your review quickly. Give them as much time as you can, consistent with asking for review while it is still reasonable to change the technology to accommodate the issues they find. -### Working with Horizontal Review labels +## Working with Horizontal Review labels Applying these labels doesn't replace the need to schedule a review of your spec at an appropriate time. (See [How to Get Horizontal Review](https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review) above.) Horizontal groups participants can find [detailed process information here](https://w3c.github.io/horizontal-issue-tracker/HOWTO). -#### Day-to-day use of labels +### Day-to-day use of labels + Apply the *-tracker label in your own repository to draw a horizontal review group’s attention to an issue in one of your own repositories. Horizontal review groups may also apply the label if they are interested in tracking a particular issue. Tooling will automatically notify the horizontal group that you attached the label. If you want some specific advice from the horizontal group, describe that request in the issue thread. @@ -190,28 +189,29 @@ Horizontal review groups may apply the \*-needs-resolu If the [horizontal group](/Guide/process/horizontal-groups.html) believes that an issue with a \*-tracker label needs to be resolved before a transition, they may apply a \*-needs-resolution label to the issue. Automatic tooling will later remove the \*-tracker label. - If you close an issue with a \*-tracker or \*-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.) +If you close an issue with a \*-tracker or \*-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.) - At the end of a review, and before attempting to transition the spec, you should clarify that a resolution is described for all of the issues with a \*-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the \*-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.) +At the end of a review, and before attempting to transition the spec, you should clarify that a resolution is described for all of the issues with a \*-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the \*-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.) - Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (+) in the issue description, +\*-tracker or +\*-needs-resolution. +Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (+) in the issue description, +\*-tracker or +\*-needs-resolution. -#### What happens with *-needs-resolution issues at transition? +### What happens with *-needs-resolution issues at transition? When a Working Group requests a new Maturity level, the transition will not be approved if a horizontal group has an open *-needs-resolution issue showing on the [tracker boards](https://www.w3.org/PM/horizontal/). Note that the tracker monitors the horizontal group's copy of the issue. Before requesting a new Maturity level, the Working Group is advised to review the tracker and contact the horizontal group to close any lingering issues. -#### What happens to unresolved issues marked \*-needs-resolution? +### What happens to unresolved issues marked \*-needs-resolution? As lead technical architect, the W3C Council is tasked (among many things) to assess consensus within W3C for architectural issues and to decide on the outcome of [Formal Objections](https://www.w3.org/2019/Process-20190301/#FormalObjection). When a horizontal issue gets flagged as *-needs-resolution and a Group chooses to request a new Maturity level despite the lack of consensus with the horizontal group, it is the task of the W3C Team to assess the issue and the outcome of the request. A horizontal group MAY choose to elevate an horizontal issue as a Formal Objection to elevate further the importance of an issue per the W3C Process. In the case where an horizontal issue hasn’t been addressed and the document was allowed to move forward, it is recommended that the issue remains open in the horizontal group repository (it MAY get closed in the specification repository unless the W3C Team requests otherwise). Some issues may take years to get resolved, but that doesn’t mean those should be forgotten.

    -### Issue trackers +## Issue trackers + The horizontal groups maintain repositories containing issues that track those raised in the WG repos. You can see a list of tracked issues on the [tracker boards](https://w3c.github.io/horizontal-issue-tracker/index), one per horizontal area. Horizontal groups participants can find [detailed process information here](https://w3c.github.io/horizontal-issue-tracker/HOWTO). -### FAQ +## FAQ
    Q: Is security and/or privacy review mandatory before a First Public Working Draft is published?
    @@ -241,7 +241,7 @@ Horizontal groups participants can find [detailed process information here](http
  • A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.
  • -### Common mistakes when making a transition request +## Common mistakes when making a transition request 1. If you make substantive changes, you'll need to do a wide review for those before you move forward to the [next maturity stage](https://www.w3.org/Guide/documentreview/#who_to_ask_for_review). 2. Never ever exclude some [horizontal groups](/Guide/process/horizontal-groups.html) from your review requests because you concluded it was irrelevant for them or they haven't responded to your last request. @@ -256,8 +256,8 @@ Horizontal groups participants can find [detailed process information here](http They may not even be able to find someone with availability to do the review in that time, and then they need a week or two to discuss their response after the review, and then they'll send you comments that may require you to make substantive changes. +## Terminology and abbreviations -### Terminology and abbreviations * pre-CR - This is a version of a Working Draft that is created to get wide review. * note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [Charles McCathie Nevile](https://www.w3.org/wiki/User:Charles" title="User:Charles) 11:18, 13 October 2014 (UTC) * requesting group - a group that is requesting a review @@ -269,10 +269,13 @@ Abbreviations: * [TR](https://www.w3.org/TR/) = Technical Report, i.e. a formal W3C publication. * WD = Working Draft +## Enhancement Requests -### Enhancement Requests See the [Document Review Dashboard](https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard) document for information about creating a dashboard type service to facilitate document reviews. +<<<<<<< HEAD
    See the [commit history](https://github.com/w3c/Guide/tree/main/documentreview).
    +======= +>>>>>>> 1885fa3 (Fix headings levels) From 0a5a1443f7f4fdac5d3f317834c77c2b4e1356c3 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 18:10:45 +0100 Subject: [PATCH 041/225] Update Markdown for definitions list in teh FAQ section --- documentreview/index.md | 39 ++++++++++++++++----------------------- 1 file changed, 16 insertions(+), 23 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 0246de43d..52d6e9e81 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -213,33 +213,26 @@ Horizontal groups participants can find [detailed process information here](http ## FAQ -
    -
    Q: Is security and/or privacy review mandatory before a First Public Working Draft is published?
    -
    -
      -
    • A: It is strongly encouraged but not required. Resolving security and privacy issues can require significant changes in specs, so it helps to identify them early.
    • -
    -
    +Is *security* and/or *privacy* review mandatory before a *First Public Working Draft* is published? +: It is **strongly encouraged** but not required. Resolving security and privacy issues can require significant changes in specs, so it helps to identify them early. -
    Q: Does a group need to prove its documents have had wide review before proceeding to CR?
    -
    -
      -
    • A: Yes, since Process-2019.
    • -
    -
    +Does a group need to prove its documents have had wide review before proceeding to CR? +: Yes, since Process-2019. -
    Q: How does a group prove its documents have had wide review before proceeding to CR?
    -
    • A: Requests to the horizontal review groups will appear in Github, as above.
    • -
    • A: Keep a Disposition of Comments (DoC) Document showing comments received and a summary of their resolution.
    +How does a group prove its documents have had wide review before proceeding to CR? +: Requests to the horizontal review groups will appear in Github, as above. -
    Q: Is there such a thing as too many reviews?
    -
    • A: Not really
    + Keep a Disposition of Comments (DoC) Document showing comments received and a summary of their resolution. -
    Q: Is it possible to make too many requests for review?
    -
    • A: Yes. To help the review groups, only request updated reviews when substantive changes have been made, and clearly identify the changes since the last review.
    • -
    • A: This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a spec…
    • -
    • A: TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience.
    -
    +Is there such a thing as too many reviews? +: Not really + +Is it possible to make too many requests for review? +: Yes. To help the review groups, only request updated reviews when substantive changes have been made, and clearly identify the changes since the last review. + + This is also the reason that the Process clearly suggests there should be (TR) Working Drafts published when there are "significant changes that would benefit from review beyond the Working Group", rather than every day or only twice in the life of a spec… + + TR Working Drafts are also useful for reviews since they provide a dated snapshot which can be recovered when the review comments are being discussed. Trying to discuss review comments against a document which has changed out of all recognition can be a frustrating and inefficient experience. ## Common mistakes when making a transition request From 19a0de43fce39fa65b0ebc5f9a8b2052b0236a18 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 18:18:33 +0100 Subject: [PATCH 042/225] Use Markdown for definitions list in the Terminology and abbreviations section --- documentreview/index.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 52d6e9e81..746082cf8 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -249,11 +249,15 @@ Is it possible to make too many requests for review? They may not even be able to find someone with availability to do the review in that time, and then they need a week or two to discuss their response after the review, and then they'll send you comments that may require you to make substantive changes. -## Terminology and abbreviations +## Terminology and abbreviations -* pre-CR - This is a version of a Working Draft that is created to get wide review. - * note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. [Charles McCathie Nevile](https://www.w3.org/wiki/User:Charles" title="User:Charles) 11:18, 13 October 2014 (UTC) -* requesting group - a group that is requesting a review +pre-CR +: This is a version of a Working Draft that is created to get wide review. + + > Note that this is a bad way to get review. In general, features should be reviewed as they are developed. Waiting for a "Last Call" for most review means that when reviews suggest changes it is far harder to make them, due to a commonly observed and logical reluctance to break deployed systems or content. -- [Charles McCathie Nevile](https://www.w3.org/wiki/User:Charles) 11:18, 13 October 2014 (UTC) + +requesting group +: a group that is requesting a review Abbreviations: * BP = Best Practices From 200628f956ca093ef7335987b0a0a4cfc5d46250 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 18:19:40 +0100 Subject: [PATCH 043/225] Let markdown processor handle ordered list numbers --- documentreview/index.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 746082cf8..3fe019b3a 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -237,15 +237,15 @@ Is it possible to make too many requests for review? ## Common mistakes when making a transition request 1. If you make substantive changes, you'll need to do a wide review for those before you move forward to the [next maturity stage](https://www.w3.org/Guide/documentreview/#who_to_ask_for_review). -2. Never ever exclude some [horizontal groups](/Guide/process/horizontal-groups.html) from your review requests because you concluded it was irrelevant for them or they haven't responded to your last request. +1. Never ever exclude some [horizontal groups](/Guide/process/horizontal-groups.html) from your review requests because you concluded it was irrelevant for them or they haven't responded to your last request. Let them make the decision that something is irrelevant to their field of expertise instead. You're welcome to time out if you don't hear back, and request to move forward anyway. -3. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews. +1. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews. It's better for a Group to miss the fact that you fixed an issue in your editor's draft than the Team missing the fact you made an unreviewed substantive change in your editor's draft. -4. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you can close the issue though, if it is resolved). +1. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you can close the issue though, if it is resolved). Those are intended solely to be used by [horizontal groups](/Guide/process/horizontal-groups.html) to [bring special attention](https://www.w3.org/Guide/documentreview/#What_happens_to_unresolved_issues_marked_needs-resolution). -5. Don't assume that the horizontal group will be able to schedule and complete a review within 2 weeks so that you can proceed to CR. +1. Don't assume that the horizontal group will be able to schedule and complete a review within 2 weeks so that you can proceed to CR. They may not even be able to find someone with availability to do the review in that time, and then they need a week or two to discuss their response after the review, and then they'll send you comments that may require you to make substantive changes. @@ -270,9 +270,4 @@ Abbreviations: See the [Document Review Dashboard](https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard) document for information about creating a dashboard type service to facilitate document reviews. -<<<<<<< HEAD -
    See the [commit history](https://github.com/w3c/Guide/tree/main/documentreview).
    - -======= ->>>>>>> 1885fa3 (Fix headings levels) From ed544e6dbab231ee779a65d366e95d0da35a5c4b Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 18:49:21 +0100 Subject: [PATCH 044/225] More Markdown usage and fixes --- documentreview/index.md | 36 +++++++++++++++++------------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 3fe019b3a..e4cc0ce07 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -22,9 +22,9 @@ toc: true ## How to do Wide Review -Getting early and wide review of a document is very important, yet in practice it can be challenging. This document provides some best practices for getting document review; it does not define explicit mandatory steps. +Getting *early* and *wide* review of a document is very important, yet in practice it can be challenging. This document provides some best practices for getting document review; it does not define explicit mandatory steps. -This page is linked to from [The Guide](https://www.w3.org/Guide/). See also the [Wide Review](https://www.w3.org/policies/process/#wide-review) section in the W3C Process document. +See also the [Wide Review](https://www.w3.org/policies/process/#wide-review) section in the W3C Process document. ## When should wide review be requested? @@ -35,8 +35,7 @@ Wide review should or must be requested: Working Groups are often reluctant to make substantive changes to a mature document, so reviewers should get a chance to send substantive technical - reviews as early as possible. This is especially important for horizontal reviews. + reviews as early as possible. This is especially important for [horizontal reviews](#how-to-get-horizontal-review). * Before a document gets advanced to [Candidate Recommendation](https://www.w3.org/policies/process/#transition-cr), gets updated as a [Candidate Recommendation Snapshot](https://www.w3.org/policies/process/#update-requests) or gets updated as a [Recommendation](https://www.w3.org/policies/process/20231103/#change-review). For those, the [W3C Process](https://www.w3.org/policies/process/) requires a Group to show that the specification has received wide review. @@ -47,21 +46,21 @@ Wide review should or must be requested: The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have adequate notice of the progress of the Working Group and are genuinely able to perform reviews of and provide comments on the specification. When considering [requests to advance the maturity level of the document](https://www.w3.org/Guide/transitions), the Team will consider who has been explicitly offered a reasonable opportunity to review the document. -You must publish an updated technical report, with the Status of the Document indicating clearly that you're looking for wide review, before inviting review from other stakeholders. Our tooling monitors publications and propagates notifications to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) automatically (for example, Candidate Recommendation Snapshot: Payment Request API (Call for Wide Review)). +You **must** publish an updated technical report, with the Status of the Document indicating clearly that you're looking for *wide review*, before inviting review from other stakeholders. Our [tooling](https://github.com/w3c/transition-notifier/blob/main/notify.js) monitors publications and propagates notifications to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) automatically (for example, [Candidate Recommendation Snapshot: Payment Request API (Call for Wide Review)](https://lists.w3.org/Archives/Public/public-review-announce/2021Jun/0008.html)). You should then inform, and request reviews from: * the groups listed in the WG's charter, especially those who manage dependencies. * the groups jointly responsible for a particular document (if any). -* the [horizontal groups](/Guide/process/horizontal-groups.html) using the [method described below](#how_to_get_horizontal_review). Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below +* the [horizontal groups](/Guide/process/horizontal-groups.html) using the [method described below](#how_to_get_horizontal_review). *Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below* * the general public, including Web developers, technology providers and implementers, application developers, etc. Consider: * sending a dedicated announcement to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) if needed (in case the default notice sent to that list is not enough). * using blog posts, social media, or other ways of alerting the public to your document and requesting feedback. * other groups, at your discretion, even if not in the WG charter, such as other W3C groups, external organizations and SSOs working on related areas, etc. -Tip: consider tracking your wide review progress using a GitHub issue, such as [issue #299 of the Sensors API](https://github.com/w3c/sensors/issues/299). You can then simply point the Team to the issue. +**Tip:** consider tracking your wide review progress using a GitHub issue, such as [issue #299 of the Sensors API](https://github.com/w3c/sensors/issues/299). You can then simply point the Team to the issue. - The reviews provided by the [horizontal groups](/Guide/process/horizontal-groups.html), a subset of a full wide review, do receive special attention and much of the rest of this document focuses on how and when to conduct horizontal reviews. ## How to get horizontal review When you have published a First Public Working Draft, you should work through available "self-review" materials and request review of your results in at least the following areas. -Long enough before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review. During the [Last Call for Review of Proposed Amendment](https://www.w3.org/policies/process/#change-review), you should also do the same. +*Long enough* before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review. During the [Last Call for Review of Proposed Amendment](https://www.w3.org/policies/process/#change-review), you should also do the same. -The meaning of "Long enough" depends on how many changes there are, how clearly you have explained them, and how much discussion is needed to resolve issues. Pointing to 14 concise points for a small spec means a short time if they are simple fixes, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a long time to get review, and potentially a long time to also discuss and agree on how to solve the issues. If you have effectively identified issues for review during development and received feedback on them, the review time will probably be shorter. Horizontal review groups sometimes get bogged down; planning in advance is useful. +The meaning of "Long enough" depends on how many changes there are, how clearly you have explained them, and how much discussion is needed to resolve issues. Pointing to 14 concise points for a small spec means a short time if they are simple fixes, pointing to 900 diffs from commits and hoping people understand them in a 300 page spec means it will take a **long** time to get review, and potentially a long time to also discuss and agree on how to solve the issues. If you have effectively identified issues for review during development and received feedback on them, the review time will probably be shorter. Horizontal review groups sometimes get bogged down; planning in advance is useful.
    Accessibility
    @@ -177,7 +175,7 @@ Recognize that horizontal review groups may be resource limited and may only be ## Working with Horizontal Review labels -Applying these labels doesn't replace the need to schedule a review of your spec at an appropriate time. (See [How to Get Horizontal Review](https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review) above.) Horizontal groups participants can find [detailed process information here](https://w3c.github.io/horizontal-issue-tracker/HOWTO). +Applying these labels doesn't replace the need to schedule a review of your spec at an appropriate time. (See [How to Get Horizontal Review](#how-to-get-horizontal-review) above.) Horizontal groups participants can find [detailed process information here](https://w3c.github.io/horizontal-issue-tracker/HOWTO). ### Day-to-day use of labels @@ -193,17 +191,17 @@ If you close an issue with a \*-tracker or \*-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the \*-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.) -Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (+) in the issue description, +\*-tracker or +\*-needs-resolution. +Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (`+`) in the issue description, `+*-tracker` or `+*-needs-resolution`. -### What happens with *-needs-resolution issues at transition? +### What happens with `*-needs-resolution` issues at transition? -When a Working Group requests a new Maturity level, the transition will not be approved if a horizontal group has an open *-needs-resolution issue showing on the [tracker boards](https://www.w3.org/PM/horizontal/). Note that the tracker monitors the horizontal group's copy of the issue. Before requesting a new Maturity level, the Working Group is advised to review the tracker and contact the horizontal group to close any lingering issues. +When a Working Group requests a new Maturity level, the transition **will not be approved** if a horizontal group has an open `*-needs-resolution` issue showing on the [tracker boards](https://www.w3.org/PM/horizontal/). Note that the tracker monitors the horizontal group's *copy* of the issue. Before requesting a new Maturity level, the Working Group is advised to review the tracker and contact the horizontal group to close any lingering issues. -### What happens to unresolved issues marked \*-needs-resolution? +### What happens to unresolved issues marked `*-needs-resolution`? -As lead technical architect, the W3C Council is tasked (among many things) to assess consensus within W3C for architectural issues and to decide on the outcome of [Formal Objections](https://www.w3.org/2019/Process-20190301/#FormalObjection). When a horizontal issue gets flagged as *-needs-resolution and a Group chooses to request a new Maturity level despite the lack of consensus with the horizontal group, it is the task of the W3C Team to assess the issue and the outcome of the request. A horizontal group MAY choose to elevate an horizontal issue as a Formal Objection to elevate further the importance of an issue per the W3C Process. +As lead technical architect, the W3C Council is tasked (among many things) to assess consensus within W3C for architectural issues and to decide on the outcome of [Formal Objections](https://www.w3.org/policies/process/#FormalObjection). When a horizontal issue gets flagged as `*-needs-resolution` and a Group chooses to request a new Maturity level despite the lack of consensus with the horizontal group, it is the task of the W3C Team to assess the issue and the outcome of the request. A horizontal group MAY choose to elevate an horizontal issue as a Formal Objection to elevate further the importance of an issue per the W3C Process. -In the case where an horizontal issue hasn’t been addressed and the document was allowed to move forward, it is recommended that the issue remains open in the horizontal group repository (it MAY get closed in the specification repository unless the W3C Team requests otherwise). Some issues may take years to get resolved, but that doesn’t mean those should be forgotten.

    +In the case where an horizontal issue hasn’t been addressed and the document was allowed to move forward, it is recommended that the issue remains open in the horizontal group repository (it MAY get closed in the specification repository unless the W3C Team requests otherwise). Some issues may take years to get resolved, but that doesn’t mean those should be forgotten. ## Issue trackers @@ -242,7 +240,7 @@ Is it possible to make too many requests for review? Let them make the decision that something is irrelevant to their field of expertise instead. You're welcome to time out if you don't hear back, and request to move forward anyway. 1. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews. It's better for a Group to miss the fact that you fixed an issue in your editor's draft than the Team missing the fact you made an unreviewed substantive change in your editor's draft. -1. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you can close the issue though, if it is resolved). +1. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you *can* close the issue though, if it is resolved). Those are intended solely to be used by [horizontal groups](/Guide/process/horizontal-groups.html) to [bring special attention](https://www.w3.org/Guide/documentreview/#What_happens_to_unresolved_issues_marked_needs-resolution). 1. Don't assume that the horizontal group will be able to schedule and complete a review within 2 weeks so that you can proceed to CR. From 07fe46307551b21d27292399178e5a84f84ee9e5 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 18:56:00 +0100 Subject: [PATCH 045/225] Replace the 'githublabel' class by the 'tag' class from the W3C Design System --- documentreview/index.md | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index e4cc0ce07..a40d339f1 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -11,13 +11,6 @@ toc: true padding: 1em 1em; background: #e2edfe; } - -.githublabel { - font-weight: bold; - border: 1px solid gray; - border-radius: .5em; - padding: 2px 5px; -} ## How to do Wide Review @@ -179,17 +172,17 @@ Applying these labels doesn't replace the need to schedule a review of your spec ### Day-to-day use of labels -Apply the *-tracker label in your own repository to draw a horizontal review group’s attention to an issue in one of your own repositories. Horizontal review groups may also apply the label if they are interested in tracking a particular issue. Tooling will automatically notify the horizontal group that you attached the label. +Apply the \*-tracker label in your own repository to draw a horizontal review group’s attention to an issue in one of your own repositories. Horizontal review groups may also apply the label if they are interested in tracking a particular issue. Tooling will automatically notify the horizontal group that you attached the label. If you want some specific advice from the horizontal group, describe that request in the issue thread. -Horizontal review groups may apply the \*-needs-resolution label to issues they expect to be resolved before the specification moves to a new maturity level. Working Groups must not remove or add this label (not even when you close your issue). +Horizontal review groups may apply the \*-needs-resolution label to issues they expect to be resolved before the specification moves to a new maturity level. Working Groups must not remove or add this label (not even when you close your issue). If the [horizontal group](/Guide/process/horizontal-groups.html) believes that an issue with a \*-tracker label needs to be resolved before a transition, they may apply a \*-needs-resolution label to the issue. Automatic tooling will later remove the \*-tracker label. -If you close an issue with a \*-tracker or \*-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.) +If you close an issue with a \*-tracker or \*-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.) -At the end of a review, and before attempting to transition the spec, you should clarify that a resolution is described for all of the issues with a \*-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the \*-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.) +At the end of a review, and before attempting to transition the spec, you should clarify that a resolution is described for all of the issues with a \*-needs-resolution label, and check that the horizontal group is aware of those resolutions. You don't have to do this for issues with the \*-tracker label. (The horizontal group was only tracking those issues, not expecting a particular resolution.) Note that the label may be applied by setting it directly on the issue if you have proper rights, or by appending it preceded with a PLUS sign (`+`) in the issue description, `+*-tracker` or `+*-needs-resolution`. @@ -240,7 +233,7 @@ Is it possible to make too many requests for review? Let them make the decision that something is irrelevant to their field of expertise instead. You're welcome to time out if you don't hear back, and request to move forward anyway. 1. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews. It's better for a Group to miss the fact that you fixed an issue in your editor's draft than the Team missing the fact you made an unreviewed substantive change in your editor's draft. -1. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you *can* close the issue though, if it is resolved). +1. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you *can* close the issue though, if it is resolved). Those are intended solely to be used by [horizontal groups](/Guide/process/horizontal-groups.html) to [bring special attention](https://www.w3.org/Guide/documentreview/#What_happens_to_unresolved_issues_marked_needs-resolution). 1. Don't assume that the horizontal group will be able to schedule and complete a review within 2 weeks so that you can proceed to CR. From c62d0a6e1c3906a30723248833202f5e5c74d1f0 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 19:00:27 +0100 Subject: [PATCH 046/225] More Markdown usage and fixes --- documentreview/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index a40d339f1..07df60c26 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -65,7 +65,7 @@ dependencies.

    -

    Note: You will be able to edit the issue's title and body before it gets created.

    +

    Note: You will be able to edit the issue's title and body before it gets created.

    The reviews provided by the [horizontal groups](/Guide/process/horizontal-groups.html), a subset of a full wide review, do receive special attention and much of the rest of this document focuses on how and when to conduct horizontal reviews. @@ -250,7 +250,7 @@ pre-CR requesting group : a group that is requesting a review -Abbreviations: +**Abbreviations:** * BP = Best Practices * CR = Candidate Recommendation * RfC = Request for Comments (aka Review Request) From 9e401f6429552d29d9df1c05d41bf82d3ed46a60 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 19:01:58 +0100 Subject: [PATCH 047/225] Move style block at the end of the document so that it does not mess up with margins between the TOC and the start of the content --- documentreview/index.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 07df60c26..8e5c40343 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -2,17 +2,6 @@ title: Document Review toc: true --- - - - ## How to do Wide Review Getting *early* and *wide* review of a document is very important, yet in practice it can be challenging. This document provides some best practices for getting document review; it does not define explicit mandatory steps. @@ -261,4 +250,13 @@ requesting group See the [Document Review Dashboard](https://www.w3.org/wiki/Dashboard#Document_Review_Dashboard) document for information about creating a dashboard type service to facilitate document reviews. + From dd37b7d36f24e22aa1234b0da3bac25b757f7c99 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 19:13:29 +0100 Subject: [PATCH 048/225] Use form markup from the W3C Design System --- documentreview/index.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 8e5c40343..2e6a3bfa4 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -49,8 +49,13 @@ dependencies.

    You may find it useful to create an issue in the GitHub repository of your spec to track your progress. Add the name of your GitHub repository to the field below and hit the "Create GitHub issue" button. This opens the "new issue" form in your repository, and pre-fills the body with review steps as a list of checkboxes.

    - -
    +
    + +
    Repository name format: owner/repo e.g. w3c/foobar
    + +

    From 2ce62b1a0a36e70bc835c9902236b6614819d1dd Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 10 Dec 2024 19:17:35 +0100 Subject: [PATCH 049/225] Fix anchor --- documentreview/create-github-issue.js | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/documentreview/create-github-issue.js b/documentreview/create-github-issue.js index 341509dc4..d5684cf7f 100644 --- a/documentreview/create-github-issue.js +++ b/documentreview/create-github-issue.js @@ -14,7 +14,7 @@ function createGitHubIssue(event) { const repo = match ? match[1] : value; if (!repo.match(/^[^\s\/]+\/[^\s\/]+$/)) { console.warn('Invalid repository name entered', value); - window.alert(`Invalid repository name: "${value}".\nExpected format: "owner/repo", e.g. "w3c/documentreview".`); + window.alert(`Invalid repository name: "${value}".\nExpected format: "owner/repo", e.g. "w3c/foobar".`); return; } @@ -43,7 +43,7 @@ function generateGitHubIssueBody() { }); return `This is a meta issue to track wide review steps for the specification. -See [How to do wide review](https://www.w3.org/Guide/documentreview/#who_to_ask_for_review) for details. +See [How to do wide review](https://www.w3.org/Guide/documentreview/#who-to-ask-for-wide-review) for details. - [ ] the groups listed in the WG's charter, especially those who manage dependencies - [ ] the groups jointly responsible for a particular document (if any). From 7a9f215e27fc7dcef0b59be8bcc96aae6f0b841a Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 14:18:45 +0100 Subject: [PATCH 050/225] Rename from .html to .md --- meetings/{organize.html => organize.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{organize.html => organize.md} (100%) diff --git a/meetings/organize.html b/meetings/organize.md similarity index 100% rename from meetings/organize.html rename to meetings/organize.md From 7605df06185a4eb131a8a88c800c0f13c3216abc Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 14:32:59 +0100 Subject: [PATCH 051/225] Convert to markdown --- meetings/organize.md | 221 ++++++++++++------------------------------- 1 file changed, 60 insertions(+), 161 deletions(-) diff --git a/meetings/organize.md b/meetings/organize.md index b78166f52..ff6d07673 100644 --- a/meetings/organize.md +++ b/meetings/organize.md @@ -1,161 +1,60 @@ - - - - - - Organizing a distributed meeting - - - - - - - - -
    -

    On This Page → 

    - -
    - -

    - W3C benefits from diverse, inclusive, and worldwide participation. This document provides guidance - to those organizing distributed meetings. -

    - -

    Dealing with timezones

    - -
    -

    A distributed meeting is one where most of the attendees are expected to participate from remote locations - (e.g., by telephone, video conferencing, or IRC).

    -

    W3C Process Document

    -
    -

    A Chair should build consensus about the time slots for distributed meetings and should - reevaluate that consensus on a regular basis. A good practice is to re-evaluate at the semi-annual spring and fall shifts in daylight saving time, and upon significant changes in membership or participation. -

    - -

    When scheduling regularly occurring distributed meetings, the Chair should consider rotating meeting times - if that helps a broader group of members to participate.

    - -

    W3C being an international organization, its meetings are impacted by holidays in various countries and cultures. You - can find a list of holidays to take into consideration. -

    - -

    A Chair might use the following steps for proposing time slots: -

      -
    • Collect participants' time zones
    • -
    • Propose candidate time slots, at least some of which start beween 06:00 and 00:00 in each participant's timezone - (see the World Clock Meeting Planner) -
    • -
    • If using a tool such as doodle.com to collect feedback, provide alternative mechanisms to participants who - have trouble accessing the tool
    • -
    -

    A Chair should consider the following when judging the group's consensus:

    -
      -
    • Prioritize preferences of core participants based on the meeting agenda
    • -
    • Give consideration to all preferences, including those in the minority, taking care - to not systematically disenfranchise any participants.
    • -
    • If the group can not reach a consensus, the Chair has the discretion to make - a decision.
    • -
    - -

    The W3C Process - provides rules about the timing of meeting announcements and agenda publication. -

    - - - -

    Group calendars

    - -

    Group calendars are available from lists of Groups. For each Group, there - is a 'Calendar' tab.

    - -
      -
    • Group and Task Force Chairs and Team contacts can schedule meetings, recurring or not.
    • -
    • Events and calendars can be exported as iCal files and subscribed to from third-party calendaring clients.
    • -
    • Group participants and other invited people are notified by email of new meetings and scheduling changes. This can be opted out from your profile.
    • -
    • All users have a personal calendar listing all meetings they are invited to.
    • -
    - -

    Creating an event

    - -

    - Things to keep in mind: -

    -
      -
    1. Create the event as 'Draft' and keep it as such until you're ready to get your event listed - on the Group calendar. -

      Draft events are found through your personal - calendar 'My Drafts', so only 'Tentative' and 'Confirmed' events will appear on the Group - calendar page.

      -
    2. -
    3. Assume a newcomer will look at your event, so use standalone information as much as possible and use - links in the event description, agenda, and joining instructions fields, so a new participant can - follow links and find out the additional information. -
    4. -
    5. Joining link and instructions are restricted. The information will NOT be part - of public email ntofications and can only be seen by W3C members, participants in the invited groups - and additional invitees, so it's safe to put passcodes in the joining instructions.
    6. -
    7. Avoid sending multiple email notifications: -
        -
      1. When updating, select "Update but don't send notifications"
      2. -
      3. Check your information on the resulted event page
      4. -
      5. If satisfied, go back into "Edit" mode and use "Update" to send the notifications out.
      6. -
      -
    8. -
    - -

    - A suggested workflow for recurring events is to create the event with the recurrence rule, keeping the - status as 'Tentative'. This will create the multiple occurences of your recurring meeting (up to one year ahead) - and notify participants (unless they opted out) of the tentative meetings. - Once you're ready to confirm the meeting and include the agenda, update the single occurence - and change the meeting status to 'Confirmed'. This will notify participants and the Group mailing list of - the updated event. - Once the minutes of the meeting are available, update again the single occurence to point - to the minutes so that it's easy to find them later in the 'Past Events' tab of your Group calendar. -

    - - -

    The W3C Calendar system does support timezones but - does not provide facilitation for finding suitable times within a set of timezones. We recommend using - online resources, such as the World Clock Meeting Planner - and doodle. -

    - -

    Report issues on GitHub if you find any.

    - -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - - +--- +title: Organizing a distributed meeting +toc: true +--- + +W3C benefits from diverse, inclusive, and worldwide participation. This document provides guidance to those organizing distributed meetings. + +## Dealing with timezones + +{% include quote.html content="A distributed meeting is one where most +of the attendees are expected to participate from remote locations +(e.g., by telephone, video conferencing, or IRC)." footer="[W3C Process Document](/policies/process/#distributed-meeting)" %} + +A Chair should build consensus about the time slots for distributed meetings and should reevaluate that consensus on a regular basis. A good practice is to re-evaluate at the semi-annual spring and fall shifts in daylight saving time, and upon significant changes in membership or participation. + +When scheduling regularly occurring distributed meetings, the Chair should consider rotating meeting times if that helps a broader group of members to participate. + +W3C being an international organization, its meetings are impacted by holidays in various countries and cultures. You can find a [list of holidays](https://www.w3.org/wiki/Holidays) to take into consideration. + +A Chair might use the following steps for proposing time slots: + +- Collect participants' time zones +- Propose candidate time slots, at least some of which start beween 06:00 and 00:00 in each participant's timezone (see [the World Clock Meeting Planner](https://www.timeanddate.com/worldclock/meetingtime.html?iso=20210127&p1=240&p2=248&p3=33&p4=195&p5=136&p6=43&p7=64&p8=224)) +- If using a tool such as doodle.com to collect feedback, provide alternative mechanisms to participants who have trouble accessing the tool + +A Chair should consider the following when judging the group's consensus: + +- Prioritize preferences of core participants based on the meeting agenda +- Give consideration to all preferences, including those in the minority, taking care to not systematically disenfranchise any participants. +- If the group can not reach a consensus, the Chair has the discretion to make a decision. + +The [W3C Process](/policies/process/#GeneralMeetings) provides rules about the timing of meeting announcements and agenda publication. + +## Group calendars + +Group calendars are available from [lists of Groups](https://www.w3.org/groups/). For each Group, there is a '*Calendar*' tab. + +- Group and Task Force Chairs and Team contacts can schedule meetings, recurring or not. +- Events and calendars can be exported as iCal files and subscribed to from third-party calendaring clients. +- Group participants and other invited people are notified by email of new meetings and scheduling changes. This can be opted out from your [profile](https://www.w3.org/users/myprofile/edit). +- All users have a [personal calendar](https://www.w3.org/users/myprofile/calendar) listing all meetings they are invited to. + +### Creating an event + +Things to keep in mind: + +1. Create the event as '*Draft*' and keep it as such until you're ready to get your event listed on the Group calendar. + + Draft events are found through your [personal calendar](https://www.w3.org/users/myprofile/calendar) 'My Drafts', so only 'Tentative' and 'Confirmed' events will appear on the Group calendar page. +2. Assume a newcomer will look at your event, so use standalone information as much as possible and use links in the event description, agenda, and joining instructions fields, so a new participant can follow links and find out the additional information. +3. Joining link and instructions are **restricted**. The information will NOT be part of public email ntofications and can only be seen by W3C members, participants in the invited groups and additional invitees, so it's safe to put passcodes in the joining instructions. +4. Avoid sending multiple email notifications: + + 1. When updating, select "*Update but don't send notifications*" + 2. Check your information on the resulted event page + 3. If satisfied, go back into "*Edit*" mode and use "*Update*" to send the notifications out. + +A suggested workflow for recurring events is to create the event with the recurrence rule, keeping the status as 'Tentative'. This will create the multiple occurences of your recurring meeting (up to one year ahead) and notify participants (unless they opted out) of the tentative meetings. Once you're ready to confirm the meeting and include the agenda, update the *single* occurence and change the meeting status to 'Confirmed'. This will notify participants and the Group mailing list of the updated event. Once the minutes of the meeting are available, update again the single occurence to point to the minutes so that it's easy to find them later in the 'Past Events' tab of your Group calendar. + +The W3C Calendar system does support timezones but does not provide facilitation for finding suitable times within a set of timezones. We recommend using online resources, such as [the World Clock Meeting Planner](https://www.timeanddate.com/worldclock/meetingtime.html?p1=43&p2=195&p3=224&p4=33&p5=248&p6=136&p7=64&p8=216&p9=152) and [doodle](https://doodle.com/). From e89971653793708556c0ff888a67911d0bcefaf3 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 14:34:25 +0100 Subject: [PATCH 052/225] Rename from .html to .md --- meetings/{tpac.html => tpac.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{tpac.html => tpac.md} (100%) diff --git a/meetings/tpac.html b/meetings/tpac.md similarity index 100% rename from meetings/tpac.html rename to meetings/tpac.md From 3128e5d84b00c3f903d36f49ae1ce741432b7e9b Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 14:43:57 +0100 Subject: [PATCH 053/225] Convert to markdown --- meetings/tpac.md | 218 +++++++++++++++-------------------------------- 1 file changed, 67 insertions(+), 151 deletions(-) diff --git a/meetings/tpac.md b/meetings/tpac.md index 4a51745ff..db842fe03 100644 --- a/meetings/tpac.md +++ b/meetings/tpac.md @@ -1,151 +1,67 @@ - - - - - - On TPAC Group and Joint-Group Meetings - - - - - - - - -
    -

    On This Page → 

    - -
    - -

    - The goal of Group meetings during a W3C TPAC is to gather the community together, to - create momentum and collective brainstorming around challenges faced by the Web. The - technical plenary is a set of collaborative meetings, bringing together W3C technical - groups, the Advisory Board, the TAG and the Advisory Committee for exciting, coordinated - work. The benefit of assembling the community for thought-provoking discussions is invaluable. -

    -

    - While W3C Groups meet throughout the year in a variety of ways (teleconference, Zoom, F2F), the annual TPAC plays a unique and special role in the annual - calendar of a Group. What sets these meetings apart is that by having the Group together - for 2 days (and also adjacent to many other groups), the Group can get done that which it - cannot normally do - specifically (see below). -

    - -

    TPAC 2021

    - -

    - With the pandemic, many Groups did not meet for TPAC 2020, and other groups met briefly - and did not fully achieve the full goals of a TPAC meeting. That has caused a deficit - in meeting the special objectives that we previously have only been able to achieve through - TPAC Group meetings. -

    -

    - In TPAC 2021, since we are still virtual, it will still be challenging to achieve all of - the benefits of a physical meeting. But two years into virtual meetings, it is recommended - that Groups try to get together to achieve some of these benefits. At a minimum they - should consider doing an overview of the state of the Working Group and its deliverables, - looking at big challenges ahead, where the priorities should be, and use a different agenda - from your regular recurring meetings. -

    -

    Since we'll be virtual, a few reminders:

    -
      -
    1. Make sure it's easy for outsiders to discover your meeting. Add your meeting to: -
        -
      1. the TPAC 2021 page.
      2. -
      3. the W3C Calendar of the Group.
      4. -
      -
    2. -
    3. A distributed meeting is one where most of the attendees are expected to participate from remote locations (see dealing with timezones).
    4. -
    5. See our considerations regarding zoom, including recordings and automated meeting transcripts.
    6. -
    7. If you plan to make a presentation, we recommend you to record them in advance. - Ask the events team for assistance if needed but they require 2 weeks lead time (deadline is October 11). See also - our recording tips.
    8. -
    9. Consider if a breakout session might be useful.
    10. -
    - -

    TPAC Group meeting

    - -

    TPAC meeting is an opportunity for a Working or Interest Group :

    -
      -
    1. look on the progress and goals of the Group as well as the deliverables;
    2. -
    3. look at related work (e.g in Community Groups) and what's new out there within the scope or related to the Group's mission;
    4. -
    5. welcome new participants, understand their interests, get their questions/feedback on the Group, and potentially mentor them on how to contribute;
    6. -
    7. welcome observers, understand their interests in the Group, and get them interested in joining the Group and helping;
    8. -
    - -

    On the deliverables:

    - -
      -
    • State of the Working Group and its deliverables (past, present and future) -
        -
      • high level view of the Working Group (success/challenges, goals, how close is the group to meet - its charter goals?, etc.) -
      • Reports on deliverables. Make sure to go through each, even if nothing changed and it gets brief, since some might - in needs in any case. -
          -
        • state of issues/pull requests -
        • state of tests -
        • state of implementation -
        • last 12 months progress -
        • expectations/hopes for next 12 months (eg important milestones coming up) -
        • what contributions would be welcome from other/new participants -
        -
    • -
    • Blocking issues that are difficult to progress in weekly calls. Some indicators of such issue: -
        -
      • Does the issue need more than 25% of the Group to be present to be moved forward? if you only need to talk to 2 or 3 individuals, take those on the side unless asked otherwise -
      • Does an issue require participants from outsiders (participants from other groups, etc.)
      • -
      • Does the issue need a whiteboard in the room to be discussed? -
      • Do you need guidance or help, such as choosing between several designs/solutions? -
      • Ask participants which issue they would like to dive in? (limit of [2? 3?] per participant?) -
      -
    -

    TPAC Joint Meetings

    -
      -
    • TPAC is an opportunity for joint meetings between Groups: -
        -
      1. issues (blocking or otherwise) that you'd be able to advance if you can schedule a joint meeting with another Group, or with representatives from that Group -
      2. horizontal issues raised during wide reviews that have been queued -
      3. requests sent to other Groups that did not progress in there -
      -
    -

    TPAC Breakouts

    - -

    - If your Group has topic(s) of general interest, consider organizing a breakout session to attract a wider audience. -

    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - - +--- +title: On TPAC Group and Joint-Group Meetings +toc: true +--- + +The goal of Group meetings during a W3C TPAC is to gather the community together, to create momentum and collective brainstorming around challenges faced by the Web. The technical plenary is a set of collaborative meetings, bringing together W3C technical groups, the Advisory Board, the TAG and the Advisory Committee for exciting, coordinated work. The benefit of assembling the community for thought-provoking discussions is invaluable. + +While W3C Groups meet throughout the year in a variety of ways (teleconference, Zoom, F2F), the annual TPAC plays a unique and special role in the annual calendar of a Group. What sets these meetings apart is that by having the Group together for 2 days (and also adjacent to many other groups), the Group can get done that which it cannot normally do - specifically (see below). + +## TPAC 2021 + +With the pandemic, many Groups did not meet for TPAC 2020, and other groups met briefly and did not fully achieve the full goals of a TPAC meeting. That has caused a deficit in meeting the special objectives that we previously have only been able to achieve through TPAC Group meetings. + +In TPAC 2021, since we are still virtual, it will still be challenging to achieve all of the benefits of a physical meeting. But two years into virtual meetings, it is recommended that Groups try to get together to achieve some of these benefits. At a minimum they should consider doing an overview of the state of the Working Group and its deliverables, looking at big challenges ahead, where the priorities should be, and use a different agenda from your regular recurring meetings. + +Since we'll be virtual, a few reminders: + +1. Make sure it's easy for outsiders to discover your meeting. Add your meeting to: + + 1. the [TPAC 2021 page](https://www.w3.org/wiki/TPAC/2021/GroupMeetings). + 2. the [W3C Calendar of the Group](https://www.w3.org/blog/2021/03/group-calendaring-service-enters-beta-test/). +2. A distributed meeting is one where most of the attendees are expected to participate from remote locations (see [dealing with timezones](organize.html)). +3. See our [considerations regarding zoom](zoom.html), including recordings and automated meeting transcripts. +4. If you plan to make a presentation, we recommend you to record them in advance. Ask the events team for assistance if needed but they require 2 weeks lead time (deadline is October 11). See also our [recording tips](https://www.w3.org/wiki/Virtual_Presentations). +5. Consider if a breakout session might be useful. + +## TPAC Group meeting + +TPAC meeting is an opportunity for a Working or Interest Group : + +1. look on the progress and goals of the Group as well as the deliverables; +2. look at related work (e.g in Community Groups) and what's new out there within the scope or related to the Group's mission; +3. welcome new participants, understand their interests, get their questions/feedback on the Group, and potentially mentor them on how to contribute; +4. welcome observers, understand their interests in the Group, and get them interested in joining the Group and helping; + +On the deliverables: + +- State of the Working Group and its deliverables (past, present and future) + + - high level view of the Working Group (success/challenges, goals, how close is the group to meet its charter goals?, etc.) + - Reports on deliverables. Make sure to go through each, even if nothing changed and it gets brief, since some might in needs in any case. + + - state of issues/pull requests + - state of tests + - state of implementation + - last 12 months progress + - expectations/hopes for next 12 months (eg important milestones coming up) + - what contributions would be welcome from other/new participants +- Blocking issues that are difficult to progress in weekly calls. Some indicators of such issue: + + - Does the issue need more than 25% of the Group to be present to be moved forward? if you only need to talk to 2 or 3 individuals, take those on the side unless asked otherwise + - Does an issue require participants from outsiders (participants from other groups, etc.) + - Does the issue need a whiteboard in the room to be discussed? + - Do you need guidance or help, such as choosing between several designs/solutions? + - Ask participants which issue they would like to dive in? (limit of \[2? 3?] per participant?) + +## TPAC Joint Meetings + +- TPAC is an opportunity for joint meetings between Groups: + + 1. issues (blocking or otherwise) that you'd be able to advance if you can schedule a joint meeting with another Group, or with representatives from that Group + 2. horizontal issues raised during wide reviews that have been queued + 3. requests sent to other Groups that did not progress in there + +## TPAC Breakouts + +If your Group has topic(s) of general interest, consider organizing a breakout session to attract a wider audience. From f69da90233a2276fbf1a9da3394d96ebe9b27a69 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 14:46:11 +0100 Subject: [PATCH 054/225] Rename from .html to .md --- meetings/{transcripts.html => transcripts.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{transcripts.html => transcripts.md} (100%) diff --git a/meetings/transcripts.html b/meetings/transcripts.md similarity index 100% rename from meetings/transcripts.html rename to meetings/transcripts.md From ef4944044f45c4d283d38b15bd4eac268138a011 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 14:50:39 +0100 Subject: [PATCH 055/225] Convert to markdown --- meetings/transcripts.md | 130 ++++++++-------------------------------- 1 file changed, 26 insertions(+), 104 deletions(-) diff --git a/meetings/transcripts.md b/meetings/transcripts.md index 312104c1c..e6ebe51e4 100644 --- a/meetings/transcripts.md +++ b/meetings/transcripts.md @@ -1,105 +1,27 @@ - - - - - Automated Meeting Transcripts - - - - - - - -
    -

    On This Page → 

    - -
    -
    -
    -

    On Saving Automated Meeting Transcripts

    -

    Many teleconferencing systems are offering automated speech-to-text - facilities to provide captioning and transcription of meetings. W3C has - some Zoom licenses to offer this feature by default.

    -

    W3C fosters a community where conversations among those present in a - meeting may be conducted freely and openly. It has proven advantageous - for meeting participants to be able to ask permission to “go off the - record” to explain some background for a position or to provide some - other detail that may be misunderstood if quoted out of context. - Moreover, some participants have expressed concerns of personal - harassment that could be exacerbated by a recorded transcript of their - comments.

    -

    Captioning and transcription can be helpful to meeting participants, - including those who have difficulty hearing, or for whom spoken - English is more difficult to understand. With regard to minuting - practices, automated speech-to-text technology is improving but is not - yet sufficiently accurate to be relied upon as the sole record of the - meeting, and its use for minutes is therefore discouraged.

    -

    In consideration of the real-time value to meeting participants of - automated captions and transcription while respecting the utility of - allowing not-for-the-record remarks, W3C’s policy is that automated - transcriptions of W3C meetings are solely for the use of those present - in the meeting and must not be saved or shared with - anyone not present in the meeting. Before enabling automatic - transcriptions, the meeting chair must ask those - present for consent to enabling transcription and must not - permit the meeting host to enable transcription if any participant - withholds consent. The chair’s announcement must cover who will have - access to the transcript, the purpose/use of it, and for how long it - will be retained.

    -
    -
    -

    Zoom-specific instructions

    -

    In the Host’s account, the ‘Save Captions’ setting must be turned - off. This setting is in the “In Meeting (Advanced)” section of the - Settings > Meeting tab. See the Zoom - Help Center article.

    -
    -
    -

    Webex-specific instructions

    -

    The Webex Host should make sure Webex Assistant is turned - off at the start of a meeting. See - Webex Assistant for Meetings Considerations.

    -
    -
    -

    Changelog

    - -
    -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +## On Saving Automated Meeting Transcripts + +Many teleconferencing systems are offering automated speech-to-text facilities to provide captioning and transcription of meetings. W3C has *some* Zoom licenses to offer this feature by default. + +W3C fosters a community where conversations among those present in a meeting may be conducted freely and openly. It has proven advantageous for meeting participants to be able to ask permission to “go off the record” to explain some background for a position or to provide some other detail that may be misunderstood if quoted out of context. Moreover, some participants have expressed concerns of personal harassment that could be exacerbated by a recorded transcript of their comments. + +Captioning and transcription can be helpful to meeting participants, including those who have difficulty hearing, or for whom spoken English is more difficult to understand. With regard to minuting practices, automated speech-to-text technology is improving but is not yet sufficiently accurate to be relied upon as the sole record of the meeting, and its use for minutes is therefore discouraged. + +In consideration of the real-time value to meeting participants of automated captions and transcription while respecting the utility of allowing not-for-the-record remarks, W3C’s policy is that automated transcriptions of W3C meetings are solely for the use of those present in the meeting and **must not** be saved or shared with anyone not present in the meeting. Before enabling automatic transcriptions, the meeting chair **must** ask those present for consent to enabling transcription and **must not** permit the meeting host to enable transcription if any participant withholds consent. The chair’s announcement must cover who will have access to the transcript, the purpose/use of it, and for how long it will be retained. + +## Zoom-specific instructions + +In the Host’s account, the ‘Save Captions’ setting must be turned off. This setting is in the “In Meeting (Advanced)” section of the Settings > Meeting tab. See the [Zoom Help Center article](https://support.zoom.us/hc/en-us/articles/360034675592-Changing-your-meeting-recording-and-telephone-settings). + +## Webex-specific instructions + +The Webex Host should make sure Webex Assistant is turned off at the start of a meeting. See [Webex Assistant for Meetings Considerations](https://help.webex.com/en-us/q1y8ig/Webex-Assistant-for-Meetings-Considerations). + +## Changelog + +- See [commits history](https://github.com/w3c/Guide/commits/main/meetings/transcripts.html) +- See also [w3process #334](https://github.com/w3c/process/issues/334) \ No newline at end of file From 2fa143751939de4dd890a26832869ecf34619082 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 15:20:25 +0100 Subject: [PATCH 056/225] Rename from .html to .md --- meetings/{workshops.html => workshops.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{workshops.html => workshops.md} (100%) diff --git a/meetings/workshops.html b/meetings/workshops.md similarity index 100% rename from meetings/workshops.html rename to meetings/workshops.md From 6b389ef4f1eacd7277e1fc27676e77f27eb52ef1 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 15:25:27 +0100 Subject: [PATCH 057/225] Convert to markdown --- meetings/workshops.md | 162 +++++++----------------------------------- 1 file changed, 24 insertions(+), 138 deletions(-) diff --git a/meetings/workshops.md b/meetings/workshops.md index 4e223ec9d..16b450773 100644 --- a/meetings/workshops.md +++ b/meetings/workshops.md @@ -1,144 +1,30 @@ - - +--- +title: Workshops +toc: true +--- - - - Workshops - - - - - +A W3C Workshop is a one-off event which W3C holds when a need is felt to advance some aspect of the Open Web Platform and the correct way forward is unclear or would benefit from a wide variety of informed points of view before Standards-track work commences. - - -
    -

    On This Page → 

    - -
    +The result of a W3C Workshop is a report, made publicly available, which summarizes the workshop discusions and recommends next steps which may be the establishment of a W3C Working Group, or a W3C Community Group, establishment of a liaison with some other body, or on occasion the conclusion that no Standards-track work should be done in the area. -
    -
    -

    Purpose

    -

    A W3C Workshop is a one-off event - which W3C holds - when a need is felt - to advance some aspect of the Open Web Platform - and the correct way forward is unclear - or would benefit from a wide variety of informed points of view - before Standards-track work commences. -

    -

    - The result of a W3C Workshop is a report, - made publicly available, - which summarizes the workshop discusions - and recommends next steps which may be - the establishment of a W3C Working Group, - or a W3C Community Group, - establishment of a liaison with some other body, - or on occasion the conclusion that - no Standards-track work should be done in the area. -

    -

    - To date, most W3C Workshops have been face-to-face meetings. - Going forward, more workshops are expected to be virtual. - As W3C gains experience with virtual workshops, - this Guide is likely to be updated. -

    -
    -
    -

    Proposing a Workshop

    -

    Most workshops to date - have been proposed by the W3C Technical Staff, - in particular, members of the W3C Strategy Team. - Workshops being planned are publicly visible - on the W3C Strategy Funnel. -

    -

    - In the planning phase, - each workshop is maintained - as an issue on GitHub. For example, here is the issue for - the Inclusive XR workshop.

    +To date, most W3C Workshops have been face-to-face meetings. Going forward, more workshops are expected to be virtual. As W3C gains experience with virtual workshops, this Guide is likely to be updated. -

    - Propose a W3C Workshop -

    -
    -
    -

    Planning a Workshop

    -
    -

    - Each workshop proposal is discussed, - undergoes a round of horizontal review - (checking for Accessibility, Internationalization, Privacy and such like aspects) - before it is approved by the W3C Management - and a Call for Participation is issued. - Here is an example - workshop call. - -

    -

    - W3C has a requirement that no a Call for Participation is issued - no later than eight weeks prior to the meeting's scheduled start date. - This helps ensure that speakers and authors - have adequate time to prepare position papers and talks. - Once a workshop is proposed and accepted, - a planning period of typically 12 weeks before the event - allows meeting planners time to prepare logistics - and business development time to organize any sponsorship. -

    -

    -
    -
    -

    Attendance

    -

    - In contrast to a conference workshop, - which is typically a tutorial attended by those who paye a fee, - W3C Workshop attendance is by submission of a Position Paper, - which is evaluated by a Program Committee. - Not all papers are accepted, - and not all accepted papers are presented in person, - although all accepted papers are made available - to the public after the event - and (ideally) - to participants before the event, - to encourage early discussion. -

    -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    +## Proposing a Workshop - \ No newline at end of file +Most workshops to date have been proposed by the W3C Technical Staff, in particular, members of the W3C Strategy Team. Workshops being planned are publicly visible on the [W3C Strategy Funnel](https://github.com/w3c/strategy/projects/2). + +In the planning phase, each workshop is maintained as an issue on GitHub. For example, here is the issue for the [Inclusive XR workshop](https://github.com/w3c/strategy/issues/175). + +[Propose a W3C Workshop](https://github.com/w3c/strategy/issues/new?assignees=&labels=Exploration%3A%20untriaged&template=00-Exploration.md&title=) + +## Planning a Workshop + +Each workshop proposal is discussed, undergoes a round of *horizontal review* (checking for Accessibility, Internationalization, Privacy and such like aspects) before it is approved by the W3C Management and a Call for Participation is issued. Here is an [example workshop call](https://www.w3.org/2019/08/inclusive-xr-workshop/). + +W3C has a requirement that no a Call for Participation is issued no later than eight weeks prior to the meeting's scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks. Once a workshop is proposed and accepted, a planning period of typically 12 weeks before the event allows meeting planners time to prepare logistics and business development time to organize any sponsorship. + +## Attendance + +In contrast to a conference workshop, which is typically a tutorial attended by those who paye a fee, W3C Workshop attendance is by submission of a Position Paper, which is evaluated by a Program Committee. Not all papers are accepted, and not all accepted papers are presented in person, although all accepted papers are made available to the public after the event and (ideally) to participants before the event, to encourage early discussion. \ No newline at end of file From 36891cdff2d4e97065ebcf154fa0ede7f7b2c48f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 15:26:35 +0100 Subject: [PATCH 058/225] Rename from .html to .md --- meetings/{zoom.html => zoom.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{zoom.html => zoom.md} (100%) diff --git a/meetings/zoom.html b/meetings/zoom.md similarity index 100% rename from meetings/zoom.html rename to meetings/zoom.md From 1d795334df005265efc7c481f0837268354a8fec Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 11 Dec 2024 15:38:30 +0100 Subject: [PATCH 059/225] Convert to markdown --- meetings/zoom.md | 267 +++++++++++++---------------------------------- 1 file changed, 73 insertions(+), 194 deletions(-) diff --git a/meetings/zoom.md b/meetings/zoom.md index 32377bd4a..a97d4e157 100644 --- a/meetings/zoom.md +++ b/meetings/zoom.md @@ -1,194 +1,73 @@ - - - - - - Zoom - - - - - - - - -
    -

    On This Page → 

    - -
    - -

    - W3C has a Zoom account and - W3C Groups may use those with assistance from the W3C Team (for Community Groups, see - the separate Tools and Infrastructure). - We are aware of questions about Zoom's security and privacy - practices and recommend mitigations - and usage guidelines. -

    - -

    Scheduling a Zoom Conference

    - -

    - W3C's groups typically meet weekly and therefore schedule recurring - meetings for the duration of their charters. - The Zoom scheduler limits how far into the future a recurring meeting may be scheduled. However, you can - extend the end date after some time has passed. -

    -

    - We have found that recurring meetings can be used at any time and are not limited to the scheduled period. Thus, ad-hoc sessions and regular - meetings that are scheduled for different times to use the same meeting number/URI. -

    - -

    - To avoid interference from non-invitees, meeting coordinates - should not be posted publicly. The meeting information, - including password, should be posted to a Member-only mailing - list and only the URI of the list archive message used in - public meeting agendas or other public group pages. -

    - -

    Suggested Settings

    - -

    - W3C Team account owners should set account default settings as follows: -

    - -
      -
    • Join before host [on]
    • -
    • Waiting room [off] (off is the default; if turned on for a meeting, "Join before host" is disabled for that meeting
    • -
    • Feedback to Zoom [off]
    • -
    • Display end-of-meeting experience feedback survey [off]
    • -
    • Whiteboard [on]
    • -
    • Show a "Join from your browser" link [on]
    • -
    • When attendees join meeting before host [off]
    • -
    • Save Captions [off].
    • -
    • Attention tracking [off] (Zoom says they have removed attention tracking as of 1 April 2020)
    • -
    - -

    - These settings will allow the group to meet even if the Team - Host is not present. If an actual Host is required, the Team - Host can join the call momentarily and assign co-Host privileges - to one or more of the other attendees. -

    - -

    Testing Your Connection

    - -

    - Zoom offers a test meeting service for anyone to use to test their connection. - You should use it to hear how your - own audio is working. This service may only work for Internet (not phone) connections. See also Zoom's - article on testing. -

    - -

    Recordings

    - -

    - Zoom provides the ability to make recordings. If this - feature is used, it must be with the consent of the meeting - participants. Chairs have the responsibility to ensure that - participants are aware that they are being recorded whenever - this feature is used. - Recordings are made available after the end (could take a - few hours) using an email notification to the meeting host, - and can only be shared by default to individuals with a W3C Zoom - account. We're looking into providing additional - recommendations to make those videos available through other - means. -

    -

    - Check also the special guidance on automated meeting transcripts. -

    - -

    Ending a Meeting

    - -

    - Participants sometimes wander off and forget to disconnect - at the end of a meeting. To avoid later embarrassment it - is recommended that someone with Host privileges explicitly - end each Zoom meeting once it has adjourned. -

    - - -

    Considerations

    - -

    Security and Privacy

    - -

    - The - standard precautions apply for meeting participants to mute - your audio except when you mean to talk to the meeting to - avoid interference and accidentally sharing private - communications (e.g. yelling at your pets), and also to pay - attention to what is visible in your video feed. -

    -

    - Besides the suggested settings for the W3C team accounts, we understand that - concerns have been raised regarding the security/privacy of the Zoom clients. Several of the issues reported - were based on native application hacks with computers already infected (such as modifying the installation script). - The best and most cost-effective way to prevent those issues is to use the Web application for Zoom but it is - more CPU intensive. Using an alternative device helps in isolating the native applications - or the impact on CPU usage from the Web application. It's the perfect opportunity to repurpose an old device. -

    - -

    Zoom documentation

    - -

    This section provides links to the Zoom documentation.

    -
      -
    • ability for a participant to turn off incoming video (see network bandwidth)
    • -
    • accessibility (FAQ)
    • -
    • audio quality and settings
    • -
    • cost
    • -
    • dial-in capability
    • -
    • internationalization
    • -
    • interoperable browser support
    • -
    • network bandwidth
    • -
    • Native platform independence (a native app that works on Linux, Mac, Windows, …)
    • -
    • privacy
    • -
    • queue management
    • -
    • reliability
    • -
    • scalability
    • -
    • screen and application sharing (share only one app, not only entire screen)
    • -
    • security
    • -
    • video quality and settings
    • -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - - +--- +title: Zoom +toc: true +--- + +W3C has a Zoom account and W3C Groups may use those with assistance from the W3C Team (for Community Groups, see the separate [Tools and Infrastructure](https://www.w3.org/community/about/tool/)). We are aware of questions about Zoom's security and privacy practices and recommend [mitigations](#settings) and usage guidelines. + +## Scheduling a Zoom Conference + +W3C's groups typically meet weekly and therefore schedule recurring meetings for the duration of their charters. The Zoom scheduler limits how far into the future a recurring meeting may be scheduled. However, you can extend the end date after some time has passed. + +We have found that recurring meetings can be used at any time and are not limited to the scheduled period. Thus, ad-hoc sessions and regular meetings that are scheduled for different times to use the same meeting number/URI. + +To avoid interference from non-invitees, meeting coordinates should not be posted publicly. The meeting information, including password, should be posted to a Member-only mailing list and only the URI of the list archive message used in public meeting agendas or other public group pages. + +## Suggested Settings + +W3C Team account owners should set [account default settings](https://w3c.zoom.us/profile/setting) as follows: + +- Join before host \[on] +- Waiting room \[off] (off is the default; if turned on for a meeting, "Join before host" is disabled for that meeting +- Feedback to Zoom \[off] +- Display end-of-meeting experience feedback survey \[off] +- Whiteboard \[on] +- Show a "Join from your browser" link \[on] +- When attendees join meeting before host \[off] +- [Save Captions](transcipts.html) \[off]. +- Attention tracking \[off] ([Zoom says they have removed attention tracking as of 1 April 2020](https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/)) + +These settings will allow the group to meet even if the Team Host is not present. If an actual Host is required, the Team Host can join the call momentarily and assign co-Host privileges to one or more of the other attendees. + +## Testing Your Connection + +Zoom offers a [test meeting service](https://zoom.us/test) for anyone to use to test their connection. You should use it to hear how your own audio is working. This service may only work for Internet (not phone) connections. See also [Zoom's article on testing](https://support.zoom.us/hc/en-us/articles/115002262083-Joining-a-test-meeting). + +## Recordings + +Zoom provides the ability to make recordings. If this feature is used, it must be with the consent of the meeting participants. Chairs have the responsibility to ensure that participants are aware that they are being recorded whenever this feature is used. Recordings are made available after the end (could take a few hours) using an email notification to the meeting host, and can only be shared by default to individuals with a W3C Zoom account. We're looking into providing additional recommendations to make those videos available through other means. + +Check also the special guidance on [automated meeting transcripts](transcripts.html). + +## Ending a Meeting + +Participants sometimes wander off and forget to disconnect at the end of a meeting. To avoid later embarrassment it is recommended that someone with Host privileges explicitly end each Zoom meeting once it has adjourned. + +## Considerations + +### Security and Privacy + +The standard precautions apply for meeting participants to mute your audio except when you mean to talk to the meeting to avoid interference and accidentally sharing private communications (e.g. yelling at your pets), and also to pay attention to what is visible in your video feed. + +Besides the [suggested settings for the W3C team accounts](#suggested-settings), we understand that concerns have been raised regarding the security/privacy of the Zoom clients. Several of the issues reported were based on native application hacks with computers already infected (such as modifying the installation script). The best and most cost-effective way to prevent those issues is to use the Web application for Zoom but it is more CPU intensive. Using an alternative device helps in isolating the native applications or the impact on CPU usage from the Web application. It's the perfect opportunity to repurpose an old device. + +### Zoom documentation + +This section provides links to the Zoom documentation. + +- ability for a participant to turn off incoming video (see network bandwidth) +- [accessibility](https://zoom.us/accessibility) ([FAQ](https://zoom.us/accessibility/faq)) +- audio quality and settings +- cost +- [dial-in capability](https://zoom.us/zoomconference) +- internationalization +- interoperable browser support +- network bandwidth +- Native platform independence (a native app that works on Linux, Mac, Windows, …) +- [privacy](https://zoom.us/privacy?zcid=1231&_ga=2.98581528.769047269.1585831637-830468457.1584135532) +- queue management +- reliability +- scalability +- [screen and application sharing](https://support.zoom.us/hc/en-us/categories/201137166) (share only one app, not only entire screen) +- [security](https://zoom.us/security) +- video quality and settings \ No newline at end of file From 8ed56e5b4963de93d83378eec09cec25f76ff6ee Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 13:42:00 +0100 Subject: [PATCH 060/225] Rename from .html to .md --- meetings/{hosting.html => hosting.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{hosting.html => hosting.md} (100%) diff --git a/meetings/hosting.html b/meetings/hosting.md similarity index 100% rename from meetings/hosting.html rename to meetings/hosting.md From f3012a1248917fb57a5419e8ba24b76a338e1f5f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 14:07:00 +0100 Subject: [PATCH 061/225] Convert to markdown --- meetings/hosting.md | 352 ++++++++++++++------------------------------ 1 file changed, 114 insertions(+), 238 deletions(-) diff --git a/meetings/hosting.md b/meetings/hosting.md index d4a6cb181..d95a24041 100644 --- a/meetings/hosting.md +++ b/meetings/hosting.md @@ -1,290 +1,166 @@ - - - - - Host Guidelines for W3C face to face - - - +--- +title: Host Guidelines for W3C face to face +toc: true +--- - - - +This page is targeted for W3C Working/Interest Group face to face meetings, Workshops, and Symposiums. Sped -
    -

    Also On This Page → 

    - -
    +## General Considerations {#general} +This document has been written to help when communicating with a potential W3C face to face host, to *explain what is expected* from them. - -

    This page is targeted for W3C Working/Interest Group face to face meetings, Workshops, and Symposiums. Sped

    +These guidelines can be used for **all sort of meetings**: Working Group face to face, Workshops, Symposiums, etc. Workshops and Symposiums should be considered more formal and generally take longer to arrange because they tend to be larger meetings between 50-100 people. Arranging for wireless internet for a larger group for example may take a host longer to coordinate especially if their facility is not equipped for this type of meeting. -

    General Considerations

    +## Communicating with potential hosts {#potential} -

    This document has been written to help when communicating with a potential W3C face to face host, to explain what is expected from them.

    +Hosts should fully understand W3C's meeting requirements along with the resources and costs associated with hosting a Workshop or WG f2f meeting before confirming that their organization is able to host a W3C meeting. This may take a couple of weeks for hosts to determine. -

    These guidelines can be used for all sort of meetings: Working Group face to face, Workshops, Symposiums, etc. Workshops and Symposiums should be considered more formal and generally take longer to arrange because they tend to be larger meetings between 50-100 people. Arranging for wireless internet for a larger group for example may take a host longer to coordinate especially if their facility is not equipped for this type of meeting.

    +It is the responsibility of the meeting Chair to communicate W3C's specific meeting requirements and ensure that potential hosts have the appropriate resources and budget to successfully organize a W3C meeting. Potential hosts will most likely need a couple of weeks (if not longer) to investigate their organization's meeting facilities, wireless internet capabilities, etc. +Note from Susan: Communicating w/ potential hosts may need to be a separate Team or Chair only page. This space would be a place for Team to make comments as well as record notes about experiences w/ negotiating, whether the meeting worked well, if the host dropped the ball in any way, things to do better next time, things to avoid, etc. I personally think this would be a very useful page. -

    Communicating with potential hosts

    +## Meeting Requirements {#requirements} -

    Hosts should fully understand W3C's meeting requirements along with the resources and costs associated with hosting a Workshop or WG f2f meeting before confirming that their organization is able to host a W3C meeting. This may take a couple of weeks for hosts to determine.

    +### Network requirements -

    It is the responsibility of the meeting Chair to communicate W3C's specific meeting requirements and ensure that potential hosts have the appropriate resources and budget to successfully organize a W3C meeting. Potential hosts will most likely need a couple of weeks (if not longer) to investigate their organization's meeting facilities, wireless internet capabilities, etc.

    +Please consult the link, for further guidance. -

    Note from Susan: Communicating w/ potential hosts may need to be a separate Team or Chair only page. This space would be a place for Team to make comments as well as record notes about experiences w/ negotiating, whether the meeting worked well, if the host dropped the ball in any way, things to do better next time, things to avoid, etc. I personally think this would be a very useful page.

    +Hi-speed Wireless Internet for 100% of estimated meeting attendance. Consult the [Meeting Network Requirements](/2006/03/hostnetworkrequirements.html) document for further guidance. +#### AC/TP Meetings -

    Meeting Requirements

    +For all large (AC, TP) meetings, the global Systems Team will take responsibility for the details of the Internet service provision at the meeting. -

    Network requirements

    +In order to accomplish that goal: -

    Please consult the link, for further guidance.

    +1. The Meeting Planner in charge of selecting the venue shall request systems support from the Systeam leader PRIOR to the selection of the venue. +2. The Systeam leader will assign a Project Leader based on locality and qualifications +3. The Project Leader and Meeting Planner will prepare a requirements statement, and include the then-current version of the standard [Meeting Network Requirements](/2006/03/hostnetworkrequirements.html) document and present same to the venue's service provider (whether internal or external). +4. The Project Leader and Meeting Planner **SHOULD** meet with the network provider in order to evaluate the vendor's capability to meet the requirements. +5. The Project Leader will work with the Meeting Planner to select a vendor that can most successfully meet the requirements. Should a technically unacceptable vendor be chosen nonetheless, the Systems Team cannot be expected to compensate or be held accountable for the result. +6. Assuming an acceptable vendor is chosen, the Meeting Planner will facilitate technical contact between the Project Leader and network vendor, applying pressure on the venue as needed to ensure adequate continuing communication. +7. The Project Leader will be the "point person" for the System Team at the scheduled event, and will work directly with the vendor's on-site support person to resolve problems. -

    Hi-speed Wireless Internet for 100% of estimated meeting attendance. Consult the Meeting Network Requirements document for further guidance.

    +#### Workshops -

    AC/TP Meetings

    +Not yet formalized in public space; contact W3C staff. -

    For all large (AC, TP) meetings, the global Systems Team will take responsibility for the details of the Internet service provision at the meeting.

    +#### WG/IG Meetings -

    In order to accomplish that goal:

    +Not yet formalized in public space; contact W3C staff. -
      -
    1. The Meeting Planner in charge of selecting the venue shall request systems support from the Systeam leader PRIOR to the selection of the venue.
    2. +### Wheelchair Accessibility -
    3. The Systeam leader will assign a Project Leader based on locality and qualifications
    4. +Not yet formalized in public space; contact W3C staff. -
    5. The Project Leader and Meeting Planner will prepare a requirements statement, and include the then-current version of the standard Meeting Network Requirements document and present same to the venue's service provider (whether internal or external).
    6. +### Seating Arrangement -
    7. The Project Leader and Meeting Planner SHOULD meet with the network provider in order to evaluate the vendor's capability to meet the requirements.
    8. +- Meeting Room: Appropriate sized room to accommodate estimated attendance w/ tables in one of the following seating arrangements below. Meeting Chair to provide estimated attendance. + + - U-shape -- chairs and tables arranged in a U-shape. This arrangement works best for groups 35 and under. + - Schoolroom -- rows of chairs w/ tables in front. This arrangement works best for Workshops and Symposiums as these meetings have formal talks. + - Conference -- chairs around a boardroom table. This arrangement also works for working group meetings. + - Other: Chair or group preference -- Meeting Chair to communicate seating preference if different from above options -
    9. The Project Leader will work with the Meeting Planner to select a vendor that can most successfully meet the requirements. Should a technically unacceptable vendor be chosen nonetheless, the Systems Team cannot be expected to compensate or be held accountable for the result.
    10. +Absolute requirements for site up front. Yes, that's my plan. -
    11. Assuming an acceptable vendor is chosen, the Meeting Planner will facilitate technical contact between the Project Leader and network vendor, applying pressure on the venue as needed to ensure adequate continuing communication.
    12. +- - A meeting room (sized for the meeting, of course, with chairs, etc, and accessible if required by some participants) and its address. +- most hosts usually do (P2): + + - presentation hardware (LCD projector, slide projector, electrical cords) + - meals and refreshments during the day (taking into consideration people's specific diet: vegan, kosher, etc) + - badges + - information about local transportation and hotels (to be added to the meeting page ahead of time) + - arrange a block of rooms in local hotels (at special rate if possible) + - IP access (e.g. an ethernet router with DHCP in the room, or some hands-on terminals in an adjacent room) + - A contact person on location the day(s) of the meeting for helping if needed +- good to have (P3): + + - a local sponsored dinner + - shuttle transportation from and to hotels each day + - availibity of a telecon phone in the room + - on site printing support + - support for brailling, sign language (if required) -
    13. The Project Leader will be the "point person" for the System Team at the scheduled event, and will work directly with the vendor's on-site support person to resolve problems.
    14. -
    +I also think a valuable addition to this page would be a short business case on the value of hosting W3C f2f for members: more visibility, easier participation from locals, etc. -

    Workshops

    +## Organizer Checklist {#organizerChecklist} -

    Not yet formalized in public space; contact W3C staff.

    +Please add to this list if you notice omissions. -

    WG/IG Meetings

    +### Hotel -

    Not yet formalized in public space; contact W3C staff.

    -

    Wheelchair Accessibility

    -

    Not yet formalized in public space; contact W3C staff.

    +(Select one "recommended" hotel and also list alternates) -

    Seating Arrangement

    +- High-speed network connections in the rooms +- Group rate? -
      -
    • Meeting Room: Appropriate sized room to accommodate estimated attendance w/ tables in one of the following seating arrangements below. Meeting Chair to provide estimated attendance. +### Meetings -
        -
      • U-shape -- chairs and tables arranged in a U-shape. This arrangement works best for groups 35 and under.
      • +- Provide phone bridge? (check with Chair). -
      • Schoolroom -- rows of chairs w/ tables in front. This arrangement works best for Workshops and Symposiums as these meetings have formal talks.
      • +{% include quote.html content="**Note:** If the meeting is in a hotel, and the group plans to dial out to a telcon bridge for most of the day, the telephone charges can be astronomical. **Meeting organizers** may try to arrange a special phone rate with the hotel, or arrange to have the call put onto a calling card. **Chairs and staff contacts** should make sure that you don't inadvertently run up a huge bill for the host by dialing out using the hotel's default long-distance service."%} -
      • Conference -- chairs around a boardroom table. This arrangement also works for working group meetings.
      • +- Provide network connection during meetings? (check with Chair) +- U-shaped arrangement of tables +- Data projector & screen +- Long projector cable (to reach all participants) +- White board or flip chart +- Amenities during meetings and breaks: water, beverages, snacks -
      • Other: Chair or group preference -- Meeting Chair to communicate seating preference if different from above options
      • -
      -
    • -
    +### Other -

    Absolute requirements for site up front. Yes, that's my plan.

    +- Lunch arrangements (most hosts pay for lunch; if that won't be the case, let the group know in advance to minimize confusion) +- Dietary restrictions (e.g., vegetarian, etc.) +- Non-smoking, if possible +- Reservation for group dinner (Host pay? Or self pay?) +- Dietary restrictions (e.g., vegetarian, etc.) +- Non-smoking, if possible +- Transportation to dinner (Share taxis? Shared rental cars?) -
      -
    • -
        -
      • A meeting room (sized for the meeting, of course, with chairs, etc, and accessible if required by some participants) and its address.
      • -
      -
    • +## Information for Attendees (Template) {#attendeeInfo} -
    • most hosts usually do (P2): +(Fill in and distribute this to attendees. Please add to this list if you notice omissions.) -
        -
      • presentation hardware (LCD projector, slide projector, electrical cords)
      • +### Meeting {#template} -
      • meals and refreshments during the day (taking into consideration people's specific diet: vegan, kosher, etc)
      • +- Meeting name: +- Meeting dates and times: +- Meeting location: +- Address: +- Phone: +- Local contact name: +- Local contact phone: +- Map of the area (or URL): -
      • badges
      • +### Air Travel -
      • information about local transportation and hotels (to be added to the meeting page ahead of time)
      • +- Nearest airport: +- Relevant tips: -
      • arrange a block of rooms in local hotels (at special rate if possible)
      • +### Transport from Airport to Hotel -
      • IP access (e.g. an ethernet router with DHCP in the room, or some hands-on terminals in an adjacent room)
      • +- Recommended transport from airport to hotel (rental car? taxi? bus? train?):(Include any relevant details such as schedule and cost.) +- Directions: +- Travel time to expect: -
      • A contact person on location the day(s) of the meeting for helping if needed
      • -
      -
    • +### Local Hotel Recommendations -
    • good to have (P3): +- Recommended hotel name: +- Address: +- Phone: +- Web site: +- Cost per night (indicate currency): +- Other relevant info: +- Alternate hotels: -
        -
      • a local sponsored dinner
      • +### Transport from Hotel to Meeting -
      • shuttle transportation from and to hotels each day
      • +- Recommended transport from recommended hotel to meeting (rental car? taxi? bus? train?): (Include any relevant details such as schedule and cost.) +- Directions from preferred hotel to Meeting location: +- Travel time to allow: -
      • availibity of a telecon phone in the room
      • +### Meals -
      • on site printing support
      • - -
      • support for brailling, sign language (if required)
      • -
      -
    • -
    - -

    I also think a valuable addition to this page would be a short business case on the value of hosting W3C f2f for members: more visibility, easier participation from locals, etc.

    -
    - -

    Organizer Checklist

    - -

    Please add to this list if you notice omissions. -

    -

    Hotel

    - -

    (Select one "recommended" hotel and also list alternates)

    - -
      -
    • High-speed network connections in the rooms
    • - -
    • Group rate?
    • -
    - -

    Meetings

    - -
      -
    • Provide phone bridge? (check with Chair). -

      Note: - If the meeting is in a hotel, and the group - plans to dial out to a telcon bridge for most of the day, - the telephone charges can be astronomical. Meeting - organizers may try to arrange a special phone rate - with the hotel, or arrange to have the call put onto - a calling card. Chairs and staff contacts should - make sure that you don't inadvertently run up a huge - bill for the host by dialing out using the hotel's - default long-distance service. - -

      -
    • - - -
    • Provide network connection during meetings? (check with Chair)
    • - -
    • U-shaped arrangement of tables
    • - -
    • Data projector & screen
    • - -
    • Long projector cable (to reach all participants)
    • - -
    • White board or flip chart
    • - -
    • Amenities during meetings and breaks: water, beverages, snacks
    • -
    - -

    Other

    - -
      -
    • Lunch arrangements (most hosts pay for lunch; if - that won't be the case, let the group know in advance - to minimize confusion)
    • - -
    • Dietary restrictions (e.g., vegetarian, etc.)
    • - -
    • Non-smoking, if possible
    • - -
    • Reservation for group dinner (Host pay? Or self pay?)
    • - -
    • Dietary restrictions (e.g., vegetarian, etc.)
    • - -
    • Non-smoking, if possible
    • - -
    • Transportation to dinner (Share taxis? Shared rental cars?)
    • -
    -
    - -

    Information for Attendees (Template)

    - -

    (Fill in and distribute this to attendees. Please add to this list if you notice omissions.)

    - -
    -

    Meeting

    - -
    • Meeting name:
    • -
    • Meeting dates and times:
    • -
    • Meeting location:
    • -
    • Address:
    • -
    • Phone:
    • -
    • Local contact name:
    • -
    • Local contact phone:
    • -
    • Map of the area (or URL):
    • -
    -

    Air Travel

    - -
      -
    • Nearest airport:
    • -
    • Relevant tips:
    • -
    -

    Transport from Airport to Hotel

    - -
      -
    • Recommended transport from airport to hotel (rental car? taxi? bus? train?):(Include any relevant details such as schedule and cost.)
    • -
    • Directions:
    • -
    • Travel time to expect:
    • -
    -

    Local Hotel Recommendations

    - -
      -
    • Recommended hotel name:
    • -
    • Address:
    • -
    • Phone:
    • -
    • Web site:
    • -
    • Cost per night (indicate currency):
    • -
    • Other relevant info:
    • -
    • Alternate hotels:
    • -
    -

    Transport from Hotel to Meeting

    - -
    • Recommended transport from recommended hotel to meeting (rental car? taxi? bus? train?): (Include any relevant details such as schedule and cost.)
    • -
    • Directions from preferred hotel to Meeting location:
    • -
    • Travel time to allow:
    • -
    -

    Meals

    - -
      -
    • Lunch (what should attendees expect?):
    • -
    • Group dinner (where? when? who pays?):
    • -
    -
    - -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +- Lunch (what should attendees expect?): +- Group dinner (where? when? who pays?): \ No newline at end of file From 5648f9a8ecd3163e4c0577dee38f4343bad6a73e Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 14:09:44 +0100 Subject: [PATCH 062/225] Rename from .html to .md --- meetings/{continuity.html => continuity.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{continuity.html => continuity.md} (100%) diff --git a/meetings/continuity.html b/meetings/continuity.md similarity index 100% rename from meetings/continuity.html rename to meetings/continuity.md From d645a033f523399f206023b89abf5e1576ecc53e Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 14:41:22 +0100 Subject: [PATCH 063/225] Convert to markdown preserving ids --- meetings/continuity.md | 529 +++++++++++++++-------------------------- 1 file changed, 194 insertions(+), 335 deletions(-) diff --git a/meetings/continuity.md b/meetings/continuity.md index dc9bf9fe8..dc88c0968 100644 --- a/meetings/continuity.md +++ b/meetings/continuity.md @@ -1,335 +1,194 @@ - - - - - - Continuity of Operations under Travel Restrictions - - - - - - - - -
    -

    Also on this page → 

    - -
    -

    Status

    -

    This is an evolving document, started in February 2020. Comments may be made in the GitHub repo.

    -

    Purpose

    - -

    - With travel restrictions, the world - relies even more on online communication/interaction and the World Wide Web is a crucial part of society. -

    -

    - This document outlines plans to continue W3C activities while - travel restrictions and isolation protocols limit the ability of W3C - community members to participate in-person in W3C meetings, - including - the W3C Staff. -

    - -

    Addressing the needs of your participants first

    - -

    - First and foremost, group chairs should make room for people to acknowledge new challenges. Everyone is coping with the crisis differently - and with different work, living or family conditions. It's important in those times to give individuals time and space - and to ensure that their care and safety come first. -

    - -

    The W3C Code of Conduct applies to - all W3C meetings, whether they are in-person, virtual, or hybrid.

    - -

    General policy for meetings

    - -

    - Meeting face-to-face is an important component of the work for some of our groups. Meetings enable group chairs to: -

    -
      -
    1. Set an alternative dynamic compared to interactions by email/Github or during teleconferences;
    2. -
    3. Focus synchronously on a set of issues and goals and reduce distractions;
    4. -
    5. Bring to closure hard issues in case they languish due to lack of consensus.
    6. -
    -

    - -
    -
    We recommend that all groups that consider holding physical face-to-face meetings take into account the needs of all group participants, by seeking for everyone to interact on an equal basis with other participants in remote locations. Group Chairs should not have or set the expectation that group participants will travel. This includes complementing in-person meetings with virtual - accommodations, rather than simply canceling in-person meetings, to the extent that these are respectful of the individual - needs.
    -
    - -

    Meeting purposes

    - -

    - We encounter several types of in-person meetings at W3C: -

    -
      -
    1. Group face-to-face meetings;
    2. -
    3. Workshops;
    4. -
    5. Plenary meetings;
    6. -
    7. Steering Committee meetings;
    8. -
    9. Advisory Committee meetings.
    10. -
    - -

    Virtual presence meetings can take several forms, some better suited - to the meeting purpose than others. Refer to - the section Meeting Formats - below for examples.

    - -

    Accommodationss for virtual presence

    - -

    - Hybrid meetings occur when all or some of the - participants are attending remotely; virtual meetings occur when all participatns are attending remotely. All participants should - realize that when people pivot to new environments new issues - can arise, - including accessibility and - separation from one's usual work place. Meeting chairs should - leave space for the participants to talk about this. -

    - -

    Video conferencing - Groups should plan to make extensive use of video conferencing services - for those unable to travel. In the case of travel restrictions - for some but not all participants, some participants may wish to gather - in hubs (if allowed by local authorities). When such gatherings occur, a local facilitator at each hub - should assure equitable participation by all through good communication - and participation practices; e.g., no "side conversations" even if muted. - Every effort must be made to put all the meeting participants on equal - terms whether they are at a hub or participating outside of a hub. -

    -

    Scheduling - Groups should give consideration to scheduling their meeting(s) in a - timezone that works for the majority of the attendees.  As - participants will be working in their local timezones, what is "workable" - will vary with individual circumstances, including sensitivity to - work-from-home environments and non-participant colleagues who may not be - aware that the participant is "away" even if they are physically in their - office.

    - -

    Meeting duration should be limited to 4 hours per day; consider two - 90-minute segments with an hour break between them.  That break can - be used by the participants for "hallway" conversations, arranged on - separate conference channels.

    - -

    Materials - Presenters are even more strongly encouraged to distribute - (post to the web) presentation materials in advance of the - meeting to avoid participants using extra - download bandwidth during the meeting. Presentation - materials must be available in accessible formats that - meet WCAG 2.1 AA. - If it is not possible to provide a structured document - within a videoconference presentation window, provide an - accessible source file on the web.

    -

    Video - Video cameras are strongly encouraged; this improves the sense of being - together.  Groups may prefer to use teleconferencing services that - allow each participant to choose not to receive video streams if their - network becomes saturated. - However, any discussion content that is shared via video, including - screen sharing, must be made accessible by some means to those who cannot - -- or choose not to -- use the video feed. As always, do not make video recordings or screen captures without the - explicit consent of the participants. -

    -

    Screen sharing - While screen sharing can be an effective way to work together, it also - causes accessibility problems since it prohibits the use of screen readers and translation services. - A best practice is to post accessible materials on the web and share links instead of just showing a picture of it.

    -

    Accessibility - In all cases W3C wants to make sure that people with - accessibility needs can participate. Meeting organizers - must consider how best to accomplish that with what is - currently available; e.g., is captioning or interpretation - needed? Are meeting organizers aware of any potential - interoperability issues between the videoconferencing - platform and individuals' assistive technologies? Ensure - that virtual meetings are accessible for all - participants using resources including making - audio and video media accessible - and how - to meet WCAG 2, a quick reference.

    -

    Testing - Participants should be offered testing opportunities to - assure their local equipment is operational and their - bandwidth adequate. Participants should test their - camera as well as the - quality of their audio. During testing solicit - feedback from others on the quality of each. -

    -

    See also tips and recommendations for making remote presentations for W3C meetings via teleconference.

    -

    Selecting a video conferencing service

    - -

    The considerations for a video conferencing service include:

    -
      -
    • ability for a participant to turn off incoming video (see network bandwidth)
    • -
    • accessibility
    • -
    • audio quality and settings
    • -
    • cost
    • -
    • dial-in capability
    • -
    • internationalization
    • -
    • interoperable browser support
    • -
    • network bandwidth
    • -
    • native platform independence (a native app that works on Linux, Mac, Windows, …)
    • -
    • privacy
    • -
    • queue management
    • -
    • reliability
    • -
    • scalability
    • -
    • screen and application sharing (share only one app, not only entire screen)
    • -
    • security
    • -
    • video quality and settings
    • -
    -

    - W3C uses Zoom services and groups may use those with assistance from the W3C Team. See also our zoom - page for additional information. -

    - -

    W3C Workshops

    - -

    - We continue to conduct fully distributed workshops with virtual presence sessions. - We are adapting the existing model (program committee issues call for participation - and invites presentations based on submitted position statements) and experiment with new models. - In any format, materials should be posted and archived accessibly. Participants should be notified of plans for audio/video recording and confidentiality level. -

    -

    - Workshops are often key gathering spots for consideration of new ideas, - with a mix of prepared presentation, pre-determined or self-organizing breakout sessions, - and the all-important "hallway track" opportunity for side conversations. - Organizers are encouraged to replicate this mix in virtual meetings. Some proposals include: -

      -
    • Plenary-style presentations: one or a few people present to the group and take questions. -
    • Distributed breakouts: break into parallel channels with distinct videoconference lines (or zoom's "breakout" feature) and report back. -
    • Lightning talks: invite attendees to give short (3-min) video presentations introducing themselves. These may be topical or highlight a side interest. -
    • Open mic breaks: leave the videoconference bridge open during breaks, and encourage attendees to chat and start side channels to continue discussions of shared interest. -
    • … additional suggestions welcome to the Strategy team. -
    - -

    W3C AC Meetings

    - -

    The Advisory Committee meeting has provided for remote participation for - many years.  We have announced (member link) that the April 2022 AC meeting will be fully distributed; with an administrative meeting "host" tasked to - identify all participants in both IRC and the teleconferencing service - and assure that all audio channels other than the Chair and presenter - are muted when not in active conversation. - -

    Presenters will be expected to pre-record their presentations and meeting - attendees will be expected to prepare for the meeting by viewing those - recordings. W3C staff will provide assistance in making the recordings - and will arrange to have captions added and translated to other languages.

    - -

    Each presentation will be accompanied by a WBS form for submitting - questions and comments in advance.

    - -

    As is our standard practice, the presentation slides should also be posted - in the web to allow the meeting participants to quickly cite and call up - a specific slide. These slides should be posted in the web at the same time - the recording is posted. The captioning should add "[next slide]" text - to allow use of assistive technology with the posted slides in combination - with the recorded captions.

    - -

    Given pre-recorded presentations, the bulk of the synchronous meeting time - should be devoted to Q&A. The presenter may do a brief (~3 minute) - recap of the material that was presented via recording but should present - only a single slide on which the discussion points are all summarized. - The presenter should use the WBS input to inform this recap and to address - questions and comments that were submitted in advance.

    - -

    High quality real-time captioning of the meeting should be provided - in more than one language.

    - -

    We will use IRC as the default mode of hand-raising and - discussion. If you have difficulty accessing IRC, for - instance due to network firewalls or assistive technology - reasons, please let us know the reason in advance in case we - are able to address it or otherwise provide an alternative. -

    - -

    - Special guests are still welcome in the meeting, upon approval of the Chair - of the Advisory Committee meeting. Recordings may be available for a limited time for - special guests. -

    - -

    Meeting formats

    -

    - Agenda items during virtual presence meetings could take - several of the following forms. The following sections - propose some suggested alternatives to in-person meetings. -

    -

    - For all forms of sessions the Chairs should also allow - asynchronous feedback and discussions, using GitHub issues, - emails, or other forms of input before and after a virtual - presence meeting, or between days in the case of a multi-day - meeting. -

    - -

    Primarily discussion sessions

    -

    Intended for agenda items requiring only discussions (such - as specification issues or panels). Those should be - replaced by dedicated discussion with virtual presence, - possibly clustered. -

    - -

    Presentation + discussion sessions

    - -

    Intended for agenda items requiring a presentation first, - followed by a discussion (such as technical proposals or - position papers). Those should be replaced by - pre-recording the presentation(s) with slides at least 24 - hours before the discussion (to avoid burden on - non-timezone friendly participants). Then, the - participants can have one or more dedicated discussion with - virtual presence. -

    - -

    Update sessions

    -

    Intended for agenda items to update the participants on - specific items (such as implementation reports or editor - updates). Those should be replaced by - pre-recording the presentation(s) with slides, with - possibly one teleconference to allow for - questions, clustering the updates - together. You MAY however differ those sessions - depending on the important of the topic. -

    - -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - - +--- +title: Continuity of Operations under Travel Restrictions +toc: true +--- + +## Status {#status} + +This is an evolving document, started in February 2020. Comments may be made in the [GitHub repo](https://github.com/w3c/Guide/issues). + +## Purpose {#purpose} + +With travel restrictions, the world relies even more on online communication/interaction and the World Wide Web is a crucial part of society. + +This document outlines plans to continue W3C activities while travel restrictions and isolation protocols limit the ability of W3C community members to participate in-person in W3C meetings, [including the W3C Staff](https://www.w3.org/blog/news/archives/8376). + +## Addressing the needs of your participants first {#people} + +First and foremost, group chairs should make room for people to acknowledge new challenges. Everyone is coping with the crisis differently and with different work, living or family conditions. It's important in those times to give individuals time and space and to ensure that their care and safety come first. + +The W3C [Code of Conduct](/policies/code-of-conduct/) applies to all W3C meetings, whether they are in-person, virtual, or hybrid. + +## General policy for meetings {#policy} + +Meeting face-to-face is an important component of the work for some of our groups. Meetings enable group chairs to: + +1. Set an alternative dynamic compared to interactions by email/Github or during teleconferences; +2. Focus synchronously on a set of issues and goals and reduce distractions; +3. Bring to closure hard issues in case they languish due to lack of consensus. + +We recommend that all groups that consider holding physical face-to-face meetings take into account the needs of all group participants, by seeking for **everyone to interact on an equal basis with other participants in remote locations**. Group Chairs should not have or set the expectation that group participants will travel. This includes complementing in-person meetings with virtual accommodations, rather than simply canceling in-person meetings, to the extent that these are respectful of the individual needs. + +## Meeting purposes {#types} + +We encounter several types of in-person meetings at W3C: + +1. Group face-to-face meetings; +2. Workshops; +3. Plenary meetings; +4. Steering Committee meetings; +5. Advisory Committee meetings. + +Virtual presence meetings can take several forms, some better suited to the meeting purpose than others. Refer to the section [Meeting Formats](#sessions) below for examples. + +## Accommodationss for virtual presence {#virtualPresence} + +Hybrid meetings occur when all or some of the participants are attending remotely; virtual meetings occur when all participatns are attending remotely. All participants should realize that when people pivot to new environments new issues can arise, including [accessibility](#accessibility) and separation from one's usual work place. Meeting chairs should leave space for the participants to talk about this. + +**Video conferencing** - Groups should plan to make extensive use of +video conferencing services for those unable to travel. In the case of +travel restrictions for some but not all participants, some +participants may wish to gather in hubs (if allowed by local +authorities). When such gatherings occur, a local facilitator at each +hub should assure equitable participation by all through good +communication and participation practices; e.g., no "side +conversations" even if muted. Every effort must be made to put all the +meeting participants on equal terms whether they are at a hub or +participating outside of a hub. +{:#videoconferencing} + +**Scheduling** - Groups should give consideration to scheduling their +meeting(s) in a timezone that works for the majority of the attendees. +As participants will be working in their local timezones, what is +"workable" will vary with individual circumstances, including +sensitivity to work-from-home environments and non-participant +colleagues who may not be aware that the participant is "away" even if +they are physically in their office. +{:#scheduling} + +Meeting duration should be limited to 4 hours per day; consider two 90-minute segments with an hour break between them. That break can be used by the participants for "hallway" conversations, arranged on separate conference channels. + +**Materials** - Presenters are even more strongly encouraged to +distribute (post to the web) presentation materials in advance of the +meeting to avoid participants using extra download bandwidth during +the meeting. Presentation materials must be available in accessible +formats that meet [WCAG 2.1 +AA](https://www.w3.org/WAI/WCAG21/quickref/?currentsidebar=%23col_customize&levels=aaa). If +it is not possible to provide a structured document within a +videoconference presentation window, provide an accessible source file +on the web. +{:#materials} + +**Video** - Video cameras are **strongly** encouraged; this improves +the sense of being together. Groups may prefer to use +teleconferencing services that allow each participant to choose not to +receive video streams if their network becomes saturated. However, any +discussion content that is shared via video, including screen sharing, +must be made [accessible](https://www.w3.org/WAI/WCAG21/quickref/) by +some means to those who cannot -- or choose not to -- use the video +feed. As always, do not make video recordings or screen captures +without the [explicit consent of the +participants](/policies/code-of-conduct/). +{:#video} + +**Screen sharing** - While screen sharing can be an effective way to +work together, it also causes accessibility problems since it +prohibits the use of screen readers and translation services. A best +practice is to post accessible materials on the web and share links +instead of just showing a picture of it. +{:#screen-sharing} + +**Accessibility** - In all cases W3C wants to make sure that people +with accessibility needs can participate. Meeting organizers must +consider how best to accomplish that with what is currently available; +e.g., is captioning or interpretation needed? Are meeting organizers +aware of any potential interoperability issues between the +videoconferencing platform and individuals' assistive technologies? +Ensure that virtual meetings are accessible for all participants using +resources including [making audio and video media +accessible](https://www.w3.org/WAI/media/av/) and [how to meet WCAG 2, +a quick reference](https://www.w3.org/WAI/WCAG21/quickref/). +{:#accessibility} + +**Testing** - Participants should be offered testing opportunities to +assure their local equipment is operational and their bandwidth +adequate. Participants should test their camera as well as the quality +of their audio. During testing solicit feedback from others on the +quality of each. +{:#testing} + +See also [tips and recommendations for making remote +presentations](https://www.w3.org/wiki/Virtual_Presentations) for W3C +meetings via teleconference. +{:#tips} + +### Selecting a video conferencing service {#selectingvideoconferencing} + +The considerations for a video conferencing service include: + +- ability for a participant to turn off incoming video (see network bandwidth) +- accessibility +- audio quality and settings +- cost +- dial-in capability +- internationalization +- interoperable browser support +- network bandwidth +- native platform independence (a native app that works on Linux, Mac, Windows, …) +- privacy +- queue management +- reliability +- scalability +- screen and application sharing (share only one app, not only entire screen) +- security +- video quality and settings + +W3C uses Zoom services and groups may use those with assistance from the W3C Team. See also our [zoom page](zoom.html) for additional information. + +## W3C Workshops {#workshops} + +We continue to conduct fully distributed [workshops](/policies/process/#GAEvents) with virtual presence sessions. We are adapting the existing model (program committee issues call for participation and invites presentations based on submitted position statements) and experiment with new models. In any format, materials should be posted and archived accessibly. Participants should be notified of plans for audio/video recording and confidentiality level. + +Workshops are often key gathering spots for consideration of new ideas, with a mix of prepared presentation, pre-determined or self-organizing breakout sessions, and the all-important "hallway track" opportunity for side conversations. Organizers are encouraged to replicate this mix in virtual meetings. Some proposals include: + +- Plenary-style presentations: one or a few people present to the group and take questions. +- Distributed breakouts: break into parallel channels with distinct videoconference lines (or zoom's "breakout" feature) and report back. +- Lightning talks: invite attendees to give short (3-min) video presentations introducing themselves. These may be topical or highlight a side interest. +- Open mic breaks: leave the videoconference bridge open during breaks, and encourage attendees to chat and start side channels to continue discussions of shared interest. +- … additional suggestions welcome to the Strategy team. + +## W3C AC Meetings {#ac_meeting} + +The Advisory Committee meeting has provided for remote participation for many years. We have [announced](https://lists.w3.org/Archives/Member/w3c-ac-members/2022JanMar/0039.html) (member link) that the [April 2022 AC meeting](https://www.w3.org/2022/04/AC/) will be fully distributed; with an administrative meeting "host" tasked to identify all participants in both IRC and the teleconferencing service and assure that all audio channels other than the Chair and presenter are muted when not in active conversation. + +Presenters will be expected to pre-record their presentations and meeting attendees will be expected to prepare for the meeting by viewing those recordings. W3C staff will provide assistance in making the recordings and will arrange to have captions added and translated to other languages. + +Each presentation will be accompanied by a WBS form for submitting questions and comments in advance. + +As is our standard practice, the presentation slides should also be posted in the web to allow the meeting participants to quickly cite and call up a specific slide. These slides should be posted in the web at the same time the recording is posted. The captioning should add "\[next slide]" text to allow use of assistive technology with the posted slides in combination with the recorded captions. + +Given pre-recorded presentations, the bulk of the synchronous meeting time should be devoted to Q&A. The presenter may do a brief (~3 minute) recap of the material that was presented via recording but should present only a single slide on which the discussion points are all summarized. The presenter should use the WBS input to inform this recap and to address questions and comments that were submitted in advance. + +High quality real-time captioning of the meeting should be provided in more than one language. + +We will use IRC as the default mode of hand-raising and discussion. If you have difficulty accessing IRC, for instance due to network firewalls or assistive technology reasons, please let us know the reason in advance in case we are able to address it or otherwise provide an alternative. + +Special guests are still welcome in the meeting, upon approval of the Chair of the Advisory Committee meeting. Recordings *may* be available for a limited time for special guests. + +## Meeting formats {#sessions} + +Agenda items during virtual presence meetings could take several of the following forms. The following sections propose some suggested alternatives to in-person meetings. + +For all forms of sessions the Chairs should also allow asynchronous feedback and discussions, using GitHub issues, emails, or other forms of input before and after a virtual presence meeting, or between days in the case of a multi-day meeting. + +### Primarily discussion sessions {#discussionSessions} + +Intended for agenda items requiring only discussions (such as specification issues or panels). Those should be replaced by dedicated discussion with virtual presence, possibly clustered. + +### Presentation + discussion sessions {#presentationSessions} + +Intended for agenda items requiring a presentation first, followed by a discussion (such as technical proposals or position papers). Those *should* be replaced by pre-recording the presentation(s) with slides at least 24 hours before the discussion (to avoid burden on non-timezone friendly participants). Then, the participants can have one or more dedicated discussion with virtual presence. + +### Update sessions {#updateSessions} + +Intended for agenda items to update the participants on specific items (such as implementation reports or editor updates). Those **should** be replaced by pre-recording the presentation(s) with slides, with possibly *one* teleconference to allow for questions, clustering the updates together. You *MAY* however differ those sessions depending on the important of the topic. \ No newline at end of file From f31937d2770be83673007cf69037821225e5b072 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 14:43:13 +0100 Subject: [PATCH 064/225] Rename from .html to .md --- meetings/{index.html => index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename meetings/{index.html => index.md} (100%) diff --git a/meetings/index.html b/meetings/index.md similarity index 100% rename from meetings/index.html rename to meetings/index.md From 9a6b7c7fed1c251813ff01ec562b3601433a303f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 14:50:25 +0100 Subject: [PATCH 065/225] Convert to markdown --- meetings/index.md | 121 ++++++++++------------------------------------ 1 file changed, 25 insertions(+), 96 deletions(-) diff --git a/meetings/index.md b/meetings/index.md index f4659e104..f27e1fd16 100644 --- a/meetings/index.md +++ b/meetings/index.md @@ -1,97 +1,26 @@ - - - - - W3C Meetings Resources - - - - - - - -
    -

    On This Page → 

    - -
    -
    -
    -

    Resources about W3C Meetings

    - -

    The following resources are included in this Guide:

    - -
    -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +- Running a Meeting with [IRC](https://www.w3.org/Project/IRC/) + + - [Scribe 101](https://www.w3.org/2008/04/scribe.html): Taking meeting minutes using W3C IRC tools + - [Quick start guide](https://w3c.github.io/scribe2/scribedoc.html) more details on setting up tools for managing an agenda, generating minutes, and updating issues lists + - [Holidays wiki](https://www.w3.org/wiki/Holidays) to help planning WG work around recurring holidays + - Individual IRC tools ("bots"): + + - [Zakim](https://www.w3.org/2001/12/zakim-irc-bot.html) for queue management, start and end meeting + - [RRSAgent](https://www.w3.org/2002/03/RRSAgent) for minutes management +- [Dealing with timezones](organize) +- [Automated Transcripts](transcripts) +- [Hybrid meeting](hybrid-meeting) +- [Continuity of Operations under Travel Restrictions](continuity) +- [Facilitating Meetings](https://www.w3.org/wiki/Facilitating_Meetings) +- [Scheduling a Zoom Conference](zoom) +- [Hosting W3C Face to Face Meetings](hosting) +- [Policies on Face-to-Face meetings](../#Meetings) +- [Tips for recording presentations in advance](https://www.w3.org/wiki/Virtual_Presentations) +- [Workshops](workshops) \ No newline at end of file From 5d3121ff568dfb7952b1163da01d46b1e3d50faf Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 15:45:32 +0100 Subject: [PATCH 066/225] Rename from .html to .md --- process/{alternate-ac.html => alternate-ac.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{alternate-ac.html => alternate-ac.md} (100%) diff --git a/process/alternate-ac.html b/process/alternate-ac.md similarity index 100% rename from process/alternate-ac.html rename to process/alternate-ac.md From b41dcdc735196f5996bbdeba5e167d216fcfa4f5 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 15:50:19 +0100 Subject: [PATCH 067/225] Convert to markdown --- process/alternate-ac.md | 62 ++++------------------------------------- 1 file changed, 5 insertions(+), 57 deletions(-) diff --git a/process/alternate-ac.md b/process/alternate-ac.md index ee4705094..b53ef2557 100644 --- a/process/alternate-ac.md +++ b/process/alternate-ac.md @@ -1,60 +1,8 @@ - - - - -Appealing a W3C decision - - - - - - - +--- +title: Alternate Advisory Committee Representatives +toc: no +--- - +An organization's AC Rep may designate an Alternate AC Rep, which designation persists until the AC Rep changes or revokes it. Any other action the AC Rep is entitled to take (e.g. responding to AC reviews, voting in elections, joining a group, approving participation requests) may be completed by the AC Rep or Alternate, and binds the organization to the same extent as if the AC Rep had acted. In the event of multiple responses to a request for organizational input, the last response before deadline controls. (Ideally, a shared dashboard helps them coordinate.) -
    -

    Nearby

    - -
    - -
    - -

    An organization's AC Rep may designate an Alternate AC Rep, which designation persists until the AC Rep changes or revokes it. Any other action the AC Rep is entitled to take (e.g. responding to AC reviews, voting in elections, joining a group, approving participation requests) may be completed by the AC Rep or Alternate, and binds the organization to the same extent as if the AC Rep had acted. In the event of multiple responses to a request for organizational input, the last response before deadline controls. (Ideally, a shared dashboard helps them coordinate.)

    - -

    Alternates receive the same email notifications and list subscriptions as AC Reps, and may attend meetings and calls. All participants are asked to ensure that people know "with which hat" they are speaking when commenting, and to avoid overwhelming message frequency. -

    -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - From 8b42ee6a37d854b56f9b382191da6bf60b8269b5 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 16:03:58 +0100 Subject: [PATCH 068/225] Rename from .html to .md --- process/{ac-appeal.html => ac-appeal.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{ac-appeal.html => ac-appeal.md} (100%) diff --git a/process/ac-appeal.html b/process/ac-appeal.md similarity index 100% rename from process/ac-appeal.html rename to process/ac-appeal.md From 76a8d5b091c4f320a89b467fbd49f9135583d8f8 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 16:11:33 +0100 Subject: [PATCH 069/225] Convert to markdown --- process/ac-appeal.md | 91 +++++++++----------------------------------- 1 file changed, 18 insertions(+), 73 deletions(-) diff --git a/process/ac-appeal.md b/process/ac-appeal.md index 3fde21b88..ecdf7d167 100644 --- a/process/ac-appeal.md +++ b/process/ac-appeal.md @@ -1,81 +1,26 @@ - - - - -Appealing a W3C decision - - - - - - - +--- +title: Appealing a W3C Decision +toc: no +--- - +The W3C process document allows Advisory Committee representatives to initiate an [Advisory Committee Appeal](/policies/process/#advisory-committee-appeal). This document provides an [email template](@@) to start the appeal. -
    -

    Nearby

    - -
    +``` + To: w3t@w3.org + Cc: w3c-ac-forum@w3.org + Subject: Appeal of a W3C Decision -
    + On behalf of [W3C Member], I appeal the decision issued at + [link to the record of the decision] -

    The W3C process document allows Advisory Committee representatives to - initiate an Advisory - Committee Appeal. - This document provides an email template to start the appeal.

    -
    -  To: w3t@w3.org
    -  Cc: w3c-ac-forum@w3.org
    -  Subject: Appeal of a W3C Decision
    +    I am formally requesting that the W3C Team starts the appeal process
    +    with the Advisory Committee.
     
    -  On behalf of [W3C Member], I appeal the decision issued at
    -     [link to the record of the decision]
    +    [provide the rationale for the Advisory Committee to support this appeal]
    +```
     
    -  I am formally requesting that the W3C Team starts the appeal process
    -  with the Advisory Committee.
    +**Note**: While copying w3c-ac-forum is not required, it is highly recommended to make your appeal visible to the W3C Membership.
     
    -  [provide the rationale for the Advisory Committee to support this appeal]
    -
    +### Revision History -

    Note: While copying w3c-ac-forum is not required, it is highly recommended - to make your appeal visible to the W3C Membership.

    - -

    Revision History

    -
      -
    • 2022-12-14: Document created.
    • -
    - -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +- 2022-12-14: Document created. \ No newline at end of file From 2bb118afefd40fe7d363cb299a1e234a99f6aac2 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 16:33:17 +0100 Subject: [PATCH 070/225] Rename from .html to .md --- process/{binding-license.html => binding-license.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{binding-license.html => binding-license.md} (100%) diff --git a/process/binding-license.html b/process/binding-license.md similarity index 100% rename from process/binding-license.html rename to process/binding-license.md From 4f28eeab471b8306017824184c454a02d26f16a0 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 16:46:11 +0100 Subject: [PATCH 071/225] Convert to markdown --- process/binding-license.md | 65 +++++--------------------------------- 1 file changed, 8 insertions(+), 57 deletions(-) diff --git a/process/binding-license.md b/process/binding-license.md index 2eecaec57..d2958b47c 100644 --- a/process/binding-license.md +++ b/process/binding-license.md @@ -1,61 +1,12 @@ - - - - - How to license definitions and bindings - - - +--- +title: How to license definitions and bindings +toc: no +--- - +Some Working Groups define API definitions, with examples and are still using the [W3C document license](https://www.w3.org/copyright/document-license-2023/). - - -

    This page is Public

    - - -
    -

    Some Working Groups define API definitions, with examples and are still using the W3C document -license.

    - -

    If you include WebIDL definitions, examples, code samples, the document -license states (as of January 1st, 2023):

    - -
    -

    In addition, "Code Components" — Web IDL in sections clearly marked as Web IDL; and W3C-defined markup (HTML, CSS, etc.) and computer programming language code clearly marked as code examples— are licensed under the W3C Software License.

    -
    -
    - -

    The W3C Software License is listed at the Open Source Initiative.

    - -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +The [W3C Software License](https://www.w3.org/copyright/software-license-2023/) is listed at the [Open Source Initiative](https://opensource.org/licenses/W3C). \ No newline at end of file From 7a5efbb20c27ee41831faa22c16ec275227ea3e0 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 16:51:19 +0100 Subject: [PATCH 072/225] Rename from .html to .md --- process/{adv-notice.html => adv-notice.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{adv-notice.html => adv-notice.md} (100%) diff --git a/process/adv-notice.html b/process/adv-notice.md similarity index 100% rename from process/adv-notice.html rename to process/adv-notice.md From 2b271570467e5bfaeba7031d92b952b9e50caa78 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 17:19:46 +0100 Subject: [PATCH 073/225] Convert to markdown preserving headers id --- process/adv-notice.md | 180 ++++++++++++++---------------------------- 1 file changed, 60 insertions(+), 120 deletions(-) diff --git a/process/adv-notice.md b/process/adv-notice.md index 53b3a63bb..6d86635bf 100644 --- a/process/adv-notice.md +++ b/process/adv-notice.md @@ -1,137 +1,77 @@ - - - - -How to send advance notice of work to the Advisory Committee - - - - - - - - - -

    This document describes the Strategy -Team's implementation of -the Process -Document requirements related to advance notice to the Advisory -Committee of charters in development. See the -background for the advance notice policy and -this document.

    - -

    Sending advance notice to the Advisory Committee

    - -
    -
    Who/Where
    -
    -

    The Strategy team determines when -to inform the AC of work-in-progress. These announcements are sent by the W3C Communications Team -to w3c-ac-members@w3.org and then forwarded to: - chairs@w3.org.

    -

    Unless an advance notice strongly requires +--- +title: How to send advance notice of work to the Advisory Committee +toc: yes +--- + +This document describes the [Strategy Team](https://www.w3.org/staff/strat/)'s [implementation](#policy) of the [Process Document requirements](/policies/process/#WGCharterDevelopment) related to advance notice to the Advisory Committee of charters in development. See the [background](#bg) for the advance notice policy and this document. + +## Sending advance notice to the Advisory Committee {#policy} + +Who/Where +: The Strategy team determines when +to inform the AC of work-in-progress. These announcements are sent by +the W3C Communications +Team to w3c-ac-members@w3.org and then forwarded to: chairs@w3.org. + + Unless an advance notice strongly requires Member-only confidentiality (which should be rare), we also inform the public via public-new-work@w3.org ( see example) and new-work@ietf.org. This -is done by the W3C Communications Team.

    -
    +is done by the W3C Communications Team. + -
    When
    -
    -

    Specialists, in conjunction with the Strategy Lead, make this +When +: Specialists, in conjunction with the Strategy Lead, make this decision based on early assessment of the factors available in the "Evaluation" section of the Funnel, as well as considering when it is useful to encourage broader input to discussion. In the Process-required notice to the AC, the Strategy team will give an early status report on the work and likely timeline -for further progress (from information captured in the Funnel).

    -

    Advance notice is not an indication that work *will* necessarily be +for further progress (from information captured in the Funnel). + + Advance notice is not an indication that work *will* necessarily be sent for charter review, but an indication that the Team is seriously evaluating possible work, and seeks wider feedback. -

    -
    -
    How/What
    -
    -

    There is +How/What +: There is a template for advance notice. Please look for recent examples in the w3c-ac-members -archive.

    - -

    The advance notice announcement to the Membership MUST include this -information:

    - -
      -
    • A summary of the intended work
    • -
    • A statement welcoming the Members to -use w3c-ac-forum for general expressions -of interest and support.
    • -
    • A request that Members send substantive comments and engage -on substantive discussion on a different mailing list or github repository -(i.e., other than w3c-ac-forum).
    • -
    • If applicable, a statement that the archive of this second list -is Member-visible.
    • -
    • Contact information if people have questions; generally these will -be the names of one or more people on the Team.
    • -
    - -

    The advance notice announcement to the Membership SHOULD include this -information:

    - -
      -
    • Expectations about when a formal Advisory Commitee Review might begin.
    • -
    - -

    The advance notice announcement to the Membership MAY include this -information:

    - -
      -
    • Pointers to draft materials. In other words, the announcement is +archive. + + The advance notice announcement to the Membership MUST include this +information: + + - A summary of the intended work + - A statement welcoming the Members to use w3c-ac-forum for general expressions of interest and support. + - A request that Members send substantive comments and engage on substantive discussion on a different mailing list or github repository (i.e., **other than w3c-ac-forum**). + - If applicable, a statement that the archive of this second list is Member-visible. + - Contact information if people have questions; generally these will be the names of one or more people on the Team. + + The advance notice announcement to the Membership SHOULD include this +information: + + - Expectations about when a formal Advisory Commitee Review might begin.
    • + + The advance notice announcement to the Membership MAY include this +information: + + - Pointers to draft materials. In other words, the announcement is not required to include a draft charter, but if one is available, -please include it. -
    • Information about other mailing lists for comments, as the -situation requires.
    • -
    -
    -
    - -

    Background for this document

    - -

    The Process Document requirements for -advance notice were introduced in response to requests from Members to -be more in the loop earlier for work in development. These -requirements were added to provide additional transparency to -some work carried out (in general) by the Team, -to encourage Members to show support for work -in development early (on w3c-ac-forum), and to enable those interested in -shaping a charter to participate on a separate list (so as not to -flood w3c-ac-forum).

    - -

    Hence the sentence in the Process Document: "Advisory Committee -representatives MAY provide feedback on the Advisory -Committee discussion list or via other designated channels."

    - -

    These ideas are further discussed in Tips for Getting to -Recommendation Faster, in particular:

    - -
    -

    When a Charter is proposed to the Advisory Committee, garner support from fellow W3C Members on w3c-ac-forum. When there is substantial support for new work among the Members, the Team may create a special mailing list for discussion among Members and Team about Group charter development. Start discussions with proposals, calendars, statements of expected resource commitments, and other such signals.

    -
    - -
    -

    Feedback is to @w3c/guidebook - is welcome on GitHub

    - - +please include it. + - Information about other mailing lists for comments, as the +situation requires. + +## Background for this document {#bg} + +The [Process Document requirements](/policies/process/#WGCharterDevelopment) for advance notice were introduced in response to requests from Members to be more in the loop earlier for work in development. These requirements were added to provide additional transparency to some work carried out (in general) by the Team, to encourage Members to show support for work in development early (on w3c-ac-forum), and to enable those interested in shaping a charter to participate on a separate list (so as not to flood w3c-ac-forum). + +Hence the sentence in the Process Document: "Advisory Committee representatives MAY provide feedback on the Advisory Committee discussion list or via other designated channels." + +These ideas are further discussed in [Tips for Getting to +Recommendation Faster](http://www.w3.org/2002/05/rec-tips), in +particular: + +{% include quote.html content="When a Charter is proposed to the Advisory Committee, garner support from fellow W3C Members on w3c-ac-forum. When there is substantial support for new work among the Members, the Team may create a special mailing list for discussion among Members and Team about Group charter development. Start discussions with proposals, calendars, statements of expected resource commitments, and other such signals."%} \ No newline at end of file From e3fcf718f36f6b88b88dcad5e97df6993edfc808 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 17:50:48 +0100 Subject: [PATCH 074/225] Rename from .html to .md --- process/{joint-deliverables.html => joint-deliverables.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{joint-deliverables.html => joint-deliverables.md} (100%) diff --git a/process/joint-deliverables.html b/process/joint-deliverables.md similarity index 100% rename from process/joint-deliverables.html rename to process/joint-deliverables.md From 0383bef69aa62fdb3058db4e83e08d89f1ffdf03 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 13 Dec 2024 20:10:20 +0100 Subject: [PATCH 075/225] Started conversion to markdown --- process/joint-deliverables.md | 60 +++-------------------------------- 1 file changed, 5 insertions(+), 55 deletions(-) diff --git a/process/joint-deliverables.md b/process/joint-deliverables.md index a40dca879..d47347209 100644 --- a/process/joint-deliverables.md +++ b/process/joint-deliverables.md @@ -1,50 +1,7 @@ - - - - -Joint deliverables between Groups - - - - - - - - - - -
    -

    Nearby

    - -
    - -
    +--- +title: Joint deliverables +toc: yes +---

    This document provides details about joint deliverables between W3C Groups.

    @@ -99,14 +56,7 @@ wisdom of the W3C Group Chairs and other collaborators.

    -

    Revision History

    +

    Revision History

    • 2023-09-14: Document created from #754.
    - -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - From b69a1fdb78d0cfb96f884a43ba67bef65d2c664f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 10:34:05 +0100 Subject: [PATCH 076/225] Convert to markdown --- process/joint-deliverables.md | 79 +++++++++++------------------------ 1 file changed, 25 insertions(+), 54 deletions(-) diff --git a/process/joint-deliverables.md b/process/joint-deliverables.md index d47347209..244132e33 100644 --- a/process/joint-deliverables.md +++ b/process/joint-deliverables.md @@ -3,60 +3,31 @@ title: Joint deliverables toc: yes --- -

    This document provides details about joint deliverables between W3C Groups.

    +This document provides details about joint deliverables between W3C Groups. -

    Joint deliverables between W3C Working Groups

    -

    As a general principle, each Working Group must follow its charter, including in the case of joint deliverables.

    +## Joint deliverables between W3C Working Groups {#between-wgs} -
      -
    1. -

      - If one of the Working Groups decides to drop a joint deliverable from its charter, - only the charters of the remaining Working Groups involved in that joint deliverable are applicable. -

      -
    2. -
    3. -

      - A Working Group cannot publish features on the W3C standard track that are outside of its scope. - The scope of the narrower Working Group prevails in joint deliverables. - As such, any feature which is out of scope for one of the Working Groups involved cannot appear in the joint deliverable. -

      -
    4. -
    5. -

      - Each Working Group is obligated to follow its Success criteria requirements. - So the success criteria of the joint deliverable is the combination of the success criteria of all of the Working Groups involved.
      - Any conflict between the success criteria sections ought to be resolved before the charters are approved. -

      -
    6. -
    7. -

      - Each Working Group must follow its decision policy. - If conflicting decisions are recorded, the Working Groups need to resolved their differences. -

      -

      - For example, all of the Working Groups must agree to publish a new revision of the joint deliverable in order for the publication - of the joint deliverable to happen. -

      -
    8. -
    9. -

      - Each Working Group must follow its patent policy.
      - Any conflict between the patent policy sections ought to be resolved before the charters are approved. -

      -

      - As of 2023, all Working Groups are following the same version of the Patent Policy so no conflict can appear. -

      -
    10. -
    11. -

      - Each Working Group must follow its licensing requirements.
      - Any conflict between the licensing sections ought to be resolved before the charters are approved. -

      -
    12. -
    +As a general principle, each Working Group must follow its charter, including in the case of joint deliverables. -

    Revision History

    -
      -
    • 2023-09-14: Document created from #754.
    • -
    +1. If one of the Working Groups decides to drop a joint deliverable + from its charter, only the charters of the remaining Working Groups + involved in that joint deliverable are applicable. +2. A Working Group cannot publish features on the W3C standard track that are outside of its scope. The scope of the narrower Working Group prevails in joint deliverables. As such, any feature which is out of scope for one of the Working Groups involved cannot appear in the joint deliverable. +3. Each Working Group is obligated to follow its Success criteria requirements. So the success criteria of the joint deliverable is the combination of the success criteria of all of the Working Groups involved. + + *Any conflict between the success criteria sections ought to be resolved before the charters are approved.* +4. Each Working Group must follow its decision policy. If conflicting decisions are recorded, the Working Groups need to resolved their differences. + + For example, all of the Working Groups must agree to publish a new revision of the joint deliverable in order for the publication of the joint deliverable to happen. +5. Each Working Group must follow its patent policy. + + *Any conflict between the patent policy sections ought to be resolved before the charters are approved.* + + As of 2023, all Working Groups are following the same version of the Patent Policy so no conflict can appear. +6. Each Working Group must follow its licensing requirements. + + *Any conflict between the licensing sections ought to be resolved before the charters are approved.* + +## Revision History + +- 2023-09-14: Document created from [#754](https://github.com/w3c/process/issues/754#issuecomment-1719014704). From 67281a74198fd9481a8be1176aa1db5c2af93f42 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 11:02:13 +0100 Subject: [PATCH 077/225] Rename from .html to .md --- process/{closing-wg.html => closing-wg.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{closing-wg.html => closing-wg.md} (100%) diff --git a/process/closing-wg.html b/process/closing-wg.md similarity index 100% rename from process/closing-wg.html rename to process/closing-wg.md From db678d000efb17180ee41127ab888ea207d4e2c0 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 11:13:13 +0100 Subject: [PATCH 078/225] Convert to markdown --- process/closing-wg.md | 135 +++++++----------------------------------- 1 file changed, 21 insertions(+), 114 deletions(-) diff --git a/process/closing-wg.md b/process/closing-wg.md index 7d9c94bcf..157b6a91a 100644 --- a/process/closing-wg.md +++ b/process/closing-wg.md @@ -1,127 +1,34 @@ - - - - -How to close a work Group - - - - - - - +--- +title: How to close a work Group +toc: yes +--- - +## 1. Introduction {#intro} -

    Introduction

    +The W3C Process describes the [lifecycle of chartered groups](/policies/process/#group-lifecyle). At a high level, W3C closes a work Group once it has completed its work. -

    The W3C Process describes -the lifecycle -of chartered groups. -At a high level, W3C closes a work Group -once it has completed its work. -

    +## 2. Normal closure {#normal} -

    Normal closure

    +Sometimes, after successful completion, the Group is left open to perform **maintenance**; other times, it is closed and a Community Group performs this function. -

    - Sometimes, after successful completion, - the Group is left open to perform maintenance; - other times, it is closed and a Community Group performs this function. -

    +## 3. Early closure {#early} -

    Early closure

    +Exceptionally, a group may be closed before it has completed its work: -

    Exceptionally, a group may be closed before it has completed its work:

    +Insufficient resources +: There is insufficient developer or implementer interest to sustain the group, and the Team proposes to close it. -
    -
    Insufficient resources
    -
    There is insufficient developer or implementer interest - to sustain the group, and the Team proposes to close it. -
    +PAG outcome +: A [Patent Advisory Group](/policies/patent-policy/#sec-Exception) has determined that essential claims exist which cannot be circumvented; so it will not be possible to create a Recommendation which can be freely implemented under the W3C Royalty-Free Patent Policy; thus, it is proposed that the group should be closed. -
    PAG outcome
    -
    A Patent Advisory Group has determined - that essential claims exist which cannot be circumvented; - so it will not be possible to create a Recommendation - which can be freely implemented under the - W3C Royalty-Free Patent Policy; - thus, it is proposed that the group should be closed. -
    +Considered detrimental +: The AB or the TAG has determined that continued operation of the group would be harmful to the Web or to W3C; thus, it is proposed that the group should be closed. -
    Considered detrimental
    -
    The AB or the TAG has determined that - continued operation of the group - would be harmful to the Web or to W3C; - thus, it is proposed that the group should be closed. -
    +Finished early +: All the Recommendation-track deliverables have been completed early, and no other work in scope of the current charter remains to be done. The options are to just let the charter run until it expires, or to formally close the group early. -
    Finished early
    -
    All the Recommendation-track deliverables - have been completed early, - and no other work in scope of the current charter - remains to be done. - The options are to just let the charter run until it expires, - or to formally close the group early. -
    -
    +A proposal to close a Group before the end of its chartered term must be explained. An Advisory Committee review takes place and, if that confirms that the group should be closed, a [W3C Decision](/policies/process/#def-w3c-decision) announces closure of the group. -

    - A proposal to close a Group before the end of its chartered term - must be explained. An Advisory Committee review takes place - and, if that confirms that the group should be closed, - a W3C Decision announces closure of the group. -

    +Note that, if the Group has Recommendation-track specifications in development, and they have not yet reached W3C Recommendation status, closing the group [terminates Disclosure Obligations](/policies/patent-policy/#sec-disclosure-termination) for those specifications. -

    - Note that, if the Group has Recommendation-track specifications in development, - and they have not yet reached W3C Recommendation status, - closing the group - - terminates Disclosure Obligations for those specifications. -

    - -

    - There is Team-only documentation of the - detailed steps for closing a group. -

    - -
    - -

    Feedback is to @w3c/guidebook and - is welcome on GitHub

    - - +There is *Team-only* documentation of the [detailed steps for closing a group.](https://www.w3.org/2003/04/closing-group.html) \ No newline at end of file From 1664e1040eff0812b3ff4101d391f0d3e840fae0 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 11:14:31 +0100 Subject: [PATCH 079/225] Rename from .html to .md --- process/{suspension.html => suspension.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{suspension.html => suspension.md} (100%) diff --git a/process/suspension.html b/process/suspension.md similarity index 100% rename from process/suspension.html rename to process/suspension.md From 4d882967369fb1b00cead14893ef87ee2d96f359 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 11:26:31 +0100 Subject: [PATCH 080/225] Convert to markdown --- process/suspension.md | 138 ++++++++++++++---------------------------- 1 file changed, 44 insertions(+), 94 deletions(-) diff --git a/process/suspension.md b/process/suspension.md index 458810925..46c0845ed 100644 --- a/process/suspension.md +++ b/process/suspension.md @@ -1,94 +1,44 @@ - - - - -Guidelines to suspend or remove participants from groups - - - - - - - - - - -
    -

    Nearby

    - -
    - -
    - -

    The W3C process document empowers the W3C CEO to suspend or remove participants from groups. This document provides details about implementation and delegation.

    -

    The W3C Code of Conduct takes priority in case of any inconsistencies with this document.

    -

    Warnings are given by W3C group chairs and/or team contacts.

    -

    1. Consistent with the practices below, the W3C CEO delegates authority to suspend or remove participants:

    -
      -
    • from a single group, to the CEO;
    • -
    • from a single group that the individual has not formally joined, to the chair(s) of the group; and
    • -
    • from all W3C groups, to the CEO and COO jointly.
    • -
    -

    If the chair, team contact, CEO, or COO is the one accused of unacceptable behavior, they should not be involved in the decision to ban.

    - -

    2. Following violation of the W3C Code of Conduct, at least one warning, and at least one subsequent violation of the Code of Conduct, chairs, or team, may temporarily or permanently suspend participation by a person who has not formally joined the group. -

    - -

    3. Following a warning, a W3C group chair and team contact may propose to suspend or remove a participant from a single group - typically for egregious and repetitive Code of Conduct violations - by making a request to the CEO.

    -
      -
    • If the group chair and team contact are not in agreement, each should explain their reasons.
    • -
    • If the participant is a W3C Member representative, the CEO will coordinate the response with the Member's Advisory Committee representative.
    • -
    • If anyone raises an issue to the CEO that a participant fails to meet the requirements of Individual Participation Criteria, then the CEO is empowered to investigate. If the participant indeed is failing to meet those requirements, then after at least one warning and at least one subsequent violation, the CEO may temporarily or permanently suspend participation.
    • -
    -

    4. In extreme cases (such as death threats, or physical threats in general), the CEO and COO, acting together, may suspend or remove someone from participation in all groups. The CEO and COO must announce the action to W3C Management along with the rationale.

    - -

    5. Typically a suspension will encompass participation in all forms, including meetings, email, IRC, Github posting, etc. In no case may a person be blocked from seeing public information (e.g. mailing list or Github posts, public minutes).

    - -

    6. No individual may be banned from sending email to the W3C Ombuds team. (Bots may be banned.)

    - -

    7. The W3C Systems team may block spammers and others who abuse our systems.

    - -

    8. The W3C Systems team will provide technical support to implement suspensions.

    - -

    Revision History

    -
      -
    • 2024-10-01: Replaced "Director" with "W3C CEO", consistent with the Director-free changes in the W3C Process.
    • -
    • 2024-03-24: Updated Code of Conduct (Code) is adopted (W3C Chairs may read the W3C decision.)
    • -
    • 2022-09-21: CEPC takes precedence. Warnings need to be sent by Chairs/TCs before suspension.
    • -
    • 2020-08-28: Document becomes operational.
    • -
    • 2020-08-21: Document created.
    • -
    - -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    - - +--- +title: Guidelines to suspend or remove participants from groups +toc: no +--- + +The W3C process document empowers the W3C CEO to [suspend or remove participants from groups](/policies/process/#ParticipationCriteria). This document provides details about implementation and delegation. + +The [W3C Code of Conduct](/policies/code-of-conduct/) takes priority in case of any inconsistencies with this document. + +Warnings are given by W3C group chairs and/or team contacts. + +1\. Consistent with the practices below, the W3C CEO delegates authority to suspend or remove participants: + +- from a single group, to the CEO; +- from a single group that the individual has not formally joined, to the chair(s) of the group; and +- from all W3C groups, to the CEO and COO jointly. + +If the chair, team contact, CEO, or COO is the one accused of unacceptable behavior, they should not be involved in the decision to ban. + +2\. Following violation of the [W3C Code of Conduct](/policies/code-of-conduct/), at least one warning, and at least one subsequent violation of the Code of Conduct, chairs, or team, may temporarily or permanently suspend participation by a person who has not formally joined the group. + +3\. Following a warning, a W3C group chair and team contact may propose to suspend or remove a participant from a single group - typically for egregious and repetitive Code of Conduct violations - by making a request to the CEO. + +- If the group chair and team contact are not in agreement, each should explain their reasons. +- If the participant is a W3C Member representative, the CEO will coordinate the response with the Member's Advisory Committee representative. +- If anyone raises an issue to the CEO that a participant fails to meet the requirements of [Individual Participation Criteria](/policies/process/#ParticipationCriteria), then the CEO is empowered to investigate. If the participant indeed is failing to meet those requirements, then after at least one warning and at least one subsequent violation, the CEO may temporarily or permanently suspend participation. + +4\. In extreme cases (such as death threats, or physical threats in general), the CEO and COO, acting together, may suspend or remove someone from participation in all groups. The CEO and COO must announce the action to W3C Management along with the rationale. + +5\. Typically a suspension will encompass participation in all forms, including meetings, email, IRC, Github posting, etc. In no case may a person be blocked from seeing public information (e.g. mailing list or Github posts, public minutes). + +6\. No individual may be banned from sending email to the W3C Ombuds team. (Bots may be banned.) + +7\. The W3C Systems team may block spammers and others who abuse our systems. + +8\. The W3C Systems team will provide technical support to implement suspensions. + +### Revision History + +- 2024-10-01: Replaced "Director" with "W3C CEO", consistent with the [Director-free](https://www.w3.org/2023/Process-20230612/#dirfree-changes) changes in the W3C Process. +- 2024-03-24: Updated [Code of Conduct (Code)](https://www.w3.org/news/2024/w3c-adopts-updated-code-of-conduct-code/) is adopted (W3C Chairs may read the [W3C decision](https://lists.w3.org/Archives/Member/chairs/2024JanMar/0059.html).) +- 2022-09-21: CEPC takes precedence. Warnings need to be sent by Chairs/TCs before suspension. +- 2020-08-28: Document becomes operational. +- 2020-08-21: Document created. \ No newline at end of file From dc39539ed228787e2a57a251ce39a71c1edf47f2 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 11:35:09 +0100 Subject: [PATCH 081/225] Convert to markdown --- process/suspension.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/suspension.md b/process/suspension.md index 46c0845ed..5f7535ea4 100644 --- a/process/suspension.md +++ b/process/suspension.md @@ -41,4 +41,4 @@ If the chair, team contact, CEO, or COO is the one accused of unacceptable behav - 2024-03-24: Updated [Code of Conduct (Code)](https://www.w3.org/news/2024/w3c-adopts-updated-code-of-conduct-code/) is adopted (W3C Chairs may read the [W3C decision](https://lists.w3.org/Archives/Member/chairs/2024JanMar/0059.html).) - 2022-09-21: CEPC takes precedence. Warnings need to be sent by Chairs/TCs before suspension. - 2020-08-28: Document becomes operational. -- 2020-08-21: Document created. \ No newline at end of file +- 2020-08-21: Document created. From 2534c511b1024ac35310698038de38bf72b0b988 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 13:31:30 +0100 Subject: [PATCH 082/225] Rename from .html to .md --- ...scinded-supserseded.html => obsolete-rescinded-supserseded.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{obsolete-rescinded-supserseded.html => obsolete-rescinded-supserseded.md} (100%) diff --git a/process/obsolete-rescinded-supserseded.html b/process/obsolete-rescinded-supserseded.md similarity index 100% rename from process/obsolete-rescinded-supserseded.html rename to process/obsolete-rescinded-supserseded.md From b97899771f67b8d7348a132aae597fb47f269e33 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 13:39:40 +0100 Subject: [PATCH 083/225] Convert to markdown --- process/obsolete-rescinded-supserseded.md | 127 +++++++--------------- 1 file changed, 38 insertions(+), 89 deletions(-) diff --git a/process/obsolete-rescinded-supserseded.md b/process/obsolete-rescinded-supserseded.md index 669bd7922..fa652709e 100644 --- a/process/obsolete-rescinded-supserseded.md +++ b/process/obsolete-rescinded-supserseded.md @@ -1,89 +1,38 @@ - - - - - Obsoleting and Rescinding W3C Specifications - - - - - - - -
    -

    Also On This Page →

    - -
    -
    -

    Nearby

    - -
    -
    -

    - Superseded specifications -

    -

    A superseded specification is one that the W3C community has decided that a newer version should be recommended for new adoption instead.

    - -

    The status of a superseded specification remains active under the W3C Patent Policy, but it is not recommended for future implementation.

    - -

    If the W3C community discovers at a later date that the reasons for superseding a specification are no longer valid, the process may be reversed.

    - -

    More information on the process for superseding a specification can be found in section 6.9 of the W3C Process.

    - -

    If you think that a specification has been superseded in error, please contact the W3C.

    - -

    - Obsolete specifications -

    -

    An obsolete specification is one that the W3C community has decided should no longer be used. For example, it may no longer represent best practices, or it may not have received wide adoption and seems unlikely to do so in the future.

    - -

    The status of an obsolete specification remains active under the W3C Patent Policy, but it is not recommended for future implementation.

    - -

    If the W3C community discovers at a later date that the reasons for a specification becoming obsolete are no longer valid, the process may be reversed.

    - -

    More information on the process for making a specification obsolete can be found in section 6.9 of the W3C Process.

    - -

    If you think that a specification has been made obsolete in error, please contact the W3C.

    - -

    - Rescinded specifications -

    - -

    A rescinded specification is one that the W3C community has decided to withdraw. For example, it may contain many errors that conflict with a more recent version, or it may face patent claims that cannot be resolved and which affect implementation.

    - -

    When a specification has been rescinded, it is no longer used and no new licenses are granted under the W3C Patent Policy.

    - -

    More information on the process for rescinding a specification can be found in section 6.9 of the W3C Process.

    - -

    If you think that a specification has been rescinded in error, please contact the W3C.

    - -
    -
    - -

    Feedback is to @w3c/guidebook and - is welcome on GitHub

    - - +--- +title: Obsoleting and Rescinding W3C Specifications +toc: yes +--- + +## Superseded specifications {#superseded} + +A superseded specification is one that the W3C community has decided that a newer version should be recommended for new adoption instead. + +The status of a superseded specification remains active under the W3C Patent Policy, but it is not recommended for future implementation. + +If the W3C community discovers at a later date that the reasons for superseding a specification are no longer valid, the process may be reversed. + +More information on the process for superseding a specification can be found in [section 6.9 of the W3C Process](/policies/process/#rec-rescind). + +If you think that a specification has been superseded in error, please [contact the W3C](mailto:webreq@w3.org). + +## Obsolete specifications {#obsolete} + +An obsolete specification is one that the W3C community has decided should no longer be used. For example, it may no longer represent best practices, or it may not have received wide adoption and seems unlikely to do so in the future. + +The status of an obsolete specification remains active under the W3C Patent Policy, but it is not recommended for future implementation. + +If the W3C community discovers at a later date that the reasons for a specification becoming obsolete are no longer valid, the process may be reversed. + +More information on the process for making a specification obsolete can be found in [section 6.9 of the W3C Process](/policies/process/#rec-rescind). + +If you think that a specification has been made obsolete in error, please [contact the W3C](mailto:webreq@w3.org). + +## Rescinded specifications {#rescinded} + +A rescinded specification is one that the W3C community has decided to withdraw. For example, it may contain many errors that conflict with a more recent version, or it may face patent claims that cannot be resolved and which affect implementation. + +When a specification has been rescinded, it is no longer used and no new licenses are granted under the W3C Patent Policy. + +More information on the process for rescinding a specification can be found in [section 6.9 of the W3C Process](/policies/process/#rec-rescind). + +If you think that a specification has been rescinded in error, please [contact the W3C](mailto:webreq@w3.org). From c1c474d9c895edd92e50450c7cd8115e7e54984b Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 13:52:59 +0100 Subject: [PATCH 084/225] Rename from .html to .md --- process/{charter-extensions.html => charter-extensions.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{charter-extensions.html => charter-extensions.md} (100%) diff --git a/process/charter-extensions.html b/process/charter-extensions.md similarity index 100% rename from process/charter-extensions.html rename to process/charter-extensions.md From 5bba34fb2cecd148bf1ee8c2f60af907788b37f4 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 14:08:22 +0100 Subject: [PATCH 085/225] Convert to markdown --- process/charter-extensions.md | 99 ++++++----------------------------- 1 file changed, 17 insertions(+), 82 deletions(-) diff --git a/process/charter-extensions.md b/process/charter-extensions.md index 85d7d5b79..49c11e3f4 100644 --- a/process/charter-extensions.md +++ b/process/charter-extensions.md @@ -1,85 +1,20 @@ - - - - -Policy on Extending W3C Group Charters - - - - - - +--- +title: Policy on W3C Group Charter End Dates +toc: no +--- - +## Charter Review -

    Charter Review

    -

    From time to time a Working Group or Interest Group will not have - completed its work prior to the end date of its group charter.  The - Director may entertain requests to extend the charter.  The Advisory - Board has asked the CEO to monitor charter end dates and group progress more - closely and in particular to clarify the status of a group that wishes to - continue to work past the end of its charter.

    -
      -
    1. On a quaterly basis, Strategy - will review the - progress of all chartered groups and the Team Contacts will present a plan - for each Group whose charter will have expired prior to the following - quarterly review meeting. Team Contacts are encouraged to look ahead - further than the next review meeting and report expectations for groups - whose charter expires within six months of each review meeting.
    2. -
    3. Strategy will review each such plan during the quarterly meetings and reach - an approved consensus plan.  The Advisory Board encourages the Team to - grant charter extensions sparingly.
    4. -
    5. Any approved plan that re-charters a group, extends a charter, - or closes a Group must be - announced to the Membership, with rationale, prior to the current - charter expiration.
    6. -
    7. Any approved plan to defer a decision; e.g. to see if the group - reaches a specific milestone, must specify the date of a regular weekly - Strategy meeting where a decision will be taken.  The date for this Strategy - discussion must be no later than -
        -
      1. one month prior to the charter expiration if an AC review of the - change to the charter is not expected or
      2. -
      3. three months prior to the charter expiration - if an AC review of the proposed change to the charter might be - conducted.
      4. -
      -

      Whether or not an AC review is conducted, a decision on the current - charter of the Group must be announced to the Membership, with - rationale, prior to the charter expiration.  TiLT may grant short - charter extensions if AC review has not completed prior to the current - charter end date.

      -
    8. -
    9. Publication Requests on behalf of a Group whose charter has expired - more than five business days prior to the date of publication will be - denied.  This five business day allowance is meant only to - accommodate unforeseen circumstances out of the Group's control.
    10. -
    11. Any Group whose charter has expired should not request nor should it - expect W3C Staff support. Strategy may choose to continue some level of - Staff support. Changes in Staff support decided by Function Leads will be - communicated to the chair(s) of the Group.
    12. -
    +From time to time a Working Group or Interest Group will not have completed its work prior to the end date of its group charter. The Director may entertain requests to extend the charter. The Advisory Board has asked the CEO to monitor charter end dates and group progress more closely and in particular to clarify the status of a group that wishes to continue to work past the end of its charter. -
    -

    Feedback is to @w3c/tilt - and is welcome on GitHub

    - - +1. On a quaterly basis, [Strategy](https://www.w3.org/staff/strat/) will review the progress of all chartered groups and the Team Contacts will present a plan for each Group whose charter will have expired prior to the following quarterly review meeting. Team Contacts are encouraged to look ahead further than the next review meeting and report expectations for groups whose charter expires within six months of each review meeting. +2. Strategy will review each such plan during the quarterly meetings and reach an approved consensus plan. The Advisory Board encourages the Team to grant charter extensions sparingly. +3. Any approved plan that re-charters a group, extends a charter, or closes a Group must be announced to the Membership, with rationale, prior to the current charter expiration. +4. Any approved plan to defer a decision; e.g. to see if the group reaches a specific milestone, must specify the date of a regular weekly Strategy meeting where a decision will be taken. The date for this Strategy discussion must be no later than + + - a. one month prior to the charter expiration if an AC review of the change to the charter is not expected or + - b. three months prior to the charter expiration if an AC review of the proposed change to the charter might be conducted. + + Whether or not an AC review is conducted, a decision on the current charter of the Group must be announced to the Membership, with rationale, prior to the charter expiration. TiLT may grant short charter extensions if AC review has not completed prior to the current charter end date. +5. Publication Requests on behalf of a Group whose charter has expired more than five business days prior to the date of publication will be denied. This five business day allowance is meant only to accommodate unforeseen circumstances out of the Group's control. +6. Any Group whose charter has expired should not request nor should it expect W3C Staff support. Strategy may choose to continue some level of Staff support. Changes in Staff support decided by Function Leads will be communicated to the chair(s) of the Group. From cde2f145dbda9331aba165a04c0d663f7d312828 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 14:21:16 +0100 Subject: [PATCH 086/225] Rename from .html to .md --- process/{cg-transition.html => cg-transition.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{cg-transition.html => cg-transition.md} (100%) diff --git a/process/cg-transition.html b/process/cg-transition.md similarity index 100% rename from process/cg-transition.html rename to process/cg-transition.md From 6e0df18fef91e37cbef9f50f1d5ea4dd94891b9b Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 14:27:12 +0100 Subject: [PATCH 087/225] Convert to markdown --- process/cg-transition.md | 335 ++++++++++----------------------------- 1 file changed, 86 insertions(+), 249 deletions(-) diff --git a/process/cg-transition.md b/process/cg-transition.md index 2d75398be..158832247 100644 --- a/process/cg-transition.md +++ b/process/cg-transition.md @@ -1,249 +1,86 @@ - - - - - - How to transition work from a Community Group to a Working Group - - - - - - - - - - -

    - From time to time a Community Group that has been incubating a technology - seeks to advance it to the W3C Recommendation track in a Working Group. - Our goal through this document is to ease that transition. -

    -

    - Preparation -

    -

    - The following questions can help a Community Group to prepare for the - transition of work to a Working Group. -

    -

    - Is the work ready for standardization? -

    -

    - Please see elsewhere in the Guide: W3C Recommendation Track - Readiness Best Practices. -

    -

    - What is the target Working Group and the relation to the CG? -

    -

    - If the Working Group does not yet exist, the Community Group can prepare - by drafting a - Working Group charter. Otherwise, if the group exists but the new - work is not within its scope W3C needs to recharter the group - to accommodate the new work. -

    -

    - The charter of the target Working Group should address two topics: -

    -
      -
    • The list of any deliverables transferred from a Community Group. -
    • -
    • The nature of the working relationship between the Working Group and - the Community Group (if any) for any deliverable originated by the - Community Group. -
    • -
    -

    - @@@TODO extract more from charter template - discussion -

    -

    - Community Group chairs should keep the Community Group participants aware - of the progress on the transition roadmap, in particular if it involves - chartering or re-chartering a Working Group. -

    -

    - Is there a record of Community Group support for the transition? -

    -

    - It is useful to record whether and how the Community Group reached - consensus on the transition (in a manner consistent with its practices). - The consensus should include expectations about the working relationship - with the Working Group moving forward. -

    -

    - Are IPR commitments in place? -

    -

    When a Working Group plans to take up a Community Group specification, it is important that there be "IPR safety" around the resulting Working Group specification.

    - -

    - If significant contributors (see tool below) have not joined the Working Group or don't plan to, then steps should be - taken to secure IPR commitments from them. There are three ways for CG - contributors to make patent licensing commitments for the specification - managed by the Working Group: -

    -
      -
    1. They can join the Working Group (if they haven't already).
    2. -
    3. They can sign the non-participant licensing agreement for - the Working Group.
    4. -
    5. They can make a commitment - (via tools) - to the Community Group specification under the W3C - Community Final Specification Agreement (FSA). Note that - the main difference between the FSA and - the W3C - Community Contributor Licensing Agreement (CLA) is that - patent licensing commitments under the CLA are for one's own - contributions, while commitments under the FSA are for the - full text of the specification. -
    6. -
    - -

    - Once the work transitions to a Working Group, that Working Group's patent - policy becomes the "primary" patent policy. Contributions to the work are - henceforth made under the W3C Patent Policy. When a contributor cannot join the Working Group, W3C will provide tools so that Working Groups can ensure that substantive contributions from non-participants are made under the terms of the W3C Patent Policy. -

    -

    - How can Community Group Participants remain involved in the work after - the transition? -

    -

    - In many cases, Community Group participants will want to continue their - involvement in discussions about a work after it has been transferred to - a Working Group. -

    - -

    - Operations -

    -

    - GitHub Repository Management -

    -

    - W3C has a number of GitHub mechanisms in place for specification - development and to help manage IPR commitments for contributions. -

    -

    - If a Community Group repository is hosted in a GitHub organization not - yet used by W3C to host Recommendation work: -

    -
      -
    • Will the repository itself be transitioned to the W3C GitHub organization? -
    • -
    • If not, is the repository owner willing to grant admin rights to - @w3cbot (which is used to help with managing operational matters on W3C - work, including for horizontal review and IPR management)? -
    • -
    -

    - Is the repository already being monitored by W3C's IPR Repo Manager? -

    -
      -
    • If yes: -
        -
      • Use the list of substantive contributors - tracked by the tool for the repository (linked from the repository list) - to ensure all such contributors have made the expected - IPR commitments.
      • - -
      • Once the transition is enacted (e.g., when the new Working - Group is launched), the IPR manager will need to be updated to reflect - the new IPR status of the work (contact dom@w3.org or plh@w3.org); if the repo is being moved or - renamed at the time of transition, please coordinate specifically with - dom@w3.org as this operation requires - special handling at the moment. -
      • -
      • If not, evaluate manually and even more carefully the IPR considerations described - above. -
      • -
      -

      - Other repository admin for the target Working Group: -

      - -

      - Other repository admin for W3C staff. -

      -
        -
      • Request that the systems team back up the org repositories. -
      • -
      • Update or add LICENSE.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md to - reflect the new contribution framework. -
      • -
      • Configure the repository with the - labels used for tracking horizontal reviews -
      • -
      • If not already set up, make sure members of the - horizontal-admin team have triage access to the repo. -
      • -
      • Make w3cbot a co-owner of the org (useful for integrating the IPR - manager among other things). -
      • -
      • Update validate-repo - to monitor the repos of that org. -
      • -
      -
      -
      - Dominique Hazael-Massieux - for @w3c/guidebook. Issues - welcome on GitHub

      - - +--- +title: How to transition work from a Community Group to a Working Group +toc: yes +--- + +From time to time a Community Group that has been [incubating a technology](../incubation.html) seeks to advance it to the W3C Recommendation track in a Working Group. Our goal through this document is to ease that transition. + +## Preparation + +The following questions can help a Community Group to prepare for the transition of work to a Working Group. + +### Is the work ready for standardization? + +Please see elsewhere in the Guide: [W3C Recommendation Track Readiness Best Practices](https://www.w3.org/Guide/standards-track/). + +### What is the target Working Group and the relation to the CG? + +If the Working Group does not yet exist, the Community Group can prepare by [drafting a Working Group charter](https://www.w3.org/Guide/process/charter.html). Otherwise, if the group exists but the new work is not within its scope W3C needs to [recharter the group](https://www.w3.org/Guide/process/charter.html) to accommodate the new work. + +The charter of the target Working Group should address two topics: + +- The list of any deliverables transferred from a Community Group. +- The nature of the working relationship between the Working Group and the Community Group (if any) for any deliverable originated by the Community Group. + +@@@TODO extract more from [charter template discussion](https://github.com/w3c/charter-drafts/issues/262) + +Community Group chairs should keep the Community Group participants aware of the progress on the transition roadmap, in particular if it involves chartering or re-chartering a Working Group. + +### Is there a record of Community Group support for the transition? + +It is useful to record whether and how the Community Group reached consensus on the transition (in a manner consistent with its practices). The consensus should include expectations about the working relationship with the Working Group moving forward. + +### Are IPR commitments in place? + +When a Working Group plans to take up a Community Group specification, it is important that there be "IPR safety" around the specification managed by the Working Group. Relevant questions are: + +- Who has made significant contributions to the Community Group specification? See below for information about a tool to identify significant contributors](#contributor-list) +- Have those contributors (or the organizations they represent) joined the Working Group or do they plan to do so? + +If significant contributors have not joined the Working Group or don't plan to, then steps should be taken to secure IPR commitments from them. There are three ways for CG contributors to make commitments for the specification managed by the Working Group: + +1. They can join (or already participate in) the Working Group. +1. They can sign the non-participant licensing agreement for the Working Group. +1. They can make a commitment (via [tools](https://www.w3.org/community/about/faq/#fsa-mechanics)) to the Community Group specification under the [>W3C Community Final Specification Agreement (FSA)](https://www.w3.org/community/about/agreements/final/). Note that the main difference between the FSA and the [W3C Community Contributor Licensing Agreement (CLA)](https://www.w3.org/community/about/process/cla/) is that patent licensing commitments under the CLA are for one's own contributions, while commitments under the FSA are for the full text of the specification. + +**Note:** FSA commitments may still have some value for situations where a Working Group ultimately does not advance the specification on the Recommendation Track. Each Community Group should make a determination whether to launch the process of gathering Final Specification commitments, based on (anticipated or actual) Contributor participation in the Working Group. + +Once the work transitions to a Working Group, that Working Group's patent policy becomes the "primary" patent policy. Contributions to the work are henceforth made under the W3C Patent Policy. When a contributor cannot join the Working Group, W3C will provide tools so that Working Groups can ensure that substantive contributions from non-participants are made under the terms of the W3C Patent Policy. + +### How can Community Group Participants remain involved in the work after the transition? + +In many cases, Community Group participants will want to continue their involvement in discussions about a work after it has been transferred to a Working Group. + +- If a Community Group participant works for a [W3C Member](https://www.w3.org/Consortium/Member/list), the participant can ask their Advisory Committee Representative to join the Working Group. +- Otherwise, please contact [Member Relations](mailto:membership@w3.org) to explore [W3C Membership](https://www.w3.org/Consortium/membership). During that exploration, [Community Group participants may continue participating in the Working Group as Invited Experts](https://www.w3.org/community/about/faq/#how-do-community-groups-make-it-easier-to-move-to-the-standards-track). + +## Operations + +### GitHub Repository Management + +W3C has a number of GitHub mechanisms in place for specification development and to help manage IPR commitments for contributions. + +If a Community Group repository is hosted in a GitHub organization not yet used by W3C to host Recommendation work: + +- Will the repository itself be transitioned to the [W3C GitHub organization](https://github.com/w3c)? +- If not, is the repository owner willing to grant admin rights to @w3cbot (which is used to help with managing operational matters on W3C work, including for horizontal review and IPR management)? + +Is the repository already being monitored by [W3C's IPR Repo Manager](https://labs.w3.org/repo-manager/)? + +- If not, evaluate even more carefully the IPR considerations described above. +- If yes: + - Use the list of substantive contributors tracked by the tool for the repository (linked from the [repository list](https://labs.w3.org/repo-manager/repos)) to ensure all such contributors have made the expected [IPR commitments](#ipr-commitments). + - once the transition is enacted (e.g., when the new Working Group is launched), the IPR manager will need to be updated to reflect the new IPR status of the work (contact [dom@w3.org](mailto:dom@w3.org) or [plh@w3.org](mailto:plh@w3.org)); if the repo is being moved or renamed at the time of transition, please coordinate specifically with [dom@w3.org](mailto:dom@w3.org) as this operation requires special handling at the moment. + +Other repository admin for the target Working Group: + +- If not already set up that way, consider [moving away from using `master` as the name of the default branch](https://lists.w3.org/Archives/Public/spec-prod/2021JanMar/0017.html) + +Other repository admin for W3C staff. + +- Request that the systems team back up the org repositories. +- Update or add LICENSE.md, CONTRIBUTING.md, CODE\_OF\_CONDUCT.md to reflect the new contribution framework. +- Configure the repository with the [labels used for tracking horizontal reviews](https://www.w3.org/Guide/documentreview/#working_with_horizontal_review_labels) +- If not already set up, make sure members of the `horizontal-admin` team have triage access to the repo. +- Make w3cbot a co-owner of the org (useful for integrating the IPR manager among other things). +- Update [validate-repo to monitor the repos of that org](https://github.com/w3c/validate-repos/blob/main/validate.js#L9). From 06334b2a95a415ea86c99ef79f5106c916996066 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 15:08:49 +0100 Subject: [PATCH 088/225] Rename from .html to .md --- process/{charter.html => charter.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{charter.html => charter.md} (100%) diff --git a/process/charter.html b/process/charter.md similarity index 100% rename from process/charter.html rename to process/charter.md From 6c287941131b1803daf3c7bcb7e0a6d588ed9ea6 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 16:04:49 +0100 Subject: [PATCH 089/225] Convert to markdown --- process/cg-transition.md | 15 +- process/charter.md | 870 +++++++++++++++------------------------ 2 files changed, 335 insertions(+), 550 deletions(-) diff --git a/process/cg-transition.md b/process/cg-transition.md index 158832247..5efa46ce9 100644 --- a/process/cg-transition.md +++ b/process/cg-transition.md @@ -32,18 +32,14 @@ It is useful to record whether and how the Community Group reached consensus on ### Are IPR commitments in place? -When a Working Group plans to take up a Community Group specification, it is important that there be "IPR safety" around the specification managed by the Working Group. Relevant questions are: +When a Working Group plans to take up a Community Group specification, it is important that there be "IPR safety" around the resulting Working Group specification. -- Who has made significant contributions to the Community Group specification? See below for information about a tool to identify significant contributors](#contributor-list) -- Have those contributors (or the organizations they represent) joined the Working Group or do they plan to do so? +If significant contributors (see [tool](#contributor-list)) below) have not joined the Working Group or don't plan to, then steps should be taken to secure IPR commitments from them. There are three ways for CG contributors to make patent licensing commitments for the specification managed by the Working Group: +{:#ipr-commitments} -If significant contributors have not joined the Working Group or don't plan to, then steps should be taken to secure IPR commitments from them. There are three ways for CG contributors to make commitments for the specification managed by the Working Group: - -1. They can join (or already participate in) the Working Group. +1. They can join the Working Group(if they haven't already). 1. They can sign the non-participant licensing agreement for the Working Group. -1. They can make a commitment (via [tools](https://www.w3.org/community/about/faq/#fsa-mechanics)) to the Community Group specification under the [>W3C Community Final Specification Agreement (FSA)](https://www.w3.org/community/about/agreements/final/). Note that the main difference between the FSA and the [W3C Community Contributor Licensing Agreement (CLA)](https://www.w3.org/community/about/process/cla/) is that patent licensing commitments under the CLA are for one's own contributions, while commitments under the FSA are for the full text of the specification. - -**Note:** FSA commitments may still have some value for situations where a Working Group ultimately does not advance the specification on the Recommendation Track. Each Community Group should make a determination whether to launch the process of gathering Final Specification commitments, based on (anticipated or actual) Contributor participation in the Working Group. +1. They can make a commitment (via [tools](https://www.w3.org/community/about/faq/#fsa-mechanics)) to the Community Group specification under the [W3C Community Final Specification Agreement (FSA)](https://www.w3.org/community/about/agreements/final/). Note that the main difference between the FSA and the [W3C Community Contributor Licensing Agreement (CLA)](https://www.w3.org/community/about/process/cla/) is that patent licensing commitments under the CLA are for one's own contributions, while commitments under the FSA are for the full text of the specification. Once the work transitions to a Working Group, that Working Group's patent policy becomes the "primary" patent policy. Contributions to the work are henceforth made under the W3C Patent Policy. When a contributor cannot join the Working Group, W3C will provide tools so that Working Groups can ensure that substantive contributions from non-participants are made under the terms of the W3C Patent Policy. @@ -70,6 +66,7 @@ Is the repository already being monitored by [W3C's IPR Repo Manager](https://la - If not, evaluate even more carefully the IPR considerations described above. - If yes: - Use the list of substantive contributors tracked by the tool for the repository (linked from the [repository list](https://labs.w3.org/repo-manager/repos)) to ensure all such contributors have made the expected [IPR commitments](#ipr-commitments). + {:#contributor-list} - once the transition is enacted (e.g., when the new Working Group is launched), the IPR manager will need to be updated to reflect the new IPR status of the work (contact [dom@w3.org](mailto:dom@w3.org) or [plh@w3.org](mailto:plh@w3.org)); if the repo is being moved or renamed at the time of transition, please coordinate specifically with [dom@w3.org](mailto:dom@w3.org) as this operation requires special handling at the moment. Other repository admin for the target Working Group: diff --git a/process/charter.md b/process/charter.md index 637886165..001203c05 100644 --- a/process/charter.md +++ b/process/charter.md @@ -1,552 +1,340 @@ - - - - -How to Create a Working Group or Interest Group - - - - - - - - - - - - - -

      The W3C Process describes -the lifecycle -of chartered groups. At a high level, W3C approves a new Working -Group or Interest Group charter after a series of reviews intended to -improve the quality of the charter and generate interest in the -work. The reviews typically happen in this order:

      - -
        -
      • Early socialization (e.g., by the Team or in a Community Group)
      • -
      • Review by the W3C Strategy Team
      • -
      • More socialization within the community
      • -
      • W3C "Horizontal" Group review
      • -
      • Advisory Committee review
      • -
      • In the case of Formal Objections, W3C Council review
      • -
      - -

      In this document we describe the operational aspects of these reviews.

      - -

      Timing: Please note that these reviews take time, and people working on charters should expect the entire process to take multiple months.

      - -

      Note: Group closures are addressed in other documentation.

      - -

      New groups

      - -

      Discussions for new work happen in a variety of venues, including Member discussions, Workshops, Working / Interest / Community Groups, and the Team.

      - -

      Within the Team, the Strategy Team manages the charter development process, including allocation of staff resources. The Strategy Team tracks charters through the process via the pipeline tool.

      - -

      Charter preparation

      - -

      These are the recommended steps for any party preparing a charter for a new Working Group or Interest Group:

      - -
      -
      Check readiness
      -
      For a Working Group charter, review: W3C Recommendation Track Readiness Best Practices, Tips for Getting to Recommendation Faster, and How to transition work from a Community Group to a Working Group.
      -
      Draft charter
      -
      Use the charter template to create a draft charter, ideally on GitHub. This is where substantive discussion of the charter should take place, including issues and pull requests. Note: There are ongoing discussions about making it easier for people to find draft charters, e.g., by using a single GitHub repo for all draft charters.
      -
      Inform Strategy Team
      -
      When ready (e.g., after sufficient discussion among stakeholders has taken place), inform the Strategy Team by -creating a new charter issue in their pipeline. The Strategy Team will use this issue to provide updates on the charter's progress through the process. Discussions of the charter's content should continue to take place in the charter's own repo.
      -
      - -

      Strategy Team role

      - -

      When a new charter issue has been raised, the Strategy Team Lead assigns a staff member to shepherd the charter through the remainder of the process, the charter shepherd is the “assignee” of the issue in the pipeline. The Strategy Team typically discusses proposed charters at its regular meeting or on its mailing list. Note: If the Strategy Team Lead cannot identify a staff member, there may be delays in advancing the charter through subsequent reviews.

      - -

      The charter shepherd (on behalf of the Strategy Team) roles include:

      - -
      -
      Evaluate readiness
      -
      Let the proponents know if the charter is not well-formed (per the template and per Process section "content of a charter"); if it is perceived to be harmful to the Web; or if it is not a priority at the current time.
      -
      Request advance notice to AC
      -
      If and when satisfied with the charter, raise awareness by requesting that the W3C Communications Team send an advance notice to the W3C Advisory Committee; for details see -how to - send advance notice of work to the Advisory Committee. Record in the pipeline issue that advance notice has been sent. - -
      Timing: The exact timing of the advance notice may vary from charter to charter. In practice, if the advance notice would precede the formal call for review by only a short delay, we skip the advance - notice. -
      -
      Request horizontal review
      -
      Soon after, or in parallel, initiate horizontal review. This is done by - adding the "Horizontal review requested" label to the issue in the pipeline. -
      Timing: Horizontal reviewers will usually respond within two weeks, though it is wise to allow for additional time. The charter shepherd may use the team-horizontal list to reach all the horizontal reviewers. -
      Horizontal reviews are not required for Groups that do not hold technical discussions, such as the Patents and Standards Interest Group. -
      -
      Prepare for TiLT Review
      -
      -
        -
      • Charter changes: Horizontal and other reviews may result in changes to the charter, or to objections. The charter shepherd should note in the request to TiLT the horizontal review status (including completed reviews and any timeouts).
      • -
      • Chairs: Per the W3C Process the W3C Team appoints Working and Interest Group Chairs. It is the responsibility of the charter shepherd to propose one or more Chairs in the request for TiLT approval.
      • -
      -
      -
      Request approval from TiLT
      -
      When the charter shepherd is satisfied that as much progress as possible has been made, they request approval from TiLT. Record in the pipeline issue that a TiLT decision has been requested. TiLT informs the charter shepherd of their decision in the pipeline issue. -
      Timing: Allow approximately 2 weeks, but see Timing of responses from TiLT for details. -
      -
      +--- +title: How to create a Working Group or Interest Group +toc: yes +--- -

      If approved, the charter shepherd works towards Advisory Committee Review.

      +The W3C Process describes the [lifecycle of chartered groups](/policies/process/#group-lifecyle). At a high level, W3C approves a new Working Group or Interest Group charter after a series of reviews intended to improve the quality of the charter and generate interest in the work. The reviews typically happen in this order: -

      Advisory Committee Review

      +- Early socialization (e.g., by the Team or in a Community Group) +- Review by the W3C Strategy Team +- More socialization within the community +- W3C "Horizontal" Group review +- Advisory Committee review +- In the case of [Formal Objections](../council/council), W3C Council review -

      In this part of the process, the charter shepherd (on behalf of the Strategy Team) roles are:

      - -
      -
      Prepare for AC Review
      -
      Work with the W3C Communications Team to organize Advisory Committee review of a charter (see implementation details for the review).
      -
      Monitor AC Review
      -
      Once the AC Review is underway, monitor responses and manage any Formal Objections. Ensure that the charter receives sufficient support from the Membership. -
      Timing: -
        -
      • Per the W3C Process, the review period is at least 28 days.
      • -
      • Any Advisory Committee representative may request an extended review period of any new or substantively modified Working Group charter as part of their response to the Call for Review. In this case the existing charter may need to be extended (see extension template). In case of extended review period, the Team must ensure that the Call for Participation for the work group occurs at least 60 days after the Call for Review of its charter.
      • -
      • The handling of Formal Objections to a charter adds more time.
      • -
      -
      -
      Manage changes resulting from review
      -
      As a result of review, make any requested very minor changes (in place) to the charter. If substantive changes are proposed, then initiate review of those proposed changes. In either case, the Team follows a process for managing changes to charters after review.
      -
      Request approval from TiLT
      -
      Once the review has ended and Formal Objections are addressed, the charter shepherd requests approval from TiLT. Record in the pipeline issue that a TiLT decision has been requested. TiLT informs the charter shepherd of their decision. -
      Timing: Allow approximately 2 weeks, but see Timing of responses from TiLT for details. -
      -
      - -

      If approved, the charter shepherd then works with the W3C Communications Team to announce the decision.

      +In this document we describe the operational aspects of these reviews. -

      Existing groups

      - -

      Here we describe the operational aspects of extending or modifying the charter of an existing group.

      +*Timing:* Please note that these reviews take time, and people working on charters should expect the entire process to take multiple months. -

      In these processes, a group's Team Contact typically plays the role of the charter shepherd.

      +**Note:** [Group closures](closing-wg.html) are addressed in other documentation. +## 1. New groups {#new-charters} -

      Request for short-term extension

      +Discussions for new work happen in a variety of venues, including Member discussions, Workshops, Working / Interest / Community Groups, and the Team. -

      The W3C Process describes the charter extensions and when they may occur. No Advisory Committee review is required for short-term extensions. Since 2015, the Team has adopted a policy on group charter end dates: a charter may only be extended without AC review for six months or less, otherwise it must recharter.

      +Within the Team, the *Strategy Team* manages the charter development process, including allocation of staff resources. The Strategy Team tracks charters through the process via the [pipeline](https://github.com/w3c/strategy/projects/2) tool. -

      For a short-term extension, the charter shepherd roles are:

      +### 1.1. Charter preparation {#charter-prep} + +These are the recommended steps for any party preparing a charter for a new Working Group or Interest Group: + +Check readiness +: For a Working Group charter, review: [W3C Recommendation Track Readiness Best Practices](https://www.w3.org/Guide/standards-track/), [Tips for Getting to Recommendation Faster](/2002/05/rec-tips), and [How to transition work from a Community Group to a Working Group](cg-transition.html). + +Draft charter +: Use the [charter template](https://w3c.github.io/charter-drafts/charter-template.html) to create a draft charter, ideally on GitHub. This is where substantive discussion of the charter should take place, including issues and pull requests. **Note:** There are ongoing discussions about making it easier for people to find draft charters, e.g., by using a single GitHub repo for all draft charters. + +Inform Strategy Team +: When ready (e.g., after sufficient discussion among stakeholders has taken place), inform the Strategy Team by [creating a new charter issue](https://github.com/w3c/strategy/issues/new?assignees=&labels=Evaluation%3A%20untriaged&template=04-Chartering.md&title=) in their [pipeline](#pipeline). The Strategy Team will use this issue to provide updates on the charter's progress through the process. Discussions of the charter's content should continue to take place in the charter's own repo. + +### 1.2. Strategy Team role {#strategy-team-role} + +When a new charter issue has been raised, the Strategy Team Lead assigns a staff member to shepherd the charter through the remainder of the process, the charter shepherd is the “assignee” of the issue in the pipeline. The Strategy Team typically discusses proposed charters at its regular meeting or on its mailing list. **Note:** If the Strategy Team Lead cannot identify a staff member, there may be delays in advancing the charter through subsequent reviews. + +The [charter shepherd](#charter-shepherd) (on behalf of the Strategy Team) roles include: + +Evaluate readiness +: Let the proponents know if the charter is not well-formed (per the template and per Process section "[content of a charter](/policies/process/#WGCharter)"); if it is perceived to be harmful to the Web; or if it is not a priority at the current time. + +Request advance notice to AC +: If and when satisfied with the charter, raise awareness by +requesting that the W3C Communications Team send an [advance notice to +the W3C Advisory Committee](/policies/process/#WGCharterDevelopment); +for details see [how to send advance notice of work to the Advisory +Committee](adv-notice.html). Record in the [pipeline](#pipeline) issue +that advance notice has been sent. +*Timing:* The exact timing of the advance notice may vary from charter to charter. In practice, if the advance notice would precede the formal call for review by only a short delay, we skip the advance notice. + +Request horizontal review +: Soon after, or in parallel, initiate [horizontal review](https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review). This is done by adding the "[Horizontal review requested](https://github.com/w3c/strategy/labels/Horizontal%20review%20requested)" label to the issue in the [pipeline](#pipeline). +*Timing:* Horizontal reviewers will usually respond within two weeks, though it is wise to allow for additional time. The charter shepherd may use the team-horizontal list to reach all the horizontal reviewers. +Horizontal reviews are not required for Groups that do not hold technical discussions, such as the Patents and Standards Interest Group. + +Prepare for TiLT Review +: +- *Charter changes*: Horizontal and other reviews may result in changes to the charter, or to objections. The charter shepherd should note in the [request to TiLT](./tilt/#request) the horizontal review status (including completed reviews and any timeouts). +- *Chairs:* Per the [W3C Process](/policies/process/#ReqsAllGroups) the W3C Team appoints Working and Interest Group Chairs. It is the responsibility of the charter shepherd to propose one or more Chairs in the request for TiLT approval. + +Request approval from TiLT +: When the charter shepherd is satisfied that as much progress as possible has been made, they [request approval from TiLT](./tilt/#request). Record in the [pipeline](#pipeline) issue that a TiLT decision has been requested. TiLT informs the charter shepherd of their decision in the [pipeline](#pipeline) issue. +*Timing:* Allow approximately 2 weeks, but see [Timing of responses from TiLT](./tilt/#timing) for details. + +If approved, the charter shepherd works towards Advisory Committee Review. + +### 1.3. Advisory Committee Review {#ac-review} + +In this part of the process, the charter shepherd (on behalf of the Strategy Team) roles are: + +Prepare for AC Review +: Work with the W3C Communications Team to organize Advisory Committee review of a charter (see [implementation details for the review](#organize-cfr)). + +Monitor AC Review +: Once the AC Review is underway, monitor responses and [manage any Formal Objections](../council/council). Ensure that the charter receives [sufficient support from the Membership](#baseline-support). +*Timing:* + + - [Per the W3C Process](/policies/process/#CharterReview), the review period is at least 28 days. + - Any Advisory Committee representative may request an extended review period of any new or substantively modified Working Group charter as part of their response to the Call for Review. In this case the existing charter may need to be extended (see [extension template](https://www.w3.org/new-doc-from-template?location=%2FTeam%2Ftemplates&template=%2Fafs%2Fw3.org%2Fpub%2FWWW%2FTeam%2FTemplates%2Fcharter-extension.html&submit=Continue...)). In case of extended review period, the Team must ensure that the Call for Participation for the work group occurs at least 60 days after the Call for Review of its charter. + - The handling of Formal Objections to a charter adds more time. + +Manage changes resulting from review +: As a result of review, make any requested very minor changes (in place) to the charter. If substantive changes are proposed, then initiate review of those proposed changes. In either case, the Team follows a process for [managing changes to charters after review](#manage-changes). + +Request approval from TiLT +: Once the review has ended and [Formal Objections are addressed](../council/council), the charter shepherd [requests approval from TiLT](./tilt/#request). Record in the [pipeline](#pipeline) issue that a TiLT decision has been requested. TiLT informs the charter shepherd of their decision. +*Timing:* Allow approximately 2 weeks, but see [Timing of responses from TiLT](./tilt/#timing) for details. + +If approved, the charter shepherd then works with the W3C Communications Team to [announce the decision](#announce-decision). + +## 2. Existing groups {#existing-groups} + +Here we describe the operational aspects of extending or modifying the charter of an existing group. + +In these processes, a group's [Team Contact](/Guide/teamcontact/role.html) typically plays the role of the [charter shepherd](#charter-shepherd). + +### 2.1. Request for short-term extension {#extension-request} + +The W3C Process describes the [charter extensions](/policies/process/#charter-extension) and when they may occur. No Advisory Committee review is required for short-term extensions. Since 2015, the Team has adopted a [policy on group charter end dates](charter-extensions): a charter may only be extended without AC review for six months or less, otherwise it must recharter. + +For a short-term extension, the charter shepherd roles are: + +Request approval from TiLT +: The charter shepherd [requests approval of the short extension by TiLT](./tilt/#request). +*Timing:* Allow approximately 2 weeks, but see [Timing of responses from TiLT](./tilt/#timing) for details. + +Request extension notice +: If the decision is positive, request that the W3C Communications Team [announce an extension](#announce-extension). + +Let the group know +: The W3C Communications Team inform the group that its charter has been extended. + +### 2.2. Request for rechartering {#recharter-request} + +A group recharters when it wishes to change its charter or extend it longer than six months. + +In these processes, the roles of the charter shepherd are: + +Record group decision +: The group should discuss and record a formal decision to request extension or to recharter. + +Follow process for creating a charter +: The handling of rechartering is almost the same as for [new charters](#new-charters). Note that, in addition to any content changes, the charter may need to be updated if the [charter template](https://w3c.github.io/charter-drafts/charter-template.html) has changed. Furthermore, the template tool will prompt for the inclusion of Patent Policy language and otherwise help you meet the [list of charter requirements in the Process](/policies/process/#WGCharter). For existing groups, the [charter assistant](https://www.w3.org/groups/wg/css/deliverables) helps in producing the list of exclusion drafts. + +## 3. Implementation details {#implementation-details} + +The following sections are mostly intended as instructions to the Team and are included here for transparency. + +### 3.1. Sufficient Member support for a charter {#baseline-support} -
      -
      Request approval from TiLT
      -
      The charter shepherd requests approval of the short extension by TiLT. -
      Timing: Allow approximately 2 weeks, but see Timing of responses from TiLT for details. -
      -
      Request extension notice
      -
      If the decision is positive, request that the W3C Communications Team announce an extension.
      -
      Let the group know
      -
      The W3C Communications Team inform the group that its charter has been extended.
      -
      - -

      Request for rechartering

      - -

      A group recharters when it wishes to change its charter or extend it longer than six months.

      - -

      In these processes, the roles of the charter shepherd are:

      - -
      -
      Record group decision
      -
      The group should discuss and record a formal decision to request extension or to recharter.
      -
      Follow process for creating a charter
      -
      The handling of rechartering is almost the same as for new charters. Note that, in addition to any content changes, the charter may need to be updated if the charter template has changed. Furthermore, the template tool will prompt for the inclusion of Patent Policy language and otherwise help you meet the - list of charter requirements in the Process. For existing groups, the charter assistant helps in producing the list of exclusion drafts. -
      -
      - -

      Implementation details

      - -

      The following sections are mostly intended as instructions to the Team and are included here for transparency.

      - -

      Sufficient Member support for a charter

      - -

      Generally, the Team will expect to receive reviews for Charter -proposals from at least 5% of the Membership. If the 5% threshold is -not met, the Charter may still be approved, but additional scrutiny is -warranted, and resource allocation may be limited. Additionally, the -Team will continue to consider the number of declarations of intent to -participate or implement the output of the work group.

      - -

      Given the diversity of work underway in the Consortium, including -groups that focus on horizontal reviews (e.g., accessibility, security, -and internationalization), as well as technologies that are initially -focused on by some segment of the Web's stakeholders, there are times -where exceptions to this practice may be considered. In those cases, -the Team will document reasons why the exception is made.

      - -

      Tips to speed up the process

      - -

      Parallelize where possible:

      - -
        -
      • Work with the W3C Communications Team to send advance notice to the AC as soon as you have something to point to, and update the pipeline.
      • -
      • Start the horizontal reviews of the charter as soon as the scope, deliverables, and dependencies - parts of the charter are stable enough. Ping the horizontal reviewers on a weekly basis.
      • -
      • Start working on resolving Formal Objections to a charter as soon as those are received. Don't wait - till the end of the AC review period. -
      • -
      • Prepare a draft of the W3C Decision announcement before getting the approval from TiLT.
      • -
      -
    • -
    - -

    Organizing the Call for Review

    - -

    Note: Team Contacts should ensure that their -work group participants are aware there is a review in progress.

    - -

    The Team Contact:

    -
      -
    • Reuses an existing Team-only mailing list (e.g., w3t-archive@w3.org) for the Advisory Committee review (or creates a new Team-only mailing list.) -
        -
      • If new, the mailing list should be named team-xxx-review@w3.org - (in accordance with the - list name policy). -
      • -
      • The mailing list must be Team-only.
      • -
      • The mailing list must be archived.
      • -
      • The mailing list must have at least one subscriber to monitor - traffic: the Team Contact.
      • -
      • The mailing list must accept posts from the - address sysbot+wbs@w3.org to - receive questionnaire responses. After the list is created, use - the list administration tool to add - this address to the accept2 file.
      • -
      -
    • -
    • Sends a request to the W3C Communications Team (w3t-comm@w3.org) - asking that a Call for Review be sent to the AC. The request should - be sent at least three business days before the anticipated start - date of the review. The request must include: -
        -
      1. A w3.org URI to the proposed charter (not a github.io URI). This charter is public, and must not be altered, during the AC review.
      2. -
      3. The list of significant changes to a revised charter - (per "Advisory Committee Review of a Working Group or Interest Group Charter" of the Process Document). It is useful to include a diff between the current and proposed charters (you may wish to use the HTML diff tool).
      4. -
      5. In case of renewal of an existing charter, whether the group scope has changed. I.e., are there any new deliverables with licensing obligations under the W3C Patent Policy? The current group participants would need to re-join the group once the revised charter is approved.
      6. -
      7. A recommended review start date and duration (at least 28 days according to the process document)
      8. -
      9. A URI to the review of the proposed charter in the Strategy GitHub repository.
      10. -
      11. The name of the Team-only mailing list for comments.
      12. -
      -
    • -
    - -

    The W3C Communications Team encourages the charter shepherd to include as part of -the request, a draft Call for Review, created by using this - -template (even if the URI to the questionnaire may not yet -exist).

    - -

    The W3C Communications Team (or the motivated Team Contact) builds a Call for -Review questionnaire. The URI for the questionnaire is added to -the Call for Review announcement to members. In case of renewal of an existing charter, it is also useful to include a diff (you may wish to use the HTML diff tool) between current and proposed charters in the Call for Review questionnaire. -

    - -

    Once the Head of W3C Communications (or delegate) has approved the Call for Review and the questionnaire, the W3C -Communications Team:

    - -
      -
    1. Sends the Call for Review to w3c-ac-members@w3.org.
    2. -
    3. Sends a version of the announcement to public-new-work@w3.org - (archive). - Use this template (and see the - example). The announcement must include: -
        -
      • The URI of the (public) charter.
      • -
      • The end date of the Member review.
      • -
      • That W3C invites public feedback on public-review-comments@w3.org - (archive). -
      • -
      • That we make no guarantees of replying to public comments.
      • -
      • That people who work for a Member organization should - coordinate their comments through their Advisory Committee Representative.
      • -
      -
    4. -
    5. Send the same email to new-work@ietf.org. Note: public-new-work@w3.org used to cc new-work@ietf.org but due to mailing list configuration issues, we stopped that practice.
    6. -
    - -

    Managing changes to charters after review

    - -

    If there are only very minor changes to a charter resulting from the review, the (future) decision includes the original charter URI and an explanation of the changes and their rationale.

    - -

    If substantive changes are proposed in response to charter review, the Team Contact must send the charter with proposed changes, the HTML - diff, and an explanation of the changes and their rationale to all who reviewed the charter, copying the member-charters-review@w3.org member-archived mailing list, accompanied by a request for response (with a deadline of a minimum of one week for response time) if reviewers have concerns or if the changes would alter their reviews. If the work continues or derives from an existing group or community effort, the Team Contact should also send the HTML - diff and a public rationale to that group or community. These communications should note that W3C has not yet approved the charter.

    -
    Suggested wording: Please let us know by [date+1 week] if you have concerns or if this change would alter your review.
    -

    If anyone expresses new concern in response to the re-review, the Team may attempt to resolve the concern (with re-review), formally open a new AC review, or the W3C Council may treat it as an objection and overrule it.

    - -

    If there are substantive changes, before any announcement, the Team Contact:

    - -
      -
    1. Mints a new URI for the version of the charter that includes the changes. In the "Charter history" section of the charter, please link to the original (reviewed) charter.
    2. -
    3. Modifies the original charter in place with the -following status sentence at the top: -
      -<p class="todo">This charter has been replaced - by <a>[a newer version]</a>.</p> -
      -
    4. -
    - -

    Announcement of W3C Decision, Call for Participation

    - -

    Preparation by the charter shepherd

    - -

    The charter shepherd ensures that the following are done and the following documentation is available before asking the W3C Communications Team to announce a group:

    - -
      -
    1. TiLT has approved the group, whether or not preceded by an AC Review.
    2. -
    3. The group exists in the Groups DB. -
        -
      • If the group does not exist:
        - Contact the W3C Communications Team to create the group by sending a mail to w3t-comm@w3.org. Note that this requires: -
          -
        • group name
        • -
        • group shortname
        • -
        • charter URI
        • -
        • homepage URI (only if you want to use a page different that the automatically generated group pages)
        • -
        - Creating the group will list the group in the drop-down for db-backed groups in the mailing list creation form. -
      • -
      • If the group already exists: -
          -
        • For WGs and IGs that are more than mailing lists:
          - Simply reuse the existing join form; all join pages are available from the list of groups.
        • -
        • If the group is an IG that is just a mailing list:
          - Document on the group's home page that to join the group people simply subscribe to the list.
        • -
        -
      • -
      -
    4. -
    5. All relevant mailing lists exist. If not, the Team Contact may create the mailing list(s).
    6. -
    7. The main mailing list is associated with the group via the Group Service Management interface.
    8. -
    9. Make sure the charter is public (since 2007, charters are public during AC review) and any final edits (e.g., addition of link to page for joining the group) have been made. If the group already exists, the new charter and the old charter should have two different URLs.
    10. -
    11. Customize the "onboarding" message that will be sent to participants as they join the group.
    12. -
    - -

    - All Working Groups and Interest Groups appear in their respective group list and have a - public list of participants (except for Interest Groups that are not managed under the W3C Patent Policy). -

    - -

    The W3C Communications Team should try to minimize the number of -messages sent to the Advisory Committee, while ensuring that each -message is clear. In general, the W3C Communications Team sends one email combining the group approval (W3C Decision) and the Call for Participation.

    - -

    Timing: this takes a week at most.

    - -

    Organizing the W3C Decision, Call for Participation

    - -

    The charter shepherd sends a draft announcement (combining W3C Decision and Call for Participation) to the W3C Communications Team (w3t-comm@w3.org) (using the template as a starting point, or sample announcement). The announcement must indicate:

    - -
      -
    • Whether the group is approved and its charter end date.
    • -
    • The URI of the final charter.
    • -
    • Any substantive changes from the charter that was reviewed. Note: In case of charter renewal, it is useful to include a HTML diff between the approved and previous charters.
    • -
    • A link to the group's public home page.
    • -
    • A link to a page with information about the mechanism used to join the group (e.g., a URI to the "join" page for a group under the W3C Patent Policy).
    • -
    • Name and contact information for the Team Contact(s).
    • -
    • AC review results of the proposed charter.
    • -
    • If applicable, the rationale for approving the group despite objections, - or despite the fact it did not receive reviews from - at least 5% of the Membership.
    • -
    - -

    In case a charter has new deliverables in-scope, it is useful to include a notice that a 45-day grace period is granted to existing participants of the group under the previous charter, who will then need to re-join the group.

    - -

    In case the new charter doesn't have new deliverables involving new patent commitment, it is useful to clarify that existing participants under the previous charter will not be required to leave/re-join the group.

    - -

    Note: Per the 2021-01-13 W3M resolution (team-only), the calls for participation should include guidance to consider diversity (available from the template):

    - -
    Please consider diversity when proposing people to participate in W3C groups. Representation from a wider group of people, especially people from under-represented groups, is vital for creating web standards that meet the needs of the wider web community.
    - -

    The announcement must also indicate when applicable:

    - -
      -
    • For a newly created group, information about the dates of the first face-to-face meeting.
    • -
    - -

    The Head of W3C Communications (or delegate) must approve the W3C Decision and Call for Participation draft announcement before the W3C Communications Team sends it to w3c-ac-members@w3.org. -
    - Timing: The W3C Communications Team SHOULD announce the W3C Decision within two weeks after the end of the AC review (or send an email setting new expectations). An announcement is -sent whether the proposal is approved or rejected.

    - -

    If the group is approved, it is a good -practice that the W3C Communications Team also:

    -
      -
    • forwards the Call for Participation to the work group's -primarily public mailing list (to notify the group, including Invited -Experts). The Results of the Call for Review and any member-only -information should be -elided. See example.
    • -
    • follows-up on the Advance Notice in public-new-work with a - pointer to that - announcement. See example.
    • -
    - -

    If the group is rejected, it is a good -practice that the W3C Communications Team follows-up on the Advance -Notice in public-new-work to close the loop for the public record.

    - -

    After sending the W3C Decision, Call for Participation

    - -

    After sending the W3C Decision and Call for Participation:

    - -
      -
    • Make sure that the Groups DB has the latest charter link (the W3C Communications Team searches the group and edits information to add a new charter). -
        -
      • 2021-07-12 update: associate with a charter the 'W3C document license', the 'W3C software and document license' or both. Which license to be selected is found in the section ‘Licensing’ of -the charter. (Rationale: we need to record that bit in the charter admin interface to expose it in our API, in order to check that a document produced by a WG/IG is using the right document license.)
      • -
      • 2022-07-19 update: For recharters, deactivate the previous charter when a new charter is valid: -
          -
        1. add a note to the previous charter indicating "This charter has been replaced by <a>[a newer version]</a>";
        2. -
        3. if the previous charter hasn't expired when a new charter is installed, deactivate the previous charter by changing its end date via the Groups DB interface<.
        4. -
        -
      • -
      -
    • -
    • For groups managed under the W3C Patent Policy (formerly IPP), -the W3C Communications Team uses the Groups DB interface to -record that a Call for Participation was sent (so that all links via the Groups DB, including the charter one on the join page, are actually live).
    • -
    • If the group was "staged", the W3C Communications Team unstages it.
    • -
    • The public list of groups is automatically updated from the Groups DB, including a 1-paragraph description.
    • -
    • Team Contact marks the chair(s) as such in the Group's admin view (this automatically adds the chair(s) to the -Chairs' group and updated the chairs@w3.org mailing list).
    • -
    • Function Lead or Team Contact(s) update the Team's effort tables.
    • -
    • For existing groups, Team Contact(s) ensures that Invited Expert statuses are being - reviewed in coordination with the group chair(s). Team - Contacts with questions about how an Invited Expert joins a group should consult the Team Policy for - Invited Experts.
    • -
    - -

    - Team contacts should look at how to setup a new group once the call for participation is out. -

    - -

    Note: When we recharter a work group and the charter scope has changed, we enter the CFP into the Group DB, which triggers messages to the group participants that they must rejoin. If the new charter doesn't have new deliverables involving new patent commitment, do not register the new CFP.

    - -

    Announcement of extension

    - -

    When requesting that the W3C Communications Team announce a charter exension, use the charter extension template. - -

    The W3C Communications Team then:

    -
      -
    • Sends extension announcements to w3c-ac-members@w3.org
    • -
    • ... and later forwards the announcements as FYI to chairs@w3.org
    • -
    • It is a good practice to forward the extension announcement to the public list of the group, and to follow-up on public-new-work.
    • -
    • updates the list of groups accordingly.
    • -
    - -

    The Communications Team modifies (or asks the Team Contact) the Charter in place as follows: -

      -
    • The "End Date" in the table at the top.
    • -
    • Any update to the Chair(s) (e.g., a Chair resigns or their affiliation changed), Team Contact(s) (e.g., names, FTEs), etc.
    • -
    • The changes including extension history are documented in the "About this charter" section at the bottom and lists each extension dates and the pairs of from/until dates. (Note: If the group is developing a new charter, link to the GitHub repo of where the new charter is being developed).
    • -
    • The text "Note: The group will document significant changes from this initial schedule on the group home page." is updated with a link to the group's updated milestones - (e.g., on the group's site) to say something like "Note: See changes from this initial schedule on the group home page."
    • -
    • Fix broken links.
    • -
    - -

    When a group Chair is (re)appointed or resigns, shortly before/after the announcement to w3c-ac-members@w3.org [then forwarded to chairs@w3.org] (sample emails [1][2]), The W3C Communications Team (or the Team Contact) modifies the charter, including:

    -
      -
    • Update the "Chair" in the table at the top.
    • -
    • Document changes in "About this charter" section at the bottom.
    • -
    - -

    Revision history

    -
      -
    • 2024-01: Public comments and Formal Objections (including from Members) are now to be sent to public-review-comments@w3.org; various editorial changes.
    • -
    • 2023-10: Updated following Process 2023 and reorganized to separate high-level processes from implementation.
    • -
    • 2012-08: Added section 3.4 Horizontal Review -following discussion at May 2012 AC meeting on better integration of horizontal -working groups and discussion within the Team and Advisory Board.
    • -
    • 2015-05: Added pointer to Policy on W3C Group Charter End Dates in "Charter Extension" section.
    • -
    • 2015-09: Updates to Process Document section numbers and titles. Removed "Activities" and "Coordination Groups" which are no longer referenced in the 2015 Process Document.
    • -
    • 2016-02: Updated mostly to reflect that the Groups DB interfaces with IPP and that systeam creates new WGs/IGs; pointed to most recent sample announcement for Director's Decision and Call for Participation; updated workflows to match current practice; further removed or clarified that "Activities" are no longer in Process..
    • -
    • 2018-01: Took latest process into account
    • -
    - -
    - -

    Feedback is to @w3c/guidebook and - is welcome on GitHub

    - - + proposals from at least 5% of the [Membership](/membership/list/). If + the 5% threshold is not met, the Charter may still be approved, but + additional scrutiny is warranted, and resource allocation may be + limited. Additionally, the Team will continue to consider the number + of declarations of intent to participate or implement the output of + the work group. + {.#review_threshold} + +Given the diversity of work underway in the Consortium, including [groups that focus on horizontal reviews](horizontal-groups.html) (e.g., accessibility, security, and internationalization), as well as technologies that are initially focused on by some segment of the Web's stakeholders, there are times where exceptions to this practice may be considered. In those cases, the Team will document reasons why the exception is made. + +### 3.2. Tips to speed up the process {#speed-tips} + +Parallelize where possible: + +- Work with the W3C Communications Team to send [advance notice to the AC](adv-notice.html) as soon as you have something to point to, and update the [pipeline](#pipeline). +- Start the horizontal reviews of the charter as soon as the scope, deliverables, and dependencies parts of the charter are stable enough. Ping the horizontal reviewers on a weekly basis. +- Start working on resolving Formal Objections to a charter as soon as those are received. Don't wait till the end of the AC review period. +- Prepare a draft of the W3C Decision announcement before getting the approval from TiLT. + +### 3.3. Organizing the Call for Review {#organize-cfr} + +**Note:** Team Contacts should ensure that their work group participants are aware there is a review in progress. + +The Team Contact: + +- Reuses an existing Team-only mailing list (e.g., [w3t-archive@w3.org](https://lists.w3.org/Archives/Team/w3t-archive/)) for the Advisory Committee review (or [creates a new Team-only mailing list](/Systems/Mail/Request/).) + + - If new, the mailing list should be named team-xxx-review@w3.org (in accordance with the [list name policy](https://www.w3.org/Systems/Mail/Request/#doc-listname)). + - The mailing list must be Team-only. + - The mailing list must be archived. + - The mailing list must have at least one subscriber to monitor traffic: the Team Contact. + - The mailing list must accept posts from the address [sysbot+wbs@w3.org](mailto:sysbot+wbs@w3.org) to receive questionnaire responses. After the list is created, use the [list administration tool](https://lists.w3.org/admin/manage) to add this address to the accept2 file. +- Sends a request to the W3C Communications Team ([w3t-comm@w3.org](mailto:w3t-comm@w3.org)) asking that a Call for Review be sent to the AC. The request should be sent **at least three business days before** the anticipated start date of the review. The request must include: + + 1. A w3.org URI to the proposed charter (not a github.io URI). This charter is public, and must not be altered, during the AC review. + 2. The list of significant changes to a revised charter (per ["Advisory Committee Review of a Working Group or Interest Group Charter"](/policies/process/#CharterReview) of the Process Document). It is useful to include a diff between the current and proposed charters (you may wish to use the [HTML diff tool](https://services.w3.org/htmldiff)). + 3. In case of renewal of an existing charter, whether the group scope has changed. I.e., are there any new deliverables with licensing obligations under the W3C Patent Policy? The current group participants would need to re-join the group once the revised charter is approved. + 4. A recommended review start date and duration (at least 28 days according to [the process document](/policies/process/#CharterReview)) + 5. A URI to the review of the proposed charter in the [Strategy GitHub repository](https://github.com/w3c/strategy/issues). + 6. The name of the Team-only mailing list for comments. + +The W3C Communications Team encourages the charter shepherd to include as part of the request, a draft Call for Review, created by using this [template](https://www.w3.org/new-doc-from-template?location=%2FTeam%2FTemplates&template=%2Fafs%2Fw3.org%2Fpub%2FWWW%2FTeam%2FTemplates%2Fcfr.html&submit=Continue...) (even if the URI to the questionnaire may not yet exist). + +The W3C Communications Team (or the motivated Team Contact) builds a [Call for Review questionnaire](https://www.w3.org/2002/09/wbs/33280/apCFRFactory). The URI for the questionnaire is added to the Call for Review announcement to members. In case of renewal of an existing charter, it is also useful to include a diff (you may wish to use the [HTML diff tool](https://services.w3.org/htmldiff)) between current and proposed charters in the Call for Review questionnaire. + +Once the Head of W3C Communications (or delegate) has approved the Call for Review and the questionnaire, the W3C Communications Team: + +1. Sends the Call for Review to w3c-ac-members@w3.org. +2. Sends a version of the announcement to public-new-work@w3.org ([archive](https://lists.w3.org/Archives/Public/public-new-work/)). Use this [template](https://www.w3.org/new-doc-from-template?location=%2FTeam%2FTemplates&template=%2Fafs%2Fw3.org%2Fpub%2FWWW%2FTeam%2FTemplates%2Fpublic-charter.html&submit=Continue...) (and see the [example](https://lists.w3.org/Archives/Public/public-new-work/2007Jan/0001.html)). The announcement must include: + + - The URI of the (public) charter. + - The end date of the Member review. + - That W3C invites public feedback on public-review-comments@w3.org ([archive](https://lists.w3.org/Archives/Public/public-review-comments/)). + - That we make no guarantees of replying to public comments. + - That people who work for a Member organization should coordinate their comments through their Advisory Committee Representative. +3. Send the same email to [new-work@ietf.org](https://www.ietf.org/mailman/listinfo/new-work). **Note:** public-new-work@w3.org used to cc new-work@ietf.org but due to mailing list configuration issues, we stopped that practice. + +### 3.4. Managing changes to charters after review {#manage-changes} + +If there are only very minor changes to a charter resulting from the review, the (future) decision includes the original charter URI and an explanation of the changes and their rationale. + +If substantive changes are proposed in response to charter review, the Team Contact must send the charter with proposed changes, the [HTML diff](https://services.w3.org/htmldiff), and an explanation of the changes and their rationale to all who reviewed the charter, copying the [member-charters-review@w3.org](https://lists.w3.org/Archives/Member/member-charters-review/) member-archived mailing list, accompanied by a request for response (with a deadline of a minimum of one week for response time) if reviewers have concerns or if the changes would alter their reviews. If the work continues or derives from an existing group or community effort, the Team Contact should also send the [HTML diff](https://services.w3.org/htmldiff) and a public rationale to that group or community. These communications should note that W3C has not yet approved the charter. + +{% include quote.html content=" Suggested wording: Please let us know by \[date+1 week] if you have concerns or if this change would alter +your review." %} + +If anyone expresses new concern in response to the re-review, the Team may attempt to resolve the concern (with re-review), formally open a new AC review, or the [W3C Council](https://www.w3.org/Guide/council/council.html) may treat it as an objection and overrule it. + +If there are substantive changes, before any announcement, the Team Contact: + +1. Mints a new URI for the version of the charter that includes the changes. In the "Charter history" section of the charter, please link to the original (reviewed) charter. +2. Modifies the original charter in place with the following status sentence at the top: + {% include quote.html content=" <p class='todo'>This charter has been replaced by <a>\[a newer version]</a>.</p>" %} + +### 3.5. Announcement of W3C Decision, Call for Participation {#announce-decision} + +#### 3.5.1. Preparation by the charter shepherd + +The charter shepherd ensures that the following are done and the following documentation is available **before** asking the W3C Communications Team to announce a group: + +1. TiLT has approved the group, whether or not preceded by an AC Review. +2. The group exists in the [Groups DB](/admin/dashboard). + + - If the group does not exist: + + Contact the W3C Communications Team to [create the group](/admin/dashboard) by sending a mail to [w3t-comm@w3.org](mailto:w3t-comm@w3.org). Note that this requires: + + - group name + - group shortname + - charter URI + - homepage URI *(only if you want to use a page different that the automatically generated [group pages](/groups/))* + + Creating the group will list the group in the drop-down for db-backed groups in the mailing list creation form. + - If the group already exists: + + - For WGs and IGs that are more than mailing lists: + + Simply reuse the existing join form; all join pages are available from the [list of groups](/groups/). + - If the group is an IG that is just a mailing list: + + Document on the group's home page that to join the group people simply subscribe to the list. +3. All relevant mailing lists exist. If not, the Team Contact may [create the mailing list(s)](/Systems/Mail/Request/). +4. The main mailing list is associated with the group via the [Group Service Management](/2011/04/dbwg/group-services) interface. +5. Make sure the charter is public (since 2007, charters are public during AC review) and any final edits (e.g., addition of link to page for joining the group) have been made. If the group already exists, the new charter and the old charter should have two different URLs. +6. Customize the ["onboarding" message](https://github.com/w3c/onboarding) that will be sent to participants as they join the group. + +All Working Groups and Interest Groups appear in their respective [group list](/groups/) and have a public list of participants (except for Interest Groups that are not managed under the W3C Patent Policy). + +The W3C Communications Team should try to minimize the number of messages sent to the Advisory Committee, while ensuring that each message is clear. In general, the W3C Communications Team sends one email combining the group approval (W3C Decision) and the Call for Participation. + +*Timing:* this takes a week at most. + +#### 3.5.2. Organizing the W3C Decision, Call for Participation + +The charter shepherd sends a draft announcement (combining W3C Decision and Call for Participation) to the W3C Communications Team ([w3t-comm@w3.org](mailto:w3t-comm@w3.org)) (using the [template](https://www.w3.org/new-doc-from-template?location=%2FTeam%2FTemplates&template=%2Fafs%2Fw3.org%2Fpub%2FWWW%2FTeam%2FTemplates%2Fcfp.html&submit=Continue...) as a starting point, or [sample announcement](https://www.w3.org/Search/Mail/Member/search?keywords=&hdr-1-name=subject&hdr-1-query=call%20for%20participation&index-grp=Member__FULL%20Public__FULL&index-type=t&type-index=w3c-ac-members)). The announcement must indicate: + +- Whether the group is approved and its charter end date. +- The URI of the final charter. +- Any substantive changes from the charter that was reviewed. Note: In case of charter renewal, it is useful to include a [HTML diff](https://services.w3.org/htmldiff) between the approved and previous charters. +- A link to the group's public home page. +- A link to a page with information about the mechanism used to join the group (e.g., a URI to the "join" page for a group under the W3C Patent Policy). +- Name and contact information for the Team Contact(s). +- AC review results of the proposed charter. +- If applicable, the rationale for approving the group despite objections, or despite the fact it did not receive reviews [from at least 5% of the Membership](#review_threshold). + +In case a charter has new deliverables in-scope, it is useful to include a notice that a 45-day grace period is granted to existing participants of the group under the previous charter, who will then need to re-join the group. + +In case the new charter doesn't have new deliverables involving new patent commitment, it is useful to clarify that existing participants under the previous charter will not be required to leave/re-join the group. + +Note: Per the [2021-01-13 W3M resolution](https://www.w3.org/2021/01/13-w3m-minutes#t08) (team-only), the calls for participation should include guidance to consider diversity (available from the [template](https://www.w3.org/new-doc-from-template?location=%2FTeam%2FTemplates&template=%2Fafs%2Fw3.org%2Fpub%2FWWW%2FTeam%2FTemplates%2Fcfp.html&submit=Continue...)): + + {% include quote.html content="Please consider diversity when proposing people to participate in W3C groups. Representation from a wider group of people, especially people from under-represented groups, is vital for creating web standards that meet the needs of the wider web community." %} + +The announcement must also indicate when applicable: + +- For a newly created group, information about the dates of the first face-to-face meeting. + +The Head of W3C Communications (or delegate) must approve the W3C Decision and Call for Participation draft announcement before the W3C Communications Team sends it to [w3c-ac-members@w3.org](mailto:w3c-ac-members@w3.org). +*Timing:* The W3C Communications Team SHOULD announce the W3C Decision within two weeks after the end of the AC review (or send an email setting new expectations). An announcement is sent whether the proposal is approved *or* rejected. + +**If the group is *approved***, it is a good practice that the W3C Communications Team also: + +- forwards the Call for Participation to the work group's primarily public mailing list (to notify the group, including Invited Experts). The Results of the Call for Review and any member-only information should be elided. See [example](https://lists.w3.org/Archives/Public/public-webassembly/2017Aug/0001.html). +- follows-up on the Advance Notice in public-new-work with a pointer to that announcement. See [example](https://lists.w3.org/Archives/Public/public-new-work/2017Aug/0001.html). + +**If the group is *rejected***, it is a good practice that the W3C Communications Team follows-up on the Advance Notice in public-new-work to close the loop for the public record. + +#### 3.5.3. After sending the W3C Decision, Call for Participation + +After sending the W3C Decision and Call for Participation: + +- Make sure that the Groups DB has the latest charter link (the W3C Communications Team [searches](/admin/dashboard) the group and edits information to add a new charter). + + - [2021-07-12 update](https://lists.w3.org/Archives/Team/w3t-comm/2021Jul/0084.html): associate with a charter the 'W3C document license', the 'W3C software and document license' or both. Which license to be selected is found in the section ‘Licensing’ of the charter. (Rationale: we need to record that bit in the charter admin interface to expose it in our API, in order to check that a document produced by a WG/IG is using the right document license.) + - 2022-07-19 update: For recharters, deactivate the previous charter when a new charter is valid: + + 1. add a note to the previous charter indicating "This charter has been replaced by <a>\[a newer version]</a>"; + 2. if the previous charter hasn't expired when a new charter is installed, deactivate the previous charter by changing its end date via the [Groups DB](/admin/dashboard) interface<. +- For groups managed under the W3C Patent Policy (formerly IPP), the W3C Communications Team uses the [Groups DB](/admin/dashboard) interface to record that a Call for Participation was sent (so that all links via the Groups DB, including the charter one on the join page, are actually live). +- If the group was "staged", the W3C Communications Team unstages it. +- The public [list of groups](/groups/) is automatically updated from the Groups DB, including a 1-paragraph description. +- Team Contact marks the chair(s) as such in the Group's admin view (this automatically adds the chair(s) to the [Chairs' group](/admin/othergroups/31972/show) and updated the chairs@w3.org mailing list). +- Function Lead or Team Contact(s) update the Team's [effort tables](/2005/09/manage/). +- For existing groups, Team Contact(s) ensures that Invited Expert statuses are being [reviewed in coordination with the group chair(s)](/invited-experts/#review). Team Contacts with questions about how an Invited Expert joins a group should consult the [Team Policy for Invited Experts](https://www.w3.org/2004/02/invited_expert). + +Team contacts should look at [how to setup a new group](../tools/new-group.html) once the call for participation is out. + +**Note:** When we recharter a work group and the charter scope has changed, we enter the CFP into the Group DB, which triggers messages to the group participants that they must rejoin. If the new charter doesn't have new deliverables involving new patent commitment, do not register the new CFP. + +### 3.6. Announcement of extension {#announce-extension} + +When requesting that the W3C Communications Team announce a charter exension, use the [charter extension template](https://www.w3.org/new-doc-from-template?location=%2FTeam%2Ftemplates&template=%2Fafs%2Fw3.org%2Fpub%2FWWW%2FTeam%2FTemplates%2Fcharter-extension.html&submit=Continue...). + +The W3C Communications Team then: + +- Sends extension announcements to w3c-ac-members@w3.org +- ... and later forwards the announcements as FYI to chairs@w3.org +- It is a good practice to forward the extension announcement to the public list of the group, and to follow-up on public-new-work. +- updates the [list of groups](/groups/) accordingly. + +The Communications Team modifies (or asks the Team Contact) the Charter in place as follows: + +- The "End Date" in the table at the top. +- Any update to the Chair(s) (e.g., a Chair resigns or their affiliation changed), Team Contact(s) (e.g., names, FTEs), etc. +- The changes including extension history are documented in the "About this charter" section at the bottom and lists each extension dates and the pairs of from/until dates. (Note: If the group is developing a new charter, link to the GitHub repo of where the new charter is being developed). +- The text "Note: The group will document significant changes from this initial schedule on the group home page." is updated with a link to the group's updated milestones (e.g., on the group's site) to say something like "Note: See changes from this initial schedule on the group home page." +- Fix broken links. + +When a group **Chair** is (re)appointed or resigns, shortly before/after the announcement to w3c-ac-members@w3.org \[then forwarded to chairs@w3.org] (sample emails \[[1](https://www.w3.org/Search/Mail/Member/search?keywords=&hdr-1-name=subject&hdr-1-query=appointed&index-grp=Member__FULL%20Public__FULL&index-type=t&type-index=w3c-ac-members)]\[[2](https://www.w3.org/Search/Mail/Member/search?keywords=&hdr-1-name=subject&hdr-1-query=steps%20down&index-grp=Member__FULL%20Public__FULL&index-type=t&type-index=w3c-ac-members)]), The W3C Communications Team (or the Team Contact) modifies the charter, including: + +- Update the "Chair" in the table at the top. +- Document changes in "About this charter" section at the bottom. + +## 4. Revision history {#revision-history} + +- **2024-01**: Public comments and Formal Objections (including from Members) are now to be sent to public-review-comments@w3.org; various editorial changes. +- **2023-10**: Updated following Process 2023 and reorganized to separate high-level processes from implementation. +- **2012-08**: Added section 3.4 Horizontal Review following [discussion at May 2012 AC meeting on better integration of horizontal working groups](https://www.w3.org/2012/05/15-ac-minutes#item14) and discussion within the Team and Advisory Board. +- **2015-05**: Added pointer to Policy on W3C Group Charter End Dates in "Charter Extension" section. +- **2015-09**: Updates to Process Document section numbers and titles. Removed "Activities" and "Coordination Groups" which are no longer referenced in the [2015 Process Document](https://www.w3.org/2015/Process-20150901/). +- **2016-02**: Updated mostly to reflect that the Groups DB interfaces with IPP and that systeam creates new WGs/IGs; pointed to most recent sample announcement for Director's Decision and Call for Participation; updated workflows to match current practice; further removed or clarified that "Activities" are no longer in Process.. +- **2018-01**: Took latest process into account From 65073656a869495ba57249bc474a4497ee1fe105 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 17:03:57 +0100 Subject: [PATCH 090/225] Rename from .html to .md --- process/tilt/{post-ac-review.html => post-ac-review.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/tilt/{post-ac-review.html => post-ac-review.md} (100%) diff --git a/process/tilt/post-ac-review.html b/process/tilt/post-ac-review.md similarity index 100% rename from process/tilt/post-ac-review.html rename to process/tilt/post-ac-review.md From b0bd2e4b805a1a8963cb4116426b56c4b4986a0f Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 17:13:25 +0100 Subject: [PATCH 091/225] Convert to markdown --- process/tilt/post-ac-review.md | 185 +++++++++------------------------ 1 file changed, 51 insertions(+), 134 deletions(-) diff --git a/process/tilt/post-ac-review.md b/process/tilt/post-ac-review.md index 2e4c19fcb..03fbc54ef 100644 --- a/process/tilt/post-ac-review.md +++ b/process/tilt/post-ac-review.md @@ -1,134 +1,51 @@ - - - - -TilT Evaluation of the AC Review Results - - - - - - - - - - - -

    TilT Evaluation of the - AC Review Results

    - -

    How TiLT manages AC review results depends on the results -themselves. The first three cases below require TilT discussion; the -fourth only requires notification to TiLT.

    - -

    Case 1: There are Unresolved Formal Objections

    - -

    The charter shepherd reports the review - results to TiLT for discussion and requests the start - of a Council.

    - -

    Case 2: There are Changes

    - -

    If there are no unresolved Formal Objections but there are changes -to the charter —either requested by reviewers or resulting from -resolution of Formal Objections:

    - -
      -
    • The charter shepherd changes the charter and notifies all - of the AC Reps who replied to the call for review. These AC Reps have - 7-10 days to express dissent.
    • -
    • In parallel or subsequently, the charter shepherd also - reports the review results to TiLT. That message - should highlight the same (7-10 day) window for TiLT to request discussion - of the changes.
    • -
    - -

    If the time period elapses without dissent by AC Reps and TiLT gave its - approval, - the charter shepherd proceeds directly to -requesting - announcement of the charter. Otherwise, TiLT discussion takes -place. Upon subsequent approval, the charter shepherd -requests announcement.

    - -

    Case 3: Uncontroversial Review but TiLT Approval Required

    - -

    If there are no Formal Objections and no changes, then there are - still two scenarios when TiLT approval is required:

    - -
      -
    • In the TiLT decision to request AC review, there was - a requirement to discuss the AC review results whatever the outcome - (e.g., to assign FTE based on the level Member support).
    • -
    • The review did not reach the 5% threshold and TiLT did not - relax that requirement in the decision to seek AC review.
    • -
    - -

    In either case, the charter shepherd reports - the review results. That message should highlight that the review was - uncontroversial and point out which topics now require TiLT - approval. Upon subsequent approval, the charter shepherd -requests announcement of the charter.

    - -

    Case 4: Uncontroversial Review and No TiLT Approval Required

    - -

    The charter shepherd reports the review - results to TiLT and indicates that the charter is deemed approved and - no further TiLT approval is required.

    - -

    The charter shepherd then - requests announcement of the charter.

    - -

    Reporting AC Review Results to TiLT

    - -

    In all of the above cases, the charter shepherd reports the review -outcomes to TiLT with the -following information:

    - -
      -
    • The distribution of reviews. It helps to highlight either that there have been - Formal Objections or that there is Consensus.
    • - -
    • A record of any substantial review comments and replies to those comments. In particular, for any Formal Objection, whether: -
        -
      • No attempt has been made to resolve it.
      • -
      • An attempt has been made to resolve it but it has remained unresolved - (e.g., because the reviewer did not respond, or no agreement can be reached).
      • -
      • It has been resolved. In this case indicate the resolution and whether - that involved changes to the charter.
      • -
      • It has been overridden by a Council (e.g, deemed out of scope or - overruled for any other reason).
      • -
      -
    • - -
    • A list of proposed changes to the charter (such as a link to one or more pull requests), - and whether those changes were requested during the review or as a result of resolving - a Formal Objection.
    • - -
    • Pertinent IPR statements, if any
    • -
    - -
    -

    Feedback is to @w3c/tilt and - is welcome on GitHub

    - - +--- +title: TilT Evaluation of the AC Review Results +toc: no +--- + +How [TiLT](/Guide/process/tilt/) manages AC review results depends on +the results themselves. The first three cases below require TilT +discussion; the fourth only requires notification to TiLT. +{:#TiLT-report} + +## Case 1: There are Unresolved Formal Objections + +The charter shepherd [reports](#TiLT-report) the review results to TiLT for discussion and [requests the start of a Council](https://github.com/w3c/tilt-private/issues/new/choose). + +## Case 2: There are Changes + +If there are no unresolved Formal Objections but there are changes to the charter —either requested by reviewers or resulting from resolution of Formal Objections: + +- The charter shepherd changes the charter and notifies all of the AC Reps who replied to the call for review. These AC Reps have 7-10 days to express dissent. +- In parallel or subsequently, the charter shepherd also [reports](#TiLT-report) the review results to TiLT. That message should highlight the same (7-10 day) window for TiLT to request discussion of the changes. + +If the time period elapses without dissent by AC Reps and TiLT gave its [approval](./#timing), the charter shepherd proceeds directly to [requesting announcement of the charter](../charter.html#director-decision). Otherwise, TiLT discussion takes place. Upon subsequent approval, the charter shepherd [requests announcement](../charter.html#director-decision). + +## Case 3: Uncontroversial Review but TiLT Approval Required + +If there are no Formal Objections and no changes, then there are still two scenarios when TiLT approval is required: + +- In the TiLT decision to request AC review, there was a requirement to discuss the AC review results whatever the outcome (e.g., to assign FTE based on the level Member support). +- The review did not reach the 5% threshold and TiLT did not relax that requirement in the decision to seek AC review. + +In either case, the charter shepherd [reports](#TiLT-report) the review results. That message should highlight that the review was uncontroversial and point out which topics now require TiLT approval. Upon subsequent approval, the charter shepherd [requests announcement of the charter](../charter.html#director-decision). + +## Case 4: Uncontroversial Review and No TiLT Approval Required + +The charter shepherd [reports](#TiLT-report) the review results to TiLT and indicates that the charter is deemed approved and no further TiLT approval is required. + +The charter shepherd then [requests announcement of the charter](../charter.html#director-decision). + +## Reporting AC Review Results to TiLT {#TiLT-report} + +In all of the above cases, the charter shepherd reports the review outcomes to [TiLT](https://github.com/w3c/tilt-private/issues/new/choose) with the following information: + +- The distribution of reviews. It helps to highlight either that there have been Formal Objections or that there is Consensus. +- A record of any substantial review comments and replies to those comments. In particular, for any Formal Objection, whether: + + - No attempt has been made to resolve it. + - An attempt has been made to resolve it but it has remained unresolved (e.g., because the reviewer did not respond, or no agreement can be reached). + - It has been resolved. In this case indicate the resolution and whether that involved changes to the charter. + - It has been overridden by a Council (e.g, deemed out of scope or overruled for any other reason). +- A list of proposed changes to the charter (such as a link to one or more pull requests), and whether those changes were requested during the review or as a result of resolving a Formal Objection. +- Pertinent IPR statements, if any \ No newline at end of file From 1a09867efb1a199f6f56651415705274f3df4038 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 17:17:27 +0100 Subject: [PATCH 092/225] Rename from .html to .md --- process/tilt/{index.html => index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/tilt/{index.html => index.md} (100%) diff --git a/process/tilt/index.html b/process/tilt/index.md similarity index 100% rename from process/tilt/index.html rename to process/tilt/index.md From 7ad0ce3ed9aee93f883ea68a640f43976fc69b23 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 16 Dec 2024 17:39:46 +0100 Subject: [PATCH 093/225] Convert to markdown --- process/tilt/index.md | 250 ++++++++++++++---------------------------- 1 file changed, 84 insertions(+), 166 deletions(-) diff --git a/process/tilt/index.md b/process/tilt/index.md index e62eaaef9..7ae73ba0f 100644 --- a/process/tilt/index.md +++ b/process/tilt/index.md @@ -1,205 +1,123 @@ - - - - -Technical issues Lead Team - - - - - - - - -
    -

    Also On This Page →

    - -
    - - -

    The mission of the TiLT is to make technical team decisions described in the W3C Process.

    - -

    TiLT authority comes from delegation -by the CEO.

    - -

    Scope

    - -

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

    - -
      -
    1. Group charters approvals, before and after AC review
    2. -
    3. Chairs appointments
    4. -
    5. Group extensions
    6. -
    7. Member submissions
    8. -
    9. Workshops(1)
    10. -
    11. Patent Advisory Groups (PAGs)
    12. -
    13. Start of Councils
    14. -
    15. Transition requests(2)
    16. -
    17. Anything related to the operational management of developing W3C specs
    18. -
    - -

    (1) Those requests still need W3C Management approval in - parallel.

    - -

    (2) TiLT delegates its authority for transition requests

    - -

    Out of Scope

    - -
      -
    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. -
    3. 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).
    4. -
    5. 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.
    6. -
    - -

    Composition

    - -

    Composition goals:

    -
      -
    • Manageable size
    • -
    • Decision-making continuity
    • -
    • Viewpoint freshness
    • -
    • Staff development
    • +--- +title: Technical issues Lead Team +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). -

    The TiLT is staffed as follows:

    +## Scope {#scope} -
      -
    • 2 seats are 2-year terms, with staggered renewals every year, - acting as co-chairs (“co-chair seat”). May need to change at - different times.
    • -
    • 3 seats are 1-year terms, with staggered renewals every 8 - months (“regular seat”)
    • -
    +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 -

    Eligibility:

    -
      -
    • By default, all Team Contacts are eligible for either co-chair or regular seats. Individuals from this group are expected to participate but may opt-out. -Other W3C Team may opt-in.
    • -
    • To fill an open seat, assemble the randomized list of individuals interested in the position, with the outgoing TiLT member at the bottom of the list, go down the list until you fill the seat.
    • -
    +(1) Those requests still need W3C Management approval in parallel. +{:#note1} +(2) TiLT delegates its authority for transition requests +{:#note2} -

    Current members

    +### 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. -

    This composition is reflected in the Github team @w3c/tilt.

    +## Composition {#composition} -

    Meetings

    +Composition goals: -

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

    +- Manageable size +- Decision-making continuity +- Viewpoint freshness +- Staff development -

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

    +The TiLT is staffed as follows: -

    Requesting approval from TiLT

    +- 2 seats are 2-year terms, with staggered renewals every year, acting as co-chairs (“co-chair seat”). May need to change at different times. +- 3 seats are 1-year terms, with staggered renewals every 8 months (“regular seat”) -

    For transition requests, TiLT delegates its authority to - @w3c/transitions. - Follow Organize a Technical Report Transition. +Eligibility: -

    Other requests for approvals MUST be sent as an open issue 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. +- By default, all Team Contacts are eligible for either co-chair or regular seats. Individuals from this group are expected to participate but may opt-out. Other W3C Team may opt-in. +- To fill an open seat, assemble the [randomized list of individuals](https://www.w3.org/2023/08/noncom-random-selection.html) interested in the position, with the outgoing TiLT member at the bottom of the list, go down the list until you fill the seat. -

    For sensitive announcement, a draft of the message going to the AC may -be needed. If so, use the "Anything else we should think before ..." -to include or link to those information.

    +### Current members {#current} -

    For requests also requiring W3M approval (such as workshop budget), the label - “w3m” label is also added. +- [Atsushi Shimono](https://www.w3.org/staff/#himorin) (September 1, 2023) +- [Chris Lilley](https://www.w3.org/staff/#chris) (May 24, 2023) +- [Carine Bournez](https://www.w3.org/staff/#carine) (December 4, 2024) (co-chair) +- [Dominique Hazaël-Massieux](https://www.w3.org/staff/#dom) (December 4, 2024) +- [Philippe Le Hegaret](https://www.w3.org/staff/#plehegar) (May 24, 2023) (co-chair) -

    The list -of pending requests is available. +This composition is reflected in the Github team [@w3c/tilt](https://github.com/orgs/w3c/teams/tilt). -

    How TiLT responds to requests

    +## Meetings {#meetings} -

    Expressions of support

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

    TiLT will only approve requests where there are: -

      -
    • At least three expressions of support, and
    • -
    • No objections from TiLT participants. Participants may abstain.
    • -
    +The entire W3C team has an open invitation to observe the discussion, including attending calls. (contact plh for that) -

    TiLT participants use +1, -1, and 0 respectively to mean support, do not support, abstain. TiLT participants register their responses as a comment in the tilt-private Github issue (last comment takes precedence). +## Requesting approval from TiLT {#request} -

    Note: Comments about charter, workshop proposals, etc. (e.g., a link is broken) should be made directly in the relevant repository (e.g., strategy) unless the comment is Team-only, in which case the TiLT repo is appropriate. +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). -

    Timing of responses

    +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. -

    TiLT responses can be expected on this schedule: -

    Within 2 business days: approval is only possible if every TiLT - participant has responded. During this period, TiLT participants - may request additional time to evaluate the request. -

    After 2 business days: approval is possible as soon as there are at - least three expressions of support and no objections or requests for - additional time. +For sensitive announcement, a draft of the message going to the AC may be needed. If so, use the "Anything else we should think before ..." to include or link to those information. -

    In cases where there are objections or requests for additional time, - TiLT will use its weekly call to resolve differences. +For requests also requiring W3M approval (such as workshop budget), the label [“w3m”](https://github.com/w3c/tilt-private/labels/w3m) label is also added. -

    Once TiLT has reached a decision

    +The [list of pending](https://github.com/w3c/tilt-private/labels/agenda) requests is available. -

    Once the threshold for a decision has been reached, any TiLT participant may record the decision and close the GitHub issue. If approved, the issue will be “Close as completed”. If rejected, the issue will be “Closed as not planned”. +## How TiLT responds to requests {#responses} -

    If a request is approved, the requestor should consult the Guidebook on Charters for next steps. +### Expressions of support {#support} -

    If a request is rejected, it gets sent back to the originating function. +TiLT will only approve requests where there are: -

    Communication

    +- At least three expressions of support, and +- No objections from TiLT participants. Participants may abstain. +TiLT participants use +1, -1, and 0 respectively to mean support, do not support, abstain. TiLT participants register their responses as a comment in the tilt-private Github issue (last comment takes precedence). +**Note:** Comments about charter, workshop proposals, etc. (e.g., a link is broken) should be made directly in the relevant repository (e.g., strategy) unless the comment is Team-only, in which case the TiLT repo is appropriate. -

    As part of the W3C Team, the recommended way to communicate with TiLT is through the -tilt-private Github repository (by raising an issue or responding to one), or use @w3c/tilt.

    +### Timing of responses {#timing} -

    If you're not part of the W3C Team, the recommended way to communicate with -TiLT is @w3c/tilt.

    +TiLT responses can be expected on this schedule: -

    For any request sent to TiLT, Team input is welcome in the Strategy repository. -Keep in mind the Team etiquette when posting publicly. For Team confidential discussion, -input is welcome in the tilt-private Github repository. Note that any +1/-1/other from -non-TiLT is NOT counted to reach TiLT approval but any TiLT member may put a -hold on a decision based on non-TiLT opinions.

    +Within 2 business days: approval is only possible if every TiLT participant has responded. During this period, TiLT participants may request additional time to evaluate the request. -

    TiLT MUST provide a weekly digest of its activities to W3M. +After 2 business days: approval is possible as soon as there are at least three expressions of support and no objections or requests for additional time. -

    - TiLT was approved by W3M on May 24, 2023. -

    +In cases where there are objections or requests for additional time, TiLT will use its weekly call to resolve differences. -
    -

    Feedback is to @w3c/tilt - is welcome on GitHub

    - - +### Once TiLT has reached a decision {#decision} + +Once the threshold for a decision has been reached, any TiLT participant may record the decision and close the GitHub issue. If approved, the issue will be “Close as completed”. If rejected, the issue will be “Closed as not planned”. + +If a request is approved, the requestor should consult the Guidebook on Charters for next steps. + +If a request is rejected, it gets sent back to the originating function. + +## Communication {#communication} + +As part of the W3C Team, the recommended way to communicate with TiLT is through the tilt-private Github repository (by raising an issue or responding to one), or use [@w3c/tilt](https://github.com/orgs/w3c/teams/tilt). + +If you're not part of the W3C Team, the recommended way to communicate with TiLT is [@w3c/tilt](https://github.com/orgs/w3c/teams/tilt). + +For any request sent to TiLT, Team input is welcome in the Strategy repository. Keep in mind the Team etiquette when posting publicly. For Team confidential discussion, input is welcome in the tilt-private Github repository. Note that any +1/-1/other from non-TiLT is NOT counted to reach TiLT approval but any TiLT member may put a hold on a decision based on non-TiLT opinions. + +TiLT MUST provide a weekly digest of its activities to W3M. + +TiLT was approved by W3M on [May 24, 2023](https://www.w3.org/2023/05/24-w3m-minutes.html#t04). From 218004ac6c66c2b88c6bece9233aa16bf99a0ac8 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 16:25:54 +0100 Subject: [PATCH 094/225] adapt existing markdown file to jekyll template --- meetings/hybrid-meeting.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/meetings/hybrid-meeting.md b/meetings/hybrid-meeting.md index 910fec76b..b634c17ab 100644 --- a/meetings/hybrid-meeting.md +++ b/meetings/hybrid-meeting.md @@ -1,4 +1,7 @@ -# Hybrid Group Meetings +--- +title: Hybrid Group Meetings +toc: yes +--- ## Introduction @@ -168,7 +171,7 @@ Sharing of accessible content via the web should be strongly preferred over scre Consider unfortunate contingencies like the tech doesn't work as expected or the physical meeting room(s) getting disconnected from the net or having a fire alarm -- and all of these things and more have indeed happened, so think carefully about contingency planning. Will (should?) those in the room continue to meet while they're disconnected from the net? Will the (other) remote participants continue to meet while those in the meeting room are milling about in a parking lot waiting for the fire department? Will remote participants already have fall-back channel info? How will the partitioned meeting know that it has been partitioned? -> [JB: ;) -- discuss emergency logistics more generally, and the fact that most of them will eventually happen.] +{% include quote.html content="discuss emergency logistics more generally, and the fact that most of them will eventually happen." footer="JB: ;)" %} Essential to have a fall-back video conference option that can be activitied. @@ -228,6 +231,3 @@ https://www.microsoft.com/en-us/research/project/the-new-future-of-work/articles W3C (various), [Remote Meetings](https://www.w3.org/wiki/Remote_Meetings), W3C public wiki, 2013-2014
    https://www.w3.org/wiki/Remote_Meetings - ----- -[maintained on GitHub](https://github.com/w3c/Guide); comment there in [issues](https://github.com/w3c/Guide/issues). \ No newline at end of file From 747377fa3dc37221a213b57d1e90d8997bee09b3 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 17:02:16 +0100 Subject: [PATCH 095/225] add missing ids for headers --- meetings/zoom.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/meetings/zoom.md b/meetings/zoom.md index a97d4e157..fafac0b5f 100644 --- a/meetings/zoom.md +++ b/meetings/zoom.md @@ -5,7 +5,7 @@ toc: true W3C has a Zoom account and W3C Groups may use those with assistance from the W3C Team (for Community Groups, see the separate [Tools and Infrastructure](https://www.w3.org/community/about/tool/)). We are aware of questions about Zoom's security and privacy practices and recommend [mitigations](#settings) and usage guidelines. -## Scheduling a Zoom Conference +## Scheduling a Zoom Conference {#scheduling} W3C's groups typically meet weekly and therefore schedule recurring meetings for the duration of their charters. The Zoom scheduler limits how far into the future a recurring meeting may be scheduled. However, you can extend the end date after some time has passed. @@ -13,7 +13,7 @@ We have found that recurring meetings can be used at any time and are not limite To avoid interference from non-invitees, meeting coordinates should not be posted publicly. The meeting information, including password, should be posted to a Member-only mailing list and only the URI of the list archive message used in public meeting agendas or other public group pages. -## Suggested Settings +## Suggested Settings {#settings} W3C Team account owners should set [account default settings](https://w3c.zoom.us/profile/setting) as follows: @@ -29,29 +29,29 @@ W3C Team account owners should set [account default settings](https://w3c.zoom.u These settings will allow the group to meet even if the Team Host is not present. If an actual Host is required, the Team Host can join the call momentarily and assign co-Host privileges to one or more of the other attendees. -## Testing Your Connection +## Testing Your Connection {#testing} Zoom offers a [test meeting service](https://zoom.us/test) for anyone to use to test their connection. You should use it to hear how your own audio is working. This service may only work for Internet (not phone) connections. See also [Zoom's article on testing](https://support.zoom.us/hc/en-us/articles/115002262083-Joining-a-test-meeting). -## Recordings +## Recordings {#recordings} Zoom provides the ability to make recordings. If this feature is used, it must be with the consent of the meeting participants. Chairs have the responsibility to ensure that participants are aware that they are being recorded whenever this feature is used. Recordings are made available after the end (could take a few hours) using an email notification to the meeting host, and can only be shared by default to individuals with a W3C Zoom account. We're looking into providing additional recommendations to make those videos available through other means. Check also the special guidance on [automated meeting transcripts](transcripts.html). -## Ending a Meeting +## Ending a Meeting {#ending} Participants sometimes wander off and forget to disconnect at the end of a meeting. To avoid later embarrassment it is recommended that someone with Host privileges explicitly end each Zoom meeting once it has adjourned. -## Considerations +## Considerations {#considerations} -### Security and Privacy +### Security and Privacy {#sec_privacy} The standard precautions apply for meeting participants to mute your audio except when you mean to talk to the meeting to avoid interference and accidentally sharing private communications (e.g. yelling at your pets), and also to pay attention to what is visible in your video feed. Besides the [suggested settings for the W3C team accounts](#suggested-settings), we understand that concerns have been raised regarding the security/privacy of the Zoom clients. Several of the issues reported were based on native application hacks with computers already infected (such as modifying the installation script). The best and most cost-effective way to prevent those issues is to use the Web application for Zoom but it is more CPU intensive. Using an alternative device helps in isolating the native applications or the impact on CPU usage from the Web application. It's the perfect opportunity to repurpose an old device. -### Zoom documentation +### Zoom documentation {#zoomdoc} This section provides links to the Zoom documentation. @@ -70,4 +70,4 @@ This section provides links to the Zoom documentation. - scalability - [screen and application sharing](https://support.zoom.us/hc/en-us/categories/201137166) (share only one app, not only entire screen) - [security](https://zoom.us/security) -- video quality and settings \ No newline at end of file +- video quality and settings From 742347c6e4117b947d45a47e4104941362b0710b Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 17:07:26 +0100 Subject: [PATCH 096/225] add missing ids for headers --- meetings/organize.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meetings/organize.md b/meetings/organize.md index ff6d07673..b3a411e66 100644 --- a/meetings/organize.md +++ b/meetings/organize.md @@ -5,7 +5,7 @@ toc: true W3C benefits from diverse, inclusive, and worldwide participation. This document provides guidance to those organizing distributed meetings. -## Dealing with timezones +## Dealing with timezones {#timezones} {% include quote.html content="A distributed meeting is one where most of the attendees are expected to participate from remote locations @@ -31,7 +31,7 @@ A Chair should consider the following when judging the group's consensus: The [W3C Process](/policies/process/#GeneralMeetings) provides rules about the timing of meeting announcements and agenda publication. -## Group calendars +## Group calendars {#calendars} Group calendars are available from [lists of Groups](https://www.w3.org/groups/). For each Group, there is a '*Calendar*' tab. @@ -40,7 +40,7 @@ Group calendars are available from [lists of Groups](https://www.w3.org/groups/) - Group participants and other invited people are notified by email of new meetings and scheduling changes. This can be opted out from your [profile](https://www.w3.org/users/myprofile/edit). - All users have a [personal calendar](https://www.w3.org/users/myprofile/calendar) listing all meetings they are invited to. -### Creating an event +### Creating an event {#create_event} Things to keep in mind: From 546cdbf87c40633aa7b5c7103543a8b7b76383c5 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 17:10:54 +0100 Subject: [PATCH 097/225] add missing ids for headers --- meetings/workshops.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/meetings/workshops.md b/meetings/workshops.md index 16b450773..49d7e1656 100644 --- a/meetings/workshops.md +++ b/meetings/workshops.md @@ -3,7 +3,7 @@ title: Workshops toc: true --- -## Purpose +## Purpose {#purpose} A W3C Workshop is a one-off event which W3C holds when a need is felt to advance some aspect of the Open Web Platform and the correct way forward is unclear or would benefit from a wide variety of informed points of view before Standards-track work commences. @@ -11,7 +11,7 @@ The result of a W3C Workshop is a report, made publicly available, which summari To date, most W3C Workshops have been face-to-face meetings. Going forward, more workshops are expected to be virtual. As W3C gains experience with virtual workshops, this Guide is likely to be updated. -## Proposing a Workshop +## Proposing a Workshop {#Proposing} Most workshops to date have been proposed by the W3C Technical Staff, in particular, members of the W3C Strategy Team. Workshops being planned are publicly visible on the [W3C Strategy Funnel](https://github.com/w3c/strategy/projects/2). @@ -19,12 +19,12 @@ In the planning phase, each workshop is maintained as an issue on GitHub. For ex [Propose a W3C Workshop](https://github.com/w3c/strategy/issues/new?assignees=&labels=Exploration%3A%20untriaged&template=00-Exploration.md&title=) -## Planning a Workshop +## Planning a Workshop {#Planning} Each workshop proposal is discussed, undergoes a round of *horizontal review* (checking for Accessibility, Internationalization, Privacy and such like aspects) before it is approved by the W3C Management and a Call for Participation is issued. Here is an [example workshop call](https://www.w3.org/2019/08/inclusive-xr-workshop/). W3C has a requirement that no a Call for Participation is issued no later than eight weeks prior to the meeting's scheduled start date. This helps ensure that speakers and authors have adequate time to prepare position papers and talks. Once a workshop is proposed and accepted, a planning period of typically 12 weeks before the event allows meeting planners time to prepare logistics and business development time to organize any sponsorship. -## Attendance +## Attendance {#attendance} -In contrast to a conference workshop, which is typically a tutorial attended by those who paye a fee, W3C Workshop attendance is by submission of a Position Paper, which is evaluated by a Program Committee. Not all papers are accepted, and not all accepted papers are presented in person, although all accepted papers are made available to the public after the event and (ideally) to participants before the event, to encourage early discussion. \ No newline at end of file +In contrast to a conference workshop, which is typically a tutorial attended by those who paye a fee, W3C Workshop attendance is by submission of a Position Paper, which is evaluated by a Program Committee. Not all papers are accepted, and not all accepted papers are presented in person, although all accepted papers are made available to the public after the event and (ideally) to participants before the event, to encourage early discussion. From 1a2202a867618e7a68c73313e1bbfafc5e1676ae Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 17:15:00 +0100 Subject: [PATCH 098/225] add missing ids for headers --- meetings/transcripts.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meetings/transcripts.md b/meetings/transcripts.md index e6ebe51e4..d6027b2c1 100644 --- a/meetings/transcripts.md +++ b/meetings/transcripts.md @@ -3,7 +3,7 @@ title: Automated Transcripts toc: true --- -## On Saving Automated Meeting Transcripts +## On Saving Automated Meeting Transcripts {#background} Many teleconferencing systems are offering automated speech-to-text facilities to provide captioning and transcription of meetings. W3C has *some* Zoom licenses to offer this feature by default. @@ -21,7 +21,7 @@ In the Host’s account, the ‘Save Captions’ setting must be turned off. Thi The Webex Host should make sure Webex Assistant is turned off at the start of a meeting. See [Webex Assistant for Meetings Considerations](https://help.webex.com/en-us/q1y8ig/Webex-Assistant-for-Meetings-Considerations). -## Changelog +## Changelog {#status} - See [commits history](https://github.com/w3c/Guide/commits/main/meetings/transcripts.html) -- See also [w3process #334](https://github.com/w3c/process/issues/334) \ No newline at end of file +- See also [w3process #334](https://github.com/w3c/process/issues/334) From 606f50f2cc5993f3456f88ad16b702d7ff459971 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 17:21:23 +0100 Subject: [PATCH 099/225] add missing ids for headers --- meetings/tpac.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meetings/tpac.md b/meetings/tpac.md index db842fe03..e677bdcff 100644 --- a/meetings/tpac.md +++ b/meetings/tpac.md @@ -7,7 +7,7 @@ The goal of Group meetings during a W3C TPAC is to gather the community together While W3C Groups meet throughout the year in a variety of ways (teleconference, Zoom, F2F), the annual TPAC plays a unique and special role in the annual calendar of a Group. What sets these meetings apart is that by having the Group together for 2 days (and also adjacent to many other groups), the Group can get done that which it cannot normally do - specifically (see below). -## TPAC 2021 +## TPAC 2021 {#tpac2021} With the pandemic, many Groups did not meet for TPAC 2020, and other groups met briefly and did not fully achieve the full goals of a TPAC meeting. That has caused a deficit in meeting the special objectives that we previously have only been able to achieve through TPAC Group meetings. @@ -24,7 +24,7 @@ Since we'll be virtual, a few reminders: 4. If you plan to make a presentation, we recommend you to record them in advance. Ask the events team for assistance if needed but they require 2 weeks lead time (deadline is October 11). See also our [recording tips](https://www.w3.org/wiki/Virtual_Presentations). 5. Consider if a breakout session might be useful. -## TPAC Group meeting +## TPAC Group meeting {#group} TPAC meeting is an opportunity for a Working or Interest Group : @@ -54,7 +54,7 @@ On the deliverables: - Do you need guidance or help, such as choosing between several designs/solutions? - Ask participants which issue they would like to dive in? (limit of \[2? 3?] per participant?) -## TPAC Joint Meetings +## TPAC Joint Meetings {#joint} - TPAC is an opportunity for joint meetings between Groups: @@ -62,6 +62,6 @@ On the deliverables: 2. horizontal issues raised during wide reviews that have been queued 3. requests sent to other Groups that did not progress in there -## TPAC Breakouts +## TPAC Breakouts {#breakout} If your Group has topic(s) of general interest, consider organizing a breakout session to attract a wider audience. From 93e59d9122c36aca093035db90b03eb8bb122d3c Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 17 Dec 2024 17:36:18 +0100 Subject: [PATCH 100/225] add ids and quote --- other/elected-body-communication-guidelines.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/other/elected-body-communication-guidelines.md b/other/elected-body-communication-guidelines.md index 5f47f9841..7fee1a6ad 100644 --- a/other/elected-body-communication-guidelines.md +++ b/other/elected-body-communication-guidelines.md @@ -5,19 +5,17 @@ toc: true This document provides guidance for members of the W3C elected bodies: the Advisory Board (AB) and Technical Architecture Group (TAG). -## W3C elected bodies +## W3C elected bodies {#intro} The [AB](/policies/process/#AB) and the [TAG](/policies/process/#TAG) are defined in the W3C Process, as are the [rules of participation](/policies/process/#AB-TAG-participation) for both groups. -## W3C values and behaviours +## W3C values and behaviours {#values} Like all W3C participants, members of elected bodies are required to follow the [W3C Code of Conduct](/policies/code-of-conduct/). As leaders, members of elected bodies should also consider the ways in which they can demonstrate the Code of Conduct's [expected behavior](/policies/code-of-conduct/#expected-behavior), and proactively respond to instances of [unacceptable behavior](/policies/code-of-conduct/#unacceptablebehavior). -## Communication guidelines +## Communication guidelines {#guidelines} -As the W3C process says: - -> Advisory Board and TAG participants have a special role within W3C. They are elected by the membership and [appointed by the Team](/policies/process/#TAG-appointments) with the expectation that they will use their best judgement to find the best solutions for the web, not just for any network, technology, vendor, or user. +{% include quote.html content="Advisory Board and TAG participants have a special role within W3C. They are elected by the membership and [appointed by the Team](/policies/process/#TAG-appointments) with the expectation that they will use their best judgement to find the best solutions for the web, not just for any network, technology, vendor, or user." footer=" W3C process " %} As leaders within the W3C community, the opinions of members of elected bodies carry particular weight, whether they are expressed within our community or elsewhere. @@ -34,7 +32,7 @@ As a member of an elected body: - If your comment is influenced by your participation in the elected body, you may want to mention it, for example "In my experience of being on the AB...". - You will be held to a higher standard as a result of your elected status and in recognition of your leadership within the W3C community. -## Representing formal decisions +## Representing formal decisions {#decisions} When communicating a formal decision by the elected body you are a member of: @@ -53,7 +51,7 @@ When discussing a matter that has not reached a conclusion: - Make it clear when feedback and comments are wanted, and let people know how to do so. - Share the intended message with the rest of the elected body you are a member of before you send it. -### Revision History +## Revision History - 2020-09-03: Document becomes operational. - 2020-09-02: Document created. From 8cd4ecd2e56bc5c1acdf7e5e72cdd137f9d595e3 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 11:08:27 +0100 Subject: [PATCH 101/225] adapt the markdown syntax + use '\' to escape the numbers --- process/non-participant-commitment.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/process/non-participant-commitment.md b/process/non-participant-commitment.md index dd0287672..869b6319d 100644 --- a/process/non-participant-commitment.md +++ b/process/non-participant-commitment.md @@ -1,14 +1,19 @@ +--- +title: Non participant commitment +toc: no +--- + This is Team guidance for implementation of [Process 6.2.6](/policies/process/#contributor-license). If you have any IPR questions, and for substantial contributions, please contact [team-legal](mailto:team-legal @ w3.org). When a non-member (or not-yet-identified member) makes a pull request contribution to a W3C Working Group repository, the repository manager tool flags it for review and sends them an email with [this text](https://github.com/w3c/ash-nazg/blob/master/templates/affiliation-mail.txt) to the contributor, chairs, and team contacts. -1. If the contributor is a member participating in the WG, link the github account to the W3C member-affiliated account and re-validate. +1\. If the contributor is a member participating in the WG, link the github account to the W3C member-affiliated account and re-validate. -1.5 If the contributor is a member not participating in the WG, first encourage them to join the WG. If they won't, and this is a one-off contribution, follow the flow below. +1.5. If the contributor is a member not participating in the WG, first encourage them to join the WG. If they won't, and this is a one-off contribution, follow the flow below. If the contribution is non-substantive, e.g. fixing a typo, mark it as non-substantive (which clears the IPR flag). -2. If the contributor is not an affiliate of a current W3C member, the team follows up with them to see: +2\. If the contributor is not an affiliate of a current W3C member, the team follows up with them to see: a. Do they work for an organization who should be a member? From ee30e27e292727b9f9aba80709ca95141c29a5f1 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 11:13:11 +0100 Subject: [PATCH 102/225] remove

    and first sentence as a duplicate of

    , remove toc --- process/joint-deliverables.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/process/joint-deliverables.md b/process/joint-deliverables.md index 244132e33..66b5be1a5 100644 --- a/process/joint-deliverables.md +++ b/process/joint-deliverables.md @@ -1,12 +1,8 @@ --- title: Joint deliverables -toc: yes +toc: no --- -This document provides details about joint deliverables between W3C Groups. - -## Joint deliverables between W3C Working Groups {#between-wgs} - As a general principle, each Working Group must follow its charter, including in the case of joint deliverables. 1. If one of the Working Groups decides to drop a joint deliverable From 94db3c6ced26a8c2ddbb54d406cea02d32ceb8e4 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 11:17:52 +0100 Subject: [PATCH 103/225] Rename horizontal-groups from .html to .md --- process/{horizontal-groups.html => horizontal-groups.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{horizontal-groups.html => horizontal-groups.md} (100%) diff --git a/process/horizontal-groups.html b/process/horizontal-groups.md similarity index 100% rename from process/horizontal-groups.html rename to process/horizontal-groups.md From f354648afe28099cff4c4ceaee0914cb7bd989c7 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 11:25:53 +0100 Subject: [PATCH 104/225] Convert horizontal-groups to markdown --- process/horizontal-groups.md | 100 +++++++---------------------------- 1 file changed, 19 insertions(+), 81 deletions(-) diff --git a/process/horizontal-groups.md b/process/horizontal-groups.md index 1eb83107a..ecbab1e3c 100644 --- a/process/horizontal-groups.md +++ b/process/horizontal-groups.md @@ -1,91 +1,29 @@ - - - - -Horizontal Groups - - - - - - - +--- +title: Horizontal Groups +toc: true +--- - +The W3C Process mentions the [W3C horizontal Groups](/policies/process/#wide-review), described in this document. -

    The W3C Process mentions -the W3C horizontal Groups, described in this document.

    +## 1. What is an horizontal group ? {#definition} -

    What is an horizontal group ?

    +An horizontal group is tasked to regularly produce expert reviews of proposals and specifications under development by other Working Groups and Community Groups, and of charters for other W3C groups. It may also produce expert reviews of proposals and specifications produced outside of W3C. -

    An horizontal group is tasked to regularly produce expert reviews of proposals - and specifications under development by other Working Groups and Community Groups, - and of charters for other W3C groups. It may also produce expert reviews of proposals and specifications - produced outside of W3C. -

    +## 2. List of W3C Horizontal Groups {#w3c-hr-list} -

    List of W3C Horizontal Groups

    +As of November 2024, there are **5 W3C horizontal groups**: -

    - As of November 2024, there are 5 W3C horizontal groups: -

    +- [Accessible Platform Architectures Working Group](https://www.w3.org/groups/wg/apa/) +- [Internationalization Working Group](https://www.w3.org/groups/wg/i18n-core/) +- [Privacy Working Group](https://www.w3.org/groups/wg/privacy/) +- [Security Interest Group](https://www.w3.org/groups/ig/security/) +- [Technical Architecture Group](https://www.w3.org/groups/other/tag/) - +## 3. Other Horizontal Groups {#other-hr-list} -

    Other Horizontal Groups

    +Some expert groups outside of W3C may also provide an horizontal review. Charters of W3C Working and Interest Groups should explicitly list the relevant expert groups if an horizontal review is expected from them. -

    Some expert groups outside of W3C may also provide an horizontal review. Charters of W3C Working and Interest Groups should explicitly - list the relevant expert groups if an horizontal review is expected from them. -

    +## 4. Horizontal Reviews {#horizontal-review} -

    Horizontal Reviews`

    - -

    Horizontal reviews are documented and part of the wide review. -

    - - -
    - -

    Feedback is to @w3c/guidebook and - is welcome on GitHub

    - - +Horizontal reviews are documented and part of the [wide review](/Guide/documentreview/). + \ No newline at end of file From 12ccd4f3dbfa7a04a9c425a1196006cfdb86997d Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 12:08:38 +0100 Subject: [PATCH 105/225] replace the quote component for examples --- process/charter.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/process/charter.md b/process/charter.md index 001203c05..ef8ae5a16 100644 --- a/process/charter.md +++ b/process/charter.md @@ -199,8 +199,8 @@ If there are only very minor changes to a charter resulting from the review, the If substantive changes are proposed in response to charter review, the Team Contact must send the charter with proposed changes, the [HTML diff](https://services.w3.org/htmldiff), and an explanation of the changes and their rationale to all who reviewed the charter, copying the [member-charters-review@w3.org](https://lists.w3.org/Archives/Member/member-charters-review/) member-archived mailing list, accompanied by a request for response (with a deadline of a minimum of one week for response time) if reviewers have concerns or if the changes would alter their reviews. If the work continues or derives from an existing group or community effort, the Team Contact should also send the [HTML diff](https://services.w3.org/htmldiff) and a public rationale to that group or community. These communications should note that W3C has not yet approved the charter. -{% include quote.html content=" Suggested wording: Please let us know by \[date+1 week] if you have concerns or if this change would alter -your review." %} +> ***Suggested wording:*** *Please let us know by \[date+1 week] if you have concerns or if this change would alter +your review*. If anyone expresses new concern in response to the re-review, the Team may attempt to resolve the concern (with re-review), formally open a new AC review, or the [W3C Council](https://www.w3.org/Guide/council/council.html) may treat it as an objection and overrule it. @@ -208,7 +208,11 @@ If there are substantive changes, before any announcement, the Team Contact: 1. Mints a new URI for the version of the charter that includes the changes. In the "Charter history" section of the charter, please link to the original (reviewed) charter. 2. Modifies the original charter in place with the following status sentence at the top: - {% include quote.html content=" <p class='todo'>This charter has been replaced by <a>\[a newer version]</a>.</p>" %} + + ``` +

    Date: Wed, 18 Dec 2024 13:09:42 +0100 Subject: [PATCH 107/225] Rename normative-references from .html to .md --- .../tilt/{normative-references.html => normative-references.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/tilt/{normative-references.html => normative-references.md} (100%) diff --git a/process/tilt/normative-references.html b/process/tilt/normative-references.md similarity index 100% rename from process/tilt/normative-references.html rename to process/tilt/normative-references.md From 78122c44d5dc1af5dfefe28ab7a2ba9781d59f86 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 13:39:55 +0100 Subject: [PATCH 108/225] Convert normative-references to markdown --- process/tilt/normative-references.md | 431 ++++++++------------------- 1 file changed, 121 insertions(+), 310 deletions(-) diff --git a/process/tilt/normative-references.md b/process/tilt/normative-references.md index a9734862d..dca14d18e 100644 --- a/process/tilt/normative-references.md +++ b/process/tilt/normative-references.md @@ -1,310 +1,121 @@ - - - - -Normative References - - - - - - - - -

    - - - -
    -

    Purpose

    -

    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. - 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.

    -
    - -
    -

    Stability

    - -

    The Team considers the stability of the referenced documents by -evaluating the probability that the referenced documents will change -and in which timeframe. In the event that the referenced document will -change in a way that is not backward compatible, the risks to deployed -resources(deployed -markup, other standards, documents, code, products, applications, …) -will be considered as well as associated recovery strategies.

    - -

    There are several factors that the Team needs to consider as part of a stability assessment.

    - -

    External organizations

    - -

    Who produced the document?

    -
    1. Is it produced by a group that the Team believes follows the OpenStand 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? -
    - -

    Stability of the referenced document

    - -

    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, 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, 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? -
    - -

    Stability of the referenced part(s)

    - -

    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? -
      -

      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? -
    - -

    Nature of the dependency

    - -

    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? - -
      1. 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:

        -
        1. 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) -
        2. 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). -
        3. 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. -
    4. If a change impacts deployed resources, what will be the recovery strategy?
    5. -
    - -

    Status of implementations

    - -

    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)? -
    -
    - -
    -

    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? -
    - -
    - -
    -

    Licensing

    - -

    -W3C seeks to issue Recommendations that can be implemented on - a Royalty-Free - 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? -
    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? -
    - -
    - - -

    - Note: The experimental normative references checker can be used to identify which references are or should be normative in your document. -

    - -
    -

    Appendix I : Stability Evaluation of HTML and DOM Living Standards

    - -

    The guidelines in - section 2 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 for each referenced feature. -
    • -
    - -

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

    - -

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

    -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Change History
    DateDescription
    2023-10-23Move document to GitHub. - Update to current, 2023 Process.
    2020-10-30Update W3C Recommendation track citation to the current W3C Process. Update Patent Policy reference to the current version and correct a fragment id. Clarify the intent regarding backwards compatibility in the Stability section introduction.
    2019-06-14Correct a mailto: reference. Update W3C Recommendation track citation to the 2019 version. Add Appendix I.
    2018-04-17Update W3C Recommendation track citation to the 2018 version, note that the checker is experimental
    2018-02-07Added a note about the normative reference checker
    2014-09-11Update W3C Recommendation track citation to the 2014 version
    2015-04-06Added a second example in 2.2.1, and an example in 2.2.2 and in 2.3.1
    2013-10-18Distributed to the W3C Advisory Committee and Chairs for comment on 18 October 2013. -
    -
    -

    Feedback is to @w3c/tilt - and is welcome on GitHub

    - - +--- +title: Normative References +toc: true +--- + +## 1. Purpose {#Purpose} + +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. + +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. + +## 2. Stability {#stability} + +The Team considers the stability of the referenced documents by evaluating the probability that the referenced documents will change and in which timeframe. In the event that the referenced document will change in a way that is not backward compatible, the risks to deployed resources(deployed markup, other standards, documents, code, products, applications, …) will be considered as well as associated recovery strategies. + +There are several factors that the Team needs to consider as part of a stability assessment. + +### 2.1 External organizations {#orgs} + +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? + +### 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**, *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**, *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? + +### 2.3 Stability of the referenced part(s) {#parts} + +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? + + **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?* + +### 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? + + 1. 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:* + + - *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? + +### 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)? + +## 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? + +## 4. Licensing {#licensing} + +W3C seeks to issue Recommendations that can be implemented on a [Royalty-Free](/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? + +**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. + +## Appendix I : Stability Evaluation of HTML and DOM Living Standards {#AppendixI} + +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. + +For HTML Recommendations produced jointly by WHATWG and W3C, the DOM Living Standard is normatively referenceable. + +For DOM Recommendations produced jointly by WHATWG and W3C, the HTML Living Standard is normatively referenceable. + +## Change History + +- **2023-10-23**: Move document to GitHub. Update to current, 2023 Process. +- **2020-10-30**: Update W3C Recommendation track citation to the current W3C Process. Update Patent Policy reference to the current version and correct a fragment id. Clarify the intent regarding backwards compatibility in the Stability section introduction. +- **2019-06-14**: Correct a mailto: reference. Update W3C Recommendation track citation to the 2019 version. Add Appendix I. +- **2018-04-17**: Update W3C Recommendation track citation to the 2018 version, note that the checker is experimental. +- **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. \ No newline at end of file From 3fa4b7a653e7f38b93775283e16d480dd848f8ad Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 14:45:40 +0100 Subject: [PATCH 109/225] add toc --- teamcontact/remote-maintainers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/teamcontact/remote-maintainers.md b/teamcontact/remote-maintainers.md index 3b297d080..e04e272a1 100644 --- a/teamcontact/remote-maintainers.md +++ b/teamcontact/remote-maintainers.md @@ -1,6 +1,6 @@ --- title: SmartList Remote Maintainers Guide -toc: false +toc: true --- W3C's mailing lists are managed using a customized version of SmartList. From eb21b0542355ec27c83dd4209fa2f86fd9c07387 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 14:50:19 +0100 Subject: [PATCH 110/225] Rename tools/new-group from .html to .md --- tools/{new-group.html => new-group.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename tools/{new-group.html => new-group.md} (100%) diff --git a/tools/new-group.html b/tools/new-group.md similarity index 100% rename from tools/new-group.html rename to tools/new-group.md From bcd6cd98ef42975c1825ca547f5af29303df3863 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 15:51:46 +0100 Subject: [PATCH 111/225] Convert tools/new-group to markdown --- tools/new-group.md | 297 +++++++++++++++------------------------------ 1 file changed, 99 insertions(+), 198 deletions(-) diff --git a/tools/new-group.md b/tools/new-group.md index 4e7b536db..956a6b67c 100644 --- a/tools/new-group.md +++ b/tools/new-group.md @@ -1,143 +1,68 @@ - - - - -How to Set Up A New Group - - - - - - - - - - -

    Once the decision of creating a new group has been announced and the group effectively exists, - there are considerations for the setup. This document suggests a Group setup for the various W3C tools. -

    - - -

    Administrivia repository

    - -

    - Having an administrivia repository allows to track and maintain potential - non-technical documents used by the group, such as: -

    -
      -
    • group process/policies
    • -
    • meeting agendas, minutes, logistics
    • -
    • invited expert expectations
    • -
    • milestones
    • -
    • homepage
    • -
    • etc.
    • -
    - -

    - For this repository, you may use the naming convention w3c/{shortname}{type}, such as w3c/privacywg. Don't forget to set - the w3c.json file appropriately (repo-type: "project"). -

    - -

    Group homepage

    - -

    - By default, the W3C website will have a homepage for the Group, maintained - by various W3C systems and accessible through the Group pages. For simplicity and ease of maintenance, - we recommend that you point your participants to that group page. Additional links can be - added by the Team in the "Tools" page of the Group if needed. -

    -

    - However, if your group do feel the need to maintain a dedicated homepage, place it in your group - administrivia repository and ask to expose it through w3.org as a proxy - (Team should look at W3C Web rewrites system). Don't forget to set - the w3c.json file appropriately (repo-type: "homepage"). -

    - -

    Github repositories

    - -

    - All GitHub repositories used by the group must indicate so, using the w3c.json file in those repositories. If you do not use the GitHub 'w3c' organization, - make sure the Team associates your GitHub organization in the 'Version Control' entry of the Tools page (Team may modify those entries using the admin interface) and the tooling - will associate by default all of the repositories in your GitHub organization to your group. -

    -

    - Make sure the license and code of conduct files are there (Team, you may use the repository manager to create those). -

    -

    - If a repository needs to be moved across organizations, the Team can help. By default, we recommend one github repository per technical documents as well as one administrvia repository. -

    -

    - All group repositories will appear on the 'Tools' page. -

    - -

    GitHub Teams

    - -

    The W3C system can generate and maintain 2 GitHub teams: Chairs/Team Contacts (group-[id]-chairs), and all participants (group-[id]-members). -You may give admin access to chairs for the group repositories, and write access for all participants.

    - -

    Calendar

    - -

    - To help W3C participants navigate through the various groups, Chairs and Team Contacts must use the W3C Calendar system rather than using separate tools. - By default, recurring meetings must be 'Tentative', confirming only meetings that will actually happen or cancelling them otherwise. For TPAC meetings, the events Team will - create specific calendar entries. Each meeting should point to where the agenda and minutes did or will appear. -

    -

    - To use zoom, see Scheduling a Zoom Conference. -

    -

    Agenda

    - -

    - To allow the broadest participation in setting meeting agendas, we recommend opening a GitHub issue in your administrivia repository, with a label "agenda", one issue per meeting. - There is at least one issue opened at all time for the next future meeting. You may use a GitHub template to facilitate the creation of such agenda issue. -

    -

    - Encourage participants to comment on the issue in order to add agenda items. Your participants may also add a label "agenda+" on any issue in technical specifications. If so, - Chairs should monitor the agenda board to catch those (and remove the label once if the issue got covered in a meeting). -

    -

    - Your calendar entry should point to the appropriate GitHub issue (or a search link to find it). -

    -

    - Chairs are reminded of the Meeting Scheduling and Announcements expectations. -

    - -

    In .github/ISSUE_TEMPLATE/agenda.md:

    -
    -
    +---
    +title: How to setup a new Working Group or Interest Group
    +toc: true
    +---
    +
    +Once the [decision of creating a new group](../process/charter.html#join-form) has been announced and the group effectively exists, there are considerations for the setup. This document suggests a Group setup for the various W3C tools.
    +
    +## 1. Administrivia repository {#administrivia}
    +
    +Having an administrivia repository allows to track and maintain potential non-technical documents used by the group, such as:
    +
    +- group process/policies
    +- meeting agendas, minutes, logistics
    +- invited expert expectations
    +- milestones
    +- homepage
    +- etc.
    +
    +For this repository, you may use the naming convention *`w3c/{shortname}{type}`*, such as *`w3c/privacywg`*. Don't forget to set the [`w3c.json` file](https://w3c.github.io/w3c.json.html) appropriately (*`repo-type: "project"`*).
    +
    +## 2. Group homepage {#homepage}
    +
    +By default, the W3C website will have a homepage for the Group, maintained by various W3C systems and accessible through the [Group pages](https://www.w3.org/groups/). For simplicity and ease of maintenance, we recommend that you point your participants to that group page. Additional links can be added by the Team in the "Tools" page of the Group if needed.
    +
    +However, if your group do feel the need to maintain a dedicated
    +homepage, place it in your group administrivia repository and ask to
    +expose it through w3.org as a proxy (Team should look at [W3C Web
    +rewrites system](https://www.w3.org/2019/03/rewrites-doc.html)). Don't
    +forget to set the [`w3c.json`
    +file](https://w3c.github.io/w3c.json.html) appropriately (*`repo-type:
    +"homepage"`*).
    +
    +## 3. Github repositories {#repositories}
    +
    +All GitHub repositories used by the group must indicate so, using the [`w3c.json` file](https://w3c.github.io/w3c.json.html) in those repositories. If you do not use the GitHub 'w3c' organization, make sure the Team associates your GitHub organization in the 'Version Control' entry of the Tools page (Team may modify those entries using the [admin](https://w3.org/admin) interface) and the tooling will associate *by default* all of the repositories in your GitHub organization to your group.
    +
    +Make sure the license and code of conduct files are there (Team, you may use the [repository manager](https://labs.w3.org/repo-manager/) to create those).
    +
    +If a repository needs to be moved across organizations, the Team can help. By default, we recommend one github repository per technical documents as well as one administrvia repository.
    +
    +All group repositories will appear on the 'Tools' page.
    +
    +## 4. GitHub Teams {#github}
    +
    +The W3C system can generate and maintain 2 GitHub teams: Chairs/Team Contacts (*`group-[id]-chairs`*), and all participants (*`group-[id]-members`*). You may give admin access to chairs for the group repositories, and write access for all participants.
    +
    +## 5. Calendar {#calendar}
    +
    +To help W3C participants navigate through the various groups, Chairs and Team Contacts must use the W3C Calendar system rather than using separate tools. By default, recurring meetings must be 'Tentative', confirming only meetings that will actually happen or cancelling them otherwise. For TPAC meetings, the events Team will create specific calendar entries. Each meeting should point to where the agenda and minutes did or will appear.
    +
    +To use zoom, see [Scheduling a Zoom Conference](https://www.w3.org/Guide/meetings/zoom).
    +
    +## 6. Agenda {#agenda}
    +
    +To allow the broadest participation in setting meeting agendas, we recommend opening a GitHub issue in your administrivia repository, with a label "**`agenda`**", one issue per meeting. There is at least one issue opened at all time for the next future meeting. You may use a GitHub template to facilitate the creation of such agenda issue.
    +
    +Encourage participants to comment on the issue in order to add agenda items. Your participants may also add a label "**`agenda+`**" on any issue in technical specifications. If so, Chairs should monitor the [agenda board](/PM/Groups/agendas.html) to catch those (and remove the label once if the issue got covered in a meeting).
    +
    +Your calendar entry should point to the appropriate GitHub issue (or a search link to find it).
    +
    +Chairs are reminded of the [Meeting Scheduling and Announcements](https://www.w3.org/policies/process/#meeting-schedules) expectations.
    +
    +In `.github/ISSUE_TEMPLATE/agenda.md`:
    +
    +```
     ---
     name: Meeting agenda
     about: Agenda discussion for a given group meeting
    @@ -158,61 +83,37 @@ assignees: 'chairgithubhandle[,chairgithubhandle]*'
     ---
     
     Please add comments to this issue if you have suggestions for agenda items.
    -  
    -
    - -

    Chairs and Team Contacts

    -

    - The Team must ensure that Chairs and Team Contacts are appropriately identify in the Group pages - (Team should use the admin interface to do so). - Chairs and Team Contacts may want to schedule a regular (weekly, bi-weekly, monthly, quaterly?) meeting to sync-up and track group progress. -

    -

    - Team Contacts should ensure that new Chairs get appropriate onboarding, including from the W3C Project Management Lead. -

    -

    See also:

    - - -

    Invited Experts

    - -

    - Invited expert approvals may include a paragraph or two to clarify the expectations to maintain the status, such as: -

    -

    In invited-experts.md:

    -
    -

    We generally welcome anyone interested in working on and improving [topic] on the Web. - However, we expect [group] participants to contribute, which can take the form of participating - in editing specifications, scribing calls, participating in discussions, among other things. - Inactive or non-contributing invited experts may not be renewed.

    -
    -

    (Team include the paragraph in the Message box to be included when editing the invited application for approval)

    -

    - To help with consistency, you should maintain those invited expert expectations in your group administrivia repository so - that it can be easily revised or pointed to. -

    - -

    - Chairs and Team Contacts should keep track of invited applications (accessible from the group participants list) and process them - on an ongoing basis. -

    - -

    Onboarding

    - -

    - Particpants will receive 2 messages when joining: -

    -
      -
    1. W3C Group Management messages: record the commitments from an organizaton and participants
    2. -
    3. W3C onboarding messages: a welcoming message that may be modified at-will for your group. See also - w3c/onboarding.
    4. -
    - -
    - -

    Feedback is to @w3c/guidebook and - is welcome on GitHub

    - - + +``` + +## 7. Chairs and Team Contacts {#chairs-and-tcs} + +The Team must ensure that Chairs and Team Contacts are appropriately identify in the [Group pages](https://www.w3.org/groups/) (Team should use the [admin](https://w3.org/admin) interface to do so). Chairs and Team Contacts may want to schedule a regular (weekly, bi-weekly, monthly, quaterly?) meeting to sync-up and track group progress. + +Team Contacts should ensure that new Chairs get appropriate onboarding, including from the W3C Project Management Lead. + +See also: + +- [W3C Chair Buddy System](../chair/buddy.html) +- [Working Groups](https://www.w3.org/PM/Groups/chairboards.html?gtype=working) and [Interest Groups](https://www.w3.org/PM/Groups/chairboards.html?gtype=interest) dashboards + +## 8. Invited Experts {#invited-experts} + +Invited expert approvals may include a paragraph or two to clarify the expectations to maintain the status, such as: + +In `invited-experts.md`: + +We generally welcome anyone interested in working on and improving \[topic] on the Web. However, we expect \[group] participants to contribute, which can take the form of participating in editing specifications, scribing calls, participating in discussions, among other things. Inactive or non-contributing invited experts may not be renewed. + +(Team include the paragraph in the `Message` box to be included when editing the invited application for approval) + +To help with consistency, you should maintain those invited expert expectations in your group administrivia repository so that it can be easily revised or pointed to. + +Chairs and Team Contacts should keep track of invited applications (accessible from the group participants list) and process them on an ongoing basis. + +## 9. Onboarding {#onboarding} + +Particpants will receive 2 messages when joining: + +1. `W3C Group Management` messages: record the commitments from an organizaton and participants +2. `W3C onboarding` messages: a welcoming message that may be modified at-will for your group. See also [w3c/onboarding](https://github.com/w3c/onboarding). From 5c87f0cecf1d8ebfe154e845302efcf29eb07f56 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 16:09:25 +0100 Subject: [PATCH 112/225] Complete the conversion of tools/new-group to markdown --- tools/new-group.md | 50 +++++++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/tools/new-group.md b/tools/new-group.md index 956a6b67c..0d269cb0e 100644 --- a/tools/new-group.md +++ b/tools/new-group.md @@ -16,7 +16,7 @@ Having an administrivia repository allows to track and maintain potential non-te - homepage - etc. -For this repository, you may use the naming convention *`w3c/{shortname}{type}`*, such as *`w3c/privacywg`*. Don't forget to set the [`w3c.json` file](https://w3c.github.io/w3c.json.html) appropriately (*`repo-type: "project"`*). +For this repository, you may use the naming convention ***`w3c/{shortname}{type}`***, such as ***`w3c/privacywg`***. Don't forget to set the [`w3c.json` file](https://w3c.github.io/w3c.json.html) appropriately (***`repo-type: "project"`***). ## 2. Group homepage {#homepage} @@ -27,8 +27,8 @@ homepage, place it in your group administrivia repository and ask to expose it through w3.org as a proxy (Team should look at [W3C Web rewrites system](https://www.w3.org/2019/03/rewrites-doc.html)). Don't forget to set the [`w3c.json` -file](https://w3c.github.io/w3c.json.html) appropriately (*`repo-type: -"homepage"`*). +file](https://w3c.github.io/w3c.json.html) appropriately (***`repo-type: +"homepage"`***). ## 3. Github repositories {#repositories} @@ -42,7 +42,7 @@ All group repositories will appear on the 'Tools' page. ## 4. GitHub Teams {#github} -The W3C system can generate and maintain 2 GitHub teams: Chairs/Team Contacts (*`group-[id]-chairs`*), and all participants (*`group-[id]-members`*). You may give admin access to chairs for the group repositories, and write access for all participants. +The W3C system can generate and maintain 2 GitHub teams: Chairs/Team Contacts (***`group-[id]-chairs`***), and all participants (***`group-[id]-members`***). You may give admin access to chairs for the group repositories, and write access for all participants. ## 5. Calendar {#calendar} @@ -60,29 +60,29 @@ Your calendar entry should point to the appropriate GitHub issue (or a search li Chairs are reminded of the [Meeting Scheduling and Announcements](https://www.w3.org/policies/process/#meeting-schedules) expectations. -In `.github/ISSUE_TEMPLATE/agenda.md`: +In ***`.github/ISSUE_TEMPLATE/agenda.md`***: ``` ---- -name: Meeting agenda -about: Agenda discussion for a given group meeting -title: '[agenda] 2025-xx-xx' -labels: 'agenda' -assignees: 'chairgithubhandle[,chairgithubhandle]*' + --- + name: Meeting agenda + about: Agenda discussion for a given group meeting + title: '[agenda] 2025-xx-xx' + labels: 'agenda' + assignees: 'chairgithubhandle[,chairgithubhandle]*' ---- + --- -## Proposed Agenda + ## Proposed Agenda -1. Introductions, Code of Conduct -1. agenda item 2 -1. agenda item 3 -1. agenda item 4 -1. AOB + 1. Introductions, Code of Conduct + 1. agenda item 2 + 1. agenda item 3 + 1. agenda item 4 + 1. AOB ---- + --- -Please add comments to this issue if you have suggestions for agenda items. + Please add comments to this issue if you have suggestions for agenda items. ``` @@ -101,11 +101,11 @@ See also: Invited expert approvals may include a paragraph or two to clarify the expectations to maintain the status, such as: -In `invited-experts.md`: +In ***`invited-experts.md`***: -We generally welcome anyone interested in working on and improving \[topic] on the Web. However, we expect \[group] participants to contribute, which can take the form of participating in editing specifications, scribing calls, participating in discussions, among other things. Inactive or non-contributing invited experts may not be renewed. + > We generally welcome anyone interested in working on and improving \[topic] on the Web. However, we expect \[group] participants to contribute, which can take the form of participating in editing specifications, scribing calls, participating in discussions, among other things. Inactive or non-contributing invited experts may not be renewed. -(Team include the paragraph in the `Message` box to be included when editing the invited application for approval) +(Team include the paragraph in the ***`Message`*** box to be included when editing the invited application for approval) To help with consistency, you should maintain those invited expert expectations in your group administrivia repository so that it can be easily revised or pointed to. @@ -115,5 +115,5 @@ Chairs and Team Contacts should keep track of invited applications (accessible f Particpants will receive 2 messages when joining: -1. `W3C Group Management` messages: record the commitments from an organizaton and participants -2. `W3C onboarding` messages: a welcoming message that may be modified at-will for your group. See also [w3c/onboarding](https://github.com/w3c/onboarding). +1. ***`W3C Group Management`*** messages: record the commitments from an organizaton and participants +2. ***`W3C onboarding`*** messages: a welcoming message that may be modified at-will for your group. See also [w3c/onboarding](https://github.com/w3c/onboarding). From a0b9948037718caaf6bf524ace70c3f0f6e16015 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 16:26:09 +0100 Subject: [PATCH 113/225] add ids and quote component --- standards-track/index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/standards-track/index.md b/standards-track/index.md index bb6e40807..cb0e44239 100644 --- a/standards-track/index.md +++ b/standards-track/index.md @@ -3,7 +3,7 @@ title: W3C Recommendation Track Readiness Best Practices toc: true --- -## Status +## Status {#status} October 2023: Document updated to account for [changes in Process 2023](https://www.w3.org/2023/Process-20230612/#changes-2021), in particular the Director-free changes. @@ -11,13 +11,13 @@ August 2016: This document was developed by a task force of the [W3C Advisory Bo This [document lives in Github](https://github.com/w3c/standards-track/blob/master/index.html), where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use [Github issues](https://github.com/w3c/standards-track/issues). -## Problem Statement +## Problem Statement {#problem} The practices proposed in this document are intended to address some specific problems: W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere -## Overview of the Proposed Solution +## Overview of the Proposed Solution {#solution} W3C should more tightly focus its formal standardization effors on specifications that are most likely to get consensus within the consortium and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD. @@ -55,7 +55,7 @@ Arguments against focused on mandating using W3C Community Groups to incubate pr The readiness criteria below outline best practices for finding an appropriate balance among these perspectives. They encourage all involved in advancing work to the Recommendation track to gather more evidence to drive the decision and to think carefully about how to interpret it. They do not mandate any one mode of gathering that evidence or an algorithm to assess it. -## Readiness Criteria +## Readiness Criteria {#criteria} The criteria here are used to evaluate whether a technical specification development effort is ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would facilitate the [W3C decision](https://www.w3.org/policies/process/#decision-types). Different cases will involve different combinations of these factors. In determining whether to approve moving work to the Recommendation track, the Team may consider other factors not listed in this document as well. @@ -83,7 +83,7 @@ Is this spec serving a specialized community and only that community needs to im The language in the [Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) describes a one community's practice: -> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. +{% include quote.html content="The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase." %} If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional [W3C Community Group Charter Template](https://github.com/w3c/cg-charter/blob/gh-pages/CGCharter.html) contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point. @@ -128,7 +128,7 @@ It is advisable for groups considering Recommendation Track work to consult with Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see [Team support for CGs](https://www.w3.org/2016/04/cg-support/)), but CG participants are encouraged to reach out to the [W3C staff](http://www.w3.org/People/) well in advance of proposing a transition to the Recommendation Track. -## Process Considerations +## Process Considerations {#process} Discussion about these guidelines has generated a number of questions about how they relate to the W3C process and the Team's existing practices. They are out of scope for this document, but they are listed for reference: @@ -156,7 +156,7 @@ Should the Process Document describe a role for CGs in getting specifications re Raised in the [AC discussions](https://lists.w3.org/Archives/Member/w3c-ac-forum/2016JanMar/0013.html). Should the Process Document do more to describe a role for Interest Groups in developing use cases for new Recommendations, and perhaps working in tandem with one or more Community Groups to develop credible technical proposals to address those use cases? -## Conclusion +## Conclusion {#conclusion} The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: From f29ffb75a91c64cd395cc7cabda265cffeb897d2 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 16:54:43 +0100 Subject: [PATCH 114/225] Rename editors-draft from .html to .md --- editor/{editors-draft.html => editors-draft.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename editor/{editors-draft.html => editors-draft.md} (100%) diff --git a/editor/editors-draft.html b/editor/editors-draft.md similarity index 100% rename from editor/editors-draft.html rename to editor/editors-draft.md From afd52b4187b164ec77af572494c26e617c9274d4 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 17:07:41 +0100 Subject: [PATCH 115/225] Convert editors-draft to markdown --- editor/editors-draft.md | 149 ++++++++-------------------------------- 1 file changed, 28 insertions(+), 121 deletions(-) diff --git a/editor/editors-draft.md b/editor/editors-draft.md index afc94d6f8..1888ef759 100644 --- a/editor/editors-draft.md +++ b/editor/editors-draft.md @@ -1,134 +1,41 @@ - - - - - Style for Group-internal Drafts - - - - - - -
    -

    Also On This Page →

    - -
    +--- +title: Style for Group-internal Drafts +toc: yes +--- - +This document, for W3C groups, reflects some discussion within the Team about how groups can avoid confusion between their internal publications and formal W3C Technical Reports. -

    Status of this Document

    +## Introduction {#intro} -

    This document, for W3C groups, reflects some discussion within the -Team about how groups can avoid confusion between their internal -publications and formal W3C Technical Reports.

    +Many Working Groups publish drafts for internal group review between publications on the TR page. In the interest of clarity of the W3C process, we request that Working Groups take care that documents are labeled with their true status. Sometimes labels like "W3C Working Draft" are copied from documents that are truly a product of the W3C Working Draft process to documents that are not, or at least not yet. -

    Introduction

    +The guidelines below are intended to reduce confusion between group-internal drafts (some of which are Member-only, while others are public) and published documents that have been through additional W3C processes. Documents that follow these guidelines have no formal standing within W3C. -

    Many Working Groups publish drafts for internal group review -between publications on the TR page. In the interest of clarity of the W3C process, we request that -Working Groups take care that documents are labeled with their true -status. Sometimes labels like "W3C Working Draft" are copied from -documents that are truly a product of the W3C Working Draft process to -documents that are not, or at least not yet. -

    +## Requirements for Group-Internal Drafts {#reqs} -

    The guidelines below are intended to reduce confusion between -group-internal drafts (some of which are Member-only, while others are public) and -published documents that have been through additional W3C processes. -Documents that follow these guidelines have no formal standing within -W3C.

    +- In a Working Group, group-internal drafts MUST follow the licensing as defined in its charter. -

    Requirements for Group-Internal Drafts

    +## Guidelines for Group-Internal Drafts {#guidelines} -
      -
    • In a Working Group, group-internal drafts MUST follow -the licensing as defined in its charter.
    • -
    +1. Use this style sheet: ***`https://www.w3.org/StyleSheets/TR/2021/W3C-ED.css`*** +2. Use an appropriate label for the document, as in: + + ``` +

    Architecture of the World Wide Web, + Volume One

    +

    Editor's Draft 15 December 2004

    + ``` +3. When the document is "Member-confidential", indicate this in an obvious place at the top of the document. Please also include a reminder in the status section. +4. Set expectations about the stability and level of confidentiality of the document in the status section, for example: + + > We welcome feedback on this informal collection of resources, which is subject to change without notice. -

    Guidelines for Group-Internal Drafts

    +## Frequently Asked Questions (FAQs) {#faq} -
      -
    1. Use this style sheet: https://www.w3.org/StyleSheets/TR/2021/W3C-ED.css
    2. -
    3. Use an appropriate label for the document, as in: -
      - <h1>Architecture of the World Wide Web, 
      -           Volume One</h1>
      - <h2>Editor's Draft 15 December 2004</h2>
      -
      -
    4. -
    5. When the document is "Member-confidential", indicate -this in an obvious place -at the top of the document. Please also include a reminder -in the status section. -
    6. -
    7. Set expectations about the stability and level of confidentiality of the document in the status section, for example: -
      -We welcome feedback on this informal collection of resources, -which is subject to change without notice. -
      -
    8. -
    +### 1. Can our group publish this type of document elsewhere than w3.org? -

    Frequently Asked Questions (FAQs)

    +In general, no (but see [Issue #110](https://github.com/w3c/modern-tooling/issues/110)). Please avoid giving the impression that these drafts have formal status within W3C or another body. Please do not label them "W3C Working Draft" in these documents. -

    1. Can our group publish this type of document elsewhere than w3.org?

    - - -

    In general, no (but see Issue #110). Please avoid giving the impression that these drafts have formal status within W3C or another body. Please do not label them "W3C Working Draft" in these documents.

    - -

    If you are just attaching a copy of an in-progress draft in email -in preparation for a group teleconference, keep in mind that the -attachment is archived and may be found by readers who don't have that -context. Please erase any indication that this is a W3C Working Draft.

    - -
    -

    Feedback is to @w3c/tilt - and is welcome on GitHub

    - - - +If you are just attaching a copy of an in-progress draft in email in preparation for a group teleconference, keep in mind that the attachment is archived and may be found by readers who don't have that context. Please erase any indication that this is a W3C Working Draft. \ No newline at end of file From e48283093037890bb08af9f68aca8b4e0a654c92 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 17:13:11 +0100 Subject: [PATCH 116/225] typo --- editor/role.md | 1 + 1 file changed, 1 insertion(+) diff --git a/editor/role.md b/editor/role.md index 49d4c38ab..335679c6e 100644 --- a/editor/role.md +++ b/editor/role.md @@ -2,6 +2,7 @@ title: W3C Specification Editor toc: false --- + The role of the editor is not that of author. They maintain the text of a current draft that the Group has agreed to and possibly to suggest concrete wording when none is forthcoming from the group. Specification editors are [appointed by the Group Chair](../chair/role.html). From b927fce51a0315352979e3888c06129e0275e984 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 17:18:32 +0100 Subject: [PATCH 117/225] adapt resources.md to the jekyll template, keep only one

    and change the header levels --- editor/resources.md | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/editor/resources.md b/editor/resources.md index 66f8c3f10..56feeec6c 100644 --- a/editor/resources.md +++ b/editor/resources.md @@ -1,6 +1,9 @@ -# Onboarding Information for Editors +--- +title: Onboarding Information for Editors +toc: true +--- -# Group Specific Information +## Group Specific Information * Your group's Email list and its archive * Your group's WebEx coordinate for group calls * Your group's IRC channel @@ -11,20 +14,20 @@ * How to identify/get group specific information? * Maybe we could use a table to specify group specific resources, e.g., group pages, wikis, ML, WebEx coordinate, IRC, and GitHub repo. -# General Information +## General Information -## List of the W3C groups +### List of the W3C groups * [Working Groups](https://www.w3.org/groups/wg/) * [Interest Groups](https://www.w3.org/groups/ig/) * [Business Groups/Community Groups](https://www.w3.org/community/groups/) -## How to join/leave the group +### How to join/leave the group * [Create your W3C account first](https://www.w3.org/accounts/request) * Ask your AC to join W3C groups and nominate you as a group participant: * Use the 'Join' button in [Working Groups/Interest Groups](https://www.w3.org/groups/) pages * [Business Groups/Community Groups](https://www.w3.org/community/groups/) -## Emails +### Emails * Email archives: * [Public lists](https://lists.w3.org/) * [Member lists](https://lists.w3.org/Archives/Member/) @@ -32,7 +35,7 @@ * [Mailing list guide](https://www.w3.org/Mail/) * [Mailinglist subscription](https://www.w3.org/Mail/Request) -## Teleconfs +### Teleconfs * Zoom: * [Zoom](https://www.w3.org/Guide/meetings/zoom) * Minutes taking by IRC: @@ -40,17 +43,17 @@ * [Zakim HOWTO](https://www.w3.org/2001/12/zakim-irc-bot.html) * [RRSAGent HOWTO](https://www.w3.org/2002/03/RRSAgent) -## Meetings +### Meetings * [W3C Member meetings](https://www.w3.org/events/) * [TPAC (Technical Plenary and Advisory Committee Meetings)](https://www.w3.org/events/tpac/) * [AC Meeting (Advisory Committee meeting)](https://www.w3.org/events/ac/) -## GitHub +### GitHub * Initial instructions for GitHub beginners: * [W3C Specs on GitHub](https://w3c.github.io/specs.html) * [W3C Tools Support Wiki](https://www.w3.org/2006/tools/wiki/Github) -## For Editor's role +### For Editor's role * Tools for spec editing: * [Markdown](https://github.github.com/gfm/) * [Respec](https://github.com/speced/respec/wiki/format) @@ -60,10 +63,10 @@ * [Pubrules](https://www.w3.org/pubrules/) * [Automatic publication tool (Echidna)](https://labs.w3.org/echidna/) -## Patent Policy (especially for WGs) +### Patent Policy (especially for WGs) * [W3C Patent Policy](https://www.w3.org/policies/patent-policy/) * [Patent Policy FAQ](https://www.w3.org/2003/12/22-pp-faq.html) -# Learn more +## Learn more * [/Guide](https://www.w3.org/Guide/) From 4d40a14c9c6c32283119bd7a9d257b95a9217fc2 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 17:20:57 +0100 Subject: [PATCH 118/225] Rename editor/index from .html to .md --- editor/{index.html => index.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename editor/{index.html => index.md} (100%) diff --git a/editor/index.html b/editor/index.md similarity index 100% rename from editor/index.html rename to editor/index.md From c5adb299b1d1641e82538a664c0498ee58cbc9b7 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 17:37:58 +0100 Subject: [PATCH 119/225] Convert editor/index to markdown --- editor/index.md | 197 +++++++++++++++++------------------------------- 1 file changed, 71 insertions(+), 126 deletions(-) diff --git a/editor/index.md b/editor/index.md index afa472ed1..16c6b4aa4 100644 --- a/editor/index.md +++ b/editor/index.md @@ -1,126 +1,71 @@ - - - - - W3C Editors' Home Page - - - - - - -
    -

    Also On This Page → 

    - -
    - -
    -

    - Introduction -

    -

    One of the main accomplishments at W3C is to write specifications and create standards out of them. While the Working Groups at large are responsible for building consensus on the technical decisions, the editors have the heavy responsibility of transforming these decisions into actual specifications.

    -

    This page tries to gather resources that can help editors do their job: documentation, tools, tutorials, etc. If you know other resources that would benefit editors by being listed here, please inform the W3C Communication Team at w3t-comm@w3.org.

    -

    - Where to start? -

    -

    If you are a newly appointed editor in your Working Group, here is some advice that should be useful to get you started.

    - -

    - Guidelines on W3C specifications editing -

    -

    W3C has developed a set of resources giving advices and guidelines on editing W3C specifications in varous domains:

    - -

    Bert Bos's essay on W3C's design principles and Tim Berners-Lee's essentials of a specification may also be a useful reading.

    -

    During the internal development of a specification, make sure to distinguish official drafts from internal ones using the style for Group-internal Drafts.

    -

    - Grammars -

    -

    W3C editors have developed several types of HTML and XML based grammars to make it easier to develop and maintain their specifications.

    -

    - Authoring tools -

    - -

    - Tools -

    -

    Here are tools that can prove to be useful when developing your specification.

    - -

    Most of these tools can be quickly accessed using the so called ,tools interface: appending ,keyword to a www.w3.org URI triggers a certain tool on this URI; for instance, appending ,validate to this page's URI will send it to the HTML validator.

    -

    - Central JavaScript repository -

    -

    Specifications should, of course, be device-independent. But, - with care, you can still include certain kinds of scripts. If - the script you want is in W3C's repository of common JavaScript libraries, you're - recommended to link to that repository, rather than make a copy - of the script. (Note that, together with the common style - sheets, these scripts are the only resources that may - be outside the specification's own directory.)

    - -

    There is no documentation for now (except for MathJax).

    -
    -
    -

    Feedback is to @w3c/tilt - and is welcome on GitHub

    - - +--- +title: W3C Editors' Home Page +toc: true +--- + +## Introduction {#intro} + +One of the main accomplishments at W3C is to write specifications and create standards out of them. While the Working Groups at large are responsible for building consensus on the technical decisions, the editors have the heavy responsibility of transforming these decisions into actual specifications. + +This page tries to gather resources that can help editors do their job: documentation, tools, tutorials, etc. If you know other resources that would benefit editors by being listed here, please inform the W3C Communication Team at [w3t-comm@w3.org](mailto:w3t-comm@w3.org). + +## Where to start? {#start} + +If you are a newly appointed editor in your Working Group, here is some advice that should be useful to get you started. + +- Get an [idea of the role of an editor](role.html) at W3C +- Check the most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki) +- Read the [W3C Publication Rules](/pubrules/doc/) (often referred as pubrules) and ask advice on the points that are unclear; if your document doesn't comply with these rules, it cannot be published as a W3C technical report. +- [How to Organize a Recommendation Track Transition](/Guide/transitions) explains the process to get a document published as a technical report. +- The [Pubrules Checker](/pubrules) is a tool that can help you assess whether or not your document complies with pubrules. +- Review [WCAG](/TR/WCAG/) +- All W3C editors are invited to join the [publicly archived mailing list <spec-prod@w3.org>](http://lists.w3.org/Archives/Public/spec-prod/) to share and discuss the techniques and tools used to produce W3C specifications. + +## Guidelines on W3C specifications editing {#quality} + +W3C has developed a set of resources giving advices and guidelines on editing W3C specifications in varous domains: + +- The [W3C Manual of Style](../manual-of-style/) is a collection of rules you're invited to follow to make your document clearer and adapted to the common style at W3C. +- Begun in 1992 and only a little out of date, the [Style Guide for online hypertext](../../Provider/Style/) by Tim Berners-Lee is a good start on writing for the Web; see also Jakob Nielsen's [How Users Read on the Web](http://www.useit.com/alertbox/9710a.html) +- The [QA Framework: Specification Guidelines](../../TR/qaframe-spec/) from the W3C Quality Assurance Activity are a work in progress that became a Candidate Recommendation in November 2003. +- The Team has guidelines for a [style for group-internal drafts](editors-draft.html) to avoid confusion with documents published on the [TR page](/TR). Please also review the related [Working Group Heartbeat Requirement](/policies/process/#revising-wd) of the W3C Process. + +[Bert Bos's essay on W3C's design principles](http://www.w3.org/People/Bos/DesignGuide/introduction) and [Tim Berners-Lee's essentials of a specification](http://www.w3.org/1999/09/specification) may also be a useful reading. + +During the internal development of a specification, make sure to distinguish official drafts from internal ones using the [style for Group-internal Drafts](editors-draft.html). + +## Grammars {#grammars} + +W3C editors have developed several types of HTML and XML based grammars to make it easier to develop and maintain their specifications. + +## Authoring tools {#authoring} + +- Check the most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki) +- [BlueGriffon](http://www.bluegriffon.org/) is a WYSIWYG HTML editor. +- Some [tips and tricks for API architecture design](http://scriptlib-cg.github.com/api-design-cookbook/) +- Some [WhatWG conventions](http://wiki.whatwg.org/wiki/Howto_spec). + +## Tools {#tools} + +Here are tools that can prove to be useful when developing your specification. + +- The [Pubrules Checker](http://www.w3.org/pubrules) provides a convenient interface to check the conformance of a document to pubrules (see [pubrules issues and tracking](http://github.com/w3c/specberus/issues)) +- The [Technical Reports shopping list](http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](http://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](http://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec +- The [TR references checker](/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](/2007/05/ietf-references-checker). +- The [W3C Glossary](/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where +- The [on-line Spell Checker](http://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos; the [W3C on-line Stylistic Checker](/2002/08/diction) helps find the most usual errors identified by the [W3C Manual of Style](/2001/06/manual/) +- [different tools](http://esw.w3.org/topic/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](http://www.w3.org/2007/10/htmldiff) +- The [MarkUp Validator](http://validator.w3.org/) can help you assess whether your documents are valid HTML, MathML or SVG. +- The [CSS Validator](http://jigsaw.w3.org/css-validator/) tells you if your use of CSS is correct. +- The [Link Checker](http://validator.w3.org/checklink) catches all the broken links that may have popped up in your document. +- The [Namespace checker](http://www.w3.org/2003/09/nschecker) finds potential namespaces URIs in the documents, and makes a few checks on them +- [HTML Tidy](http://tidy.sourceforge.net/), originally by Dave Raggett and now maintained at SourceForge.net, is a lint that cleans up but does not validate HTML and XHTML. With indent off, Tidy can sometimes shave 10% or more off file size. + +Most of these tools can be quickly accessed using the so called **[`,tools`](./,tools)** interface: appending **`,keyword`** to a www.w3.org URI triggers a certain tool on this URI; for instance, appending **[`,validate`](,validate)** to this page's URI will send it to the HTML validator. + +## Central JavaScript repository {#javascript} + +Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries,](../../scripts/) you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.) + +There is no documentation for now (except for [MathJax](https://www.w3.org/scripts/MathJax/)). + From f097c24db9a08cff7259bb32b9d7e8a2312bfaf1 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 17:57:55 +0100 Subject: [PATCH 120/225] Rename HOWTO.md --- transitions/{HOWTO.md => howto.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename transitions/{HOWTO.md => howto.md} (100%) diff --git a/transitions/HOWTO.md b/transitions/howto.md similarity index 100% rename from transitions/HOWTO.md rename to transitions/howto.md From 5a86c8e7289cb4e8ea479bc22b15a40956a635bd Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 18 Dec 2024 18:02:43 +0100 Subject: [PATCH 121/225] adapt howto.md to the jekyll template --- transitions/howto.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/transitions/howto.md b/transitions/howto.md index b1b0ff20f..424ae5bf2 100644 --- a/transitions/howto.md +++ b/transitions/howto.md @@ -1,4 +1,7 @@ -# The Fu to edit the transition requirements +--- +title: The Fu to edit the transition requirements +toc: false +--- HTML elements are displayed (or not) based on the user selection. @@ -43,7 +46,7 @@ If the user selected an updated Candidate Recommendation Snapshot (the URL conta To find the possible values for each data attribute, look at the HTML option and input HTML elements in [the document](https://github.com/w3c/transitions/blob/main/index.html#L269). Or, if you're looking for a particular document transition, use the form to select and see the values of the URL parameters. -# New W3C Process +## New W3C Process To add or remove a document status, one must: @@ -56,14 +59,14 @@ If HTML input elements were added or removed: 1. update the config object near the top of the script 1. update the JS functions onpushstate (URL) and titleMatch (attribute matching) -# New Echidna updates +## New Echidna updates For echidna updates: 1. Update data-profile on the ul element with id='echidna-selection" 2. Update the data-echidna as needed (you're likely to add data-echidna="false"') 3. Update the JS function hasEchidna() -# History +## History The transition requirements document is originally based on https://services.w3.org/xslt?xmlfile=https://www.w3.org/2005/08/01-transitions2017.html&xslfile=https://www.w3.org/2005/08/transitions2017.xsl From c80318dc2fccc48b507c074907ad271969ad9749 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 20 Dec 2024 09:52:29 +0100 Subject: [PATCH 122/225] Rename process/predicting-milestones from .html to .md --- process/{predicting-milestones.html => predicting-milestones.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/{predicting-milestones.html => predicting-milestones.md} (100%) diff --git a/process/predicting-milestones.html b/process/predicting-milestones.md similarity index 100% rename from process/predicting-milestones.html rename to process/predicting-milestones.md From a77e29ed87a1592c2b99752747d8130d962209a4 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 20 Dec 2024 09:57:26 +0100 Subject: [PATCH 123/225] Convert process/predicting-milestones to markdown (in progress) --- process/predicting-milestones.md | 838 ++++++++++--------------------- 1 file changed, 266 insertions(+), 572 deletions(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 07b15064a..47bb11755 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -1,583 +1,277 @@ - - - - - Predicting milestones - - - - - - -
    -

    Introduction

    -

    Aims and Scope

    -

    This document is intended to help in predicting milestones for work on - the W3C Standards track. Realistic milestones are important for resource - allocation at the start of new work, and to monitor progress when - rechartering or extending existing work. At the same time, the very - nature of the work means that progress is somewhat unpredictable; delays - can and will occur relative to the predicted schedule.

    -

    Delays are not necessarily a bad thing. For example, delays due to an - unexpectedly large volume of last call comments may improve the - specification or may indicate that what was previously considered a - simple problem is actually more complex. Delays due to incomplete - implementations may indicate that implementers disagree on the meaning - of the specification, or that priorities have shifted away to other - work. So these delays may indicate where the work needs to be improved. - Delay, and a better specification, is usually preferable to a rapidly - produced but poor quality specification that needs to be revised, - substantially reworked, or abandoned and replaced because it was - unsuitable.

    -

    If eventual timescales to Recommendation are unpredictable, should - milestones be abandoned altogether? No. Some indication is needed to - judge the likely scope of the work. What can be done is to - produce realistic initial schedules, based on past experience, - and to clearly communicate the reasons for delays and the lessons - learned from them when adjusting milestones as the work progresses.

    -

    Reading this document

    -

    While the technical work undertaken by W3C is very diverse and hard to - generalize, non-technical aspects such as required review periods - mandated by the Process Document [PROCESS] - or the W3C Patent Policy [W3CPP] - are common to all work. The main focus of this document is therefore on - the required periods of time needed for the non-technical work. - Understanding these avoids producing initial milestones which are - unreasonably short and thus, inevitably destined to 'fail'. Alongside - each of these time periods, tips are given on how to minimize delays.

    -

    This document aims to collect together some of that experience so that - new Chairs, Team Contacts, and Advisory Committee representatives can:

    -
      -
    • Produce charters with realistic initial milestones
    • -
    • Understand how to minimize avoidable delays
    • -
    • Cope with and draw lessons from unpredicted delays
    • -
    • Clearly communicate why and by how much an initial timeline has been - revised as work proceeds.
    • -
    -

    Throughout the document, minimum time durations are documented, styled like this; supported by hints and tips on - avoiding needless delay, styled like this.

    -

    This document is an informal guide to predicting the likely duration of - Recommendation-track work. It is not a normative definition of the - various time periods; for that, follow the links to the Process Document - and the Patent Policy.

    -

    Preparatory work

    -

    The first set of milestones are drawn up before work starts, and put in - an initial charter. In this phase, an idea is firmed up from "hey we - could do this" to a fully fledged, chartered Working Group. If the work - is entirely new, or would take an existing group in a radical new - direction, the Process Document requires - that Advance Notice be sent to the AC. Often, an initial draft charter - is sent along with this notice (but this is not required). The aim here - is to avoid surprises, to quickly gather brainstorming-type feedback, - and to get buy-in on the proposed direction from likely members of the - eventual Working Group.

    -
    -
    Advance Notice
    -
    -

    There is no set period for Advance Notice, but four weeks is a - typical minimum period.

    -
    -
    -
    -
    Advance Notice
    -
    -

    When developing materials for and advance notice, - try to strike a balance between fast (but overly sketchy and vague) - and thorough (but slow, maybe over-detailed or over-constraining).

    -

    If work has been prepared beforehand in a - Community group, or formalizes existing, industry standard - practices, then an Advance Notice might be skipped.

    -
    -
    -

    The results from Advance Notice may indicate broad consensus on the - proposed direction (if so, proceed rapidly to a formal charter review). - Or they may indicate disagreement on the best direction forward (in - which case, iterate). Some commentors may want a fast development of an - initial version, while others may want a fully fledged solution.

    -
    -
    Advance Notice Feedback
    -
    -

    If feedback indicates disagreement on scope, consider - proposing both a fast initial version and a requirements - gathering and drafting item for a full-featured second version. This - will help avoid delays due to disagreements on scope.

    -
    -
    -

    Once broad agreement is reached, a draft charter is created (or - updated, if one was sent with the Advance Notice) and reviewed by W3M - before being sent to the AC.

    -
    -
    W3M review
    -
    -

    There is no set period for W3M review, but two reviewers are needed - and two weeks is a typical minimum period.

    -
    -
    -
    -
    W3M review
    -
    -

    One of the reviewers can be the Domain leader, who - should already be familiar with the proposed work from Team - discussions. This can lead to faster and more thorough review.

    -

    The draft charter must indicate a proposed chair. - Save time by identifying likely chairs during the Advance Notice - period.

    -

    If one or two likely implementors have - been identified during Advance Notice, communicate this to W3M so - that they can see that the proposed work has developer backing.

    -

    Clearly distinguish in the charter between Groups - with a formal dependency, and other related groups. This distinction - will be important during Candidate Recommendation. -

    -
    -
    -

    Once review comments from W3M have been incorporated into the charter, - it is sent - to the AC for review.

    -
    -
    AC review
    -
    -

    There is no set period for AC review, but four weeks is a typical - minimum period followed by two to four weeks to incorporate feedback - and to make the decision to charter the proposed Working Group.

    -
    -
    -
    -
    AC review
    -
    -

    Respond to each review comment as it arrives, - rather than waiting for the review period to end. Others may have - similar concerns, so addressing them early avoids needless repeat - comments.

    -

    Keep the proposed charter unchanged (so the AC - has a stable document to review) but make a copy at a different - location and incorporate comments (so commentors can see the - resolution of their issues in-place).

    -

    Talk to likely implementers during AC - review and try to gauge the level of interest.

    -
    -
    -

    Starting the Group

    -

    Once the decision to start the Working Group has been communicated to - the AC, participants can join. This may take some time, particularly if - participants need to perform a legal review of the work items (for - example, to review their patent portfolio in light of the W3C - Royalty-Free commitment). In the case of a new group, some or all - of the participants may be unfamiliar with W3C processes, tools (such as - IRC, phone conferencing, issue tracking, version control). The Chair and - Staff Contact take a lead role in getting a new group up to productive - speed.

    -
    -
    WG startup
    -
    -

    There is no set period until a Group starts to become productive. - Experienced participants with a capable Chair and Team Contact, - working on a new version of an existing specification can be - productive immediately. A new group with participants new to W3C, - working in a new area which is rife with Intellectual property - concerns, may take several months to become productive.

    -
    -
    -
    -
    WG startup
    -
    -

    Make a diff document of the final charter, - compared to the one sent for AC review. Legal review can focus on - just what has changed.

    -

    As soon as the decision is made to charter the - group, set up the usual infrastructure (public web page, archived - mailing lists(s), wiki, issue and action tracker) so that - participants are not kept waiting and so that they become used to - the way of working.

    -

    Establish a day and time for a first telephone call - (based on the geographic location of the participants) to get people - introduced and up to speed. Do not expect to accomplish any - technical work at first.

    -

    Identify likely editors early.

    -

    Ensure that participants are familiar with the action - tracking as soon as possible.

    -
    -

    Establish a system for recording and tracking actionable - comments on the specification. That system might be:

    -
      -
    • an open mechanism, such as the - the W3C GitHub - (which would enable commenters to submit comments on the - specification directly into the tracking system directly themselves)
    • -
    • a moderated mechanism, such as GitHub issues - (which would enable the working-group to control which comments - actually get entered into the system as issues for the group)
    • -
    • some combination of open and moderated mechanisms; for - example, using the W3C Bugzilla service for first-level - comment tracking, with the editor responsible for resolving - comments, and using the W3C Tracker tool for comments that - have been “escalated” for resolution by the working group as a whole.
    • -
    -

    Use the tracking system at all phases of the life cycle of the - specification. An advantage of setting up such a tracking system early and - using it as part of the working group’s normal operating - procedures is that the same system can later also be used during - Candidate Recommendation, for tracking Candidate Recommendation comments. So it can help the - working group to proceed through Candidate Recommendation more quickly—because - by the time the specification reaches Candidate Recommendation, the working - group will already have long experience and familiarity with - using a system for recording and tracking comments, and will save the - start-up time they would otherwise need to spend during Candidate Recommendation to get - accustomed to using a new and unfamiliar comment-tracking system for the - first time.

    -
    -
    -
    -

    A face to face meeting can be a helpful way to build social bonds and - to start off new work. For a newly chartered group, there is a minimum - notice period for a first meeting.

    -
    -
    First f2f meeting
    -
    -

    There is a set minimum period of eight - weeks for announcement of a face to face meeting.

    -
    -
    -
    -
    First f2f meeting
    -
    -

    Propose a date and location of the first - meeting, in the materials sent for AC review. This gives more - notice, and allows the mandatory notice period to overlap with the - AC review period.

    -

    Allow sufficient time for group members to organize - travel and obtain legal review before the first f2f meeting.

    -
    -
    -

    First Public Working Draft

    -

    The First Public Working Draft is an important milestone. It makes - concrete the proposed work. It is an opportunity to publicize the work - of the Group. This is also a legal milestone; FPWD triggers a patent - exclusion period for all features that are in that document. Features added - afterwards are not covered until the work progresses to a Last - Call. There is therefore a balance to be struck between speed and - feature completeness (at least an outline of the features; details of - syntax and specification for a given feature can be altered later).

    -
    -
    Exclusion period for FPWD
    -
    -

    Announcement of an open exclusion period, immediately after - publication of FPWD, triggers an exlusion - period of 150 days.

    -
    -
    -
    -
    Exclusion period for FPWD
    -
    -

    You don't have to wait for an exclusion - period to end before moving to the next stage in the Rec track. - Exclusion periods can overlap.

    -
    -
    -

    Test suites

    -

    The W3C Process does not require tests to be available until exiting - Candidate Recommendation. Leaving testing until it is the only thing - left holding you back from Proposed Recommendation is, however, unwise. - Tests give implementers something to work with, and provide examples for - those reviewing the specification. Tests help make concrete the - sometimes abstract language of a specification. Tests can show where - reasonable interpretations of the same specification text could lead to - divergent and non-interoperable implementations.

    -
    -
    Early testing
    -
    -

    Start writing tests when you start writing the - specification.

    -

    Just as you have one or more specification - editors, consider having one or more test suite editors to drive - testing

    -

    Generate implementation reports early, even if - they are very incomplete. Sections of the specification that - everyone is avoiding become clear (and you can examine why this is - so). Also, peer pressure to outperform competing implementations is - a wonderful thing.

    -
    -
    -

    Getting to Candidate Recommendation

    -

    Once all open issues are closed (or deferred to the next version) and - the group believes the document is stable enough for wide review, a Working Draft can be published for wide review. Other Groups, expecially those with - formal dependencies, are invired to review. External Groups with whom - the Working group has an ongoing liaison should also be invited to - review.

    -
    -
    Wide Review Duration
    -
    -

    The minimum duration for the Wide Review comment period should be 4 weeks.

    -
    -
    -
    -
    Wide Review Duration
    -
    -

    'Horizontal' groups that review many - specifications (for example, WAI P&F and I18n Core) may, because - of their workload, need longer than the minimum period.

    -

    Discuss Candidate Recommendation duration with the Chairs - and Team contacts of groups that you expect to provide comments, before - Candidate Recommendation is announced.

    -

    Bear in mind that external groups invited to - review will have different processes to W3C. For example, they may - only meet periodically. Be aware of their schedule before going to - Candidate Recommendation.

    -

    Bear in mind the impact of vacation periods on Last - Call duration. People won't comment if they are on vacation and will - complain if they were unable to comment.

    -

    Explain why your document is relevant to - each Group invited to review. If a particular section is especially - relevant, call it out explicitly and give an explanation. Groups - which do not understand why they are asked to review a document may - be slow to respond.

    -

    There can be more than one wide review draft. If the - document has changed substantially, in particular, if new features - have been added, a new wide review will be needed.

    -
    -
    -

    If your specification defines one or more new Internet Media Types - (previously called "MIME types"), put a draft registration of these - types in an appendix, and send (the plain text of) this for ietf-types - review at wide review

    -

    Processing Wide Review

    -

    Each Candidate Recommendation review comment must be documented, the changes made (if - any) and rationale for the change documented, and the agreement or - disagreement of the reviewer to the change also documented.

    -
    -
    Processing Wide Review comments
    -
    -

    There is no minimum duration for responding to wide review comments.

    -
    -
    -
    -
    Processing Wide Review comments
    -
    -

    Deal with comments as they come in, rather than - waiting until the end of the wide review period. Besides saving time, - this can also avoid duplicate comments.

    -

    Maintain a draft Disposition of Comments. This allows - commentors to see that their comment has been received and what the - status of the response is. It also allows the Working Group to track - the overall progress of the review. The Disposition of Comments will - be needed during transition to CR.

    -

    Keep an Editors Draft up-to-date with changes made as a - result of wide review comments, so that commentors can see the changes - in place. This speeds sign-off on the changes.

    -

    If a Group is expected to comment and has not done so, ask if they - need more time. This encourages them to either make their comments - on time, or ask for an extension of known duration. Also ask that, - if they have no comments, they send an explicit 'no comments' - message. This helps 'show wide review' in the following Transition - call, and differentiates groups whose review is complete from groups - which are late.

    -

    If review comments are vague, ask for clarification or - for concrete specification text which would satisfy the comment.

    -

    If review comments are overly ambitious and would - exceed the planned scope of the current specification, ask if they - can be deferred to the next version.

    -

    If a reviewer and the Working Group cannot reach - agreement on a proposed change, give the reviewer a choice of - accepting the change anyway ('can live with it') or filing a formal - objection.

    -

    If changes are made in response to a comment and - the reviewer does not react to repeated requests for confirmation - that the changes are acceptable, send a final reminder stating that - failure to respond by a given date will be taken as a sign that the - changes are acceptable. Document the number of reminders sent and - their dates, then move on.

    -
    -
    -

    Transition to CR

    -

    Once the Disposition of Comments shows that all wide review - comments have been handled, your Group can request a transition to - Candidate Recommendation. At that meeting, besides checking the - responses and looking for outstanding disagreement, you will be asked - which features - are at risk, what the CR exit criteria are, and to give a mimimum - time for CR. The purpose of that minimum time is to allow other - implementers, perhaps unknown to the group, to contribute their - implementation feedback.

    -

    Although having a Test Suite and an Implementation report at this stage - is not required, it is highly recommended. Firstly, if the report shows - implementation of each feature by at least two independent - implementations, it is possible to exit CR quickly (a Call for Exclusion might delay a bit). Secondly, an early Implementation report helps to - identify features which are currently not well implemented so that the - Group can discuss whether these features need to be marked as 'at risk'.

    -

    This section assumes that the earlier tips were followed and you have a - test suite.

    - -
    -
    CR Duration
    -
    -

    There is a minimum duration of 28 days for comments for CR. Two - months is a more typical figure. For follow-on CR publications, two weeks - is a realistic minimum.

    -
    -
    -
    -
    CR Duration
    -
    -

    Historically, the time taken to exit CR varied from - zero (rare) to many years, largely due to the absence of test suites - sufficiently early in the process.

    -

    By the time a Group is ready to enter - CR, it should be possible to estimate with more confidence the - likely duration, provided there is an existing Test Suite and draft - implementation Report, and provided the Group is able to gauge the - momentum of implementers.

    -

    If there is no test suite when entering CR, the - likely duration cannot be accurately estimated.

    -
    -
    -

    Publication of a Candidate Recommendation triggers an Exclusion period on all features - which were not in the previous First Public Working Draft (or previous - Candidate Recommendation, if there was one).

    -
    -
    Exclusion period for Candidate Recommendation
    -
    -

    Announcement of an open exclusion period, immediately after - publication of Candidate Recommendation, triggers an exclusion period of 60 - days.

    -
    -
    -
    -
    Exclusion period for Candidate Recommendation
    -
    -

    Exclusion periods can overlap. Check whether - the exclusion period for FPWD is still open.

    -
    -
    -

    Leaving CR

    -

    Exiting the Candidate Recommendation phase can be triggered by:

    -
      -
    1. meeting the CR exit criteria (which leads to Proposed - Recommendation), or
    2. -
    3. dropping features which were not marked as 'at risk', or adding new - features as a result of implementer feedback (which leads to another - Candidate Recommendation).
    4. -
    -
    -
    Post-CR Candidate Recommendation Duration
    -
    -

    The minimum duration for the Candidate Recommendation comment period is 28 days.

    -

    Announcement of an open exclusion period, immediately after - publication of Candidate Recommendation, triggers an exclusion period of 60 days.

    -
    -
    -
    -
    Avoiding or minimizing repeating CR publications
    -
    -

    Identify likely 'at risk' features by looking at - implementation reports before entering CR.

    -

    If in doubt, leave a feature in the spec - and mark it 'at risk'. You can drop it without having another LC. - Adding it back in afterwards, however, or dropping it without having - identified it as 'at risk', triggers another Candidate Recommendation.

    -

    If a new CR is needed, limit the scope of - comments to the removed or added features. State that, due to the - maturity of existing implementations, all new feature requests will - be deferred to the next version.

    -

    In practice, it is common to get no comments - in such a late CR, because the implementers already agreed to - drop/add whatever feature triggered the new CR. However, other - implementers or dependent groups may have other ideas on the - changes.

    -
    -
    -

    Proposed Recommendation

    -

    Following a successful transition call where the CR exit criteria were - demonstrated to have been met, the next stage is Proposed - Recommendation. This review period is not expected to raise substantive - technical issues.

    -
    -
    PR Duration
    -
    -

    The minimum duration for the PR review period is four - weeks, followed by two weeks for a W3C's decision. If the - review period spans the July/August or December holiday periods, - more time is typically added.

    -
    -
    -
    -
    Minimising delay during PR
    -
    -

    Personally contact the AC representative for each - organization on the group (cc'ing the Group member) to remind them - of the review.

    -

    Prepare an Editors Draft Recommendation, taking a copy - of the PR document, and incorporate any changes (assumed editorial, - such as out-of-date references, grammatical errors, and rewording of - ambiguous paragraphs) that happen as a result of AC review.

    -

    If the group decides to produce a Press release to - accompany the Recommendation, start work on this at the PR - transition (or earlier). This allows time for testimonials to be - approved and for the release itself to be translated into other - languages.

    -

    Schedule the anticipated publication date of the - final Recommendation with the Comm Team (especially if there will be - press activity) and the webmaster.

    -
    -
    -

    Recommendation

    -

    Congratulations. Now start collecting errata - for the Recommendation, and working on v.next.

    -

    Dealing with the calendar

    -

    The calendar and publication moratorium may get in the way of predicting precise milestones. Use our milestones calculator to help with dates.

    -
    -
    -
    Chris Lilley
    - $Id: predicting-milestones.html,v 1.4 2012/01/30 20:49:40 clilley Exp - $
    - - + From 0eb3e9f2bb07ed7d8b03f258bd5df24f44cec360 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 20 Dec 2024 10:10:29 +0100 Subject: [PATCH 124/225] Rename incubation from .html to .md --- incubation.html => incubation.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename incubation.html => incubation.md (100%) diff --git a/incubation.html b/incubation.md similarity index 100% rename from incubation.html rename to incubation.md From 8627e39ab2e81cf8cf00bdf759c19decd27ab5bb Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 20 Dec 2024 10:27:22 +0100 Subject: [PATCH 125/225] Convert incubation to markdown --- incubation.md | 312 +++++++++++++------------------------------------- 1 file changed, 81 insertions(+), 231 deletions(-) diff --git a/incubation.md b/incubation.md index 45c8adca5..0b099e7eb 100644 --- a/incubation.md +++ b/incubation.md @@ -1,231 +1,81 @@ - - - - - - Incubation - - - - - - - - -
    -

    On This Page → 

    -
      - -
    -
    - -
    -
    -

    Purpose

    -

    Incubation is a way of exploring - some new aspect of the Open Web Platform - when the best way forward is unclear, - when feasibility, compatibility, or developer interest is not yet established, - or when early development would benefit from a wide variety of informed points of view - before Standards-track work commences. -

    -

    It enables exploration of novel work, - without overly diffusing the effort of a Working Group - or expending a lot of resources on work that is ultimately abandoned. -

    -

    - One possible result of incubation is the transfer of work - to a Working Group, for Standards-track development. Work might also be forwarded to another group in liaison with W3C. - Another possible result is the conclusion - that this is a promising area of work, but that a number of prerequisites exist - which should be solved first. - Finally, incubators might conclude that - no Standards-track work should be done in the area. - This is still a valuable result, - as it can reduce the effort expended on unfruitful options. -

    -
    -
    -

    Venues for incubation

    -

    Incubation can be done in several places; - the correct choice depends very much on such factors as:

    -
      -
    • the specific work area
    • -
    • the existence of already established communities, at W3C or elsewhere
    • -
    • the estimated likelihood of success
    • -
    • developer interest
    • -
    • desirability of early IP protection
    • -
    -
    -

    Web Platform Incubator Community Group (WICG)

    -

    Established specifically to incubate potential new work - for the Open Web Platform, - this venue has the merit of a large critical mass of knowledgeable developers. - A huge number of proposals pass through WICG. - This has the benefit that it is very easy to suggest a new one, - and the drawback that a particular proposal may easily be overlooked - unless effort is made to socialize the benefits and encourage review and comment. -

    -

    Mature proposals are made and tracked on the - WICG Proposals Repo, - while early explorations and less formed ideas should start on - Discourse. -

    -

    -
    -
    -

    A Community Group

    -

    Starting a new, topic-specific Community Group - is a little more effort than proposing an idea to WICG - but can have the advantage of review by - a more focused group of people with shared interests - or topic-specific knowledge. - It is a good option when one or more external communities already exist, - but are not necessarily made up of W3C Members. - -

    -

    There is a list of existing CGs. - Check whether a suitable one already exists before creating a new one.

    -

    An emerging pattern is, when chartering a Working Group, - to use a CG to handle incubation for topics related tothe Working Group. - Regular joint meetings between WG and the associated CG - provide opportunities for progress reports - demonstrations, - and discussions on moving particular items to the WG. - Note: depending on the chartered scope of the WG, - adding a new Standards-track work item may require rechartering the WG. -

    -

    -
    -
    -

    Member Submission

    -

    If work has already been explored by one or more W3C Members, - a Member Submission can be an effective way to bring the work to wider review. - Like other incubation methods, a Submission is not a guarantee that - Standards-track work will take place in the area. - The likelihood of success is increased if there is already developer interest, - and if royalty-free commitments to known patents are made along with the submission. - -

    -

    -
    -
    -

    W3C Workshop

    -

    A W3C Workshop can be a good way - to bring a new community together and, - if consensus is reached on some new area, - the workshop report may suggest next steps - including creation of a CG, or even - passing the work to a new or existing Working Group. -

    -
    -
    -

    A Working Group

    -

    In some cases, incubation - can be done directly in a Working Group. - For best results, - the chartered scope should be broad enough to permit this, - the proposed work should be closely related to existing work items, - and the chairs should ensure that discussion on incubated work - does not interfere with progress on Standards-track items. - For example, a separate call or a separate GitHub repo, - or use of GitHub issues and labels, - can keep the incubation and Standards-track items somewhat separate. -

    -

    - If the community of interest is wider than the existing WG, - a tandem CG is probably a better choice. -

    -
    -
    -
    -

    Getting Review

    -

    - Early review of a new proposal is crucial to success - (whether success means further development, - or early identification of unsuitable areas of work which should be dropped). -

    -
    -

    Create an Explainer

    -

    - Since the incubated work is by definition novel, - it is important to explain what it is, - what benefits it would bring, - and how it would fit in with the rest of the Open Web Platform. - This is the job of an explainer document. - A good explainer balances conciseness with detail, - has many examples, - and ideally links to a prototype of the proposed work. - -

    -
    -
    -

    TAG review

    -

    Once some discussion has taken place, - and an explainer exists, - and the proposed work is agreed to be promising, - then before moving the work to a Working Group, - it is good practice to request review by the Technical Architecture Group (TAG). - -

    -
    -
    - -
    -

    Next Steps

    -

    - If it is concluded that work should not be further developed, - update the explainer to document that fact - and list the reasons that development ceased. - This will help people in the future who may have the same or similar ideas; - perhaps some of the factors (such as developer interest) change in the future. -

    -

    TODO

    -
      -
    • IPR commitments
    • -
    • deciding to stop work
    • -
    • liaison with external groups
    • -
    • when to do early horizontal review
    • -
    • prototyping, extensibility points
    • -
    • splitting work into current and future versions
    • -
    -
    - -
    -
    -

    Feedback is to @w3c/guidebook - and is welcome on GitHub

    +--- +title: Incubation +toc: yes +--- + +## Purpose + +Incubation is a way of exploring some new aspect of the Open Web Platform when the best way forward is unclear, when feasibility, compatibility, or developer interest is not yet established, or when early development would benefit from a wide variety of informed points of view before Standards-track work commences. + +It enables exploration of novel work, without overly diffusing the effort of a Working Group or expending a lot of resources on work that is ultimately abandoned. + +One possible result of incubation is the [transfer of work to a Working Group, for Standards-track development](process/cg-transition.html). Work might also be forwarded to another group in liaison with W3C. Another possible result is the conclusion that this is a promising area of work, but that a number of prerequisites exist which should be solved first. Finally, incubators might conclude that no Standards-track work should be done in the area. This is still a valuable result, as it can reduce the effort expended on unfruitful options. + +## Venues for incubation + +Incubation can be done in several places; the correct choice depends very much on such factors as: + +- the specific work area +- the existence of already established communities, at W3C or elsewhere +- the estimated likelihood of success +- developer interest +- desirability of early IP protection + +### Web Platform Incubator Community Group ([WICG](https://www.w3.org/community/wicg/)) + +Established specifically to incubate potential new work for the Open Web Platform, this venue has the merit of a large critical mass of knowledgeable developers. A huge number of proposals pass through WICG. This has the benefit that it is very easy to suggest a new one, and the drawback that a particular proposal may easily be overlooked unless effort is made to socialize the benefits and encourage review and comment. + +Mature proposals are made and tracked on the [WICG Proposals Repo](https://github.com/WICG/proposals), while early explorations and less formed ideas should start on [Discourse](https://discourse.wicg.io/). + +[Join WICG](https://www.w3.org/community/wicg/join) + +### A Community Group + +Starting a new, topic-specific Community Group is a little more effort than proposing an idea to WICG but can have the advantage of review by a more focused group of people with shared interests or topic-specific knowledge. It is a good option when one or more external communities already exist, but are not necessarily made up of W3C Members. + +There is a [list of existing CGs](https://www.w3.org/community/groups/). Check whether a suitable one already exists before creating a new one. + +An emerging pattern is, when chartering a Working Group, to use a CG to handle incubation for topics related tothe Working Group. Regular joint meetings between WG and the associated CG provide opportunities for progress reports demonstrations, and discussions on moving particular items to the WG. *Note:* depending on the chartered scope of the WG, adding a new Standards-track work item may require rechartering the WG. + +[Propose a new CG](https://www.w3.org/community/groups/propose_cg/) + +### Member Submission + +If work has already been explored by one or more W3C Members, a Member Submission can be an effective way to bring the work to wider review. Like other incubation methods, a Submission is not a guarantee that Standards-track work will take place in the area. The likelihood of success is increased if there is already developer interest, and if royalty-free commitments to known patents are made along with the submission. + +[Member Submission Process](/policies/process/#Submission) + +### W3C Workshop + +A [W3C Workshop](meetings/workshops.html) can be a good way to bring a new community together and, if consensus is reached on some new area, the workshop report may suggest next steps including creation of a CG, or even passing the work to a new or existing Working Group. + +### A Working Group + +In some cases, incubation can be done directly in a Working Group. For best results, the chartered scope should be broad enough to permit this, the proposed work should be closely related to existing work items, and the chairs should ensure that discussion on incubated work does not interfere with progress on Standards-track items. For example, a separate call or a separate GitHub repo, or use of GitHub issues and labels, can keep the incubation and Standards-track items somewhat separate. + +If the community of interest is wider than the existing WG, a tandem CG is probably a better choice. + +## Getting Review + +Early review of a new proposal is crucial to success (whether success means further development, or early identification of unsuitable areas of work which should be dropped). + +### Create an Explainer + +Since the incubated work is by definition novel, it is important to explain what it is, what benefits it would bring, and how it would fit in with the rest of the Open Web Platform. This is the job of an [explainer](https://tag.w3.org/explainers/) document. A good explainer balances conciseness with detail, has many examples, and ideally links to a prototype of the proposed work. + +### TAG review + +Once some discussion has taken place, and an explainer exists, and the proposed work is agreed to be promising, then before moving the work to a Working Group, it is good practice to [request review by the Technical Architecture Group (TAG)](https://github.com/w3ctag/design-reviews). + +## Next Steps + +If it is concluded that work should *not* be further developed, update the explainer to document that fact and list the reasons that development ceased. This will help people in the future who may have the same or similar ideas; perhaps some of the factors (such as developer interest) change in the future. + +TODO + +- IPR commitments +- deciding to stop work +- liaison with external groups +- when to do early horizontal review +- prototyping, extensibility points +- splitting work into current and future versions From ae774f385cebcd6053130d53b4b9fda6938c029c Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 20 Dec 2024 11:43:05 +0100 Subject: [PATCH 126/225] Add classes and style to differentiate "Time" and "Tips" --- process/predicting-milestones.md | 148 ++++++++++++++++++++----------- 1 file changed, 98 insertions(+), 50 deletions(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 47bb11755..0b0a6bf48 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -26,7 +26,13 @@ This document aims to collect together some of that experience so that new Chair - Cope with and draw lessons from unpredicted delays - Clearly communicate why and by how much an initial timeline has been revised as work proceeds. -Throughout the document, minimum time durations are documented, styled like this; supported by hints and tips on avoiding needless delay, styled like this. +Throughout the document, minimum **time durations** are documented, +> styled like this +{:.time} + +and supported by **hints and tips** on avoiding needless delay, +> styled like this. +{:.tip} This document is an informal guide to predicting the likely duration of Recommendation-track work. It is not a normative definition of the various time periods; for that, follow the links to the Process Document and the Patent Policy. @@ -55,106 +61,132 @@ Advance Notice Feedback Once broad agreement is reached, a draft charter is created (or updated, if one was sent with the Advance Notice) and reviewed by W3M before being sent to the AC. +> W3M review : There is no set period for W3M review, but two reviewers are needed and two weeks is a typical minimum period. +{:.time} +> W3M review : One of the reviewers can be the Domain leader, who should already be familiar with the proposed work from Team discussions. This can lead to faster and more thorough review. - +> The draft charter must indicate a proposed chair. Save time by identifying likely chairs during the Advance Notice period. - +> If one or two likely implementors have been identified during Advance Notice, communicate this to W3M so that they can see that the proposed work has developer backing. - +> Clearly distinguish in the charter between Groups with a formal dependency, and other related groups. This distinction will be important during Candidate Recommendation. - +{:.tip} + Once review comments from W3M have been incorporated into the charter, it is [sent to the AC for review](/policies/process/#CharterReview). +> AC review : There is no set period for AC review, but four weeks is a typical minimum period followed by two to four weeks to incorporate feedback and to make the decision to charter the proposed Working Group. +{:.time} +> AC review : Respond to each review comment as it arrives, rather than waiting for the review period to end. Others may have similar concerns, so addressing them early avoids needless repeat comments. - +> Keep the proposed charter unchanged (so the AC has a stable document to review) but make a copy at a different location and incorporate comments (so commentors can see the resolution of their issues in-place). - +> Talk to likely implementers during AC review and try to gauge the level of interest. +{:.tip} ## Starting the Group {#wg-startup} Once the decision to start the Working Group has been communicated to the AC, participants can join. This may take some time, particularly if participants need to perform a legal review of the work items (for example, to review their patent portfolio in light of the [W3C Royalty-Free commitment](/policies/patent-policy/#sec-Requirements)). In the case of a new group, some or all of the participants may be unfamiliar with W3C processes, tools (such as IRC, phone conferencing, issue tracking, version control). The Chair and Staff Contact take a lead role in getting a new group up to productive speed. +> WG startup : There is no set period until a Group starts to become productive. Experienced participants with a capable Chair and Team Contact, working on a new version of an existing specification can be productive immediately. A new group with participants new to W3C, working in a new area which is rife with Intellectual property concerns, may take several months to become productive. +{:.time} +> WG startup : Make a diff document of the final charter, compared to the one sent for AC review. Legal review can focus on just what has changed. - +> As soon as the decision is made to charter the group, set up the usual infrastructure (public web page, archived mailing lists(s), wiki, issue and action tracker) so that participants are not kept waiting and so that they become used to the way of working. - +> Establish a day and time for a first telephone call (based on the geographic location of the participants) to get people introduced and up to speed. Do not expect to accomplish any technical work at first. - +> Identify likely editors early. - +> Ensure that participants are familiar with the action tracking as soon as possible. - +> Establish a system for recording and tracking actionable comments on the specification. That system might be: - +> - an open mechanism, such as the [the W3C GitHub](https://github.com/w3c) (which would enable commenters to submit comments on the specification directly into the tracking system directly themselves) - a moderated mechanism, such as GitHub issues (which would enable the working-group to control which comments actually get entered into the system as issues for the group) - some combination of open and moderated mechanisms; for example, using the W3C Bugzilla service for first-level comment tracking, with the editor responsible for resolving comments, and using the W3C Tracker tool for comments that have been “escalated” for resolution by the working group as a whole. - +> Use the tracking system at all phases of the life cycle of the specification. An advantage of setting up such a tracking system early and using it as part of the working group’s normal operating procedures is that the same system can later also be used during Candidate Recommendation, for tracking Candidate Recommendation comments. So it can help the working group to proceed through Candidate Recommendation more quickly—because by the time the specification reaches Candidate Recommendation, the working group will already have long experience and familiarity with using a system for recording and tracking comments, and will save the start-up time they would otherwise need to spend during Candidate Recommendation to get accustomed to using a new and unfamiliar comment-tracking system for the first time. +{:.tip} A face to face meeting can be a helpful way to build social bonds and to start off new work. For a newly chartered group, there is a minimum notice period for a first meeting. +> First f2f meeting : There is a set minimum period of [eight weeks](/policies/process/#GeneralMeetings) for announcement of a face to face meeting. +{:.time} +> First f2f meeting : Propose a date and location of the first meeting, in the materials sent for AC review. This gives more notice, and allows the mandatory notice period to overlap with the AC review period. - +> Allow sufficient time for group members to organize travel and obtain legal review before the first f2f meeting. +{:.tip} ## First Public Working Draft {#fpwd} The First Public Working Draft is an important milestone. It makes concrete the proposed work. It is an opportunity to publicize the work of the Group. This is also a legal milestone; FPWD triggers a patent exclusion period for all features that are in that document. Features *added afterwards* are not covered until the work progresses to a Last Call. There is therefore a balance to be struck between speed and feature completeness (at least an outline of the features; details of syntax and specification for a given feature can be altered later). +> Exclusion period for FPWD : Announcement of an open exclusion period, immediately after publication of FPWD, triggers an [exlusion period of 150 days](/policies/patent-policy/#sec-exclusion-with). +{:.time} +> Exclusion period for FPWD : You don't have to wait for an exclusion period to end before moving to the next stage in the Rec track. Exclusion periods can overlap. +{:.tip} ## Test suites {#test} The W3C Process does not require tests to be available until exiting Candidate Recommendation. Leaving testing until it is the only thing left holding you back from Proposed Recommendation is, however, unwise. Tests give implementers something to work with, and provide examples for those reviewing the specification. Tests help make concrete the sometimes abstract language of a specification. Tests can show where reasonable interpretations of the same specification text could lead to divergent and non-interoperable implementations. +> Early testing : Start writing tests when you start writing the specification. - +> Just as you have one or more specification editors, consider having one or more test suite editors to drive testing - +> Generate implementation reports early, even if they are very incomplete. Sections of the specification that everyone is avoiding become clear (and you can examine why this is so). Also, peer pressure to outperform competing implementations is a wonderful thing. +{:.tip} ## Getting to Candidate Recommendation {#getting-to-lc} Once all open issues are closed (or deferred to the next version) and the group believes the document is stable enough for wide review, a Working Draft can be published for wide review. Other Groups, expecially those with formal dependencies, are invired to review. External Groups with whom the Working group has an ongoing liaison should also be invited to review. +> Wide Review Duration : The minimum duration for the Wide Review comment period should be 4 weeks. +{:.time} +> Wide Review Duration : 'Horizontal' groups that review many specifications (for example, WAI P&F and I18n Core) may, because of their workload, need longer than the minimum period. - +> Discuss Candidate Recommendation duration with the Chairs and Team contacts of groups that you expect to provide comments, *before* Candidate Recommendation is announced. - +> Bear in mind that external groups invited to review will have different processes to W3C. For example, they may only meet periodically. Be aware of their schedule before going to Candidate Recommendation. - +> Bear in mind the impact of vacation periods on Last Call duration. People won't comment if they are on vacation and will complain if they were unable to comment. - +> Explain why your document is relevant to each Group invited to review. If a particular section is especially relevant, call it out explicitly and give an explanation. Groups which do not understand why they are asked to review a document may be slow to respond. - +> There can be more than one wide review draft. If the document has changed substantially, in particular, if new features have been added, a new wide review will be needed. +{:.tip} If your specification defines one or more new Internet Media Types (previously called "MIME types"), put a draft registration of these types in an appendix, and send (the plain text of) this for ietf-types review at wide review @@ -162,25 +194,29 @@ If your specification defines one or more new Internet Media Types (previously c Each Candidate Recommendation review comment must be documented, the changes made (if any) and rationale for the change documented, and the agreement or disagreement of the reviewer to the change also documented. +> Processing Wide Review comments : There is no minimum duration for responding to wide review comments. +{:.time} +> Processing Wide Review comments : Deal with comments as they come in, rather than waiting until the end of the wide review period. Besides saving time, this can also avoid duplicate comments. - +> Maintain a draft Disposition of Comments. This allows commentors to see that their comment has been received and what the status of the response is. It also allows the Working Group to track the overall progress of the review. The Disposition of Comments will be needed during transition to CR. - +> Keep an Editors Draft up-to-date with changes made as a result of wide review comments, so that commentors can see the changes in place. This speeds sign-off on the changes. - +> If a Group is expected to comment and has not done so, ask if they need more time. This encourages them to either make their comments on time, or ask for an extension of known duration. Also ask that, if they have no comments, they send an explicit 'no comments' message. This helps 'show wide review' in the following Transition call, and differentiates groups whose review is complete from groups which are late. - +> If review comments are vague, ask for clarification or for concrete specification text which would satisfy the comment. - +< If review comments are overly ambitious and would exceed the planned scope of the current specification, ask if they can be deferred to the next version. - +> If a reviewer and the Working Group cannot reach agreement on a proposed change, give the reviewer a choice of accepting the change anyway ('can live with it') or filing a formal objection. - +> If changes are made in response to a comment and the reviewer does not react to repeated requests for confirmation that the changes are acceptable, send a final reminder stating that failure to respond by a given date will be taken as a sign that the changes are acceptable. Document the number of reminders sent and their dates, then move on. +{:.tip} ## Transition to CR {#transition-cr} @@ -190,23 +226,31 @@ Although having a Test Suite and an Implementation report at this stage is not r This section assumes that the earlier tips were followed and you have a test suite. +> CR Duration : There is a minimum duration of 28 days for comments for CR. Two months is a more typical figure. For follow-on CR publications, two weeks is a realistic minimum. +{:.time} +> CR Duration : Historically, the time taken to exit CR varied from zero (rare) to many years, largely due to the absence of test suites sufficiently early in the process. - +> By the time a Group is ready to enter CR, it should be possible to estimate with more confidence the likely duration, provided there is an existing Test Suite and draft implementation Report, and provided the Group is able to gauge the momentum of implementers. - +> If there is no test suite when entering CR, the likely duration cannot be accurately estimated. +{:.tip} Publication of a Candidate Recommendation triggers an Exclusion period on all features which were not in the previous First Public Working Draft (or previous Candidate Recommendation, if there was one). +> Exclusion period for Candidate Recommendation : Announcement of an open exclusion period, immediately after publication of Candidate Recommendation, triggers an exclusion period of [60 days](/policies/patent-policy/#sec-exclusion-with). +{:.time} +> Exclusion period for Candidate Recommendation : Exclusion periods can overlap. Check whether the exclusion period for FPWD is still open. +{:.tip} ## Leaving CR {#leaving-cr} @@ -215,35 +259,43 @@ Exiting the Candidate Recommendation phase can be triggered by: 1. meeting the CR exit criteria (which leads to Proposed Recommendation), or 2. dropping features which were not marked as 'at risk', or adding new features as a result of implementer feedback (which leads to another Candidate Recommendation). +> Post-CR Candidate Recommendation Duration : The minimum duration for the Candidate Recommendation comment period is 28 days. - +> Announcement of an open exclusion period, immediately after publication of Candidate Recommendation, triggers an exclusion period of 60 days. +{:.time} +> Avoiding or minimizing repeating CR publications : Identify likely 'at risk' features by looking at implementation reports before entering CR. - +> If in doubt, leave a feature in the spec and mark it 'at risk'. You can drop it without having another LC. Adding it back in afterwards, however, or dropping it without having identified it as 'at risk', triggers another Candidate Recommendation. - +> If a new CR is needed, limit the scope of comments to the removed or added features. State that, due to the maturity of existing implementations, all new feature requests will be deferred to the next version. - +> In practice, it is common to get no comments in such a late CR, because the implementers already agreed to drop/add whatever feature triggered the new CR. However, other implementers or dependent groups may have other ideas on the changes. +{:.tip} ## Proposed Recommendation {#pr} Following a successful transition call where the CR exit criteria were demonstrated to have been met, the next stage is Proposed Recommendation. This review period is not expected to raise substantive technical issues. +> PR Duration : The minimum duration for the PR review period is [four weeks](/policies/process/#rec-pr), followed by two weeks for a W3C's decision. If the review period spans the July/August or December holiday periods, more time is typically added. +{:.time} +> Minimising delay during PR : Personally contact the AC representative for each organization on the group (cc'ing the Group member) to remind them of the review. - +> Prepare an Editors Draft Recommendation, taking a copy of the PR document, and incorporate any changes (assumed editorial, such as out-of-date references, grammatical errors, and rewording of ambiguous paragraphs) that happen as a result of AC review. - +> If the group decides to produce a Press release to accompany the Recommendation, start work on this at the PR transition (or earlier). This allows time for testimonials to be approved and for the release itself to be translated into other languages. - +> Schedule the anticipated publication date of the final Recommendation with the Comm Team (especially if there will be press activity) and the webmaster. +{:.tip} ## Recommendation {#rec} @@ -254,24 +306,20 @@ Congratulations. Now start collecting [errata](/policies/process/#errata) for th The calendar and publication moratorium may get in the way of predicting precise milestones. Use our [milestones calculator](https://w3c.github.io/spec-releases/milestones/) to help with dates. From 593f7e205d5dbc6b5ebc091403ed3a91c352109e Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 20 Dec 2024 11:49:38 +0100 Subject: [PATCH 127/225] typo --- process/predicting-milestones.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 0b0a6bf48..a398d8146 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -7,8 +7,6 @@ toc: true ### Aims and Scope {#aims} -The background color is `#ffffff` for light mode and `#000000` for dark mode. - This document is intended to help in predicting milestones for work on the W3C Standards track. Realistic milestones are important for resource allocation at the start of new work, and to monitor progress when rechartering or extending existing work. At the same time, the very nature of the work means that progress is somewhat unpredictable; *delays can and will occur* relative to the predicted schedule. Delays are not necessarily a bad thing. For example, delays due to an unexpectedly large volume of last call comments may improve the specification or may indicate that what was previously considered a simple problem is actually more complex. Delays due to incomplete implementations may indicate that implementers disagree on the meaning of the specification, or that priorities have shifted away to other work. So these delays may indicate where the work needs to be improved. Delay, and a better specification, is usually preferable to a rapidly produced but poor quality specification that needs to be revised, substantially reworked, or abandoned and replaced because it was unsuitable. @@ -310,7 +308,7 @@ blockquote.time dl > dt:before { content: "Time: "} blockquote.time::before { background-color: #EE9 !important; - width: 0.3rem !important; + width: 0.3rem !important; height: 90% !important; left: -0.5rem !important; } From 74e64d7a422b0e0f121d4f1ae9ae72aadacc2aac Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 6 Jan 2025 14:41:37 +0100 Subject: [PATCH 128/225] Move Tips/Times from CSS to content + fix wrong "<" + set bloqquote text on the same line as their ">" --- process/predicting-milestones.md | 86 +++++++++++--------------------- 1 file changed, 28 insertions(+), 58 deletions(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index a398d8146..f635a4c11 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -38,13 +38,11 @@ This document is an informal guide to predicting the likely duration of Recommen The first set of milestones are drawn up before work starts, and put in an initial charter. In this phase, an idea is firmed up from "hey we could do this" to a fully fledged, chartered Working Group. If the work is entirely new, or would take an existing group in a radical new direction, the Process Document [requires](/policies/process/#WGCharterDevelopment) that Advance Notice be sent to the AC. Often, an initial draft charter is sent along with this notice (but this is not required). The aim here is to avoid surprises, to quickly gather brainstorming-type feedback, and to get buy-in on the proposed direction from likely members of the eventual Working Group. -> -Advance Notice +> Time: Advance Notice : There is no set period for Advance Notice, but four weeks is a typical minimum period. {:.time} -> -Advance Notice +>Tips: Advance Notice : When developing materials for and advance notice, try to strike a balance between fast (but overly sketchy and vague) and thorough (but slow, maybe over-detailed or over-constraining). > If work has been prepared beforehand in a Community group, or formalizes existing, industry standard practices, then an Advance Notice might be skipped. @@ -52,20 +50,17 @@ Advance Notice The results from Advance Notice may indicate broad consensus on the proposed direction (if so, proceed rapidly to a formal charter review). Or they may indicate disagreement on the best direction forward (in which case, iterate). Some commentors may want a fast development of an initial version, while others may want a fully fledged solution. -> -Advance Notice Feedback +> Tip: Advance Notice Feedback : If feedback indicates disagreement on scope, consider proposing both a fast initial version *and* a requirements gathering and drafting item for a full-featured second version. This will help avoid delays due to disagreements on scope. {:.tip} Once broad agreement is reached, a draft charter is created (or updated, if one was sent with the Advance Notice) and reviewed by W3M before being sent to the AC. -> -W3M review +> Time: W3M review : There is no set period for W3M review, but two reviewers are needed and two weeks is a typical minimum period. {:.time} -> -W3M review +>Tips: W3M review : One of the reviewers can be the Domain leader, who should already be familiar with the proposed work from Team discussions. This can lead to faster and more thorough review. > The draft charter must indicate a proposed chair. Save time by identifying likely chairs during the Advance Notice period. @@ -77,13 +72,11 @@ W3M review Once review comments from W3M have been incorporated into the charter, it is [sent to the AC for review](/policies/process/#CharterReview). -> -AC review +> Time: AC review : There is no set period for AC review, but four weeks is a typical minimum period followed by two to four weeks to incorporate feedback and to make the decision to charter the proposed Working Group. {:.time} -> -AC review +>Tips: AC review : Respond to each review comment as it arrives, rather than waiting for the review period to end. Others may have similar concerns, so addressing them early avoids needless repeat comments. > Keep the proposed charter unchanged (so the AC has a stable document to review) but make a copy at a different location and incorporate comments (so commentors can see the resolution of their issues in-place). @@ -95,13 +88,11 @@ AC review Once the decision to start the Working Group has been communicated to the AC, participants can join. This may take some time, particularly if participants need to perform a legal review of the work items (for example, to review their patent portfolio in light of the [W3C Royalty-Free commitment](/policies/patent-policy/#sec-Requirements)). In the case of a new group, some or all of the participants may be unfamiliar with W3C processes, tools (such as IRC, phone conferencing, issue tracking, version control). The Chair and Staff Contact take a lead role in getting a new group up to productive speed. -> -WG startup +> Time: WG startup : There is no set period until a Group starts to become productive. Experienced participants with a capable Chair and Team Contact, working on a new version of an existing specification can be productive immediately. A new group with participants new to W3C, working in a new area which is rife with Intellectual property concerns, may take several months to become productive. {:.time} -> -WG startup +> Tips: WG startup : Make a diff document of the final charter, compared to the one sent for AC review. Legal review can focus on just what has changed. > As soon as the decision is made to charter the group, set up the usual infrastructure (public web page, archived mailing lists(s), wiki, issue and action tracker) so that participants are not kept waiting and so that they become used to the way of working. @@ -123,13 +114,11 @@ WG startup A face to face meeting can be a helpful way to build social bonds and to start off new work. For a newly chartered group, there is a minimum notice period for a first meeting. -> -First f2f meeting +> Time: First f2f meeting : There is a set minimum period of [eight weeks](/policies/process/#GeneralMeetings) for announcement of a face to face meeting. {:.time} -> -First f2f meeting +> Tips: First f2f meeting : Propose a date and location of the first meeting, in the materials sent for AC review. This gives more notice, and allows the mandatory notice period to overlap with the AC review period. > Allow sufficient time for group members to organize travel and obtain legal review before the first f2f meeting. @@ -139,13 +128,11 @@ First f2f meeting The First Public Working Draft is an important milestone. It makes concrete the proposed work. It is an opportunity to publicize the work of the Group. This is also a legal milestone; FPWD triggers a patent exclusion period for all features that are in that document. Features *added afterwards* are not covered until the work progresses to a Last Call. There is therefore a balance to be struck between speed and feature completeness (at least an outline of the features; details of syntax and specification for a given feature can be altered later). -> -Exclusion period for FPWD +> Time: Exclusion period for FPWD : Announcement of an open exclusion period, immediately after publication of FPWD, triggers an [exlusion period of 150 days](/policies/patent-policy/#sec-exclusion-with). {:.time} -> -Exclusion period for FPWD +> Tips: Exclusion period for FPWD : You don't have to wait for an exclusion period to end before moving to the next stage in the Rec track. Exclusion periods can overlap. {:.tip} @@ -153,8 +140,7 @@ Exclusion period for FPWD The W3C Process does not require tests to be available until exiting Candidate Recommendation. Leaving testing until it is the only thing left holding you back from Proposed Recommendation is, however, unwise. Tests give implementers something to work with, and provide examples for those reviewing the specification. Tests help make concrete the sometimes abstract language of a specification. Tests can show where reasonable interpretations of the same specification text could lead to divergent and non-interoperable implementations. -> -Early testing +> Tips: Early testing : Start writing tests when you start writing the specification. > Just as you have one or more specification editors, consider having one or more test suite editors to drive testing @@ -166,13 +152,11 @@ Early testing Once all open issues are closed (or deferred to the next version) and the group believes the document is stable enough for wide review, a Working Draft can be published for wide review. Other Groups, expecially those with formal dependencies, are invired to review. External Groups with whom the Working group has an ongoing liaison should also be invited to review. -> -Wide Review Duration +> Time: Wide Review Duration : The minimum duration for the Wide Review comment period should be 4 weeks. {:.time} -> -Wide Review Duration +> Tips: Wide Review Duration : 'Horizontal' groups that review many specifications (for example, WAI P&F and I18n Core) may, because of their workload, need longer than the minimum period. > Discuss Candidate Recommendation duration with the Chairs and Team contacts of groups that you expect to provide comments, *before* Candidate Recommendation is announced. @@ -192,13 +176,11 @@ If your specification defines one or more new Internet Media Types (previously c Each Candidate Recommendation review comment must be documented, the changes made (if any) and rationale for the change documented, and the agreement or disagreement of the reviewer to the change also documented. -> -Processing Wide Review comments +> Time: Processing Wide Review comments : There is no minimum duration for responding to wide review comments. {:.time} -> -Processing Wide Review comments +> Tips: Processing Wide Review comments : Deal with comments as they come in, rather than waiting until the end of the wide review period. Besides saving time, this can also avoid duplicate comments. > Maintain a draft Disposition of Comments. This allows commentors to see that their comment has been received and what the status of the response is. It also allows the Working Group to track the overall progress of the review. The Disposition of Comments will be needed during transition to CR. @@ -208,7 +190,7 @@ Processing Wide Review comments If a Group is expected to comment and has not done so, ask if they need more time. This encourages them to either make their comments on time, or ask for an extension of known duration. Also ask that, if they have no comments, they send an explicit 'no comments' message. This helps 'show wide review' in the following Transition call, and differentiates groups whose review is complete from groups which are late. > If review comments are vague, ask for clarification or for concrete specification text which would satisfy the comment. -< +> If review comments are overly ambitious and would exceed the planned scope of the current specification, ask if they can be deferred to the next version. > If a reviewer and the Working Group cannot reach agreement on a proposed change, give the reviewer a choice of accepting the change anyway ('can live with it') or filing a formal objection. @@ -224,13 +206,11 @@ Although having a Test Suite and an Implementation report at this stage is not r This section assumes that the earlier tips were followed and you have a test suite. -> -CR Duration +> Time: CR Duration : There is a minimum duration of 28 days for comments for CR. Two months is a more typical figure. For follow-on CR publications, two weeks is a realistic minimum. {:.time} -> -CR Duration +> Tips: CR Duration : Historically, the time taken to exit CR varied from zero (rare) to many years, largely due to the absence of test suites sufficiently early in the process. > By the time a Group is ready to enter CR, it should be possible to estimate with more confidence the likely duration, provided there is an existing Test Suite and draft implementation Report, and provided the Group is able to gauge the momentum of implementers. @@ -240,13 +220,11 @@ CR Duration Publication of a Candidate Recommendation triggers an Exclusion period on all features which were not in the previous First Public Working Draft (or previous Candidate Recommendation, if there was one). -> -Exclusion period for Candidate Recommendation +> Time: Exclusion period for Candidate Recommendation : Announcement of an open exclusion period, immediately after publication of Candidate Recommendation, triggers an exclusion period of [60 days](/policies/patent-policy/#sec-exclusion-with). {:.time} -> -Exclusion period for Candidate Recommendation +> Tips: Exclusion period for Candidate Recommendation : Exclusion periods can overlap. Check whether the exclusion period for FPWD is still open. {:.tip} @@ -257,15 +235,13 @@ Exiting the Candidate Recommendation phase can be triggered by: 1. meeting the CR exit criteria (which leads to Proposed Recommendation), or 2. dropping features which were not marked as 'at risk', or adding new features as a result of implementer feedback (which leads to another Candidate Recommendation). -> -Post-CR Candidate Recommendation Duration +> Time: Post-CR Candidate Recommendation Duration : The minimum duration for the Candidate Recommendation comment period is 28 days. > Announcement of an open exclusion period, immediately after publication of Candidate Recommendation, triggers an exclusion period of 60 days. {:.time} -> -Avoiding or minimizing repeating CR publications +> Tips: Avoiding or minimizing repeating CR publications : Identify likely 'at risk' features by looking at implementation reports before entering CR. > If in doubt, leave a feature in the spec and mark it 'at risk'. You can drop it without having another LC. Adding it back in afterwards, however, or dropping it without having identified it as 'at risk', triggers another Candidate Recommendation. @@ -279,13 +255,11 @@ Avoiding or minimizing repeating CR publications Following a successful transition call where the CR exit criteria were demonstrated to have been met, the next stage is Proposed Recommendation. This review period is not expected to raise substantive technical issues. -> -PR Duration +> Time: PR Duration : The minimum duration for the PR review period is [four weeks](/policies/process/#rec-pr), followed by two weeks for a W3C's decision. If the review period spans the July/August or December holiday periods, more time is typically added. {:.time} -> -Minimising delay during PR +> Tips: Minimising delay during PR : Personally contact the AC representative for each organization on the group (cc'ing the Group member) to remind them of the review. > Prepare an Editors Draft Recommendation, taking a copy of the PR document, and incorporate any changes (assumed editorial, such as out-of-date references, grammatical errors, and rewording of ambiguous paragraphs) that happen as a result of AC review. @@ -304,20 +278,16 @@ Congratulations. Now start collecting [errata](/policies/process/#errata) for th The calendar and publication moratorium may get in the way of predicting precise milestones. Use our [milestones calculator](https://w3c.github.io/spec-releases/milestones/) to help with dates. From 2b56c1148e134d6ccee23daf6006f4464eba35f1 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 6 Jan 2025 15:21:53 +0100 Subject: [PATCH 129/225] Add a link on "Tilt" pointing to /process/tilt/ --- process/charter-extensions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/charter-extensions.md b/process/charter-extensions.md index 7ba0fc5bd..3fe5e1fdf 100644 --- a/process/charter-extensions.md +++ b/process/charter-extensions.md @@ -15,6 +15,6 @@ From time to time a Working Group or Interest Group will not have completed its - one month prior to the charter expiration if an AC review of the change to the charter is not expected or - three months prior to the charter expiration if an AC review of the proposed change to the charter might be conducted. - Whether or not an AC review is conducted, a decision on the current charter of the Group must be announced to the Membership, with rationale, prior to the charter expiration. TiLT may grant short charter extensions if AC review has not completed prior to the current charter end date. + Whether or not an AC review is conducted, a decision on the current charter of the Group must be announced to the Membership, with rationale, prior to the charter expiration. [TiLT](tilt/) may grant short charter extensions if AC review has not completed prior to the current charter end date. 5. Publication Requests on behalf of a Group whose charter has expired more than five business days prior to the date of publication will be denied. This five business day allowance is meant only to accommodate unforeseen circumstances out of the Group's control. 6. Any Group whose charter has expired should not request nor should it expect W3C Staff support. Strategy may choose to continue some level of Staff support. Changes in Staff support decided by Function Leads will be communicated to the chair(s) of the Group. From 8d64d0ad0746fcfdeedf16d24e684cc52f86a8da Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Mon, 6 Jan 2025 15:30:05 +0100 Subject: [PATCH 130/225] Remove "Sped". Add link to "Policy regarding Non-Disclosure Agreements and W3C meetings --- meetings/hosting.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/meetings/hosting.md b/meetings/hosting.md index d95a24041..b207d0dfe 100644 --- a/meetings/hosting.md +++ b/meetings/hosting.md @@ -3,7 +3,10 @@ title: Host Guidelines for W3C face to face toc: true --- -This page is targeted for W3C Working/Interest Group face to face meetings, Workshops, and Symposiums. Sped +[Policy Regarding Non-Disclosure Agreements and W3C Meetings](https://www.w3.org/policies/no-nda/) + +This page is targeted for W3C Working/Interest Group face to face +meetings, Workshops, and Symposiums. ## General Considerations {#general} @@ -163,4 +166,4 @@ Please add to this list if you notice omissions. ### Meals - Lunch (what should attendees expect?): -- Group dinner (where? when? who pays?): \ No newline at end of file +- Group dinner (where? when? who pays?): From 4f9dce696ed32d90b35785bed214612e3e37921d Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:12:43 +0100 Subject: [PATCH 131/225] Fix typos Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index f635a4c11..bc23f44a5 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -43,7 +43,7 @@ The first set of milestones are drawn up before work starts, and put in an initi {:.time} >Tips: Advance Notice -: When developing materials for and advance notice, try to strike a balance between fast (but overly sketchy and vague) and thorough (but slow, maybe over-detailed or over-constraining). +: When developing materials for an advance notice, try to strike a balance between fast (but overly sketchy and vague) and thorough (but slow, maybe over-detailed or over-constraining). > If work has been prepared beforehand in a Community group, or formalizes existing, industry standard practices, then an Advance Notice might be skipped. {:.tip} From 9b4f6a1fca726705ff8627ccb4ca80b2b4568aa3 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:13:20 +0100 Subject: [PATCH 132/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index bc23f44a5..d598301d7 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -51,7 +51,7 @@ The first set of milestones are drawn up before work starts, and put in an initi The results from Advance Notice may indicate broad consensus on the proposed direction (if so, proceed rapidly to a formal charter review). Or they may indicate disagreement on the best direction forward (in which case, iterate). Some commentors may want a fast development of an initial version, while others may want a fully fledged solution. > Tip: Advance Notice Feedback -: If feedback indicates disagreement on scope, consider proposing both a fast initial version *and* a requirements gathering and drafting item for a full-featured second version. This will help avoid delays due to disagreements on scope. +: If feedback indicates disagreement on scope, consider proposing both a fast initial version *and* a requirements gathering and drafting item for a full-featured second version. This can help avoid delays due to disagreements on scope. {:.tip} Once broad agreement is reached, a draft charter is created (or updated, if one was sent with the Advance Notice) and reviewed by W3M before being sent to the AC. From 6ecb53a7f0b1d96b7f32e02229748fdf93c8d881 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:16:29 +0100 Subject: [PATCH 133/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index d598301d7..66c8ec1cc 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -79,7 +79,7 @@ Once review comments from W3M have been incorporated into the charter, it is [se >Tips: AC review : Respond to each review comment as it arrives, rather than waiting for the review period to end. Others may have similar concerns, so addressing them early avoids needless repeat comments. > - Keep the proposed charter unchanged (so the AC has a stable document to review) but make a copy at a different location and incorporate comments (so commentors can see the resolution of their issues in-place). + Keep the proposed charter unchanged (so the AC has a stable document to review) but make a copy at a different location and incorporate comments (so commenters can see the resolution of their issues in-place). > Talk to likely implementers during AC review and try to gauge the level of interest. {:.tip} From 3af0221656ba0dd8efe8f37da3bf003690402ce1 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:16:44 +0100 Subject: [PATCH 134/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 66c8ec1cc..f94d08320 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -86,7 +86,7 @@ Once review comments from W3M have been incorporated into the charter, it is [se ## Starting the Group {#wg-startup} -Once the decision to start the Working Group has been communicated to the AC, participants can join. This may take some time, particularly if participants need to perform a legal review of the work items (for example, to review their patent portfolio in light of the [W3C Royalty-Free commitment](/policies/patent-policy/#sec-Requirements)). In the case of a new group, some or all of the participants may be unfamiliar with W3C processes, tools (such as IRC, phone conferencing, issue tracking, version control). The Chair and Staff Contact take a lead role in getting a new group up to productive speed. +Once the decision to start the Working Group has been communicated to the AC, participants can join. This may take some time, particularly if participants need to perform a legal review of the work items (for example, to review their patent portfolio in light of the [W3C Royalty-Free commitment](/policies/patent-policy/#sec-Requirements)). In the case of a new group, some or all of the participants may be unfamiliar with W3C processes and tools (such as IRC, phone conferencing, issue tracking, version control). The Chair and Staff Contact take a lead role in getting a new group up to productive speed. > Time: WG startup : There is no set period until a Group starts to become productive. Experienced participants with a capable Chair and Team Contact, working on a new version of an existing specification can be productive immediately. A new group with participants new to W3C, working in a new area which is rife with Intellectual property concerns, may take several months to become productive. From 8f3449168e8f99ff447220eba14f904ae36e50ab Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:17:16 +0100 Subject: [PATCH 135/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index f94d08320..406de662e 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -89,7 +89,7 @@ Once review comments from W3M have been incorporated into the charter, it is [se Once the decision to start the Working Group has been communicated to the AC, participants can join. This may take some time, particularly if participants need to perform a legal review of the work items (for example, to review their patent portfolio in light of the [W3C Royalty-Free commitment](/policies/patent-policy/#sec-Requirements)). In the case of a new group, some or all of the participants may be unfamiliar with W3C processes and tools (such as IRC, phone conferencing, issue tracking, version control). The Chair and Staff Contact take a lead role in getting a new group up to productive speed. > Time: WG startup -: There is no set period until a Group starts to become productive. Experienced participants with a capable Chair and Team Contact, working on a new version of an existing specification can be productive immediately. A new group with participants new to W3C, working in a new area which is rife with Intellectual property concerns, may take several months to become productive. +: There is no set period after which a Group becomes productive. Experienced participants with a capable Chair and Team Contact, working on a new version of an existing specification, can be productive immediately. A new group with participants new to W3C, working in a new area which is rife with intellectual property concerns, may take several months to become productive. {:.time} > Tips: WG startup From f3b27a43c5d305b8e2634455de86ab161020f83a Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:17:42 +0100 Subject: [PATCH 136/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 406de662e..1a5ddca18 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -218,7 +218,7 @@ This section assumes that the earlier tips were followed and you have a test sui If there is no test suite when entering CR, the likely duration cannot be accurately estimated. {:.tip} -Publication of a Candidate Recommendation triggers an Exclusion period on all features which were not in the previous First Public Working Draft (or previous Candidate Recommendation, if there was one). +Publication of a Candidate Recommendation triggers an Exclusion period on all features which were not in the preceding First Public Working Draft (or previous Candidate Recommendation, if there was one). > Time: Exclusion period for Candidate Recommendation : Announcement of an open exclusion period, immediately after publication of Candidate Recommendation, triggers an exclusion period of [60 days](/policies/patent-policy/#sec-exclusion-with). From 83e6f27a46c230f8740000f8b028c83ba27d3335 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:18:26 +0100 Subject: [PATCH 137/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 1a5ddca18..e5aba9664 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -256,7 +256,7 @@ Exiting the Candidate Recommendation phase can be triggered by: Following a successful transition call where the CR exit criteria were demonstrated to have been met, the next stage is Proposed Recommendation. This review period is not expected to raise substantive technical issues. > Time: PR Duration -: The minimum duration for the PR review period is [four weeks](/policies/process/#rec-pr), followed by two weeks for a W3C's decision. If the review period spans the July/August or December holiday periods, more time is typically added. +: The minimum duration for the PR review period is [four weeks](/policies/process/#rec-pr), followed by two weeks for a W3C decision. If the review period spans the July/August or December holiday periods, more time is typically added. {:.time} > Tips: Minimising delay during PR From af3755c48cb25c357e71453d90491b3cdb30f940 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:18:55 +0100 Subject: [PATCH 138/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index e5aba9664..1f3125014 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -233,7 +233,7 @@ Publication of a Candidate Recommendation triggers an Exclusion period on all fe Exiting the Candidate Recommendation phase can be triggered by: 1. meeting the CR exit criteria (which leads to Proposed Recommendation), or -2. dropping features which were not marked as 'at risk', or adding new features as a result of implementer feedback (which leads to another Candidate Recommendation). +2. dropping features which were not marked as 'at risk', or adding new features as a result of implementer feedback (either of which leads to another Candidate Recommendation). > Time: Post-CR Candidate Recommendation Duration : The minimum duration for the Candidate Recommendation comment period is 28 days. From b4c9a3f855baed11dbec3f4330f58a5df8de19ec Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:19:17 +0100 Subject: [PATCH 139/225] Editorial Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 1f3125014..2d041ffa7 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -260,7 +260,7 @@ Following a successful transition call where the CR exit criteria were demonstra {:.time} > Tips: Minimising delay during PR -: Personally contact the AC representative for each organization on the group (cc'ing the Group member) to remind them of the review. +: Personally contact the AC representative for each organization on the group (CCing the Group member) to remind them of the review. > Prepare an Editors Draft Recommendation, taking a copy of the PR document, and incorporate any changes (assumed editorial, such as out-of-date references, grammatical errors, and rewording of ambiguous paragraphs) that happen as a result of AC review. > From 77de615f180bd403f980d48711c708fdf13e6545 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 08:20:20 +0100 Subject: [PATCH 140/225] Fix as Last Call has been dreprecated Co-authored-by: Ted Thibodeau Jr --- process/predicting-milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/predicting-milestones.md b/process/predicting-milestones.md index 2d041ffa7..26cc89357 100644 --- a/process/predicting-milestones.md +++ b/process/predicting-milestones.md @@ -244,7 +244,7 @@ Exiting the Candidate Recommendation phase can be triggered by: > Tips: Avoiding or minimizing repeating CR publications : Identify likely 'at risk' features by looking at implementation reports before entering CR. > - If in doubt, leave a feature in the spec and mark it 'at risk'. You can drop it without having another LC. Adding it back in afterwards, however, or dropping it without having identified it as 'at risk', triggers another Candidate Recommendation. + If in doubt, leave a feature in the spec and mark it 'at risk'. You can drop it without having another CR. Adding it back in afterwards, however, or dropping it without having identified it as 'at risk', triggers another Candidate Recommendation. > If a new CR is needed, limit the scope of comments to the removed or added features. State that, due to the maturity of existing implementations, all new feature requests will be deferred to the next version. > From d7d009def0ac20c417477d24ba89e89d84f34875 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 09:39:33 +0100 Subject: [PATCH 141/225] Disable jekyll-readme-index plugin --- Gemfile | 1 - _config.yml | 2 -- 2 files changed, 3 deletions(-) diff --git a/Gemfile b/Gemfile index 7e825bf9f..f9233618c 100644 --- a/Gemfile +++ b/Gemfile @@ -15,7 +15,6 @@ gem "jekyll", "~> 4.1.0" # our markdown files don't have frontmatter group :jekyll_plugins do gem 'jekyll-optional-front-matter' - gem "jekyll-readme-index" gem "jekyll-titles-from-headings" gem "jekyll-relative-links" gem 'jekyll-commonmark' diff --git a/_config.yml b/_config.yml index f2bf0161e..7014b064d 100644 --- a/_config.yml +++ b/_config.yml @@ -13,7 +13,5 @@ defaults: layout: "default" optional_front_matter: remove_originals: true -readme_index: - remove_originals: true toc: max_level: 3 From 4bdc157106f8cb5505781c1194fe8265ef94b270 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 09:50:45 +0100 Subject: [PATCH 142/225] HOWTO file was not supposed to be part of the public Guidebook as it only contains instructions to explain how to edit the transitions requirements, renaming it as README.md which is most common --- transitions/{howto.md => README.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename transitions/{howto.md => README.md} (100%) diff --git a/transitions/howto.md b/transitions/README.md similarity index 100% rename from transitions/howto.md rename to transitions/README.md From e853414a1e6c21b27f127570649e51105e075780 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 09:51:22 +0100 Subject: [PATCH 143/225] Exclude README.md from jekyll site content --- _config.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/_config.yml b/_config.yml index 7014b064d..72c1e5e68 100644 --- a/_config.yml +++ b/_config.yml @@ -11,6 +11,7 @@ defaults: path: "" # an empty string here means all files in the project values: layout: "default" +exclude: ["README.md", "**/README.md"] optional_front_matter: remove_originals: true toc: From b1a6d48833e1eca6b5f87b496420a94045df649d Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 09:52:57 +0100 Subject: [PATCH 144/225] Disable jekyll-optional-front-matter plugin --- Gemfile | 1 - _config.yml | 2 -- 2 files changed, 3 deletions(-) diff --git a/Gemfile b/Gemfile index f9233618c..66026e8ee 100644 --- a/Gemfile +++ b/Gemfile @@ -14,7 +14,6 @@ gem "jekyll", "~> 4.1.0" # our markdown files don't have frontmatter group :jekyll_plugins do - gem 'jekyll-optional-front-matter' gem "jekyll-titles-from-headings" gem "jekyll-relative-links" gem 'jekyll-commonmark' diff --git a/_config.yml b/_config.yml index 72c1e5e68..366a28a0b 100644 --- a/_config.yml +++ b/_config.yml @@ -12,7 +12,5 @@ defaults: values: layout: "default" exclude: ["README.md", "**/README.md"] -optional_front_matter: - remove_originals: true toc: max_level: 3 From a58413e8e2d44e3750ca28406dc1ae4ff51407df Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 7 Jan 2025 10:18:29 +0100 Subject: [PATCH 145/225] Add a submenu publication Policies --- editor/editors-draft.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/editor/editors-draft.md b/editor/editors-draft.md index 1888ef759..9c1df4858 100644 --- a/editor/editors-draft.md +++ b/editor/editors-draft.md @@ -1,6 +1,7 @@ --- title: Style for Group-internal Drafts -toc: yes +submenu: [publication-policies] +toc: no --- ## Status of this Document {#sotd} @@ -38,4 +39,4 @@ The guidelines below are intended to reduce confusion between group-internal dra In general, no (but see [Issue #110](https://github.com/w3c/modern-tooling/issues/110)). Please avoid giving the impression that these drafts have formal status within W3C or another body. Please do not label them "W3C Working Draft" in these documents. -If you are just attaching a copy of an in-progress draft in email in preparation for a group teleconference, keep in mind that the attachment is archived and may be found by readers who don't have that context. Please erase any indication that this is a W3C Working Draft. \ No newline at end of file +If you are just attaching a copy of an in-progress draft in email in preparation for a group teleconference, keep in mind that the attachment is archived and may be found by readers who don't have that context. Please erase any indication that this is a W3C Working Draft. From 861f8de32e86afa78a9fad84571851543f1cae8b Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Tue, 7 Jan 2025 10:25:10 +0100 Subject: [PATCH 146/225] Add a submenu Publication Policies --- _data/submenu-publication-policies.yml | 34 ++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 _data/submenu-publication-policies.yml diff --git a/_data/submenu-publication-policies.yml b/_data/submenu-publication-policies.yml new file mode 100644 index 000000000..5f6c77249 --- /dev/null +++ b/_data/submenu-publication-policies.yml @@ -0,0 +1,34 @@ +title: Publication Policies + +pages: + +- title: Technical Report Publication Policy + url: https://www.w3.org/pubrules/ + html: https://www.w3.org/pubrules/ + +- title: About pubrules + url: https://www.w3.org/pubrules/doct + html: https://www.w3.org/pubrules/doct + +- title: Version Management in W3C Technical Reports + url: https://www.w3.org/2005/05/tr-versions + html: https://www.w3.org/2005/05/tr-versions + +- title: Guidelines for linking to disclosure pages + url: https://www.w3.org/2005/07/13-pubrules-disclosure + html: https://www.w3.org/2005/07/13-pubrules-disclosure + +- title: URIs for W3C Namespaces + url: https://www.w3.org/2005/07/13-nsuri + html: https://www.w3.org/2005/07/13-nsuri + +- title: How to Register a Media Type for a W3C Specification + url: https://www.w3.org/2020/01/registering-mediatypes + html: https://www.w3.org/2020/01/registering-mediatypes + + +- title: XPointer Scheme Name Registry Policy + url: https://www.w3.org/2005/04/xpointer-policy + html: https://www.w3.org/2005/04/xpointer-policy + + From 98a1f74118e95030b155d497cb6927f4fc7d3e30 Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Tue, 7 Jan 2025 13:59:40 +0400 Subject: [PATCH 147/225] GH action to install jekyll dependencies and update GH pages --- .github/workflows/jekyll-gh-pages.yml | 51 +++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 .github/workflows/jekyll-gh-pages.yml diff --git a/.github/workflows/jekyll-gh-pages.yml b/.github/workflows/jekyll-gh-pages.yml new file mode 100644 index 000000000..eba2b9817 --- /dev/null +++ b/.github/workflows/jekyll-gh-pages.yml @@ -0,0 +1,51 @@ +name: Deploy Jekyll with GitHub Pages dependencies preinstalled + +on: + # Runs on pushes targeting the default branch + push: + branches: ["new-design"] + +# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. +# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. +concurrency: + group: "pages" + cancel-in-progress: false + +jobs: + # Build job + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Setup Ruby + uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1.195.0 + with: + ruby-version: '3.3' # Not needed with a .ruby-version file + bundler-cache: true # runs 'bundle install' and caches installed gems automatically + - name: Build with Jekyll + # Outputs to the './_site' directory by default + run: bundle exec jekyll build + env: + JEKYLL_ENV: production + - name: Upload artifact + id: github-pages + uses: actions/upload-pages-artifact@v1 + with: + name: github-pages + path: _site/ + + # Deployment job + deploy: + needs: build + permissions: + pages: write + id-token: write + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + runs-on: ubuntu-latest + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v1 From 8ff44ec5f03e76a3b42f8a0f95b2a6bed8280c3b Mon Sep 17 00:00:00 2001 From: Denis Ah-Kang Date: Tue, 7 Jan 2025 14:02:09 +0400 Subject: [PATCH 148/225] ruby 3.2.3 --- .github/workflows/jekyll-gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/jekyll-gh-pages.yml b/.github/workflows/jekyll-gh-pages.yml index eba2b9817..c76d66ef7 100644 --- a/.github/workflows/jekyll-gh-pages.yml +++ b/.github/workflows/jekyll-gh-pages.yml @@ -21,7 +21,7 @@ jobs: - name: Setup Ruby uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1.195.0 with: - ruby-version: '3.3' # Not needed with a .ruby-version file + ruby-version: '3.2.3' # Not needed with a .ruby-version file bundler-cache: true # runs 'bundle install' and caches installed gems automatically - name: Build with Jekyll # Outputs to the './_site' directory by default From 7ddd92c1b17b8edf2518950be434d73dfd85887d Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Tue, 7 Jan 2025 14:21:02 +0100 Subject: [PATCH 149/225] Remove unneeded 'html' links --- _data/submenu-publication-policies.yml | 9 --------- 1 file changed, 9 deletions(-) diff --git a/_data/submenu-publication-policies.yml b/_data/submenu-publication-policies.yml index 5f6c77249..f494d860c 100644 --- a/_data/submenu-publication-policies.yml +++ b/_data/submenu-publication-policies.yml @@ -4,31 +4,22 @@ pages: - title: Technical Report Publication Policy url: https://www.w3.org/pubrules/ - html: https://www.w3.org/pubrules/ - title: About pubrules url: https://www.w3.org/pubrules/doct - html: https://www.w3.org/pubrules/doct - title: Version Management in W3C Technical Reports url: https://www.w3.org/2005/05/tr-versions - html: https://www.w3.org/2005/05/tr-versions - title: Guidelines for linking to disclosure pages url: https://www.w3.org/2005/07/13-pubrules-disclosure - html: https://www.w3.org/2005/07/13-pubrules-disclosure - title: URIs for W3C Namespaces url: https://www.w3.org/2005/07/13-nsuri - html: https://www.w3.org/2005/07/13-nsuri - title: How to Register a Media Type for a W3C Specification url: https://www.w3.org/2020/01/registering-mediatypes - html: https://www.w3.org/2020/01/registering-mediatypes - - title: XPointer Scheme Name Registry Policy url: https://www.w3.org/2005/04/xpointer-policy - html: https://www.w3.org/2005/04/xpointer-policy - From fe3d2f5a73f9a0aa468961e4556461231ce18fe8 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 8 Jan 2025 11:01:22 +0100 Subject: [PATCH 150/225] Add the template properties, check document, use new design style for the
    inputs --- transitions/index.html | 1560 +++++++++++++++++----------------------- 1 file changed, 646 insertions(+), 914 deletions(-) diff --git a/transitions/index.html b/transitions/index.html index fd6882aa4..2fc22f858 100644 --- a/transitions/index.html +++ b/transitions/index.html @@ -1,431 +1,212 @@ - - - - - - - How to Organize a Technical Report Transition (2023 Process) - - - - - - - - - - - - - - - -
    -

    Publication Policies

    - -

    Resources

    - -

    Tools

    -
      -
    • Milestones planning
    • -
    • Link checker
    • -
    • HTML Validator
    • -
    • CSS Validator
    • +--- +title: Organize a Technical Report Transition (2023 Process) +toc: false +--- + +
      + +
      +
      + + +
      +
      + +
      + -
      - -

      - Select your steps : - -

      - - -
        +
        • - -
        • - +
          + +
        -
          + +
          • - - +
            + + +
          • - +
            + +
          • - +
            + +
          -

          Note: The first Candidate +


          Note: The first Candidate Recommendation publication after verification of a transition request is also considered a Candidate Recommendation Snapshot.

          -

          -
            +
            • - +
              + +
            -
              +
              • - +
                + +
              • - +
                + +
              • - +
                + +
              • - +
                + +
              • - +
                + +
              • - +
                + + +
              • - +
                + +
              • - +
                + +
              • -
              • -

                You may also follow Candidate +

              • +

                You may also follow Candidate Recommendation for substantive corrections

              • -
              • -

                We allow some in place modifications of Recommendations, including markup changes. See In-place modification of W3C Technical Reports.

                +
              • +

                We allow some in place modifications of Recommendations, including markup changes. See In-place modification of W3C Technical Reports.

              -
                + +
                • - +
                  + +
                • - +
                  + +
                • - +
                  + +
                • - +
                  + +
                -

                Not sure what's your next step? Try our step finder + +

                Not sure what's your next step? Try our step finder and look at milestones calculator.

                +
    +

     

    -

    About This Document

    +

    About This Document

    -

    This resource describes the internal W3C Technical Report +

    This resource describes the internal W3C Technical Report publication processes. A companion document provides more information about roles involved in these processes and interactions with the W3C Communications Team.

    -
    +
    -

    Steps for - transition to - an update request for a - publication of a +

    Steps for + transition to + an update request for a + publication of a publication of an LABEL Snapshot @@ -441,54 +222,40 @@

    Steps for

    - + Once the Process Document requirements for the transition to LABEL have been satisfied (see - section 6.3.5 - section 6.3.7 - section 6.3.8.1 - section 6.3.9 - - section + section 6.3.5 + section 6.3.7 + section 6.3.8.1 + section 6.3.9 + + section 6.3.11.5 and section 6.3.4 - section 6.3.11.3 - section 6.3.11.4 + section 6.3.11.3 + section 6.3.11.4 - section 6.3.10 + section 6.3.10 or section 6.3.12.4 for restoring a Recommendation - section 6.3.12.4 + section 6.3.12.4 - section 6.3.12.4), + section 6.3.12.4), W3C follows the steps described below to complete the transition. - Once the Group determined that the requirements of section 6.3.6 apply, the W3C follows + Once the Group determined that the requirements of section 6.3.6 apply, the W3C follows the steps described below to update a STATUS. - Once the Group, or the Maintainer Contact, determined that the requirements of section 6.3.11.2 apply, the W3C follows + Once the Group, or the Maintainer Contact, determined that the requirements of section 6.3.11.2 apply, the W3C follows the steps described below to update a STATUS. - Once the Group determined that the requirements of section 6.3.8.2 have been + Once the Group determined that the requirements of section 6.3.8.2 have been satisfied, the Working Group follows the steps described below to publish a STATUS. @@ -504,13 +271,11 @@

    Steps for in parallel with the publication request steps.

    -

    +

    Note: If your specification involves (or updates) an Internet Media Type, before the transition to First Public - STATUS, see also How to Register + STATUS, see also How to Register an Internet Media Type for a W3C Specification to review the entire Internet Media Type registration process. @@ -528,8 +293,7 @@

    Steps for

    Note: If your specification defines (or updates) an XPointer - Scheme, before the transition to STATUS, please register the scheme in the W3C XPointer Scheme + Scheme, before the transition to STATUS, please register the scheme in the W3C XPointer Scheme Registry.

    @@ -546,7 +310,7 @@

    Steps for wide review in order to move to Candidate Recommendation. The Group MUST show that all horizontal *-needs-resolution issues have been closed by the relevant - horizontal group in the horizontal group's tracker + horizontal group in the horizontal group's tracker in order to publish the STATUS. The Group MUST show that any horizontal *-needs-resolution issues have been acknowledged in order to publish @@ -559,33 +323,23 @@

    Steps for -
    Transition request
    +
    Transition request
    Update request
    -
    +
    • If an individual - made a request to the relevant Working Group, or the TAG (using w3ctag/obsoletion) if such a group does not exist, + made a request to the relevant Working Group, or the TAG (using w3ctag/obsoletion) if such a group does not exist, to obsolete or to supersederescind a Recommendation, and the request was not answered within 90 days, the individual should send his request to webreq@w3.org, cc'ing plh@w3.org, www-archive@w3.org.
    • -
    • - At least one week prior to an expected +
    • + At least one week prior to an expected decision from or meeting with the Team, the - The Document Contact - - - creates a transition request in w3c/transitions. - For the purpose of the automatic publishing + The Document Contact + + + creates a transition request in w3c/transitions. + For the purpose of the automatic publishing system, it's important that the title of the issue ends with the shortname of your specification, thus you will need one single issue for each specification. Note: @@ -596,86 +350,71 @@

      Steps for sends a transition request to the Team: ralph@w3.org, plh@w3.org, cc'ing ylafon@w3.org, - w3t-comm@w3.org. An issue is also created in w3c/transitions (for tracking purposes). + w3t-comm@w3.org. An issue is also created in w3c/transitions (for tracking purposes). A public archive of transition requests is available (since October 2019). -

    • + -
    • - Following an initial review by the Team, the Document Contact +
    • + Following an initial review by the Team, the Document Contact MAY be asked to organize a transition meeting with the Team to discuss the request.
    • -
    • - +
    • + The Project Management Industry or Strategy Lead approve the transition request. The Lead MAY ask the CEO (or someone assigned by the CEO) to take responsibility for approving the transition request. - + The Team verifies the transition request. - Approvals are expected to appear as an issue comment "Transition - approved." in w3c/transitions + Approvals are expected to appear as an issue comment "Transition + approved." in w3c/transitions and - the label 'Awaiting + the label 'Awaiting Publication' will need to be set. - + In most cases the decision to approve the transition is made on Fridays.
    -
    +
    Publication Planning
    @@ -694,8 +433,7 @@

    Steps for
  • If the publication is the result - of stopping work on a specification, the Document Contact + of stopping work on a specification, the Document Contact alerts the Webmaster at webreq@w3.org, optionally cc'ing w3c-archive@w3.org (which has a Member-visible archive). @@ -704,20 +442,17 @@

    Steps for -
    +
    Form and Announcement Preparation
    -
    Announcement Preparation
    -
    +
    Announcement Preparation
    +
    -
    Publication and Transition Announcement
    +
    Publication and Transition Announcement
    Publication and Update Announcement
    -
    Publication
    +
    Publication
    Transition Announcement
      -
    • The Webmaster completes publication and notifies the Chair - and Team Contact of publication, cc'ing webreq@w3.org +
    • The Webmaster completes publication and notifies the Chair + and Team Contact of publication, cc'ing webreq@w3.org and w3t-comm@w3.org.
    • -
    • The Document +
    • The Document Contact publishes the document using the W3C automatic system.
    • -
    • +
    • After coordination with the Communications Team on the transition announcement timing (especially those accompanied by press releases; see more about @@ -866,15 +582,13 @@

      Steps for Since September 2015, the Communications Team no longer posts homepage news for regular WDs, unless explicitely requested.

    • -
    • +
    • The W3C Communications Team sends the transition announcement to w3c-ac-members@w3.org and chairs@w3.org - and on the W3C home page. + and on the W3C home page. The Advisory Committee review is started. The Call for Exclusions and the Advisory Committee review are started.
    • @@ -884,15 +598,13 @@

      Steps for to chairs@w3.org and on the W3C home page. -
    • The Chair or Team Contact(s) SHOULD forward +
    • The Chair or Team Contact(s) SHOULD forward the announcement to the Working Group's public mailing list taking caution not to send any Member-confidential information to a public list.
    • The - Document Contact SHOULD forward the announcement to the Working + Document Contact SHOULD forward the announcement to the Working Group's public mailing list.
    • @@ -916,39 +628,33 @@

      Steps for

      Note: STATUS - is not a maturity stage defined in the W3C Process but is described as a proposal before the next + is not a maturity stage defined in the W3C Process but is described as a proposal before the next step.

      -
      - -
      -
      -

      Transition Requirements for STATUS

      -

      The decision to advance a document to Recommendation is a - W3C Decision. +


      +

       

      +
      +
      +

      Transition Requirements for STATUS

      +

      The decision to advance a document to Recommendation is a + W3C Decision.

      -

      The Working - GroupW3C:

      +

      The Working + GroupW3C:

        -
      • must record the group’sindividual(s) decision to request advancement. -

        Provide a link to meeting minutes, github issues, or email announcing the decision.

        +
      • must record the group’sindividual(s) decision to request advancement. +

        Provide a link to meeting minutes, github issues, or email announcing the decision.

        -

        For a Recommendation, you may reuse the group's decision to move to +

        For a Recommendation, you may reuse the group's decision to move to Proposed Recommendation.

      • -
      • must obtain Team +
      • must obtain Team verification. -

        Submit a transition request.

        +

        Submit a transition request.

      • -
      • must publicly +
      • must publicly document all new features (class 4 changes) to the technical report @@ -956,12 +662,12 @@

        Transition Requirements for S

        Include a link to a change log where new features are highlighted, highlight them in the Status of the Document.

      • -
      • must not contain new features +
      • must not contain new features (class 4 changes) to the technical report since the Recommendation.
      • -
      • must publicly document if other substantive changes +
      • must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.
        @@ -977,19 +683,15 @@

        Transition Requirements for S whether processors should continue to process content according to the previous Recommendation?

      • If there will be two Recommendations of different major revision numbers, does the newer specification explain the relationship?
      • -
      +

  • -
  • should publicly document if editorial +
  • should publicly document if editorial changes have been made, and may document the details of such changes.
  • -
  • must formally address all issues - raised about the document since the previous maturity level. -
    +
  • must formally address all issues + raised about the document since the previous maturity level. +
    • Include a link to an issues list, such as GitHub issues, that indicates that the group has been responsive to reviewers who have raised issues since the previous transition. The Team's @@ -997,10 +699,9 @@

      Transition Requirements for S has formally addressed each issue.

    • For changes in the issues list since the previous transition:
        -
      • Highlight issues where the Group has declined to make a change, with rationale. See also Clarification: tables - summarizing review, Tim Berners-Lee (Tue, Feb 15 2000). -
      • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded +
      • Highlight issues where the Group has declined to make a change, with rationale. See also Clarification: tables + summarizing review, Tim Berners-Lee (Tue, Feb 15 2000). +
      • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded to the reviewer, or the reviewer has not yet acknowledged the Group's decision.
      • Show, without highlighting:
          @@ -1009,62 +710,52 @@

          Transition Requirements for S reviewer.

      • - +
  • -
  • should formally +
  • should formally address all errata raised about the document since the Recommendation. -

    Include a link to an issues list, such as GitHub issues, that indicates that errata have been +

    Include a link to an issues list, such as GitHub issues, that indicates that errata have been responded.

  • -
  • must provide public documentation of any Formal Objections. +
  • must provide public documentation of any Formal Objections.

    Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.

  • -
  • should report which, if any, of the Working Group'sindividual(s) requirements +
  • should report which, if any, of the Working Group'sindividual(s) requirements for this document have changed since the previous step.
  • -
  • should report any changes in +
  • should report any changes in dependencies with other groups. -
    +
    • In general, documents do not advance to Proposed Recommendation with normative references to other - specifications that are considered unstable. See also Normative References Guidelines.
    • + specifications that are considered unstable. See also Normative References Guidelines.
    • Documents must not include normative references to a Rescinded/Obsolete/Superseded Recommendation.
  • -
  • should - provide information about implementations known to the Working Groupindividual(s). -

    +
  • should + provide information about implementations known to the Working Groupindividual(s).
  • -
  • must provide information about +
  • must provide information about implementations known to the individual(s). -

    See implementation experience

    +

    See implementation experience

  • -
  • must provide information about implementations known to the - Working Groupindividual(s). +
  • must provide information about implementations known to the + Working Groupindividual(s).
      -
    • Unless this information changed since the previous +
    • Unless this information changed since the previous transition, indicate "No change".
    • -
    • Include a link to a final implementation report, or, if there is +
    • Include a link to a final implementation report, or, if there is no such report, rationale why the Team should approve the request nonetheless.
    • -
    • If you use WPT results, provide a snapshot of those results, e.g wpt.fyi +
    • If you use WPT results, provide a snapshot of those results, e.g wpt.fyi snapshot of webauthn (save a copy of the resulting report)
    @@ -1072,43 +763,35 @@

    Transition Requirements for S

  • -
    +

    Requirements for revising a STATUS

    -

    A Working Group should publish a Working Draft to the W3C Technical Reports page +

    A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

    If 6 months elapse without significant changes to a specification, - a Working Group should publish a revised Working Draft, + a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.

    To publish a revision of a Working draft, a Working Group:

      -
    • must record the group’s decision to request publication. Consensus is +
    • must record the group’s decision to request publication. Consensus is not required, as this is a procedural step, -
      +

      Provide a link to meeting minutes, github issues, or email announcing the decision. The decision may be applicable to one or more revisions.

      - This link should be given to the W3C automatic system + This link should be given to the W3C automatic system using the decision parameter.

    • must provide public documentation - of substantive changes to the technical report - since the previous Working Draft, + of substantive changes to the technical report + since the previous Working Draft,
    • should provide public documentation - of significant editorial changes to the technical report + of significant editorial changes to the technical report since the previous step,
    • should report which, @@ -1120,45 +803,39 @@

      Requirements for revising a STATU

    -
    +

    Requirements for updating a STATUS

    -

    WARNING: If your existing Recommendation was not - approved for accepting new features, +

    WARNING: If your existing Recommendation was not + approved for accepting new features, you are not allowed to follow these steps. You MUST follow the First Public Working Draft steps instead.

    -

    The decision to incorporate proposed amendments in a Recommendation is a - W3C Decision. +

    The decision to incorporate proposed amendments in a Recommendation is a + W3C Decision.

    -

    The Working Group:

    -

    The W3C:

    +

    The Working Group:

    +

    The W3C:

      -
    • must obtain Team +
    • must obtain Team verification, or fulfill the criteria for Streamlined Publication Approval.

      Submit an update request.

    • must record the group’s decision to request the update. -

      Provide a link to meeting minutes, github issues, or email announcing the decision.

      +

      Provide a link to meeting minutes, github issues, or email announcing the decision.

    • -
    • must show that the changes - proposed amendments have received wide +
    • must show that the changes + proposed amendments have received wide review. -
      +
      • Was the public requested to review the changes (such as announcement from a previous publication)?
      • Which are the groups with dependencies, per the Group's charter, and did they review the document?
      • -
      • Were the horizontal groups given proper opportunities to review subtantive changes? Are there any *-needs-resolution +
      • Were the horizontal groups given proper opportunities to review subtantive changes? Are there any *-needs-resolution issue pending?
      • Was there early review from implementers? Are the changes already deployed in implementations?
      • -
      • +
      • Streamlined Publication Approval requires, for each of the W3C Horizontal Groups, if the Horizontal Review Group has made available a set criteria under which their review is not necessary, @@ -1168,15 +845,12 @@

        Requirements for updating a STATU

      - Proposed amendments can only be incorporated as-is, per section 6.3.11.5. + Proposed amendments can only be incorporated as-is, per section 6.3.11.5.

    • -
    • - Streamlined Publication Approval requires the group to formally address: +
    • + Streamlined Publication Approval requires the group to formally address:
      • all issues raised against the document that resulted in changes since the previous publication

        @@ -1193,24 +867,22 @@

        Requirements for updating a STATU of the person who raised it: their proposal has been accepted, or a compromise has been found, - or they accepted the Working Group’s rationale for rejecting it. This implies no pending *-needs-resolution issues, + or they accepted the Working Group’s rationale for rejecting it. This implies no pending *-needs-resolution issues, and no pending PAG conclusions.

      • -
      • must provide public documentation of any Formal +
      • must provide public documentation of any Formal Objections.
        • Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.
        • -
        • +
        • Streamlined Publication Approval requires no formal objection have been registered.
        • -
        +
    -
  • must publicly document of all new +
  • must publicly document of all new features (class 4 changes) to the technical report @@ -1226,33 +898,30 @@

    Requirements for updating a STATU must not happen, unless it was a proposed amendment.

  • -
  • should publicly document if editorial +
  • should publicly document if editorial changes changes have been made, and may document the details of such changes.
  • must show that the revised specification - meets all Working Group requirements, + meets all Working Group requirements, or explain why the requirements have changed or been deferred,
    • Where are the requirements defined (e.g,. a charter or requirements document)?
    • Are any requirements previously satisfied no longer satisfied? Are any requirements previously unsatisfied now satisfied?
    • -
    • +
    • Streamlined Publication Approval requires no changes to Working Group requirements.
  • -
  • should report which, if any, of the Working Group's +
  • should report which, if any, of the Working Group's requirements for this document have changed since the previous step.
      -
    • +
    • Streamlined Publication Approval requires no changes to Working Group requirements.
    @@ -1260,19 +929,17 @@

    Requirements for updating a STATU

  • should report any changes in dependencies with other groups.
  • -
  • should provide information about implementations known to the Working Group. +
  • should provide information about implementations known to the Working Group.
  • -
    +
    • must show that the specification - has met all Working - Groupindividual(s) + has met all Working + Groupindividual(s) requirements, or explain why the requirements have changed or been deferred,
      @@ -1289,8 +956,7 @@

      Requirements for updating a STATU
    • Does this specification have any normative references to other specifications that are not yet stable? The Team's expectations are that, as a document advances, there will be an increasingly need - for normative referenced materials to be scrutinized. See Normative References Guidelines. + for normative referenced materials to be scrutinized. See Normative References Guidelines.
    • Does this specification have any normative references to a Rescinded/Obsolete/Superseded Recommendation? Documents must not include normative references to a @@ -1308,10 +974,9 @@

      Requirements for updating a STATU

    • must document - how adequate implementation experience will be demonstrated, + how adequate implementation experience will be demonstrated, -
      +

      This is also known as "CR exit criteria".

      • Are there tests or test suites available that will allow the WG to demonstrate/evaluate that features @@ -1328,12 +993,9 @@

        Requirements for updating a STATU

    • -
    • may identify features in the document as at risk. +
    • may identify features in the document as at risk. These features may be removed - before advancement to Proposed Recommendation without a requirement to publish a new Candidate + before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

      If any, the list of features at-risk must appear in the Status of the Document.

      @@ -1343,10 +1005,9 @@

      Requirements for updating a STATU and should be longer for complex documents, and,

      This deadline must appear in the Status of the Document.

    • -
    • must show that the specification has received wide +
    • must show that the specification has received wide review. -
      +
      @@ -1365,7 +1025,7 @@

      Requirements for updating a STATU

      -
      +
        @@ -1374,12 +1034,9 @@

        Requirements for updating a STATU and should be longer for complex documents,

        This deadline must appear in the Status of the Document.

        -
      • may identify features in the document as at risk. +
      • may identify features in the document as at risk. These features may be removed - before advancement to Proposed Recommendation without a requirement to publish a new Candidate + before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.

        The list of features at-risk must appear in the Status of the Document, if any.

        @@ -1387,13 +1044,10 @@

        Requirements for updating a STATU

      -
      -

      Requirements for publishing a STATUS

      +
      +

      Requirements for publishing a STATUS

      -

      A Working Group should publish an Update Draft to the W3C +

      A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document @@ -1402,29 +1056,23 @@

      Requirements for publishing a The Working Group:

      -
      -

      Updating a STATUS with editorial changes

      +
      +

      Updating a STATUS with editorial changes

      The Working Group:

      -
      +

      Requirements for requesting a STATUS

      The request:

        @@ -1663,35 +1272,32 @@

        Requirements for requesting a STATUS

        a link to meeting minutes, github issues, or email announcing the decision).

        -
      • must include rationale for the proposal.
      • +
      • must include rationale for the proposal.
      • must provide the Document title and URLs of the newer version, if any.
      • -
      • must identify known dependencies.
      • -
      • should provide information about known +
      • must identify known dependencies.
      • +
      • should provide information about known implementations.
      • -
      • should publish documentation of significant changes to +
      • should publish documentation of significant changes to the technical report since any previous publication.
      -

      +

      The Team must then submit the request to the Advisory Committee for review.

      -
      -

      Transition requirements to STATUS

      +
      +

      Transition requirements to STATUS

      The W3C:

        -
      • must obtain Team +
      • must obtain Team verification. -

        Submit a transition request.

        +

        Submit a transition request.

      • -
      • must formally +
      • must formally address all issues - raised about the document since the previous maturity level. -
        + raised about the document since the previous maturity level. +
        • Include a link to an issues list, such as GitHub issues, that indicates that the group has been responsive to reviewers who have raised issues since the previous transition. The Team's expectations @@ -1699,10 +1305,9 @@

          Transition requirements to STA addressed each issue.

        • For changes in the issues list since the previous transition:
            -
          • Highlight issues where the Group has declined to make a change, with rationale. See also Clarification: tables - summarizing review, Tim Berners-Lee (Tue, Feb 15 2000). -
          • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded to +
          • Highlight issues where the Group has declined to make a change, with rationale. See also Clarification: tables + summarizing review, Tim Berners-Lee (Tue, Feb 15 2000). +
          • Highlight issues where the Group has not satisfied a reviewer and has either not yet responded to the reviewer, or the reviewer has not yet acknowledged the Group's decision.
          • Show, without highlighting:
              @@ -1711,25 +1316,22 @@

              Transition requirements to STA reviewer.

          • - +
      • -
      • must provide public documentation of any Formal Objections. +
      • must provide public documentation of any Formal Objections.

        Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.

      • If there was any dissent in Advisory Committee reviews, - the Team must publish the substantive content of the dissent + the Team must publish the substantive content of the dissent to W3C and the general public, - and must formally address the comment + and must formally address the comment at least 14 days before publication as a W3C Recommendation.
        @@ -1742,18 +1344,14 @@

        Transition requirements to STA
      • Provide link(s) to the Advisory Committee reviews, issues where the dissent was made public, and where the comment was addressed.
      -
    • +
    -
    -

    Transition requestUpdate Request

    +
    +

    Transition requestUpdate Request

    Tip: When updating an existing Candidate Recommendation, focus your new request on what @@ -1761,45 +1359,37 @@

    +

    An First Public STATUS - transitionupdate request MUST + transitionupdate request MUST include:

      -
    1. Document title, URIs, and estimated +
    2. Document title, URIs, and estimated publication date.
    3. The document Abstract and Status sections, either by reference (e.g., the URL to the document) or direct inclusion.
    4. -
    5. +
    6. A statement whether or not the group considers the document to be a delta specification.
    7. -
    8. Fulfill the requirements for the Advancement on the Recommendation Track.
    9. -
    10. Fulfill the requesting the STATUS.
    11. -
    12. Fulfill the requirements for the update request.
    13. +
    14. Fulfill the requirements for the Advancement on the Recommendation Track.
    15. +
    16. Fulfill the requesting the STATUS.
    17. +
    18. Fulfill the requirements for the update request.
    19. Has anything changed on the patent disclosure page since the previous transition? Have there been any incomplete or problematic disclosures?

    -
    +

    Transition Meeting with the Team

    @@ -1810,8 +1400,7 @@

    Transition
    • The Team contact(s)
    • -
    • The Maintainer Contact
    • +
    • The Maintainer Contact
    • The Project Management Lead (or someone appointed by him), who generally chairs the meeting.
    • @@ -1822,18 +1411,13 @@

      Transition transition involves contentious issues such as IPR, technical or other concerns. -
    • The Working Group Chair(s)individual(s)
    • +
    • The Working Group Chair(s)individual(s)
    • -
    • Others invited by the Project Management Lead (or whoever is +
    • Others invited by the Project Management Lead (or whoever is chairing the transition meeting)
    • -
    • In the event that the specification significantly affects the +
    • In the event that the specification significantly affects the work of another WG, a (non-Team) representative of that Group should be invited to the call.
    • @@ -1864,7 +1448,7 @@

      Transition -

      Sample agenda

      +

      Sample agenda

      Administrative
      @@ -1909,8 +1493,7 @@

      Sample agenda

    • If the decision is positive: how do we announce this decision? when? what is the plan and schedule for any - communications opportunities, including Member + communications opportunities, including Member testimonials? any action items from this meeting?
    • @@ -1920,15 +1503,13 @@

      Sample agenda

      Some reasons for declining a transition request

        -
      • - The Team is not satisfied after its verification with how the Working Group fulfilled +
      • + The Team is not satisfied after its verification with how the Working Group fulfilled the requirements for advancement.
      • -
      • +
      • The Working Group has issued a transition request despite a - Formal Objection and the Council is not + Formal Objection and the Council is not satisfied with the Working Group's rationale.
      • @@ -1947,8 +1528,7 @@

        Some reasons for declining a transition request

      -

      Per section 6.3.13.4, in some conditions, the +

      Per section 6.3.13.4, in some conditions, the Team is required to accept the transition request.

      @@ -1963,26 +1543,19 @@

      Some reasons for declining a transition request

    -
    +
    -

    - Scheduling Publication -

    +

    Scheduling Publication

    -

    - Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the +

    + Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the Webmaster and are not subjected to publishing moratoria.

    -

    7 days for transition: Unless there are exceptional - circumstances, the Team requires a minimum of 7 days period between the transition request and the publication. +

    7 days for transition: Unless there are exceptional + circumstances, the Team requires a minimum of 7 days period between the transition request and the publication. - This allows other Groups or outside individuals to review the transition request and may formally object within this period. + This allows other Groups or outside individuals to review the transition request and may formally object within this period. While the Team strives to address transitions within this 7 days period, delays due to transition issues or competing Team's priorities are not unheard of and may increase the length of the period needed. Group @@ -1994,14 +1567,13 @@

    Please send advance notice to webreq@w3.org: -

      +

      • 3 business days in advance: If you need help from the Webmaster to fix errors, or ask for Pubrules error exception.
      • 2 business days in advance: If the document is perfectly ready.
      -

      -

      Publication Request

      +

      Publication Request

      Note: Someone from the W3C @@ -2012,8 +1584,8 @@

      Publication Request

      A publication request MUST include the following information:
      ⟶ You may copy the list below and paste into the email sent to webreq@w3.org -

      -

        +

        +

        1. Information:
          • Document Title: xxx xxx
          • @@ -2038,7 +1610,7 @@

            Publication Request

            *Document tags update: (see the list of tags here) -
          • *Retired: (only needed when 'yes')
            +
          • *Retired: (only needed when 'yes')
            ⟶ Indicate if the publication is the result of stopping work on a specification (aka "retired").
          • @@ -2047,65 +1619,56 @@

            Publication Request

          • Approvals:
              -
            • Record of +
            • Record of approval of the transition request.
            • -
            • Record of approval of the +
            • Record of approval of the update request.
            • Record of W3M decision to close the group.
            • -
            • Team's approval state: +
            • Team's approval state: (approved / not yet / not needed)
            • Evidence that publication is in accordance with expectations set by the group charter (e.g., quote the charter).
            • -
            • Record of +
            • Record of approval of the Group.
          • *Skip CfE for CR text delete: (only needed when 'yes')
            ⟶ If there has been a previous Candidate Recommendation, whether the only change is - that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ). + that text has been deleted; If so, W3C can skip the Patent Policy Exclusion (see the Patent Policy FAQ).
          • Checks:
            • Pass Pubrules' check: (yes / need Team's exception) -
              ⟶ Check the document using Pubrules +
              ⟶ Check the document using
              Pubrules UI
              . -
              ⟶ How to deal with Pubrules' result: +
              ⟶ How to deal with Pubrules' result:.
                -
              • error: should not contain any `error`, unless it's an - exception approved by the Team. This could likely block publication
              • -
              • warning: Please read through each warning and try to reduce the number of them. -
              • +
              • error: should not contain any `error`, unless it's an + exception approved by the Team. This could likely block publication
              • +
              • warning: Please read through each warning and try to reduce the number of them. +
              -
            • *Comment on Pubrules: (describe the help you need if there's any error)
            • Pass Link Checker's check: (yes) -
              ⟶ Check the document using W3C +
              ⟶ Check the document using
              W3C Link Checker
              . -
              ⟶ How to deal with result of Link Checker: +
              ⟶ How to deal with result of Link Checker:
                -
              • 404 Not Found: should not contain any `404` link. - This could likely block publication.
              • -
              • 403 Forbidden: Please check manually.
              • -
              • Broken Fragments: These kind of error could be false alarm, please check manually. -
              • -
              • Status: 301: Please consider using the new link.
              • +
              • 404 Not Found: should not contain any `404` link. + This could likely block publication.
              • +
              • 403 Forbidden: Please check manually.
              • +
              • Broken Fragments: These kind of error could be false alarm, please check manually.
              • +
              • Status: 301: Please consider using the new link.
              -
        -

        It is perfectly appropriate to send a publication while waiting for a Team's approval but does run the risk of not receiving @@ -2129,15 +1692,13 @@

        Publication Request

        these publishing moratoria with approximately six months notice. The announcements are linked from the Chairs' Guidebook.

        -

        Publication

        +

        Publication

        In order to ensure publication standards, upon receiving a publication request the Webmaster SHALL make a best effort to verify that the document satisfies the pubrules - requirements except for the accessibility requirements of section 7. The Webmaster SHALL publish the document (cf. the + requirements except for the accessibility requirements of section 7. The Webmaster SHALL publish the document (cf. the Webmaster's guide) if the following conditions have been met:

        @@ -2162,7 +1723,7 @@

        Publication

      1. The publication request is complete, and
      2. The document indicates clearly its new status verified by the Webmaster. The updated version may remove the main body of the - document.
      3. + document.

    Otherwise the Webmaster SHALL NOT @@ -2177,8 +1738,7 @@

    Publication

    -
    +

    Transition Announcement

    An @@ -2219,8 +1779,7 @@

    Transition Announcement

    -
    +
    1. That this is a STATUS @@ -2233,7 +1792,7 @@

      Transition Announcement

    2. Review end date.
    3. -
    4. Link to information about the review; this is the link +
    5. Link to information about the review; this is the link to an online review form (WBS) created by the Team Contact. The following information from the transition request MUST be available (generally in the @@ -2247,7 +1806,7 @@

      Transition Announcement

    6. implementation information
    7. information about changes
    8. -
    9. information about obsoleting or superseding previous Recommendations, if applicable. +
    10. information about obsoleting or superseding previous Recommendations, if applicable. This avoids sending an additional WBS survey just for the purpose of obsoleting/superseding a Recommendation.
    11. information about wide review
    12. @@ -2260,8 +1819,7 @@

      Transition Announcement

    -

    Please use the Team-only +

    Please use the Team-only transition announcement template as a starting point.

    @@ -2294,8 +1852,7 @@

    Transition Announcement

  • Document abstract and status.
  • -

    Please use the Team-only +

    Please use the Team-only transition announcement template as a starting point.

    @@ -2316,7 +1873,7 @@

    Transition Announcement

    -
    +
    1. That this is an STATUS @@ -2341,18 +1898,15 @@

      Transition Announcement

    -

    Please use the Team-only +

    Please use the Team-only transition announcement template as a starting point.

    -

    Please use the Team-only +

    Please use the Team-only transition announcement template as a starting point.

    -
    +
    1. That this is a First Public @@ -2369,8 +1923,7 @@

      Transition Announcement

    -
    +

    Call for Exclusions

    The Patent Policy FAQ clarifies @@ -2378,62 +1931,53 @@

    Call for Exclusions

    out.

    -

    +

    The Team sends a Call for Exclusion to participants. The exclusion opportunity lasts 150 days. At approximately 90 days, The Team sends out a reminder with a pointer to the "Patent Review Draft".

    -

    +

    If the document was published within 90 days of the First Public Working Draft, it becomes the new Patent Review Draft for the Call for Exclusions started at the time of the First Public Working Draft publication. - Exclusions are with respect to the set of features in this new STATUS. + Exclusions are with respect to the set of features in this new STATUS.

    - A Working Group under the W3C Patent Policy publishes a STATUS. + A Working Group under the W3C Patent Policy publishes a STATUS. The Team sends the second exclusion opportunity. The exclusion opportunity lasts 60 days. Any exclusions are with respect - to new features in the STATUS added since the exclusion + to new features in the STATUS added since the exclusion opportunity of the First Public Working Draft.

    - The Working Group changes the document substantially after STATUS and published a - new STATUS. The Team sends a new exclusion opportunity. It lasts 60 + The Working Group changes the document substantially after STATUS and published a + new STATUS. The Team sends a new exclusion opportunity. It lasts 60 days. Exclusions are with respect to new features in the specification since the previous exclusion - opportunity, i.e., the previous LABEL. + opportunity, i.e., the previous LABEL.

    The Working Group updates the document substantially since the Recommendation and published a - STATUS. The Team sends a exclusion opportunity. It lasts 60 + STATUS. The Team sends a exclusion opportunity. It lasts 60 days. Exclusions are with respect to new features in the specification since the previous exclusion opportunity, i.e., the one applying to the previous Recommendation.

    The Working Group proposes to update the document substantially since the Recommendation and published a - STATUS with proposed changes. The Team sends a exclusion opportunity. It lasts 60 - days. Exclusions are with respect to the proposed changes identified in the + STATUS with proposed changes. The Team sends a exclusion opportunity. It lasts 60 + days. Exclusions are with respect to the proposed changes identified in the specification.

    -
    -
    -

    Feedback is to @w3c/transitions - and is welcome on GitHub

    - - - + + \ No newline at end of file From 253b8f4da7db3abbf3a318c50a5f77580983194e Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 12:17:51 +0100 Subject: [PATCH 151/225] Fix links --- incubation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/incubation.md b/incubation.md index 0b099e7eb..1367cb6b8 100644 --- a/incubation.md +++ b/incubation.md @@ -9,7 +9,7 @@ Incubation is a way of exploring some new aspect of the Open Web Platform when t It enables exploration of novel work, without overly diffusing the effort of a Working Group or expending a lot of resources on work that is ultimately abandoned. -One possible result of incubation is the [transfer of work to a Working Group, for Standards-track development](process/cg-transition.html). Work might also be forwarded to another group in liaison with W3C. Another possible result is the conclusion that this is a promising area of work, but that a number of prerequisites exist which should be solved first. Finally, incubators might conclude that no Standards-track work should be done in the area. This is still a valuable result, as it can reduce the effort expended on unfruitful options. +One possible result of incubation is the [transfer of work to a Working Group, for Standards-track development](process/cg-transition.md). Work might also be forwarded to another group in liaison with W3C. Another possible result is the conclusion that this is a promising area of work, but that a number of prerequisites exist which should be solved first. Finally, incubators might conclude that no Standards-track work should be done in the area. This is still a valuable result, as it can reduce the effort expended on unfruitful options. ## Venues for incubation @@ -43,11 +43,11 @@ An emerging pattern is, when chartering a Working Group, to use a CG to handle i If work has already been explored by one or more W3C Members, a Member Submission can be an effective way to bring the work to wider review. Like other incubation methods, a Submission is not a guarantee that Standards-track work will take place in the area. The likelihood of success is increased if there is already developer interest, and if royalty-free commitments to known patents are made along with the submission. -[Member Submission Process](/policies/process/#Submission) +[Member Submission Process](https://www.w3.org/policies/process/#Submission) ### W3C Workshop -A [W3C Workshop](meetings/workshops.html) can be a good way to bring a new community together and, if consensus is reached on some new area, the workshop report may suggest next steps including creation of a CG, or even passing the work to a new or existing Working Group. +A [W3C Workshop](meetings/workshops.md) can be a good way to bring a new community together and, if consensus is reached on some new area, the workshop report may suggest next steps including creation of a CG, or even passing the work to a new or existing Working Group. ### A Working Group From a3d9bc4d10b37827930eec6aafc0ed65d41fd518 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 12:18:43 +0100 Subject: [PATCH 152/225] Fix links --- chair/buddy.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/chair/buddy.md b/chair/buddy.md index af78b8434..1660c3459 100644 --- a/chair/buddy.md +++ b/chair/buddy.md @@ -5,14 +5,13 @@ toc: true The [Working Group effectiveness Task Force](https://github.com/w3c/wg-effectiveness) helped establish a Chair Buddy System by which experienced Chairs can volunteer as buddy-mentors to help buddy-mentees Chairs. -Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies@w3.org) ([Member-only archive](https://lists.w3.org/Archives/Member/member-chairbuddies/)[). Chairs have access to their contact information via the]() [Chairs group](https://www.w3.org/2000/09/dbwg/details?group=31972). +Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies@w3.org) ([Member-only archive](https://lists.w3.org/Archives/Member/member-chairbuddies/)). Chairs have access to their contact information via the [W3C groups listing](https://www.w3.org/groups/). ## Principles - This program is under the responsibility of the [W3C Project Lead](https://www.w3.org/staff/project/). - W3C Chairs self-declare as Mentors or Mentees by writing to [chairbuddies@w3.org](mailto:chairbuddies@w3.org). - - - Ideally, they add their names to this page by [editing it on GitHub](https://github.com/w3c/Guide/edit/main/chair/buddy.md). + - Ideally, they add their names to this page by [editing it on GitHub](https://github.com/w3c/guide/edit/main/chair/buddy.md). - The W3C Project Lead proceeds to pairing those who request to have a buddy, with those who volunteer to be a buddy. ## Buddy-Mentors @@ -22,8 +21,7 @@ Thank-you for agreeing to be a W3C Chair Buddy! You should have been assigned yo - Email your buddy-mentee and introduce yourself! It helps if you give some details on your chair experience, some general W3C experience, and what groups you have interests in. - Arrange an initial meeting with your buddy-mentee. This can be a teleconference, or face-to-face if you're lucky to live in the same area or are participating in the same meeting. - Buddy meetings can be managed however you wish, some guidelines are given below: - - - Ask questions such as "how long have you been chairing?", "what is the size of your group?", "how many chairs are there?", "what are you group working practices?", "how do you manage and conduct meetings?", "how many documents and editors do you have?", "what are your document timelines?", "tell me about your editors / participants", "where are your participants based?". + - Ask questions such as "how long have you been chairing?", "what is the size of your group?", "how many chairs are there?", "what are your group working practices?", "how do you manage and conduct meetings?", "how many documents and editors do you have?", "what are your document timelines?", "tell me about your editors / participants", "where are your participants based?". - Finding out as much as you can about your buddy-mentee will allow you to give the best advice! - Try to speak to your buddy-mentee every quarter. The job of arranging meetings should be with the buddy-mentee, but it doesn't hurt to send them a quick email every so often! @@ -41,7 +39,6 @@ Thank-you for joining the W3C Chair Buddy system! As a buddy-mentee you should h - Email your buddy-mentor and introduce yourself! Give details on the group you chair, whether you have a co-chair, and some quick details on the specs you're working on and the size of your group. - Arrange an initial meeting with your buddy-mentor. This can be a teleconference, or face-to-face if you're lucky to live in the same area or are participating in the same meeting. - Buddy meetings can be managed however you wish, some guidelines are given below: - - You should be giving your buddy-mentor as much information as possible about your current chairing situation, this will help them give you the best advice! - You should also bring with you a list of your own questions, here are some examples: "how do you manage consensus when one or few people are blocking?", "how do you manage meetings when participants are so distributed?", "how can I help my editors get to work?", etc. - Try to speak to your buddy-mentor every quarter, but you may speak to them more infrequently or frequently depending on what works for you and your buddy-mentor. In yuor initial meeting try to discuss a schedule for meetings (even if you decide to do ad-hoc meetings) then arrange the meetings by sending calendar invites (or another method of your choosing). From 0cf6155e49efb2940878dd4fe543e90c3ba0d801 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 12:26:09 +0100 Subject: [PATCH 153/225] Update links --- chair/meetings.md | 56 +++++++++++++++++++++++------------------------ 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/chair/meetings.md b/chair/meetings.md index 1ccd0e2a0..e23879fcc 100644 --- a/chair/meetings.md +++ b/chair/meetings.md @@ -3,69 +3,69 @@ title: Chairs Meetings toc: false --- -{% include quote.html content="I am overwhelmed by the level of talent and dedication in this group." footer="[Tim Berners-Lee](https://www.w3.org/People/Berners-Lee), at the [Nov 97 WG chairs' meeting](../Member/9711/wg-chairs.html)" %} +{% include quote.html content="I am overwhelmed by the level of talent and dedication in this group." footer="[Tim Berners-Lee](https://www.w3.org/People/Berners-Lee/), at the [Nov 97 WG chairs' meeting](https://www.w3.org/Member/9711/wg-chairs.html)" %} We met originally in November 1997 to facilitate shared context among the W3C Working Group Chairs and the W3C Team. We did a few more face-to-face meetings and several teleconferences. -See also the [technical plenary history](../2002/09/TPOverview.html) +See also the [technical plenary history](https://www.w3.org/events/tpac/) 20 Nov 1997 -: [1st Working Group Chairs Meeting](../Member/9711/wg-chairs.html) -- [Press and Communications](../Member/Talks/971120Press) -- Sally's presentation -- [Organizing a W3C Meeting](../meetings/hosting.html) -- Susan's presentation +: [1st Working Group Chairs Meeting](https://www.w3.org/Member/9711/wg-chairs.html) +- [Press and Communications](https://www.w3.org/Member/Talks/971120Press) -- Sally's presentation +- [Organizing a W3C Meeting](../meetings/hosting.md) -- Susan's presentation - [Tim Berners-Lee's Perspective](/Member/9711/wg-chairs-intro.html) -- [The Web: Sharing, Group Memory, and Communication](WebSharing.html) -- Dan's presentation +- [The Web: Sharing, Group Memory, and Communication](https://www.w3.org/OldGuide/WebSharing.html) -- Dan's presentation 13 Jul 1998 -: [The Art of Consensus II](/1998/07/chairs.html) +: [The Art of Consensus II](https://www.w3.org/1998/07/chairs.html) 24 Sep 1998 -: [3rd meeting record](/1998/09/24-chairs.html) +: [3rd meeting record](https://www.w3.org/1998/09/24-chairs.html) 1 Dec 1998 -: [4th meeting record](/1998/12/01-chairs.html) +: [4th meeting record](https://www.w3.org/1998/12/01-chairs.html) 2 Feb 1999 -: [5th meeting record](/1999/02/02-chairs.html) +: [5th meeting record](https://www.w3.org/1999/02/02-chairs.html) 6 Apr 1999 -: [6th meeting record](/1999/04/06-chairs.html) +: [6th meeting record](https://www.w3.org/1999/04/06-chairs.html) 8 June 1999 -: [7th meeting record](/1999/06/08-chairs.html) +: [7th meeting record](https://www.w3.org/1999/06/08-chairs.html) 7 Sep 1999 -: [8th meeting record](/1999/09/chairs56.html) +: [8th meeting record](https://www.w3.org/1999/09/chairs56.html) 16 Nov 1999 -: [9th meeting record](/1999/11/chairs298.html) +: [9th meeting record](https://www.w3.org/1999/11/chairs298.html) 15 Sep 2000 -: [10th meeting record](/2000/09/ch53) +: [10th meeting record](https://www.w3.org/2000/09/ch53.html) 20 Nov 2000 -: [11th meeting](/2000/11/ch64.html) +: [11th meeting](https://www.w3.org/2000/11/ch64.html) 29 Jan 2001 -: 12th meeting [agenda](https://lists.w3.org/Archives/Member/chairs/2001JanMar/0041.html), [IRC log](/2001/01/29-chairs-irc) +: 12th meeting [agenda](https://lists.w3.org/Archives/Member/chairs/2001JanMar/0041.html), [IRC log](https://www.w3.org/2001/01/29-chairs-irc) 28 February 2001 -: [Technical Plenary](/2001/02/allgroupoverview.html#Agenda1) ([plenary day agenda](/2001/02/Plenary/Agenda.html)) +: [Technical Plenary](https://www.w3.org/2001/02/allgroupoverview.html#Agenda1) ([plenary day agenda](https://www.w3.org/2001/02/Plenary/Agenda.html)) Feb 2002 : [Tech Plenary Feb 25-March 1 2002](https://www.w3.org/2001/07/allgroupoverview) ([announcement](https://lists.w3.org/Archives/Member/chairs/2001JulSep/0034.html)) 23 Apr 2002 -: Steve Bratt re-starts chairs meetings. [IRC log](/2002/04/23-chairs-irc) +: Steve Bratt re-starts chairs meetings. [IRC log](https://www.w3.org/2002/04/23-chairs-irc) 25 Jul 2002 : [meeting record](https://lists.w3.org/Archives/Member/chairs/2002JulSep/0047.html). (50+ participants!) 21 Jan 2003 -: [meeting record](../2003/01/21-chairs-notes.html) ([6 Feb from C. M. Sperberg-McQueen](https://lists.w3.org/Archives/Member/chairs/2003JanMar/0032.html)) +: [meeting record](https://www.w3.org/2003/01/21-chairs-notes.html) ([6 Feb from C. M. Sperberg-McQueen](https://lists.w3.org/Archives/Member/chairs/2003JanMar/0032.html)) 3-7 March 2003 in Cambridge, MA, USA -: [Tech Plenary](/2002/10/allgroupoverview.html) +: [Tech Plenary](https://www.w3.org/2002/10/allgroupoverview.html) 6 May 2003 Chairs meeting : [minutes](https://www.w3.org/2003/05/06-chair-notes.html) @@ -74,16 +74,16 @@ Feb 2002 : [minutes](https://www.w3.org/2003/10/31-chair-notes.html), [IRC log](https://www.w3.org/2003/10/30-chair-irc) 3 March 2004 -: [Technical Plenary](/2003/08/allgroupoverview.html) ([plenary day minutes](/2004/03/plenary-minutes), [Chairs Breakfast announcement](https://lists.w3.org/Archives/Member/chairs/2004JanMar/0075)) +: [Technical Plenary](https://www.w3.org/2003/08/allgroupoverview.html) ([plenary day minutes](https://www.w3.org/2004/03/plenary-minutes), [Chairs Breakfast announcement](https://lists.w3.org/Archives/Member/chairs/2004JanMar/0075)) 2 September 2004 -: [minutes](/2004/09/02-chair-minutes.html) +: [minutes](https://www.w3.org/2004/09/02-chair-minutes.html) 2 March 2005 -: [Technical Plenary Week 2005](../2004/12/allgroupoverview.html) in Boston ([minutes](https://www.w3.org/2005/03/plenary-minutes)) +: [Technical Plenary Week 2005](https://www.w3.org/2004/12/allgroupoverview.html) in Boston ([minutes](https://www.w3.org/2005/03/plenary-minutes)) 2 March 2005 -: [Technical Plenary 2006](/2005/12/allgroupoverview.html) in Cannes-Mandelieu ([minutes](/2006/03/TP-minutes.html)) +: [Technical Plenary 2006](https://www.w3.org/2005/12/allgroupoverview.html) in Cannes-Mandelieu ([minutes](https://www.w3.org/2006/03/TP-minutes.html)) 13 March 2007 : Chairs Call Teleconference ([minutes](https://lists.w3.org/Archives/Member/chairs/2007JanMar/0128)) @@ -95,16 +95,16 @@ Feb 2002 : [TPAC 2007 in Boston](https://www.w3.org/2007/11/07-TechPlenAgenda.html) ([minutes](https://www.w3.org/2007/11/07-tp-minutes.html)) 17 April 2008 -: [agenda](https://lists.w3.org/Archives/Member/chairs/2008AprJun/0022.html), [minutes](/2008/04/17-chairs-minutes.html) +: [agenda](https://lists.w3.org/Archives/Member/chairs/2008AprJun/0022.html), [minutes](https://www.w3.org/2008/04/17-chairs-minutes.html) 1 October 2008 : [agenda](https://www.w3.org/2008/10/01-chairs-minutes.html), [minutes](https://www.w3.org/2008/10/01-chairs-minutes.html) 22 October 2008: TPAC 2008 -: [agenda](https://www.w3.org/2008/10/TPAC/TPDay-Agenda.html), [minutes](/2008/10/22-tp-minutes.html) +: [agenda](https://www.w3.org/2008/10/TPAC/TPDay-Agenda.html), [minutes](https://www.w3.org/2008/10/22-tp-minutes.html) 15 September 2009: Chairs teleconference -: [agenda](https://lists.w3.org/Archives/Member/chairs/2009JulSep/0044.html), [minutes](/2009/09/15-chairs-minutes) +: [agenda](https://lists.w3.org/Archives/Member/chairs/2009JulSep/0044.html), [minutes](https://www.w3.org/2009/09/15-chairs-minutes) 3 November 2010: TPAC 2010 : [agenda](https://www.w3.org/2010/11/TPAC/PlenaryAgenda#details), [minutes](https://www.w3.org/2010/11/03-tpac-minutes) From 392832f717aec7be9f282168f4225c4eb1bda134 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 12:31:58 +0100 Subject: [PATCH 154/225] Update links --- chair/role.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/chair/role.md b/chair/role.md index 2a080ee92..0d961eb4d 100644 --- a/chair/role.md +++ b/chair/role.md @@ -3,23 +3,23 @@ title: W3C Working/Interest Group Chair toc: true --- -The [W3C Team](https://www.w3.org/Process#ref-for-team%E2%91%A2%E2%91%A6) appoints (or re-appoints) a Chair (or more than one co-Chair) for every Working Group and Interest Group ("Group"). The Chair's primary role is to facilitate [consensus](/policies/process/#Consensus)-building among Group members. The Chair works together with the W3C [Staff Contact](../teamcontact/role.html). Key roles of the Group Chair are listed below. Additional information on the role of the Group Chair is in the [W3C Process Document](/policies/process/#general-requirements). +The [W3C Team](https://www.w3.org/policies/process/#ref-for-team%E2%91%A2%E2%91%A6) appoints (or re-appoints) a Chair (or more than one co-Chair) for every Working Group and Interest Group ("Group"). The Chair's primary role is to facilitate [consensus](https://www.w3.org/policies/process/#Consensus)-building among Group members. The Chair works together with the W3C [Staff Contact](../teamcontact/role.md). Key roles of the Group Chair are listed below. Additional information on the role of the Group Chair is in the [W3C Process Document](https://www.w3.org/policies/process/#general-requirements). ## Chair Buddy System The [Working Group effectiveness Task Force](https://github.com/w3c/wg-effectiveness) helped establish a Chair Buddy System by which experienced buddy-mentors help buddy-mentees. -Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies@w3.org) ([Member-only archive](https://lists.w3.org/Archives/Member/member-chairbuddies/)) and visit the dedicated [Chair Buddy System page](buddy.html). +Interested parties should visit the dedicated [Chair Buddy System page](buddy.md). ## Role of the Group Chair ### Creates Group charter and convenes Group -- [Develops Group charter](/policies/process/#WGCharterDevelopment) together with the Staff Contact. -- Is familiar with the [W3C Process](/policies/process/), the [W3C Code of Conduct](/policies/code-of-conduct/), the [Antitrust and competition policy](/policies/antitrust/), and [Guidebook](/Guide). -- Convenes Group and ensures Group members oriented to [W3C Process](/policies/process/) *with assistance of Staff Contact.* +- [Develops Group charter](https://www.w3.org/policies/process/#WGCharterDevelopment) together with the Staff Contact. +- Is familiar with the [W3C Process](https://www.w3.org/policies/process/), the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/), the [Antitrust and competition policy](https://www.w3.org/policies/antitrust/), and [Guidebook](..). +- Convenes Group and ensures Group members oriented to [W3C Process](https://www.w3.org/policies/process/) *with assistance of Staff Contact.* - Schedules deliverables and sets milestones towards completion of deliverables. -- Appoints document editors. (NOTE: [Editors](https://www.w3.org/2003/Editors/) are responsible for ensuring that Group decisions are correctly reflected in Group documents, and for maintaining an issue list.) +- Appoints document editors. (NOTE: [Editors](../editor/) are responsible for ensuring that Group decisions are correctly reflected in Group documents, and for maintaining an issue list.) - Proposes invited experts *with assistance of Staff Contact* (W3C staff must be involved in decisions regarding inclusion/exclusion of participants). Makes sure that all participants have filled out a call for participation and have disclosed their IPR in accordance with W3C process. - (If there is a Co-chair) Establishes clear and close coordination with Co-chair. @@ -39,8 +39,8 @@ Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies - Judges items in or out of scope for the Group. - Generally stays neutral in discussion but can participate in technical discussions if announces in advance that will remove their chair "hat" at that time. - Keeps Group's charter compliant with W3C Process, and initiates charter update as needed. -- Ensures participants abide by the terms and spirit of the [W3C Code of Conduct](/policies/code-of-conduct/) -- Find suitable time slots for distributed meeting where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC). (see also [Organizing a distributed meeting](../meetings/organize.html) ) and revisit those time slots on a regular basis. +- Ensures participants abide by the terms and spirit of the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/) +- Find suitable time slots for distributed meeting where most of the attendees are expected to participate from remote locations (e.g., by telephone, video conferencing, or IRC). (see also [Organizing a distributed meeting](../meetings/organize.md) ) and revisit those time slots on a regular basis. - Announces calls, meetings, events with appropriate advance time and through proper channels. - Ensures minutes are taken and posted in due time. - Defines meeting agendas. @@ -57,17 +57,17 @@ Interested parties should subscribe to [chairbuddies@w3.org](mailto:chairbuddies - Previous participation or technical contributions in related communities; - Ability to satisfy the time commitment (from you and/or your organization/management); - Familiarity or willingness to learn W3C Process and document formatting rules; -- Familiarity with the [W3C Code of Conduct](/policies/code-of-conduct/); +- Familiarity with the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/); - Ability to keep the Working Group "in Charter", both for technical and IPR issues; - Ability (both actual and perceived by the Working Group -- including potential competitors) to forge consensus fairly and without bias from your affiliation/employer and, sometimes, even your own technical positions. * * * -The team contact should arrange for the Chair and the [W3C Team](https://www.w3.org/Process#ref-for-team%E2%91%A2%E2%91%A6) to meet (by phone if necessary) to make sure they're on the same wavelength about things like: +The Team contact should arrange for the Chair and the [W3C Team](https://www.w3.org/policies/process/#ref-for-team%E2%91%A2%E2%91%A6) to meet (by phone if necessary) to make sure they're on the same wavelength about things like: -- where the group's work fits into [Web Architecture](/TR/webarch/) +- where the group's work fits into [Web Architecture](https://www.w3.org/TR/webarch/) - where does it fit with other groups - testing, test suites ... generating tests as you come to each - responsibility not just to the group -- working toward consensus of the whole community - cost of delaying wider consensus - negotiating your reviews and really getting in touch with people - versus time to market and specification relevance -- formal objections, i.e. the tricky bits of W3C process \ No newline at end of file +- formal objections, i.e. the tricky bits of W3C process From e11d7cfc665cde15d52c151af56cf9de0db38b03 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 12:34:05 +0100 Subject: [PATCH 155/225] Update links --- chair/meetings.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/chair/meetings.md b/chair/meetings.md index e23879fcc..6bae9a581 100644 --- a/chair/meetings.md +++ b/chair/meetings.md @@ -13,7 +13,7 @@ See also the [technical plenary history](https://www.w3.org/events/tpac/) : [1st Working Group Chairs Meeting](https://www.w3.org/Member/9711/wg-chairs.html) - [Press and Communications](https://www.w3.org/Member/Talks/971120Press) -- Sally's presentation - [Organizing a W3C Meeting](../meetings/hosting.md) -- Susan's presentation -- [Tim Berners-Lee's Perspective](/Member/9711/wg-chairs-intro.html) +- [Tim Berners-Lee's Perspective](https://www.w3.org/Member/9711/wg-chairs-intro.html) - [The Web: Sharing, Group Memory, and Communication](https://www.w3.org/OldGuide/WebSharing.html) -- Dan's presentation 13 Jul 1998 From 96123acf899aceb02c70c802d0333f6751073328 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 12:35:15 +0100 Subject: [PATCH 156/225] Removing sentene about ensuring that teh chair is in teh Chairs group as this is indeed automated --- chair/role.md | 1 - 1 file changed, 1 deletion(-) diff --git a/chair/role.md b/chair/role.md index 0d961eb4d..12f3075f5 100644 --- a/chair/role.md +++ b/chair/role.md @@ -28,7 +28,6 @@ Interested parties should visit the dedicated [Chair Buddy System page](buddy.md - Maintains close coordination with W3C *Staff Contact.* - Maintains coordination with assigned liaisons from other W3C working groups. - Participates in the Chairs mailing list ([archive](https://lists.w3.org/Archives/Member/chairs/)) and attends Chairs meetings. - *the Team Contact should make sure the Chair is in the [Chairs group](/admin/othergroups/31972/show)* (should be managed automatically) - Works with the Communications Team and Team Contact in preparing press release. - Communicates with the press, when necessary and appropriate, and with prior coordination with the communication team, on behalf of the group. - *Ensures all participants have proper access to Group data with assistance from Staff Contact.* From 993ebb538ec2bf0ebb4e2a5f113da0d6a1b82a69 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 13:09:51 +0100 Subject: [PATCH 157/225] Update links and add heading ids --- council/council.md | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/council/council.md b/council/council.md index facc5fe5e..829679503 100644 --- a/council/council.md +++ b/council/council.md @@ -7,7 +7,7 @@ This document supplements the Process Document by providing best practices to re In this document, resolving a Formal Objection means finding a solution that has no objections. Deciding means giving a yes/no answer to the question of whether an objection should be overruled (i.e., no) or sustained (i.e., yes). -## Cases that warrant a W3C Council +## Cases that warrant a W3C Council {#council} W3C aims to make decisions by consensus. If there are differences of opinions, groups work to understand different points of view and reach agreement, either by compromise, or by the force of some argument. When that is working well, Formal Objections are rare. @@ -19,19 +19,19 @@ The fact that Formal Objections should be rare does not de-legitimize them. On s Nonetheless, the fact that the process is oriented towards consensus implies that before an objection gets higher review there already has been significant work on the issue. There is generally clarity on what the W3C decision was (that is being objected to). The objector, in trying to reverse the decision, has generally pulled together their best arguments and brought them to the group. The fact that so much work should be accomplished prior to higher review should make it easier to decide a Formal Objection. -## The Team, the W3C Council, and different types of objections +## The Team, the W3C Council, and different types of objections {#objection-types} The Team has the responsibility to try to resolve a Formal Objection, or to come up with an analysis that might be used by the W3C Council in deciding a Formal Objection. The Team takes the early steps in processing Formal Objections. There are different types of Formal Objections and W3C needs to make sure they are all handled properly. Here are some interesting cases: 1. There is a Formal Objection to a decision in a Working Group. The Team as a neutral bystander attempts to resolve the objection. If it succeeds, W3C takes the path recommended by the Team. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides. -2. The Team proposes a Charter to the W3C Advisory Committee and there are objections. The Team attempts to resolve the objection even though they are not a neutral bystander. If it succeeds, W3C takes the recommended path. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides. -3. The Advisory Board (AB) or Technical Architecture Group (TAG) make a decision (e.g., on a process issue, or in a Statement emanating from a TAG finding) and there are objections. +1. The Team proposes a Charter to the W3C Advisory Committee and there are objections. The Team attempts to resolve the objection even though they are not a neutral bystander. If it succeeds, W3C takes the recommended path. If it fails, the Team prepares a report for the W3C Council. The W3C Council decides. +1. The Advisory Board (AB) or Technical Architecture Group (TAG) make a decision (e.g., on a process issue, or in a Statement emanating from a TAG finding) and there are objections. -It is important that even though the Team is an interested party in [case 2](#case-2), and the AB or TAG could be interested parties in [case 3](), the overall process must provide the objectivity and transparency to give the W3C Community the confidence that such cases are handled fairly. +It is important that even though the Team is an interested party in case 2, and the AB or TAG could be interested parties in case 3, the overall process must provide the objectivity and transparency to give the W3C Community the confidence that such cases are handled fairly. -## Processing of Formal Objections +## Processing of Formal Objections {#processing-of-formal-objections} All Formal Objections are made in response to a decision. Decisions are typically made by a Working Group as part of the Technical Report Development Process or by the Team as part of chartering a new group. @@ -39,7 +39,7 @@ Since W3C operates by consensus, it is always better if there can be a consensus This report is then sent to the W3C Council, to the deciders, and to the objectors. The W3C Council, like the Team before it, may try to find a consensus path forward. Otherwise, the W3C Council uses input from the report, the deciders, and objectors to either overrule the objection (in which case the original decision is in force), or to sustain the objection (in which case the original decision is vacated). The W3C Council also writes a report explaining their decision, which may be based on the Team's report. -### Team attempts to resolve Formal Objections +### Team attempts to resolve Formal Objections {#team-fo} When a Formal Objection is raised, the Team assigns someone to attempt to resolve the Formal Objection. That assignee is expected to follow the best practices below. @@ -55,9 +55,9 @@ The assignee works with all parties to explore whether there is a way to resolve See also: [Ongoing Team Attempts](https://www.w3.org/Member/wiki/DirectorFOdashboard#Team_is_attempting_to_find_consensus_or_not_ready_to_ask_a_Council) -### Publishing formal objections +### Publishing Formal Objections {#publishing-fos} -Formal objections must be made public using [public-review-comments](https://lists.w3.org/Archives/Public/public-review-comments/), no later than when the relevant council is initiated. The team should publish formal objections as soon as reasonable within the 90 days investigation and mediation period, with some considerations including: +Formal Objections must be made public using [public-review-comments](https://lists.w3.org/Archives/Public/public-review-comments/), no later than when the relevant council is initiated. The team should publish formal objections as soon as reasonable within the 90 days investigation and mediation period, with some considerations including: - all Formal Objections must be published, even those that are expected to be — or have already been — withdrawn. - the Formal Objection ought to be made public as soon as it is received if it needs to be discussed by a [W3C Group](https://www.w3.org/groups/). @@ -66,7 +66,7 @@ Formal objections must be made public using [public-review-comments](https://lis To avoid leaving people wondering what happened, the Team should post a response to the announcement of the formal objection, indicating the resolution of the formal objection, such as overruled or withdrawn, and giving a quick summary as to why. -## Referral to W3C Council +## Referral to W3C Council {#referral} If resolution is not possible in the allocated time frame, the assignee must refer the Formal Objection to the W3C Council for decision. The steps for that are as follows: @@ -85,23 +85,23 @@ If resolution is not possible in the allocated time frame, the assignee must ref - The assignee should indicate an explicit team contact (which can be the assignee) for comments on the draft document. - The W3C Council determines who will rule on this objection and who will chair the Council. - - See [Council Participation, Dismissal, and Renunciation](/policies/process/#council-participation) and [Council Chairing](/policies/process/#council-chairing). + - See [Council Participation, Dismissal, and Renunciation](https://www.w3.org//policies/process/#council-participation) and [Council Chairing](https://www.w3.org//policies/process/#council-chairing). - Every person serving on the W3C Council is expected to be sufficiently knowledgeable that they feel comfortable with the decision of the W3C Council. The breadth of the W3C Council membership, and therefore the participation of each of its members, is key to the Council’s ability to provide an appropriate balance of viewpoints. -- In extraordinary circumstances, the W3C Council may vote to [delegate](/policies/process/#council-delegation) or [short-circuit](/policies/process/#council-short-circuit) its decision. -- The W3C Council [deliberates and reaches a decision](/policies/process/#council-deliberations) to sustain or overrule the original decision. +- In extraordinary circumstances, the W3C Council may vote to [delegate](https://www.w3.org//policies/process/#council-delegation) or [short-circuit](https://www.w3.org//policies/process/#council-short-circuit) its decision. +- The W3C Council [deliberates and reaches a decision](https://www.w3.org//policies/process/#council-deliberations) to sustain or overrule the original decision. - If the W3C Council members deem that the written summaries are sufficient, they are not required to discuss with participants further, although they may do so if they wish. They may consult with deciders and objectors if they wish. See thoroughness and fairness below. - Once consultations are completed, the Chair of the W3C Council assesses the consensus of the Council, or if consensus cannot be found, calls for a vote of the W3C Council to sustain or overrule the Formal Objection. - If there is disagreement within the Council about the meaning of those sections of the Process that govern the Council itself, in a way that interferes with its ability to discuss the substance of the case, the Chair should try to resolve this by consensus, and should seek advice from the Team contact on how to interpret the Process. If consensus cannot be found, the chair should make a determination, possibly through a vote, to allow the deliberations to move on. Any such point of procedural contention should be covered in the Council Report. - - The W3C Council [publishes its decision and its rationale](/policies/process/#council-decision). + - The W3C Council [publishes its decision and its rationale](https://www.w3.org//policies/process/#council-decision). - Whether the decision is to sustain or overrule, the W3C Council may include additional guidance for any of the participants involved. - If the objection is sustained, the relevant group (i.e., Working Group, or Team developing a charter) may resume work to develop a different proposal for their document. -See also: [Ongoing Referrals to W3C Council](https://www.w3.org/Guide/council/council#referral) +See also: [Ongoing Referrals to W3C Council](#referral) -## The Nature of W3C Council deliberations +## The Nature of W3C Council deliberations {#nature-of-council-deliberations} -### I. Considerations +### I. Considerations {#considerations} Each Formal Objection referred to the W3C Council has unique aspects, and the W3C Council needs the flexibility to choose how it reaches a decision. In studying a particular Formal Objection, the W3C Council should always balance several factors: @@ -113,7 +113,7 @@ Each Formal Objection referred to the W3C Council has unique aspects, and the W3 - Treating all objectors consistently irrespective of who the objector might be. - Workload. If processing each Formal Objection results in significant work for a very large Council, then the Council will not have time to process the workload and the W3C Council design will not scale. -### II. Convincing the W3C Council +### II. Convincing the W3C Council {#convincing-the-council} The nature of a Formal Objection is that a Decision has been made and someone has raised a Formal Objection to that Decision. The W3C Council is required by the Process to review the Decision, and choose whether to overrule the objection or sustain the objection. This section addresses what information the Council has to consider. @@ -134,7 +134,7 @@ Placing the burden of convincing on the objectors is supported by several consid - Treating objectors consistently. If the Council begins to accept the burden of convincing on themselves for some Objections, then to be consistent, they will need to accept the burden for all objectors. That would be a tremendous expansion of scope for Formal Objections. - Workload. If the W3C Council begins to accept the burden of convincing on themselves, that would considerably add workload to the Council. -### III. W3C Council Reports +### III. W3C Council Reports {#council-report} The W3C Council Decision Report section of the Process covers what information the Council is expected to provide in its report. Fundamentally, the Council needs to either: @@ -150,11 +150,11 @@ While providing guidance beyond a simple sustain/overrule decision increases the Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. -## Best Practices +## Best Practices {#best-practices} Above we described, qualitatively, how the W3C Council should deal with Objections. A useful Best Practices checklist may be arranged in categories. -### I. Thoroughness +### I. Thoroughness {#thoroughness} This includes: @@ -177,7 +177,7 @@ Analysis of all arguments raised : Although the W3C Council's published decision should be clear, well explained, and unambiguous, it should nonetheless acknowledge legitimate points raised by the party that is not favored in the ruling, but explain why they are not decisive. -### II. Fairness +### II. Fairness {#fairness} This includes: @@ -213,7 +213,7 @@ Adherence to the W3C Process However, the W3C Council is not required to always sustain such an objection—they need to take all factors into consideration in terms of the best solution for the Web. -### III. Communications +### III. Communications {#communications} This includes: From b28e2b22f9781f80e499049c398c6317b0b33731 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 13:14:24 +0100 Subject: [PATCH 158/225] Fix broken links from last commit --- council/council.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/council/council.md b/council/council.md index 829679503..f863f89e3 100644 --- a/council/council.md +++ b/council/council.md @@ -85,15 +85,15 @@ If resolution is not possible in the allocated time frame, the assignee must ref - The assignee should indicate an explicit team contact (which can be the assignee) for comments on the draft document. - The W3C Council determines who will rule on this objection and who will chair the Council. - - See [Council Participation, Dismissal, and Renunciation](https://www.w3.org//policies/process/#council-participation) and [Council Chairing](https://www.w3.org//policies/process/#council-chairing). + - See [Council Participation, Dismissal, and Renunciation](https://www.w3.org/policies/process/#council-participation) and [Council Chairing](https://www.w3.org/policies/process/#council-chairing). - Every person serving on the W3C Council is expected to be sufficiently knowledgeable that they feel comfortable with the decision of the W3C Council. The breadth of the W3C Council membership, and therefore the participation of each of its members, is key to the Council’s ability to provide an appropriate balance of viewpoints. -- In extraordinary circumstances, the W3C Council may vote to [delegate](https://www.w3.org//policies/process/#council-delegation) or [short-circuit](https://www.w3.org//policies/process/#council-short-circuit) its decision. -- The W3C Council [deliberates and reaches a decision](https://www.w3.org//policies/process/#council-deliberations) to sustain or overrule the original decision. +- In extraordinary circumstances, the W3C Council may vote to [delegate](https://www.w3.org/policies/process/#council-delegation) or [short-circuit](https://www.w3.org/policies/process/#council-short-circuit) its decision. +- The W3C Council [deliberates and reaches a decision](https://www.w3.org/policies/process/#council-deliberations) to sustain or overrule the original decision. - If the W3C Council members deem that the written summaries are sufficient, they are not required to discuss with participants further, although they may do so if they wish. They may consult with deciders and objectors if they wish. See thoroughness and fairness below. - Once consultations are completed, the Chair of the W3C Council assesses the consensus of the Council, or if consensus cannot be found, calls for a vote of the W3C Council to sustain or overrule the Formal Objection. - If there is disagreement within the Council about the meaning of those sections of the Process that govern the Council itself, in a way that interferes with its ability to discuss the substance of the case, the Chair should try to resolve this by consensus, and should seek advice from the Team contact on how to interpret the Process. If consensus cannot be found, the chair should make a determination, possibly through a vote, to allow the deliberations to move on. Any such point of procedural contention should be covered in the Council Report. - - The W3C Council [publishes its decision and its rationale](https://www.w3.org//policies/process/#council-decision). + - The W3C Council [publishes its decision and its rationale](https://www.w3.org/policies/process/#council-decision). - Whether the decision is to sustain or overrule, the W3C Council may include additional guidance for any of the participants involved. - If the objection is sustained, the relevant group (i.e., Working Group, or Team developing a charter) may resume work to develop a different proposal for their document. From 634a761368582024cccb14ae1bae8cd83f9d2afa Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 14:44:56 +0100 Subject: [PATCH 159/225] Update links --- documentreview/index.md | 67 ++++++++++++++++++++--------------------- 1 file changed, 33 insertions(+), 34 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 2e6a3bfa4..2cc604d2b 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -18,7 +18,7 @@ Wide review should or must be requested: Working Groups are often reluctant to make substantive changes to a mature document, so reviewers should get a chance to send substantive technical reviews as early as possible. This is especially important for [horizontal reviews](#how-to-get-horizontal-review). -* Before a document gets advanced to [Candidate Recommendation](https://www.w3.org/policies/process/#transition-cr), gets updated as a [Candidate Recommendation Snapshot](https://www.w3.org/policies/process/#update-requests) or gets updated as a [Recommendation](https://www.w3.org/policies/process/20231103/#change-review). +* Before a document gets advanced to [Candidate Recommendation](https://www.w3.org/policies/process/#transition-cr), gets updated as a [Candidate Recommendation Snapshot](https://www.w3.org/policies/process/#update-requests) or gets updated as a [Recommendation](https://www.w3.org/policies/process/#change-review). For those, the [W3C Process](https://www.w3.org/policies/process/) requires a Group to show that the specification has received wide review. * When a document is both reasonably stable and still flexible enough to allow changes where issues are identified. @@ -26,7 +26,7 @@ Wide review should or must be requested: ## Who to ask for wide review? -The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have adequate notice of the progress of the Working Group and are genuinely able to perform reviews of and provide comments on the specification. When considering [requests to advance the maturity level of the document](https://www.w3.org/Guide/transitions), the Team will consider who has been explicitly offered a reasonable opportunity to review the document. +The objective is to ensure that the entire set of stakeholders of the Web community, including the general public, have adequate notice of the progress of the Working Group and are genuinely able to perform reviews of and provide comments on the specification. When considering [requests to advance the maturity level of the document](../transitions/), the Team will consider who has been explicitly offered a reasonable opportunity to review the document. You **must** publish an updated technical report, with the Status of the Document indicating clearly that you're looking for *wide review*, before inviting review from other stakeholders. Our [tooling](https://github.com/w3c/transition-notifier/blob/main/notify.js) monitors publications and propagates notifications to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) automatically (for example, [Candidate Recommendation Snapshot: Payment Request API (Call for Wide Review)](https://lists.w3.org/Archives/Public/public-review-announce/2021Jun/0008.html)). @@ -35,13 +35,12 @@ You should then inform, and request reviews from: * the groups listed in the WG's charter, especially those who manage dependencies. * the groups jointly responsible for a particular document (if any). -* the [horizontal groups](/Guide/process/horizontal-groups.html) using the [method described below](#how_to_get_horizontal_review). *Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below* +* the [horizontal groups](../process/horizontal-groups.md) using the [method described below](#how_to_get_horizontal_review). *Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below* * the general public, including Web developers, technology providers and implementers, application developers, etc. Consider: * sending a dedicated announcement to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) if needed (in case the default notice sent to that list is not enough). * using blog posts, social media, or other ways of alerting the public to your document and requesting feedback. * other groups, at your discretion, even if not in the WG charter, such as other W3C groups, external organizations and SSOs working on related areas, etc. - **Tip:** consider tracking your wide review progress using a GitHub issue, such as [issue #299 of the Sensors API](https://github.com/w3c/sensors/issues/299). You can then simply point the Team to the issue. -The reviews provided by the [horizontal groups](/Guide/process/horizontal-groups.html), a subset of a full wide review, do receive special attention and much of the rest of this document focuses on how and when to conduct horizontal reviews. +The reviews provided by the [horizontal groups](../process/horizontal-groups.md), a subset of a full wide review, do receive special attention and much of the rest of this document focuses on how and when to conduct horizontal reviews. ## How to get horizontal review When you have published a First Public Working Draft, you should work through available "self-review" materials and request review of your results in at least the following areas. @@ -92,14 +91,14 @@ The meaning of "Long enough" depends on how many changes there are, how clearly If you are developing javascript APIs you may also want to ask public-script-coord@w3.org, a technical discussion list shared by W3C and ECMA's TC 39.
    Show useful links - +
    @@ -110,14 +109,14 @@ The meaning of "Long enough" depends on how many changes there are, how clearly request a review via GitHub.
    Show useful links -
    @@ -127,14 +126,15 @@ The meaning of "Long enough" depends on how many changes there are, how clearly request a review via GitHub from the Privacy Interest Group.
    Show useful links -
    @@ -143,15 +143,14 @@ The meaning of "Long enough" depends on how many changes there are, how clearly
    Write a "Security Considerations" section for your document, taking into account the Self-Review Questionnaire: Security and Privacy, then request a review via GitHub -
    Show useful links -
    @@ -172,7 +171,7 @@ If you want some specific advice from the horizontal group, describe that reques Horizontal review groups may apply the \*-needs-resolution label to issues they expect to be resolved before the specification moves to a new maturity level. Working Groups must not remove or add this label (not even when you close your issue). -If the [horizontal group](/Guide/process/horizontal-groups.html) believes that an issue with a \*-tracker label needs to be resolved before a transition, they may apply a \*-needs-resolution label to the issue. Automatic tooling will later remove the \*-tracker label. +If the [horizontal group](../process/horizontal-groups.md) believes that an issue with a \*-tracker label needs to be resolved before a transition, they may apply a \*-needs-resolution label to the issue. Automatic tooling will later remove the \*-tracker label. If you close an issue with a \*-tracker or \*-needs-resolution label attached, do not remove the label. Keeping the label maintains the tracking if the issue is reopened, but also provides potentially useful information about what was tracked. (Closed issues in your repository have no effect on tools that check for unresolved issues.) @@ -221,15 +220,15 @@ Is it possible to make too many requests for review? ## Common mistakes when making a transition request -1. If you make substantive changes, you'll need to do a wide review for those before you move forward to the [next maturity stage](https://www.w3.org/Guide/documentreview/#who_to_ask_for_review). -1. Never ever exclude some [horizontal groups](/Guide/process/horizontal-groups.html) from your review requests because you concluded it was irrelevant for them or they haven't responded to your last request. +1. If you make substantive changes, you'll need to do a wide review for those before you move forward to the [next maturity stage](../documentreview/#who_to_ask_for_review). +1. Never ever exclude some [horizontal groups](../process/horizontal-groups.md) from your review requests because you concluded it was irrelevant for them or they haven't responded to your last request. Let them make the decision that something is irrelevant to their field of expertise instead. You're welcome to time out if you don't hear back, and request to move forward anyway. 1. Publish a Working Draft or a Candidate Recommendation Draft when asking for reviews. It's better for a Group to miss the fact that you fixed an issue in your editor's draft than the Team missing the fact you made an unreviewed substantive change in your editor's draft. 1. Don't flag your issues with one of those \*-needs-resolution labels, and don't remove one which has been applied (you *can* close the issue though, if it is resolved). - Those are intended solely to be used by [horizontal groups](/Guide/process/horizontal-groups.html) to [bring special attention](https://www.w3.org/Guide/documentreview/#What_happens_to_unresolved_issues_marked_needs-resolution). + Those are intended solely to be used by [horizontal groups](../process/horizontal-groups.md) to [bring special attention](../documentreview/#What_happens_to_unresolved_issues_marked_needs-resolution). 1. Don't assume that the horizontal group will be able to schedule and complete a review within 2 weeks so that you can proceed to CR. They may not even be able to find someone with availability to do the review in that time, and then they need a week or two to discuss their response after the review, and then they'll send you comments that may require you to make substantive changes. From 18a42742f4c1ea65ec881f6190e38978d250a518 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 14:56:15 +0100 Subject: [PATCH 160/225] Update links --- documentreview/index.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/documentreview/index.md b/documentreview/index.md index 2cc604d2b..4220203e5 100644 --- a/documentreview/index.md +++ b/documentreview/index.md @@ -35,7 +35,7 @@ You should then inform, and request reviews from: * the groups listed in the WG's charter, especially those who manage dependencies. * the groups jointly responsible for a particular document (if any). -* the [horizontal groups](../process/horizontal-groups.md) using the [method described below](#how_to_get_horizontal_review). *Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below* +* the [horizontal groups](../process/horizontal-groups.md) using the [method described below](#how-to-get-horizontal-review). *Note that sending an email to the public-review-announce list alone is not sufficient to trigger horizontal reviews. You will still need to formally request review from the Horizontal Groups, as described below* * the general public, including Web developers, technology providers and implementers, application developers, etc. Consider: * sending a dedicated announcement to [public-review-announce@w3.org](mailto:public-review-announce@w3.org) if needed (in case the default notice sent to that list is not enough). * using blog posts, social media, or other ways of alerting the public to your document and requesting feedback. @@ -74,11 +74,11 @@ The meaning of "Long enough" depends on how many changes there are, how clearly
    Accessibility
    Work through this questionnaire then - request a review via GitHub from APA + request a review via GitHub from APA
    Show useful links
    From d738c0b87491c9d77776efcfe9924c826a8f74f8 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 15:20:21 +0100 Subject: [PATCH 162/225] Minor markdown fix --- editor/editors-draft.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/editor/editors-draft.md b/editor/editors-draft.md index 9c1df4858..a5c1b1271 100644 --- a/editor/editors-draft.md +++ b/editor/editors-draft.md @@ -21,17 +21,14 @@ The guidelines below are intended to reduce confusion between group-internal dra ## Guidelines for Group-Internal Drafts {#guidelines} 1. Use this style sheet: ***`https://www.w3.org/StyleSheets/TR/2021/W3C-ED.css`*** -2. Use an appropriate label for the document, as in: - +1. Use an appropriate label for the document, as in: + ```html +

    Architecture of the World Wide Web, Volume One

    +

    Editor's Draft 15 December 2004

    ``` -

    Architecture of the World Wide Web, - Volume One

    -

    Editor's Draft 15 December 2004

    - ``` -3. When the document is "Member-confidential", indicate this in an obvious place at the top of the document. Please also include a reminder in the status section. -4. Set expectations about the stability and level of confidentiality of the document in the status section, for example: - - > We welcome feedback on this informal collection of resources, which is subject to change without notice. +1. When the document is "Member-confidential", indicate this in an obvious place at the top of the document. Please also include a reminder in the status section. +1. Set expectations about the stability and level of confidentiality of the document in the status section, for example: + > We welcome feedback on this informal collection of resources, which is subject to change without notice. ## Frequently Asked Questions (FAQs) {#faq} From 10fa45a8fad56813f3c985269c986f116ffc6119 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 15:23:22 +0100 Subject: [PATCH 163/225] Update links and content --- editor/resources.md | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/editor/resources.md b/editor/resources.md index 56feeec6c..c6ee3983f 100644 --- a/editor/resources.md +++ b/editor/resources.md @@ -22,8 +22,8 @@ toc: true * [Business Groups/Community Groups](https://www.w3.org/community/groups/) ### How to join/leave the group -* [Create your W3C account first](https://www.w3.org/accounts/request) -* Ask your AC to join W3C groups and nominate you as a group participant: +* [Create your W3C account first](https://www.w3.org/account/request/) +* Ask your AC Rep to join W3C groups and nominate you as a group participant: * Use the 'Join' button in [Working Groups/Interest Groups](https://www.w3.org/groups/) pages * [Business Groups/Community Groups](https://www.w3.org/community/groups/) @@ -32,8 +32,7 @@ toc: true * [Public lists](https://lists.w3.org/) * [Member lists](https://lists.w3.org/Archives/Member/) * How to use W3C mailinglists: - * [Mailing list guide](https://www.w3.org/Mail/) - * [Mailinglist subscription](https://www.w3.org/Mail/Request) + * [Mailing lists guide](https://www.w3.org/email/) ### Teleconfs * Zoom: @@ -50,8 +49,7 @@ toc: true ### GitHub * Initial instructions for GitHub beginners: - * [W3C Specs on GitHub](https://w3c.github.io/specs.html) - * [W3C Tools Support Wiki](https://www.w3.org/2006/tools/wiki/Github) + * [W3C on GitHub](https://w3c.github.io/) ### For Editor's role * Tools for spec editing: @@ -67,6 +65,3 @@ toc: true * [W3C Patent Policy](https://www.w3.org/policies/patent-policy/) * [Patent Policy FAQ](https://www.w3.org/2003/12/22-pp-faq.html) -## Learn more -* [/Guide](https://www.w3.org/Guide/) - From c40e93b25d9bf7d8b101b99a4d8292c4bfe05aa4 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 15:24:08 +0100 Subject: [PATCH 164/225] Minor markdown fix --- editor/resources.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/editor/resources.md b/editor/resources.md index c6ee3983f..25492022b 100644 --- a/editor/resources.md +++ b/editor/resources.md @@ -4,6 +4,7 @@ toc: true --- ## Group Specific Information + * Your group's Email list and its archive * Your group's WebEx coordinate for group calls * Your group's IRC channel @@ -17,17 +18,20 @@ toc: true ## General Information ### List of the W3C groups + * [Working Groups](https://www.w3.org/groups/wg/) * [Interest Groups](https://www.w3.org/groups/ig/) * [Business Groups/Community Groups](https://www.w3.org/community/groups/) ### How to join/leave the group + * [Create your W3C account first](https://www.w3.org/account/request/) * Ask your AC Rep to join W3C groups and nominate you as a group participant: * Use the 'Join' button in [Working Groups/Interest Groups](https://www.w3.org/groups/) pages * [Business Groups/Community Groups](https://www.w3.org/community/groups/) ### Emails + * Email archives: * [Public lists](https://lists.w3.org/) * [Member lists](https://lists.w3.org/Archives/Member/) @@ -35,6 +39,7 @@ toc: true * [Mailing lists guide](https://www.w3.org/email/) ### Teleconfs + * Zoom: * [Zoom](https://www.w3.org/Guide/meetings/zoom) * Minutes taking by IRC: @@ -43,15 +48,18 @@ toc: true * [RRSAGent HOWTO](https://www.w3.org/2002/03/RRSAgent) ### Meetings + * [W3C Member meetings](https://www.w3.org/events/) * [TPAC (Technical Plenary and Advisory Committee Meetings)](https://www.w3.org/events/tpac/) * [AC Meeting (Advisory Committee meeting)](https://www.w3.org/events/ac/) ### GitHub + * Initial instructions for GitHub beginners: * [W3C on GitHub](https://w3c.github.io/) ### For Editor's role + * Tools for spec editing: * [Markdown](https://github.github.com/gfm/) * [Respec](https://github.com/speced/respec/wiki/format) @@ -62,6 +70,7 @@ toc: true * [Automatic publication tool (Echidna)](https://labs.w3.org/echidna/) ### Patent Policy (especially for WGs) + * [W3C Patent Policy](https://www.w3.org/policies/patent-policy/) * [Patent Policy FAQ](https://www.w3.org/2003/12/22-pp-faq.html) From 9494ce5f30fb19ad654b2620d0abed5cc2053023 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 15:26:28 +0100 Subject: [PATCH 165/225] Update links --- editor/index.md | 51 ++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/editor/index.md b/editor/index.md index 16c6b4aa4..b17a0db31 100644 --- a/editor/index.md +++ b/editor/index.md @@ -13,26 +13,26 @@ This page tries to gather resources that can help editors do their job: document If you are a newly appointed editor in your Working Group, here is some advice that should be useful to get you started. -- Get an [idea of the role of an editor](role.html) at W3C +- Get an [idea of the role of an editor](role.md) at W3C - Check the most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki) -- Read the [W3C Publication Rules](/pubrules/doc/) (often referred as pubrules) and ask advice on the points that are unclear; if your document doesn't comply with these rules, it cannot be published as a W3C technical report. -- [How to Organize a Recommendation Track Transition](/Guide/transitions) explains the process to get a document published as a technical report. -- The [Pubrules Checker](/pubrules) is a tool that can help you assess whether or not your document complies with pubrules. -- Review [WCAG](/TR/WCAG/) -- All W3C editors are invited to join the [publicly archived mailing list <spec-prod@w3.org>](http://lists.w3.org/Archives/Public/spec-prod/) to share and discuss the techniques and tools used to produce W3C specifications. +- Read the [W3C Publication Rules](https://www.w3.org/pubrules/doc/) (often referred as pubrules) and ask advice on the points that are unclear; if your document doesn't comply with these rules, it cannot be published as a W3C technical report. +- [How to Organize a Recommendation Track Transition](../transitions/) explains the process to get a document published as a technical report. +- The [Pubrules Checker](https://www.w3.org/pubrules/) is a tool that can help you assess whether or not your document complies with pubrules. +- Review [WCAG](https://www.w3.org/TR/WCAG/) +- All W3C editors are invited to join the [publicly archived mailing list <spec-prod@w3.org>](https://lists.w3.org/Archives/Public/spec-prod/) to share and discuss the techniques and tools used to produce W3C specifications. ## Guidelines on W3C specifications editing {#quality} W3C has developed a set of resources giving advices and guidelines on editing W3C specifications in varous domains: - The [W3C Manual of Style](../manual-of-style/) is a collection of rules you're invited to follow to make your document clearer and adapted to the common style at W3C. -- Begun in 1992 and only a little out of date, the [Style Guide for online hypertext](../../Provider/Style/) by Tim Berners-Lee is a good start on writing for the Web; see also Jakob Nielsen's [How Users Read on the Web](http://www.useit.com/alertbox/9710a.html) -- The [QA Framework: Specification Guidelines](../../TR/qaframe-spec/) from the W3C Quality Assurance Activity are a work in progress that became a Candidate Recommendation in November 2003. -- The Team has guidelines for a [style for group-internal drafts](editors-draft.html) to avoid confusion with documents published on the [TR page](/TR). Please also review the related [Working Group Heartbeat Requirement](/policies/process/#revising-wd) of the W3C Process. +- Begun in 1992 and only a little out of date, the [Style Guide for online hypertext](https://www.w3.org/Provider/Style/) by Tim Berners-Lee is a good start on writing for the Web; see also Jakob Nielsen's [How Users Read on the Web](https://www.nngroup.com/articles/how-users-read-on-the-web/) +- The [QA Framework: Specification Guidelines](https://www.w3.org/TR/qaframe-spec/) from the W3C Quality Assurance Activity are a work in progress that became a Candidate Recommendation in November 2003. +- The Team has guidelines for a [style for group-internal drafts](editors-draft.md) to avoid confusion with documents published on the [TR page](https://www.w3.org/TR/). Please also review the related [Working Group Heartbeat Requirement](https://www.w3.org/policies/process/#revising-wd) of the W3C Process. -[Bert Bos's essay on W3C's design principles](http://www.w3.org/People/Bos/DesignGuide/introduction) and [Tim Berners-Lee's essentials of a specification](http://www.w3.org/1999/09/specification) may also be a useful reading. +[Bert Bos's essay on W3C's design principles](https://www.w3.org/People/Bos/DesignGuide/introduction) and [Tim Berners-Lee's essentials of a specification](https://www.w3.org/1999/09/specification) may also be a useful reading. -During the internal development of a specification, make sure to distinguish official drafts from internal ones using the [style for Group-internal Drafts](editors-draft.html). +During the internal development of a specification, make sure to distinguish official drafts from internal ones using the [style for Group-internal Drafts](editors-draft.md). ## Grammars {#grammars} @@ -41,31 +41,30 @@ W3C editors have developed several types of HTML and XML based grammars to make ## Authoring tools {#authoring} - Check the most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki) -- [BlueGriffon](http://www.bluegriffon.org/) is a WYSIWYG HTML editor. -- Some [tips and tricks for API architecture design](http://scriptlib-cg.github.com/api-design-cookbook/) -- Some [WhatWG conventions](http://wiki.whatwg.org/wiki/Howto_spec). +- Some tips and tricks for API architecture design: [Web API Design Cookbook](https://www.w3.org/TR/api-design/) +- Some [WhatWG conventions](https://wiki.whatwg.org/wiki/Specs/howto). ## Tools {#tools} Here are tools that can prove to be useful when developing your specification. -- The [Pubrules Checker](http://www.w3.org/pubrules) provides a convenient interface to check the conformance of a document to pubrules (see [pubrules issues and tracking](http://github.com/w3c/specberus/issues)) -- The [Technical Reports shopping list](http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](http://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](http://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec -- The [TR references checker](/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](/2007/05/ietf-references-checker). -- The [W3C Glossary](/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where -- The [on-line Spell Checker](http://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos; the [W3C on-line Stylistic Checker](/2002/08/diction) helps find the most usual errors identified by the [W3C Manual of Style](/2001/06/manual/) -- [different tools](http://esw.w3.org/topic/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](http://www.w3.org/2007/10/htmldiff) -- The [MarkUp Validator](http://validator.w3.org/) can help you assess whether your documents are valid HTML, MathML or SVG. -- The [CSS Validator](http://jigsaw.w3.org/css-validator/) tells you if your use of CSS is correct. -- The [Link Checker](http://validator.w3.org/checklink) catches all the broken links that may have popped up in your document. -- The [Namespace checker](http://www.w3.org/2003/09/nschecker) finds potential namespaces URIs in the documents, and makes a few checks on them -- [HTML Tidy](http://tidy.sourceforge.net/), originally by Dave Raggett and now maintained at SourceForge.net, is a lint that cleans up but does not validate HTML and XHTML. With indent off, Tidy can sometimes shave 10% or more off file size. +- The [Pubrules Checker](https://www.w3.org/pubrules/) provides a convenient interface to check the conformance of a document to pubrules (see [pubrules issues and tracking](https://github.com/w3c/specberus/issues)) +- The [Technical Reports shopping list](https://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](https://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](https://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec +- The [TR references checker](https://www.w3.org/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](https://www.w3.org/2007/05/ietf-references-checker). +- The [W3C Glossary](https://www.w3.org/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where +- The [on-line Spell Checker](https://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos; the [W3C on-line Stylistic Checker](https://www.w3.org/2002/08/diction) helps find the most usual errors identified by the [W3C Manual of Style](../manual-of-style/) +- [different tools](https://esw.w3.org/topic/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](https://www.w3.org/2007/10/htmldiff) +- The [MarkUp Validator](https://validator.w3.org/) can help you assess whether your documents are valid HTML, MathML or SVG. +- The [CSS Validator](https://jigsaw.w3.org/css-validator/) tells you if your use of CSS is correct. +- The [Link Checker](https://validator.w3.org/checklink) catches all the broken links that may have popped up in your document. +- The [Namespace checker](https://www.w3.org/2003/09/nschecker) finds potential namespaces URIs in the documents, and makes a few checks on them +- [HTML Tidy](https://www.html-tidy.org/), originally by Dave Raggett and now maintained at SourceForge.net, is a lint that cleans up but does not validate HTML and XHTML. With indent off, Tidy can sometimes shave 10% or more off file size. Most of these tools can be quickly accessed using the so called **[`,tools`](./,tools)** interface: appending **`,keyword`** to a www.w3.org URI triggers a certain tool on this URI; for instance, appending **[`,validate`](,validate)** to this page's URI will send it to the HTML validator. ## Central JavaScript repository {#javascript} -Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries,](../../scripts/) you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.) +Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries,](https://www.w3.org/scripts/) you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.) There is no documentation for now (except for [MathJax](https://www.w3.org/scripts/MathJax/)). From 5528aae9ca31d3fd1db9a54810b7874ba7ae1995 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 15:26:32 +0100 Subject: [PATCH 166/225] Update links --- editor/role.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/editor/role.md b/editor/role.md index 335679c6e..e90a51765 100644 --- a/editor/role.md +++ b/editor/role.md @@ -5,7 +5,7 @@ toc: false The role of the editor is not that of author. They maintain the text of a current draft that the Group has agreed to and possibly to suggest concrete wording when none is forthcoming from the group. -Specification editors are [appointed by the Group Chair](../chair/role.html). +Specification editors are [appointed by the Group Chair](../chair/role.md). ## Role of the editor From ca3db51663a657909778a329103e82f8d0296dbd Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 15:51:34 +0100 Subject: [PATCH 167/225] Update links and remove retired tools --- editor/index.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/editor/index.md b/editor/index.md index b17a0db31..abfa5b37e 100644 --- a/editor/index.md +++ b/editor/index.md @@ -52,12 +52,11 @@ Here are tools that can prove to be useful when developing your specification. - The [Technical Reports shopping list](https://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](https://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](https://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec - The [TR references checker](https://www.w3.org/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](https://www.w3.org/2007/05/ietf-references-checker). - The [W3C Glossary](https://www.w3.org/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where -- The [on-line Spell Checker](https://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos; the [W3C on-line Stylistic Checker](https://www.w3.org/2002/08/diction) helps find the most usual errors identified by the [W3C Manual of Style](../manual-of-style/) -- [different tools](https://esw.w3.org/topic/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](https://www.w3.org/2007/10/htmldiff) +- The [on-line Spell Checker](https://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos +- [different tools](https://www.w3.org/wiki/HtmlDiff) are available to produce a `diff` between 2 HTML versions of a document; W3C offers an [on-line HTMLDiff service](https://services.w3.org/htmldiff) - The [MarkUp Validator](https://validator.w3.org/) can help you assess whether your documents are valid HTML, MathML or SVG. - The [CSS Validator](https://jigsaw.w3.org/css-validator/) tells you if your use of CSS is correct. - The [Link Checker](https://validator.w3.org/checklink) catches all the broken links that may have popped up in your document. -- The [Namespace checker](https://www.w3.org/2003/09/nschecker) finds potential namespaces URIs in the documents, and makes a few checks on them - [HTML Tidy](https://www.html-tidy.org/), originally by Dave Raggett and now maintained at SourceForge.net, is a lint that cleans up but does not validate HTML and XHTML. With indent off, Tidy can sometimes shave 10% or more off file size. Most of these tools can be quickly accessed using the so called **[`,tools`](./,tools)** interface: appending **`,keyword`** to a www.w3.org URI triggers a certain tool on this URI; for instance, appending **[`,validate`](,validate)** to this page's URI will send it to the HTML validator. From ebe6d5aef1dd33c2a04ce4b49a99aee9d14db99e Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Wed, 8 Jan 2025 16:01:48 +0100 Subject: [PATCH 168/225] Remove Technical Reports shopping list and Bibliography Extractor as those have been retired --- editor/index.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/editor/index.md b/editor/index.md index abfa5b37e..efed34bb4 100644 --- a/editor/index.md +++ b/editor/index.md @@ -49,7 +49,6 @@ W3C editors have developed several types of HTML and XML based grammars to make Here are tools that can prove to be useful when developing your specification. - The [Pubrules Checker](https://www.w3.org/pubrules/) provides a convenient interface to check the conformance of a document to pubrules (see [pubrules issues and tracking](https://github.com/w3c/specberus/issues)) -- The [Technical Reports shopping list](https://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2005%2F06%2Ftr-shopping.xsl&xmlfile=http%3A%2F%2Fwww.w3.org%2F2002%2F01%2Ftr-automation%2Ftr.rdf) and the [Bibliography Extractor](https://www.w3.org/2002/01/tr-automation/tr-biblio-ui) help building bibliographies based on other W3C Technical Reports; there is a [similar mechansim](https://lists.w3.org/Archives/Public/spec-prod/2003OctDec/0002.html) for XMLSpec - The [TR references checker](https://www.w3.org/2004/07/references-checker-ui) may help maintain your references list up to date. See also the [IETF references checker](https://www.w3.org/2007/05/ietf-references-checker). - The [W3C Glossary](https://www.w3.org/2003/glossary/) is a repository of all the terms defined in W3C specifications (and more); a good source to find which terms have already been defined and where - The [on-line Spell Checker](https://www.w3.org/2002/01/spellchecker) helps spot misspellings and typos @@ -63,7 +62,7 @@ Most of these tools can be quickly accessed using the so called **[`,tools`](./ ## Central JavaScript repository {#javascript} -Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries,](https://www.w3.org/scripts/) you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.) +Specifications should, of course, be device-independent. But, with care, you can still include certain kinds of scripts. If the script you want is in W3C's [repository of common JavaScript libraries](https://www.w3.org/scripts/), you're recommended to link to that repository, rather than make a copy of the script. (Note that, together with the common style sheets, these scripts are the *only* resources that may be outside the specification's own directory.) There is no documentation for now (except for [MathJax](https://www.w3.org/scripts/MathJax/)). From 0144ea9dcc938c558415d6611820e14f6908b90e Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 8 Jan 2025 16:30:52 +0100 Subject: [PATCH 169/225] update style --- transitions/index.html | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/transitions/index.html b/transitions/index.html index 2fc22f858..83580b07d 100644 --- a/transitions/index.html +++ b/transitions/index.html @@ -1,5 +1,6 @@ --- title: Organize a Technical Report Transition (2023 Process) +submenu: [publication-policies] toc: false --- @@ -191,7 +192,6 @@ and look at milestones calculator.

    -

     

    About This Document

    @@ -2216,11 +2216,8 @@

    Call for Exclusions

    - - - - - - -

    About This Document

    This resource assists in finding the internal W3C Technical Report publication processes.

    -

    Next Steps

    -
    -

    - You may use a TR to find out your next step:
    -

    - - - + +

    Next Steps

    +
    + +
    You may use a TR shortname to find out your next step
    + + + +
    + -
    -

    Feedback is to @w3c/transitions - and is welcome on GitHub

    - - - - + trace("restored " + window.location.href); + \ No newline at end of file From 408e0d478a61df32ddd913ef7be57021a6d96348 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Wed, 8 Jan 2025 16:39:27 +0100 Subject: [PATCH 171/225] update a link --- transitions/nextstep.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transitions/nextstep.html b/transitions/nextstep.html index b4a09d0b7..5c7579f27 100644 --- a/transitions/nextstep.html +++ b/transitions/nextstep.html @@ -46,7 +46,7 @@

    Next Steps

    Other resources

    About This Document

    This resource describes the internal W3C Technical Report - publication processes. A companion document provides - more information about roles involved in these processes and - interactions with the W3C Communications Team.

    - +publication processes. A companion document provides +more information about roles involved in these processes and +interactions with the W3C Communications Team.

    Steps for - transition to - an update request for a - publication of a - publication of an - LABEL - Snapshot - (intended to update a Recommendation) - Draft - (with candidate corrections) - (with candidate additions) - (with proposed corrections) - (with proposed additions) - (with editorial changes) - (incorporating proposed corrections) - (incorporating proposed additions) -

    + transition to + an update request for a + publication of a + publication of an + LABEL + Snapshot + (intended to update a Recommendation) + Draft + (with candidate corrections) + (with candidate additions) + (with proposed corrections) + (with proposed additions) + (with editorial changes) + (incorporating proposed corrections) + (incorporating proposed additions) +

    @@ -317,7 +312,7 @@

    Steps for the STATUS. The Group MUST show that the changes have received wide review in order to publish the STATUS. - See the considerations, guidelines and best practices + See the considerations, guidelines and best practices that groups should follow to get early and wide review of a document. @@ -462,7 +457,7 @@

    Steps for
  • The Document Contact prepares the document in accordance with pubrules and develops a proposed publication schedule, taking into - account possible publishing moratoria. The + account possible publishing moratoria. The title page date is chosen based on the anticipated publication schedule.
  • @@ -735,7 +730,7 @@

    Transition Requirements for S
    • In general, documents do not advance to Proposed Recommendation with normative references to other - specifications that are considered unstable. See also Normative References Guidelines.
    • + specifications that are considered unstable. See also Normative References Guidelines.
    • Documents must not include normative references to a Rescinded/Obsolete/Superseded Recommendation.
    @@ -956,7 +951,7 @@

    Requirements for updating a STATU
  • Does this specification have any normative references to other specifications that are not yet stable? The Team's expectations are that, as a document advances, there will be an increasingly need - for normative referenced materials to be scrutinized. See Normative References Guidelines. + for normative referenced materials to be scrutinized. See Normative References Guidelines.
  • Does this specification have any normative references to a Rescinded/Obsolete/Superseded Recommendation? Documents must not include normative references to a @@ -1009,7 +1004,7 @@

    Requirements for updating a STATU review.
      -
    • Make sure to look at How to do Wide +
    • Make sure to look at How to do Wide Review
    • Was the public requested to review the document (such as announcement from a previous publication)?
    • @@ -1549,7 +1544,7 @@

      Scheduling Publication

      Tip: STATUSs published through the W3C automatic system do not need to get scheduled with the - Webmaster and are not subjected to publishing moratoria. + Webmaster and are not subjected to publishing moratoria.

      7 days for transition: Unless there are exceptional @@ -1690,7 +1685,7 @@

      Publication Request

      of the calendar year and around certain W3C events such as AC meetings and All-Group meetings. The Communications Team announces these publishing moratoria with approximately six months notice. The - announcements are linked from the Chairs' Guidebook.

      + announcements are linked from the Chairs' Guidebook.

      Publication

      @@ -2401,4 +2396,4 @@

      Call for Exclusions

      stroke: black; stroke-width: .5 } - \ No newline at end of file + From 940dfaae41f258d2e62435095a5f5ca89fec7f05 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Thu, 9 Jan 2025 14:50:03 +0100 Subject: [PATCH 202/225] Update links and code reformating --- transitions/nextstep.html | 589 +++++++++++++++++++------------------- 1 file changed, 291 insertions(+), 298 deletions(-) diff --git a/transitions/nextstep.html b/transitions/nextstep.html index 5c7579f27..b5634f0b7 100644 --- a/transitions/nextstep.html +++ b/transitions/nextstep.html @@ -3,340 +3,333 @@ toc: false --- +

      About This Document

      -

      About This Document

      +

      This resource assists in finding the internal W3C Technical Report publication processes.

      -

      This resource assists in finding the internal W3C Technical Report - publication processes.

      - - -

      Next Steps

      -
      - -
      You may use a TR shortname to find out your next step
      - +

      Next Steps

      +
      + +
      You may use a TR shortname to find out your next step
      + -
      +
      -
    -

    Not sure what's your next step? Try our step finder +

    Not sure what's your next step? Try our step finder and look at milestones calculator.

    @@ -1584,7 +1584,7 @@

    Publication Request

  • Information:
    • Document Title: xxx xxx
    • -
    • Document URL: https://www.w3.org/TR/yyyy/XX-xxx-yyyymmdd/
    • +
    • Document URL: https://www.w3.org/TR/yyyy/XX-xxx-yyyymmdd/
    • *Publication Date: (if document not installed) Month Date Year
    • *Description: Used in TR/xx/all page (only needed if differ From 278be8bef6ce4339afd50b0f86947793f8d555fa Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Thu, 9 Jan 2025 15:21:17 +0100 Subject: [PATCH 205/225] Fix links --- transitions/index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/transitions/index.html b/transitions/index.html index 490f8d798..f929002d7 100644 --- a/transitions/index.html +++ b/transitions/index.html @@ -312,7 +312,7 @@

      Steps for the STATUS. The Group MUST show that the changes have received wide review in order to publish the STATUS. - See the considerations, guidelines and best practices + See the considerations, guidelines and best practices that groups should follow to get early and wide review of a document.

    @@ -1004,7 +1004,7 @@

    Requirements for updating a STATU review.
      -
    • Make sure to look at How to do Wide +
    • Make sure to look at How to do Wide Review
    • Was the public requested to review the document (such as announcement from a previous publication)?
    • From 2e62ef25c214dd448510a3af0c9be951d674804f Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Thu, 9 Jan 2025 15:28:27 +0100 Subject: [PATCH 206/225] Fix links pointing to specific Process Document sections --- transitions/index.html | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/transitions/index.html b/transitions/index.html index f929002d7..c4281bafb 100644 --- a/transitions/index.html +++ b/transitions/index.html @@ -457,7 +457,7 @@

      Steps for
    • The Document Contact prepares the document in accordance with pubrules and develops a proposed publication schedule, taking into - account possible publishing moratoria. The + account possible publishing moratoria. The title page date is chosen based on the anticipated publication schedule.
    • @@ -717,7 +717,7 @@

      Transition Requirements for S

      Include a link to an issues list, such as GitHub issues, that indicates that errata have been responded.

      -
    • must provide public documentation of any Formal Objections. +
    • must provide public documentation of any Formal Objections.

      Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.

      @@ -760,7 +760,7 @@

      Transition Requirements for S

      Requirements for revising a STATUS

      -

      A Working Group should publish a Working Draft to the W3C Technical Reports page +

      A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

      @@ -812,7 +812,7 @@

      Requirements for updating a STATU
      • must obtain Team verification, - or fulfill the criteria for Streamlined Publication Approval. + or fulfill the criteria for Streamlined Publication Approval.

        Submit an update request.

      • must record the group’s decision to request the update. @@ -1042,7 +1042,7 @@

        Requirements for updating a STATU

        Requirements for publishing a STATUS

        -

        A Working Group should publish an Update Draft to the W3C +

        A Working Group should publish an Update Draft to the W3C Technical Reports page when there have been significant changes to the previous published document @@ -1188,13 +1188,13 @@

        Updating a STATUS with

        Highlight any substantive issues.

      • must not have any substantive changes since the most recent Candidate Recommendation Snapshot, - other than dropping features identified at + other than dropping features identified at risk.

        Include, for example, a link to a change log. If substantive changes were made, the Working Group must republish the document at an earlier status.

      • may have removed features - identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification + identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot.

        The list of features at-risk that have been removed must appear in the Status of the Document, if any.

        @@ -1212,7 +1212,7 @@

        Updating a STATUS with will ensure about this. No need to indicate anything beyond providing the Status of the Document.

      • - may identify itself as intending to allow new features (class 4 + may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation, as described in section 6.3.11.4 Revising a @@ -1230,16 +1230,16 @@

        Updating a STATUS with
      • must identify where errata are tracked,

        Errata are tracked through GitHub nowadays. The link to your errata page must appear in the document heading. This will be checked by our publication rules.

      • -
      • must not include any substantive changes from the Proposed Recommendation on which it is based. +
      • must not include any substantive changes from the Proposed Recommendation on which it is based.

        Include, for example, a link to a change log where most important changes are highlighted. Otherwise, the Working Group must republish the document at an earlier status.

      • -
      • If there was any dissent in Advisory +
      • If there was any dissent in Advisory Committee reviews, - the Team must publish the substantive content of the dissent + the Team must publish the substantive content of the dissent to W3C and the general public, - and must formally address the comment - at least 14 days before publication as a W3C + and must formally address the comment + at least 14 days before publication as a W3C Recommendation.
          @@ -1317,17 +1317,17 @@

          Transition requirements to STA

      • -
      • must provide public documentation of any Formal Objections. +
      • must provide public documentation of any Formal Objections.

        Provide link(s) to the objection, attempts to satisfy the reviewer, and a public record of the decision.

      • -
      • If there was any dissent in Advisory +
      • If there was any dissent in Advisory Committee reviews, - the Team must publish the substantive content of the dissent + the Team must publish the substantive content of the dissent to W3C and the general public, - and must formally address the comment - at least 14 days before publication as a W3C + and must formally address the comment + at least 14 days before publication as a W3C Recommendation.
          From fad6cb87437498d9884c6653843bcaec0d944aed Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Thu, 9 Jan 2025 16:32:31 +0100 Subject: [PATCH 207/225] Minor markup updates --- transitions/nextstep.html | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/transitions/nextstep.html b/transitions/nextstep.html index b5634f0b7..ef254968b 100644 --- a/transitions/nextstep.html +++ b/transitions/nextstep.html @@ -13,7 +13,7 @@

          Next Steps

          Shortname
          You may use a TR shortname to find out your next step
          - @@ -21,31 +21,32 @@

          Next Steps

        Other resources

        -

        - From b5419bda1762197db0816cb7a56c7617114b7b17 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Thu, 9 Jan 2025 18:27:07 +0100 Subject: [PATCH 209/225] Update prefooter display (use a text component and italic) --- _includes/prefooter.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/_includes/prefooter.html b/_includes/prefooter.html index 50d7c4ccb..d131f1443 100644 --- a/_includes/prefooter.html +++ b/_includes/prefooter.html @@ -1 +1,3 @@ -

        This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.

        +
        +

        This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.

        +
        From 6f8603e065419560efdfcba83c7d01639b2106c0 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 10 Jan 2025 09:10:29 +0100 Subject: [PATCH 210/225] Rename main index from .html to .md --- index.html => index.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename index.html => index.md (100%) diff --git a/index.html b/index.md similarity index 100% rename from index.html rename to index.md From 7e4d566319c2dce87efea83e80c4aabb8ce68a24 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 10 Jan 2025 09:51:49 +0100 Subject: [PATCH 211/225] Convert main index to markdown --- index.md | 649 +++++++++++++++++-------------------------------------- 1 file changed, 203 insertions(+), 446 deletions(-) diff --git a/index.md b/index.md index af76f824b..90caefbbf 100644 --- a/index.md +++ b/index.md @@ -1,447 +1,204 @@ - - - - - The Art of Consensus: A Guidebook for W3C Group Chairs, Team Contact and - Participants - - - - - -
        -

        Also On This Page → 

        - -
        -
        -

        Chair Training Modules

        - -
        -
        -

        Current and Upcoming

        - -
        -
        -

        Nearby

        - -
        -
        - - -

        Starting a Group

        - - -

        Running a Group

        - - -

        Closing a Group

        - - -

        Specification Development

        - -

        Speaking About Your Work

        - -
        -

        Reference

        -

        Tools in this section and the previous are in wide use and are - supported by the systems team (ask for help on sysreq@w3.org) - and comm team. For service enhancements or new systems projects, please - contact w3t-sys@w3.org with a - detailed description of your needs. Outages and scheduled operations appear on the W3C System - Status page. See collected wisdom below for - less mature tools.

        -
        -

        Patent Policy

        - -

        Test Suites

        - -

        Process

        - -
        - -

        Note on Member Submissions: Per section - "Scope of Member Submissions" of the Process Document, "when a - technology overlaps in scope with the work of a chartered Working Group, - Members SHOULD participate in the Working Group and contribute the - technology to the group's process rather than seek publication through the - Member Submission process." Read more about how - to send a Member Submission request.

        -

        Collected Wisdom, Advice

        -

        Many of these resources were contributed by your colleagues; we - invite you to write down and share your experiences as well. Discussion - of issues that groups face take place on the chairs mailing list - (Member-only archive). You may - also find chairs meetings back to 1997 an - interesting source of wisdom.

        -
        -

        Advice on Specification Development

        - -

        GitHub

        - -
        -
        -

        Roles

        - -

        Advice on Meetings, Decisions, Issue Tracking

        - -

        Historical

        - -
        -

        About - the Guidebook

        -

        This Guidebook is intended to complement the W3C - Membership Agreement and the W3C - Process. This index page is Public, although a - small number of resources linked from this page may be visible only to the - W3C Membership or Team.

        -

        You are expected to be familiar with the parts of this Guidebook that - affect your work. Working Group chairs should get a "tour" from their team - contact. Then take a look again, for example, if you're going to hold a - face-to-face meeting; read the section on meetings to be sure you understand what's written - there, and to record any valuable knowledge you pick up along the way.

        -

        As editor of the guidebook, @w3c/guidebook will do its best to see that it gets better - over time. This does not mean that we do all the editing ourselves!

        -

        Note: Not all pages are maintained with the same - frequency. Some may be quite outdated. Please add your issues to the GitHub repository of this Guidebook if you have any specific comments and/or proposals to improve this Guidebook.

        -
        -

        Feedback is to @w3c/guidebook - and is welcome on GitHub

        - - +--- +title: The Art of Consensus +toc: true +--- +### Starting a Group {#start} + +- [Recommendation Track Readiness Best + Practices](https://www.w3.org/Guide/standards-track/) +{:#Recommendation} + +- [Create a Charter](process/charter.html) +{:#Charters} + +- [How to incubate](https://www.w3.org/Guide/incubation.html) + + - [W3C Community & Business Groups](https://www.w3.org/community/) + - [W3C Team support for W3C Community Groups](https://www.w3.org/2016/04/cg-support/) + - [W3C Workshops](https://www.w3.org/Guide/meetings/workshops.html)for starting incubation +- [How to transition work from a Community Group to a Working Group](process/cg-transition.html) +- [Join a group](https://www.w3.org/participate/faq.html#join)(see also [Invited Expert Policy](https://www.w3.org/2004/08/invexp.html)) +- If you need a blog, wiki, GitHub repository, or mailing list, ask your team contact. +- ...more [advice on roles in a group](#roles) + +### Running a Group {#run} + +- [W3C Chair Buddy System](https://www.w3.org/Guide/chair/buddy.html)(volunteer experienced Chairs can mentor other Chairs) +- Check out our [Working Groups](https://www.w3.org/PM/Groups/chairboards.html?gtype=working)and [Interest Groups](https://www.w3.org/PM/Groups/chairboards.html?gtype=interest)dashboards to navigate through what we know about them. The Project Management team only maintains a [collection of links and tools](https://www.w3.org/PM/)to keep track. +- [Moderating (Facilitating) Meetings](https://www.w3.org/wiki/Moderating_Meetings) +- [Creating and delivering effective presentations](https://www.w3.org/wiki/Speaker_Resources) +- Running a Meeting (especially a teleconference) on [IRC](https://www.w3.org/Project/IRC/)( [Web client](https://irc.w3.org/)): + + - See [how to setup a new group](tools/new-group.html)for general tooling advises + - [Quick start guide](https://w3c.github.io/scribe2/scribedoc.html)on setting up tools for managing an agenda, generating minutes, and updating issues lists + - [Scheduling teleconferences](https://www.w3.org/Guide/meetings/zoom) + - [Group calendars](https://www.w3.org/Guide/meetings/organize.html#calendars) + - [Holidays wiki](https://www.w3.org/wiki/Holidays)to help planning WG work around recurring holidays + - Individual IRC tools ("bots"): + + - [Zakim](https://www.w3.org/2001/12/zakim-irc-bot.html)for queue management, start and end meeting + - [RRSAgent](https://www.w3.org/2002/03/RRSAgent)for minutes management + - Hints for [rescuing minutes when RRSAgent is absent](https://w3c.github.io/scribe2/rescue.html) +- [Predicting milestones](process/predicting-milestones.html), use our [milestones calculator](https://w3c.github.io/spec-releases/milestones/)to help with dates. +- Face-to-face meetings + + - [**Continuity of Operations under Travel Restrictions**](meetings/continuity) + - [Host a face-to-face meeting](meetings/hosting.html)and [Standard Venue Arrangements for W3C Events: Conferences, Workshops, and Meetings](https://www.w3.org/2011/06/WorkshopHost.html) + - [Policy Regarding Non-Disclosure Agreements and W3C Meetings](https://www.w3.org/2004/06/NoNDAPolicy.html) + - [W3C Travel Policy affecting Staff Contacts](https://lists.w3.org/Archives/Member/chairs/2017JanMar/0141.html) +- Issue tracking: + + - Use [GitHub](https://github.com/w3c/)to track issues through mail and the Web +- [WBS](https://www.w3.org/2002/09/wbs/)for questionnaires +- People management + + - [HumanDimension](https://www.w3.org/wiki/Guide/HumanDimension)(a Chair training module) + - [Code of Conduct](/policies/code-of-conduct/)and [Procedures](/about/positive-work-environment/#Procedures)to assist all parties when issues arise. We have [guidelines to suspend or remove participants from groups](process/suspension.html). See more on the [Positive Work Environment Home Page](https://www.w3.org/Consortium/pwe) +- [Antitrust and competition policy](/policies/antitrust/) +- [Copyrights for documents, software, tests](/copyright/) +- ...more [advice on meetings, decisions, issue tracking](#mtg-advice) + +### Closing a Group {#close} + +- [How to Close a Working Group](./process/closing-wg) + +### Specification Development {#Deliverables} + +- [W3C Editors home page](editor/)and specifically the [Style for Group-internal Drafts](editor/editors-draft) +- Advancement on the Recommendation Track: + + - [W3C Process for Busy People](https://github.com/w3c/wg-effectiveness/blob/master/process.md) + - [Section 6.3 Technical Reports](/policies/process/#rec-advance)of the W3C Process + - Considerations for [joint deliverables](process/joint-deliverables.html) + - [Transition requirements](https://www.w3.org/Guide/transitions/)for all W3C maturity levels (First Public Draft, Last Call, CR, PR, REC, etc.). Try also our [step finder](https://w3c.github.io/transitions/nextstep.html)and look at [milestones calculator](https://w3c.github.io/spec-releases/milestones/). + - [Request Wide Review](https://www.w3.org/Guide/documentreview/)at least *2-3 months before CR*, to allow time for discussion and rework. This includes requesting [horizontal reviews](https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review). + - [Pubrules](https://www.w3.org/pubrules/)( [publication requirements](https://www.w3.org/pubrules/doc)) and links to related policies (e.g., [namespaces](https://www.w3.org/2005/07/13-nsuri), [MIME type registration](https://www.w3.org/2020/01/registering-mediatypes), [version management](https://www.w3.org/2005/05/tr-versions), and [in-place modifications](https://www.w3.org/2003/01/republishing/)) + See also [Pubrules issue management](https://github.com/w3c/specberus/issues) + - **March 2017**: [Obsoleting and Rescinding W3C Specifications](https://www.w3.org/2016/11/obsoleting-rescinding/) +- [Normative References](process/tilt/normative-references.html); considerations the Team takes into account when evaluating normative references +- Addressing formal objections: [best practices to resolve and decide Formal Objections](./council/council)(aka council guide) +- Publications can only happen on Tuesdays and Thursdays ( [Member-only archive of announcement](https://lists.w3.org/Archives/Member/chairs/2009JanMar/0192.html)), unless you use the [automated publication system](https://github.com/w3c/echidna/wiki) +- **September 2015**: W3C Comm Team no longer post Homepage News stories for regular WDs publications, unless explicitly requested at publication request. +- [W3C Documents and license related to API definitions, code samples, or examples](process/binding-license) +- Discussion about specifications tooling and versioning on [spec-prod@w3.org](https://lists.w3.org/Archives/Public/spec-prod/) +- ...more [advice on specification development](#spec-advice) + +### Speaking About Your Work {#speaking} + +- Blogs, articles, Press interviews: Working Group participants, TAG Members, W3C Staff are among the world's experts in Web technologies and their impacts. Give heads-up, share relevant work, things you author, or press enquiries, by writing to the W3C Comm team ( [w3t-pr@w3.org](mailto:w3t-pr@w3.org)) about how you may attribute your work (or not) to W3C. +- Use the [Upcoming Talks form](https://www.w3.org/blog/talks/how-to-add-a-new-talk/)(W3C Group participants, members of the W3C Team, and Office Staff); talks publicized on [W3C home page](https://www.w3.org/), [Public Weekly Newsletter](https://lists.w3.org/Archives/Public/w3c-announce/), W3C Social Media. +- [Press release testimonial guidelines](https://www.w3.org/2004/12/testimonial_pr-guidelines.html) +- [Creating and delivering effective presentations](https://www.w3.org/wiki/Speaker_Resources) +- [How to Make Presentations Accessible to All](https://www.w3.org/WAI/training/accessible) + +## Reference {#ref} + +*Tools in this section and the previous are in wide use and are supported by the systems team (ask for help on [sysreq@w3.org](mailto:sysreq@w3.org)) and comm team. For service enhancements or new systems projects, please contact [w3t-sys@w3.org](mailto:w3t-sys@w3.org)with a detailed description of your needs. Outages and scheduled operations appear on the [W3C System Status page](https://status.w3.org). See [collected wisdom](#sa34)below for less mature tools.* + +#### Systems and Tools {#systems} + +- [Markup Validators](https://validator.w3.org/), [Link checker](https://validator.w3.org/checklink), [Spell checker](https://www.w3.org/2002/01/spellchecker), [HTML diff tool](https://services.w3.org/htmldiff), [SpecRef](https://www.specref.org/), [normative references checker](https://labs.w3.org/normative-references/), [bibliography generator](https://www.w3.org/2002/01/tr-automation/tr-biblio-ui), and [more tools](https://www.w3.org/2004/12/wg-tools.html) +- See also: [Tools Wiki](https://www.w3.org/2006/tools/)and [W3C Editors home page](editor/) +- [Mailing list archive](https://lists.w3.org/Archives/Member/w3c-tools/)of tools announcements (Member-only) +- [Predefined ACLs](https://www.w3.org/2002/02/auto-acl) +- [Edit your contact information or affiliation](https://www.w3.org/users/myprofile) +- Start with [modern tooling](https://github.com/w3c/modern-tooling/issues)for ongoing tooling issues. + +#### Mailing Lists {#mlistools} + +- [Mailing List Audit](https://www.w3.org/Member/Mail/AuditForm)(who is subscribed, information about lists) (Member-only) +- [SmartList Remote Maintainers Guide](teamcontact/RemoteMaintainers.html) +- [Spam filtering options](https://www.w3.org/2002/11/spam-filtering) +- [Mailing Lists Search service](https://www.w3.org/Search/Mail/) + +#### Guidelines and Policies {#policies} + +- [Antitrust and Competition Guidance](/policies/antitrust/) +- [Charter Extensions](https://www.w3.org/2015/04/charter-extensions.html) +- [External Funding](https://www.w3.org/2017/05/external-funding.html) +- [Invited Experts policy](https://www.w3.org/participate/invited-experts/) +- [IPR policies](https://www.w3.org/policies/) +- [NDAs and W3C Meetings](https://www.w3.org/2004/06/NoNDAPolicy.html) +- [Normative References guidelines](process/tilt/normative-references.html) +- [Processing of Formal Objections](council/council) +- [Continuity of Operations under Travel Restrictions](https://www.w3.org/Guide/meetings/continuity.html) + +#### Patent Policy {#patents} + +- [W3C Patent Policy](/policies/patent-policy/) +- Commentary: [FAQ](https://www.w3.org/2003/12/22-pp-faq.html), [Summary](https://www.w3.org/2004/02/05-patentsummary.html), and [Business Benefits](https://www.w3.org/2004/03/pp-points-20040210.html) +- Patent Policy Information about Groups and Disclosures can be found from the [Group pages](https://www.w3.org/groups/) +- ...more questions? Contact the [PSIG](https://www.w3.org/2004/pp/psig/) + +#### Test Suites {#testsuites} + +- Start with [web-platform-tests](http://web-platform-tests.org/), home for the Open Web test suites (including W3C ones). +- All WPT contributions are licensed under the terms of the [3-Clause BSD License](https://github.com/web-platform-tests/wpt/blob/master/LICENSE.md). For non-WPT test suites, see [Test suites licenses](/copyright/test-suites-licenses/)for Contribution of Test Cases +- ...more questions about the testing infrastructure? Contact [public-test-infra@w3.org](https://lists.w3.org/Archives/Public/public-test-infra/) + +#### Process {#processdoc} + +- [Operative W3C Process Document](/policies/process/) +- [Guidelines to suspend or remove participants from groups](process/suspension.html) +- [Guidelines for disciplinary action](process/suspension.html) +- [Antitrust and Competition Guidance](/policies/antitrust/) +- [Ongoing process issues](https://github.com/w3c/process/issues). Discussion happens in the context of the [W3C Process Community Group](https://www.w3.org/community/w3process/). +- ...more questions? Contact the [Advisory Board](https://www.w3.org/groups/other/ab/) +{:#suspension} + +**Note on Member Submissions:**Per [section "Scope of Member Submissions" of the Process Document](/policies/process/#SubmissionScope), "when a technology overlaps in scope with the work of a chartered Working Group, Members SHOULD participate in the Working Group and contribute the technology to the group's process rather than seek publication through the Member Submission process." Read more about [how to send a Member Submission request](https://www.w3.org/submissions/guide/). + +## Collected Wisdom, Advice {#sa34} + +*Many of these resources were contributed by your colleagues; we invite you to write down and share your experiences as well. Discussion of issues that groups face take place on the chairs mailing list (Member-only [archive](https://www.w3.org/Archives/Member/chairs)). You may also find [chairs meetings back to 1997](chair/meetings)an interesting source of wisdom.* + +#### Roles {#roles} + +- [Chair's role](chair/role.html); [Guidance for Multiple Chairs](https://www.w3.org/wiki/MultipleChairs) +- [Editor's role](editor/role.html), [Editor, Author, Contributor Policies](https://www.w3.org/Signature/Contributor.html) +- [team contact's role](teamcontact/role.html) +- [Liaison's role](teamcontact/liaison-role.html). **Note:**Per [section "Liaisons"](/policies/process/#Liaisons)of the Process Document, liaisons MUST be coordinated by the Team due to requirements for public communication; patent, copyright, and other IPR policies; confidentiality agreements; and mutual membership agreements. +- [Advisory Committee Representative](https://www.w3.org/Member/faq.html)(Member-only) +- [Guidelines for communicating as a member of a W3C elected body](other/elected-body-communication-guidelines.html) + +#### Advice on Meetings, Decisions, Issue Tracking {#mtg-advice} + +- [ESW Wiki](https://www.w3.org/wiki/FrontPage)patterns: [MidwestWeeklyAgenda](https://www.w3.org/wiki/MidwestWeeklyAgenda), [MeetingRecords](https://www.w3.org/wiki/MeetingRecords), [TrackingIssues](https://www.w3.org/wiki/TrackingIssues) +- Doing a [Hybrid Group Meeting](meetings/hybrid-meeting) +- [The Seven Sins of Deadly Meetings](https://www.fastcompany.com/26726/seven-sins-deadly-meetings) + +#### Historical {#historical} + +- [W3C XML Specification DTD + (XMLspec)](https://www.w3.org/2002/xmlspec/), by Norman Walsh. +{:#xmlspec} + +- [XMLSpec diff generation](https://www.w3.org/2008/05/xmlspec-diff-generation/) +- QA resources: [Specification Guidelines](https://www.w3.org/TR/qaframe-spec/), [Handbook for QA in groups](https://www.w3.org/TR/qa-handbook/), and [QA Framework primer](https://www.w3.org/QA/WG/qaframe-primer) +- [HTML Slidy](https://www.w3.org/Talks/Tools/Slidy2/)for slide presentations + +#### Advice on Specification Development {#spec-advice} + +- Most popular editing tools: [Bikeshed](https://speced.github.io/bikeshed/), [respec](https://github.com/speced/respec/wiki) +- [W3C Manual of Style](manual-of-style/) +- [Tips for getting to Recommendation faster](https://www.w3.org/2002/05/rec-tips) + +#### GitHub {#GitHub} + +- [W3C on GitHub](https://w3c.github.io/) +- [Using GitHub for W3C specifications (slides)](https://www.w3.org/2015/Talks/1217-github-w3c/) +- [Using GitHub for Spec Work (documentation)](https://tobie.github.io/specs-on-github/) +- [GitHub Repository Manager](https://labs.w3.org/hatchery/repo-manager/): One interface to find all group github contributors and the IPR status +- [Github repo activity digest](https://lists.w3.org/Archives/Member/chairs/2016OctDec/0100.html)(Member-only) +- [Adds preview and diff links to pull requests](https://lists.w3.org/Archives/Public/spec-prod/2017JanMar/0047.html)( [Config Helper](https://tobie.github.io/pr-preview/config.html)) + +## About the Guidebook {#care-and-feeding} + +This Guidebook is intended to complement the [W3C Membership Agreement](https://www.w3.org/Consortium/Agreement/Appendix)and the [W3C Process](/policies/process/). This index page is **Public**, although a small number of resources linked from this page may be visible only to the W3C Membership or Team. + +You are expected to be familiar with the parts of this Guidebook that affect your work. Working Group chairs should get a "tour" from their team contact. Then take a look again, for example, if you're going to hold a face-to-face meeting; read the [section on meetings](#Meetings)to be sure you understand what's written there, and to record any valuable knowledge you pick up along the way. + +As editor of the guidebook, [@w3c/guidebook](https://github.com/orgs/w3c/teams/guidebook)will do its best to see that it gets better over time. This does *not*mean that we do all the editing ourselves! + +**Note:**Not all pages are maintained with the same frequency. Some may be quite outdated. Please add your issues to the [GitHub repository of this Guidebook](https://github.com/w3c/Guide/issues)if you have any specific comments and/or proposals to improve this Guidebook. From de8f6b542f8068db8c70b57515b5931a2b4f3896 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 10 Jan 2025 11:28:19 +0100 Subject: [PATCH 212/225] convert wide-review-request.html --- transitions/wide-review-request.html | 748 +++++++++++---------------- 1 file changed, 310 insertions(+), 438 deletions(-) diff --git a/transitions/wide-review-request.html b/transitions/wide-review-request.html index 16514ada7..e9c308f3f 100644 --- a/transitions/wide-review-request.html +++ b/transitions/wide-review-request.html @@ -1,173 +1,35 @@ - - - - -Request a wide review - - - +--- +title: Request a wide review +toc: false +--- - - - - - - - - -

        About This Document

        This resource assists in request the wide review of a document.

        -

        ****MOCKUP - DO NOT USE*****

        -
        -

        - You may use a TR to find out your next step:
        -

        - - - -
        -
      • In-place modification of W3C Technical Reports
      • "; + function listItem(text, query) { + let id = "option" + Math.round(Math.random() * 10000); + return "
      • " + `
        ` + `` + `
        "; + +"
      • "; + } + + function nextSteps(spec) { + let base = "https://www.w3.org/Guide/transitions?"; + let next = document.getElementById("next"); + let list = document.getElementById("step_list"); + + if (spec.isGroupClosed) { + if (spec.status === "Recommendation") { + list.innerHTML = + INPLACE + + listItem("Publish an Amended Recommendation with only editorial changes", "profile=REC&rec=editorial") + + listItem("Publish a Candidate Recommendation with substantive changes (but no new features)", "profile=CR&cr=rec-amended") + + listItem("Propose to obsolete or supersede the Recommendation", "profile=PR-OBSL"); + } else if (spec.status === "Group Note") { + list.innerHTML = INPLACE + listItem("contact webreq@w3.org", "profile=WG-NOTE"); + } else if (spec.status === "Retired") { + list.innerHTML = listItem("Propose to restore the Recommendation", ""); + } else { + list.innerHTML = listItem("Publish as Working Group Note (oops, this should have been done already)", "profile=WG-NOTE"); + } + } else if (spec.status === "Working Draft") { + // !isGroupClosed(spec) + let WD = ""; + if (!spec["_links"]["predecessor-version"]) { + function formatNumber(n) { + return n < 10 ? "0" + n : n; + } + let today = new Date(); + let sToday = today.getUTCFullYear() + "-" + formatNumber(today.getUTCMonth()) + "-" + formatNumber(today.getUTCDate()); + if (sToday === spec.date) WD = INPLACE; // same day only + } + list.innerHTML = + WD + listItem("Update the Working Draft", "profile=WD") + listItem("Advance to Candidate Recommendation", "profile=CR&cr=new") + listItem("Publish to Working Group Note (which you may mark as retired)", "profile=WG-NOTE"); + } else if (spec.status === "Candidate Recommendation") { + list.innerHTML = + listItem("Update the Candidate Recommendation Draft", "profile=CR&cr=draft") + + listItem("Update as a Candidate Recommendation Snapshot", "profile=CR&cr=snapshot") + + listItem("Advance to Proposed Recommendation", "profile=PR") + + listItem("Return to Working Draft", "profile=WD&returning=true") + + listItem("Publish as a Working Group Note (which you may mark as retired)", "profile=WG-NOTE"); + } else if (spec.status === "Candidate Recommendation Draft" || spec.status === "Candidate Recommendation Snapshot") { + list.innerHTML = + listItem("Update the Candidate Recommendation Draft", "profile=CR&cr=draft") + + listItem("Update as a Candidate Recommendation Snapshot", "profile=CR&cr=snapshot") + + listItem("Advance to Proposed Recommendation", "profile=PR") + + listItem("Return to Working Draft", "profile=WD&returning=true") + + listItem("Publish as a Working Group Note (which you may mark as retired)", "profile=WG-NOTE"); + } else if (spec.status === "Proposed Recommendation") { + list.innerHTML = + listItem("Advance to Recommendation", "profile=REC&rec=new") + + listItem("Return to Working Draft", "profile=WD&returning=true") + + listItem("Publish as a Working Group Note (which you may mark as retired)", "profile=WG-NOTE"); + } else if (spec.status === "Recommendation") { + list.innerHTML = + INPLACE + + listItem("Update the Recommendation with only editorial changes", "profile=REC&rec=editorial") + + listItem("Publish as a Recommendation with candidate corrections (substantive changes)", "profile=REC&cr=candidate-corrections") + + listItem("Publish as a Recommendation with candidate additions (new features)", "profile=REC&cr=candidate-additions") + + listItem("Incorporate candidate corrections (substantive changes)", "profile=REC&cr=substantive") + + listItem("Incorporate candidate additions (new features)", "profile=REC&cr=features") + + listItem("Publish as a First Public Working Draft with new features (if your current Recommendation doesn't allow those)", "profile=FPWD") + + listItem("Propose to rescind the Recommendation", "profile=PR-RSCND") + + listItem("Propose to obsolete or supersede the Recommendation", "profile=PR-OBSL"); + } else if (spec.status === "Group Note") { + list.innerHTML = INPLACE + listItem("Update the Working Group Note (which you may mark as retired)", "profile=WG-NOTE"); + } else if (spec.status === "Retired") { + list.innerHTML = listItem("Propose to restore the Recommendation", ""); + } else { + list.innerHTML = listItem("... Not sure yet. See the transition requirements", ""); + } + next.style.display = "block"; + } + + function defaultStep() { + let base = "https://www.w3.org/Guide/transitions?"; + let next = document.getElementById("next"); + let list = document.getElementById("step_list"); + list.innerHTML = listItem("Publish as a First Public Working Draft", "profile=FPWD") + listItem("Publish as a Working Group Note", "profile=WG-NOTE"); + next.style.display = "block"; + } + + function updateSpec(spec) { + let div = document.getElementById("spec"); + console.log(spec); + if (spec === undefined) { + div.style.display = "none"; + document.getElementById("next").style.display = "none"; + defaultStep(); + } else { + for (let key in spec) { + let elt = document.getElementById("spec_" + key); + if (elt !== null) { + let obj = spec[key]; + if (key === "deliverers") { + elt.innerHTML = ""; + spec.deliverers.then((groups) => { + for (let index = 0; index < groups.length; index++) { + let group = groups[index]; + let a = document.createElement("a"); + a.href = group._links.homepage.href; + a.textContent = group.name; + elt.appendChild(a); + if (group["is_closed"]) { + elt.appendChild(document.createTextNode(" (closed) ")); + } + elt.appendChild(document.createTextNode(", ")); + } + }); + } else if (obj instanceof Promise) { + console.log("[Promise] " + key); + } else if (obj.indexOf("https://") !== -1 || obj.indexOf("http://") !== -1) { + elt.innerHTML = "" + obj + ""; + } else { + elt.textContent = obj; + } + } + } + div.style.display = "block"; + nextSteps(spec); + } + } + + function adjustForms() { + // adjust the HTML forms according to the config + trace("adjustForms for " + JSON.stringify(config)); + for (let key in config) { + let input = null; + if (key === "shortname") { + input = document.getElementById("shortname"); + input.value = config.shortname; + } + } + } + + // initialization + + document.getElementById("spec").style.display = "none"; + document.getElementById("next").style.display = "none"; + + for (const [key, value] of new URL(location).searchParams) { + let input; + if (key === "shortname") { + input = document.getElementById("shortname"); + } + if (input !== undefined) { + config[key] = value; + } + } + if (config.shortname !== undefined) { + findShortname(config.shortname); + } + adjustForms(); + + function shortname(e) { + let s = e.target.value; + if (s.length > 2) { + findShortname(s); + } + } + var nodes = document.querySelectorAll("input"); + for (let i = 0; i < nodes.length; i++) { + if (nodes[i].type === "text") { + nodes[i].oninput = shortname; + } + } + trace("restored " + window.location.href); + \ No newline at end of file From 2678df3aaabff19348a58fd80c1d1eb326efc80c Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 10 Jan 2025 11:43:12 +0100 Subject: [PATCH 213/225] typo --- transitions/wide-review-request.html | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/transitions/wide-review-request.html b/transitions/wide-review-request.html index e9c308f3f..3b957877a 100644 --- a/transitions/wide-review-request.html +++ b/transitions/wide-review-request.html @@ -181,8 +181,12 @@

        Other resources

        let INPLACE = "
      • In-place modification of W3C Technical Reports
      • "; function listItem(text, query) { let id = "option" + Math.round(Math.random() * 10000); - return "
      • " + `
        ` + `` + `
        "; - +"
      • "; + return `
      • ` + + `
        ` + + `` + + `
        ` + + `
      • `; } function nextSteps(spec) { From 26367ea031d1f135506669849cad5f847bd52854 Mon Sep 17 00:00:00 2001 From: Laurent Carcone Date: Fri, 10 Jan 2025 11:48:20 +0100 Subject: [PATCH 214/225] Add a submenu publication-policies for transitions/details.md --- transitions/details.md | 1 + 1 file changed, 1 insertion(+) diff --git a/transitions/details.md b/transitions/details.md index 943190ac1..c5997d9c0 100644 --- a/transitions/details.md +++ b/transitions/details.md @@ -1,5 +1,6 @@ --- title: Organize a Recommendation Track Transition (Details) +submenu: [publication-policies] toc: false --- This document explains the processes W3C uses internally to prepare and carry out a transition of a document on the Recommendation Track. This document complements the "[Organize a Technical Report Transition](./)". Please refer to the latest version of "Organize a Technical Report Transition" with this URI: `https://www.w3.org/guide/transitions/`. From 14276b1f0fd025df29fba53e1e8a7d84a4aeaeb4 Mon Sep 17 00:00:00 2001 From: Vivien Lacourba Date: Fri, 10 Jan 2025 15:43:16 +0100 Subject: [PATCH 215/225] Link and markup fixes --- transitions/wide-review-request.html | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/transitions/wide-review-request.html b/transitions/wide-review-request.html index 3b957877a..040f5abf6 100644 --- a/transitions/wide-review-request.html +++ b/transitions/wide-review-request.html @@ -16,9 +16,10 @@

        ****MOCKUP - DO NOT USE*****

        Shortname
        You may use a TR shortname to find out your next step
        - + - +