Gaia/SMS/Scrum/2.2S11/Planning

Sprint is from 16 Apr -> 5 May (called 2.2S11) (2.5 weeks)

Velocity: [p=11]

From current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1043903 [tests] [skip]
Bug 1043903 - [Messages][Tests] Add integration tests for the thread panel with a large number of messages

(Julien) A review has been already done. So what's left is another review and possibly final fixes.

(Oleg) I can do it out of the sprint, slower and if you can review it out of the sprint we can skip for the sprint :)

(Julien) given it's not urgent I agree we can handle this in slower moments.

https://bugzilla.mozilla.org/show_bug.cgi?id=1152758 [bug] [p=1]
Bug 1152758 - [Messages] Empty report panel when opening it for an SMS that has been sent/received from a SIM that's not in the device anymore

(Julien) Very simple patch.

(Steve) p=1 I think patch is already there.

(Oleg) p=1

(Julien) p=1

https://bugzilla.mozilla.org/show_bug.cgi?id=1127398 [technical debt] [skip]
Bug 1127398 - [Messages] Display existing thread when sending a message using phone-number-/email-link context menu

(Julien) quite good cleanup patch from Oleg; first review still needs to be done.

(Oleg) I'd say p=2 to be on the safe side, if approach is accepted I need mainly unit tests though.

(Julien) I only wonder if we want it in this sprint; this is a good cleanup but this is not necessary for v3? Given we're not really advanced in the process, we can maybe handle this in background during our slow moments? Unless Oleg's slow moments are during the night :p

(Steve) p=2

(Oleg) :D I'm fine to do it in the background (during day :)) Yeah, it has low priority.

(Julien) I think it's lower priority than other things we have, that's why..

https://bugzilla.mozilla.org/show_bug.cgi?id=1084298 [technical debt] [p=1]
Bug 1084298 - [Messages] Decoupling the all inputs query logic from DOM tree structure

(Julien) was r+ but Steve would like a last review

(Steve) Should be p=1 unless you have more thought about this patch?

(Julien) even with more thoughts it would be p=1 ;)

(Oleg) p=1

https://bugzilla.mozilla.org/show_bug.cgi?id=1015194 [technical debt] [skip]
Bug 1015194 - [Messages] Invalid recipients are sometimes still considered as valid recipients

(Julien) quite important cleanup but I think we should leave it out of the sprint because it's too big. I can still work on it during some slower moments.

(Oleg) Works for me.

https://bugzilla.mozilla.org/show_bug.cgi?id=1144612 [CSS] [skip]
Bug 1144612 - [Messages][Refactoring] Make CSS more efficient by reducing the rule in tag category

(Steve) Not sure how to estimate it properly... I might create a meta for shared, but it's already struggling to me that shared will be replaced by web component someday :/

(Julien) good idea for the meta bug. Do you think we should have a separate team for the CSS changes?

(Steve) I've asked some member in Taipei but seems not much people is willing to modify the shared :p Maybe starting from web component would be more persuasive

(Julien) Let's keep this out of the SMS sprint; I'll talk to Wilson to know how likely it is that we'll switch to the web components soon.

(Steve) Sounds good

Blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1153808 [2.2+] [p=1]
Bug 1153808 - [Messages] Thread is not marked as read (in UI only) when thread is opened from notification

(Oleg) Depends on the solution we want, any solution + test is p=1, but if we want to try different approaches, measure and choose it will be p=2

(Julien) We discussed about it some time already, and I think that in the end I agreed with your solution. So let's say p=1 to do a proper review and fix nits.

(Oleg) Okay, p=1 then.

(Steve) p=1 unless you want to try another approach :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1149345 [3.0+] [skip]
Bug 1149345 - [Messages][Threads] Images can be attached to incoming messages, and corrupt the thread it was originally meant for.

(Julien) This is not actionable, we need activity.cancel(). Maybe it should not be a blocker given it looks like we have this forever...

(Steve) Ya, I think we asked for this feature long time ago but in vain

(Julien) it seems we'll have it at last in the other similar bug 1122205

(Oleg) Let's skip then.

Nominations

https://bugzilla.mozilla.org/show_bug.cgi?id=1154993 [3.0?] [p=1]
Bug 1154993 - [flame][3.0]Can't view SMS that has no phone number associated

(Julien) regression from recent Promise change.

(Julien) I think the correct change should actually be in mozContacts but I asked Gregor.

