Closed Bug 386750 Opened 18 years ago Closed 13 years ago

Mass-reassign old and unused QA contacts to default contact for unresolved bugs

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: whimboo, Unassigned)

References

Details

Currently we have a lot of old and unused QA contacts for most components. To increase the quality of our triage work it would be really helpful if we could reset all this contacts to the default value. As I was informed, members of the triage team use the bug watcher list to get notified when new bugs are filed or modified. This is really helpful to track bug reports. But this doesn't work if a special user is listed as QA contact. Than only this person receives the notification and all others who are interested in that component don't have the current state without adding them self as CC. That cumbers our work. As Axel mentioned we should wait until the bugzilla reorganization is finished. Also we should avoid sending any bug notification if it is possible.
(In reply to comment #0) > Currently we have a lot of old and unused QA contacts for most components. To > increase the quality of our triage work it would be really helpful if we could > reset all this contacts to the default value. This doesn't require any special access to do. Anybody with editbugs can reassign bugs to proper QA contacts. The issue is that you need to make sure you don't mess up the assignee when you change it. > As Axel mentioned we should wait until the bugzilla reorganization is finished. That's going to be fun, as there's currently not a way to move a component from one product to another. :P > Also we should avoid sending any bug notification if it is possible. It is not possible, and even if it were, I'd rather have the bugmail.
(In reply to comment #1) > This doesn't require any special access to do. Anybody with editbugs can > reassign bugs to proper QA contacts. The issue is that you need to make sure > you don't mess up the assignee when you change it. Indeed. But there are thousands of bug reports involved. I for myself don't want to do that step by step. A sql query which changes the entry for all reports will save us a lot of time. The only thing we have to do first is trying to reach the persons and asking for their acceptance.
i had scripts capable of doing it bug at a time, but it's trivial to do component at a time using change several bugs at once. the query is: component=X, qacontact!=qacontact(component). &tweak=1 check all, and change only qacontact to qacontact(component). I too want the bugmail and don't appreciate having people try to rob me of it. I'm willing to do the reassigns, note that comments are a bad idea as they mean more useless reading. i could give notice to people so they could choose not to listen for mail, or i could just do it. it'd be fairly trivial for reed to modify the watcher settings for most of the users who used to be qa contacts so that they watch the default qa contacts who replaced them. but i'm not sure how much we care. if the people are active, they know to watch, if they aren't, they probably don't need more mail.
timeless: your query doesn't work because it misses the "old and unused" part of the bug title. We really want to search for each unused account, and change the bugs to restore the default QA without restoring the default owner. That's somewhat tricky. Gerv
(In reply to comment #4) > timeless: your query doesn't work because it misses the "old and unused" part > of the bug title. I don't understand. We want all of the QA contacts fields to be restored to their current defaults, whether the old "QA contact" is active or not. Given the way we use QA contacts on b.m.o, there's no reason for the QA contact field to contain anything other than the default value. Of course, if we're considering mass changes, we should be sure that all components have appropriate defaults. I think that was done for most components that needed it in bug 378950.
(In reply to comment #5) > I don't understand. We want all of the QA contacts fields to be restored to > their current defaults, whether the old "QA contact" is active or not. Given > the way we use QA contacts on b.m.o, there's no reason for the QA contact field > to contain anything other than the default value. Gavin, thats not trivial. We still have active accounts for a lot of given QA contacts. If we reassign all to default what should we do with that ones? We can't dictate that they have to watch the components default QA from now on. They will be flooded with messages. I believe you also don't want that. :) That's why my proposal was to only change old and unused first. All others could be reassigned at a later time. > Of course, if we're considering mass changes, we should be sure that all > components have appropriate defaults. I think that was done for most components > that needed it in bug 378950. There are some components left which don't have a default QA set. Timeless, can this easily be done by a script? Should I file a new bug for that issue which blocks this one?
(In reply to comment #5) > I don't understand. We want all of the QA contacts fields to be restored to > their current defaults, whether the old "QA contact" is active or not. Given > the way we use QA contacts on b.m.o, there's no reason for the QA contact field > to contain anything other than the default value. Are you sure that's true of every part of the project? I can give you several counter-examples in the mozilla.org product, and I'm sure there are some in the others. Real people are QA contacts too. We should only reset the QA contact for those bugs which have a "dead" QA contact. Gerv
(In reply to comment #7) > Are you sure that's true of every part of the project? I can give you several > counter-examples in the mozilla.org product, and I'm sure there are some in > the others. Real people are QA contacts too. Yeah, as I mentioned earlier, there are some components that don't follow this convention. I think we should correct that. I can't think of any cases where a generic QA contact isn't desirable. Do you know of any?
(In reply to comment #6) > There are some components left which don't have a default QA set. > ... > Should I file a new bug for that issue which blocks this one? Yes, you should. People have been filing such bugs for a while now, in specific cases where there was a need (e.g. wanting to watch a component but not being able to). If we're going to be doing mass-changes to all bugs, we need to ensure that the defaults are correct for all components.
All that being said, I'm not sure that a mass change like this is really worth doing. I think that fixing the default QAs and letting it take effect for new bugs is sufficient in most cases, and doesn't cause people to get upset for receiving a lot of mail. In certain cases we've been "re-assigning to default" once we've fixed a default QA contact/assignee for open bugs in a component, and ignoring resolved bugs. These kind of targeted changes produce less bugmail and are generally just as effective at making sure people get mail for active bugs than a mass change would be.
It won't be quite as effective tree-wide (or at least not without some communication and cooperation on the part of triage/QA and developers), but in Camino we've been doing a modified version of what Gavin described in comment 10 for some time now: letting the new defaults get phased in as new bugs are filed, but also reassigning to defaults (or only fixing the QA, depending on the bug) on existing bugs as we have some other reason to touch those bugs. It keeps bugspam down and doesn't mess up people's queries like mass changes do, and any existing bug that's "relevant" will pretty quickly get updated to the new system. Any old bug that's not relevant will be updated at such time when it becomes relevant....
Depends on: 387230
(In reply to comment #9) > > Should I file a new bug for that issue which blocks this one? > > Yes, you should. People have been filing such bugs for a while now, in specific This is bug 387230 now. (In reply to comment #11) > 10 for some time now: letting the new defaults get phased in as new bugs are > filed, but also reassigning to defaults (or only fixing the QA, depending on > the bug) on existing bugs as we have some other reason to touch those bugs. That's right. I think we can differentiate between two groups: maintained and unmaintened bugs. The first ones are all bugs which are confirmed, assigned or resolved. I think that we don't have to take care about them. If the QA contact isn't the right one, it can be changed with the next entry. But mainly we have a huge amount of unmaintained (unconfirmed) bugs in our database. These ones have to be triaged by the appropriate people. If we only do a mass-change for such bugs we could lower the count rapidly. This can also be done stepwise for each component. In that case the bugspam wouldn't be too high.
No longer depends on: 387230
Depends on: 387230
I think it makes sense to re-assign *unresolved* bugs in a component after we've corrected the defaults (nobody@ assignee, generic "watcher" account for QA contact). I don't think it makes sense to do that in a way that doesn't send out bugmail - the entire point of the exercise is to make these bugs visible to those watching the component. Is that what you're suggesting?
(In reply to comment #13) > Is that what you're suggesting? Yes, that's why I created bug 387230 and let it block this one. So anyone who is watching a component gets notified. I hope that we can resolve a lot of these bug reports.
(In reply to comment #13) > I think it makes sense to re-assign *unresolved* bugs in a component after > we've corrected the defaults (nobody@ assignee, generic "watcher" account for > QA contact). I still don't agree - QA is not defined as being _solely_ for watching purposes, and there may be components where it is not used that way - i.e. each bug has a specific, allocated QA contact. This may be the right thing to do for some components, but not for all. Gerv
(In reply to comment #15) > This may be the right thing to do for some components, but not for all. Like I said before, if you think there are components for which a generic QA contact is not the right solution, please list them? I can't think of a case where a specific person as default QA would be better than a generic account.
(In reply to comment #16) > Like I said before, if you think there are components for which a generic QA > contact is not the right solution, please list them? I can't think of a case > where a specific person as default QA would be better than a generic account. Correct. I also don't see a reason why a single person is set as default QA contact. In such a case we should create a new default contact and add this one to the bug watcher list of that person. Dunno if we can automate this process.
(In reply to comment #16) > Like I said before, if you think there are components for which a generic QA > contact is not the right solution, please list them? I don't think that's the right way around. You can't say "I'm about to remove everyone who is a QA contact from being a QA contact; shout if you want me to stop". You may think it's desirable for every component to have a generic QA contact, but you can't just make that decision unilaterally, without consulting people who are already QA contacts - and, even if they agree, giving them time to set up the necessary watching relationships so they don't lose bugmail. Here is what I suggest you do: - Post in mozilla.dev.planning, saying "We are planning to move all open bugs completely to a generic QA contact mechanism", and invite comments. If you want to do this for the more outlying parts of the project, such as NSS, you'll need to post to some other groups too. - If the reaction is positive, email everyone who is currently a QA contact on an open bug, telling them of the plan and allowing them to opt-out. - Two weeks later, create all the necessary dummy accounts, and notify people of what they are so they can update their watching. - A week after that, make the changes. Gerv
I'm not proposing we change default QA contacts without notifying them. But I know from experience that the group of people that want to be QA contact and are still active in the Mozilla community has approximately 0 members. By and large the existing default QA contacts are defaults from several years ago, and most of those people are either no longer interested in getting mail for all of these bugs, or are no longer active at all and don't read their bugmail anyways. That isn't to say we shouldn't give them a say in these changes. In any case, I think we've already made a lot of progress in cleaning up the defaults. I'm not really sure that this bug is useful; I think we should file individual bugs about specific components/products, as we've been doing (e.g. bug 327772, bug 334198, bug 362258, and many others), and let them track both changing the defaults and "mass changing" the unresolved bugs in those components once that's done. The default QA contacts for the component can be CCed on these bugs and asked to approve the change.
Summary: Mass-reassign old and unused QA contacts to default contact → Mass-reassign old and unused QA contacts to default contact for unresolved bugs
Assignee: mozillamarcia.knous → nobody
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
closing bug due to inactivity. please re-open this bug if still relevant.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
This bug was blocked on bug 387230 and that was the reason of no activity. Not sure how much we have to do here. AFAIR we moved all the old default QA entries to somewhat else and re-introduced the default QA field from fresh. Please correct me if I'm wrong. But does that mean that all those un-used contacts are gone now? If that's the case we can mark it as fixed by bug 684088.
Status: RESOLVED → REOPENED
No longer depends on: 387230
Resolution: WONTFIX → ---
(In reply to Henrik Skupin (:whimboo) from comment #21) > This bug was blocked on bug 387230 and that was the reason of no activity. > Not sure how much we have to do here. AFAIR we moved all the old default QA > entries to somewhat else and re-introduced the default QA field from fresh. > Please correct me if I'm wrong. But does that mean that all those un-used > contacts are gone now? If that's the case we can mark it as fixed by bug > 684088. The default QA contacts used to serve as a way to watch a component before Component Watching was added to Bugzilla. The "old" default QA contacts can still be used that way, and it will work; or you can use "Component Watching", see https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch The "old" default QA contacts can also be added to the Cc field of a bug in order to send bugmail to every watcher of some Product::Component other than the bug's current one (it's sometimes hard to decide in which exact Product::Component a bug belongs; or else, some bugs may have implications for more than one). AFAIK they are the only way to do that. AFAICT the "new" default QA contacts are all blank, but even today I sometimes see someone setting himself as the QA contact for some particular bug. This means that nondefault QA contacts which haven't changed for a long time might or might not have to be reset to the default (those @formerly-netscape.com.tld probably should, if there are any left) but those which were set recently should probably be left unchanged. How obvious it is to distinguish the ones from the others in a mass-reassign request I don't know; but I can figure that for this reason a WONTFIX resolution might be appropriate.
when we migrated away from qa-contacts to component watching, all bugs which had a "watching" address as the qa-contact had that value cleared. there are some components which specify a default qa-contact, and it's set on bugs too, however in these cases it's used for tracking the person who is actually responsible for qa related tasks. marking as wontfix.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → WONTFIX
So actually bug 684088 fixed the problem then. Clearing off all the old values from the open bugs is what this bug is about. Given that change we can call this bug fixed and not wontfix which is indeed the wrong resolution.
Depends on: 684088
Resolution: WONTFIX → FIXED
You need to log in before you can comment on or make changes to this bug.