Re: discussion of some -1s by Ben Roberts

Hi Henry,

I'll try to explain these one by one, I didn't want to flood the page with
too much discussion of every one.  I figured it was more just for voting.
Maybe we'll see me get over-ruled by plenty of +1's.
I also fixed in on what was said about wanting to complete a first revision
of the API quicker and to cut the excess.  Lots of the stories I down-voted
was not because they aren't useful but they would add a lot of complexity
that can be looked at after we get something working initially.


On Thu, Feb 19, 2015 at 10:23 AM, henry.story@bblfish.net <
henry.story@bblfish.net> wrote:

> I just picked up a lot of -1 by Ben Roberts, which are not very well
> defeneded I think.
> So it's easier to have the discussion on the mailing list when these
> things turn up.
>
>
> Product issue reports
> =====================
>
>         • Each product a company makes has its own URL which can be read
> off the product. From that URL the user can find the history of the
> product, from creation to the present.
>         • Only the current buyer and the company has access to that page
>         • A user finds a problem with his product and goes to his Product
> page. There he can open a new bug report.
>         • He can upload pictures of the problem, descriptions, and discuss
> with the Technical Support Staff
>         • The Technical Support Staff or the User can add new people to
> the discussion, eg. technical experts, parts manufacturers, sales people,
> legal, etc...
>         • New members can then contribute to the discussion bringing their
> expertise to bear.
> From User:Bblfish
> -1. Doesn't really seem like a social network feature to me. Perhaps a
> company would have a social account that could handle, but getting to
> product level gets too specific. — Ben Roberts (talk) 02:00, 19 February
> 2015 (UTC)
>
> -----
>
> Well it is social because people communicate on a topic. Instead of
> discussing a picture on a wall, you can create
> an issue on a product. Additionally you can enlarge the group of people
> who can see the issue, to include more people in the discussion.
>
> Does that help?
>
>
I voted this one a -1 because I don't see creating URLs for physical items
or managing what users have purchased what items as being involved in the
social API.  Anyone hosting their own service could certainly go ahead and
add that, and this would be a great user story for a developer of that
system, but I don't think its a good User Story for our purposes.   I am
trying to keep anything that is a custom solution separate from the general
social API.



> Using a Smart Client
> ====================
>
>         • Jillian downloads iFoaf to her smart phone, starts the program,
> enters her identity, and authenticates herself to her home server. The
> client gets her profile data and initiates the application with data taken
> from her Social Web Server and her client
>         • The Application asks Jillian if she wishes to add people found
> in the smart phone address book to one of her already published groups or a
> new one. Denise publishes them to a new group, to categorise later
>         • As Jillian is an EFF advocate she travels a lot, and so do many
> of the people she is in contact with. So she often does not know what time
> it is for the person she wants to call. But she has convinced 50% of her
> friends to have their own home servers with Social Web compliant APIs.
>         • Jillian uses iFoaf to call people.
>                 • If the person she wishes to call publishes her time zone
> info, Jillian can know if it is advisable to call them.
>                 • Jillian always gets the latest phone number people are
> using, and never has out of date phone numbers
>         • As Jillian travels iFoaf can let her know what friends of hers
> happen to be in the same town. She can quickly message them to say hello.
>         • Any messages Jillian sends travels over an encrypted channel
> directly to her friends computer, so Jillian knows that her messages are
> never read by anyone else than their intended recipients.
>         • Jillian's server also allows traffic over Tor, to allow her to
> communicate with people in politically sensitive positions.
> From User:Bblfish.
>
> -1. Seems more Use case for the app, not the API. — Ben Roberts (talk)
> 02:00, 19 February 2015 (UTC)
>
> -------
>
> I don't see how you can distinguish in a user story between what the
> interface gives you and what API that it communicates over gives you.
> Furthermore this used to be part of the developer section, which was
> removed, so yes
> that is why it is developer focused. Not sure why that deserves a -1
> though.
>

There is a LOT going on in this story, not that its a bad thing.  But upon
reading this over again, you are right, i'm not sure it deserves a -1.  I
was trying to lean more toward excluding excess than including too much.
Getting a user's time zone and phone number is important to include, but
that is inferred any time you get a user's profile. What you do with it
after that is more of the app's territory.  That's what dissuaded me from
it.



>
> Follow a neighbourhood group
> ============================
>
>         • Joe, Jane and their children move into a new house and Joe
> brings his personal server to the new house, and switches it on by plugging
> it into the wall and connecting it to the fibre optic cable.
>         • The server sets up the DNS so that all Joe's previous contents
> are now available at the same URLs as in his previous house, meaning that
> his social network is back online.
>         • One of Jane's friends notices their new geo-location over the
> web and introduces them to Jack, one of Joe's neighbours.
>         • Jack and Joe accept the friend of a friend (foaf) invitation and
> Jack comes by the next day to say hello.
>         • Jack adds the family to the neighbourhood group ( stored
> somewhere ), and sends Joe a hello message welcoming him to the group.
>         • Joe receives the hello message the next day, visits the group,
> and leaves an introductory message for his neighbours.
>         • On that group Jane discovers that there is a collective barbecue
> the next weekend and leaves time in the calendar for the family to go there
> with the family.
>         • After the barbecue Joe connects up directly with some of the
> neighbours he ended up in longer conversations with.
>         • These closer friend relations gives those neighbours more access
> to each others plans, allowing them for example to organise taking kids to
> school on a rotary basis.
> From: User:Bblfish
> -0. Seems like mostly a dupe of #Groups, with lots of plumbing added.
> --Evan Prodromou (talk) 15:31, 18 February 2015 (UTC)
> -1. Too complex — Ben Roberts (talk) 02:00, 19 February 2015 (UTC)
>
> So it's either too complex, or a duplication with a bit of plumbing of
> #Groups.
> Why is it too complex?
>
> It seems that at the very least it is stretching the imagination a bit,
> since what seems like a normal group
> participation story now seems to be something super complex to do :-)
>
>
Too complex of a story.  There is a lot going on here, identifying nearby
users by geo-location, adding others to a group without choice (Jack adds
the family to the neighborhood group).  I feel like these are just more
complex versions of #Groups.  So yes, this user story is a duplicate and
made too complex.


> Assigning roles during meeting
> ==============================
>
>         • Telecon starts
>         • Ann assigns herself as a chair
>         • Lloyd assigns himelf as a scribe
> see also: https://www.w3.org/wiki/Template:Agenda-preamble
> From: elf Pavlik
> -1. I don't think we need to manage teleconferences with this API. --Evan
> Prodromou (talk) 15:51, 18 February 2015 (UTC)
> -1. Perhaps later, but not for the first version of the API. — Ben Roberts
> (talk) 05:00, 19 February 2015 (UTC)
>
> I think what we need to do is distinguish between the API and the
> vocabulary here. IF the API is general enough
> it should be easy to do the above once one has the correct vocabulary.
> Now in games on social networks, assigning oneself to roles is quite
> common. So it seems that this is just doing something like that, which is
> not very complicated.
>

Looking this over, this seems like something that would actually be
perfectly reasonable in an app, but I don't think it makes sense to have
every event be able to have a set of positions at the event.  This is
easily completed with just text and the permissions become really complex
as to who is allowed to assign themselves to what positions, etc.


> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>
Hope that clears up some of my voting on these, would people prefer I give
longer discussions on the user stories page?

Ben
https://ben.thatmustbe.me/