(Oleg) Yeah, I agree with you, behavior of mozContacts looks weird to me. Since it's 3.0? we can skip it until we get response from Gregor.

(Julien) I'd like to fix this rather sooner than later; I also don't mind working on the mozContacts part.

(Oleg) If mozContacts is changed, do we need to anything? If you do this then yeah, it will help to every our recipients refactoring. p=1, not sure though how complex this API internally.

(Julien) I'd say it's p=1 for any fix once we agree on the fix.

(Steve) Sorry but not sure why it's related to message?

(Julien) There are 2 possible fixes: one in mozContacts, one in Messages. I'd say because it impacts our app, I could well do the fix in mozContacts is nobody can in their team.

(Steve) ok, I thought it might be more reasonable to fix in mozContact but just like you said

Features

(7 points left)

Story: Split panels in separate documents

(Oleg) I'm not sure, but I'd say we can split this into several steps: 1. Is to thread list and thread ui (with composer, report, participants) views in different documents first, then thread ui and composer and then extract report and participants.

(Julien) not sure we should extract report; it's more a "dialog" of thread_ui. But this is a side-question :)

(Julien) about the strategy: how about starting from scratch the documents? I mean using copy/paste of course, but maybe we can work on have separate composer and thread_ui documents already? Maybe with the same JS of course, but at least different documents?

(Oleg) maybe, I thought it's still more difficult to split ThreadUI and Composer :) But anyway

(Steve) Maybe we can pend ThreadUI/composer split later? It's seems not that urgent at first, just my POV

(Julien) I'm sure it's difficult to split from a JS point of view, but I don't think it's difficult to split the HTML and keeping the same JS, and this can help to do navigation properly later. But maybe you'd rather split the JS in the same time?

(Steve) If we don't, could we accept the JS/CSS(maybe we can split CSS first) loaded in every document just to make sure app is runnable

(Julien) I think we'll need to load most CSS at first, because our CSS is not well organized :/ But you're right that's really valid questions. So what can be the plan? 1. separate HTML. 2. separate JS. 3. separate CSS?

(Oleg) That's why I was thinking about ThreadListUI - Thread, here we can probably do everything as it seems simpler to touch every aspect, less intersections in JS, CSS and HTML and gain experience faster :)

(Steve) So we only need to split into 2 doc, including JS/CSS separation?

(Oleg) + some communication bridge between views, they have ~10 direct dependencies

(Steve) Ya right we'll need inter-app communication

(Julien) In my head, I wanted to first load the document separately; for example for thread: app://sms.gaiamobile.org/thread.html?id=6. And make it load properly in Firefox.

(Oleg) Yep, it's definitely first step for any strategy we choose I think. It's just a huge task that we should split into p=1, p=2 actionable steps. So what do you guys think should be the first steps?

(Julien) I initially thought p=2 per view :) but it's maybe too small estimate and too big steps.

(Steve) Maybe we'll need branching first? because it seems not working on master during working on this story

(Julien) why not ? :) splitting CSS could work for master too, as does splitting JS. It might take more time to test properly but in the end it saves time if we don't have a branch to maintain.

(Steve) Re-factoring the css is a good start, but still back to the original question: How many doc do we want to split firstly?

(Julien) I'm fine with the initial solution of making a separate thread_list_ui and thread_ui views first. Next sprint we can work on others depending on how this goes. Can this be parallelized ? One person for ThreadList and another for ThreadUI?

(Oleg) Don't think so for ThreadList-ThreadUI, but ThreadUI-Composer probably can be started in parallel, at least JS/CSS separation for ThreadUI-Composer will require some initial steps if I'm not mistaken. Maybe I'm wrong :)

(Julien) so maybe we can start working on both separations in parallel?

(Oleg) I think so. And sounds like both separations can be split into subtasks, like separate on code level only (ah, forgot to ask, do we plan to have separate folders for views? I'd really like to)

(Julien) sounds like a good idea :)

(Steve) Separate folder for view +1

(Oleg) Good then we need a small convention on structure. Like this https://github.com/gmarty/photo-browse/tree/master/views (threads.js example) or something better? Maybe out of scope for planning though

(Julien) we can use the same convention (I think it's used elsewhere in other apps too).

(Steve) So where to put the global styling or js that needs for each view? makes several copy directly?

(Julien) No I think we can have a /shared in the SMS app :)

(Oleg) + some js will go to a "services" folder

(Julien) yep !

