Gaia/SMS/Scrum/2.2S5/Planning

Sprint is from 27 Jan -> 9 Feb (called 2.2S5) (2 weeks)
Velocity: [p=6] (normal is 10)

(Julien) I'll be there full-speed, I think Oleg has 1 week off for ideation; what about you Steve?

(Steve) Not sure how much time will spend on my group, because we already give a pitch with simple prototype. But I think maybe I can put ~70% time on message/CMAS

(Julien) OK so maybe 6 points instead of 7. (I removed 3 points for Oleg already).

Focus for this sprint is feature-b2g, which are all perf-related.

(Oleg) And I see at least one RTL issue with feature-b2g flag

(Julien) oops I wanted to say blocker, but if we have a RTL issue maybe we should take it still. Francisco told me that maybe RTL will soon be the most important topic for us because of an incoming partner.

(Steve) yep,that's what I heard as well, but I think we solved most of RTL issues last month?

(Julien) yep, we just found one recent regression. Not sure it's _really_ urgent but it's a blocker we should consider for inclusion in the sprint.

(Oleg) + this one "Bug 1120018 - [RTL][Messages] Latin characters and numbers are right-aligned on input field" that is feature-b2g-2.2+.

(Julien) Just added it in the "feature" section below. We can decide to take it before 2.2 blockers if you want.

from current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1112131 [p=1]
Bug 1112131 - [header] Propose a start and end attributes to hint the component about the left and right offsets

(Julien) patch by Wilson, review by me, should land either today or tomorrow. I don't think we should include in the sprint because work is done by another team. (but review by me ?)

(Oleg) I'd say it's your call, depending on how much time it takes to review :)

(Steve) maybe 1 point for you review?

(Julien) I think we can skip, I doubt I'd need 1 point to finish the review, more like 0.25 points ;)

(Julien) that said, I already know we'll have some more follow-ups that I'll likely review, so maybe 1 point can be good to account for all of them.

(Oleg) Sounds good for me

https://bugzilla.mozilla.org/show_bug.cgi?id=1089920 [p=1]
Bug 1089920 - [Messages] Investigate and fix the gaia-header in Messages app

(Julien) patch is ready, I'll only need a review from one of you when bug 1112131 lands.

(Oleg) Is it 3rd WIP?

(Julien) nope, first :)

(Oleg) Is gaia-header part of this patch will be in the scope of this patch then?

(Steve) Does these changes need tests?

(Julien) I added tests in the first WIP already (the other patches should be ignored, I didn't obsolete them because I wanted to see them easily but I'll do soon)

(Julien) Oleg: no, I think we'll land the gaia-header part separately in bug 1112131. It's here for convenience mainly.

(Oleg) Okay, then it looks like p=1?

(Julien) I think it is too.

(Steve) p=1

https://bugzilla.mozilla.org/show_bug.cgi?id=1087981 [skip]
Bug 1087981 - [Message] Lazy init settings in notify.js

(Julien) r+ but waiting for a last question from Steve.

(Julien) I'd say to skip it from the sprint if Steve agrees to keep the same approach ;) p=1 if I need to change the logic.

(Steve) skip+1. replying on the github

https://bugzilla.mozilla.org/show_bug.cgi?id=1089154 [p=1]
Bug 1089154 - [Messages] investigate scoping CSS rules

(Julien) Steve we need your insight here; what have you found and do you think we should take it given the performance impact you saw?

(Steve) From the selector(in shared) replace we can still see the small improvement. I'm working on the selectors in messages and one more point should be enough. Or selector refine for shared and scope for message?

(Julien) I don't understand the last question :)

(Steve) I mean, still apply css scoping like your first patch, or we just refine the selector(or doing both)?

(Julien) I don't think CSS scoping can solve all problems here. I'd rather fix the BB if we can :)

(Steve) Got it, 1 point for this is fine

(Oleg) p=1 then

(Julien) same for me, hope it's not too small ;)

https://bugzilla.mozilla.org/show_bug.cgi?id=1118214 [skip]
Bug 1118214 - [Messages] Investigate how we can make shared/js/date_time_helper.js more performant at executing time

