Milestone planning - May 26th -> July 7th

velocity =~ 30

We took the result of previous planning; then we estimated some of the stories we didn't finish yet, and we discussed about the services we want to create (see also the etherpad https://etherpad.mozilla.org/ng-message-threads-api).

It was quite difficult to estimate because a lot of tasks are new to us. So the estimations may be completely wrong (in one direction or the other).

Results of the planning

Story: Split panels in separate documents

Inbox is nearly ready, Conversation still has some work needed. See discussion below.

Estimate: ~4.3 [julien 5][oleg 3][steve 5]

Story: Define all services for Inbox panel

See discussion below. This is including the mozAPI wrappers.

Estimate: ~15

Story: IndexedDB in Gaia

Estimate: ~10

Discussions

Story: Split panels in separate documents

(Julien) Where are we? I think we still work on removing dependencies, but do you know where we are in this process? (I think you Oleg and Steve know better than me here)

(Oleg) So Inbox is separated, we have a bunch of Conversation view dependencies to other views, but I don't think it stops us from experimenting with rendering them in a separate documents/iframes even with mocked dependencies... But nothing is landed yet though

(Steve) I think the first separation for inbox markup is almost ready, if we don't focus on too much refactoring :p (These refactoring is great anyway)

(Oleg) No more refactoring, I swear! :)

(Julien) I'm most worried about the issues we have with system messages for Conversation; and if we start using the threads lib.

(Oleg) mmm I don't really see why we can't workaround system messages like we do (in WIP) with activities? Until we can have them in SW.

(Steve) The workaround for activity is fine, I don't think we could migrate to threads lib directly and we'll need a replacible interface for it

(Oleg) Mm, but we already use threads.js in WIP or what do you mean? I mean it doesn't need any workers or ifames to work

(Steve) yes but I suppose we might need to wrap up the system message part in service

(Oleg) Yep, so I was thinking like this: now we create services that handles system messages and live in main context that can recieve those messages, then (when we have system messages in SW) these service are moved there and client code is not affected.

(Julien) so in the WIP we could have services that live in the top level page ?

(Oleg) Yeah, this WIP actually works :) Threads based on BroadcastChannel internally, so when we create two broadcast channel instances (one when we create service part and once when we create client part - they use "threadsmanager" channel) in the same context they can recieve messages from each other. That's why our client sees service. Not sure though if it's not a bug in threads.js :D

(Julien) Ok I see (and remember now :p).

(Julien) so I think we should go on splitting conversation.html. What are the tasks left for this split ?

(Oleg) ActivityHandler part is in progress, and I'm not sure about Navigation part... don't have idea how it's going to work. I mean we can easily extract conversation.html (everything except for what we moved to index.html :)) but when we load this html in iframe we should have they way to switch to Conversation or Composer it's kind of intersecting with navigation, so I'm not sure what "acceptance criteria" for this task?

(Julien) navigation part is another story below ;)

(Steve) My "acceptance criteria" is quite low: you can simply split the mark up and load composer/conversation separately. For the navigation we can leave it to navigation part.

(Julien) I think the acceptance criteria is "load in firefox" and that's all for this story.

(Oleg) Okay, let's see what we can do without too much touching current navigation code, oh yeah I remembered what stopped me a bit - it requires Threads to be ready (for the Threads.active). We can probably shim it with direct loading of all threads.

(Julien) as a start I'm fine if we keep all current necessary JS to make it work

(Oleg) Ok. And just to confirm: we go with workaround of system messages or is there any other good way (my main fear is that new navigation stuff will get rid of main context :))?

(Julien) I've seen no good way working in all cases :( only activity could maybe work in an iframe... Yeah the navigation stuff can show issues but we can still have a main context with the shim... Maybe it's not that difficult to fix the system messages enough to work in an iframe, will see. We can also report to Jacob about this urgent issue. (I already reported to Francisco and Vivien)

(Oleg) Okay then

(Steve) yeah we can leave our worries until introduce the nativation and finish it by workaround first.

(Julien) just sent a mail to Jacob about the System Messages issue. So can we estimate what's left for the inbox/conversation splitting only? (note: I think we've been too optimistic in the previous planning :) )

(Oleg) Yeah, now I don't consider all dependencies, just split to make work with navigation easier and minimum of refactoring as I did NOT do this sprint :)

(Oleg) Is it the only in-team dependency that blocks you from navigation experiments?

(Julien) nope, it was only everything happening around us :p I started for real last friday but was quite late in the sprint :/

Estimate: [julien 5 given we took more time than expected in previous planning][oleg 1 for inbox and 2 for conversation][steve 1 for inbox, but not quite sure about the conversation... maybe totally 5 for all is sufficient]

Story: Which questions do we need to answer ? (are there others)

