[use cases] Meeting minutes for 2015-03-19 telecon

The minutes for today's Web Payments IG Use Cases Task Force telecon can
be found here:

http://www.w3.org/2015/03/19-wpay-minutes.html

Full text of the meeting follows:
--------------------------------------------------------------------
Attendees

Present: Ian, Manu, Dave_Raggett, David_Ezell, David_Jackson,
         Cyril, Shane
Scribe: Ian

Topics
1. Look at current use cases doc
2. Revised Use Cases Documents
3. Payment Phases Applied to the Real World
4. Next Meeting

Manu: Agenda requests? [none]

Revised Use Cases Documents

<manu>
https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#toc
Manu: At this point, all of Ian's suggested changes have been integrated
(or rejected! :)

[Manu reviews the document flow]

Manu: Still need stories in section 7

<manu> Ian: One minor comment - I have some additional notes that I have
not integrated - those don't change the document much.
Manu: Group seems to be ok with the doc structure
... Any comments or concerns about _structure_?

<CyrilV> fine for me
+1 for doc structure

<manu>
https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes
Manu: We need to figure out how to group some sections

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-offer

Manu: Ubiquitous schemes have been around or a while; emerging are new

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes

Manu: I think we will also have requirements

https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations

<manu> Ian: I want to have a greater discussion on whether this document
should have requirements. My emerging understanding, and the one I
heard, is that use cases don't need to include any requirements. It
could just say "here's the scope of the work".
<manu> Ian: When we get to the next level down - concrete requirements,
we can derive them from the use cases. I think it's tempting to include,
but I think it's unnecessary and we'll be duplicating information
between architecture and this document.
DavidE: I think I agree with Ian at this point...I was looking at
Chaal's material...I think probably we need to pursue Ian's path
... requirements would reference the use cases that led to them.

Manu: I disagree slightly.
... we've seen other WGs put their requirements in their use cases
doc...and it's worked out for them.
... the biggest concern I have is that developers who look at use cases
may be confused because we don't say anything about requirements.
... it may feel toothless without requirements.
... we could "list" requirements in use cases doc and then link to them
in a separate reqs document.
... we should link "goals" to exec summary
... we could do same with requirements.
... the down side is that we have to keep the docs in sync

<manu> Ian: I feel like the requirements flow from the use cases and not
vice-versa - it is quite possible that in real life we find that we
reach a steady state with the use cases (at least in the first iteration)
<manu> Ian: If we're satisfied with them at some point, we don't end up
touching that document at all - or if it's combined, we don't focus on
it too much - then all attention will shift to requirements document.
<manu> Ian: Since the purpose is narrow in scope - then the rest of our
work will turn the implicit requirements into well document requirements
that point back to use cases that generate them.
<manu> Ian: Yes, we can put everything in one document. Aware of
costs/benefits of everything in one document. I think the use cases
document is going to become stable at some point, and we may not touch
it after that.
<manu> Ian: If we have references back to use cases, they should all
have their own IDs.
<manu> Ian: It's not clear to me, functionally, that people would look
at the subscription use case and then say "Ok, what requirements would
be derived from this."
<manu> Ian: In order to get to FPWD, we can try it without requirements
- given work that needs to be done and timeframe, let's not focus on
requirements yet.
<manu> Ian: Without saying it'll be in the same document or another. I
don't think we'll be fleshing out a bunch of requirements, don't think
that'll be in FPWD.
<Zakim> manu, you wanted to mention he doesn't feel strongly about this.
<CyrilV> +1 to a "list only" of requirements in "use case doc" and
details in another document
Manu: I agree we should not do requirements before FPWD
... meanwhile, I don't feel that strongly about this...we can put the
doc out...and see how people respond.
... part of me is trying to figure out a way to head off comments

[IJ suggests a note up front that we will use these to create technical
requirements and those are forthcoming]

<manu> Ian: We should set the expectation that there will be
requirements. In the intro, etc, without making a commitment on where
they'll be.
DavidE: Yes, I think the requirements come next
... I also agree too much to add before FPWD