(Julien) I'd say to skip it, likely a too small impact

(Oleg) Agree

https://bugzilla.mozilla.org/show_bug.cgi?id=1087329 [p=1]
Bug 1087329 - [messages] More perf improvements

(Julien) other ideas: tuning the readahead.

(Julien) During the night I got an idea about "async" scripts too, I'd like to experiment (but maybe in background). Doing something like Google (loading a synchronous script to take into account the loading of other async scripts and only then kick off the startup). Will experiment a bit.

(Steve) So 1 more point for experiment?

(Julien) yes, good idea, let's "point box" this :)

(Oleg) Yep!

https://bugzilla.mozilla.org/show_bug.cgi?id=1091511 [skip]
Bug 1091511 - [Flame][v2.1][Message]The number/email or URL can't be tapped if there is full-width text in this message.

(Julien) ready to land, I think?

(Oleg) Yeah, should be ready to land

(Steve) yep, will land it today

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1125601 [2.1+] [skip]
Bug 1125601 - [Messages] It's impossible to immediately navigate to Thread or Composer once app is loaded

(Oleg) When I was trying to reproduce I had a feeling that this problem is outside of Messages, but maybe I'm wrong. Soo I'd skip and use blocker points once regression-window is provided as it's unclear what should be fixed and how much time it'll take.

(Julien) I don't think it's outside of Messages but ok to use blocker points.

https://bugzilla.mozilla.org/show_bug.cgi?id=1124944 [2.2+] Bug 1124944 - [Messages] Messages app opens as a blank screen when opened as a share activity multiple times

(Julien) I think we should disable some menu that triggers some activities (pick should be ok, but others are not) when we're in an activity. Let's see what Jenny will tell us.

(Steve) So skip it first or still count it in?

(Julien) I think we can take it, assuming we'll remove the activity triggering items. If the assumption is wrong, we'll do something else ;) Unless you think it's less important than the RTL issue we have below.

(Steve) Not sure if hiding header action is enough, maybe we'll need to disable more

(Julien) in group view too, I'd say. But it should be easy to find with ones are triggering activities and then decide which ones we want to cut.

(Julien) let's estimate the RTL bug and come back here if we have points left.

https://bugzilla.mozilla.org/show_bug.cgi?id=1125369 [2.2+] [skip]
Bug 1125369 - [Messages][Edit] Users can prompt the delete confirmation screen multiple times at once

(Oleg) Looks like it's going to be handled outside of messages team, but Julien is reviewing. Does it still fit into your p=1 for reviews?

(Steve) 1 for review +1

(Julien) I think it will be very small so let's skip it. It goes into the 30% we remove from velocity ;)

features

https://bugzilla.mozilla.org/show_bug.cgi?id=1120018 [p=2]
Bug 1120018 - [RTL][Messages] Latin characters and numbers are right-aligned on input field

(Steve) If we only need to change dir="auto", maybe 1 point is enough. But not sure if it's sufficient for all the cases

(Oleg) I'm wondering if the same rule should be applied for subject and recipient input as well as all these fields should behave in the same way

(Julien) I think we have another bug for subject (and maybe recipient is already like this?), but otherwise yep.

(Oleg) Looking.. but can't remember any. Didn't find. So if we want to cover all cases I think it may be more than 1 point, likely 2. I remember we had some magic (I mean some bugs in contenteditable & RTL that we tried to overcome with text-align and friends) with contenteditable inputs.

(Julien) Can't find either. I think the only magic was dir=auto? :) but ok for p=2 because it's not really easy.

(Steve) Agree that p=2, I think it would be more complicate considering the recipients

(Oleg) And another question, will it be consistent with other inputs in certified apps. I remember we reversed header for RTL :) And then to be consistent with apps that didn't do it returned it back :)

(Julien) it should :) actually the header was handled in the component, but we did change the slide direction and had to revert this. If you have doubt about other cases maybe ask Stephany.

(Oleg) Yeah, will just ask about it.

(Julien) so p=2 ? :) Yep

(Julien) so no points left !