Data Shapes WG teleconference

spec version / URIs

elianaP: I believe Carine made a proposal?

caribou: I believe HolgerK already merged the PR? Confirmed
… we had a reference to recommendation of SHACL
… i.e. previous version, ending with /tr/shacl
… would become URIs for latest work
… so makes sense to use as stable URI for the work
… /tr/shacl will probably be the 'latest version' shortname

Way of working

elianaP: I believe AndyS has asked some questions?

AndyS: yes I did

elianaP: not everyone can attend all meetings
… not sure what's the general approach, but proposing to work async
… if big decision has to be made, we announce ahead of time
… would be good to address follow-ups during meetings time slots

TallTed: in previous incarnation of this group
… small numbers of east coast participants
… small percentage of the group was impacted
… saw the 4am meeting time *after* it had happened

elianaP: I believe that the meetings are accessible somewhere

<AndyS> https://www.w3.org/2025/01/20-data-shapes-minutes.html

elianaP: not sure where

caribou: it's on the calendar page for the group, pasting here

<caribou> https://www.w3.org/groups/wg/data-shapes/calendar/

<AndyS> https://www.w3.org/2025/02/03-data-shapes-minutes.html

TallTed: default location is perfect

elianaP: what's the actionable approach suggested otherwise?

TallTed: typical w3c practice: decision made in a call, the group has a week to respond to it
… anybody can make a formal objection at any point
… but it's a heavy lift if happens after > 1 week

elianaP: sounds reasonable

ajnelson-nist: ony question is shortest expecting timing w.r.t. resolution?
… 8 days windows after decision is announced?

elianaP: just heard one week?

ajnelson-nist: so someone announces something yesterday, could be discussed today, then closed the week after?

caribou: not expected to vote on all decisions
… decisions will be recorded in the meetings
… people can chime in later
… For publication decisions, Call for Consensus involves responding by email
… or we can use github
… email works

ajnelson-nist: thanks

bergos: about PRs
… as an editor, want to know when to turn something into a PR
… do we need to make a decision here as well?

elianaP: anyone with more experience?

AndyS: case by base basic?
… if the editor sees concensus emerging, then a PR could be opened
… very difficult to know on issue, it's not binary
… so it has to be judgement call
… also don't want editors to go down too many tracks
… not a good use of time

ajnelson-nist: speaking as someone who was forward with an issue
… should anyone feel free to open an PR?
… or is that editor-only delegation?

<TallTed> +1 anyone can start a PR, just like anyone can create an issue

elianaP: in my experience, it's good for people to open PR
… as long as people maintain their branches
… then it's up to editors to decide when appropriate to merge
… any objection with people making PR?

caribou: my advice is that if it's something not controversial, if you are editor, you can start a PR and ask people to comment directly in the PR
… otherwise, you open issue and get the group to discuss, before you get to open a PR
… if not a editor, you might also open a PR e.g., fixing typo, small editorial change, etc.
… default is to open issues first

AndyS: anyone can open PR, it's like code, so please submit PRs
… better to pair with issues
… because logs might not reflect decisions
… related to that: which merge policy to use? merge commit? rebase? squash?

ajnelson-nist: strong pref for merge commit
… so we do not loose info from git blame

caribou: typically we don't squash and don't rebase

AndyS: not rebasing main, only the PR
… so that when a PR is merged, no losing of history *on* main
… avoiding useless PR titles
… e.g, when using git UI "squash and merge"

caribou: right, hence opening issues
… my advice is to discuss with WG, then open issue, then work on PR
… always open issue first

TallTed: reason to open issue in parallel of PR, is because discussion history gets lost
… it's important to know how decision came to be
… also in my experience, there's a collaborative editing process
… even if PR is never merged, the issue is the place for discussion

elianaP: +1
… make sure that decisions for changes are reflected both in issue and PR text

elianaP: about PRs and time frame
… don't think we want timeframe for everything

ajnelson-nist: if question about timeframe becomes a case per case judgment
… should we have 2 people to approve merge request?
… if there's a hint of contrversion on PR, an editor can say "let's not merge yet, let's escalate to WG first"

elianaP: in that case, please make addition to agenda

caribou: it's always better to have ok from the group first
… unless there's truly no controversy
… we can take 5 minutes in the group to go through PRs and vote on them getting merged

elianaP: also good for the group to be aware

elianaP: are we aligned?

HolgerK: on the main branch / gh-pages
… should we make it as protected?

