Re: freezing the user stories

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

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

The user story has changed, that's the point.  The degree of the change
could be discussed.


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

Yes


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

I did not say that the raiser of an issue must be the most productive
member of the group.  I said anyone proposing a change should be prepared
to review related material.


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

For example, Profile editing.  We demoed this at the face to face.  Now the
key factor of the demo, adding of home town, is proposed to be removed in a
"v2" version.  This slows us down, removes a successfully demoed story, and
gives implementers less certainty of the stability.


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

I am sorry you are deterred by lack of funding, I can appreciate that.
There are many incentives and disincentives that come with working on these
things.  I dont have a company sponsoring me.  I have been voluntarily
contributing to helping this group and the previous XG for over 5 years
including foreign travel to the F2F, which is expensive, and never
subsidized in any way.  My only motivation is to want to see the web be a
better place.  Many projects compete for my time and I have to weigh each
one on how useful they will be.  Moving goal posts are certainly a
disincentive.  Especially when they are done in such a heavy handed way.


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