https://bugzilla.wikimedia.org/show_bug.cgi?id=40985
--- Comment #7 from Dereckson <[email protected]> 2012-10-16 19:44:43 UTC --- (In reply to comment #6) > (In reply to comment #5) > > The point I'm trying to make is I would prefer developers closes themselves > > bug > > with relevant comments if needed or allow the discussion about the bug to > > go on > > when needed. > > And that's something I disagree absolutely with. If some developer wants to > manually close a bug or comment on it, he can do so. But why burden volunteer > or paid developers with unnecessary, mechanical management tasks? There is a > huge cost involved, but what is the benefit (besides your personal > preference)? The benefit seems to me the increase quality of the bug resolution workflow. Note I offered an hybrid solution. We could add a checkbox in Gerrit merge form (with a setting to have it checked by default) to close the linked bug in Bugzilla. > > > I would also like to stress two of the newly appointed bug wrangler > > objectives: > > > (1) Grow a community of volunteer bug responders who help transfer issue > > reports from other communication channels to the bug tracker, and who share > > bug > > management responsibilities > > > (2) Clean up and organize the existing bug tracker backlog, identifying > > duplicated and outdated bugs > > > This translates a willingness to assign such bug closure responsibility to > > humans, instead to automated systems. > > I don't see any such requirement. These tasks refer to bug triage that > requires human assessment, not to have someone waiting for someone else's > message "Bug fixed" to click on the button "Bug fixed". > > > [...] > > "Yesterday, there were 8 548 open bug reports in MediaWiki. Should we take > > Wikipedia offline until they are all fixed?" doesn't constitute a logical > > argument, as: > > (1) the number of open bugs is quantitative, the way we close bug is > > qualitative; > > (2) the 8 548 bugs are in the immense majority bug not yet resolved or > > analyzed, not bugs resolved with forgotten closure; > > (3) there is no need to close Wikipedia to fix bugs (we use continuous > > integration processes) (and by the way, not all open bugs are related to > > components used on Wikimedia projects); > > (4) you start with the hypothesis 8 548 open bugs is bad and this amount > > should > > be decreased, I beg to differ, this proves we've a living bug report > > ecosystem, > > with users finding bugs and asking new features. > > > Why do you use such catastrophic exaggeration in a constructive dialog to > > find > > the better way to improve bugs handling? > > If all of this is true, why don't you want to apply the same continuous > improvement process that we use on MediaWiki to its bug management and > implement an initial auto-close on the commit of bug fixes even if there are > cases where that will not be useful? Because I disagree with your number of 95% and even if the approximate is right, I would prefer a 99.5% of useful score. 5% of errors isn't acceptable, there is an huge risk issues not totally resolved are forgotten. Especially if we could offer a very easy way instead to close the bug merging the change. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
