add affect-specs column to finished-proposals

[ericprud]

It will be easier to reference changes from versioned docs if the affected docs (core, js-api, web-api) are listed in a column next to the date

[dschuff]

#141 implements this.
Having said that, this isn't the only way to provide the metadata about which proposal affects which specs (or even necessarily the best). Could you say a little more about how you expect the spec publication workflow to work, and how this information would be used?

[ericprud]

The W3C publication process promises changes since the last published version. In this case, we're going from the published v1 REC to a 1.1 first public working draft (FPWD). The spirit of this commitment is to offer folks a high-level view of what's changed since they last looked at doc. This guides the public who can see the progress and guides internal review from e.g. accessibility or internationalization who can scan the changes and decide if any new feature falls into their domain.

I'm not entirely sure how auto-publish (echidna) will operate going forward, but this is mostly to meet the requirement for the FPWDs and maybe give other finished-proposals readers a sense of what happened where.