Firefox OS/Comms/Dialer/Sprint/v2.2-S4
Bugs
Status
File:Dialer v2.2-S4 burndown chart.png
- <POINTS>,0,0,0,0,0,0,0,0,0
Bugs Taken in Planning
Bugzilla query error
Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1
- Does not include Bugs Taken but not Completed.
Bugs Taken but not Completed
Bugzilla query error
Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1
Bugs Taken During Sprint
Bugzilla query error
Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1
All Issues for this Sprint
Bugzilla query error
Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1
- Does not include Bugs Taken but not Completed.
Bugs Redirected
Bugzilla query error
Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1
Daily Standup Meetings
- Current hosts: drs, gtorodelvalle, thills
- Hosts rotate every week.
- If you're not available for a standup that you're scheduled to host, then ask for someone else to host instead for just that time.
- Start by pinging everyone who should be participating.
- List any administrative items you have, and then ask for more from other people (look at the Etherpad).
- Look at the list of blockers and blocker nominations and see if there's anything new or that needs action. Mention these during this time.
- Move to individual updates. Go alphabetically, in descending order.
- If someone's update is taking longer than 3-4 minutes, you should generally cut them off and ask them to talk about it after the standup.
- Copy the reports from the GDoc to the wiki page for that day. Use the Etherpad-to-Wiki converter to format it. You can just copy and paste the whole thing and the converter will do everything for you.
- Ask the person who should be hosting the week after you if they'll be available. If not, move onto the next person.
Day 10:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 9:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 8:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 7:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 6:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 5:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 4:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 3:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 2:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
Day 1:
FirefoxOS/Comms/Dialer/Sprint/v2.2-S4/2014mmdd-StandupNotes
PTO
- drs: None. Next one will be in early Feb, probably for a week.
- gsvelto: None
- gtorodelvalle: None
- jlorenzo: None
- thills: None.
Office Hours
Day 7
Day 2
- Clean up the dialer's startup procedure
- The place of verification in the development process of new features?
- Make branches for user stories, verify them all together at once before approving for landing
- Mini-triage
- Canceled as we didn't have time
Retrospective
Things we did well
- <jlorenzo> 2 intermittent failures fixed on the Python side (bug 1113154, bug 1097754)
- <gsvelto> We landed quite a bit of stuff in spite of the vacations which I find always remarkable
Things we could do better
- <drs> We missed FLR. My fault. Will watch the schedule more closely and step in where needed in the future.
Action items
- <thills> we should decide what we are going to do going forward with the daily notes/burndown, etc.
- <drs> We will start writing daily notes when working on a new feature branch, probably v3.
- <jlorenzo> Following up the fixed intermittent failures fixed: Add "always wait until an animation finishes" in the best practices for Marionette JS tests which QA is writting down.