Gaia/SMS/Scrum/2.1S9/Planning

Sprint is from 12nov -> 25nov
Velocity: [p=7]

(Julien) won't be here at the end of the sprint (likely holidays the week before Portland)

(Oleg) I shouldn't have any holidays for this sprint

(Julien) I think we still need to keep points for SmartData. Last sprint they were taken by meetings, I expect this sprint this will be more coding. But still we need to account for it.

(Julien) Steve, no holidays for you?

(Steve) Will have 1 or 2 days PTO

(Julien) ok, so should we decrease the velocity? Like p=7?

(Oleg) yeah, let's have p=7

from current sprint

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

• (Julien) I tested Wilson's branch from https://bugzilla.mozilla.org/show_bug.cgi?id=1074783#c38 and it showed a small improvement, but it's still slower than on v2.0 (maybe it's another issue though).

  (Julien) next steps (IMO) is profile the launch in v2.0 vs v2.1 (using https://github.com/julienw/gaia-juju-tools maybe). Maybe we can manually add time()/timeEnd() couples in gaia-header to see what takes time. profile()/profileEnd() works fine with WebIDE too (but only at one place at a time).

  (Oleg) Can we have eg. p=1 subtask instead to do this profiling, just to understand next steps?

  (Steve) +1 for 1 point for profiling first

  (Julien) I already did some profiling in https://bugzilla.mozilla.org/show_bug.cgi?id=1087329 but yeah we need to do more _inside_ gaia-header, and this makes sense to plan 1 point for this. Do you think additional work would be done by the gaia-header team?

  (Oleg) I wouldn't exclude such possibility :)

  (Steve) yep it's possible,

  (Julien) ok, then, let's just do some more profiling? Should we keep one more point for doing more investigations?

  (Steve) Sounds good to me

  (Julien) so overall p=2?

  (Oleg) do we still have blocker points that we can use for "further investigation"? Tbh, it's not clear yet what we're going to investigate

  (Julien) so you think: p=1 for doing what's sure here (profiling and finding likely issues), and using blocker bugs to do more?

  (Oleg) yep, that was my idea. In fact it's kind of perf blocker

  (Julien) yep I anticipate we'll have a perf blocker for v2.1 because of this (even if we rejected it already in the past)

  (Julien) ok then, p=1

  (Steve) p=1 +1

https://bugzilla.mozilla.org/show_bug.cgi?id=1079824 [2.2+] [p=1]
Bug 1079824 - [Messages] Draft saved from activity is duplicated

• (Steve) Since we all decide to clear filed, p=1

  (Julien) good for me

  (Oleg) p=1

blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1091299 [2.2+][skip]
Bug 1091299 - It's possible to open the SMS activity menu multiple times

• it's ready to be landed.

nominations

Nothing here.

features

https://bugzilla.mozilla.org/show_bug.cgi?id=1080832 [RTL] [p=1]
Bug 1080832 - [Messages][RTL] Cursor is badly located in recipients and subject when they're empty

• (Julien) some investigation needed, might be a gecko issue

  (Oleg) Agree that it has main RTL priority - the most frequently used, but non-RTL-ed-yet-feature :)

  (Steve) Could we reproduce this with simplified test case on desktop?

  (Julien) that's clearly the first thing to do here :)

  (Julien) I'd say p=1 for doing a testcase, and p=1 more if we need to fix it in SMS app. So p=2 to be safe, p=1 if we anticipate it's a gecko issue that we can't workaround.

  (Steve) I would prefer p=1 first and decide what we can do in next sprint

  (Julien) Oleg what do you think?

  (Oleg) I was planning p=2, but if you think Gecko will like to handle this, then yes p=1. Looks like it's related to that
  inside empty content editable. Oh we also need to handle recipients pills for RTL

  (Julien) you mean, with RTL names? Or you mean, the pills themselves in a RTL document?

  (Oleg) yeah, I mean that eg. international numbers aren't shown correctly inside pills, or maybe it's another bug?

  (Julien) ok; yeah I think it should be a different bug actually, but we need to handle this.

  (Julien) so, p=1 for this, and if we need more because it's not a gecko issue, we can either use blocker points if we have time or keep it for next sprint.

<to be created bug> - handle recipient pills in a RTL document, make sure it behaves correctly [RTL] [p=1]

• (Julien) should we take it or handle it later on?

  (Oleg) Maybe take, looks like we'll have points for it

  (Steve) ya, it looks like the task we could handle in RTL

  (Julien) is p=1 enough for this? given the experience we have on the previous bug with phone numbers

  (Oleg) p=1 sounds good, I see only "assimilated" pills case and the case when you're entering international number, currently "+" is located in the wrong place.

  (Steve) So both editable and non-editable pills will need to be addressed , I think?

  (Julien) yep, I think we need to handle both cases, but likely they'll be handled together. I recall it's part of building blocks BTW so it should also handle email case ;)

