- DRAFT -

Social Web Working Group Teleconference

17 Feb 2015

Attendees

Present: eprodrom, elf-pavlik, +1.617.247.aaaa, dret, [IPcaller], aaronpk, benthatmustbeme, cwebber2, Sandro, rhiaro, hhalpin, tantek, Tsyesika, bblfish, +1.408.335.aabb, AdamB, dromasca
Regrets Chair: eprodrom
Scribe: cwebber2

eprodrom: so! the schedule we kinda laid out last week / a few weeks ago, we'd collect user stories, which we've done, close to 50 user stories
... some very close together, some may be hard to address thru an API
... nevertheless, have quite a few out there
... looks like for our next step is to decorate this list
... sandro has called it a survey result

I can't hear

scribe: our next step is to decorate the list with upvotes and downvotes
... +1 0 -1
... to each user story
... +1: yes, I need it, will implement, worth doing; -1: so far out of scope we shouldn't do it
... would love to do that with mediawiki-style comments

<eprodrom> ":+1 good idea. --Christopher Webber (talk) 18:58, 17 February 2015 (UTC)"

tantek: another legitimate use of -1 is to say "this doesn't belong in the first version of the social API, it's too edge case to be in the 0 edition social API. Might mean you're not against the use case, but you don't think it's necessary yet, or don't think it's in the same class of needs as the other user stories"
... if you do say -1 *please* provide reasons why.
... 0 is "I don't think it's important, but not opposed to inclusion"
... people don't really need to explain the 0
... 0 could be "yes I've looked at this, not really compelling, but I'm not opposed to having it drive requirements"
... or 0 could be "I think it's already covered, thus irrelevant"
... that way we can give people some guidance

eprodrom: I def see -1 as being pulling the emergency brake on something
... it will require some resolution if you use your -1
... so use sparingly / as needed
... not just because you don't care one way or the other

tantek: I have slight difference of opinion, people should be willing to use -1 to restrict requirements
... we want to ship soon, so smaller requirements means ship sooner

<elf-pavlik> tantek, how do you see 0 than?

tantek: rather than kitchen sink api
... so -1 can be "should I really use this"
... because with -1 I want to ship sooner than ship this

eprodrom: I feel a -1 is, if a proposal for this comes in, I won't accept it

can I toss in something?

<bill-looby> I think we need consistency

how about the -1 -0 0 +0 +1

<Zakim> elf-pavlik, you wanted to discuss -1 not in core, please implement as extension first

<bill-looby> can we make a call ?

<bblfish> it can be subjective to know what is easy or not to do

elf-pavlik: I'd like to follow up on focusing on the core, and say "this can be an extension"

<bblfish> for example some people may think that some user stories are difficult to do, because they don't know how to do it

<Loqi> Abasset made 1 edit to Socialwg/2015-03-17 https://www.w3.org/wiki/index.php?diff=81518&oldid=81517

elf-pavlik: because hopefully we can have independent implementations

eprodrom: we have no user story for any extension mechanism
... so not sure that's reasonable

<rhiaro> extensions would be a developer story?

elf-pavlik: thx

bblfish: we could have a merger between two stories

eprodrom: yes, but maybe would be good for that to happen before, I think we're at the point where we need to just select them

<tantek> https://www.w3.org/wiki/Socialwg/2015-02-17#Social_API

eprodrom: I'm not sure we're at a point today to do editorial mergers of sort

<bblfish> fine

<harry> and also note that if you are a +1 and plan to implement, please note your implementation commitment.

<elf-pavlik> cwebber2: number of groups used +1 / 0 / -1

-0 +0

<elf-pavlik> ... but also used +0 and -0

<harry> that proposal sounds reasonable.

<elf-pavlik> ... that could help to fill the space where eprodrom and tantek sound like disagreeing

+1 +0 0 -0 -1

<harry> +0 and -0 sounds good t ome.

<KevinMarks> if there's a difference of meaning, use a different term

<elf-pavlik> +1 +0 / -0

tantek: i think that captures some of that, w3c does this a lot to capture for or against

<bill-looby> FYI - There is an extension mechanism implied by Story "Integration : Bringing tools together" . . . depending on what you consider an extension

