Gaia/SMS/Scrum/FxOS-S3/Planning

Sprint is from July 2nd -> July 20th (called FxOS-S3) (2.5 weeks)

Velocity: [p=12]

PTO ?

Julien: July 14th is french holiday

Steve: No Holidays in this sprint

Oleg: don't have any PTO/Holidays in mind for this sprint

=> I roughly counted p=12 (12 days * 3 devs - 1 PTO) / 2 points * 0.7 (velocity)

From current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1169573 [p=2]
Bug 1169573 - [Messages][NG] Lay out Messaging service structure

(Steve) Patch submitted for some early feedback

(Julien) then how many point to finish ? 2 points ? I think it's fine if everything does not work properly at that moment either.

(Steve) I could expect it's not working unless we need address settings part. So p=2 works for me.

(Oleg) p=2 sounds good.

https://bugzilla.mozilla.org/show_bug.cgi?id=1169576 [p=3]
Bug 1169576 - [Messages][NG] Implement Conversation service: method for retrieving of all threads

(Oleg) Just wondering, should not it be blocked by "Bug 1179628 - [Messages][NG] Lay out Settings service structure"? Mmm, now I'm a bit confused: it sounds more like ConversationService related bug (don't remember what I had in mind when I was filing this bug)?

(Steve) I think we could do it parallel without blocking each other

(Julien ) I think we should focus on the main goal (loading inbox) and see what we need; we'll likely need the stream to retrieve threads from the API (until we have the DB, which we won't have really soon I guess)

(Oleg) We'll likely need bug for "drafts" part or we do this in the scope of this bug?

(Julien) if it's Conversation and not mozMessaging shim, then yes we'll need a bug for DraftsService too; and contacts too, right ?

(Oleg) Yeah, for drafts and contacts, also we already has mozMobileShim.getThreads stream I think.

(Julien) OK; so I think this depends on all these.

(Steve) I thought we will simply load draft DB in conversation service, and the draft service is mainly for draft save/delete. But maybe I misunderstood it

(Julien) mmm yes I think you're right Steve, that was the plan (also because the drafts information were supposed to be in the main DB :) )

(Oleg) right, so only Contacts shim is the blocker or maybe it's not a blocker at all, as the first step we can fill contacts from view controller like we do now?

(Steve) for the first step we might not need to consider the contact shim. We can have it later when we need to insert contact into DB/cache in conversation service.

(Julien) yes we can definitely do this way as a first step

(Oleg) \0/ it's actionable now! So what we need to do here, just query mozMobileMessage shim for threads and asyncStorage for drafts, join results and return?

(Julien) yep, but as a stream :) also wondering how we'll test such services. Do we need a bridge service test utility library ?

(Oleg) Hard to say right now, oh, and endpoints just landed - we need some time to migrate to it I think, it's better to do earlier than later.

(Julien) yep, I think so, especially we don't have much code yet. We just need to add ".listen();" to our existing services ?

(Steve) We might need it eventually, but not sure if it's a good time to do this

(Julien) it should be done in a separate bug for sure IMO. Steve BTW to be clear, Oleg is talking about the latest change to the threads.js library, and is talking about migrating to latest version of threads.js library which changes the API somewhat.

(Oleg) Yep, at least we need to upgrade ActivityShim and mozMobileMessageShim (and see if it still works :)) that are in master already

(Julien) and the empty ConversationService :) I think this would be a change to BridgeServiceMixin actually?

(Oleg) Ah yeah, sure - so we need separate bug for it for this sprint then.

(Julien) Yep, look below ----v (my ascii art skills are lacking)

(Oleg) Soo only 3 points left? Sounds like a good fit for this bug :)

(Steve) p=3 sounds good because it's not trivial task.

(Julien) agreed ! I'd especially like to see the code be used in both the old and the new architecture. But even if we don't land this during this sprint I'd consider the task "done" if we have something working even without landing. Don't know what you think ?

(Oleg) I think so, plugging nga to master is very nice to have, but not strict requirement IMO

(Steve)I think it's fine for just work, BTW do we want to do profiling in this issue?

(Julien) profiling, you mean performance profiling ? I think we'll regress for sure :D

(Steve) :D but just wondering if we could have enough information for analysis and figure out how to improve it.

(Julien) I think we're still too early for this.

http://bugzilla.mozilla.org/1179705
Bug 1179705 - upgrade to latest threads.js version [p=2]

(Julien) I'd say p=1 is enough for this

(Oleg) Yeah I think so (my main fear if it still works for service-client in one window).

(Julien) and Wilson is in holidays, I think. So worst case is we wait for his return :)

(Oleg) Yeah, he said all questions to :gmarty. So p=1.

(Steve) So we're not going to update shims in this bug?

(Oleg) I believe we should, I just hope that it won't take much time :)

(Julien) we need to update shims to work with the new library; best case is we just need to adjust to the new syntax and everything will still work like before; worst case is nothing works and we need to adjust. So maybe it's safer to have p=2 ? If we're in the best case we'll have free time :)

(Steve) yeah p=2 would be safer

https://bugzilla.mozilla.org/show_bug.cgi?id=1162030 [p=3]
Bug 1162030 - [Messages][NG] Figure out how navigation works

(Oleg) That one is important :), but hard to say how much time it needs, Julien what do you think about it?

(Julien) I think I need 1 point to have something working, 1 point for tests, 1 point to handle review -> 3 points overall. The current patch does "something" but is not working properly yet.

(Oleg) p=3 sounds good to me

(Steve) p=3 +1

https://bugzilla.mozilla.org/show_bug.cgi?id=1175503 [p=1]
Bug 1175503 - [Messages][NG] Get rid of direct ConversationView dependencies from Compose component

(Oleg) I want to slowly start separating NewMessageView from ConversationView, so would like to include 1-2 such bugs into upcoming sprints.

(Julien) I think this bug is fairly started so I'm fine including it. Missing is especially unit tests, right ?

(Oleg) I'd say I need 1 point for tests and 1 point to make sure it works for all cases.

(Julien) p=2 works for me too

(Steve) p=2

https://bugzilla.mozilla.org/show_bug.cgi?id=1178712 [skip]
Bug 1178712 - [Message]When we launch Message from a contact details view for the second time, device does not enter the compose view, but enters a view where there is only a title "message".

(Oleg) What do you think about this one? Should we include it or use "blocker" points to investigate further and fix if needed?

(Julien) IMO it's an edge case and I don't really want to include this in current sprints, we have a lot of work already :/

(Oleg) Okay

https://bugzilla.mozilla.org/show_bug.cgi?id=1179628 [p=1]
Bug 1179628 - [Messages][NG] Lay out Settings service structure

(Steve) Not sure if it's time to discuss this, but seems we forgot this part as first

(Julien) yep; not sure what we can remove to put this instead... I'd say we can remove the ConversationView dependencies bug for example, but not sure how Oleg feels about it :)

(Steve) I think we can only have some discussion about the shape of Settings service or shims, it seems not really urgent for now.

(Oleg) We can steal p=1 from split bug and 1 point I can get when I'm blocked during the sprint :)

(Julien) I think it's good to have 1 point here to at least discuss and possibly implement how to do this settings service.

(Oleg) okay

(Julien) ok let's try like this

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1149345 [2.5+] [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=1160049 [2.5+] [skip]
Bug 1160049 - [Messages] Attach menu should not dismiss when user cancel the replace attachment request

(Julien) let's skip again, not urgent, not risky

nominations

No nomination \o/