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.

• «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.).

--Nemo 22:05, 8 November 2012 (UTC)

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#Why upgrade? 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)

I agree about going back to UNCONFIRMED if you cannot reproduce, but that required somebody to actually try to reproduce. It doesn't imply that all other issues have been both recently tested and reproduced. "is known" isn't very unclear to me - if somebody adds a comment mentioning a version, or even just bumps the Version field, it's implicit enough that it's meant to mean that the problem still happens in that version. "this is clearly not how the field is currently used in our bugzilla": Neither first version nor last version is how the field is currently consistently used - There simply is no consistent use. I myself use it for last version, because I don't see any useful information in "this problem was first reported about version 1.17 but git blame/log said it was introduced in 1.14 and nobody has tested it in 1.24 yet" compared to "this still happens in 1.24 and I can find this valid ticket to work on by searching for open tickets with version 1.24". However, it all won't matter soon when we don't have a version field anymore in a different tool. I hope. :) --AKlapper (WMF) (talk) 14:20, 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 bugzilla: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)
  • I would say that a bug that involves loss of user data (such as an edit session disappearing into thin air) in a relatively common scenario or set of circumstances should be marked "critical"; I would certainly set the severity that way were I to file such a bug. This, that and the other (talk) 10:03, 15 June 2014 (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... [1] --Nemo 07:24, 13 June 2014 (UTC)

Vote

Add infomations about vote of "Importance" please. --Liuxinyu970226 (talk) 23:04, 31 July 2014 (UTC)

Voting has nothing to do with Importance. I don't consider Voting a useful thing to document. --AKlapper (WMF) (talk) 07:29, 1 August 2014 (UTC)

@AKlapper (WMF): We could document it with "don't do this, it's pointless and no-one pays attention to them"? :-) Jdforrester (WMF) (talk) 15:52, 1 August 2014 (UTC)

Yeah, but dropping my 15 quotes here (to not look like I came up myself with that statement) wouldn't really scale and the problem with Voting will be mostly gone once we've moved away from Phabricator. :P --AKlapper (WMF) (talk) 16:33, 1 August 2014 (UTC)