The bugmaster is, sadly, not the be-all and end-all. There are circumstances where this approach to QA will fail, and likely fail badly.
|problem spaces requiring /deep/ expertise which the bugmaster does not have. 100% accuracy is not typically a massive problem for bugmastering- bug tracking is, by nature, an iterative process involving dialogue and discourse, and so mistakes can be fixed by the hackers, QA volunteers, and leadership. But being able to at least get in the right ballpark is crucial- since a major part of the job is understanding and clarifying (in the form of triage, for example) getting it roughly right before handing it off to experts is important. This means that fields where 'roughly right' is very difficult to understand are going to be problematic for bugmasters. The canonical example of this in the free software world is libraries and APIs- since getting the impact of an API bug right is usually hard for someone without deep technical expertise in the API, initial triage of API bugs by a bugmaster is not likely to save developers much time, or to give leaders an accurate understanding of the state of the API. Any other project where very deep knowledge is necessary to understand a bug (say, UI design of very specialized interfaces, or accessibility work for more unusual disabilities) is likely to suffer from similar problems unless the bugmaster also has such deep knowledge.|
|if they disagree with developers or management on priorities. This is not a huge problem for gnome- stable, polished products are agreed to be a high priority by everyone. But we've seen problems where a bug volunteer has their own agenda, or entire projects where quality just isn't a priority. If that is the case, a bugmaster is unlikely to succeed. They can help push an agenda (indeed, that is one of the strengths I identified above) but the seeds for success of that agenda must have been sown by others for it to be successful- it can't start with the bugmaster.|