Odp: [Editors] Upcoming Editor's call

Gregg Kellogg <gregg@greggkellogg.net>  We have a call scheduled for Wednesday at 18:00 CET/9:00 PST. Pierre-Antoine uploaded the agenda (copied below), but I just wanted to preface this meeting.   * Introductions, contributions and expectations - roundtable  * The editor process (see  github.com https://github.com/w3c/rdf-star-wg/wiki/Editor%27s-guide)  * Next steps  * Next sync : 2 weeks?   This call is intended to sync up the editing process for the over twenty docs we’re working on with a large number of editors. I’ve created an Editor’s Guide wiki page [1] that would probably be useful to go over before the meeting.   Consider attending if you signed up to edit one or more documents, need some suggestions to get started using ReSpec and help us set standard style guidelines for consistency across the different specs. There’s far to much to go through in one meeting, but the Wiki is intended to cover the basics.   I’d like to keep this and future calls informal; we can create actions to report back on, but otherwise not worry about the typical hassles of scribing. But, we will be on IRC, and minutes can be produced from whatever is put there, even if not done as in a typical WG meeting.   For those new to the role of Editor of W3C Specs, I’ll note this bit about roles at W3C [2]:   Editors manage documents and their publication. Editors play different roles in different groups, at times reflecting decisions of the group, at other times leading by drafting proposals and responding directly to reviewers. Learn more about the Role of Editor.   Thanks for the comprehensive information.   Gregg, you're doing a great job.    At some point, we’ll need to talk about integrating testing, and having tests for normative statements. The data-tests attribute [3] can be used effectively, which helps when it comes time to transition to be sure we have tests for normative statements. I’ve used this in YAML-LD [4] based on work elsewhere. This creates a Tests detail with references to specific tests for a given normative statement. Tooling can reverse this, so that the HTML version of the test manifest links back to the statement in the spec [5]. This would be onerous to do retrospectively, but we might consider using this for new normative language. It comes in handy when doing transitions and showing that each statement has a corresponding test.   What is the practice in this regard? Will these tests be visible at all stages of specification development? Will they also be there when it reaches Recommendation status?   Lastly, we’ll eventually need to consider what it means to be a "Living Standard”. Phillipe Le Hégret gave a presentation on this at the 2020 TPAC [6] and the 2021 Process Document has a section on revising recommendations [7].   I'm not a fan of the Living Standard concept. Maybe because I come from circles (e.g. ISO) where the specifications had their specific versions. In my opinion, "Living Standard" is a jumble of words is a bit contradictory. Because the (official) standard must be discreet (yes, it is constantly developing inside, but outside the users of the standard get the final product). And "Living" means continuous (outside). Therefore, many questions arise, e.g., what about backward compatibility? How to refer to historical fragments (which are changed or deleted)? In my opinion, a discrete specification versioning process makes a lot of sense. This does not mean that we are to deliver a standard and not worry about it. If errors occur, there should be an errata. If new features appear - great, let's make a new version, e.g., according to Semantic Versioning principles [0].   [0]  semver.org https://semver.org/   Best,  Dominik Tomaszuk    Gregg Kellogg   gregg@greggkellogg.net   [1]  github.com https://github.com/w3c/rdf-star-wg/wiki/Editor%27s-guide  [2]  www.w3.org https://www.w3.org/wiki/Guide/Roles  [3]  github.com https://github.com/w3c/respec/wiki/data-tests  [4]  json-ld.github.io https://json-ld.github.io/yaml-ld/spec/  [5]  json-ld.github.io https://json-ld.github.io/yaml-ld/tests/basic-manifest.html#cr-well-formed-1-positive  [6]  www.w3.org https://www.w3.org/2020/10/TPAC/w3c_2020_living_standards_and_reviews.html  [7]  www.w3.org https://www.w3.org/2021/Process-20211102/#revising-rec