Gaia/SMS/Scrum/2.2S13/Planning

Sprint is from May 5th -> May 26th (called 2.2S13) (3 weeks)

Velocity: [p=13]

PTO:
Julien: May 8th -> May 17th
Steve: May 8th
Oleg: May 14th - public holiday, May 15th PTO
=> I roughly counted p=13 (5 days * 3 weeks * 3 devs - 6 PTO - 1 PTO - 2 PTO) / 2 points * 0.7 (velocity)

From current sprint

https://bugzilla.mozilla.org/show_bug.cgi?id=1155509 [ng-architecture] [p=7 to be split in several bugs]
Bug 1155509 - [Messages][New Gaia Architecture] Split ThreadList view from current structure

(Julien) what's left ?

(Oleg) Remove dependecies (bugs below) and to think about startup.js - not sure how it can be split. Index.html is extracted already. So once dependencies are resolved it's p=1.

(Julien) in Network Alerts we have separate startups per view -- maybe we can do the same, with one main startup to call the other ones for now until we split documents ? - yeah maybe I can try this.

(Steve) p=2, do we suppose to make the app work correctly in this patch?

(Julien) I think it would be nice to use little-browser and have master still work (this is needed work anyway) but maybe this could be done in 2 bugs.

(Steve) If we separate the bug, then p=1 is ok

(Oleg) I this bug I didn't plan to use little-browser yet - just to have views/inbox/index.html with markup required by inbox only. At the same time we'll have main untouched index.html.

(Julien) how do you feel having one dependent bug: create separate index.html for each views + one dependent bug: use little-browser ?

(Oleg) mmm but this bug about ThreadList only :) I think once we split at least two views - inbox + conversation we can have bug that will use little-browser to navigate between them. For little-browser we need one more index.html (views/index.html) and supporting js code.

(Julien) I agree, that's why I say we need separate bugs :) But I think this "split" bug won't be finished if we don't use it for real on master. (and so will stay untested?).

(Oleg) Yes, nobody except us will see it, it can be opened in browser of course to test and improve further. I had plan to extract views, remove dependencies and change main index.html somehow to use these external extracted index.html files from specific view folders - so that master use the same files internally... Don't know really yet. What do you think?

(Julien) like using the build file to insert the extracted files back to the main file?

(Oleg) I wasn't really concerned about performance on master - so I was thinking about dynamic loading into iframes maybe... so that old navigation.js code can be used.

(Julien) how is this really different than little-browser ? :)

(Oleg) Only in the part that little-browser is not used for master :) I'm not sure it can do everything we need - need to check thoroughly.

(Julien) it can be a task for this sprint: use little-browser with the splitted files (or even with made-up files as a start).

(Julien) to summarize: I'm fine with having first one bug to just create separate html files and keeping the current index file untouched. If we can find an easy way to just the separate html files in the main file it's better (build or other) but it's not necessary because it's not something we want long term. Then there is a second bug to use little-browser -- maybe we'll need to change little-browser to make it work like we need, so there is some work involved. (but needed work overtime too.)

(Steve) I would say keep the index untouched first and try out the little browser directly(if we have time for this sprint), but I don't against any interesting idea about making separate html works nicely on current codebase

(Oleg) Yep, it's tightly coupled with the task about adapting navigation.js to ng.

(Julien) I'm interested in testing lttle-browser anyway :p

(Julien) I think we should try to estimate both tasks separately -- i'd say p=2 for splitting HTML and p=3 for adapting to little-browser. What do you think?

(Steve) 2 for HTML split and 3 for little browser sounds fine for me

(Oleg) Same for me. So we need two more bugs then, one to extract index.html for Conversation (I think still with Composer until bug 1155534 is resolved) and one for little-browser.

(Julien) definitely, Conversation still hold Composer + Report + Participants views

(Steve) I think we are not hurry for splitting conversation view

(Julien) yep, we mostly need to exercize the bridge, service worker, little browser, so one split is enough for this right now.

(Oleg) Sooo, for this particular bug it's still p=1 or max 2, right?

(Julien) I think this bug is more a meta now :) what actions do you think of, after the 2 other bugs ?

(Oleg) Let me think: close this bug with extracted inbox/index.html and startup.js --> bug to extract conversation/index.html ---> bug to have views/index.html (or layouts/index.html if you prefer) that uses little-browser to switch between inbox and conversation ---> start using bridge for first service to share data/events between inbox and conversation (I was thinking that Drafts maybe good example)

(Julien) so: Bug 1 - extract inbox/index.html; Bug 2 - extract conversation/index.html; bug 3 - use little-browser in views/index.html; bug 4 - start using bridge with shared worker; bug 5 - use little-browser's main page as master's main page;

(Steve) I though we Bug 1/2 for this bug originally, but I'm fine if you prefer to split (Julien: that was in my mind too but we can split to have a finer granularity)

(Oleg) Ahhh, you want use little-browser on master?

(Julien) eventually :D but maybe it's not possible before we use a service worker with the model in it ?

(Oleg) I thought little-browser doesn't depend on SW, or smth changed? Okay we need to discuss on IRC our "model" model :) Initially I was thinking about SW as manager for various caches, notifications (when they start supporting it) and shared workers for services that acts on models... okay we need to discuss

(Julien) yeah, I tend to mix the service worker and the shared worker -- but I wanted to say shared worker (I think). In my head there is only 1 worker with everything in it and that's all but I'm wrong :p

(Oleg) Okay, np

(Julien) so ok, we need the model in a shared worker with use of threads.js (I don't like the name :p - yeah it's awful name :D Maybe it's because I'm not native speaker) before using it in master, right ?

