Gaia/SMS/Scrum/2.1S2/Planning

From MozillaWiki
< Gaia‎ | SMS‎ | Scrum‎ | 2.1S2
Jump to: navigation, search

Minutes

(Julien) any holidays until 18th August? 15th is a holiday in France. I am in holidays starting 20th August until 12th September.
(Oleg) no any holidays in August, at least in this sprint :)

=> velocity=11 again ?

(Oleg) I'm for 11

from current sprint

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

  • use event dispatcher in MessageManager
  • not much left
    (Julien) Oleg, what's left here? It's already the 2nd review right ?
    (Oleg) Yes, it's waiting for 2nd review
    (Julien) since we agreed on most things, I'd say p=1 is fine here?
    (Oleg) yes p=1
    (Steve) p=1 +1

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

  • the back button is stayed pressed
  • should be finished soon
  • note: real fix is to (1) separate proper panels report and group; (2) have proper headers for these panels
    (Oleg) regarding to real fix - yes, but not for v2.0 probably, v2.1 - do we plan to divide these panels soon?
    (Julien) probably v2.2 ;) I don't know if we have a bug already. https://bugzilla.mozilla.org/show_bug.cgi?id=961572 is related
    (Julien) let's stick to the subject, my fault :)
    (Oleg) ok, "hover" fix for now then :) But I'm always glad to divide these panels
    (Julien) estimation is: p=1 for this simple fix (unless it's already reviewed? :) )
    (Oleg) p=1 if not reviewed :)
    (Steve) I haven’t tried it yet, so p=1 :p (of courser not for the dividing panel one) (of course :) )

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

  • Add this not because me might face some memory leak in original thumbnail creation.
    (Julien) in feedback phase. Steve, what's left here?
    (Steve) Only some test to add later, so p=1 if the solution is confirmed, but if you have more idea about the solution, I could take more time for it.
    (Oleg) IMO looks like more than p=1, p=2
    (Julien) subtasks maybe ? :)
    (Steve) One for f+ on solution and one for final review +?
    (Julien) so it's more p=2 to me; maybe a small 2, but still 2 :) if we count both review time + unit tests + possible follow ups + manual tests (then it can reach p=3 :D) (one subtask is not necessary 1, it can be .5 or less)
    (Steve) Well I'm not sure google's chart API could present .5 :p
    (Oleg) In this sprint we don't use 0.5 for burdown anyway :)
    (Julien) don't let yourself abused by technical issues :) we can scale the graph by *2 :p or just don't represent this on the burndown. We don't do this for this sprint anyway. Right now it's only a help to estimate and understand better what's left.
    (Julien) so, p=1 or p=2? In the end, if we use 2, we can also add some more bugs to the sprint (the previous one is a small 1 too :) ).
    (Oleg) p=2, I think it needs careful review too that also takes time, but I'm not involved in the task, probably I'm wrong :)
    (Julien) Steve?
    (Steve) p=1 for me.
    (Julien) we need to converge ! is it p=1 because there is not much work left?
    (Steve) If the feedback is + already, I can confirm p=1
    (Julien) I haven't looked at the patches yet ;)
    (Steve) ok, I'm fine with p=2 and plan more carefully.

