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

This is the Sprint Planning for the first sprint for the Gaia SMS subteam. SMS issues handled by the SMS subteam (blocks the sprint bug)

ID Assigned to Summary Blocking b2g Whiteboard
871432 Steve Chung [:steveck] [sms][mms] display the received time inside the sms/mms box --- [p=2]
881469 Julien Wajsberg [:julienw] [MMS] Implement Navigation object --- [p=3][comms-triaged]
963013 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Messages][Refresh] Update bubbles style and layout of the thread. --- [p=1]
980461 Oleg Zasypkin [:azasypkin][⏰UTC+1] [MMS] Visual adjustments to attachment download indicator --- [p=1]
1003384 Oleg Zasypkin [:azasypkin][⏰UTC+1] [B2G][1.4][SMS] - The phone type "Other" is not translated in any of the languages when suggested contacts are shown in SMS 1.4+ [p=1] LocRun1.4
1008823 Oleg Zasypkin [:azasypkin][⏰UTC+1] [Messages] Don't use activity to send message via "Send Message" action from unknown number context menu --- [p=1]
1010301 Oleg Zasypkin [:azasypkin][⏰UTC+1] [B2G]][Messaging App] Spinning icon when sending an sms and mms is not displayed --- [p=1][not-part-of-initial-sprint]

7 Total; 0 Open (0%); 5 Resolved (71.43%); 2 Verified (28.57%);

Informal decisions

  • Minimal number of points for a bug is 1
  • a bug that will be worked on (even if there is a r+ patch already) is included in the sprint