AndyS: one thing is to make it protected, would protect history for ever
… we need that
… then we can have rules for merging

elianaP: not everyone should be able to merge into main

AndyS: could be a problem e.g., admin page
… which is in the same gh-pages branch

caribou: we can create another branch for that

elianaP: and then we can merge later

caribou: now gh-pages branch requires approval

elianaP: sounds fine
… agenda should eventually make it into main
… doesn't have to be merged every week
… any reason not to merge to main?

caribou: we have no main branch

ajnelson-nist: primary branch is gh-pages

AndyS: make every meeting a PR

elianaP: maybe once a semester
… hearing no objection

Scribe rotation

elianaP: would be nice to know in advance so that we don't need to ask
… if there are 2 chairs, maybe the other one can scribe?
… but not opposed to rotating scribes
… not sure how it's done in other groups

caribou: several ways to do it
… e.g., zakim, pick a victim
… if someone can't do it for _any_ reason they can opt out

elianaP: we can do that
… ideally we'd have volunteers too

caribou: if noone designated in advance, then zakim can used
… also want to avoid someone who needs to speak during the meeting
… e.g., making a presentation

elianaP: ok, for next few meetings, will try to identify scribes in advance

ajnelson-nist: can scribe on 4pm, not so much 4am

ajnelson-nist: any place to learn about Zakim?

<caribou> https://www.w3.org/guide/meetings/zakim.html

<caribou> https://w3c.github.io/scribe2/scribedoc.html

Proposed Resolution: Adopt the working drafts w3c/data-shapes#167

HolgerK: this was original input from previous WG
… just took old spec
… divided into core and sparql
… I thought there were no objection so far
… so merged to main branch
… as it's official starting point, we should vote on that
… it's pure syntactic split
… no semantic change
… preserving everything from old spec
… so it's shacl 1.0 split into 2 docs
… few things to be fixes by editors later
… then there will be other docs following same naming schemes

elianaP: no objection from other editors?
… what is the exact process here?

HolgerK: in the previous group, we used to have votes on proposal
… people can say +1 and -1 and everything in between
… not sure if same process applies

caribou: we could just ask if there's any objection

elianaP: should we use this as example of voting async?

caribou: I don't think in this case
… no need for Call for Consensus (CfC)

TallTed: it is the way to participate in the group

caribou: CfC by email is rather for publication decision
… consensus in WG is evaluated by the chairs
… if objections, there's a way already to do that formally
… CfCs are mostly for transitions and publication
… this draft is not published yet, it's just an editors draft
… for first publication as FPWD, there will be a CfC
… so I do not see problem with proceeding here

elianaP: got it. people can voice objection at any time anyway
… just not needed right now

ajnelson-nist: Q not about process
… HolgerK: do you expect links to be live somewhere?

<ajnelson-nist> https://w3c.github.io/data-shapes/shacl/

ajnelson-nist: as in, rendered somewhere
… the shacl core spec doesn't resolve I think

<ajnelson-nist> https://w3c.github.io/data-shapes/shacl-sparql/ - does not resolve

ajnelson-nist: just checking what's expected here

<ajnelson-nist> https://w3c.github.io/data-shapes/shacl-core/ - does not resolve

HolgerK: haven't tried, will check

<AndyS> https://w3c.github.io/data-shapes/shacl12-sparql/

ajnelson-nist: ok, just don't know where to find those docs

<caribou> https://w3c.github.io/data-shapes/shacl12-core/

AndyS: pasted link

<ajnelson-nist> https://w3c.github.io/data-shapes/shacl12-sparql/ - DOES work, thank you!

AndyS: would like the resolution into the minutes
… then it will be resolved in the minutes
… easier to find later too

RESOLUTION: approve PR 167

YoucTagh: to get the latest editor version, you can go to editor repo, then you take the path, it should work

Robert: what tools people use for editing?
… directly edit the HTML?
… first time editor here

YoucTagh: I just clone the repo, make sure I'm on the right branch, then use liveserver to get the preview, and then push

AndyS: there's a system call ReSpec by W3C

<AndyS> See https://respec.org/docs/

AndyS: best way is to learn from other docs

caribou: also spec-prod@w3.org mailing list to talk to other editors

<caribou> spec-prod@w3.org

<caribou> https://lists.w3.org/Archives/Public/spec-prod/

elianaP: any last minute remarks/questions?
… done within the hour!

elianaP: hope to see you next week at 9am UTC
… have a nice day/night!