[Dev] Tracking with Bugzilla (2) - vote on component list

[Philippe Bossut]

Katie Capps Parlante wrote:

> One comment about the swags -- other groups/projects have been using 
> wiki tables to track tasks, 

The rationale behind using Bugzilla instead of a Wiki table was:
- the App team felt this need may be more than other because:
    - bugs have been filled that are really feature work
    - specs do point to bugzilla records
- most of our task for 0.6 have a cleanup/fit and finish focus and the 
difference between bug and task is becoming too blurry
- the consensus then was that having one single spot to report and track 
everything (bugs and tasks) would make our life easier

> and have a swag column as well. The convention for the swag value has 
> been:
>    small => a few days
>    med => 1-2 weeks
>    large => ~1 month
>
> These values were meant to swag task times at the beginning of a 
> project, before enough detailed work was done to build a detailed 
> schedule. I know that the apps team is trying to break things down 
> into smaller tasks to do better estimates. Also, we presumably want 
> these to apply to bugs as well as tasks.
>
Indeed, we want to have estimates that are consistent for both bugs and 
tasks, hence the extended range. I think however that in 0.6 we need to 
focus and stay clear from "1 month" tasks... This is at least true for 
the Chandler App team.

> You are proposing:
>
>     * [SWAG : Trivial] : bug that takes a few hours to fix
>     * [SWAG : Small] : 1 day to fix or implement
>     * [SWAG : Medium] : 2 to 3 days to fix or implement
>     * [SWAG : Big] : 1 week to fix or implement
>     * [SWAG : Huge] : 2 weeks or more to fix or implement (those are 
> good candidates for spec and further decomposition)
>
> Is it important to be consistent? Are people happy with the swag units 
> as proposed here?
>
The App team is already using this since a couple of weeks and it worked 
well for us. Consistency is indeed important within the team. Using 
different scale for bugs and tasks will lead to problems if, say, a bug 
is upgraded to a task because it's really a new feature and we need a 
spec for it.

> I like the proposal overall. +1
>
Thanks!... :)

BTW, I'd like to have the votes of you Apps devs (got only Bryan so 
far). I'd also like to get your comment on the "App:" prefix issue for 
components. I personally feel that the current component list feels a 
little chaotic without this extra level of organization but I won't 
fight the issue if the consensus agrees with Heikki and Katie. I just 
want something that makes our life easier... What do you guys think?

Cheers,
- Philippe