Retargeting enhancements

[Frédéric Buclin]

> I'd like to come up with a way to deal with enhancement requests which 
> avoids targeting them at a specific release until they have an owner 
> actually working on them that can tell us they think it'll make it by 
> then...  in other words, if it still has the default assignee, it 
> shouldn't be targeted to a release.

Several bugs have assignees who are pretty inactive, or who are active 
but are not interested in these bugs anymore and forgot to reassign them 
to the default assignee. So looking for bugs who have the default 
assignee on them only is not a good idea IMO.

My suggestion is to retarget all enhancement bugs targetted 2.22 to --- 
and let each assignee retarget them back to 2.24 if they are (still) 
working on them (and marking the bug as ASSIGNED to make it clear). In a 
month or so, all enhancement bugs targetted --- should be reassign to 
the default assignee (and QA contact for the older ones), showing 
clearly that anyone can take it (this way, these bugs will also fall 
back to UNCO or NEW, cleaning up old ASSIGNED bugs). This will give us a 
good idea of which bugs have real activity.


> need architectural changes before they can be implemented?  Do we have 
> someone willing to triage the "Future" stuff periodically and "defuture" 
> things that required architectural changes that have been made since 
> they were filed?

Here are interesting results from charts for the Bugzilla product, 
including all bugs (enhancement + "real" bugs):

Date\Series,"UNCONFIRMED","NEW","ASSIGNED","REOPENED","RESOLVED","VERIFIED","CLOSED"
2005-11-10,180,1743,191,27,5502,1314,164


Do you really want to triage more than 2000 open bugs?? Let's retarget 
them to --- and don't waste your time triaging bugs targetted Future or 
---. More important (from my point of view) is to triage old open bugs 
and close those we don't want to fix and those who have been fixed 
already or are no longer applicable.


LpSolit