Talk:Bugzilla/Fields

We need to add Microsoft Server 2008 to the list of OS on Bugzilla --Lisa Ridley (talk) 17:39, 3 March 2010 (UTC)

Priority
I think priority is worth some thinking. Currently, it's mostly a useless field because almost nobody follows it to set their priorities; still, it makes people quarrel. --Nemo 22:05, 8 November 2012 (UTC)
 * «If this is the priority level on a bug, then the bugwrangler is either not concerned with it (e.g. Semantic Wiki items are tracked in Bugzilla, but the bugwrangler does not set priority on those items) or hasn't seen it.»
 * Perhaps it would be useful to clarify when the bugwrangler is not concerned with them. It's probably not needed/not really constructive to set priorities from outside the team when the bug's component has an active maintaining team with a product manager etc.? For instance ArticleFeedback, Translate.
 * In general: the current definitions are not realistic. Previously, their only effect on reality was that the bugmeister used them to ping people regularly (the higher the priority, the more frequently); and older bugs got their priority lowered semi-automatically (to avoid wasting pings?). I don't know how useful the pinging was, but surely setting priorities semi-blindly makes us lose information (it's something you can just query) compared to actual priority considerations (which summarize the bug discussion etc.).

Version
«The latest version of MediaWiki, that the bug is known to affect» Latest, really? This would mean to change the Version field in thousands of bugs; in practice, it's usually the earliest known affected version, or unspecified if it's unknown/all of them. Bugs are assumed to be still current until someone closes them when trying to reproduce them; and if it's unclear, usually I see people commenting "still reproducible" etc. (to also poke cc'ed users). --Nemo 23:28, 9 November 2012 (UTC)
 * Changed. "Latest" was irrealistic and I didn't see it applied. Earliest is more useful, for instance the link Manual:Upgrading allows to quickly see what version is affected by a security bug and in what version it was fixed, if version and target milestone are set. We should set it more often for important bugs. --Nemo 07:01, 13 June 2014 (UTC)
 * I'm strongly against this. It's entirely irrelevant if the problem happened in MediaWiki 1.6 or not, relevant is if somebody could still reproduce it in 1.24 which is now, and that's what to reflect in the Version field, and that's how I use the Version field. "Bugs are assumed to be still current" is part of the problem created by not bumping the version field to where it was last reproduced. --AKlapper (WMF) (talk) 09:37, 13 June 2014 (UTC)
 * That's information about the status of the bug and it should be reflected in the status. If a bug can't be reproduced in a recent version it's marked UNCONFIRMED with an appropriate comment, or RESOLVED straight away if the tester is sure enough.
 * You may have a strong opinion for "Version" to be the latest, but this is clearly not how the field is currently used in our bugzilla. Instructions are also unclear: «is known» by whom and how do I know what others know? We could make it simpler, for instance «Version of MediaWiki in which the bug was found/reproduced [by the reporter/triager]». --Nemo 13:33, 13 June 2014 (UTC)

Critical, data loss
What does the parenthesised part of "loss of data (internally, not your edit preview!)" mean? John Vandenberg (talk) 08:13, 2 October 2013 (UTC)
 * It means that "data loss" is something like a revision disappearing from the database, not your cat unplugging your computer's power and making you lose an edit in your browser. --Nemo 08:18, 2 October 2013 (UTC)
 * Ok, what about 52187, where the VE UI caused the user to unwillingly close their editing session containing incomplete/unsaved changes? John Vandenberg (talk) 08:48, 2 October 2013 (UTC)


 * It refers to data that is definitely lost on the servers (like accidentially deleted images) and cannot be restored (e.g. it is not possible to revert a previous "delete" action). It does not refer to data in your browser only, like losing the content of an edit after clicking the "Preview changes" button (e.g. when your session times out). --AKlapper (WMF) (talk) 08:56, 2 October 2013 (UTC)

Alias field?
New Bugzilla version, new field: "Alias", above the name field. What is this, how does it work, and how should it be used? Guidance appreciated. Jdforrester (WMF) (talk) 20:10, 13 February 2014 (UTC)
 * Uhm, thanks for bringing this up. We had the Alias field disabled before but since 4.4 it is enabled and the setting has been removed (and in 5.0 it will become part of the title. https://bugzilla.mozilla.org/page.cgi?id=fields.html says: "Alias: A short, unique name assigned to a bug in order to assist with looking it up and referring to it in other places in Bugzilla." (for example you can also enter the alias in the "blocks" or "depends" field instead of the bug number - might be helpful for tracking bugs so you don't need to remember the exact bug number anymore). --AKlapper (WMF) (talk) 20:24, 13 February 2014 (UTC)
 * Added. --AKlapper (WMF) (talk) 01:51, 14 February 2014 (UTC)
 * Thanks, Andre! Jdforrester (WMF) (talk) 03:43, 14 February 2014 (UTC)
 * Ugh, sounds like a nightmare. I hope there is automatic redirection between old and new aliases. --Nemo 07:48, 14 February 2014 (UTC)
 * It's mapped but not redirected. Who knows about Phabricator... --Nemo 07:24, 13 June 2014 (UTC)