Re: freezing the user stories

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

That is indeed the definition of frozen. As I said, I believe there is some
room for clarification, which indeed does better encourage implementations.
This change did not change intent of user story, therefore would not affect
any implementation that read that intent correctly.


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

If the semantics of the user story remain the same, I myself insist the
user story has not changed. Much like if you rewrote the user story in
French, that user story actually remains the same, but it is clarified. If
the title is changed to cause a contradiction or upset the semantics of the
user story, that would be wrong. This is not the case here.


> 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.
>

It was voted upon. Your -1 was overruled. In my opinion that was justified.
You argued against the general philosophy of any change, not the validity
of this specific change. That is, your complaint is on something of a
higher severity, which you are discussing here. This is a better place to
discuss this than the call, where it was off-topic.


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

We have calls and votes exactly in order to discuss and clarify raised
issues. It is not necessary for somebody that raises an issue to be the
most productive reader of the group. In fact, we welcome, as policy, issues
generated by non-members. This happens, for instance, in our github repos.
Precedent for that exists: issues from non-members have already been
deliberated in meetings. One could also say that the onus is on the
detractor to be on the conference call to argue their point actively, but
it is fair to say we also won't consistently demand it if they are on IRC.


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

In my opinion, only the editors of the specification should commit to
representing the user stories in their entirety. (A very commendable task)
The opinion is divided in the group whether or not implementations drive
specification decisions/user stories. I don't feel that implementations are
necessary for proving the existence of a user story. Anybody could
implement anything and say it should be there. It says just as much or more
when we see the need for something that doesn't exist. Especially through
the lens of looking at what already exists and why that is deficient. Also
because extensibility demands we think about the potential futures. The
opposing viewpoint is still justified in that it maintains scope and
clarity, which is why it should be a little of both, but I'm over the "we
need to clone facebook"/"we simply need to standardize status.net/indieweb"
mentality. proofs of concept are not a proof of sufficiency.


> 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.
>

When have we changed user stories? I recall no user story change that would
be blocking or even irritating to an implementer. I can definitely see us
needing to clarify user stories, however, when any ambiguity/confusion may
arise in the future. It would be naive to strictly interpret "user stories
are frozen" when we may, due to lack of foresight, back ourselves into a
corner.


> 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.


It is completely up to you to work on your implementation. No one is
beholden to volunteer the effort to create a full implementation entirely
on their own. It is at our own peril that we are all stubborn/clever enough
to each have our own implementations in mind. Yet, wouldn't it be nice to
have a dozen implementations! Almost ideal, really. Though, to be fair,
James' github repos are our canonical reference implementation:
https://github.com/jasnell and I'm sure he'd accept contributions or larger
projects built off of those libraries.

Though, I'm confused by how this simple clarifying title change has caused
such a confusion in you about how to implement the story that you are now
stalled. If there is confusion in how the story could be implemented,
certainly that's worth discussing and changing the user story to be more
well-defined. It hasn't been demonstrated that this title change affects
the semantics of the story, so no implementation should be hindered by it.
If that is untrue, then just state what the ambiguity is and we can solve
that and you can move forward. If you are working on this particular story,
then you must be very close to a working prototype of a simple social
system. That's very good work.

If bureaucracy alone is your holdup, then you might have a hard time. Many
people dislike working groups such as this because they are slow and overly
political. The solution is usually either 1. ignore the working group and
implement whatever you want, or 2. implement the working group spec but
ignore any changes. Those are legitimate things to do. Even though we
wouldn't encourage them, we still, obviously, need to accommodate people
within those camps. That's why I tend to champion extensibility because it
will ultimately aid in interoperability with those that dislike the
WG/committee-style politics and do their own thing.

I myself am deterred by a lack of funding. I always feel that if I'm going
to set up local routing tables to test federation that I should get paid
for it. :)

On Thu, Jul 30, 2015 at 11:36 AM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> 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.
>>>>>
>>>>
>>>>
>>>
>>
>