RDF-star WG

Scribe: Alexiev, Vladimir

Approve last week's minutes 1 Approve 2023-02-23 minutes 2

pfps: Still problems with last week's minutes
… no subtopics
… things hard to find

pfps: Soon it will be hard to find what we discussed, important stuff. Minutes should support finding what we did.

ktk: I am at a loss of words.

TallTed: You have a very specific idea of what should be there. W3C has a very loose idea of what minutes are.

<pfps> last week's minutes are minimally acceptable - it would be much better if there were subtopics that were included

TallTed: If there are specific changes you want, draft them, but now we are wasting time. I agree they are not perfect: welcome tyo humanity. Automatic scribing would be worse.

<pfps> I'm happy suggesting changes to the minutes via email or some other method

pchampin: I have a proposal I was making for the CG: For every issue and pull request add a link to the minutes, specific point. Typically when you look at a pull request, you want to know how that relates to what was discussed.

pfps: I can add the things that I find are missing.

ktk: Objections?

pfps: No

ktk: Minutes are approved from last week.

<pfps> updated minutes from 23 Feb look fine

RESOLUTION: approve minutes https://www.w3.org/2023/03/09-rdf-star-minutes.html

ktk: Now the minutes from 23rd of February

pchampin: I added the relevant topics to address Peter's concerns.

ktk: These minutes are also accepted.

RESOLUTION: approve minutes https://www.w3.org/2023/02/23-rdf-star-minutes.html

Resolutions for topics presented on list

ktk: me, ora and pchampin went through Peter's suggestions

<pchampin> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Mar/0064.html

<pchampin> proposals after ""Potential proposed resolutions""

ktk: Now my interpretation is that Peter wants these officially accepteed by the WG

pfps: I call them "potential", they are examples

Moving forward with pending Pull Requests

gkellogg: I wanted to discuss my repeated calls for open pull requests
… There are some process proposals, I responded to those. For example, make better use of the existing project, add issues there.
… I interpreted that I needed to stop work. What can we merge, what can we work on? Many pull requests open in RDF concepts and N-quads.

<Zakim> gkellogg_, you wanted to discuss call for clarification on open pull requests

TallTed: Things at the end of Peter's email are issues
… The old method of just using the mailing list is unwieldy.

<pchampin> +1 to favour GH issues over the mailing list

pchampin: We have not quite figured out how to use the GH project.
… Adrian put me in touch with his dev ops person, he can help.

<gkellogg_> Recall that issues can be manually added to the project: https://github.com/orgs/w3c/projects/20/views/1

pchampin: We have not resolved to publish our FPWD, we need to make progress towards that.

ktk: Gregg, you made some suggestions about pull requests.

<ktk> this guide from gkellogg_ https://github.com/w3c/rdf-star-wg/wiki/Editor's-guide

<pfps> which pull request is the one being talked about?

gkellogg: Pull requests: if there is a review process, and it requests changes and blocks ability to merge, that needs to be resolved, the pull request needs to go back or the status of the review needs to be changed.

<pfps> I think the pull request is w3c/rdf-concepts#16

gkellogg: Asking for changes blocks a pull request.

gkellogg: I was asked to address the pull request process re: editors' guide.
… Asking for changes means you have the duty to clear your comment for progress to be made.
… GH is for this, not discussing everything individually in meetings.
… Can we make use of GH labels?

...we can use github labels to reflect the status of issues

<Zakim> TallTed, you wanted to note that labels are only available to Editors/CODEOWNERS ...

<gkellogg_> Have we set up CODEOWNERS?

<Zakim> VladimirAlexiev, you wanted to ask Can't we let more than the editors edit labels, and maybe even add assignees?

VladimirAlexiev: we could have a smaller set of people approviing changes, but more people editing labels
… Gregg, what is "code owner? A Github mechanism?

<TallTed> CODEOWNERS also have various permissions (e.g., merging PRs) that others don't

gkellogg: yes, it is something that can be setup in github

gkellogg: CODEOWNERS is a mechanism to automatically assign PRs to editors for review before the PR is merged (of course, anyone can request more reviews)

<TallTed> the GitHub Notifications page is https://github.com/notifications ... also useful is the base https://github.com/

