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.

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.

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)

?

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.

Concur with @RobLa-WMF.

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

In T694#16895, @Aklapper wrote:

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.

2. 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

@chasemp: https://gerrit.wikimedia.org/r/#/c/170679/

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.

Fields not shown:

https://bugzillapreview.wmflabs.org/T11

I compared data of tickets https://bugzillapreview.wmflabs.org/T204 https://bugzillapreview.wmflabs.org/T716 https://bugzillapreview.wmflabs.org/T828 https://bugzillapreview.wmflabs.org/T939 https://bugzillapreview.wmflabs.org/T924 https://bugzillapreview.wmflabs.org/T941 with Bugzilla and all looks perfect to me. Great great great!

All 404 now, but thanks for fixing this, will make things much prettier.

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

In T694#779001, @Nemo_bis wrote:

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