Gaia/SMS/Scrum/1/Planning
From MozillaWiki
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)
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!