(Julien) do we have more questions to answer? After all it looks like we only get the questions once we start experimenting... So not sure we should keep this one.

(Oleg) Yeah, the only question I wanted to ask you guys via email, but forgot :) Is about telemetry - we're going to have separate startup files for views and need to fire performance events for all startup paths (default or when we start directly from conversation)

(Julien) I think most of it should be handled automatically by the telemetry lib -- maybe untrue in the end, but it's clearly too early to worry right now

(Oleg) I'm saying about this as it may trigger false alerts in auto performance tests since we're going to move things around (at least I didn't know what to do with these events for separated views, we can just not fire them for now), but if you think it's too early we can ignore for now

(Steve) Don't think telemetry will handle all the performance event, maybe I'm wrong. But I agree we should only handle cold launch path for now.

(Julien) the only startup path that's being tested is the cold launch path anyway, right ? Maybe we should focus on this one only right now.. it's quite easy to add later on anyway?

(julien) should we skip this story about finding questions ?

(Oleg) Yes

(Steve) +1

Estimate: [SKIP]

Story: Branching

(Julien: I think we need also to define how we merge between master and the branch)

(Julien) I guess we decided to not branch :) Let's see if we can sustain this for now ?

(Oleg) IMO it became harder but still doable.

(Steve) I thought it might be less possible to branch now

(Julien) what do you mean "less possible" ?

(Steve) Current master looks quite different then 2.x now and it seems not that necessary to brach from now unless we are really blocked with no workaround to shim

(Julien) I think we should branch as soon as we know we break something

Estimate: [SKIP]

Story: Review existing JS files to determine if they are frontend/backend. If some should belong to both, they need to be split

(Oleg) It feels like this story and the story below are the same :) Once I started to work on the service (that uses bridge) I review/determine/move JS files to the right places.

(Julien) yep I agree

Estimate: [SKIP]

Story: Use the Bridge

(Julien) Where are we here? I think we started using it and reporting issues to developers. I'd say this was the goal of the story itself

(Oleg) Yep, I'd say this particular task is completed.

(Steve) The things bothered me most is how we define our Threads service :/

(Oleg) I believe we should start doing it and see how it goes, looks like we have some agreement on etherpad that we can use as start point.

(Steve) So it will be much more work then simply introducing the bridge :p

(Steve) Maybe even the "IndexedDB in Gaia" part

(Julien) in previous milestone planning, we had the meta-story "Split current js into front-end and back-end", this is likely what we need to do now? Should we define the additional stories for this meta-story? I'd say 1 story per service could be a good idea?

(Oleg) Yep, service definitely deserves story that we'll split into tasks.

(Steve) So how many serivces we might have in the end? Like we discussed in etherpad?

(Oleg) + services for activity and notification (aka system message related services). And then maybe some light complimentary services for other tasks.

(Julien) We'll need services for the APIs where we need to be in a window too. But this can be one story (we have one below about this, but we might need it earlier than expected :))

(Julien) clearly the "ConversationManager" service (as I called it -- we can call it differently if you want; "ConversationService" works too) is very big and will need to have itself substories.

(actually I prefer "Service" over "Manager" now :p +1 in Java we usually have these 2 layers high-level "service" + lower-level "manager" . A rule (in Java) is that services can't call each other, they need to call managers only. This helps keeping things tidy. Don't know if we want the same here, maybe not due to worker overhead... But we can maybe still separate the objects Service and Manager properly in one "service" object.

So let's try to create the stories now:

Services

• ConversationService
  • Story "mozMobileMessageAPI" internal service that's based on iframe?

    (Steve) I thought it is MessagingService ?

    (Oleg) Maybe, but I though that MessagingService should only expose send/resend/download and be wrapper around of part of "mozMobileMessage" service - but maybe it's just overhead :) In my head that internal service is shared between Conversation and Messaging and will eventually go away. (Julien) yep I think views should never call mozMobileMessage wrapper directly (and we can avoid calling this one "service" to make this easier to assert)

    (Julien) yeah for me ConversationService is mostly about retrieving information to be displayed. + some high-level things like mark read/unread, delete, things that are directly related to conversations but nothing else (from the point of view of the views -- of course mark read/unread and delete will delete from Gecko as well, but the view does not know this)

  • Story "sms-received System Message" internal service?

    (Julien) To me it was part of MessagingService but I can discuss :)

    (Oleg) Yeah we can discuss, for me it was like if we have "list" service (ConversationService) it should have event smth like "on-item-added" (sms-received, sms-sent), "on-item-updated" (failed to send, delivery-status-change) or smth like this, maybe I'm wrong.

    (Julien) on my paper, I wrote "ConversationService or MessagingService ?" :) In the end I chose MessagingService because I thought it was more network-related but both would work for me. Let's discuss more deeply about this later.

    (Oleg) Okay, and regarding to this service we can have "future" separate bug that will implement local IDB, initially we can do it with in-memory cache inside service - just to see all flows in more or less finished state before dealing with DB.

    (Julien) not even necessary to have in-memory cache, we can just proxy to API for now. (and keep some in-memory cache where this makes sense). But the main goal is defining the API and make sure it makes sense for the view, IMO.

    (Oleg) Yep, that's what I mean

