Kilimanjaro/Developers

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Thank for you helping the Mozilla Kilimanjaro project! We have just begun to nominate and prioritize bugs in the various Kilimanjaro products. Our first task is to take the Kilimanjaro roadmap documents and make sure that bugs are filed on each piece of work that remains, and track those bugs using blocking flags.

Roadmap Documents

Each product or technology has its own roadmap. We will be triaging bugs and features against these roadmap documents:

• Mozilla’s 2012 Roadmap
• Firefox desktop browser roadmap
• Firefox for mobile roadmap
• Persona roadmap
• Marketplace roadmap
• Apps roadmap
• Sync roadmap

Blocking Flags and Triage

At a basic level, blocking flags and notations we need to able to answer a few key questions:

• Is this bug/work part of Kilimanjaro?
• What is the priority?
• What milestone are we targeting this work for ie: fx15?
• Who is the owner of this work or doing something about it?

This will be handled with a combination of the blocking-kilimanjaro flag as well as whiteboard notations. Anybody can nominate a bug and (similar to the way we handle tracking flags today) it's helpful to the triagers to add comments as to why this bug is blocking Kilimanjaro.

Blocking bugs will use the whiteboard to add information about priority and milestone. The whiteboard tags will be in the form [k9o:p1:fx15]. Since the triage will be distributed it's quite possible we require feedback from others to set the priority and/or milestone. In this case we would use the '?' ie: [k9o:p1?:fx15?] to indicate that someone needs to review this and accept the target and priority by dropping the '?' or come back to triage with a suggested alternative. This enables us to run simple queries to identify bugs that are approved but do not have the whiteboard status flags or do not have a confirmed priority or target. Similar to fx4, we will have a wiki page with links to all the various queries.

The final part of this proposal is that all bugs approved should have some idea of a owner. So what does that mean? This doesn't necessarily mean the person who is doing the work. Of course it will get assigned to a developer as they are working on it. It could be a dev lead who is responsible for making sure the work gets assigned to someone. Maybe it's blocked on someone else doing something. It could be someone who is going to help us determine scope so we can target a particular train. We will use the assign to field for this purpose. We have been using this model for tracking bugs and in the mobile team.

Queuing off the list of bugs that product setup for the high level use cases, we are setting up a number of triage sessions so we can start to organize the work and get to a certain point where think we have most stuff logged and the dependencies setup. One we've done this initial pass at rounding up all the stuff, I expect triage to be a much more distributed process with component leads and others looking at bugs on a regular basis. There have been quite a few questions around who is triaging what and when, that's the next thing we want to tackle.

The product team has begun filing tracking bugs for each of the high-level items on the Kilimanjaro roadmap. The next task will be to add in all the features and sub bugs that fall under these use cases to create a dependency tree. It is true that some bugs can be associated with multiple use cases. We definitely want to expose this type of information. Queuing off the list of bugs that product setup for the high level use cases, we are setting up a number of triage sessions so we can start to organize the work and get to a certain point where think we have most stuff logged and the dependencies setup. One we've done this initial pass at rounding up all the stuff, I expect triage to be a much more distributed process with component leads and others looking at bugs on a regular basis. There have been quite a few questions around who is triaging what and when, that's the next thing we want to tackle.

In the meantime, there are a bunch of things that people can help us with using the process above.

Component leads: Should look at the high level requirements and start filing/moving bugs required to implement them. Including a rough estimate for each of those bugs would also be good.

Community members: Should, at this stage, be helping with both moving existing bugs under each of the high level requirements as well as identify any additional work that may be needed by nominating blockers.