<gkellogg_> +1 to giving WG members "triage" permissions to repos.

+1 on everyone being able to add labels

pchampin: currently only W3C editors have write access to repo, and contributors have read access (i.e. must make PRs). There's also a github level "triage" that lets people edit labels and assign issues

<pchampin> https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

<gkellogg_> +1

+1

<pchampin> PROPOSED: give Triage permission to all WG participants in all of our repos

TallTed: let's setup these Github features, and we can always revert if in the future the process doesn't work out

<gtw> +1

+1

<ktk> +1

<afs> +1

<pchampin> +1

<olaf> +1

<TallTed> +1

<doerthe> +1

<Zakim> VladimirAlexiev, you wanted to ask about github Discussions, which are kind of like Issues but may be better for well... discussions

<TallTed> theoretically, only Chairs should add PROPOSED or RESOLVED items

<pfps> +1

RESOLUTION: give Triage permission to all WG participants in all of our repos

ACTION: pchampin to give Triage permission to all WG participants in all of our repos

<ghurlbot> Created action #34

https://docs.github.com/en/discussions

<Zakim> TallTed, you wanted to talk briefly about GH Discussions

VladimirAlexiev: RDF4J has ruled out the use of GH discussion, but we might want to consider them?

VladimirAlexiev: how about github Discussions, which are kind of like Issues but may be better for well... discussions. https://docs.github.com/en/discussions. They have threading

TallTed: I really dislike them, they are more like StackOverflow Q&A ("best" answer is pushed up), so not really a threaded discussion.

pchampin: I also dislike Discussions. However, we've had in some WGs "perma-issues" (a special label) for issues that are really prolonged discussions

pchampin: we need a resolution on the PR process (how much leeway we give to editors), so that we can move forward

<TallTed> a draft PROPOSAL (either as an emote or noted as DRAFT PROPOSAL) would help toward that desired RESOLUTION

<gkellogg_> w3c/rdf-concepts#18

gkellogg: w3c/rdf-concepts#18 is an example of a controversial issue, for which if we give editors more leeway, someone later may be unhappy about it.

<pfps> pfps: editors should feel free to do make changes that the working group has directed

ora: we need to find a balance

pfps: editors should be able to request changes to PRs that they believe have been decided/directed by the group

<pfps> the direction that I remember was to update documents to the current standard and something about fixing errata but the charter says editorial errata

ktk: in some cases we need to take some very old documents and bring them up to date. Can you give examples of editor changes that would contravene the Charter?

pfps: the Charter says we can fix Editorial errata, but no other kinds of errata

afs: one person's substative erratum may be another person's Editorial erratum. A recent example was an erratum in SPARQL that's been standing for ages, and every implementor have read the erratum, and fixed their implementation. We should feel free to fix this erratum

<TallTed> +1 neutral language is important in `issue notes` and the like (and we're getting better at this)

<pfps> pfps: yes, it can be hard to decide on the boundary between editorial and other errata

gkellogg: another similar example is an erratum in c14n. Another is in JSON results format.

gkellogg: a counter-example is Language Direction, which has major implications across the stack, and we can't just add it was part of this WG

afs: because people will work in the WG at different days of the week (eg my Wednesdays are devoted to fixing Dependabot warnings), we'll need a cycle of a complete week

TallTed: for trivial stuff like fixing a typo, we can use a very short cycle (fix it as part of the same PR), but for bigger changes (eg multi-line changes) we may need to wayt the whole weekly cycle. Let's use best effort and best judgement.

pchampin: I feel we're getting to a sort of agreement. We have a bunch of PRs, some are lacking initial direction. Let's go through the PRs, and editors add labels controversial/noncontroversial (or editorial/substantive, or needsFormalApproval), so we can merge the simple ones

<afs> Simple step - try to react in a "few days" ... which can include "I will provide a response this week".

<gkellogg_> I can't say that any open PRs I'm responsible for are purely "editorial".

<TallTed> commenting "this will be merged YYYYMMDD, if no one raises concerns before then" is also a fine step to take

<gkellogg_> Some changes are normative, others informative.

Editors will label PRs for next week's meeting, the controversial ones we can discuss, everything else can just be merged.

ora: label some PRs so we can play with the GH Project Board and see how we can manage the PRs