• Story MessagingService
• Story ContactService
• Story ActivityService
• Story NotificationService
• Story DraftsService

(Steve) I think the serivces above should be sufficient; or we need to list all the non-UI related js here?

(Oleg) I also hesitating about DraftsService, I think we'll eventually have it, but maybe we can start without separate service for it.

(Julien) Yep, I think we need it, I forgot it when I moved from my paper to the etherpad ;) But IMO it should only be about saving/deleting drafts, not retrieving them (retrieving should be part of ConversationService, it will come directly when retrieving a conversation (hasDraft) or all conversations (isDraft + hasDraft)). Still need to think about retrieving isDraft draft though, I realize I forgot about this case ;)

(Steve) So we still have saveDraft/discardDarft from DraftService? I think it might be intergrate in ThreadService updateThread, maybe it will make the ThreadService too complicate?

(Julien) I think that the DraftService itself will likely call things in the ConversationService -- but the caller does not need to know.

(Julien) Should we try to estimate previous stories? Or subdivise ConversationService first? Take only some of them?

(Oleg) Let's try to subdivide

(Steve) I feel it's hard to discuss only the ConversationSerivce since they are all related - Since we might want to move part of messaging/contact update/darft updating into it.

(Julien) So you think we should better focus on the use cases?

(Steve) Probably, for example, in drafts case we might want to touch both serivces. And the conversation service might be the last one for readiness

Estimating use cases ?

The use cases can be separated per panels:

Inbox

• Load all threads and drafts (together)
  • It will require wrapper around mozMobileMessage.getThreads (in iframe or main context)
  • it will require wrapper around mozContacts as well/ContactsService?

    (Steve) I think we can put it in another item.. (Oleg) mm, we don't want to return ready contact information at first? (Steve) I mean, maybe we can do it in follow up, not sure if doing all the stuff will make the scope too big. (Oleg) Yeah, but we'll need such wrapper for "React to change events" events anyway

    (Julien) I'm sure that the first works will take more time than the next ones :) maybe start with easier ones ? not sure either how easy it is to do one and not the other

    (Oleg)Maybe we can have first bug that introduces service with only one very simple method that returns threads only, so that work can be parallelized when service skeleton is landed. Second bug would be to return drafts + threads altogether and so on. Third - altogether with contacts info :)

    (Julien) Maybe yep. Sorry to be pushy here, but I don't think we need to go in really deep detail today, it will take too much time... we need to estimate roughly so that we know what we can do in the next 6 weeks... Is it too difficult if we don't go into details? Just trying to keep the meeting short otherwise we'll need the full day...

    (Steve) Yeah I agree we might spend too much time in milestone planning, but it's actually too much uncertainty. Maybe we can give a more then enough point on items and discuss more details in sprint planning.

    (Julien) I know, it's a difficult task to estimate things we never did in the past :) Can we say that in this milestone we can focus on writing the services for Inbox only ? Given all the tasks I'd say this could take 15 points (or maybe even more). We already have ~4 points for the split, + navigation and some IDB work, should be more than enough for this milestone. Then tomorrow we can discuss about how to do this. How does this sound?

    (Steve) Sounds good to me

    (Oleg) +1

    (Julien) OK then, let's focus this milestone on the Inbox -- already a lot of work to do. If we can start some things in the other panels, this is good, but this is secondary :)

• Delete conversations

  (Oleg) does it include "Delete draft"?

  (Julien) I'd say yes, IMO the view should not make a lot of differences between drafts/conversations beside styling (and likely how to load it?). But I think this is debatable, different ways should work fine.

• Mark Read/Unread
• React to change events (message received, contact change)

Conversation

• Load 1 conversation (including its messages + contact information + Draft)
• Send message
• Delete messages
• Add/Delete drafts
• Mark as read
• React to change events

Report

• Load 1 message
• Resend message
• React to change events

Participants

• Load 1 message + contacts information

New Message

• (I expect that finding a conversation for the phone number could be done in service worker)
• Find contacts (including unknown contacts)
• Send message

"on sms received"

(eventually done in SW, but will call other services anyway)

• add message to conversation (needed once we have a local IDB)
• send a notification (that needs to react to onclick and open conversation)
• class0 messages (not sure what we do now?)

"notification" system message

• open (redirect to?) the conversation

"activity"

• open (redirect to?) the new message panel

"IAC+Alarm"

• handles the DB used to filter when receiving/displaying message -- separate DB? separate service?