tantek: so +0 or -0 kind of shows I'm kind of for or against, but I'm okay with what happens
... the "can live with it" is an important opinion that should be captured in these polls, so thanks for bringing up these options

<elf-pavlik> cwebber2++

tantek: and if you really don't care, put a 0

<Loqi> cwebber2 has 10 karma

<tantek> that someone was me

eprodrom: so, next item is someone made notes for proposals that we stop editorial at midnight EST, and feedback starts after that

<tantek> sorry forgot to sign

eprodrom: yep, looks like tantek, ok

<eprodrom> PROPOSAL: editorial stops 18 Feb 2015 at 00:00 EST, survey runs exactly 1 week

<eprodrom> +1

+1

<Tsyesika> +1

<tantek> +1

<harry> +1

<benthatmustbeme> +1

<aaronpk> that means next week's call will be before voting ends

<AdamB> +1

<dret> +1

<bill-looby> +0 :-)

<elf-pavlik> +1

eprodrom: we got +1 on our +1 processes

<aaronpk> +1

eprodrom: ok, looks like consensus
... we'll mark that as resolved

yes, I forget how

<eprodrom> RESOLVED: editorial stops 18 Feb 2015 at 00:00 EST, survey runs exactly 1 week

<harry> PROPOSAL:

ok: )

<elf-pavlik> RESOLVED: editorial stops 18 Feb 2015 at 00:00 EST, survey runs exactly 1 week

eprodrom: ok, any other discussions on user stories?
... if not, I'd like to move on

tantek: I think this is left over from last week, was brought up but not discussed... many assumptions brought into the user stories
... I think it's fine to cite silos as examples of where we've experienced these user stories, but as far as assumptions in our group, we should assume every user in our user story could be on a different system

eprodrom: or same system

tantek: yes, same system is a degenerate case of that
... because I think bblfish brought that up in email
... that has been well documented for a while, but let's make it documented

eprodrom: should work independent of network topologies, whether on same/different servies
... servers

(what's a servie?)

<Zakim> elf-pavlik, you wanted to discuss groups

elf-pavlik: I'd like to clarify, we have different stories for groups
... I might have a group on my, someone else's server, etc
... w3c stories for example

tantek: I agree with that

eprodrom: do we need to call that out separately?
... or can we just leave that advice at that

<bblfish> "You should assume that all of these stories are independent of network topologies: the stories should work whether all the actors have accounts on a single server, on different servers, and independently of where the data is located."

elf-pavlik: no note is fine, just wanted to clarify on call

eprodrom: sounds good
... excellent

<bblfish> if groups are actors that follows

eprodrom: I think we can move on

<Loqi> Almereyda made 1 edit to Socialwg/Social API/User stories https://www.w3.org/wiki/index.php?diff=81519&oldid=81513

eprodrom: additional items agenda item
... which means we're at the end of our agenda
... anything else to discuss here?

<harry> We could discuss f2f

<scribe> ... new business, new updates?

Additional Agenda Items

dret: yes, since we have a bit of time left, in last maybe 2 weeks, what exactly does the current model of having structured activities mean
... if I had a like syntax, if the like actually is a respond
... is that an obligation for that system?
... if I ask for a respond activity, will that actually get delivered
... for use cases discussed, it seems like must me wondering, is this a weird little hobby of mine, or is it not well specified

<tantek> I think that's the difference between responses (includes all interactions, likes, replies, reposts), and replies (just comments)

dret: what does the activity structure mean if not that?
... looking for feedback

eprodrom: so harry is on the queue, so will ack, but I think it's an interesting question
... let me give a bit of experience from activitystreams 1.0, early versions had different verbs that were based on different products based on companies' products
... eg digg had a "dug" thing, like you "dug" a url, but that didn't mesh with like etc
... so early system was built to convey that if you don't understand a "dig", fall back to "like"
... I'm not sure if this was conscious consensus or general laziness on part of implementers
... but almost completely collapsed
... as soon as implementing AS 1.0
... if a like was not literally a like, like the full identifying URI for a like, was just ignored.

<KevinMarks> like vs favorite have different mapping - heart versus star too

eprodrom: and multiple verb system fell out of AS 1.0

dret: (?) yes that means that you have weak inference in the spec

who was that?

<dret> me

oh dret

<bill-looby> there also wasn't an explicit hierarchical association to the extent there is with a vocabulary iirc

eprodrom: not sure if you Should or Must process these as "treat a like as a response" or a "fwoop as a like" and it'll actually get implemented

<rhiaro> Quora and Reddit (I think) have upvote which is similar but not quite the same as like, or maybe how similar depends on who is using it and when/where

eprodrom: will get off my soapbox and ack harry

harry: basically the question is whether you should have some inference is should the implementations actually do so

<KevinMarks> how does +0 map to like? ;)

