Re: freezing the user stories

On 30 July 2015 at 17:04, Dave Wilkinson <wilkie@xomb.org> wrote:

> Clarifications to the user stories are not the same as changing the user
> stories. I don't believe there is any legitimate fear of a slippery slope
> where user stories or focus will suddenly change. In fact, this change is a
> clarification that distances the story from a direct implementation detail
> of the API, which is a good thing for driving the spec and implementations.
> User stories should capture a general goal, not target specify
> philosophical aspects of a particular specification. We should, as a group,
> reserve some capability to clarify/generalize user stories as these issues
> arise. Of course, taking care that the intent and general functionality
> reflected in the user story does not change. The semantics of the voted
> story remain absolutely the same, and in my mind are more reflective of
> what was originally intended. Due process was achieved by a vote by those
> on the call with the "-1" being discussed. I'm ok with all of this. It's
> really not a big deal.
>

Dave, thanks for a sensible response.

What do you think about the points I raised?

1. Frozen user stories should not change, if this group wants to encourage
implementations.

2. A user story consists of title, url and description.  Changing the title
is changing the user story.

3. Only in light of overwhelming support should clarifications in language,
errata etc. be considered, on the user stories with the most consensus (of
which this was #1).

3.1 Generally this should have unanimous support.

3.2 Generally the onus on the proposer is to look for threads raised on the
mailing list on a similar topic

3.3. The proposers of the change should commit to implementing the user
stories in its entirety.

This group is lacking in implementations.  IMHO this is impacting the
deliverables.  A large amount of time was spent creating and curating 90
user stories and voting on them.

There is to date only one implementation actually working using the social
syntax ("posting, editing and deleting a note") and that is from SoLiD.

We are learning that some of the technology proposed in this group *cannot*
handle the user stories.  The result has been to change the user stories,
rather than, improving the technology.

75/90 of the user stories have been relegated to the non approved bucket,
including fundamental ones.  Of the remaining 10 or so that we have
consensus on which took over a year, we are seeing *yet further* changes.
Slippery slope is a big issue in this context.  I personally in the process
of implementing this user story have been deterred from volunteering my
time to do so.  Note that while this may not be a big deal, it would
actually double the live working implementations of this groups
deliverables using the user stories and social syntax.

Simply put, does this group want to encourage implementations or hinder
them.


>
> On Thu, Jul 30, 2015 at 5:58 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>>
>>
>> On 29 July 2015 at 12:59, Amy G <amy@rhiaro.co.uk> wrote:
>>
>>> The minutes from this discussion are here:
>>> https://www.w3.org/wiki/Socialwg/2015-07-28-minutes#Rename_inbox_user_story
>>>
>>> The user story was *not* changed, just renamed to make the name more
>>> consistent with the contents of the user story (it was renamed from 'Inbox'
>>> to 'Read social stream', and given that 'social stream' is mentioned in the
>>> user story contents more times than 'inbox' this change seems sensible to
>>> me). The contents of the story were not changed at all. Any implementation
>>> of the steps described in the user story should not have been affected by
>>> the name change.
>>>
>>> If you use the name 'inbox' in your code, that's fine: an implementation
>>> detail. If you use 'inbox' in your UI, that's also a totally reasonable
>>> implementation detail. If the actual functionality of your implementation
>>> is dependant on the story being called 'inbox', could you give more details
>>> how? Again, the requirements outlined in the story are the same.
>>> Implementations should be of those requirements.
>>>
>>> My understanding is that to -1 a proposal on a telecon, you should be
>>> prepared to dial into the call to better explain your position, rather than
>>> relying on IRC.
>>>
>>
>> Amy, my objection primarily was to adding it to the agenda, because the
>> user stories are frozen.  Of course, naturally, given that first position,
>> as an implementor I object to the way it's trying to be rail roaded.
>>
>> User stories consist of a title, a url and a body.  To argue that
>> changing the title but not changing the body is not changing the user story
>> is an ABSURD position.
>>
>> It's like arguing that changing the name of this group to the W3C
>> Microblogging Working Group is not a change, and therefore, does not
>> require due process.  Of course that is not the case.
>>
>> This change was bikeshedding and added to the agenda out of nowhere.  If
>> the user stories are frozen, they should not change.
>>
>>
>>>
>>> On 29 July 2015 at 11:41, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>> I was under the impression that the work on the user stories was frozen
>>>> and that the focus now was on implementations.
>>>>
>>>> This is not the case.
>>>>
>>>> Yesterday there was a proposal to change one of the user stories, in
>>>> fact it was the user story that had the most consensus out of all 90 (15
>>>> +1s)
>>>>
>>>> I am  against this change, not least of which because I had already
>>>> announced I was attempting to implement it, and was told the user stories
>>>> were frozen.
>>>>
>>>> I propose to reject this change and there should be changes to the user
>>>> stories under the following sensible conditions:
>>>>
>>>> 1. If it goes to a vote, the vote should be unanimous.
>>>>
>>>> Yesterday there was a -1 and a -0.5. and I think a 0 (minutes would
>>>> help)
>>>>
>>>> 2. The proposer of a change should have or be implementing the user
>>>> story *in its entirety*
>>>>
>>>> I dont believe any of the people voting for the change are implementing
>>>> it *it its entirety* only partially.  I have several GB of setup data on my
>>>> hard drive preparing to create all the steps of this story, I now am
>>>> starting to feel my time could be better spent doing other things.
>>>>
>>>> 3. The proposer must be prepared to follow the mailing list and related
>>>> discussions.
>>>>
>>>> In this case the proposer (also a chair) has refused to follow the
>>>> mailing list, and so, we dont have a good record in our official
>>>> communication flow of arguments for and against.  Is it even allowed under
>>>> W3C WG rules for a chair not to read the ML?
>>>>
>>>> Please could we freeze the user stories, going forward unless there is
>>>> unanimous consent.
>>>>
>>>
>>>
>>
>