Meeting minutes
Approval of minutes from the last two meetings: 1 , 2
pfps: The ones from two weeks ago are missing headings
<enrico> apologies I leave for few minutes
<gtw> I was present on zoom but not irc last week (16 January 2025), so missed recording presence.
pchampin: I can check the log and see what I can do.
<ora> PROPOSAL: Approve minutes of last two meetings (provided pchampin fixes the heading issue)
<tl> +1
<Dominik_T> +1
<ora> +1
<niklasl> +1
<gkellogg> +1
<ktk> +1
<AndyS> +1
<james> +1
<gtw> +1
<TallTed> +1
<eBremer> +1
<doerthe> +1
<pchampin> +1
<Souri> +1
RESOLUTION: Approve minutes of last two meetings (provided pchampin fixes the heading issue)
<AZ> +1
<pchampin> gtw, I will fix the minutes and add you to the present list
Prioritization of next week's topics 3
ora: do we want to discuss the mode of operation here?
pfps: there are topics we may be able to do quickly. There are many issues with directional language strings. This is needed for rdf entailment
… we might have a quick vote next week to say yes or no
ora: sounds good
<pfps> the issue is are directional strings a required datatype for RDF entailment?
<pfps> #139
<gb> Issue 139 are directional strings a required datatype for RDF entailment? (by pfps) [needs discussion]
gkellogg: these requirements are required for other things. I'm surprised there is controversy.
ora: anybody disagrees with this
pfps: I do
<pfps> I don't see that there is anything that depends on whether directional language string are required in RDF entailment.
pfps: I think this is something that needs to be decided
<pchampin> I think it can be a quick decision, but yes, it needs to be formally decided
ora: let's make this the first vote next week
pchampin: I suggest a topic next week. It resonates with things enrico said in previous meetings.
… The topic is reconsider the relationship between triples and triple terms, what enrico calls triples structure
… when we switched to triple term we kind of shifted things and we have two different things now.
… I don't like this. If we come back to what rdf star had it would be cleaner.
… I propose to create an issue for it and discuss it next week.
gkellogg: there are other things in the way. The notion of triple terms in subject position will not go away. And until it does, we can't really make progress on other documents.
<pchampin> +1 to make a final(ish) decision about triple-terms in the subject position
gkellogg: There is some renewed discussion about RDF/XML and we need to figure out how to support triple terms in RDF/XML.
… We need to decide if we want to invest effort into that or if we address it after everything else is done.
ora: is this a show stoper for other things?
gkellogg: it is not. But it is not a dead format.
<niklasl> Let's address this.
ora: At some point we should adress it. Is it important enough to discuss it now?
gkellogg: it's the triple term in subject position that is the roadblock
<niklasl> I also agree with pchampin's suggested topic.
AndyS: I'm sympathetic to pchampin request. Could we do that last next week to not overrun the time.
niklasl: I agree with AndyS
doerthe: the xml discussion was related to the triple term in subject position. We in the semantic TF had the discussion that this might not be possible in RDF/XML
<tl> there seems also to be a question if/how rdf:ID in RDF/XML relates to triple terms and reifiers
Topics for next week: vote about language direction, triple term in subject position, terminology about triples and triple terms.
<niklasl> I'd say everything is "possible", but every new feature has as cost and consequence (was is the added usefulness, what are the possibly negative consequences).
<pfps> directional strings issue is w3c/
<gb> Issue 139 is rdf:dirLangString a required datatype for RDF entailment? (by pfps) [needs discussion]
ora: how do people feel about talking RDF/XML first regarding having it in subject position?
<tl> +1 to gregg
gkellogg: if we agree to having it in the abstract syntax it does not mean that every serialization has to support it.
ora: Then we have the triple terms in subject position first, then pchampin one. And RDF/XML last, in case we still have time.
pfps: We need to talk about re-use of mime-types at some point in time.
… there is an issue and it has "needs discussion" on it.
ora: let's add this as backup
<niklasl> I agree that we need to, but I think it would be tough to have that too... (Maybe measure the temperature though.)
gkellogg: If we discuss this we should invite Ruben Verbough as well, to get his perspective.
AndyS: This discussion should move forward in the issue first.
doerthe: I can ping Ruben about it.
Review of open actions, available at 4
<pchampin> w3c/
<gb> Action 137 create label spec:new-feature, and add reference to class-X in the relevant label descriptions (on afs, pchampin) due 2024-11-28
pchampin: we can close w3c/
Review of pull requests, available at 5
pchampin: I sent an email to all the editors about the way we manage PRs.
… I remember we decided in the begining of the group how long PRs are open and when they are closed.
… We said every PR has to be discussed before it is merged. That is not efficient.
… With RDF Concepts we said have a look at the full document and say what is a problem.
… I propose we finish that with RDF Concepts and use the method for other documents as well.
… We have the administrative meeting only every other week, which makes the process not very agile.
… If a PR is merged this does not mean that it cannot be undone with someone comes with new agruments.
… The only change is that if editors get enough support in the issue they can merge it before the next meeting.
… I want to know what other think about this.
… We won't go to CR with any document before discussing it in the whole group.
… But we do it in a larger way and not on PR level.
ora: this also implies that we keep the PRs small and granular.
pchampin: yes
… Our process made sense when we had big decisions to take. More we discuss more granular things.
TallTed: To date PRs have been pretty large scale. That has led to take them much longer. They are large and take a lot of comments.
… I proposed to replace some comas with dashes. Some of them were closed without remark.
… I don't agree to rush through them, some things take time.
tl: In principle I agree. I have two problems. I don't follow github closely, I would like to get an announcement on the mailing list before it gets merged.
… Also what happens with comments that did not make it, should I open a new issue/PR?
AndyS: I put in a lot of small remarks, the system does not work.
… I would like to have small PRs but it does not work on the system we have right now. It takes too long.
… It is also hard to follow some of the discussions. Some have 80 comments on them, you can't catchup with them. I would prefer to have some of these comments in the document instead.
pchampin: to tl. If a PR is merged we can decide if the issue was solved or not. it can stay open.
… to TallTed. It is natural that big PRs take longer to review than small ones. That's why I propose small ones. But if we have many small ones they are overlapping and if we don't merge them fast, it does not work.
… We should be more disciplined in comments we have on the issue and with those in PRs. So we don't get sidetracked in the PRs.
ktk: how was this done in the days before GitHub & PRs?
AndyS: Documents were written and reviewed
TallTed: pass systems for me had editors not just being discrete about things but going of in their direction. These things were managed in wikis often. A changelog in a big document in a wiki does not work.
… That did lead to problems years later.
… For what we are doing today. If a discussion is going longer than it should, we can create issues from discussions in a PR via "Use this to create a new issue"
… So we can address it later. But I want to make sure these decisions are taken by a group as a whole and not just by individuals.
gkellogg: GitHub is a tool and it's valuable. But it created some confusion. The role of editors in W3C is clearly defined.
… Editors have a role and even when we have PRs, not everyone becomes an editor.
… I support a streamlined mechanism to get PRs in.
… The flow is far too stuck the way we are.
… If things are not addressed in a PR, create an issue.
niklasl: I agree with that.
… Regarding the primer we have > 100 comments. We should merge it and create new issues for unresolved comments in the PR.
… I ask for help for that from those who think things are not addressed right now.
… I would prefer that those create a new issue so the comment is properly captured.
ora: I agree with pchampin suggestion. TallTed I hear you, you have valid concerns.
… before much of the discussion was made on the mailing list.
… You can also contact the editor directly, you don't always have to use the mechanism we have in place. That might move too slowly.
… I do think we need a more agile way forward
tl: niklasl merge it IMO
ora: I propose we can try this approach by pchampin. And if it does not work, we can still change it.
pchampin: we tried to reach concensus on every pr.
… that does not work.
AndyS: The editors have to have the right to say no to some input.
james: Some efforts should be made to record that if some comments were made but not resolved, the editor should say there were reviewed but rejected.
ora: So provide clear justification on why it was merged.
PROPOSAL: Merging a PR does not necessarily need consensus. It is good judgement of the editor
<ora> +1
<gkellogg> +1
<ktk> +1
<Dominik_T> +1
<doerthe> +1
<james> +1
<AZ> +1
<pfps> +1
<TallTed> +1
<eBremer> +1
<niklasl> +1
<pchampin> +1
<AndyS> +1
<Souri> +1
<tl> + 1 (and the addition that James just proposed would be useful)
RESOLUTION: Merging a PR does not necessarily need consensus. It is good judgement of the editor.
<enrico> +1 (late)
<ktk> pchampin: there is [xxx] in it in something you said. can you check and replace