Gaia/SMS/Scrum/2.2S14/Planning

Sprint is from May 27th -> June 16th (called 2.2S14) (3 weeks)

Velocity: [p=15]
Note: Whistler: 22 -> 26 June. So happens in the sprint after.

PTO ?
Julien: conference this friday, traveling 15th June, I'll be in Vancouver 16th June so I don't know how we'll do next planning exactly... will see !
Steve:no PTO (probably)
Oleg: no PTO planned except that today is hack day

=> I roughly counted p=15 (5 days * 3 weeks * 3 devs - 2 PTO) / 2 points * 0.7 (velocity)

from current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1162028 [NGA] [p=3]
Bug 1162028 - [Messages][New Gaia Architecture] extract conversation/index.html

(Julien) we need to estimate dependencies too

(Oleg) mm, I thought we decided to just extract index.html here without resolving of all deps?

(Julien) we could have deps also just for this :) do we have any ?

(Steve) We will need to create another bug for activity service for sure Done! :) 1168441 :)

(Julien) do we need this bug 1168441 to do the extraction ?

(Oleg) Not really, but just want to land it in this sprint, but yes it's not a blocker for this bug. All inter-view deps in this bug we can just fulfill with stubs. One dep I can think of is to load all threads when we don't load inbox (the case for extracted conversation view). and check if Navigation.js works well without "thread-list" default panel.

(Julien) OK; main goal is still to just load conversation.html?id=XXX (for example, could be something else like a hash for now) and make it load correctly.

(Oleg) yep

(Oleg) So to me subtasks are the following with rough estimates:

• Extract conversation.html; - 1 point
• Load all threads somehow so that Threads.active is not null; 1 or 2 points

  (Julien) if that's easy to load only 1 thread, we could do that too; but if it's too much changes then I'm fine with loading all.

• Verify/fix navigation to work with non-default panel. 1 point if fix needed.

  (Julien) note: I have a fix somewhere too, I'll point it to you

  (Oleg) good :)

  (Julien) https://github.com/mozilla-b2g/gaia/pull/27437 (it's not really nice, some part should move to other objects, but this could give an idea)

(Oleg) So p=3 o p=4 then

(Julien) could bug 1122174 be a dependency and land it separately? Or do you think it's better to land one patch?

(Oleg) If you'd like to finish 1122174, we can wait for it, doesn't really matter for me :)

(Julien) You can take over it too :p ; but yeah I can also try to finish it separately.

(Steve) p=3 sounds reasonable since we already left some efforts in activity service

(Oleg) "" You can take over it too :p ;" - sure, let me try to start and see what way is better then :)

(Julien) are we positive that p=3 will be enough to extract inbox.html ?

(Oleg) I feel p=3 is enough, will not do much refactoring :) "stub, stub and one more stub" :) p=4 sounds a bit too much honestly and not accountable.

(Julien) I agree, with p=4 we need to separate in subtasks :p (ok we did it). ok then, p=3 works for me.

https://bugzilla.mozilla.org/show_bug.cgi?id=1168441 [NGA] [p=3]
Bug 1168441 - [Messages][NG] Implement ActivityService

(Oleg) So as I said I'd rather include this bug in this sprint, we can sharpen it in whatever way we want just to have simple example of ready service - it's probably the simplest one.

(Julien) I'm fine with including this in the sprint but yeah we need to define properly what we want in it (I haven't followed completely all your discussions I admit :) ).

(Steve) So this patch will include doc for service as well?

(Oleg) Yeah, I think so. It's a good practice to start doing so :) So kind of review is starting from spec discussion and next commits are implementation ones. So with our spec-driven approach it would be not less than p=3 even that patch is ready I'm not sure you are ok with it. What do you think?

(Steve) Yeah I think the same if we are planning for spec and implementation, p=3

(Julien) OK this sounds about right.

For other bugs from sprint, I think we should either skip or reestimate them given the tasks we decided yesterday in milestone planning. See the "features" part.

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1149345 [3.0+] [skip]
Bug 1149345 - [Messages][Threads] Images can be attached to incoming messages, and corrupt the thread it was originally meant for.

(Julien) This is not actionable, we need activity.cancel().

https://bugzilla.mozilla.org/show_bug.cgi?id=1159939 [3.0+] [skip]
Bug 1159939 - [SMS] text/html email-gatewayed MMS messages display as an untitled attachment in Messages app thread (such as those produced by the email app in reply to an MMS message)

(Julien) nothing urgent, I'd suggest to skip.

(Oleg) agree

(Steve) skip

