Dave, Good point. I will re-look at this problem taking your comments into consideration.
Since we are already past code freeze for the 2008.11 release, I still think that every bug that we are planning to fix for this release should be assigned to a known available resource/real person. I will be assigning the bugs with Target Milestone of 2008.11 to the respective project lead. If the project team determine that the bug will not be fixed for this release, when they change the target milestone they can also reset the assigned engineer to the default value. Please let me know if you have concerns with this approach. thanks, -Moriah Dave Miner wrote: > Moriah Waterland wrote: >> Folks, >> >> We currently have a lot of bugs hanging out that are owned >> by: qa-(installer, distro, ...). I am planning to assign all bugs that >> are currently owned by qa-* and do not have a Target Milestone of >> "future" to the respective project leads so that in the current hectic >> state these aren't accidentally overlooked. Thereafter it will be up to >> the project lead to determine what should be done with the bug. >> >> Project leads, if you would like me to do something different or more >> specific, please let me know and I would be happy to help. >> >> I am adding this procedure to the recommendation of how the POC should >> be dealing with incoming bugs. I will be discussing this procedure along >> with other recommendations for defining the POC's responsibilities/duty >> at the staff meeting on Oct 30th. >> > > The problem with this procedure is that it doesn't appear, to the > outside observer (by outside, I mean anyone not intimately familiar with > our procedures, which includes people within Sun as well), that those > bugs are available to work on. That's quite undesirable from an open > development point of view. > > If the problem here is that we're not sure things have been looked at, I > think bug state and comments is a more accurate indicator, rather than > using an assignment-based metric. > > Dave