(Julien) so should we have 2 tasks for this sprint? What can we have as goal for this sprint? Have separate documents but no inter-communication? Or do we want to reduce interdep first ?

(Oleg) I'd like to reduce, but it may require significant effort (proper re-thinking I mean :), haven't analyzed yet), maybe for this sprint we can have workaround to support existing inter-view communication?

(Steve) I would prefer make a real inter-communication, so it's not hurry for me to have it in this sprint

(Julien) we need something finished for this sprint :) what can we commit? Thats why just loading the panels in firefox could be good enough for this sprint, keeping in mind the additional requirements?

(Oleg) Separating in code and loading in FF maybe?

(Steve) Sounds good to me

(Julien) for only ThreadList/Thread separation, or also for Thread/Composer ? I think we can do both. Even if we don't finish both.

(Oleg) Agree, it's going to be done in parallel anyway

(Steve) We could try this both for this sprint

(Julien) so, 2 separate bugs :) how do we estimate? What are the tasks for each? create HTML file, add needed JS and CSS files, handle parameters, separate CSS/JS files (optional in this sprint). I'd say it's p=1 for HTML file and needed JS/CSS files, p=1 for parameters, p=2 or 3 for CSS/JS files, so p=5 for overall work. Do I miss something?

(Oleg) handle inter-view dependencies somehow since views will be in diff iframes? Otherwise ThreadUI for example will throw a bunch of errors while loading.

(Steve) I understand ThreadUI has tones of direct access to ThreadList view. I thought we might just ignore there and wait for communication mechanism ready. Or you would prefer to come up a mock?

(Oleg) Don't have opinion, just asking you guys :)

(Julien) I don't get what errors we can get? I see "Mark as read". Drafts is not at load time? I mean not inter-view draft change.

(Oleg) Yeah, for example, drafts maybe. So we can just ignore them I don;t know

(Julien) Maybe I'm just wrong thinking its not a problem. I don't think we really want a interview comm btw. We want to change a model that will be in service (or shared) worker and when we change the model this will impact other views.

(Oleg) Right, I'm asking about current sprint? Do we just ignore current state of things (inter-view dependencies)?

(Steve) I think draft is not a inter-comm issue, it's more like we need to set it in backend or even worker.

(Julien) can we mock ThreadListUI in the view, and add console.log in each functions? So that we can clearly see what's missing in logs?

(Oleg) Yes, you're both right :) I was asking about mock (or how I named it previously temporal workaround for interview deps). So ok, let's mock it.

(Julien) so how do we estimate? :)

(Oleg) Your estimation above sounds reasonable for me

(Julien) if we have 2 bugs with p=5 we can stop the planning now :D

(Steve) Agree!

(Oleg) Such a long and valuable discussion!

(Julien) I'll file the bugs then, I'll keep you informed :) And watch Wilson's presentation from yesterday !

(Steve) Thanks! But don't we need branching this sprint? I'm afraid these changes would be appropriate for master

(Oleg) Thanks!

(Julien) I'll ask for branching :)

Story: Which questions do we need to answer ? (are there others)

(Oleg) Do we need a special meta for v3 related tasks, so that everyone can see our progress related to v3? I'd say yes, but not sure.

(Julien) yep I think it's useful. I initially thought about putting this in a wiki page, but a meta bug is fine too (if not better).

(Steve) Not sure if we'll need wiki page, but meta bug and maybe dev-gaia mail thread is enough.

(Oleg) I haven't seen Wilson preso yet, so is threads.js ready to use (assuming Julien attended :) )?

(Julien) looks like it is; actually I think he waits for actual use to find issues.

(Oleg) Good, will find them :)

(Oleg) IIRC all new tools (threads, CW) are separate components, bower maybe? If so we probably should start using bower in sms. It's not a big task, but still new for sms and needs some work.

(Julien) yes possibly

(Oleg) How do you think, should we create more integration tests when we touch some important functionality or it will slow us down?

(Steve) Maybe we can simply adjust existing integration test first?

(Julien) I think it's too early to do integration tests on NG. This will still move a lot...

(Oleg) Steve, you mean improve/extend current tests? Julien, yeah, I was thinking only about big changes we merge back into upstream master.

(Steve) Maybe I'm wrong that shifting existing test for new arch will work, and rewriting the test is the only way. Let's move on first and decide later.

(Oleg) Yeah, I think they should work at least as I see it currently. Yep.

Story: Branching

Story: IndexedDB in Gaia

(Julien) I've put it here already because it will be long so better start earlier