Skip to content

Commit

Permalink
move files from w3c/transitions
Browse files Browse the repository at this point in the history
  • Loading branch information
@deniak
deniak committed Nov 7, 2024
2 parents 9232f7f + e2f6d9b commit f9c84ab
Show file tree
Hide file tree
Showing 6 changed files with 3,958 additions and 1 deletion.
1 change: 0 additions & 1 deletion transitions
Submodule transitions deleted from 3537e0
69 changes: 69 additions & 0 deletions transitions/HOWTO.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
# The Fu to edit the transition requirements

HTML elements are displayed (or not) based on the user selection.

When an option is selected, it updates the URL of the document with a new set of parameters. Those parameters are reflected within the HTML document using the @data attributes.

So far, we have the following data attributes (each matching a URL parameter):

1. `data-profile` for a |-separated list of profile
2. `data-rec` for a |-separated list of REC paths
3. `data-cr` for a |-separated list of CR paths
3. `data-informativeOnly` for a |-separated list of FPWD and WD paths
4. `data-returning` for a |-separated list of FPWD and WD paths
5. `data-notehistory` for a |-separated list of first [working|interest] group note paths
7. `data-echidna` for automatic publishing

If no data attributes are present, the element will get displayed for all possible states *within the scope of the parent element*. For example, to display an element for all types of Recommendations, use `data-profile="REC"` and don't use the `data-rec` attribute on that element.

The data attributes may be combined but, if data attributes are used, one of them must be `data-profile`, otherwise the other data attributes will be ignored.

You may use multiple values for each attribute, separated by `|`. For example, to display an element for all types of Recommendations and Candidate Recommendations, use `data-profile="REC|CR"`.

e.g.
```
<div id='d1' data-profile="CR">
<p id='e1'>This is a new publication.</p>
<p id='e2' data-profile="CR" data-cr="new|snapshot">It will a snapshot (which might be the first snapshot).</p>
<p id='e3' data-profile="CR" data-cr="draft">It will be a draft.</p>
<p id='e4' data-profile="REC">This is bogus.</p>
<p id='e5' data-rec="new">I did not mean to display this.</p>
</div>
```

If the user selected an updated Candidate Recommendation Snapshot (the URL contains the parameters `profile=CR&cr=snapshot` ):

