Gaia/SMS/Scrum/2.1S1/Planning

Minutes

Planned velocity: 12

(Julien) Is it ok for you? Since Steve is back full-time we can add 2 points to previous sprint's velocity. Is any of you taking holidays in the coming sprint ? :)

(Oleg) no any holidays

(Steve) Nope, but I wish no more 1.3t blockers in next sprint :p

(Julien) this velocity keeps about 3 or 4 points for unexpected blockers; a full sprint for us is about 16 points, I think (it's a rough estimation :) )

from current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=944249 [P=2]

• completely move the send button/character counter/message type handling to compose.js
• what's left: is: use event_dispatcher, some other minor changes, and reviews + follow-ups

  (Oleg) I'd say still not less than p=2

  (Julien) p=2 was also my thought.

  (Steve) Considering the scale of the changes, p=2 for me even if the patch is ready for review

  (Julien) the patch is not ready fo review, but the remaining work is not big until the first review.

https://bugzilla.mozilla.org/show_bug.cgi?id=1035279 [P=1]

• error_dialog.js refactoring
• what's left is: really decide what we want to do

  (Oleg) In any case it shouldn't be more than p=1. As far as I remember the patch is mostly reviewed, the main question is to use or not constants, if we decide to remove it - it's quite easy.

  (Julien) given the patch has already been reviewed once, I think p=1 is fine too.

  (Steve)This patch looks close, so p=1 for me

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1038176 [P=2]

• Launch Latency for v2.0
• we still hope this is a Gecko issue

  (Oleg) I'm doubt who will fix that, so maybe we can't take it to the sprint due to uncertainty?

  (Julien) you can look at it in 2 ways. Either we don't take it, and if we have to do it, we'll do it out of the sprint, because it's a 2.0 blocker. Or we take it, and if we don't have to do it, we'll have free time. :)

  (Oleg) But looking at it I can't even estimate the work :) Not sure what is the main reason

  (Julien) we have a lot more JS files since v1.3, so that may be part of the reason. We can maybe lazyload some js files already (eg: information.js, and other things not directly needed at the start).

  (Oleg) I mean if we take it to the sprint and use main velocity points for it, let's define what we're going to do, like lazy loading or smth. So to understand what to expect in the end.

  (Julien) Yep. It's certainly not bad to add some lazy loading. So maybe we can do some limited and safe lazy loading in this bug. We'll still need to help gecko engineers too, but that's difficult to estimate.

  (Oleg) Ok, so actionable item is to figure out what files can be lazy loaded and make it lazy. There is no any uncertainty here then :)

  (Julien) could be a good idea to move this to a separate bug and make it block this bug.

  (Oleg) yeah, the best option

  (Julien) estimation: 2 or 3; I'm afraid of complications with the various starting points we have (activities, system messages...)

  (Oleg) Have we done something like this already? I mean lazy loading of files. I see this for desktop-only files.

  (Julien) we did it in v1.2 and then reverted to the old behavior in v1.3. I wrote some history in https://bugzilla.mozilla.org/show_bug.cgi?id=1040020#c9 :) But it was not done correctly: we were lazy loading everything in the "onload" event. Here I think we need to lazy load only _some_ files, so that we don't wait for it to show the interface and load the threads.

  (Steve) yap, we did this before, but the visible time will dealy if we use lazyloader. I could understand that putting some files for lazyloader, maybe I can try this later(like settings/attachment menu/waitscreen/...), But I also concern how much it could be improved only with few js files.

  (Julien) "git diff v1.3..v2.0 apps/sms/index.html" to see the new JS files

  (Oleg) do we still load several files in "release" mode?

  (Julien) no, they're all concatenated and minified, but it still takes time. Another possibility is that the "init" takes time?

  (Oleg) I'd rather compare size of concatenated and minified file for 1.3 and 2.0 first then, since I suspect some new files are just extractions from other.

  (Julien) since we're on the device, I'll argue that the size is not really an issue in the end; I've heard the initial cost of loading the zip file in memory takes time (that's why minification is good (need to check something) (ok, all the unminified files are still in the zip file actually)).

  (Steve) I've heard the loading time could be reduced for few hundred ms after minified

  (Oleg) do partners test on "release" minified version?

  (Julien) yes, at least I really hope so !

  (Julien) a partner tried removing js files from SMS: https://bugzilla.mozilla.org/show_bug.cgi?id=1040020#c8 we can see the load time is linear to the number of files. I think the parsing time is important too.

  (Oleg) That's why I'm wondering whether he used dev version

  (Steve) It's possible that effect of loading the less files might not efficient in release build

  (Julien) I just asked him on the bug.

  (Oleg) Soo, we probably need to measure first with very draft solution and in release mode. Like Doug made sometime ago by removing all css rules to measure the best case :)

  (Julien) so what do we do with this bug in the end ? :) can we "invest" some points without really estimating? Then the time we'll take on this bug will both take invested points and blocker points if necessary?

  (Oleg) I think yes

  (Steve) I suggest that we take 1 point for investigation in this sprint, and re-estimate in next sprint(if we really want to take ome action in gaia side)

  (Julien) if we need to do things in Gaia we'll need to do it in this sprint; but this can be in "blocker points". Still I think p=2 is safer here.

  (Steve) Ok for me (for 2 points)

  (Julien) Oleg ?

  (Oleg) Ok let's keep p=2 and estimate next bugs and see if we have room for it in sprint velocity points