https://bugzilla.mozilla.org/show_bug.cgi?id=1160049 [3.0+] [skip]
Bug 1160049 - [Messages] Attach menu should not dismiss when user cancel the replace attachment request

(Julien) Involves modifying common code, not urgent, but still a regression

(Julien) I think we should skip.

(Oleg) I'd rather skip as well

(Steve) skip

nominations

https://bugzilla.mozilla.org/show_bug.cgi?id=1168060 [3.0?] [p=1]
Bug 1168060 - [Flame][DSDS][Message]"Dial 12345 via" is displayed as heading at "Select SIM" view.

(Julien) I started a patch because it was quite easy -- should be ready today. Can be out of the sprint given it's nearly finished.

(Oleg) I'd still include it in sprint since you're working on it and it's blocker nomination

(Julien) in that case it's p=1.

(Steve) p=1

features

Story: Split panels in separate documents

See above; do we need any more work for this currently? I think we estimated already.

Maybe: do you think it's possible to somehow build index.html from inbox/index.html and conversation/index.html so that there is no duplication?

(Oleg) I tried but it took too much time for me and haven't found any good way, I'm happy if anyone else tries to think about it :(

(Steve) I'm fine for leaving the dup temporary, because we won't need the main index.html eventually

(Julien) I'm mainly afraid when we'll fix bugs in index.html and not the others (or the other way around). But we don't change the markup very often anyway, we mostly change JS.

(Steve) Yeah your concern is right but we didn't touch the markup frequently, so I think it's fine for me

(Julien) OK for me

Story: Define all services for Inbox panel

Let's look at use cases in https://wiki.mozilla.org/Gaia/SMS/Scrum/Milestone_Planning/2#Inbox and decide which ones we take for this sprint. 8 points left.

Load all threads and drafts (together)

(Steve) I think we might need to introduce first version of the messageAPI service(getThreds) for Thread service?

(Julien) I think the first task will be responsible to do a lot of things anyway; so maybe better to start with a simpler service ?

(Julien) first task is to write the spec too, BTW :)

(Oleg) Just to clarify, should not we create mozMobileMessage wrapper service first that will be hosted in iframe/main context? +1

(Julien) I think so, it needs to be in "window" context -- does it need to be spawned in the main context or can it be spawned in any view ?

(Oleg) Actually not a big deal right now. Service won't know about context much anyway.

(Steve) Not sure about the mozmessage, but I tried battery API not in the main context and it seems works, we should try it try and raise if it doesn't work.

(Julien) OK. Should create a bug for each service we need to create ? Goal would be to just set up the frame for the services without implementing them for real, so that in each use cases we could implement ?

(Oleg) Sorry didn't get last sentence :)

(Julien) I mean we could create 1 bug per service; goal for each bug would be to create only the structure (spawn the service itself, create the JS file for the service) without the implementation. Then the other bugs for the use cases would implement what they need inside the service.

(Oleg) Ah yeah, so that basically means create specs only + basic interface based on approved spec. Right? If so then yes - totally agree.

(Steve) Sounds good to me

(Julien) I was thinking: 1 bug for spec, 1 bug per service. (so that it's finer granularity and we can see the sprint moving forward).

(Oleg) mm maybe, my main point was that it's much easier when we edit/review spec and interface altogether (without implementation), but as you guys wish, both approaches work for me.

(Steve) I think the bug(sounds like meta) will only for spec and maybe basic prototype of service

(Julien) IMO the spec will already take some time to discuss, and the basic prototype can be separate because can be done by somebody else too.

(Oleg) So let's choose whatever way and estimate :)

(Julien) 1 bug for spec, 1 bug per service, this works better for me. okay +1

Delete conversations

(Steve) It will involve messageAPI service as well.

Mark Read/Unread

(Steve) Need to introduce messageAPI service?

React to change events (message received, contact change)

Bug - Define the specification for services [p=1]

(Julien) preliminary work is at https://etherpad.mozilla.org/ng-message-threads-api, I'll file a bug and starts up a PR with what is there already. Then we can all discuss on the PR.

(Steve) I already have 2 bugs for Threads(conversation) and drafts:

(Steve) https://bugzilla.mozilla.org/show_bug.cgi?id=1166198 Threads(will rename later)

(Steve) https://bugzilla.mozilla.org/show_bug.cgi?id=1163955 Drafts

(Steve) Not sure if it works for you,

(Julien) I'd prefer a separate bug; your bugs look like metas :)

(Julien) we can reuse them as meta I think. I'll think about it.

(Julien) given we already discussed and the list of services is already roughly defined, does p=1 sound good ? Goal is to have a README (or others, SERVICES.md maybe ?) explaining the services and their goals.

(Oleg) maybe services/README.md, p=1 for one bug means very draft description of all services we're going to have?

(Julien) yep, I take into account that you said below about adding more spec when laying out the service.

(Oleg) Yeah, I wanted to say the same that spec will be updated later with more details, so p=1

(Steve) If it's only very first version and we might update it later , p=1 is fine

Bug - Add some (shell ?) code to easily update threads.js (especially if we want to rename it) and add threads.js to our codebase. [p=1]

(Oleg) Btw, is that so critical? Looks like we don't have naming conflict right now, it just looks similar to Threads but it's threads :)

