Echidna and working drafts for non-Rec docs

[r12a]

the i18n WG needs to be able to minimise the difference at any point in time between the TR and the editor's versions of a document. We have many documents on which people may send comments, and we have had problems with people reviewing or not having access to out-of-date versions. Review of github documents is not viable, since we cannot make dated snapshots of such documents – we need people to review the TR versions, but we need those versions to be more regularly updated.

can we please look again at allowing use of Echidna for publishing docs such as those shown below to TR.

at w3c/specberus#143 i see some discussion of how the publication process may need changing wrt to handling of Notes, but i still don't understand why, pending those changes (which are unlikely to happen for a while), echidna cannot be used for Working Drafts of documents intended for eventual Note status.

the following are all currently under development or soon will be, and we look for comments on them at all times.

Character Model for the World Wide Web: String Matching and Searching
http://www.w3.org/TR/2014/WD-charmod-norm-20140715/
http://w3c.github.io/charmod-norm/

Language Tags and Locale Identifiers for the World Wide Web
http://www.w3.org/TR/2015/WD-ltli-20150423/
http://w3c.github.io/ltli/

Requirements for Hangul Text Layout and Typography
http://www.w3.org/TR/2015/WD-klreq-20150414/
http://w3c.github.io/klreq/
(actually two docs, one in Korean)

Indic Layout Requirements
ttp://www.w3.org/TR/2014/WD-ilreq-20141216/
http://w3c.github.io/ilreq/

Predefined Counter Styles
http://www.w3.org/TR/2015/WD-predefined-counter-styles-20150203/
http://w3c.github.io/predefined-counter-styles/

Additional Requirements for Bidi in HTML
http://www.w3.org/TR/2010/WD-html-bidi-20100304/

and very soon
Requirements for Chinese Text Layout
http://w3c.github.io/clreq/
(4 docs, including translations)

and hopefully not long after
Requirements for Ethiopic Text Layout
Requirements for Arabic Text Layout
Requirements for Mongolian Text Layout
Requirements for Tibetan Text Layout
Requirements for Uighur Text Layout
(the latter three include translations)

[tripu]

@r12a, w3c/specberus#143 is pending clarification from @plehegar. There are doubts about what is possible/advisable to do with non-normative docs according to the current rules. I need someone with a better understanding (and some authority) to give clear guidelines before I can tackle this one.

I just assigned that issue to him.

@plehegar, ping :¬)

[r12a]

@tripu i discussed with @plehegar today, and argued that we should decouple the question about long-term policy wrt Note track documents, and look at the feasibility of fixing echidna for publication of working drafts (only) in the meantime, given that i18n and WAI need this now for a good number of docs.

plh said he'd look into the feasibility. I guess that if you have some ideas about what technical changes would be needed to make this happen, and how much work that would be, that would help him.

[tripu]

@r12a, I talked about this today with @deniak too. We believe the exact same rules we are applying when we check WDs should work for WDs-that-are-intended-to-become-notes too. (With the probable exception of one extra rule to make sure that there is copy on the document making it explicit that it's informative, ie, not in REC-track.)

So it's a political o philosophical decision more than a technical one. That being said, I don't think we should bend the rules or cheat ourselves just because we can, to get this done in the short term…

[akuckartz]

👍 I am considering to propose the use of Echidna to a Community Group.

[aphillips]

In a recent teleconference [1], the I18N WG tasked me [2] with following up on this issue formally. I also commented about this on the spec-prod list.

While the Internationalization Working Group publishes some documents on the REC track, like a few other "horizontal" groups (accessibility, security, privacy, and the like), we also publish a reasonably large number of Working Group Notes.

One reason for a Working Group Note is to record some work for historical purposes, such as setting down the requirements that went into some REC or recording work done on a document that has been abandoned. Unlike those purposes, our WG publishes documents with best practices information, authoring guidelines, information about cultures or languages, and other materials. Publication under Note status makes the document available as a reference in other, more normative, documents and provides a stable URL in /TR/ space on the W3C site.

Could you please:

1. Confirm that Note track documents (with a status of Working Draft but not FPWD) can be autopublished using the new tools?
   2a. Assuming (1) is true, clarify the process and other documentation (such as the bullet point about "only normative documentation" at [4])?
   2b. Assuming (1) is false, fix it so that we can?
2. Estimate a schedule for allowing non-REC-track documents or let us know what is necessary to unblock this?

Thanks (for I18N),

Addison

[1] https://lists.w3.org/Archives/Public/www-international/2015AprJun/0267.html
[2] http://www.w3.org/International/track/actions/444
[3] https://lists.w3.org/Archives/Public/spec-prod/2015AprJun/0021.html
[4] https://github.com/w3c/echidna/wiki/How-to-use-Echidna

[tripu]

Hello, @aphillips. I'm now coming back to this issue, and to w3c/specberus#143, and will answer you soon, either here or in the spec-prod mailing list.

[tripu]

Coming back to this one after a long time, I'm a bit confused by some nuances in the status of documents, and overlapping ways to classify them and their intended “track”.

@deniak, do you have clear answers to @aphillips' questions above — #197 (comment)?

[deniak]

@tripu thanks for reviving that issue.
@aphillips I confirm, echidna should be able to handle the documents on Note track. People often publish them as WD that are intended to become NOTES but it's easier to publish a Note directly and update it as the process allows it. And it also makes things easier to understand.

I'm happy to help setting up the auto publishing for a few repositories if it helps.