blockers

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

  • launch regression
  • QC blocker, supposed to be finished by thursday. (I'm laughing) (I warned Bhavana that it won't be finished, but still, it's the most important thing we have now)
  • not sure what we can do now. suggestions?
    • facebook lib, shadow+radius styles
  • Style changes [P=2]
    • (Oleg) If images, border-shadow\radius affect performance greatly, can we render it later? Even with fading in effect :)
      (Julien) we can file a separate bug to investigate style changes.
      (Oleg) yeah that would be nice to have, we'll need this anyway for new thread view. I mean investigating performance impact of CSS effects.
      (Julien) So, can we try to estimate this? Changing styles, see how we can improve rendering, make Jenny agree with it :)
      (Steve) p=1 for this part
      (Oleg) Well subtasks are following I think:
      • Investigate whether removing image/css effects gives us any significant benefit; Don't have much experience to correctly estimate this.
        (Julien) Do you have 2 similar devices?
        (Oleg) Yes, received second flame recently.
        (Julien) so best way is to have old version on one, new version on another, and compare with your eyes :p (and maybe with good logs using Date.now(), but for reflow/painting stuff it's not like this)
        (Oleg) Ok, some things I can check with my eyes
      • Confirm with Jenny first, if "Yes" for the first task :)
      • Implement "lazy" image loading/effects application; It doesn't sound bigger than p=2 for me
      (Steve) I think it worth p=2 or more for complete investigation
      (Julien) I'd take p=3 for this, but I can agree with 2 for the sprint (because we have the additional "blocker bug points" for this)
      (Oleg) Yeah, p=2 with blocker points in mind
    • any radical thought (like cache everything in localstorage or something)? Anything you'd like to try?
      (Steve) I've thought that we cache the first panel of thread list directly. But it means we need to update the list more carefully
      (Julien) you mean, because we cache things, we need to update the cache too? and so sometimes update the list after it's displayed?
      (Steve) yes, but we don’t have thread list update mechanism yet, so it seems not a reasonable way for 2.0
      (Julien) we have "updateThread" already :) and setContact for updating the contact information. What have you in mind that we don't have?
      (Steve) If we having a small IDB or simply a localstorage for 9 or 10 latest thread list.. That's means we need to update this cache every time when receiving/sending the message(or sync the thread list view with time interval?)
      (Julien) for this we can try to reuse asyncStorage; I'm worried of the time to display because of IDB but we need to try it. Should we file a separate bug for this then?
      (Steve) I think we should because it's like a new feature for me.
      (Julien) estimate for caching the first panel? Investigation can be a very rough test just to see if it makes things better :)
      (Julien) p=3 for this? Maybe we can subtask?
      (Steve) subtask this one would be better
      (Julien) here is my try:
      • store things in a storage on first time launching
      • use the storage when launching if available
      • update the storage + display, once first panel is displayed (try both requesting Gecko DB in parallel or in sequence and see which one works better)
      • update the storage when we receive/send message
      • clean up old threads in storage
      • unit tests
      • (miss anything?)
      (Steve) Do you think this should be in 2.0? Not sure if it's safe to land this feature in late 2.0
      (Julien) remember v1.3t ;) but yeah it sounds really risky. Maybe better to look at reducing impact of facebook lib if this is easier?
      (Steve) Yes, for 2.0 maybe styling issue is more urgent, but we could diffidently plane this in this sprint
      (Julien) I'd like to see if accessing only one DB to display first panel (instead of 4) can be quicker. What can we do to at least check this is a good path?
      (Steve) Yes I can spend some time on it. maybe p=1 for this issue?
      (Julien) p=1 to test this, and if it makes things really better? :)
      (Steve) Maybe pending all the request until first panel ready? But user will see some late update on panel...
      (Julien) another solution is to cache only the contacts?
      (Steve) contact that existed in thread? I think it's good to try, but the effect might not be very obvious considering the effort
      (Julien) well, a JS map threadId -> contact information, vs mozContacts lookup + possibly facebook lookup? :) The JS map for first panel (or even all threads) can be stored in asyncStorage. Of course we need to update it too, but I think we have oncontactchange events?
      (Steve) ya we also need to update the contact while oncontactchange event
      (Steve) So p=2 for contact cache?
      (Julien) let's do p=2 for testing first what happens when doing less IDB requests, and then doing more things depending on the investigation? This is really not clear but because it's a QC blocker...
      (Steve) ok for me, let' move on to the next issue :)
  • Minify Concat CSS [p=1]
    • (Steve) BTW, maybe we coud try css minified/concat at our own build time(if we want to reduce the launch time further)
      (Julien) separate bug for this then?
      (Steve) For sure, if we really want to try it out.
      (Julien) I think it's worth trying. Should be easy to just try a minified CSS for a start, and see how it goes.
      (Julien) p=1 for this?
      (Steve) Not sure if we will face any problem on build test, otherwise p=1 is good for me for adding some minify stuff in build time.
  • Reduce Facebook Lib Impact
    • Check that it really has impact
    • uses datastore only, maybe roughly check if it would be faster using IDB to access data (even false data)
      (Julien) I'd like to see if using datastore directly is slow.
(Oleg) How many points left after these QC blocker subtasks? :)
(Julien) 2, but I think we can remove bug 983172 for the sprint and then have 4.

nominations

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

  • issue when using window.alert with several windows for the same process (eg: inline activities)
  • window.alert stops some events, but Gecko does not stop always the event on the right window...
  • should be a bug out of Gaia::SMS
  • maybe we'll need to work around the issue but we can keep it for the sprint after
    (Steve) I think we faced this issue before... will check with alive later, and it's not sms issue for sure.
    (Julien) if you can check with Patrick Wang it's better (I NI him on the bug already). We faced a similar issue in the past, yep. I added lots of info in the bug already :)
    (Steve) Ya, I can talk to them about this issue face to face