+1 to not committing to who we will implement them when we have them

Manu: We can add note to the status section we'll do reqs next
... ok with that?

+1

<CyrilV> +1
<manu>
https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes
Manu: In 6.2.2.1 high priority...there's something called MANUal
selection ;)
... it has bulleted items in manual
... each one is a different way of looking at the manual selection use case
... we're trying to gather them into a single block.
... is it ok for use to intersperse single line and bullet items?

<manu> Ian: If I'm correct, this is the approach I had labeled groups -
this is more or less.
<manu> Ian: Visually, at first I thought there was a problem with the
use case... I wonder if the bulleted list could be a sub-bulleted list
of a single line. For example, short higher-level statement, and then
subbullets.
<manu> Ian: For example: "Manual selection has multiple ways of
happening, for example:" - these are thematically related... when I hit
just five bullets and have no framing, I don't know why I have five and
how they relate. I'd like to keep it extremely short - multiple
illustrations of something.
<manu> Ian: Rough criteria would be - if they would be illustrating
different things, they should be on their own... or if they're showing N
different instruments, and we found it annoying to break all of them
apart, let's characterize them differently.
<manu> Manu: Yes, I think that would work.
Manu: I think that would work...

<Zakim> ShaneM, you wanted to ask about one of the use cases
Shane: I think it makes sense to use the bullet list and can see why
there is an intro sentence to explain why there is a bulleted list.
... but they should all have the same motivation..other wise it becomes
mixed up.
... so the same goals and motivation => group them together.
... my second comment has to do with specific wording in 6.2.2.1

"Claire has multiple credit cards from the same bank as well as one
debit card. " =>

"Claire has multiple credit cards and a debit card from the same bank.
She chooses her debit card"

Manu: Yes, the bullets need review and cleanup

<Zakim> Ian, you wanted to discuss minor suggestion
Manu: Summary - if we have a bulleted list, let's have intro sentence to
justify the list. And one way to determine whether to have a bullet list
is to look at motivation/goals

<manu> Ian: This is a very minor comment - finding deeply nested
numbering system annoying - I get freaked out at hierarchies... can we
remove numbers from high priority.
<ShaneM> +1
<manu> Ian: What if we don't need the high priority label at all.
<Zakim> manu, you wanted to mention hierarchy and priority.
<ShaneM> I sort of like reinforcing that things are high priority
Manu: I agree that the deep hierarchy is annoying; we can remove the
numbering

IJ: My proposal is to say up front "Unless we say otherwise, it's a high
priority"

Manu: We have 140 use cases that we've not yet reviewed...I feel like we
are going to end up where we are now

<manu> Ian: I want us to prioritize them, but from an editorial
perspective - don't say high priority - just say everything is high
priority until we say otherwise.
Manu: Ah, ok. Makes sense to me.

Shane: I have a weak disagreement.
... the factor out approach presumes people are reading the whole doc
(which people may not read)
... I'm happy to try this out but expect there will be confusion and I
get to say "I told you so"

+1 :)

Manu: I agree with Shane that's the reason we have these labels

<ShaneM> [H] Ubiquitous Schemes
<ShaneM> [H] Emerging Schemes
<manu> Ian: I think any time you're going to have a formal system, you
need to have definitions on what "High/medium/low" means.
<manu> Ian: Maybe we have lower-priority for the group - throw
everything in one category - hold funds and trial-ware, for example. For
FPWD - we're still working on priority - then definition becomes "this
is where group defines priority"
<Zakim> manu, you wanted to argue against "low priority category"
<manu> Ian: If it was a high priority to make them have the ability to
be quoted independently - then I'd agree with your assessment.
Manu: We had, Ian, what you suggested 3 or 4 weeks ago...we had
high/med/low.....

