See also: IRC log
<Ian> https://www.w3.org/Payments/IG/wiki/ExecSummary
<Ian> yes
<Ian> scribe: Ian
<scribe> scribe: Dave
<scribe> scribenick: dsr
Manu sets out the agenda
Ian suggests payment flow conversation take place on Monday’s call with Evert
… re Evert’s diagram, the glossary and so forth
Manu: let’s talk a bit today if we get to it
<Ian> Manu: Alibaba has requested to move the call earlier. We could move it to 10am ET on Thursdays
Manu: Alibaba has propsed we bring the call forward by 2 hours.
Any thoughts on these 2 options?
<Ian> IJ: Simpler to have 1 time; I don't have experience with alternating times
<Ian> DSR: We are trying alternating times in the web of things IG.
<Ian> ...rather, we have two calls
Ian: I don’t have any experiece with alternating timeslots, but suggest a fixed time is less confusing
Dave: WoT IG alternates between 9am and 6pm UTC but this isn’t good when you want to have people from America and Asia in the same call.
David: I think Alibaba wants the
call to start before midnight their time.
... I think that Alibaba may be more interested in the use
cases work than the main call, given their email input on use
cases in particular.
Manu: let’s try 10am ET on Thursday and see if that makes them happier
Ian: shall I update the page to reflect that?
Manu: yes
Dave: we may want to check what the timezone will be for Alibaba given that the US changes on Sunday.
<Ian> RESOLUTION: Weekly use cases call now 10:00am ET on Thursdays.
<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations
Ian presents his list of things we should do in respect to the use cases work
<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations
Ian: we’re working on an executive summary to communicate this. It doesn’t mention the deliverables though.
I hope it provides a better structure for the way we describe the use cases.
Manu: I feel that if we produce several documents it could get confusing. I would prefer to have the architecture and requirements in the same document.
<Ian> Please note that these are called out as separate deliverables, but how we implement them (e.g., one or multiple documents) has not been established.
<Ian> http://www.w3.org/TR/dwbp-ucr/
Ian: conceptually these are different pieces but they could go in the same document.
<Ian> http://www.w3.org/TR/powerful-features/
<Ian> http://www.w3.org/TR/media-accessibility-reqs/
Ian cites an example of a requirements document with use cases included, although not called out.
<Ian> http://www.w3.org/TR/xquery-30-requirements/
The Xquery requirements document omits use cases. I would like to discuss the rationale for the choices before us.
<Zakim> Laurent_, you wanted to raise a question on the single narrative
I think we could shrink the current use cases document considerably. I am playing around to see what feels practical and will then provide my advice to the IG
Laurent: just wanted to check with Ian the purpose of the single narrative approach
<Ian> Payment Narrative
<Ian> ---
<Ian> Description: To help illustrate the (somewhat abstract) steps of a typical transaction, it is useful to have a single narrative that covers all of the steps at a high enough level to be understandable by a very general audience. Once the reader has a solid grasp of the steps of a payment, it will be easier to understand how the use cases have been organized. Note: It may be useful to create a number of these "complete narratives" for different scenarios.
<Ian> ---
<Zakim> manu, you wanted to mention that we're going to talk about Payment Narrative in the next topic
Laurent: a single narrative is what I would call a use case. I want us to give the impression that we are enabling a level playing field.
Manu: I agree that we need to talk about that, and will do so in the next agendum.
<manu> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations
Laurent: as a small detail for the reqs doc, it would be useful to keep the scope out of it
Ian: whatever we have in phase 1, we have use cases for the focus for that phase
We will have a different kind of scope for the technical work
Dave notes that explanatory text for use cases could cover a range of alternative payment instruments
Ian: W3M would love us if we can come up with several WG charters later this year.
David: my phone is dying, I will send some feedback to Ian later today
<Zakim> manu, you wanted to say that we need a "slide deck" on here for messaging.
Manu: I think we’re missing a standard set of slides with talking points we can show at public events etc.
<Ian> https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force
Ian: yes. There are things officially produced by the IG versus supporting materials produced by IG members.
… I would like a slide deck that is IG approved.
Manu: I would like some core material that we individually can include in our presentations
Ian: I will make a note to track
the idea and think about it some more
... on Monday we can ask if the approach works for people and
discuss the split across documents
We will also need to identify the editor for the document(s)
Manu: anything else on the comms strategy? Sounds good to us so far
<Ian> http://www.w3.org/2015/02/wpay-sample.html
<manu> http://www.w3.org/2015/02/wpay-sample.html
Ian: I had 2 thoughts. Do the steps make sense as described. This is not intended to cover everything the IG wants to address
… the idea is to use one use case narrative and apply it to explain the payment flow.
Laurent: concerned that it gives too much emphasis to one payment method and could bias people reading it
<Ian> +1 to second narrative
Ian: I think we could address your concern by giving a 2nd narrative.
<Ian> +1 to Laurent creating second 1 :))
Laurent: for a non card payment
<Zakim> manu, you wanted to mention that we need to ground the 'phases' with something.
<manu> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#introduction
Manu: I am a bit concerned about giving all these examples of flows.
What’s missing is a high level account of how everything fits together
It isn’t a comprehensive account, but rather an introduction. We can then get into more detais with the micro use cases.
<Ian> [IJ also sees that Manu's integrated approach could work]
If we can get 3 or 4 alternatives that should show the flexibility
Manu: I think we only need the high level account for a single narrative, is that good for you Laurent?
Laurent: if you cover 2 or 3 narratives it would work better
I definitely like the full range with the micro use case approach
<Ian> Laurent: +1 to micro use cases to cover the scenarios; 2-3 full narratives as examples
<Ian> dsr: The email I sent with high-level single perspective narratives...that could be a single document
<manu> dsr: The email I sent w/ high-level perspectives/narratives - that could be one document targeted at people that want to ignore the details.
<Ian> ....the kind of explanation you want to do in a second doc, that focuses on a separate audience
<Zakim> Ian, you wanted to say I was imagining separate doc and to add that having multiple narratives makes more sense to me in a separate doc...but see one as better in same doc as use
Ian: if we have an extended narrative just before the micro use cases, this would work.
If we did 3 then I would prefer to have the full set later, e.g. in an appendix
Ian: I would like to have a look at Dave’s email again.
<Zakim> Laurent_, you wanted to react on Dave's mail
I like to keep things short and simple to understand
Laurent: why not write 2 or 3 use
case narratives in more detail and point to them as a separate
document
... I like user centric narratives, that is important for W3C
for using facing narratives.
some of dave’s narratives are too far from the IG’s focus.
<Zakim> manu, you wanted to mention that people will skip over the links.
<Ian> Manu: Risk of multiple pages is that people will miss them.
Manu: I worry that people may not follow the links
It is less of a risk if we have a single document. We could use the first working draft as an experiment and see how people react
<Laurent_> +1 on iterating
… and the use the comments to improve the structure for the next draft
<Ian> +1 always on iterating :0
Manu: I prefer to have a single extended narrative followed by the micro use cases
Ian: everbody loves iteration so no complaints from me on that
I think we can rely on appendices for details, but want to ensure that readers understand what we are trying to convey
<Laurent_> +1 on one main narrative + other ones in annexes / end of document
<manu> +1 I could live with that - other narratives in appendices
Ian: my other comment is about Laurent’s convergence point. The IG is chartered to support convergence between web and payment terms in brick & mortar stores. Is this something we do from the start or get to later?
Laurent: we need to reach agreement on scope. Right now I think our scope is too broad
this risks slow progress
Manu: agree that we want to not take on too many work items.
I want to reach an agreement on immediate next steps.
<Ian> +1 to micro use cases, narrative, and micro-narratives
a. move narratives into the use cases document
<Ian> (Notes: IJ's narrative is incomplete. Dave's might be split between micro-use cases and micro-narratives; need to see)
<manu> PROPOSAL: Integrate Ian and Dave Raggett's basic narrative into use cases document, integrate examples of micro-usecase alternatives into use cases document, and integrate alternate narratives into an appendix in the use cases document.
Ian: I really like making the use cases simpler and easier to explain to people outside of the IG
Manu and Laurent check their understanding of terms for micro use cases
Dave notes the current document is very hard to follow
<manu> s/:O/:)/
<manu> ACTION: Manu to integrate Ian and Dave Ragget's basic narrative into use cases document, integrate examples of micro-usecase alternatives into use cases document, and integrate alternate narratives into an appendix in the use cases document. [recorded in http://www.w3.org/2015/03/05-wpay-minutes.html#action01]
<trackbot> Created ACTION-76 - Integrate ian and dave ragget's basic narrative into use cases document, integrate examples of micro-usecase alternatives into use cases document, and integrate alternate narratives into an appendix in the use cases document. [on Manu Sporny - due 2015-03-12].
<Ian> ok
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/avoid/ensure/ Succeeded: s/ensure/give/ Succeeded: s/given/giving/ Succeeded: s/Ragget/Raggett/ FAILED: s/:O/:)/ Succeeded: s/Docs!/Web Payments IG Deliverables/ Succeeded: s/yes// Succeeded: s/happening right now...// Found Scribe: Ian Found Scribe: Dave Found ScribeNick: dsr Scribes: Ian, Dave WARNING: Dash separator lines found. If you intended them to mark the start of a new topic, you need the -dashTopics option. For example: <Philippe> --- <Philippe> Review of Action Items Present: Ian David Manu Laurent Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0001.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 05 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/05-wpay-minutes.html People with action items: manu WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]