* `d1`, `e1`, `e2` and `e5` will get displayed. `e3`, `e4` will not get displayed.
* `d1` gets displayed because the profile matches.
* `e1` gets displayed because it's within `d1`.
* `e2` gets displayed because the profile and the cr match.
* `e3` will not get displayed because the cr does not match.
* `e4` will never get displayed since the scope of its parent element `d1` is `data-profile="CR"` (and a document can't be a CR and a REC at the same time).
* `e5` will get displayed because, since there is no `data-profile` on that element, `data-rec` gets ignored. So `e5` is similar to `e1`.

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

To add or remove a document status, one must:

1. remove or add the status in the HTML option elements (id="profile")
2. add or remove HTML input elements if applicable
3. Update the data-profile attributes

If HTML input elements were added or removed:
1. update the corresponding data- attributes
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

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

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
229 changes: 229 additions & 0 deletions transitions/details.html
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,229 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Details of How to Organize a Recommendation Track Transition</title>
<link rel="stylesheet" href="/StyleSheets/generic-base-1.css" type="text/css"/>
<link rel="stylesheet" href="https://www.w3.org/StyleSheets/generic-base-1.css" type="text/css" crossorigin="anonymous"/>
<link rel="stylesheet" type="text/css" href="https://www.w3.org/Guide/assets/main.css" crossorigin="anonymous" />
<link rel="shortcut icon" href="https://www.w3.org/Icons/WWW/Literature.gif" crossorigin="anonymous" />
</head>
<body>
<div id="header">
<span class="logo"><a href="/"><img src="/Icons/WWW/w3c_home_nb"
alt="W3C" height="48" width="72"/></a></span>
<div class="breadcrumb">
<a href="/participate/">Participate</a> &#x2192; <a href="/Guide/">The Art of
Consensus</a> &#x2192;
<h1>Organize a Recommendation Track Transition (Details)</h1>
</div>
<p class="baseline">This <strong>Guidebook</strong> is the collected
wisdom of the W3C Group Chairs and other collaborators.</p>
</div>

<div class="toc">
<h4>Also On This Page &#x2192;</h4>
<ul>
<li><a href="#roles">Roles</a> &bull;</li>
<li><a href="#commteam">Comm Team</a> &bull;</li>
<li><a href="#history">History</a></li>
</ul>
</div>

<div class="toolbox box" style="margin-bottom: 1em">
<h4>Publication Policies</h4>
<ul>
<li><a href="/pubrules">Technical Report Publication Policy</a></li>

<li><a href="/pubrules/doc">About pubrules</a></li>
<li><a href="/2005/05/tr-versions">Version Management in W3C Technical Reports</a></li>
<li><a href="/2005/07/13-pubrules-disclosure">Guidelines for linking to
disclosure pages</a></li>
<li><a href="/2005/07/13-nsuri">URIs for W3C Namespaces</a></li>
<li><a href="/2020/01/registering-mediatypes">How to Register a Media Type for a W3C Specification</a></li>
<li><a href="/2005/04/xpointer-policy">XPointer Scheme Name Registry Policy</a></li>
</ul>
<h4>Resources</h4>
<ul>
<li><a href="/Guide/transitions/">Organize Recommendation Track
Transition</a></li>
<li>Details of Rec Track transitions</li>
<li><a
href="/policies/process/#Reports">Recommendation
Track Process</a></li>
<li><a href="/Guide/editor/">W3C Editors' Home Page</a></li>
<li><a href="/Guide/manual-of-style/">Manual of Style</a></li>
<li><a href="/Guide/editor/editors-draft">Style Guidelines for Group-Internal Drafts</a></li>
</ul>
<h4>Tools</h4>
<ul>
<li><a href="https://validator.w3.org/checklink">Link checker</a></li>
<li><a href="https://validator.w3.org/">HTML Validator</a></li>
<li><a href="https://jigsaw.w3.org/css-validator/">CSS Validator</a></li>
</ul>
</div>

<p id="start">
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:
<code>&lt;https://www.w3.org/Guide/transitions&gt;</code>.</p>

<p>This document does not address:</p>

<ol>
<li>Requirements for documents themselves; see <a
href="/pubrules/doc">Technical Report Publication Policy</a>
("pubrules") for this information.
</li>

<li>What required information must be public; this is covered in <a
href="/policies/process/#requirements-and-definitions">
section 7.2</a> of the Process Document and in the governing patent
policy.</li>

<li>Possible next steps after each transition; see the description
of the <a href="/policies/process/#Reports">Recommendation Track
Process</a>.</li>

<li>The Comm Team's policy regarding <a
href="/2003/01/republishing/">in-place modification of W3C
Technical Reports</a>.</li>
</ol>

<p><a name="Exceptions"
id="Exceptions">Exceptions</a> to these processes <span
class="rfc2119">MAY</span> be authorized by <a href="https://github.com/orgs/w3c/teams/transitions">@w3c/transitions</a>.</p>

<p>The key words <span class="rfc2119">MUST</span>, <span
class="rfc2119">MUST NOT</span>, <span
class="rfc2119">REQUIRED</span>, <span
class="rfc2119">SHALL</span>, <span class="rfc2119">SHALL
NOT</span>, <span class="rfc2119">SHOULD</span>, <span
class="rfc2119">SHOULD NOT</span>, <span
class="rfc2119">RECOMMENDED</span>, <span
class="rfc2119">MAY</span>, and <span
class="rfc2119">OPTIONAL</span> are to be interpreted as described
in <a href="https://www.rfc-editor.org/rfc/rfc2119.txt">RFC
2119</a>.</p>

<h2 id="roles">Roles</h2>

<dl>

<dt id="Webmaster">Webmaster</a>

<dd>The <em>Webmaster</em> publishes documents.</dd>

<dt id="teamVerification">@w3c/transitions</dt>
<dd>Transition approvals are given by <a href="https://github.com/orgs/w3c/teams/transitions">@w3c/transitions</a>,
under the delegation from <a href="/Guide/process/tilt/">Technical issues Lead Team</a>.</dd>

<dt id="Chair">Chair</dt>
<dd>Group Chair responsibilities may be carried out by either the Chair
or Team Contact.</dd>

<dt id="DocContact">Document Contact</dt>
<dd>The <em>Document Contact</em> 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 <a href="#MaintainerContact">Maintainer Contact</a> becomes the <em>Document Contact</em>. Consult the <a href="mailto:team-project@w3.org">W3C
Project Management Lead</a> if you're not sure who is the relevant
Document Contact.</dd>

<dt id="MaintainerContact">Maintainer Contact</dt>
<dd>The <em>Maintainer
Contact</em> is a designated individual tasked with requesting
Team's approval in order to publish a
Recommendation without a Working Group. Consult the <a href="mailto:team-project@w3.org">W3C
Project Management Lead</a> if you're not sure who is the relevant
Maintainer Contact. (Note: as of January 2018, the maintainer
contact is <a href="mailto:plh@w3.org">plh</a>)</dd>
</dl>

<p>See also the <a href="/Guide/editor/">W3C Editor's Home Page</a>
and Guidebook documentation of <a href="#roles">roles of W3C
participants</a>, including the <a href="/Guide/chair/role">Chair's
role</a> and the <a href="/Guide/teamcontact/role">Team Contact's
role</a>.</p>

<h2 id="commteam">Interactions with the W3C
Communications Team</h2>

<p>At various stages during the Recommendation Track process, the
W3C Communications Team assists Working Groups as follows:</p>

<ul>
<li>Organizing formal Advisory Committee reviews (including
scheduling and preparation of review forms).</li>

<li>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 <a href="/press-releases/">W3C press releases</a> into additional
languages.</li>

<li>Soliciting testimonials in support of a document, usually more
than a month in advance of publication of a Recommendation.</li>

<li>Announcing publication to Members and the press.</li>

<li>Listing the publication on the W3C home page and in Member
publications. In general, the Communications Team
drafts home page announcements for publications (see
<a href="/news/">past news items</a>). Input from Team Contacts
for announcements of First Public Working Drafts is appreciated.</li>

<li>Writing speaking points for the press, generally with input
from the Working Group.</li>

<li>Coordinating spokespeople to answer technical questions from
the press.</li>
</ul>

<p>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.</p>

<h2 id="history">History of "How to Organize a Transition"</h2>

<p>20240112: Moved to Github. For future history, see the <a href='https://github.com/w3c/transitions/commits/main/details.html'>github log</a>.</p>

<p>20180416: Fixed broken fragments, updated links, general quality assurance and updates.</p>

<p>20170301: Revised for <a href="/Guide/transitions/">transitions documentation for Process 2017</a>.</p>

<p>20161101: Updated for reorganization 2016</p>

<p>20160804: Transitions 2005 and 2014 superseded by 2015.</p>

<p>20151123: Revised for <a href="/Guide/transitions/">transitions documentation for Process 2015</a>.</p>

<p>20140801: Revised for <a href="/Guide/transitions/">transitions documentation for Process 2014</a>.</p>

<p>20060131: Revised for
release with pubrules. <a href="https://lists.w3.org/Archives/Member/chairs/2006JanMar/0026.html">Released 31 January 2006</a> but created in August
2005.</p>

<p><a href="/2003/12/01-transitions">20031201</a>: Version sent for
review with 24 Dec 2003 Process Document.</p>

<p><a href="/2003/05/Transitions">20030501</a>: Version published
with June 2003 Process Document.</p>

<hr>
<p>Feedback is to <a href="https://github.com/orgs/w3c/teams/transitions">@w3c/transitions</a>
and is welcome on <a href="https://github.com/w3c/transitions/issues">GitHub</a></p>

</body>
</html>

Loading

0 comments on commit f9c84ab

Please sign in to comment.