updated changes section

[himorin]

part of #188 (3rd)

• restored change log inserted at 2022 REC publication
• turned rs-changelog into ul/li list for 2022 REC to current

---

Preview | Diff

[marcoscaceres]

I don't understand why this is needed? ReSpec should be generating this for us?

We can put it in for now and revert it later, but it seems like we are doing things in a messy way to rush things.

[marcoscaceres]

@himorin, is this really a requirement for us to publish as REC? This seems like an epic waste of time to include and maintain, if I'm being honest.

I'd rather delete the entire section if the Process doesn't require us to have it than have this in the document (unless it's automatically generated).

[marcoscaceres]

I think we want this instead: #201

[marcoscaceres]

Should use #201 instead

[himorin]

@himorin, is this really a requirement for us to publish as REC? This seems like an epic waste of time to include and maintain, if I'm being honest.

I'd rather delete the entire section if the Process doesn't require us to have it than have this in the document (unless it's automatically generated).

Ah, I've missed opening this PR before finalizing (but just copy paste from respec output), sorry.
I actually am not exactly sure what we should include in this section (see Note below), but I wondered how (and whether) to include changes made directly into main branch without PR, like editorial changes for turning this spec into candidate-* markup.
I'd happy to follow thoughts of co-chairs and editors (incl. @anssiko @reillyeon ), and these changes sections could be kept left as now. Of course, I am really a fan of automation, but it strongly rely on we are doing good, e.g. strictly following Process or Guide, but in reality I personally think I cannot say myself as acting well at all...
For list of candidates (amendments or corrections) in SoTD, I had the same issue that filtering will not work - which is the root cause why I've started research of #188 ...

Note: text in Process 6.2.1. Publication of Technical Reports as should explain or link to an explanation of significant changes from the previous version. could read as class 3/4 changes?, but Guide for transition mentions substantive change as MUST and significant editorial change as SHOULD..

[anssiko]

I'd happy to follow thoughts of co-chairs and editors (incl. @anssiko @reillyeon ), and these changes sections could be kept left as now.

My recommendation is the editors will generate a changes summary for significant publications such as CR and REC. A summarization model can be used to assist. Thank you for your contributions.

[marcoscaceres]

let's go with #201 and the SoTD (plus the change log). That's more than enough. Plus all the changes are already listed in the purple boxes. That's 3x redundancy and it's a "should", so criteria met.

[himorin]

let's go with #201 and the SoTD (plus the change log). That's more than enough. Plus all the changes are already listed in the purple boxes. That's 3x redundancy and it's a "should", so criteria met.

not to change any decision here, but please note (in mind) that SoTD and purple boxes will be totally removed after publication of next round of WD or CRS (as far as I believe,,,). So, the only item which will remain in future is changelog. (and I suppose I should record on this here (as staff contact's role...),,,)

[marcoscaceres]

Yep, that's #181.

So, the only item which will remain in future is changelog.

As is should be 😉