Meeting minutes
issue and PR triage
pchampin: I marked some issues and PR as "needs discussion" because I think they are ready for quick decision
Pull Request 692 use all common files by reference (to json-ld-wg) (by pchampin) [needs discussion]
pchampin: this is to get rid of duplicated common files that we need to keep in sync
bigbluehat: seems like a good move; let's merge it, it won't make things worse
https://github.com/w3c/json-ld-api/pull/691
pchampin: anatoly-scherbakov and niklasl both made PRs on syntax and API to remove ins/del tags
… this one is the missing link
… it removes the blocks that were describing the candidate-level changes
… so it moves that description into the changelog
… oh...well...looks like I broke something by editing the `common/` files...which we just changed in the previous PR
Pull Request 675 Add in memoriam text for @gkellogg. (by BigBlueHat) [needs discussion]
pchampin: this one has a lot of approval; I don't know why it was not already merge
bigbluehat: me neither; let's merge it
Pull Request 669 Improve test fromRdf#t0027. (by davidlehn) [needs discussion]
bigbluehat: approved by two people
anatoly-scherbakov: could we setup an automerge after a given number of approval?
bigbluehat: not sure about that; there are different kinds of approval
pchampin: the reason I put the "needs discussion" label is that it was approved a long time ago, no reason to let it linger
… whether or not my suggested change is included
anatoly-scherbakov: the reason I suggest auto-merge is that the probability to merge is high if several people approve and no one objects
… also, reverting a PR is cheap; we could be faster with auto-merge and rare revert, than we are today
bigbluehat: a reason we are slow is that PRs have been stacking up for a long time, which also takes us time to "restore context"
<Zakim> TallTed, you wanted to speak antiautomerge
TallTed: I'm usually on the side of letting automation help the human
… however, auto-merge because of 2 approvals does not lead to the desired effect, in my experience
… it is too easy for people to auto-approve; and reverting can also be a nightmare
pchampin: +1 to what TallTed and bigbluehat have said
… there are some things about the current situation which makes things slow
… but I think the discussions are helpful, especially as we get back into doing the work in this phase
… I was happy to have my PRs discussed
… but in interest of time, we could also give more leeway to editors to merge things more quickly
… likely via some agreed upon rules from the group
… something the Linked Web Storage group does is convert comments into issues
… which prevents blocking PRs on commentary
… so they push comments into issues to keep things in the queue
bigbluehat: I would like to see us do this more often
<TallTed> converting PR comments to new issues is a GREAT feature I've been using for some months if not years
dlehn: we just merged a comment in an n-quads file, which previously had no comment.
… Is that a problem?
… I'm not sure the custom n-quads parser we are using supports them...
bigbluehat: I think we will figure out :)
… please, if it does break, either fix it or let us know
Issue 47 Add discussion of processing models and their uses. (by wes-smith) [editorial] [needs discussion]
bigbluehat: I think we can remove the "needs discussion" from this one; looks like we did discuss it
… let's see if We resurfaces it
Issue 436 URI in Profile triggers CORS Unsafe Request Header Byte rule (by azaroth42) [spec:w3c] [needs discussion] [tag-needs-resolution]
bigbluehat: I think the conclusions we raised earlier about that one was to avoid using URLs in profiles
dlehn: I need to wrap my head around this issue, but my recollection is that it was a user issue, not an error
… things are behaving as expected
… it leads to a preflight CORS request, which the server needs to handle
pchampin: I agree with dlehn that, in an ideal world where servers "do the right thing", this should not be an issue
… but we don't live in an ideal world
<pchampin> +1 to address this in the best practices document
bigbluehat: what we can do is address it in the best practices document
… it will probably not impact most JSON-LD users
… and we can come back to this if it turns out we need to fix it in syntax or api
niklasl: I agree; Rob wrote in a comment that he agrees we can close it
pchampin: a little off topic, but regarding n-quads parsers
… n-quads 1.2 adds directives, so it's now more complex than one quad per line
… so having a more capable parser seems prudent.
Issue 457 is there a way to use `@container:@list` with custom props? (by VladimirAlexiev) [needs discussion] [defer-future-version]
bigbluehat: this one is labelled as "Future Version", but we are now in the future
… we probably need more granular labels (1.2, 1.3)
… do we want to use milestones?
niklasl: I kind of like milestones
bigbluehat: me too, but I'm not sure how it is going to play in the project
… looks like projects support them
TallTed: I'm not against that, but the downside is that we would need to apply milestones to *everything* we have
… currently we are used to using labels
pchampin: I slightly disagree with TallTed, just because we use milestones does not mean that we can't leave them unspecified on some issues/PRs
[discussion on whether we want to set due dates on milestones]
bigbluehat: back to this issue, that sounds like a big change
anatoly-scherbakov: is this a use-case for JSON-LD profiles
… can a profile deviate from the spec?
bigbluehat: this does not affect the syntax, only the RDF output
niklasl: that's also how I read it
… I don't think it would be an easy thing to introduce
… I would probably be against considering this for 1.2 or 1.3
<pchampin> +1, it also seems too big to me
bigbluehat: I would suggest push the pain to another level
… they would need to deal with that if they got an rdf:List from Turtle, for example