harry: does schema actually have a product in that space?

<eprodrom> B-)

<dret> we need it and do it.

harry: we need to distinguish between features cool
... how do we go down that path
... anything without real code and users will be removed from spect

spec

before last call

<dret> justcooked up our own way. which is unfortunate.

scribe: at yahoo we did that but had a difficult time gettinmg to scale
... if specs demand to do things implementers won't do

<Zakim> elf-pavlik, you wanted to discuss creating official issue for that

scribe: can't put it in the spec

what

elf-pavlik: create an issue on the tracker
... create user story

<harry> In particular, it would be great to know if Siemens has a product or even planned product/codebase in this space.

elf-pavlik: for custom word
... hesitation to not use a custom verb
... make it an issue to clarify how to handle custom verbs

<harry> In general, it's a super-cool featur

<Zakim> tantek, you wanted to note how in IndieWeb we've distinguished responses (includes all interactions, likes, replies, reposts), vs replies (just comments), likes, reposts

<harry> but we have to see if people actually do it, which is kind of common-sense.

tantek: there's tension between how to distinguish between special responses / all responses
... notion of class of types of posts all interacting/responding to another post
... apis want a way to query all those kinds of posts

<harry> Its possible developer community has moved on since AS1.0 and inference is not so painful/messy for developers.

tantek: have a discrete set of (??)

<elf-pavlik> https://github.com/openbadges/openbadges-specification/pull/22#issuecomment-73144928

tantek: like likes, reposts, etc
... comments
... which it makes sense to do a core thing for those
... that's our experience in the indiewebcamp community
... special handling for events, invitations
... invitations are another kind of response
... because you can post an invitation to invite a 3rd party
... will make sure user stories cover, or else I'll add it

dret: looking for what spec tells me to implement
... looks like spec doesn't requie I implement this
... apparently right now I have a choice
... if we do it like this it makes more sense...

tantek: as publisher of consumer?

<elf-pavlik> i'll raise it as issue, not sure about proces to officialy open it...

dret: it's someone looking at activitystream activity and looking at what it means

<bill-looby> also a federator

tantek: so a consumer

dret: yes, also a publisher, because I can't interpret it as a response unless I (??)

<elf-pavlik> w3c tracker issue!

tantek: second point I wanted to emphasize experience with ActivityStreams 1.0

<dret> tracker or github issue?

tantek: I remember specifying the special likes
... nobody cared to consume those in practice
... several anti-patterns
... there was a brand-centric, company-centric ego of "I have my special dig, or whuffie, and it's so special a snowflake it can't be a like"

<dret> people live their snowflakes!

tantek: but nobody cared about those beautiful unique snowflakes

<eprodrom> Google+'s first API version had a verb type for "plusOne"

<elf-pavlik> dret, i'll raise it in tracker and we can decide to open it later

tantek: so I will emphasize that in my votes
... and encourage others
... and if you haven't had experience with it
... ping eprodrom or etc

<elf-pavlik> dret, even better if you can create it since you explain it very well :)

tantek: it's counter-intuitive to the semantic web community which says extensibility is good, but my expereince is that extensibility is the opposite of interop
... it's stuff people publish but don't consume
... we should look at that as evidence to maybe even leave out extensibility in v1

<dret> we could at least tell people to label their snowflakes in interoperable ways. at the very least we should have a well-defined story. we don"t have one right now.

tantek: that experience is important, i know many are pro-extensibility, but wanted to put that out there

bill-looby: one thing I experienced
... I agree that events and event types require heierarchy
... if it has an explicit heirarchy there's an explicit requirement on processors to add such streams
... do we need to review what we add there