(Julien) but I'm sure we have variables called "threads" all over the place too :/ this will be really confusing.

(Steve) Anyway rename the lib is easy, do we need to have a consensus about the lib name here? And where will we put it?

(Julien) I think the name "bridge" is quite good for us: easy to understand, no conflict. I don't really mind where we put it... we can discuss on the bug about that, I know you have ideas :)

(Julien) I think Steve already knows the code to update threads.js so I'd say p=1 is enough.

(Oleg) p=1

(Julien) what do you think Steve ? You'll likely the one who'll do this :)

(Steve) If you agree with "bridge" and only add it to our code base, p=1 is enough

(Julien) and about adding a script to make it possible to update it easily ? (I'm not asking to integrate with the build system :) )

(Steve) Not quite sure about this part, so we will using bower to fetch the lib in the build time?

(Julien) no, I'm especially saying I don't want to fetch automatically at build time. What I want is a simple shell script running the necessary commands to update the lib, so that it's easy to update for anyone of us.

(Steve) Ah, ok, so just a script to create a output lib we want

(Oleg) yeah, kind of wget&browserify would work for me, not sure about Julien :)

(Julien) I think it will likely be a call to bower + to browserify, with maybe a gitignore to ignore bower_components ? Different solutions, but yeah that's what I want :) I still think it's p=1 given this, what do you think ?

(Steve) ok

Do we agree on the list of services in https://wiki.mozilla.org/Gaia/SMS/Scrum/Milestone_Planning/2#Services ? (at least roughly -- we could have some more)

(Oleg) looks good to me

Bug - Lay out the structure for ConversationService
Bug - Lay out the structure for MessagingService
Bug - Lay out the structure for ContactService
Bug - Lay out the structure for ActivityService (maybe not needed ?)

(Oleg) I can add spec to existing patch I think

(Julien) I think the spec should live in the first bug "Define the specification for services" but not sure?

(Oleg) mmm do you want single bug for all services? I mean it may lasts too long to resolve for all services. I thought like once we agreed on some single service, we update/land spec or part of spec for it so that someone can start implementing it or what was your plan?

(Julien) (trying to organize in my own head) Yeah after all whatever works for me.

Bug - Lay out the structure for NotificationService
Bug - Lay out the structure for DraftsService

(Steve) Seems like we won't finish all the layout in this sprint

(Julien) Which ones do we really need for Inbox ? I'd say ConversationService especially

(Oleg) Yep, drafts and contacts can probably wait for their services

(Julien) Remember that in inbox drafts and contacts will come with threads... so I don't think we'll need the services in Inbox.

(Steve) So Conversation/ Messageing / Notification/(Activity?) for this sprint?

(Julien) I think we can do Conversation/Messaging/Activity (activity because it's already started). Then focus on the use cases and start implementing them. I hope we'll be able to reuse some of the current code. Also I expect the first one might take p=1 but the other ones only p=0.5.

(Julien) That would do p=2 both these 3 (and given we aleady have 3 more for ActivityService above). What do you think?

(Oleg) Sounds good

(Julien)That leaves 4 points to work on some use cases. Maybe we can use all of these to work on the initial load of threads? I'm sure the first use case will be quite long to do because this will be the first service and we'll likely need to create sub-services (or "Managers") like the wrappers for mozAPI etc. I'd rather start with an easier use case but I'm not sure this is meaningful to start "deleting" (for example) before we do the initial load...

(Oleg) Maybe loading of threads is good start, initially without drafts and contact info, next step to "enrich" threads

(Julien) Yes maybe you're right, we could work like this

(Oleg) So we can create bugs for these steps and spread 4 points between them :)

(Steve) So all 4 points for loading threads(not including drafts/contacts)?

(Julien) I think the 4 points will be easily taken by doing all the work even excluding drafts/contacts; I could create a bug for the mozMobileMessaging wrapper.

(Steve) Yeah that might have some dependency for loading

(Oleg) Yeah, that maybe true

Story: IndexedDB in Gaia

Not in this sprint.