Page MenuHomePhabricator

Print URL, Version, etc only when they contain data
Closed, ResolvedPublic

Description

Currently these fields are being always printed in the bugzillapreview:

URL: none
Version: unspecified
See Also: none
Hardware/OS: unknown/unknown

See for instance https://bugzillapreview.wmflabs.org/T6408

If these fields contain just the defaults, they don't offer any information and are pure noise. Can we migrate these fields only when they have specific information (not the default)?

DECISION

Fields to always keep in the initial description of a Phab task, no matter what the value is set to:

  • Version
  • Severity

Fields to drop from the initial description of a Phab task only if set to default value "All":

  • Platform/Hardware
  • OS

Fields to drop from the initial description of a Phab task only if value is entirely empty:

  • URL
  • Whiteboard
  • See Also

Event Timeline

Qgil created this task.Oct 18 2014, 10:36 PM
Qgil raised the priority of this task from to Low.
Qgil updated the task description. (Show Details)
Qgil added a project: Bugzilla-Preview.
Qgil changed Security from none to None.
Qgil added a subscriber: Qgil.
chasemp closed this task as Declined.Oct 20 2014, 10:03 PM
chasemp claimed this task.

We looked at this and decided it is more confusing to have different fields per ticket as it begs the question did this just fail in migration or is it truly not set? Since descriptions can be cleaned up easily anywhere people do not like this in regards to an active task I am going to mark this as declined.

Qgil reopened this task as Open.Oct 24 2014, 3:49 PM
Qgil added a subscriber: Jdforrester-WMF.

Reopening this task only to make sure that people see it before creating a duplicate.

By the way, even if I reported this task, I fully agree with the decision. Makes sense.

Qgil updated the task description. (Show Details)Oct 24 2014, 3:51 PM
In T694#12394, @chasemp wrote:

We looked at this and decided it is more confusing to have different fields per ticket as it begs the question did this just fail in migration or is it truly not set? Since descriptions can be cleaned up easily anywhere people do not like this in regards to an active task I am going to mark this as declined.

Although I can understand that decision in the context of the migration, I think it's a huge mistake. This violates the principle of progressive disclosure, and so increases the confusion for non-expert and new members when they're reading each task imported from a Bugzilla bug — tasks which will be around for years to come. Instead, they will all need to be manually updated to remove this cruft. This doesn't feel very respectful of people's time.

Qgil added a comment.Oct 24 2014, 4:53 PM

One possibility could be: based on the proof of concept that bugzillapreview is, we trust the script, and we will instruct it not to print the unnecessary fields.

In T694#14544, @Qgil wrote:

One possibility could be: based on the proof of concept that bugzillapreview is, we trust the script, and we will instruct it not to print the unnecessary fields.

So far I've seen no issues at all in the import in terms of missing content, so this seems sensible.

Qgil raised the priority of this task from Low to Medium.Oct 24 2014, 6:38 PM

In regards to the principle of progressive disclosure, this not a phabricator or migration issue.

https://bugzilla.wikimedia.org/show_bug.cgi?id=68559 looks like this:

phabricator looks like

Bugzilla chooses to display fields that have no set value, I assume because an unset field is not the same thing as no data. The current approach is the least surprise approach as it most closely preserves the set of data, set and unset, in the original bug report. Not liking it is fine, not wanting it shown on issues people are actively working on where the value of this data can be examined is fine. It can be removed from any description, but the default migrated description would be missing valuable context without it.

Just for the records I don't have a strong opinion here and don't see an issue with 'empty' values being exposed (or not) in Phab's initial comment...

In T694#14606, @chasemp wrote:

In regards to the principle of progressive disclosure, this not a phabricator or migration issue.

https://bugzilla.wikimedia.org/show_bug.cgi?id=68559 looks like this:

phabricator looks like

Bugzilla chooses to display fields that have no set value, I assume because an unset field is not the same thing as no data. The current approach is the least surprise approach as it most closely preserves the set of data, set and unset, in the original bug report. Not liking it is fine, not wanting it shown on issues people are actively working on where the value of this data can be examined is fine. It can be removed from any description, but the default migrated description would be missing valuable context without it.

I agree that Bugzilla is also crap at this. :-) However, we can and should do better.

I agree with James. Let's just not print the unused fields.

We are discussing two different types of Bugzilla fields which will be dropped as "text only" in the initial description of a Phab ticket imported from Bugzilla (as listed here):

  1. We have 4 dropdown fields with pre-defined values. By nature these fields must have one selected pre-defined value set:
    • Version
    • Platform/Hardware
    • OS
    • Severity
  2. We have 3 free-form text fields which can be entirely empty:
    • URL
    • Whiteboard
    • See Also

As a compromise between "correct and complete conversion of Bugzilla data" vs. "readability of initial descriptions" (I know my wording is oversimplifying):
Can we agree on

  1. keeping dropdown fields with pre-defined values (as "Version: unspecified" or "OS: All" in Bugzilla could be considered information to transfer/preserve)
  2. dropping completely empty free-form text fields from being listed in the initial description of a Phab task (as an empty Whiteboard or See Also field in Bugzilla could be considered no information to transfer/preserve)