https://bugzilla.mozilla.org/show_bug.cgi?id=1053709 [RTL] [p=2]
Bug 1053709 - Make SMS messages content UI RTL-friendly

• (Julien) some investigation needed + we need to add some example data in the desktop mocks

  (Julien) work likely needed: add dir=auto for content, but also force dir=ltr (_not_ overriding) for links (phone numbers, url, email) in threadUI

  (Julien) be careful: work needed for ThreadList and ThreadUI. Maybe file an issue at System app to add dir=auto for the alerts and notifications, if not done already.

  (Oleg) I'd say not less than p=2

  (Steve) Agree, especially we are not sure which is the most proper display for RTL content

  (Julien) agree; we need to check also RTL message in a LTR document, and LTR message in RTL document, and even RTL messages containing LTR content and LTR messages containing RTL content. Lots of cases to check (would be easier with data in the desktop mock).

  (Julien) and as Steve said, where we should put the bubble. But this can be handled in a separate bug if we don't have the definite answer for this, this is not difficult, just a bunch of floats to override :)

  (Oleg) I believe we have padding instead - even easier :)

  (Julien) so, end is p=2, or more? I don't think we need more but up to you :)

  (Oleg) Still p=2 sounds good :)

  (Steve) p=2

https://bugzilla.mozilla.org/show_bug.cgi?id=1094131 [RTL][skip]
Bug 1094131 - [Messages][RTL] Ellipsis truncates first part of the LTR contact name in Thread List

• quite minor, and likely more a Gecko issue, I don't know what we can do

  (Oleg) so probably we should skip this, we'll see once Ehsan returns :)

(Julien) ok, we have 1 point left !

(Steve) Copy/paste? It's likely needed for 2.2

(Oleg) I'm eager to improve/use copy/paste in Messages, do we have any defined issue/feature to fix/implement?

(Julien) Steve, I think you mean the "Copy bubble" bug? We can maybe start something yep.

(Steve) Oh yep, to be precisely, it's bubble copy/paste

(Oleg) Yep, let's outline from what we can start

(Steve) https://bugzilla.mozilla.org/show_bug.cgi?id=1092437

(Julien) so, p=1 to start doing "something" here?

(Steve) Well it's hard to say if we need to do any further adjustment for copy/paste enable, but at least we have a clear idea what we should do for bubble copy(spec is ready)

(Oleg) Mm, spec is only about SMS, should we handle MMS in the same way (subject, attachments)?

(Julien) it's not clear what we can do with attachments

(Steve) We could do nothing for attachment now... But we'll need to copy subject as Jenny told me.

(Julien) and then we should copy... what? "Subject: <text>" ?

(Julien) and btw we need clipboard API to copy the bubble content; is it ready?

(Steve) Won't be ready for 2.2 :-/

(Julien) so maybe we can't do much now... and we should wait to know what we can do for v2.2?

(Oleg) but per spec we just need to provide user with smth editable where he can select text (that currently works for other inputs) or what for we need clipboard api?

(Julien) maybe I misunderstood; clipboard API is to copy directly bubble content to clipboard. But if we need to set user-select correctly, then ok, we don't need it. But it's more work :p I don't think it fits in p=1 but maybe it's because I don't have really clear idea about this feature.

(Steve) Maybe I could give a WIP for testing, and create bugs for other copy paste issue while implementation.

(Oleg) yeah p=1 sounds good for WIP

(Julien) good for me; the more ahead we are with v2.2 features, the less stress we'll have.