<manu> Ian: As an example - look at section 6.1.1 - without a label -
start w/ high priority ones... then group all medium/low use cases -
don't think there's a good difference between medium/low - still working
out priority.
<manu> Ian: Some sections won't have a label, others say we're still
working on it. Now that there are only two labels - these are "high
priority", "we're working on these".
<Zakim> manu, you wanted to say "must have", "nice to have"
Manu: I think the categories we have today are "we agreed" and "we have
not yet agreed"
... but those categories are going to change to "must have" v. "nice to
have"
... I hear you saying we have no label for the ones we've agreed to, and
we have a single label for where we are still working.

IJ: +1 to telling people how we are thinking about how the doc will
evolve. +1 to having "decided/not decided" today

with an explanation of future plan

(which is "must" v. "nice to have")

Manu: Any disagreement with that approach for FPWD?

(None expressed)

+1 for that approach

<dezell> +1
<Jackson> +1
Manu: Any other thoughts on how use cases are structured?
... if not I will apply today's discussion to the text
... and do integration of FTF-approved use cases

[Thanks Manu!]

Payment Phases Applied to the Real World

https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#the-payment-phases-applied-to-the-real-world

<manu> We want to do something like this:
https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#a-basic-example-of-the-payment-phases
Manu: We should have a small number of them that tell stories to help
people understand the flows that we have in mind

<manu> for section 7:
https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#the-payment-phases-applied-to-the-real-world
Manu: Do people like this approach of having more involved stories at
the end of the doc to ground the steps into real-world examples?

DavidJ: I have a question...How much more detail are you looking for for
each use case?

Manu: Section 4 gives you the story of a complete transaction.
... those details line up as a full example.
... we want to take that idea and do the same in section 7 with
recounting complete scenarios (in the terms of our flow)

<dezell> david: section 7 is a set of proofs that we have defined things
that are useful.
<manu> Ian: Why do we have the document in this structure? It's useful
to talk about hoof shapes of different types of mammals... The use cases
talk about all the different types of hooves. Section 7 talks about the
shape of the animal... you can't just talk about the hooves, you have to
also talk about the animal.
<manu> http://en.wikipedia.org/wiki/Farrier
Manu: Any volunteers to contribute stories to section 7?
... it takes about 2 hours to do one in my experience

DavidE: I will try Apple Pay but can't promise

David: If there is a sub-interaction you want to do ... if I can help
edit and send by email.that's fine.

Manu: +yes
... e.g., copy section 4 and write your own, then send email
... we'll drop in the doc and people can review

IJ: Manu, who has volunteered already to write stories?

<manu> Ian: Who have volunteered so far?
Manu: Kepeng said he would write one for Alipay

<manu> Ian: Kepeng volunteered, I think Laurent volunteered as well.
<manu> Ian: One other comment - as I look at the edited stories in 7, my
sense is that some of them may not fit with the payment phase that we
have described - government entitlements disbursement.
<manu> Ian: We might want to have a new appendix for other payment flows
that we're going to work on - partly meant to answer questions that are
likely to arise - "What about /my/ use case?"
<manu> Ian: We are going to get to person-to-person,
government-to-individual, etc. Having some of those in a new section on
future payment flows might make more sense.
<manu> Ian: We're only trying to do so much in the first pass - 7.6-7.8
might fit elsewhere.
Manu: Agreed in general...I think 7.6, 7.7, and 7.8 fit into our current
flow.
... but we can't also do everything in the FPWD
... i think the place to put this is in the status section
... e.g., status section
... maybe we need a loud statement in status on future work:

* Use cases

* ISO alignment

* Real-World payment stories

<manu> Ian: I think it should be in an appendix - "Future Plans"
IJ: How about an appendix and a link from status to keep status short

Manu: proposal is a big warning on "future work" that we have more plans
... Work for people?

[No disagreement]

Manu: Thanks all!
... I think we are getting into good shape for FPWD

Next Meeting

26 March at 10am ET for 1 hour

<CyrilV> thanks

Received on Thursday, 19 March 2015 16:15:45 UTC