Re: User stories for Social API

Daniel,
I completely agree with just about everything you say below, except that I 
think that as we want to make fast  progress, some of the context work 
needs to be done in parallel rather than as a prerequisite. We can always 
re-evaluate and update in light of context clarification later.

I had started some context documents with this in mind under Contexts here 
(I'm not sure what way the access works) ->
https://www.w3.org/wiki/Socialwg/Social_API/User_stories#Proposed_contexts
These are however particular to the situations I'm familiar with rather 
than definitive for now.

One other point I'd like to make is that in terms of ownership and 
federation, it's not just a question of P2P, Silos and a mix,. For any 
given 'Object' (say a sales forecast), there may be multiple associated 
Social Features, each provided by different applications at different 
locations, that require appropriate aggregation, for example -
Sales Report - located at AllSales.com
Owner details - P2P details managed by mypersonalserver.ie
Access control provided by - GroupsRUs.com
Commenting service and Liking provided by - TalkAboutMyStuff.com
Activity Stream - needs to aggregate all details in multiple locations -
On my profile at mypersonalserver.com
At AllSales,com when viewing the report
. . . and pmore
 - an effective API will be sufficient to allow appropriate interaction at 
each point to each service.

Rgds.
-Bill.

_________________________________________
Bill Looby
Software Architect, Dublin Software Lab, IBM Ireland
IBM UK & Ireland Technical Staff Member
Phone (Internal) : 515129
Phone (External) : +353 1 8155129
_________________________________________
IBM Ireland Product Distribution Limited registered in Ireland with number 
92815.  Registered office: IBM House, Shelbourne Road, Ballsbridge, Dublin 
4.



From:   Daniel Harris <daniel@kendra.org.uk>
To:     public-social-interest@w3.org
Date:   10/02/2015 11:08
Subject:        Re: User stories for Social API



Dear All,

I'm not in the SocialWG so I'll make my comments here regarding the 
discussion that took place at:
http://lists.w3.org/Archives/Public/public-socialweb/2015Feb/thread.html#msg18


As I see it... At one end we have social silos ? all people pointing their 
social clients at the same organisation/server. At the other end we have 
pure distributed systems (P2P) where people have their clients connecting 
directly to other clients belonging to other people ? note that there are 
no social silos or social organisations or even social servers involved ? 
a little bit like real life. Somewhere in between these polls is a 
federated social system where social organisations interconnect their 
social servers enabling people to interconnect, even though they may not 
be using the same social server. However, surely the protocol we create 
needs to work with all these scenarios? From the outset our terminology 
and philosophy must be such that this is one system and one protocol even 
though it may comprise of many different parts and scenarios and get built 
in stages.

For example, I want to be able to friend Pavlik directly ? client to 
client ? device to device. Now some may scoff at building in pure P2P but 
it's already out there, so shouldn't we be modelling and catering for this 
scenario too? If you do want to get into architecture then pure P2P could 
be just be another instance of a federated system where my device has both 
a web client (for the UI) and web server builtin and each device talks to 
each other device server to server.

The issue about the users being in single organisation or from different 
organisations is a misnomer. In my beautiful world there are no 
organisations per se. We are all individuals in permanent freelance. We 
interact with each other on projects (big and small ? long and short). We 
create products/IPR with others on an ongoing/dynamic basis. Take a look 
at value networks ( http://en.wikipedia.org/wiki/Value_network ). Is it 
really going to work (be successful) if we build a single server 
implementation of the Social API and don't take into account all the 
issues associated with a multi server (a pure P2P) scenario.

It just feel like we should be doing some high level modelling before we 
get down to the nitty gritty ? sorry if this has already been done, can 
someone point me to it? And that means being totally abstracted away from 
any technological constraints. Without this 'context' document to work 
from, I can see how easy it is for interactions/misunderstandings, such as 
what happened on Feb 4th on the WG list, to take place.

By the way ? and importantly ? it doesn't mean we have to implement 
everything in a 'blue sky'/'context' document in phase one of the 
protocol. But what it does mean is that we are, at least, aware of the 
bigger picture.

This process needs to be staged and I'm concerned that there doesn't seem 
to be clear stages stated at the outset. Or, if there are clear stages 
stated, then they don't seem to be being followed. Stage one should just 
be list user stories in order of input ? with no ranking or categorisation 
needed. Each author should be attached to each user story. Then, once this 
has been done, all the authors should have a call and talk (yes, I mean 
*talk*) through where user stories: can be combined (in which case both 
authors can be listed on one story (if needs be)); can be modified to 
better suit the needs of the social web; can be categorised into areas of 
interest/technology.

I really don't understand why this is being rushed through in a week after 
years of work in various groups. Seems like a recipe to start a fire and 
I'd like to suggest everyone does everything they can to cool the 
situation off and take stock.

Just my 140 quid's worth!

Cheers Daniel