Separate the notes from the REC track documents

[mattgarrish]

Most of the notes aren't directly tied to the major revisions, so rather than have to carry them forward each time this pull request splits them off into a new folder.

The changes in a nutshell are:

• created a new wg-notes folder in the repository root
• moved all the notes from the epub33 folder to this directory except epubcfi and locators as they were never published (the fxl notes also remain for now, but those will be moved once the open pull requests are merged)
• the overview and a11y techniques notes are staying in the epub34 folder because these are directly tied to revisions of the REC documents
• add meta tags with http-equiv=refresh to the old note files in the /epub33 folder to redirect people to the new editor drafts
• moved the /common folder to the repository root and updated all the /epub34 and /wg-notes files to reference this location
• left the common acknowledgements.html file in the root of /epub34 since this is the one common file that is revision-specific

I noticed with the acknowledgements that we apply them inconsistently to notes. It seems like about half don't add acknowledgements and half do. For consistency, I've removed the include of the file from all the notes. If we keep acknowledgements in the notes then we have the same problem of needing to reference into a specific revisions list of participants. I don't think it's worth it. We could keep acknowledgements in the overview and a11y techniques, though, since those are tied to a revision. I'm open to going either way on those.

Why I moved /common to the root is similarly because if it's a version-specific folder then the notes get caught either having to be updated to reference into a revision folder or have to have their own copy.

Let me know if anyone has any issues with the above shuffling, or if there are other changes you think we could make.

If you want to review the new directory and file structure, it's probably going to be more readable by going through the branch itself: https://github.com/w3c/epub-specs/tree/move/notes

---

Preview | Diff

[mattgarrish]

Note that we should probably shut off the workflows while making these changes as they're just going to fail trying to publish the redirect files.

We could merge changes to all the paths in the yml files first, but that would trigger a publish and we don't really need new versions as it's only the editor draft locations that change (and the redirects will handle those).

[iherman]

One procedural step: we will have to ask for approval for the republication of the overview and the a11y note. These receiving new short names means it is a new note, new echidna secret token, etc.

We will have to discuss whether we want the history set up so that it jumps back to the epub 33 versions, actually. Probably it should, and that will require some extra magic on the header (we will cross the bridge when we get there).

My proposal is to do these steps (including a formal WG vote for the new votes) once the epub 34 line has been published. Just to avoid hopelessly messing up everything...

[shiestyle]

I agree with separating the notes from the main specs.

[mattgarrish]

My proposal is to do these steps ... once the epub 34 line has been published.

Is it safe to merge this now and do those steps later? I've turned off all the workflows so any changes we make now will only be reflected in the editor drafts.

[iherman]

Is it safe to merge this now and do those steps later? I've turned off all the workflows so any changes we make now will only be reflected in the editor drafts.

Then I do not see why not. I think these steps are safe:

• This PR is merged with all echidna scripts switched off
• The echidna scripts for all notes listed in wg-notes are updated, and they are then safe to be switched on again
• When epub 3.4, rs 3.4 and a11y 1.1.1 are published, I set up new secrets for those to replace the old ones (I will probably reuse the same secret names to avoid confusions); with those we can get those set up for echidna again. (The corresponding echidna script must be updated, too.)
• In parallel with the previous steps we should get an approval for the new short names for the 3.4 notes, publish them and echidna them. Note that there will be a publishing moratorium due to the AC, so these steps will go to April