Gaia/SMS/Scrum/1/Planning

This is the Sprint Planning for the first sprint for the Gaia SMS subteam.

http://mzl.la/1fUDBz9: SMS issues handled by the SMS subteam (blocks the sprint bug)

Full Query

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]	[Messages][Refresh] Update bubbles style and layout of the thread.	---	[p=1]
980461	Oleg Zasypkin [:azasypkin]	[MMS] Visual adjustments to attachment download indicator	---	[p=1]
1003384	Oleg Zasypkin [:azasypkin]	[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]	[Messages] Don't use activity to send message via "Send Message" action from unknown number context menu	---	[p=1]
1010301	Oleg Zasypkin [:azasypkin]	[B2G]][Messaging App] Spinning icon when sending an sms and mms is not displayed	---	[p=1][not-part-of-initial-sprint]

7 Total; 7 Open (100%); 0 Resolved (0%); 0 Verified (0%);

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

Minutes

<julienw> I've set up the various lists in https://wiki.mozilla.org/Gaia/SMS/Scrum#Sprint_Planning
<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 (https://bugzilla.mozilla.org/show_bug.cgi?id=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 (https://bugzilla.mozilla.org/show_bug.cgi?id=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> https://github.com/julienw/gaia/compare/881469-navigation-object 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 https://wiki.mozilla.org/Gaia/SMS/Scrum#Sprint_Planning
<julienw> there is one issue in 1.3t? : bug 1008071 (http://bugzil.la/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 (http://bugzil.la/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: https://bugzilla.mozilla.org/show_bug.cgi?id=891344#c29
<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> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/storage_watcher.js#L130
<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 (http://bugzil.la/990537)
<julienw> bug 871432 for putting the time in the bubble (http://bugzil.la/871432)
<julienw> bug 963109 (http://bugzil.la/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 (http://bugzil.la/963013 -- thread visual refresh)
<julienw> here is the full list for messaging: https://bugzilla.mozilla.org/buglist.cgi?bug_id=1008127%2C963109%2C985995%2C980461%2C963013%2C1003060%2C996889%2C990537%2C990518%2C871432%2C951682%2C963018%2C1003820%2C951672%2C881469&list_id=10162364
<julienw> we can definitely take bug 980461 (http://bugzil.la/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 (http://bugzil.la/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 (http://bugzil.la/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 (http://bugzil.la/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!