WebDriver/RemoteProtocol/Meetings/2019/10/23: Difference between revisions

WebDriver/RemoteProtocol/Meetings/2019/10/23 (view source)

Revision as of 14:16, 23 October 2019

5,453 bytes added , 23 October 2019

→‎Minutes: add

Ato

715

edits

@@ Line 16: / Line 16: @@
 == Minutes ==
+=== Tracking work ===
+; mmucci
+:4 weeks cycle to work through backlog (adjust goals regularly), I will provide weekly updates about progress. Next step, team decides on backlog.
+; AutomatedTester
+: marco will track a flag in bugzilla. What about github?
+; mmucci
+: https://docs.google.com/spreadsheets/d/1iVI5BmK29aRKZ5qtAH6Ci9txb9O8SBkP6Mi6QuWubGU/edit?usp=sharing
+: Dashboard used on DevTools Fission project.
+: The GitHub issues will appear on the list of work, as part of the backlog.
+: The work that exists on GitHub can stay on GitHub. This should not be a problem.
+; AutomatedTester
+: When I say in GitHub, it might not be under the Mozilla organisation. Does that make a difference?
+: I just need to give you the repository you need to track?
+; mmucci
+: Yes, just give me the link to the repo and the flags you want to track.
+: There are two main components: the status dashboard and the list of work needed to be done.
+: You pick work off the backlog that you want to do.
+: There’s no need for a dashboard in the first four weeks.
+; whimboo
+: At the moment we have meta bugs for a lot of the domains we are implementing.
+: For the MVP we may not have to implement every dependency for these.
+: Would it cause problems for you if we rearrange the dependencies?
+; mmucci
+: This should not be a problem for as long as we use one coherent whiteboard tag.
+; AutomatedTester
+: mmucci will start work on tracking this project on Monday.
+; mmucci
+: As soon as the bugs get tagged [whiteboard entry added?] we can start.
+: In the first four weeks, keep adding to the backlog of things you want to work.
+; maja_zf
+: Does Bugzilla priorities matter?
+; mmucci
+: Everything that is MVP in the backlog that is waiting to be selected will be marked P2.
+: Once you assign yourself we change it to P1 and add yourself as an assignee.
+: P3 are bugs that we have for a reserved backlog.
+: For example, if you have too many bugs on your backlog that the schedule shows you won’t have time to do you can move some of the backlog over to the ‘reserved backlog’.
+: These are not important for M1, but if we’re looking for work we can draw from this list.
+: But they are not things required in order for M1 to ship.
+: What this process depends on is when you start work on a bug. The clock stops when it lands and the bug is resolved.
+; whimboo
+: What if you work on something that you’re working on, but it’s blocked?
+; mmucci
+: You will have to unassign yourself so the timer doesn’t run.
+; maja_zf
+: The whiteboard tag you want to use for MVP is equivalent to P2 priority?
+; mmucci
+: The MVP backlog would be the list of work your team is committing to complete by a certain date.
+: It switches to P1 to indicate work that is in development.
+: The P2 is work developers will pick up eventually. We don’t know when or who, but it is next on the list.
+: whimboo
+: We have lots and lots of P3s right now that we don’t want to count right now.
+; mmucci
+: Yes, these will not be counted. They will be part of the reserve backlog.
+: P3s are tracked but not part of the schedule
+: [explains forecast graph in link from above]
+; maja_zf
+: In past projects, what happens when team members realise something involves more work or they pick up incidental work?
+: Does that work get split up in more bugs? Or how do we track this?
+; mmucci
+: Often developers find they need to split work up in more bugs.
+: Say you start with one bug, but it’s easier to solve as four individual bugs.
+: We have contingency built in to the model.
+: There will always be some unknown work and we have to plan for these incontingencies.
+: This means we have to move some work to the reserved backlog so we don’t expand the scope.
+: If you’re ahead of schedule you may be able to absorb some more work.
+: If behind schedule, you have to move your priorities around in order not to increase scope so you hit your deadline.
+; maja_zf
+: As a team we are going to change the way we work to adapt to this.
+: Often we don’t bother filing separate bug and some incidental work ends up landing in the same changeset on the same bug.
+; mmucci
+: My experience is that you have a mix of bugs with a lot of patches, and some with only one patch.
+: These are outliers and it’s the middle ground that counts.
+: This will also be factored in to the model after the first four weeks.
+; maja_zf
+: What I’m hearing is that we should continue work in the same style we do now.
+; mmucci
+: You should work the way that is most efficient to you.
+; whimboo
+: Should we as a team discuss whether a new bug fits into the MVP and update the whiteboard entries?
+; mmucci
+: In DevTools we don’t have triage meetings.
+: At the normal team meeting they would take five minutes at the beginning to prioritise the incoming work. [?]
+; AutomatedTester
+: We’re probably going to make mistakes along the way.
+: The idea of getting a sense of where we are going…
+: I’ve heard good things. The idea it shouldn’t affect how we do things [?]
+; mmucci
+: I’m not there to manage the engineering work.
+: I’m there to collect information so you can make decisions based on this.
+; whimboo
+: What preparation work will we have to do?
+; AutomatedTester
+: Time-bound tracking bug versus feature-bound.
+; ato: That seems to duplicate marco's approach to tracking milestones with whiteboard tag and P2.
+; AutomatedTester: Track alpha and beta release. Will go through bugs and check-in with team.
 == Changelog ==