(Julien) Bug 1: p=1; Bug 2: p=1; Bug 3: p=1; Bug 4: p=3 (or more); bug 5: p=(not sure, maybe too early to estimate) (note, I exchanged bug 4 and 5 :) )

(Oleg) Sounds good except for the bug 3 - I'd say at least p=2

(Steve) Ya I would expect more for little browser since we haven't really test it on master yet

(Oleg) Sorry, quick unrelated question - do we still plan to use different gaia-headers for every document?

(Julien) I say p=1 because we don't need to make it work very reliably since it's not used by default on master -- but p=2 works for me too.

(Julien) good question, I don't know what the long term plan is, but I think that currently it's still the case. Why do you ask ?

(Oleg) I remember and (photo-browse example reminds me again) that main view that hosted little-browser was supposed to host gaia-header so that it's not involved into transition between views - but it's too opinionated so we can stick with whatever is simpler for us.

(Julien) I'll have a look at photo-browse -- for us it's not that easy because our header is dynamic so we'll need logic to change it anyway. (maybe it's the case for photo-browse too :) ).

(Steve) Yes the separated header is simpler for us now,

(Julien) should be easy to revisit later

(Oleg) Yep we can think about it later, if compare it to "headers" from other languages/frameworks it could have like .setConfig(menuItems) or smth - ok, skip for now.

(Julien) back to estimation :) so let's say p=2 for Bug 3; what about Bug 4? I think it would be nice to start using it so that we can give feedback to developers.

(Oleg) p=3 sounds reasonable and I'm glad we start working on it this sprint. it's our core :)

(Julien) Just wondering how much of it will depends on the DB -- or at least on an asynchonous access to threads.js (our threads.js).:D

(Oleg) It's hard to say until we touch it :)

(Julien) ok, let's say p=3 for bug 4 for this sprint, but we know we might not finish it. and skip bug 5.

(Steve) bridge experiment for 3 is fine

(Julien) ok, that means p=7 for these bugs together. Let's move on :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1155534 [ng-architecture] [p=1 to find subtasks]
Bug 1155534 - [Messages][New Gaia Architecture] Separate composer view from message thread view

(Oleg) So as of my experience from Inbox - it needs subtasks for js and css part. And dependency removing - there are a lot of them.

(Steve) Agree, we'll need to create subtasks, maybe we can skip first

(Julien) Yeah, it's not urgent, but this will also be more difficult (I think) -- so maybe we can define tasks and start at least one? One I can think is how Compose can work with 2 different views. Or is it easier if we have 2 HTML files (no need to make it instanciable after all) ?

(Oleg) I'd vote for two separate index.html and shared Composer component (I believe still not web component not sure if contenteditable-inside-web-component bugs are fixed)

(Julien) Maybe one task for this sprint could be to find out the needed work -- find out cross-view dependencies, issues, CSS... so more like background work to prepare the following sprint?

(Steve) Sounds good, I'll try to create bugs for this meta, and we can define which item could be implement first

(Julien) I'd like to say p=1 for the task of finding tasks :) What do you think ?

(Oleg) Yeah, why not, one can spend p=1 to thoroughly find out subtasks. It's tough nut to crack :)

https://bugzilla.mozilla.org/show_bug.cgi?id=1050823 [ng-architecture] [p=1]
Bug 1050823 - [Messages][Refactoring] Revise "ThreadUI.updateHeaderData" call while retrieving threads

(Oleg) It's "dependency-removing" task, I'd say it's ready, but what do you think Julien?

(Julien) yeah I think not much is left to do, should be p=1.

(Steve) p=1 since patch is there

https://bugzilla.mozilla.org/show_bug.cgi?id=1010216 [ng-architecture] [p=2]
Bug 1010216 - [Messages][Drafts] Improve consistency of the draft code in ThreadUI and ThreadListUI

(Oleg) It's also from "dependency-removing" category, I worked on it during entire previous week, and it still needs some work, I'd say min p=2.

(Julien) I'm curious to know what you did so far -- is the dependency that difficult to remove or do you use the occasion to do more work ? ;)

(Oleg) Yeah :) I couldn't resist - but nothing really redundant

(Julien) ok, do not hesitate to ask feedback early

(Oleg) Sure!

(Steve) Not sure how to estimate properly, maybe p=2 if you propose to address all the items in comment 0(or you have more ideas about refactoring?)

(Oleg) Yeah sorry didn't push the PR, but it basically does what mentioned in comment 0, except maybe for total removing of ConversationView.draft. Yeah I think it's p=2 since I already started the work.

(Julien) I hesitate between 2 or 3. Let's do 2 if you both agree.

Blockers

https://bugzilla.mozilla.org/show_bug.cgi?id=1156464 [2.2+] [p=1]
Bug 1156464 - [Window Management] Accessing a message thread via notification after killing Messages app creates adverse effects on future notifications while in app

(Julien) should be very easy to fix.

(Oleg) Yes, main work is to verify that nothing is broken + integration test (depends on bug 1050823). So with all this it still sounds like p=1

(Julien) yep p=1 is enough to write integration tests too

(Steve) p=1

https://bugzilla.mozilla.org/show_bug.cgi?id=1160232 [2.2+] [p=1]
Bug 1160232 - [SMS][Text Selection] Attempting to 'select all' in the TO: field of a new message will select text from both the TO: field and the message area

(Steve) Apply the some logic on message bubble should work, will verify it later

(Julien) I'd say it's p=1 too -- Steve is quite used to these issues ;)

(Steve) 1 is fine for me

(Oleg) p=1 for experienced Steve :)

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().

(Steve) We might need more discussion first because gecko side were not convinced to create an API for activity.cancel

(Julien) I think Fabrice was quite convinced but yeah, maybe this needs discussion...