Open markboots opened 7 years ago
+1 to webhook as I think it will force some interesting thought. (what do you do with the result?)
Would advise we think carefully around what "mobile" means, I suspect there are at least three things here: Messaging, IVR, USSD .. Note that Messaging could be an IP channel (Telegram)
I suspect these each need to be their own "extension" (is that what we are calling them or layer?)
+1 to Messaging and IVR specs being in scope for sprint 2. +1 to Console/IO extension being in scope for sprint 2. +1 to building a rehearsal suite, perhaps just an examples/ folder, fine with those being just primitive for now
I'm ok pushing primitive engine.
Hey Nic,
As a followup to your comments about getting utility for RapidPro/Nyaruka out of FLOIP, are the items you +1ed things that would help w/this, are there other things not on this list that would?
@pld I think our comments there were more that we aren't gaining additional insights in this work than we wouldn't have gotten otherwise, not that the pieces of work are the wrong ones. I think the same is true for these pieces, they are the right ones to work on, whether we will gain anything by working on them on FLOIP vs our own RapidPro playground, that we'll see.
I'd like to see some formalisation of flow execution semantics in this sprint. What are the different objects that an engine should include, how they relate to each other and how they evolve. Item 7 from Mark's list should be included here I think.
+1 to webhook spec +1 to console I/O +1 to start defining mobile primitives (this will probably span more than one sprint)
Hi team,
Apologies for the delay in following up here; I was off last week.
We have consensus on these items for Sprint 2:
To make our sprint planning process work, would be great to get to a clear (1 paragraph) description of what counts as "done" for these tasks, come up with an estimate for them, and get them assigned out to teams. Any volunteers?
What do we build in Sprint 2?
e.g.:
Actions: