Add Considerations section

[csarven]

Include a section on Considerations (with specific subsections).

See also:

• https://solidproject.org/ED/protocol#considerations
• https://solid.github.io/web-access-control-spec/#considerations
• https://solid.github.io/notifications/protocol#considerations
• [..]
• https://w3c.github.io/did-core/#security-considerations , https://w3c.github.io/did-core/#privacy-considerations ...

[melvincarvalho]

-0 not now

I'd much rather we get the superset spec done first before adding this. Some things belong in WebID-Turtle which is different from the superset spec, and other subset specs

[TallTed]

@csarven — I suggest listing the specific subsections you think are necessary or useful (or just possibly relevant, if you want to spend minimum time on this right now) in the initial comment on this issue, possibly as a checkbox list.

It seems likely there should eventually be an issue and/or PR per subsection, and such a checkbox list will help keep track of these until all are complete.

[TallTed]

@melvincarvalho — It seems likely that a similar, though perhaps not identical, set of XYZ Considerations subsections will be appropriate for each spec, albeit with different details.

As to the timing of working on these, I suggest that some labels should be created in the repo, and appropriate labels be put on issues/PRs as we go, along the lines of "before CR", "after CR", "for 1.0 CG Report" "for 1.x CG Report after 1.0", "for 2.0 CG Report or later", etc. Determining the appropriate label(s) for any given issue or PR should be part of periodic triage/review by relevant (sub)group in concert with document editor(s).

In my experience, it's generally better to capture issues like this as/when they're noticed, which does not automatically imply urgency of handling. This helps prevent failing to address such issues because "it wasn't the right time to raise that issue."

[webr3]

suggest that some labels should be created in the repo, and appropriate labels be put on issues/PRs as we go, along the lines of "before CR", "after CR", "for 1.x after 1.0", "for 2.0 or later", etc

Totally inappropriate. This is a CG.

WD and CR are for working groups, not CGs. Do not try to masquerade a CGs work in progress editors drafts as anything close to w3 endorsed standard track, it's explicitly inappropriate to do so.

[TallTed]

@webr3 --

Forgive me. I'm involved in a great many groups, and occasionally mentally misplace which context I'm in.

Yes, WD and CR would be inappropriate labels for this document in this CG. Some mental misalignment might be understandable given that we're currently working on revising on an ED of a REC-track document that was produced (with my participation) in a WG a decade ago and has since been revived in context of a CG with intent to have it adopted by another WG.

All that said, I don't believe I had mentally misplaced myself with my comment above, as I was suggesting labels along the lines of those I listed, not exactly those listed.

Please try not to suggest that I'm doing anything underhanded, here in the public square. It's both extremely inappropriate to suggest such, and extremely unlikely to be what I'm doing. Ironically, in this particular case, I spent literally years trying to get published versions of the 2014 ED to be properly labeled/watermarked/similar as ED, because they included incorrect and inappropriate text and W3C CSS describing and branding themselves as further along the REC-track than they had actually traveled within that old WG.

Finally, please try not to issue commands in my direction. It's extremely inappropriate to do so, and unlikely to achieve your desired result. I am not your inferior (nor vice versa), and I do not appreciate being addressed as if I were such.

[jacoscaz]

/chair hat on

Usual reminder, in this case for @webr3 but it really applies to everyone, myself included: when in doubt 1) assume good faith and 2) make sure that your writing reflects such an assumption.