nominations

https://bugzilla.mozilla.org/show_bug.cgi?id=1037661 [P=2]

• MMS is discarded when we press "home" while resizing
• Steve's current idea is to save drafts more aggressively

  (Should I take it back from Salva? I didn't do it because other 1.3t issue, but I'm not sure if we should let him handle it)

  (Julien) I assigned it back to you ;) But if you're too busy someone else can take it. I think it's too complicated for Salva though.

  (Julien) estimation: p=2 if we don't try to save invalid recipients.

  (Oleg) p=2.

  (Steve) I feel p=2 is safer

https://bugzilla.mozilla.org/show_bug.cgi?id=1041779 [OUT]

• BB regression, but it looks easy to override. should we take it?

  (Oleg) Since Arnau provided patch, I think we shouldn't. It's ok to review it using time planned for unexpected things.

  (Julien) yep

  (out of the sprint then)

features for v2.1

(Steve) Does product or UX has their own priority for these feature?(Or should we considering their preference)

(Julien) Here I took the "feature-b2g:2.1" bugs that were ready; so it's definitely a priority for product. The earlier we finish them, the more we can do other things without being bugged :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1026685 [OUT]

• CMAS work
• we need to separate the tasks in separate bugs
• work in this sprint could be to do some exploration and define the subtasks
• define the questions for things we don't know (how to display the message? attention screen? separate app ?)
• invest 2 points?

  (Steve) Do we need to handle the alert message in message app? This behavior seems more close to cell broadcast.

  (Julien) I don't know how cell broadcast work. Is it in the System app? Is it a separate app?

  (Oleg) Don't have idea about this, never seen on my phone (android and ios) such thing :) T-Mobile, O2, MTS

  (Steve) Moving this to next sprint? I could spend more time with Jenny and gecko about how we need to deal with

  (Julien) it's really a lot of work that's why I wanted to start now, at least start experimenting.

  (Oleg) That would be nice to have steps to simulate such messages first, then we can experiment +1

  (Julien) cell broadcast seems to be in the System app currently. If we do this it should be in a separate app IMO. There may be UX issues in having a separate app.

  (Steve) Yes ,it is

  (Julien) we may discuss with Wilfred why it's in the Comms team...

  (Oleg) Good first step IMO

  (Julien) ok, let's keep it out of the sprint for now, and discuss with Wilfred and others to understnd better what's needed. I can take this action and then Steve can discuss with Gecko maybe.

https://bugzilla.mozilla.org/show_bug.cgi?id=1026694 [P=1]

• move the attach button from header to the composer
• should be quite easy to do now that we use a flexible layout

  (Oleg) Agree that it should be easy, looks like p=1

  (Julien) p=1 for me as well

  (Steve) p=1 as well

https://bugzilla.mozilla.org/show_bug.cgi?id=1003843 [P=1]

• show the number of recipients for group mms
• does not look very difficult

  (Julien) estimation: p=1

  (Oleg) p=1

  (Steve) p=1

https://bugzilla.mozilla.org/show_bug.cgi?id=1015841 [P=2]

• reduce the size of the recipient panel when we have only one line of recipients
• main difficulty: prevent synchronous reflow

  (Oleg) I'd say p=2, it's complex beast something can go wrong :)

  (Julien) p=2 because it looks easy but uncertain

  (Steve) Considering the uncertainty of the solution, p=2 is safer

haida work

https://bugzilla.mozilla.org/show_bug.cgi?id=1041124 [OUT]

• Remove dependency to UI components from MessageManager, also prerequisite work for DS.

  (Oleg) There is a patch already, but since it's not really small I'd say still p=2. I've just attached patch for you to quickly observe...

  (Julien) it's BIG :)

  (Oleg) Unit test part is big, yeah :)

  (Julien) even the code; I think this can be split in separate bugs in the end. Currently, if I need to estimate it, I'd say it's like my Compose patch, so p=5 ;) What's the state of the current patch? Ready? nearly ready? WIP?

  (Oleg) Ready, I'm testing it on device. It's not so big as it may seem :)

  (Steve) I would say p=3 for this one, it's not been reviewed yet

  (Julien) same for me; and we don't have enough points for this. We have 1 point left, so maybe better to take the next one instead? And keep this bug if we have time in the end?

  (Oleg) I don't mind, anyway I was planning to do it in background at first :)

  (Julien) TBH I'd rather take this one than other 2.1 refresh features (as it's more risky, better to do it earlier) but also once we do the refresh stuff we don't care later and we still have time to do this after. We definitely need to take and finish next sprint though, so that we have time to find possible regressions.

https://bugzilla.mozilla.org/show_bug.cgi?id=1011089

• set hash when navigating panels
• probably one of the easiest haida work

  (Julien) estimate this? or should we keep the point for the blockers or launch latency bug?

  (Steve) I'm fine with leaving it for blocker;

  (Oleg) I'd rather leave point for blocker and I'm not sure about "restore panels from hash" part in this bug, is that really easy?

  (Julien) "restore panels from hash" should be already working. But it was not really tested ;)

  (Julien) I think this bug is easy but would be more than 1 point for uncertainty; so let's keep the remaining point for blockers and performance issues. I'm adding 1 point to the 2.0 blocker performance estimation then?

  (Oleg) is it somewhat different if we just reduce main velocity to 11 instead of 12?

  (Julien) not really different, I don't mind. Let's do this then :)