<julienw> I've set up the various lists in
<julienw> do you agree with the goal of 9 points for us 3 ?
<schung> I think we could try 9 points for this sprint first
<azasypkin> yep
<azasypkin> it's hard to say for sure at the first sprint planning :)
<julienw> yes :)
<julienw> so azasypkin and I already added 3 bugs; 2 of them are not in any list
<julienw> one will be really quick as the patch is already there and reviewed though
<azasypkin> julienw, yeah, what point value we should set for it in such case?
<julienw> the other one is the navigation patch, david insists on finishing it, that's why I included it on the list, is it fine for you ?
<julienw> azasypkin, if we stick to the rule of "not less than 1 point", then it's 1
<julienw> it will possibly balance with another bug that will take more than expected
<azasypkin> ok
<julienw> does that make sense ?
<azasypkin> yes
<schung> ok
<julienw> about bug 1003384 ( -- 'Other' is not translated correcty in the contact suggestions list)
<julienw> how many points do you think ?
<julienw> state is: one review has already be done
<julienw> so the next review will hopefully be the last one as it's not a big patch
<azasypkin> julienw, it depends, do you like me to fix carrier label?
<azasypkin> see my last comment
<julienw> nope
<julienw> other bug, you're right :)
<azasypkin> nice :) then it's reviewed by you, the second patch is just to change 'Other' to 'other'
<azasypkin> it's already attached
<azasypkin> I mean the one for master
<julienw> right, I already did a r+
<julienw> so I guess it' s a p=1 too ?
<azasypkin> yes 0..1 :)
<julienw> okay
<julienw> schung, ok for you ?
<schung> another bug for carrier +1
<julienw> oki great !
<schung> so we can close this one first
<julienw> so you think we should do a p=0 for this one?
<schung> hmm... not sure if  we can put p=0 for a bug...
<julienw> oki so let's keep p=1
<julienw> it will be an easy point for this sprint's velocity
<julienw> will compensate the next one :) bug 881469 ( -- Implement Navigation Object)
<julienw> I think I'll add a "[technical debt]" on such bugs, so that we  can pick one or two of them during each sprint too
<julienw> if this looks good for you
<julienw> current status is: I think I fixed the last bugs I was seeing, I need to test again on the device, clean up some //TODO, and request a first review
<julienw> I expect the review to take time too
<julienw> because it's quite big
<azasypkin> works for me, yeah this patch is more than just tech debt
<julienw> I'll let you think of this until we give points
<schung> Maybe we can judge it after you provide the patch?
<julienw> we need to give points now :)
<julienw> but you can already have a look to the patch
<julienw> is updated from last thursday
<julienw> I think the first review for such a patch takes about 3 hours :o)
<julienw> if not more
<schung> I think 2~3 points for that is reasonable
<julienw> azasypkin, what's your thought ?
<julienw> I'd say 3 points
<azasypkin> I think 3 is closer to reality
<julienw> do you think more ?
<schung> more is safe :p
<julienw> I mean, more points ?
<julienw> would 5 points bee too many points ?
<schung> 5 seems a little bit too much since the patch is already there
<julienw> ok, so everybody agrees on p=3? azasypkin ?
<azasypkin> ok, let's try with 3 and see how it goes
<julienw> so we have 4 points left
<julienw> maybe we can add one more because we have 2 points that are really small ;)
<julienw> if we take back the list in
<julienw> there is one issue in 1.3t? : bug 1008071 ( -- Sometimes attaching a Gallery image will cause Messages app to be killed (not Low Memory Killer))
<julienw> I expect this bug to move to another component
<julienw> so I think we should not take it in the sprint; if we need to do it it would go in the 3-point margin we have
<julienw> does that make sense for you ?
<julienw> (and it's not a blocker yet)
<azasypkin> totally, it's not clear what to do here to put it to the plan
<azasypkin> I thought that we can plan only bugs with more or less known solution 
<azasypkin> unless it's for investigation
<schung> +1, should we put it in this sprint?
<julienw> I think we should not
<julienw> moving forward then ?
<azasypkin> 2.0+ then
<julienw> david says that visual refresh bugs are more urgent than 2.0+ bugs
<azasypkin> ah
<schung> ok
<julienw> maybe except bug 891344 ( -- display "device space low" warning) that will have l10n changes
<julienw> david's rationale is that we'll have a lot of weeks to do 2.0+ bugs after the branching but we won't be able to do features
<julienw> I'm not sure I completely agree ;)
<julienw> so what do you think ?
<azasypkin> hmm, regarding to bug 891344, did you decide to show one notification on start up + make generic "low storage" notification more detailed? 
<azasypkin> *on SMS app startup*
<julienw> Omega provided clear UX here:
<azasypkin> julienw, yes, but what about case we run app with sufficient space?
<azasypkin> but later it'll change
<azasypkin> I mean do need to listen for smth ?
<azasypkin> *do we need*
<julienw> good question
<julienw> seems there is a "change" event on device storage
<schung> cool~ 
<schung> I haven't used that before 
<julienw> neither did i :)
<azasypkin> do we need to track only "navigator.getDeviceStorage('apps');" storage?
<julienw> I don't know :o)
<azasypkin> :)
<julienw> so, should we take this in the sprint?
<schung> Apparently  we will need more time on this
<julienw> or should someone take the time to investigate this sprint
<julienw> so that we take it next sprint?
<azasypkin> I can investigate this
<schung> I could investigate this
<azasypkin> cool )
<julienw> ahah
<julienw> choose :)
<azasypkin> I guess Steve will make it faster than me :)
<julienw> only investigating, no code, no patch? Or do you think we can finish this this sprint?
<schung> will, basically I only got one visual refresh item for now, so I have some time for this
<julienw> schung, I see 3 visual refresh items
<julienw> with you as assignee
<julienw> bug 990537 for dsds (
<julienw> bug 871432 for putting the time in the bubble (
<julienw> bug 963109 ( -- multi recipient view should have a back button) (but it's blocked by 881469.. so it's another reason to finish bug 881469 now BTW)
<julienw> I'm fine if you unassign with some of them :)
<schung> Oh, for the DSDS, I might unassign it for now and set dependency for other refresh bug
<julienw> good for me !
<julienw> so back to bug 891344; should we take it for this sprint?
<julienw> (I think we should)
<schung> Before assigning this, I think we might need 2~3 points on that
<schung> To close this one completely
<julienw> yep, I agree
<azasypkin> how many points left then?
<schung> so,is it ok to make total points over 9 points(a lot)?
<julienw> we  can maybe do 10 points but not more
<julienw> so, we can say p=3 on bug 891344, but agree we won't do all these 3 points on this sprint?
<julienw> like 2 points in this sprint, 1 on next sprint?
<julienw> would that work?
<schung> well, it seems a little bit complicate for this system...
<julienw> I want to show that you'll spend time on this on this sprint, because it will take from other work
<julienw> or we say we don't take it at all
<julienw> and you investigate on the "efficiency" margin
<julienw> and at the end of the sprint we'll look whether we were right :)
<azasypkin> how should be deal with bugs that can't fit into the sprint (not meta), should we just reevaluate p value at the next sprint planning?
<julienw> if a bug is too big for a sprint, I think it should just be split
<azasypkin> Like p=1 to investigate and p=2 to fix?
<julienw>  (here it's different, we don't want to spend too much time on it because of visaul refresh is more important
<schung> yap we should split into other bugs
<julienw> so, bug 891344 ? what do we do about it ?
<julienw> keep it for next time ?
<julienw> also, we have only 2 sprints to finish the visual refresh
<julienw> I can still put p=3 on bug 891344 because after all we decided the points, but without taking it
<schung> I think maybe we should just focus on visual in this sprint
<julienw> good for me
<julienw> so back to 5 points left for visual ?
<julienw> (I'm trying to move forward because we spent like 25 minutes on bug 891344 :) )
<azasypkin> :) Ok, what we have for VR
<schung> sure
<julienw> last thing on bug 891344: is p=3 fine for all of you? (so that these 25 minutes are not lost ;) )
<azasypkin> agree
<schung> +1 
<julienw> oki great
<julienw> for VR
<julienw> I don't understand joan's answer in bug 963013 ( -- thread visual refresh)
<julienw> here is the full list for messaging:
<julienw> we can definitely take bug 980461 ( -- "download" button visual refresh) which is pending a review from me
<julienw> (sorry ;) )
<azasypkin> julienw, np :)
<julienw> it would be a p=1 ?
<azasypkin> yes
<azasypkin> p=1 or if you're ok with the patch, then we can just land it
<julienw> I haven't looked at it yet :(
<julienw> probably will be a no brainer
<azasypkin> it's simple we just need to agree in which patch to do your suggested nit :)
<julienw> I agreed with your comment when I read it (so do the space issue in the other bug)
<julienw> just did not comment
<azasypkin> great! Back to bug 963013 - I think it's quite important for us
<azasypkin> but I also didn't get what Joan meant
<julienw> let's do p=1 on the attachment download indicator then, hopefully not taking too many bugs according to velocity will help us having less pending bugs next time
<azasypkin> sure
<julienw> bug 963013: I think Joan's answer is how we do the bubbles in the thread
<julienw> header == the date
<schung> Not sure my bug 871432 ( -- display time in the message bubble) will conflict with his work
<julienw> currently, one logical block "header + bubbles" is like "<header></header><div threads-container><thread1><thread2></div>"
<julienw> and he says that there should be another div block around these
<julienw> we did it in the thread list inbox too
<julienw> schung, yeah I was thinking of this too
<julienw> schung, but probably not so much, if the style changes are in the building blocks only
<schung> If he is only working on BB styling I think it's no conflict 
<schung> But the problem is I'm not sure about how deep they will involved in the app
<julienw> bug 951672 ( -- meta thread visual refresh) is where the BB changes will be, I guess ?
<julienw> or maybe not
<julienw> I think we should take bug  963013 in the sprint
<julienw> even if it's not very clear
<azasypkin> anyway we don't have any other unassigned VR bugs except small bug 996889 ( -- add a new icon for attachment). So let's pull bug 963013 in the sprint
<julienw> and how many points ?
<julienw> I'd say at least 2 because of the uncertainness
<julienw> uncertainty
<julienw> we also need to take bug 871432 in the sprint
<schung> 2 is ok for me
<schung> I also set p=2 in bug 871432 
<julienw> azasypkin, is p=2 for bug 963013 ok for you ?
<azasypkin> julienw, yep
<julienw> p=2 for 871432 works for me too
<julienw> azasypkin, for you too ?
<azasypkin> yes
<julienw> ok, then it's finished !
<julienw> 10 points for this sprint
<julienw> (with 3 easy ones ;) )
<schung> \0/
<julienw> ideally we should finish early so that we can record demos
<julienw> we can also record demos out of WIP patches
<julienw> but we need demos ! :)
<azasypkin> :)
<julienw> ok I'll copy paste this in the wiki later today (I need to go now) 
<julienw> try to think also whether the IRC format was good or not
<julienw> see you later and thanks !
<azasypkin> see you, thanks!
<schung> thank you too!