| Lucas_Werkmeister_WMDE | |
| Jul 7 2017, 9:55 AM |
| F8797883: image.png | |
| Jul 19 2017, 1:40 PM |
| F8796236: image.png | |
| Jul 19 2017, 10:32 AM |
| F8796243: image.png | |
| Jul 19 2017, 10:32 AM |
| F8793673: image.png | |
| Jul 18 2017, 2:55 PM |
For instance, by ordering them after violations and making them semi-transparent.
This should only be done after T169531: Show invalid constraint parameters on constraint statement, otherwise we’re left with no place at all where bad parameters are shown prominently.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Lucas_Werkmeister_WMDE | T169532 Better treatment of constraint parameters | |||
| Resolved | Lucas_Werkmeister_WMDE | T169971 Make “bad parameters” results less prominent in the gadget |
Here’s what it could look like:
I suppose it would be nice to have some indicator why this is less prominent. Something like small-print “this is a problem with the constraint definition, not with this entity”, perhaps. @Jan_Dittrich what do you think?
@Lucas_Werkmeister_WMDE can you tell me the context here – when would these "less prominent" entries be shown?
What I understand is that we make things that are caused by problems with the constraint definition less prominent. But if we know that they are caused by a problem, why do we show them at all?
These entries are shown when there is a problem with the constraint definition statement itself, e. g. when a “conflicts with” constraint statement doesn’t specify the other property that a property conflicts with. Those problems are shown in two ways: on the constraint statement itself (see T169531 – I just added a screenshot there), and on every statement of this property on other entities.
The motivation for this task is that, especially for widely used properties, “on every statement of this property” means a lot of reports – for example, currently there’s such a report on every “subclass of” statement on Wikidata (we have roughly two million of them). But these reports can be harder to understand and to fix, so we don’t want to display them as prominently to every user. At the same time, we don’t want to completely hide them, to make sure that the problem gets fixed soon.
Change 365988 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Make “bad parameters” results less promiment
Result of IRL discussion:
We discussed the following:
Assumption behind above suggestions: "Users who don't have a clue what to do about these additional warnings should not be exposed to them, so they don't worry and/or do changes that don't solve the problem but corrupt the data"
Ideally, we would have a watchlist like page for these "advanced problems" (so people who know about them can have a look there), but as discussed with @Lucas_Werkmeister_WMDE this is probably difficult.
Change 366226 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Collapse bad parameter reports
Here’s what it looks like with the two linked changes:
Collapsed (default):
Expanded:
Change 366538 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Use ConstraintReport{Group,List} in gadget
Change 366226 abandoned by Lucas Werkmeister (WMDE):
Collapse bad parameter reports
Reason:
Now part of I6e31e84d40 and I63903c06c8.
Change 365988 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Extract ConstraintReport{Group,List} classes
Change 366538 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Use ConstraintReport{Group,List} in gadget