Kilimanjaro/2012-04-16

Kilimanjaro Planning

We met today to discuss the next steps in moving forward with Kilimanjaro. Most of the conversation centered around how we are going to track progress.

Bugzilla/Github

• Some teams use bugzilla and others use github.
• Browser Id - the Identity folks will have all Kilimanjaro related work logged in Bugzilla. They have a github repository but nothing in github is specific to Kilimanjaro.
• Apps - All platform work is tracked in bugzilla. The store related work is tracked in bugzilla as well. For the services and browser id integration, items are logged in bugzilla. We have a few items logged on the services side.
• B2G - Gecko platform work is logged in bugzilla. Gaia work is logged in github.
• With the exception of Gaia, everything should be in bugzilla already.
• It's going to be important that we have automated dashboards that show Kilimanjaro progress as a whole.
• We need to figure out if there is an easy way to integrate the github items so they can be tracked in the same dashboard as the bugzilla items.
• Sheila and her team will look into what our alternatives might be with help from Bob's team.

Tracking Work Horizontally

• We also discussed the need to be able to coordinate work across horizontal slices.
• For example we might want to understand how much work we have left to complete a target use case. This probably consists of work from various different teams.
• We decided that we would have meta bugs in bugzilla to track each individual use case. Using dependencies, people can then see all the different pieces of work that need to be done in order to satisfy that use case.
• The product team is going to add meta bugs for all the use cases. We can then start to log bugs for the various features that make up the next level. Many of these are logged already so we would go through a triage process with individual teams to identify all the bugs under the various use cases.

Tracking Process

• We worked through some details on how we want to track Kilimanjaro progress.
• We already have the blocking-kilimanjaro flag setup in bugzilla.
• Upon further discussion we realized that we need to also have a way to indicate priority as well as target milestone.
• Having a target milestone helps us plan and coordinate work as well as track dependencies.
• We discussed using the current fields in bugzilla for that but target milestone is being used a different way by devs.
• Snappy and other projects have been adding priority to the whiteboard field.
• We decided on a format like [K9O:P1:FF15] to track priority and target.
• This is very similar to the way we do other projects so it won't be something new for devs.
• We can adopt a similar convention for indicating that we are guessing about the priority and target milestone by adding a '?'
• Process proposal
  • Bugs are nominated for blocking-kilimanjaro by setting the ?
  • As we approve bugs we add in a priority and target to the whiteboard status in the format above.
  • We can use the ? to indicate this needs further triage ie: [K9O:P?:FF15?]
  • We can have a set of queries to isolate bugs that are missing these indicators or that need further triage.
  • We can communicate this process on the list so that people add these flags during initial triage which will be somewhat distributed.
• Sheila to do a write up on the process to send out for review.

Next Actions

• PM team to look into how to integrate items in github in a dashboard.
• Product team to add in use cases as meta bugs in bugzilla.
• Sheila to write-up the process for tracking.
• Team will meet again next Monday.