eprodrom: I think what you're saying is we need to say "if we can't process this heirarchy, remove that hierarchy"

<dret> +1

bill-looby: also seems implicit in the other decisions we've also nearly made

<tantek> +1 on flatten

<tantek> most use of hierarchy is useless in practice

eprodrom: why don't we open this up... dret can you open this as an issue in AS 2.0

<elf-pavlik> tracker

dret: on tracker or github?

<eprodrom> jasnell

eprodrom: either

bill-looby: other option is to be explicit about early terms

<elf-pavlik> http://www.w3.org/Social/track/products/1

bill-looby: similar to early AS 1.0 stuff

harry: that's exactly how we do it now, we use AS 1.0 verb
... we then in this case have an extension field in there which lets anyone understand our specific way of handling this

<KevinMarks> prior art: http://designingsocialinterfaces.com/patterns/Main_Page

harry: so if you really care about htat not just being a dig
... so you can understand it's a like

<rhiaro> +1 for reliable fallbacks

harry: so a cheapo understanding of heirarchy
... that's what we currently use
... now AS2 does something similar
... that's basically what we're doing now
... trying to figure out what AS2 can do
... am confused when I read the spec

was that harry or dret ?

sorry if I set the wrong one

<dret> me

harry: a bit more formally, we have different ways to process, agree it would be great to do, but also understand it's hard from previous implementers

<tantek> In experience, what implementers/customer,-�sk for* and what they *implement* are two very different things

harry: we should work with working group to put it in the spec put it in as feature, feature at risk, and if not implementing it by last call, remove or change
... there's a tradition in w3c to wait till implement
... we're hoping to enter last call to see about implementation

<elf-pavlik> +1 feature at risk

eprodrom: is there a way we can split the baby on this one
... maybe suggest to publishers "you can do whatever extension you want, but best practice is to use a vocabulary verb because downstream is more likely to see it"

<dret> that's my pet project: the processing model section

eprodrom: to consumer: you can concentrate on a particular activity type, but look at heirarchy

<Zakim> elf-pavlik, you wanted to discuss documenting previous experience

eprodrom: so everyone should do the right thing, but be aware not everyone might

elf-pavlik: one reason I suggested with official document was to reference to links to impelmeentations, proposals, etc
... shouldn't be doing voting on this in this call
... chew on it, document past experience

<dret> +1

elf-pavlik: maybe do resolution at face to face or in near future

+1 btw

<eprodrom> I like this

<rhiaro> +1

<Zakim> tantek, you wanted to add to Harry's encouragement to implement early. when voting on user-stories, if you +1 as an implementer, say whether you *will* implement it, or *already

eprodrom: ok and, tantek ?

tantek: wanted to emphasize harry's message of implement early, implement often
... many of us have implement these already

that's something we can capture

scribe: that's something we can capture
... as part of your +1
... if you already have implemented, please indicate that

<elf-pavlik> https://www.w3.org/wiki/Socialwg/Social_API/User_stories/Implementations

scribe: even if it only works on a specific network topology, please mention
... and if you did do it cite a URL that shows you did it
... and that's one of the strongest votes you can make for a user story
... so capture that immediately

eprodrom: excellent, if we're done with that, we're closing in on the hour

<dret> thanks everybody! bye!

eprodrom: would love to offer everyone their last 5 minutes back
... talk to you next week

<elf-pavlik> thanks everyone!

<elf-pavlik> eprodrom++

eprodrom: please give feedback on user stories

<elf-pavlik> cwebber2++

<Loqi> eprodrom has 4 karma

<Loqi> cwebber2 has 11 karma

<tantek> cweb ++ thanks for scribing!

tantek: np :)

<tantek> cwebber2++ thanks for scribing :)

<Loqi> cwebber2 has 12 karma

<harry> trackbot, end meeting

<eprodrom> trackbot, end meeting

Summary of Action Items

[End of minutes]

Socialwg/2015-02-17-minutes

- DRAFT -

Social Web Working Group Teleconference

17 Feb 2015

Attendees

Contents

Approval of Minutes of 10 February 2015 Teleconf

Next week Teleconf

Tracking of Actions and Issues

Social API

Additional Agenda Items

Summary of Action Items