On Oct 17, 2019, at 7:34 AM, Michael Dolan <mdolan@...> wrote:

My personal responses in-line below. I've not discussed this with Steve or anyone... (and I will openly admit I'm not as familiar with these parts are you all are).

On Wed, Oct 16, 2019 at 11:14 PM J Lovejoy <opensource@...> wrote:

1) what do we do with the webpage/URL and various places that link to such? redirect to the appendix in the spec? but then what happens when the spec updates?  (It’s really important for people to be able to easily read/find this).  Could we generate the webpage from the spec Appendix markup?

For specs that have subcomponents with faster moving sections, we have had other communities pull those out into separate GitHub .md file and the spec includes the current snapshot of that file at the time of the spec being approved and published as final. That way they have a record of the version at the time it was approved in the spec itself. But the .md file evolves at the pace it needs to.

Yes, I think this is how it has been set up in the PR - as it’s own Appendix and .md file, so one can refer to it separately there. I suppose we could change links to point to the Github .md, rather than the spec, that way it’s “standalone” - but I’m not familiar enough with how the spec is pushed and updated at the individual PR/file level, so could use Gary and Kate’s input here. 

 

2) does this then mean the matching guidelines must follow the cycles/versions of the spec? (it has had it’s own cycle because it doesn’t update very often)

Similar to my answer above, but is it possible to move the "current source" for the guidelines out into a separate .md file? 

yes, already done.

 

3) what about the list of equivalent words- can we have that live as a separate file in the license list Github repo and then have the main relevant matching guideline link to it? and if so, should that list live in the license list repo or with the spec?

Similar reaction as above.

I think the idea of having this list as a separate file is the easy part (apparently this makes it easier for tools to consume), but the question is: where should that file live?