?

Dzahn added a subscriber: Dzahn.Oct 29 2014, 9:08 PM

a key without a value is not the same as a key that doesn't exist

In T694#16896, @Dzahn wrote:

a key without a value is not the same as a key that doesn't exist

Technically, correct. Practically, *shrug*. Look at this:

URL: none
Version: unspecified
Severity: normal
Whiteboard: none
Hardware/OS: unknown/unknown
See Also: none

Sure, the keys might exist, but it's academic. I would go so far as to say that the default values (even "Severity"=="normal") should just be dropped, since chances are, no human ever cared enough about it to change it. It's complete clutter, and in the case that someone really cares, the values can be inferred by their absence.

Qgil reassigned this task from chasemp to Aklapper.Oct 29 2014, 9:24 PM
Dzahn removed a subscriber: Dzahn.Oct 29 2014, 10:31 PM
Qgil added a comment.Oct 29 2014, 10:37 PM

What about keeping Version and Severity in all cases, and the rest only when there is a value different than the default? Reasoning below.

  1. We have 4 dropdown fields with pre-defined values. By nature these fields must have one selected pre-defined value set:
    • Version

In fact Version is a hybrid: many products/components don't have a concept of version, and Bugzilla forces the related reports to have the only possible value: "unspecified" (example). 22572 reports (31%) have a version other than "unspecified" or "--". Well, ok.

  • Platform/Hardware

4789 reports (6.6%) have a value other than "All". In most cases the hardware is not even relevant, and sometimes reporters specify their hardware just because. I'm fine with migrating the values that were defined, but printing "Platform/Hardware: All" in 67.000 tasks is not very useful to the purpose of the task.

  • OS

4930 reports (6.8%) have an OS other than the default "All". Same reasoning as Platform/Hardware.

  • Severity

Nothing to say, I agree it should be always specified. It was a relevant field and we are getting rid of it.

  1. We have 3 free-form text fields which can be entirely empty:

OK. Since I had the calculator at hand, and just to have an idea about the impact...

  • URL

18% have something

  • Whiteboard

3.1% have something

  • See Also

7.6% have something

I would go so far as to say that the default values (even "Severity"=="normal") should just be dropped, since chances are, no human ever cared enough about it to change it.

Some triagers do, especially correcting by setting the hard to discover "enhancement" value. Severity information was explicitly requested in T695 hence I'd always keep it.

What about keeping Version and Severity in all cases, and the rest only when there is a value different than the default?

I think I've gotten tired of discussing so I can live with that and what Quim proposes here.
Wondering if "the values can be inferred by their absence" should be "documented" on https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla though.

More numbers for completeness, talking about 72760 tickets in Bugzilla:

  • "Platform" (Hardware) field ever changed (!) to current default "All": 2524 tickets
  • "OS" field ever changed to current default "All": 2502 tickets
  • In both cases I can imagine that many reporters religiously filled out all fields just describing which OS and Browser s/he used though totally irrelevant for the actually reported bug (and hence set back to default "All" when somebody cared about metadata)
  • "Severity" field ever changed to current default "Normal": 2109 tickets
  • (Default) Values for "Version" are per product and not global, hence no simple numbers.

To summarize the proposal that I can live with:

  • For "OS" and "hardware" fields, drop if the value is set to "All"
  • for "URL", "Whiteboard", "See Also": Drop if field is entirely empty
Aklapper updated the task description. (Show Details)Oct 31 2014, 2:05 PM
Aklapper reassigned this task from Aklapper to chasemp.Nov 3 2014, 7:48 AM

Ignore my last comment; Chase already fixed this in https://git.wikimedia.org/commit/phabricator%2Ftools.git/a0822790ea39f53020ddfdc782e2577ba9ed4289

I think this can be closed, leaving that to Chase.

Aklapper moved this task from Ready To Go to Done on the Bugzilla-Preview board.Nov 4 2014, 3:51 PM
Jdforrester-WMF closed this task as Unknown Status.Nov 5 2014, 5:24 PM
In T694#19030, @chasemp wrote:

Looks great. Thank you!

Jdforrester-WMF changed the task status from Unknown Status to Resolved.Nov 5 2014, 5:50 PM

Whoops, my thumb must have slipped on the bus.

chasemp closed this task as Resolved.Nov 5 2014, 5:52 PM
chasemp mentioned this in Unknown Object (Diffusion Commit).Nov 13 2014, 3:51 PM

I'm still seeing "unspecified" though. https://phabricator.wikimedia.org/T54136

Qgil added a comment.Nov 24 2014, 3:01 PM

I'm still seeing "unspecified" though. https://phabricator.wikimedia.org/T54136

Consistent with the decision in the description:

DECISION

Fields to always keep in the initial description of a Phab task, no matter what the value is set to:

Version
Severity