SocialCG/2018-09-12/minutes

<cwebber2> ===== MEETING LOGGING STARTS =====
<cwebber2> present+
<tantek> the whole practice of creating forks of vocabs in "RDF space" that go stale is a massive anti-pattern IMO
<aaronpk> Well I *was* gonna be on a flight just now but it is delayed so I can try to dial in
<aaronpk> No promises on airport Wi-Fi tho
<tantek> (kind of a problem with SemWeb approaches in general, but that's a larger / harder topic beyond the context of this telcon)
<eprodrom> present+
<puckipedia> present+
<cwebber2> chair: cwebber2
<tantek> will try to join by mumble by ~08:30 PDT
<cwebber2> scribe: cwebber2
<eprodrom> scribenick: eprodrom
<eprodrom> scribe: eprodrom
<cwebber2> https://www.w3.org/wiki/SocialCG/2018-09-12
<cwebber2> eprodrom: re: scheduling CG telecon meetings
<cwebber2> eprodrom: coming off of summer, we've had skipped meetings over last couple weeks and I'd like to get us to a point where we have a good process for meetings
<cwebber2> eprodrom: I understand we're coming out of the summer period, but seems like a good time to talk about process going forward
<cwebber2> cwebber2: should we be making changes to the meeting patterns?
<cwebber2> eprodrom: I think if we're on biweekly meetings that's fine, but it seems to be a lot, but maybe there would be more energy behind monthly meetings
<cwebber2> eprodrom: the other question is about chairing meetings, it may be useful for you and aaron to have a clear agreement on who's chairing when
<cwebber2> cwebber2: I'm open to switching off co-chairing, and I'm open to moving to monthly meetings
<cwebber2> puckipedia: I think that's good, also currently there doesn't seem to be as much to be things happening specifically with the SocialCG
<cwebber2> eprodrom: I would agree with that, I'll be as honest as I can be, I think we've gotten jammed up with AS2 issues, and I think Chris agrees here
<cwebber2> eprodrom: hopefully if we can clear up that blockage with this meeting we can start stuff moving forward
<eprodrom> cwebber2: Agree that vocabulary discussion has dragged, will be good to close it up
<eprodrom> cwebber2: pulling in more implementers would be great
<eprodrom> cwebber2: triaging and resolving AP issues will help also
<cwebber2> eprodrom: there's also a lot of open AS2 issues we should triage, it's cool we're getting th ekind of review necessary to do that and next step is to knock them down
* tantek has quit (Ping timeout: 180 seconds)
<cwebber2> eprodrom: I think we have good ideas on how to deal with that now
<cwebber2> eprodrom: in terms of meeting, do we want to switch to a monthly meeting, say the 2nd weds of the month and try it out for now?
<eprodrom> cwebber2: that gets a +1 from me
<cwebber2> aaronpk, ^^^
<puckipedia> +1 from me as well
<aaronpk> +1
<cwebber2> eprodrom: I'll make a formal proposal
<eprodrom> PROPOSAL: reschedule teleconferences to monthly meeting on the 2nd Wednesday of the month
<cwebber2> +1
<puckipedia> +1
<eprodrom> +1
<eprodrom> RESOLVED: reschedule teleconferences to monthly meeting on the 2nd Wednesday of the month
<cwebber2> eprodrom: I think this will make things higher stakes to where we'll take prioritization more seriously
<cwebber2> cwebber2: agreed
<cwebber2> cwebber2: and we can prioritize later
* vasilakisfil has quit ("Konversation terminated!")
* up201705417 (~includeals@public.cloak) has joined
<cwebber2> eprodrom: vcard and sec are examples of changes backed up because we don't know how to do this
* vt (~vt@public.cloak) has joined
* up201705417 has quit ("ZNC - http://znc.in")
<cwebber2> https://github.com/w3c/activitystreams/wiki/Extension-process
<cwebber2> present+ sandro
<cwebber2> present+ melody 
<cwebber2> eprodrom: I'll do a quick overview
<cwebber2> eprodrom: issues we're trying to address, biggest for me is the context property we have to put into the AS2 doc, can get really complicated really fast.  If you're trying to include many vocabularies and namespaces and etc, it gets messy
<cwebber2> eprodrom: ideally what we'd like to do is to say "use that single string for AS2" and I realize that's an ideal... but the more we approach to saying move widely used prefixes into the context itself, the easier it becomes for everyone to make good as2 documents, and it cuts down on accidents.  I think it's helpful, the more we can do to ?? our document, the easier it is for publishers to use AS2
<cwebber2> eprodrom: I originally made this doc with suggestions on how to add things to the AS2 namespace, but namespace is distinct from context document, and there was pushback on that
<cwebber2> eprodrom: so I changed it so that it's not about changing namespace, only about including terms in our context
<cwebber2> eprodrom: and it may be worthwhile to rename this page or call it something else, but for right now what it's doing is just talking about including external namespaces
<cwebber2> eprodrom: it talks about a number of different namespaces from external vocabularies to there are plenty of namespaces we want to leave out
<cwebber2> eprodrom: we drop a lot of implementation-specific documentation
<cwebber2> eprodrom: how we would use namespace, where we choose to incorporate
* ben_thatmust has quit (Client closed connection)
<cwebber2> eprodrom: where we've gotten caught up is I think two camps, one that says that ok if you're going to do new features for AS2 you should do it as an external namespace, another that says we should do it in an internal namespace
* ben_thatmustbeme (~quassel@public.cloak) has joined
<cwebber2> eprodrom: it's interesting but we don't have consensus and we're not bringing in any of these external namespaces
<cwebber2> eprodrom: I'd take the security namespace as a good example, it's widely used for AP but we all have to find it and include it and etc... would be very nice for it to just be included in the AS2 context document.  Can we agree on this mechanism for including external namespaces and have the argument about whether to use external namespaces or augment as2 namespaces as a separate discussion?
<cwebber2> sandro: can we go for a slightly more... not siding on a mechanism but including a bunch of external namespaces or ???
<cwebber2> eprodrom: are you saying have votes on a per-namespace basis or all at once
<cwebber2> sandro: the harm is if we include something we want to take out again that woudl cause problems and if we can't agree on prefix that would also be a problem
<cwebber2> sandro: don't know if those are controvercial or at risk
<cwebber2> sandro: frankly I wasn't thinking about that as the issue
<cwebber2> puckipedia: we have two things, actual extensions and things where we have eg the sec: namespace which isn't an extension as itself, it doesn't add any functionality to AP, just using the namespace as a way to basically create an extension with existing namespaces
<cwebber2> puckipedia: I think that's what kind of sandro means?
<cwebber2> sandro: I don't know what the sec namespace is, can someone explain?
* vasilakisfil (~vasilakisfil@public.cloak) has joined
<cwebber2> eprodrom: I'd like to get this to a vote, do we do it or not
<cwebber2> sandro: you didn't say anything about my proposal
<cwebber2> eprodrom: my response to that is I've been working on this extension process for months instead of skipping over it
<cwebber2> +1 from me
<cwebber2> eprodrom: I'd like to get this off the agenda, if we get to the point where we don't agree, but I'd like to close that up
<cwebber2> eprodrom: I'm honestly really tired of it
<cwebber2> cwebber2: it soudns like what evan is proposing is the process
<cwebber2> eprodrom: that's it
<cwebber2> sandro: this is about the context and not the extension process?
<cwebber2> eprodrom: that's true
<cwebber2> sandro: can you read the proposal?
<eprodrom> PROPOSAL: Accept https://github.com/w3c/activitystreams/wiki/Extension-process as extension process for AS2
<eprodrom> -1
<cwebber2> eprodrom: it seems we don't have consensus on it, so I think we just move on
<cwebber2> sandro: -1
<eprodrom> Rounding down!
<cwebber2> +1
* bengo (~bengo@public.cloak) has joined
<bengo> +1
<cwebber2> eprodrom: why don't we take this as closed, if we have need for guidelines for an extension process, otherwise we don't have a process for extensions to AS2
<cwebber2> eprodrom: maybe we just do it ad-hoc as needed
<cwebber2> eprodrom: we do have a couple of issues open that might help guide discussion
<puckipedia> -1 for now, we should most definitely figure out how to do this and maybe just try it out first, before having a proper process
<bengo> I don't think you can hear me. Sandro, do you have an issue filed?
<bengo> about your concerns?
<puckipedia> bengo: noone can hear you
<puckipedia> you're not talking at all
<cwebber2> bengo, yeah I can't hear you
<cwebber2> bengo: it sounded like evan voted -1 for consensus reasons rather than the issue itself
<cwebber2> bengo: maybe there's a path forward
<cwebber2> bengo: maybe further discussion on github issues
<eprodrom> q+
<cwebber2> bengo: this happens to all humans, but there's room for that passing, maybe evan will only vote -1 if there's not full consensus
<puckipedia> q+
<bengo> sandro btw I am soooo sympathetic to the fact you didn't see it till later. <3
<cwebber2> sandro: I think in my posting last night, I apologize for not noticing the issue until late last night... I do care about this community, I do care about namespaces... I wrote about the extension process for the namespace, not sure what else to say than I said.  I'm 0 (or -0?) on the context thing
<bengo> k
<cwebber2> ack eprodrom 
<cwebber2> eprodrom: so I wonder if there's any value in... since there's two other items on the agenda... it feels like we have not moved this proposal forward and it's not closed.  We've literally talkeda bout this at every meeting since may.  If we were ready to go we would but we're not.  Maybe we approve moving a couple of namespaces into the context, high value ones, and we develop a process through experience rather than prescriptive process
<cwebber2> sandro: +1
<cwebber2> ack puckipedia 
<cwebber2> puckipedia: so my opinion, we're trying to make a process for something that hasn't yet occurred at all except for possibly... we don't have any formal proposals for extensions yet, and we don't have any... we could go with experience with adding extensions and how people hadnle that
<cwebber2> https://github.com/w3c/activitystreams/issues/459
<Loqi_> [evanp] #459 Add vcard to @context
<cwebber2> https://github.com/w3c/activitystreams/issues/477
<Loqi_> [evanp] #477 Add the Web security namespace to @context
<cwebber2> eprodrom: we have two proposals above
<eprodrom> https://www.w3.org/TR/activitystreams-core/#actors
<cwebber2> s/eprodrom: we have/cwebber2: we have
<cwebber2> eprodrom: wish I had a chance to get multiple examples together
<cwebber2> eprodrom: vcard is SHOULD in AS2, if that's the case it seems like a simple... adding the namespace ot the context document is low-impact, the only downside would be if for some reason someone is using vcard for something else that it would interfere or be confusing otherwise this seems like a simple addition for AS2
* tantek (~tantek@public.cloak) has joined
<bengo> yes, propose so I can +1
<tantek> present+
* tantek muted
* tantek checks logs
<eprodrom> PROPOSED: Accept https://github.com/w3c/activitystreams/commit/94a2dfad623a663dd206f4de2505c1c75c54f84e to close issue #459
<cwebber2> eprodrom: clarification, this is just about adding vcard: shortname
<cwebber2> +1
* sandro_ (~sandrohawkeorg@public.cloak) has joined
<eprodrom> +1
<melody> +1
<bengo> +1
<puckipedia> +1
* tantek will defer to rest of CG on this issue
<puckipedia> https://github.com/w3c/activitystreams/pull/491
<Loqi_> [evanp] #491 Add vcard: prefix to context document; closes #459
<puckipedia> <eprodrom> PROPOSED: Accept https://github.com/w3c/activitystreams/commit/94a2dfad623a663dd206f4de2505c1c75c54f84e to close issue #459
* tantek has changed the topic to: next telcon: https://www.w3.org/wiki/SocialCG/2018-09-12. Logs: https://chat.indieweb.org/social/
<sandro_> +1
<bengo> https://github.com/w3c/activitystreams/pull/491
<Loqi_> [evanp] #491 Add vcard: prefix to context document; closes #459
<bengo> thanks puck
<bengo> :P
* tantek sees a lot of whitespace changes 😂
<eprodrom> RESOLVED: Accept https://github.com/w3c/activitystreams/commit/94a2dfad623a663dd206f4de2505c1c75c54f84e to close issue #459
<eprodrom> tantek: I know, I just noticed that myself
<bengo> https://github.com/w3c/activitystreams/pull/490 for 'sec:'
<Loqi_> [evanp] #490 Issue 477
<puckipedia> +q
<cwebber2> puckipedia: one issue I have with PRs currently is that it isn't actually useful for anything currently, becasue all current uses of this namespace have been by importing the entire context, which for example is use used for publicKeyPem etc
<tantek> hmm I thought vCard already had a KEY property
<bengo> q+
<cwebber2> puckipedia: if we were to embed the context we should also at least unpack the parameters
<eprodrom> q+
<sandro_> losing puck audio
<cwebber2> puckipedia: for compatibility with current servers
<cwebber2> bengo: I think that's a step further, the way the PR is currently done, it wouldn't make existing implementations break, they can still use more namespaces in their context, so wouldn't be backwards incompatible?
<cwebber2> puckipedia: it wouldn't be incompatible, but it wouldn't make sense to include it and have nobody use it
<bengo> q?
* tantek agrees with puckipedia
<cwebber2> q+
<tantek> feel premature
<cwebber2> eprodrom: question would be... if this is accepted, this would be a simple context, and then you could use the sec: terms with prefixes.  So sec:publicKeyPem etc and that would just... that saves the step of having to add it for the context
<bengo> We can always do what puck is proposing later... but there isn't a PR for that now. And also Occam's razor applies. "It's vain to do with more what can be done with less" for adding all thos ealiases. I'm in favor of PR as is
<cwebber2> eprodrom: I realize that it does not also mean adding the aliases, I wonder if it's valuable to us to separate those two changes, first add the namespace then add the aliases, or must we do both simultaneously
<cwebber2> puckipedia: I would like to point out there is a small issue with doing this and it is id values, eg sec:owner is id, so if you put a string in it it becomes a url
<cwebber2> puckipedia: if you just use the prefix it doesn't do this
<cwebber2> {"sec:publicKeyPem": "..."}
<cwebber2> {"publicKeyPem": {"@type": "@id", "@id": "..."}}
<puckipedia> {"sec:owner": "https://puckipedia.com/"} is either {"@value": "https://puckipedia.com/"} or an object {"id": "https://puckipedia.com/", "preferredUsername": "puckipedia"}
<Loqi_> HACKER TEEN PUCKIPEDIA 👩‍💻
<eprodrom> q+
<cwebber2> eprodrom: we're coming up on 12:00, unfortunately I can't keep going, can we vote this up or down or defer?
<tantek> my vote is defer as well
<tantek> in particular, no evidence is documented in the issue for "security namespace as a good example, it's widely used for AP"
<tantek> cwebber2: can you add such examples to https://github.com/w3c/activitystreams/issues/477 ?
<Loqi_> [evanp] #477 Add the Web security namespace to @context
<tantek> we should back up assertions like "widely used" with citations in GitHub
<tantek> thanks
<eprodrom> Thanks all
<cwebber2> eprodrom: we're running out of time, should we defer this?
<cwebber2> cwebber2: yes
<cwebber2> cwebber2: see you next month, oct 10th
<cwebber2> ===== MEETING LOGGING END