13:39:09 RRSAgent has joined #wpay 13:39:09 logging to http://www.w3.org/2015/03/19-wpay-irc 13:39:13 zakim, this will be wpay 13:39:13 I do not see a conference matching that name scheduled within the next hour, manu 13:39:53 zakim, room for 10 for 120 minutes? 13:39:54 ok, manu; conference Team_(wpay)13:39Z scheduled with code 9729 (WPAY) for 120 minutes until 1539Z; however, please note that capacity is now overbooked 13:56:39 manu? 13:56:45 I think the name of the con is not pay 13:56:50 I think the name of the conference is not pay 13:56:53 I think the name of the conference is not wpay 13:57:21 https://www.w3.org/Guide/1998/08/teleconference-calendar#s_6653 13:57:25 Aha 13:57:32 I have not moved the recurring confs yet 13:57:34 I will do so 13:57:38 so you don't need to request each week 13:58:05 dsr has joined #wpay 13:59:43 zakim, call Ian-Office 13:59:43 ok, Ian; the call is being made 13:59:44 Team_(wpay)13:39Z has now started 13:59:45 +Ian 14:00:01 +manu 14:00:54 +Dsr 14:00:58 Jackson has joined #wpay 14:01:04 dezell has joined #wpay 14:01:25 zakim, who's here? 14:01:25 On the phone I see Ian, manu, Dsr 14:01:27 On IRC I see dezell, Jackson, dsr, RRSAgent, ShaneM, manu, Zakim, Karen, trackbot, Ian 14:01:40 +Davd_Ezell 14:01:40 CyrilV has joined #wpay 14:02:16 zakim, davd is me 14:02:16 +dezell; got it 14:02:25 +David_Jackson 14:03:04 + +33.1.58.40.aaaa 14:03:12 +ShaneM 14:03:18 zaki, aaaa is CyrilV 14:03:25 zakim, who's here? 14:03:27 On the phone I see Ian, manu, Dsr, dezell, David_Jackson, +33.1.58.40.aaaa, ShaneM 14:03:27 On IRC I see CyrilV, dezell, Jackson, dsr, RRSAgent, ShaneM, manu, Zakim, Karen, trackbot, Ian 14:03:35 zakim, aaaa is Cyril 14:03:35 +Cyril; got it 14:04:16 -> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html Editor's draft of use cases 14:04:17 agenda? 14:04:25 zakim, bye 14:04:25 leaving. As of this point the attendees were Ian, manu, Dsr, Davd_Ezell, dezell, David_Jackson, +33.1.58.40.aaaa, ShaneM, Cyril 14:04:25 Zakim has left #wpay 14:04:27 Zakim has joined #wpay 14:05:00 agenda+ revised use cases docs 14:05:03 scribe; Ian 14:05:05 scribe: Ian 14:05:14 Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0087.html 14:05:17 agenda+ Push vs. Pull Payment Flows 14:05:21 agenda+ flow diagrams 14:05:26 agenda+ multiple payment agents 14:05:39 topic: Look at current use cases doc 14:06:31 Manu: Agenda requests? [none] 14:06:34 Topic: Revised Use Cases Documents 14:06:39 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#toc 14:07:02 Manu: At this point, all of Ian's suggested changes have been integrated (or rejected! :) 14:07:03 q+ 14:07:32 [Manu reviews the document flow] 14:08:25 Manu: Still need stories in section 7 14:08:44 ack Ian 14:09:03 Ian: One minor comment - I have some additional notes that I have not integrated - those don't change the document much. 14:09:45 Manu: Group seems to be ok with the doc structure 14:09:52 Manu: Any comments or concerns about _structure_? 14:09:59 fine for me 14:10:04 +1 for doc structure 14:10:13 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes 14:10:37 Manu: We need to figure out how to group some sections 14:10:39 slaory has joined #wpay 14:11:33 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-offer 14:11:47 Manu: Ubiquitous schemes have been around or a while; emerging are new 14:12:01 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes 14:12:25 Manu: I think we will also have requirements 14:12:25 q+ 14:12:33 ack Ian 14:12:51 https://www.w3.org/Payments/IG/wiki/Communications_Strategy_Task_Force/Doc_Relations 14:13:09 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". 14:13:39 q+ 14:13:39 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. 14:13:44 ack dezell 14:14:16 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 14:14:34 q+ 14:14:39 ....requirements would reference the use cases that led to them. 14:14:41 ack manu 14:14:47 Manu: I disagree slightly. 14:14:59 ...we've seen other WGs put their requirements in their use cases doc...and it's worked out for them. 14:15:24 ...the biggest concern I have is that developers who look at use cases may be confused because we don't say anything about requirements. 14:15:29 ...it may feel toothless without requirements. 14:15:47 ...we could "list" requirements in use cases doc and then link to them in a separate reqs document. 14:16:01 ...we should link "goals" to exec summary 14:16:02 q+ 14:16:07 ...we could do same with requirements. 14:16:13 ...the down side is that we have to keep the docs in sync 14:16:13 ack Ian 14:16:43 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) 14:17:12 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. 14:17:36 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. 14:18:07 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. 14:18:21 Ian: If we have references back to use cases, they should all have their own IDs. 14:18:47 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." 14:18:55 q+ to mention he doesn't feel strongly about this. 14:19:13 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. 14:19:33 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. 14:19:34 ack manu 14:19:34 manu, you wanted to mention he doesn't feel strongly about this. 14:19:35 ack manu 14:19:38 +1 to a "list only" of requirements in "use case doc" and details in another document 14:19:39 q+ 14:19:48 Manu:I agree we should not do requirements before FPWD 14:20:07 ...meanwhile, I don't feel that strongly about this...we can put the doc out...and see how people respond. 14:20:25 ...part of me is trying to figure out a way to head off comments 14:20:40 [IJ suggests a note up front that we will use these to create technical requirements and those are forthcoming] 14:21:05 Ian: We should set the expectation that there will be requirements. In the intro, etc, without making a commitment on where they'll be. 14:21:13 ack dezell 14:21:30 DavidE: Yes, I think the requirements come next 14:21:44 ...I also agree too much to add before FPWD 14:21:59 +1 to not committing to who we will implement them when we have them 14:22:08 Manu: We can add note to the status section we'll do reqs next 14:22:12 ...ok with that? 14:22:13 +1 14:22:18 +1 14:22:20 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-accepted-schemes 14:22:42 Manu: In 6.2.2.1 high priority...there's something called MANUal selection ;) 14:22:59 ...it has bulleted items in manual 14:23:09 ...each one is a different way of looking at the manual selection use case 14:23:24 ...we're trying to gather them into a single block. 14:23:39 ..is it ok for use to intersperse single line and bullet items? 14:23:42 q+ 14:23:42 q+ to ask about one of the use cases 14:23:48 ack Ian 14:24:03 Ian: If I'm correct, this is the approach I had labeled groups - this is more or less. 14:25:33 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. 14:26:28 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. 14:27:04 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. 14:27:13 q? 14:27:23 Manu: Yes, I think that would work. 14:27:24 Manu: I think that would work... 14:27:25 ack ShaneM 14:27:25 ShaneM, you wanted to ask about one of the use cases 14:27:46 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. 14:28:00 ...but they should all have the same motivation..other wise it becomes mixed up. 14:28:10 ...so the same goals and motivation => group them together. 14:28:30 ...my second comment has to do with specific wording in 6.2.2.1 14:28:43 "Claire has multiple credit cards from the same bank as well as one debit card. " => 14:28:57 "Claire has multiple credit cards and a debit card from the same bank. She chooses her debit card" 14:29:07 Manu: Yes, the bullets need review and cleanup 14:29:15 q+ for minor suggestion 14:29:40 ack Ian 14:29:40 Ian, you wanted to discuss minor suggestion 14:29:43 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 14:30:13 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. 14:30:22 +1 14:30:46 Ian: What if we don't need the high priority label at all. 14:30:57 q+ to mention hierarchy and priority. 14:31:01 ack manu 14:31:03 manu, you wanted to mention hierarchy and priority. 14:31:03 q+ 14:31:08 I sort of like reinforcing that things are high priority 14:31:24 Manu: I agree that the deep hierarchy is annoying; we can remove the numbering 14:31:46 IJ: My proposal is to say up front "Unless we say otherwise, it's a high priority" 14:32:03 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 14:32:50 q- 14:33:11 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. 14:33:25 Manu: Ah, ok. Makes sense to me. 14:33:30 Shane: I have a weak disagreement. 14:33:54 ...the factor out approach presumes people are reading the whole doc (which people may not read) 14:34:09 ...I'm happy to try this out but expect there will be confusion and I get to say "I told you so" 14:34:11 +1 :) 14:34:32 Manu: I agree with Shane that's the reason we have these labels 14:35:04 q+ 14:35:09 ack Ian 14:35:10 [H] Ubiquitous Schemes 14:35:21 [H] Emerging Schemes 14:35:36 Ian: I think any time you're going to have a formal system, you need to have definitions on what "High/medium/low" means. 14:36:28 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" 14:36:35 q+ to argue against "low priority category" 14:37:00 ack Manu 14:37:00 manu, you wanted to argue against "low priority category" 14:37:04 Ian: If it was a high priority to make them have the ability to be quoted independently - then I'd agree with your assessment. 14:37:35 Manu: We had, Ian, what you suggested 3 or 4 weeks ago...we had high/med/low..... 14:37:42 q+ 14:37:49 ack Ian 14:38:45 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. 14:38:51 q+ to say "must have", "nice to have" 14:39:35 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". 14:39:45 ack manu 14:39:45 manu, you wanted to say "must have", "nice to have" 14:40:14 Manu: I think the categories we have today are "we agreed" and "we have not yet agreed" 14:40:25 ...but those categories are going to change to "must have" v. "nice to have" 14:40:59 ...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. 14:41:46 IJ: +1 to telling people how we are thinking about how the doc will evolve. +1 to having "decided/not decided" today 14:41:51 with an explanation of future plan 14:41:59 (which is "must" v. "nice to have") 14:42:24 Manu: Any disagreement with that approach for FPWD? 14:42:27 (None expressed) 14:42:29 +1 for that approach 14:42:33 +1 14:42:37 +1 14:43:10 Manu: Any other thoughts on how use cases are structured? 14:43:17 ..if not I will apply today's discussion to the text 14:43:27 ..and do integration of FTF-approved use cases 14:43:32 [Thanks Manu!] 14:43:35 Topic: Payment Phases Applied to the Real World 14:44:15 https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#the-payment-phases-applied-to-the-real-world 14:44:30 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 14:44:38 Manu: We should have a small number of them that tell stories to help people understand the flows that we have in mind 14:44:40 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 14:45:07 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? 14:45:32 DavidJ: I have a question...How much more detail are you looking for for each use case? 14:45:45 Ian has left #wpay 14:45:50 Ian has joined #wpay 14:46:11 Manu: Section 4 gives you the story of a complete transaction. 14:46:21 ...those details line up as a full example. 14:46:39 ..we want to take that idea and do the same in section 7 with recounting complete scenarios (in the terms of our flow) 14:47:11 q+ 14:47:25 david: section 7 is a set of proofs that we have defined things that are useful. 14:47:25 ack Ian 14:48:34 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. 14:49:19 http://en.wikipedia.org/wiki/Farrier 14:50:04 Manu: Any volunteers to contribute stories to section 7? 14:50:14 ..it takes about 2 hours to do one in my experience 14:50:45 DavidE: I will try Apple Pay but can't promise 14:50:53 q+ 14:51:14 David: If there is a sub-interaction you want to do ... if I can help edit and send by email.that's fine. 14:51:16 Manu: +yes 14:51:30 ...e.g., copy section 4 and write your own, then send email 14:51:47 ...we'll drop in the doc and people can review 14:51:48 q+ 14:52:15 IJ: Manu, who has volunteered already to write stories? 14:52:16 ack Ian 14:52:17 ack me 14:52:28 Ian: Who have volunteered so far? 14:52:45 Manu: Kepeng said he would write one for Alipay 14:52:53 Ian: Kepeng volunteered, I think Laurent volunteered as well. 14:53:42 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. 14:54:24 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?" 14:54:50 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. 14:55:15 Ian: We're only trying to do so much in the first pass - 7.6-7.8 might fit elsewhere. 14:55:33 Manu: Agreed in general...I think 7.6, 7.7, and 7.8 fit into our current flow. 14:55:39 ...but we can't also do everything in the FPWD 14:55:46 ...i think the place to put this is in the status section 14:56:03 ..e.g., status section 14:56:13 ...maybe we need a loud statement in status on future work: 14:56:14 * Use cases 14:56:17 * ISO alignment 14:56:26 * Real-World payment stories 14:56:59 Ian: I think it should be in an appendix - "Future Plans" 14:57:05 IJ: How about an appendix and a link from status to keep status short 14:57:24 Manu: proposal is a big warning on "future work" that we have more plans 14:57:35 Manu: Work for people? 14:57:39 [No disagreement] 14:57:53 Manu: Thanks all! 14:58:04 ...I think we are getting into good shape for FPWD 14:58:09 Topic: Next meeting: 14:58:12 thanks 14:58:23 26 March at 10am ET for 1 hour 14:58:25 rrsagent, make minutes 14:58:25 I have made the request to generate http://www.w3.org/2015/03/19-wpay-minutes.html Ian 14:58:25 rrsagent, set logs member 14:59:03 Meeting: Web Payments IG Use Cases Task Force 14:59:32 Present: Ian, Manu, Dave_Raggett, David_Ezell, David_Jackson, Cyril, Shane 14:59:52 Chair: Manu 15:00:03 s/Next Meeting:/Next Meeting/ 15:00:15 s/Next meeting:/Next Meeting/ 15:00:22 rrsagent, draft minutes 15:00:22 I have made the request to generate http://www.w3.org/2015/03/19-wpay-minutes.html manu 15:00:39 rrsagent, make logs public 15:01:00 s/manu?// 15:01:05 zakim, drop Ian 15:01:05 sorry, Ian, I don't know what conference this is 15:01:08 s/I think the name of the con is not pay// 15:01:19 s/I think the name of the conference is not pay// 15:01:28 s/I think the name of the conference is not wpay// 15:01:31 s/Aha// 15:01:37 s/I have not moved the recurring confs yet// 15:01:42 s/I will do so// 15:01:47 s/so you don't need to request each week// 15:01:53 s/scribe; Ian// 15:02:47 rrsagent, make logs public 15:02:51 rrsagent, make minutes 15:02:51 I have made the request to generate http://www.w3.org/2015/03/19-wpay-minutes.html manu 16:27:05 github-bot has joined #wpay 16:27:05 [13webpayments-ig] 15ianbjacobs pushed 1 new commit to 06master: 02https://github.com/w3c/webpayments-ig/commit/73127447c30ba3f9cc8666445f9970ae6a0f1ec5 16:27:05 13webpayments-ig/06master 147312744 15Ian Jacobs: Add question on entity dfn 16:27:05 github-bot has left #wpay 18:00:22 chaals has joined #wpay 18:29:35 dsr has joined #wpay 18:34:44 dsr has joined #wpay 19:37:01 Karen has joined #wpay 19:52:58 ShaneM has joined #wpay 21:27:17 ShaneM has joined #wpay 21:37:17 Karen has joined #wpay 22:12:40 ShaneM has joined #wpay 22:41:35 Karen has joined #wpay 23:34:19 ShaneM has joined #wpay 23:37:52 ShaneM_ has joined #wpay