Fixes to the README; creation of echidna manifest #10
Conversation
|
Note that you can't publish a FPWD via echidna. It has to be done the old-fashioned way, starting with a transition request. Details are in The Guide. |
| @@ -0,0 +1,3 @@ | |||
| # ECHIDNA configuration | |||
There was a problem hiding this comment.
Note, we don't need this file anymore. The new publishing system takes care of it for us so feel free to delete this.
When we are ready to auto publish, I can help set that up. Just give me a ping.
There was a problem hiding this comment.
Marcos, do you have a pointer to some documentation around this?
Are you referring to the auto-publish feature, that republishes your document every time you change the ED? We weren't planning to use that, since we often want to get people to review text before replacing the NOTE/WD in TR.
There was a problem hiding this comment.
Marcos, do you have a pointer to some documentation around this?
https://w3c.github.io/spec-prod/
Are you referring to the auto-publish feature, that republishes your document every time you change the ED?
Yes.
We weren't planning to use that, since we often want to get people to review text before replacing the NOTE/WD in TR.
Sorry, I'm bit confused... ".pr_preview" and pull requests are used for reviews, no? The W3C would like to move away from using Github pages in the manner you suggest above (otherwise the stuff on TR is always unnecessarily stale).
There was a problem hiding this comment.
@marcoscaceres it's not the way we've been working. A couple of reasons:
- we commonly need more than one PR/commit to get a change right and complete, and we don't usually want to expose (sometimes incorrect) workings to a Note. We tend to move things to Note, rather than WD, when we feel that there is a certain amount of stability and the text is reliable. When we update a Note, we usually announce the update on Twitter and in our news feed.
- we have almost 30 documents that need to be updated regularly but the changes involve no PRs or changes to the main html file at all. These are the gap-analysis documents. So there's nothing to trigger an auto-update for those.
- the pr_preview previews are often not good enough to check the proposed changes to the document. For example, some styling and javascript get omitted. It's also sometimes easier, especially for complex edits, to generate a new ED so that people can point to it, and/or add further edits that would otherwise produce conflicts. It's useful in those cases not to automatically push the changes to /TR, especially if we're working on something we elevated to Note status.
What i think would be helpful in order to keep TR from getting unnecessarily stale, is a dashboard or (better) notification service which tells me, for each of our 30-40 drafts being worked on, what the gap is between last publication to TR and most recent changes to the ED. If we were pinged once a week with an email that listed items over a week old, with categories such as 'Published this month', 'Published 1-3 months ago', 'Published over 6 months ago', etc. that would be quite useful as a reminder to consider updating TR. That said, we do try to keep on top of things.
There was a problem hiding this comment.
I agree that /TR being stale is a problem. Even the editor themselves sometimes thinks that the /TR version is the latest draft and writes a long issue about some section, but it turns out that the content in the ED is already different.
I think the first two problems raised by @r12a can be solved by manually publishing. It is tracked in w3c/spec-prod#6 (The first problem can be solved by better review of changes to the documents, but is difficult to avoid completely.)
The third problem is indeed an important problem, which is also one of the reasons why the CSSWG puts new features in specs with a higher level. Long-standing PRs are bad for discoverability and tend to cause merge conflicts. As for the PR Preview issue itself, it is tracked in tobie/pr-preview#87
I agree that the notification service idea is a way to solve this issue. I look at the freshness of specs regularly in other groups, but if there is an automatic reminder, it would be better.
- change status to FPWD - change static links to i18n-glossary to point to TR
index.html
Outdated
| @@ -6,7 +6,7 @@ | |||
| <script src="https://www.w3.org/Tools/respec/respec-w3c" async="" class="remove"></script> | |||
| <script class="remove"> | |||
| var respecConfig = { | |||
| specStatus: "ED", | |||
| specStatus: "FPWD", | |||
There was a problem hiding this comment.
Since we have specStatus=FPWD in the echidna file, we don't have to modify the config in the ED here.
There was a problem hiding this comment.
@xfq this isn't going to be published by echidna, since it's going to be published as a FPWD.
However, the ED shouldn't say that it's anything other than an ED. Addison, you can change this to generate the flat file for publication, but you shouldn't commit it to GH like that.
index.html
Outdated
| @@ -6,7 +6,7 @@ | |||
| <script src="https://www.w3.org/Tools/respec/respec-w3c" async="" class="remove"></script> | |||
| <script class="remove"> | |||
| var respecConfig = { | |||
| specStatus: "FPWD", | |||
| specStatus: "WD", | |||
There was a problem hiding this comment.
The status needs to be restored to ED, not WD.
Preparing to publish.
Preview | Diff