features for v2.1

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

  • add an image for a groupmms thread in the inbox panel
  • if it's ready only
    (Oleg) Soo, it's not ready yet + doesn't sound like priority thing
    (Julien) yeah, does not sound risky, so the last sprint should be good enough
    (Oleg) Spec just arrived! :)

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

  • remove the "tap" handler in the "report" panel
  • should be really easy
    (Steve) Already have a patch for it ;) p=1 for me
    (Oleg) p=1 then :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1048362 [p=1 for actionable] [p=2 for subject]

  • composer panel refresh
  • some work to do, maybe not _completely_ actionable, but most of it is and I think the remaining questions will be resolved soon.
    (Oleg) mm, UI from first attachment from the comment 0 is different from proposed refresh from second attachment, looks like refresh will include "highlight actionable item" too, right? Or UX spec is just schematic? :)
    (Julien) UX spec is just UX :) "highlight actionable item" is what is committed, so maybe we can divide the task in commited vs uncommited.
    (Julien) most of it looks quite easy, right?
    (Oleg) Except subject field, markup change will be needed, it won't be in single container with message input anymore as I see.
    (Julien) yeah, except subject field, we can handle the subject field in a separate bug, it's not committed from my PoV.
    (Oleg) I'd rather start exactly from subject as the riskiest thing (probably involves changing our magic with composer height "calc" function):)
    (Julien) TBH I think the subject change should move to v2.2 :p we don't have time for this in this release (with blockers + haida we want to move forward).
    (Oleg) Ahhhh :) Ok, but except subject what should be done in this bug? Just background color change?
    (Julien) yes, + maybe other color changes (but I'm not sure) + don't focus when tap the green color
    (Julien) about subject: I'm not sure we need markup changes (I admit I don't know the new markup well either), but we'll need for sure additional CSS and testing and this takes time.
    (Julien) so, should we do the subject, or not?
    (Oleg) IMO almost all composer refresh is around subject, I'd rather try to do it.. I'm just afraid that just updating color will look a bit ugly.. need to check though
    (Julien) Steve? My view here is that the subject stuff is not needed, but the actionable stuff is needed.
    (Steve) Can't we separate the issue? We can focus on actionable item in this sprint
    (Julien) That's what I think too, esp with the QC blocker :/ Maybe we can do more at the end of the sprint, hopefully
    (Steve) So set the point for individual part?
    (Julien) 1 and 1 for me.
    (Oleg) 1 for color/actionable part and probably 2 for subject
    (Steve) 1 for actionable and 2 for subject
    (Julien) ok, let's do this. (1 and 2). You're estimating with small points IMO ;)

https://bugzilla.mozilla.org/show_bug.cgi?id=976091 [p=1]

  • DSDS visual refresh, including showing the SIM information in the bubble
  • I think we should land the sms-simulator first (https://github.com/julienw/gaia/compare/sms-simulator) so that it's easier to design in Firefox. I think the current version is good enough, no need to do more functional work for now, but needs a review of course :)
    (Oleg) sms-simulator doesn't block, it just nice to have :)
    (Julien) it does not block but it makes it a lot easier to work for DSDS! Alternative is to use it locally without landing (as I did in the past)
    (Oleg) Ok, I probably just used to use device with Web IDE :)
    (Julien) if it works for you it's fine ;)
    (Julien) estimation? p=1 for me
    (Steve) p=1 for me as well
    (Oleg) p=1

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

  • Thread view redesign
  • all questions not resolved yet, but is there some work we can already do, or should we wait for the final spec?
    (Steve) I think we could wait until every thing is clear and start from next sprint.
    (Julien) I think we should do at least the background color (because we'll do it in Composer as "highlight actionable item" action). But keep the rest of redesign for next sprint?
    (Steve) Sounds good to me
    (Julien) But also remember that risky things should be done earlier so that we have more time to fix regressions...
    (Oleg) Probably background change will happen in the scope of composer refresh (that we discussed above)?
    (Julien) I think so, yes. Then let's leave the other changes for either next sprint or v2.2?
    (Oleg) Yep, depending on UX input
    (Steve) +1

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

  • adding call button to the header of the single recipient thread
  • just needs small clarification from UX side
    (Julien) both non risky and non ready, it's safe to wait for next sprint
    (Julien) I think CMAS is more important than this
    (Oleg) Right
    (Steve) So pending to next sprint?
    (Julien) yep, unless we have time at the end of this sprint :)

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

  • CMAS Alert channel support
  • main question is: is the POC UX good enough? Will we be able to use it or will we need to integrate into system? Hopefully will be answered before the planning...
  • remaining work is:
    • check how it works with a simultaneous call + alarm
    • listen to CMAS alert
    • use the setting
    • probably ignore CMAS in the System app
    • make the code better + unit tests
    • land the task runner to /shared
    (Julien) remaining points for the sprint is.... 1 :) that's if we remove jpeg parsing bug and we don't take subject
    (Oleg) Then you can't say we use small points :) (I mean, in the sprint !) (Ahh, sorry)
    (Steve) I think we could try to verify if CMAS API is workable first... :p
    (Julien) good point; I can't test it here, maybe with emulator though?
    (Julien) I can integrate what Jenny told me earlier in the POC, discuss with Michael about notifications handling (we need silent notifications), and then I'll need to let you finish this because I'll be in holidays :p with 1 point I can check the first point (several attention screens in the same time), update following Jenny's comments, and make the code easier to take by you. Deal? Worst case is we do it all in System app...
    (Steve) Fine for me
    (Oleg) works for me too
    (Julien) then, let's close the meeting ! Remember the QC blocker is the most important right now (sadly)
    (Oleg) yep, thanks!
    (Steve) Thanl you all!!
    (Julien) let's do a sprint as beautiful as previous one !! :)
Retrieved from "https://wiki.mozilla.org/index.php?title=Gaia/SMS/Scrum/2.1S2/Planning&oldid=1002698"