Page MenuHomePhabricator

new constraint level for suggestions
Closed, ResolvedPublic

Authored By
Sep 16 2018, 11:37 AM
Referenced Files
F28323833: i.png
Mar 4 2019, 11:34 AM
F28323843: flag.png
Mar 4 2019, 11:34 AM
F28302337: Screenshot_2019-02-28 Douglas Adams.png
Feb 28 2019, 4:55 PM
F28302346: Screenshot_2019-02-28 Douglas Adams(2).png
Feb 28 2019, 4:55 PM
F28302068: Suggestion.svg
Feb 28 2019, 4:20 PM
F28302067: Needs Fix.svg
Feb 28 2019, 4:20 PM
F28302069: Mandatory.svg
Feb 28 2019, 4:20 PM
F28210556: Screenshot_2019-02-13 Douglas Adams(1).png
Feb 13 2019, 5:44 PM
"Like" token, awarded by Jc86035."Love" token, awarded by Marsupium."Like" token, awarded by Manu1400.


In editathons and similar events we noticed that especially new people are put off when they add a statement and it triggers a constraint violation that really is merely a suggestion to add another statement.
We should introduce a new suggestion level next to mandatory and normal in order to be able to distinguish the really crucial ones from the ones that are merely used to suggest additional edits that would be nice to make.

"native language" has a constraint that says it also requires a statement for "languages spoken, written or signed". This is a mere suggestion to expand the data, not a hard requirement. There are other similar cases.

GIVEN a property
WHEN defining a new constraint for the property
THEN the constraint can be given the level "suggestion"
AND violations of this constraint are marked with a non-scary indicator icon

Acceptance criteria:

  • constraint definitions can be given a "suggestion" level
  • Violations with the suggestion level have their own less scary/alarming indicator icon

Open questions:

  • What should the icon look like for this new level?

Designing icons according to styleguide

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Once we have the icon we can pick this up.

I'd really love if, by introducing this new level, mandatory constraints became truly mandatory. Otherwise, levels start to make no sense, all of them have the same implications and none of them can be taken seriously...

Let's use a lightbulb icon based on the lightbulb icon from OOUI :

Potential issue2x.png (20×20 px, 300 B)

I did a bit of research on this. As the suggested icon should signify suggestion, I had a look what an established icon to signify "suggestion" is. The lightbulb seems to be a rather common icon for suggestion and it is there at least since the 90s. Alternatives I found overlapped with generic speech bubble iconography (sure, suggesting = communication = speech, in this thinking) but this is very generic to the point of "not even wrong" (compare with the use of arrows to signify "action") and clashed with other icons (Notification, Message…).

Given that the space is rather small (14x14px) it needs to be very simple. I think even the light bulb is a bit too complex visually (also given the constraints of a flat 1bit design) but it is far simpler than the alternatives I came across.

Yeah let's try the lightbulb.
@Hanna_Petruschat_WMDE: Did you make custom ones for the other constraint levels? Does the OOUI lightbulb need to be adjusted to fit with the icons for the other two constraint levels?

Change 486088 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add icon for constraint suggestions

@Hanna_Petruschat_WMDE as feared the icon is too prominent. It is the most in-your-face of the three. It is not very easy to see that it is a lightbulb either. In addition they are all too prominent with the size increase.
Maybe we switch to a non-filled lightbulb? And decrease the color saturation as you suggested previously?

Based on the feedback of the heaviness and an unclear reading of the lightbulb, my suggestion for the "Suggestion constraint" would be a flag. A flag only highlights a fact conveniently enough it is already in the OOUI collection. I adapted the icon to be an outline icon and therefor be a bit more subtle, similar to the existing ones.
I also adjusted the "potential issue"/exclamation mark to slowly adapt to the notice icon from the OOUI collection. The mandatory-icon should remain as is.

In order to have a more gentle approach for suggestions I highly recommend a text change.
Currently it says:

Potential Issue
"item requires statement constraint
An entity with native language should also have a statement languages spoken, written or signed ."

If this is an example for a suggestion I would change the text to something like:

Suggestion/Suggested Addition
For entities with native language we suggest to add statements for languages spoken, written or signed."

@Lucas_Werkmeister_WMDE I'm happy to discuss text changes. It would also make sense to involve communication people in this regard.

Find the icons here
flash (Mandatory (remain as is))

exclamation mark (Potential Issue)

flag (Suggestion)

Regarding the icon size: The specs for the icons are meant to go along with the base text size of 1 em (eg 16 px). The base font size at wikidata is only 0.85 em (14 px) which is why the icons look too big.

@Lucas_Werkmeister_WMDE can we try out if it would work to scale the icons otherwise I would adapt them to that size manually (17*17px).

Thanks, the flag looks good! Appropriately inconspicuous :)

Text changes would probably be useful, though I’m not sure if they should happen as part of this task. Perhaps a subtask? I also wonder if we should distinguish between mandatory and non-mandatory constraints this way (e. g. change “should” to “must” for mandatory ones)?

Side note: the icons you posted all have a rectangular white background, which looks a bit odd on references. It’s easy to completely remove the background in the SVG source, but I wonder if you think the inside of each icon still should be filled white? Here’s what that would look like:

Screenshot_2019-02-13 Douglas Adams.png (32×221 px, 2 KB)

I’m still not sure about the size. Are there plans to adjust the text size on Wikidata? (Apparently that’s set by the Vector skin – with Minerva, for example, text and constraint violation icons look larger.) Otherwise, we need to do something with the icons, yes… even at 0.875 scale they still feel a big large:

Screenshot_2019-02-13 Douglas Adams(1).png (32×417 px, 2 KB)

For comparison, here’s 0.75:

Screenshot_2019-02-13 Douglas Adams(2).png (32×417 px, 2 KB)

(I took those screenshots by setting transform: scale(FACTOR) on the .wbqc-reports-button via CSS, but especially at 0.875 the scaled icons don’t look good IMHO, so I suspect manual adaptation would be best.) We can also sit together to experiment with this a bit more if you’d like.

As just discussed, here are the adjusted icons:

Thanks, @Lucas_Werkmeister_WMDE.

Change 493450 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add icon for constraint suggestions

Thanks! Screenshot of the icons on their own:

Screenshot_2019-02-28 Douglas Adams.png (35×131 px, 860 B)

And in the context of a statement:

Screenshot_2019-02-28 Douglas Adams(2).png (184×910 px, 11 KB)

\o/ Are you both happy with it now?

Yes, if it’s okay with you as well we can merge the Gerrit changes to update the icons :)

I think you're going to hate me (more), my comment is late and perhaps too subjective... but I can't tell at first glance which of the icons corresponds to which level of severity. The circle with the ! inside reminds me too much of the information icon, which I would associate with a suggestion.

i.png (480×480 px, 29 KB)

At the same time, I associate the flag with serious problems, that's the icon normally used to report abuse, spam, etc.

flag.png (200×200 px, 7 KB)

Having a triangle around the exclamation mark instead of a circle would make the meaning clearer to me, while the icon for suggestions might be similar to the round information icon shown above or to a square equivalent.

This is just my perception, the meaning of icons is always subjective, please don't change your mind if you don't consider what I say is reasonable enough. :-)

Hehe fair enough.
Ok since Hanna doesn't have time at the moment and I really want to finally get this out let's roll it out and refine when we got some more feedback and Hanna has more time again. (I want to get this out now because we get a lot of feedback that the current state of suggestions being marked as violations is a very bad message for new/less experienced editors.)

This has two patches is +2 but doesn't seem to be merged looks like a duplicated or old one

we moved it to peer review because there were patches for it, but now I'm not sure if that's correct. What should be the status of this?

Change 486088 abandoned by Lucas Werkmeister (WMDE):
Add icon for constraint suggestions

replaced by Ifc7a2077ec

Change 493450 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add icon for constraint suggestions

As far as I’m aware this still hasn’t been implemented beyond the addition of the icon. It should probably move back to the “To Do” column.

Talked to Lucas. The remaining steps are:

  • implement support in constraintparameterparser
  • implement support in delegatingconstraintchecker

Change 500495 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Add new constraint status for suggestions

The [wbcheckconstraints documentation on]( describes the status like this (emphasis added):

The main status of the result. The main statuses are compliance, violation, and warning (violation of non-mandatory constraint). Other statuses include exception (entity is an exception to the constraint), todo (unimplemented or unknown constraint), bad-parameters (parameters of the constraint definition are broken), and deprecated (constraint check skipped on deprecated statement). While the API is still evolving, other statuses may be added without prior notice.

Do we want to make use of this, or should we announce this as a breaking change per the stable interface policy? That means we have to wait at least two weeks before deploying the change to Wikidata (but during that time the change should already be available for testing on Test Wikidata).

@Lucas_Werkmeister_WMDE Is there any chance that the change make people's tools break (eg if they are checking the level of the constraint in their code)?

I think so, yeah – they’ll need to decide whether they want to treat suggestions like other constraint violations, ignore them, or treat them separately. (Strictly speaking, things will only start to break once editors on Wikidata start using the new status, not immediately with deploying this feature, but I imagine that’ll happen pretty soon after.)

Then, let's go the safe way and treat it as a breaking change :)

See T220028, in case you're interested, find the proposed changes reasonable and can make the most of the breaking change.

@abian Thanks! We'll take some time to study your proposal. But just to make it clear, for now we will go forward with the levels we have.

The plan for the process:
✅ April 8th: Announcements: new constraint level to come & breaking change
✅ Latest on April 22th: test system ready and announced
⬜ May 2nd: deployment (not activated)
⬜ May 6th: enabling

@Lea_Lacroix_WMDE, thank you! There are some things about the change that I wonder on T220028; for example, will suggestions be the new default/unspecified level (when there's no qualifier defined)?

@abian No, for now the default level will still be the "normal" level, suggestion will be a new qualifier to be added.

Breaking change process on its way:
✅ April 8th - Announcement
✅ April 17th - Enabling on
⬜ May 2nd - Deployment (not enabled)
⬜ May 6th - enabling the config change

Well, deployment will need to happen before April 17th if we want to enable the feature on then. So Ia76615712b should be merged soon…

Change 500495 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Add new constraint status for suggestions

Change 502490 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Update references to possible constraint statuses

Change 502490 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Update references to possible constraint statuses

@Lucas_Werkmeister_WMDE Everything's fine for deploying on test tomorrow? :)

Now it is, yes, but thanks for the reminder :)

Mentioned in SAL (#wikimedia-operations) [2019-04-17T11:38:00Z] <lucaswerkmeister-wmde@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:504380|Enable suggestion constraint status on testwikidata (T221108, T204439)]] (duration: 01m 01s)

I guess I can't test it in prod today, since it's not activated, so I'll test on Monday once it's enabled :)

Change 508303 had a related patch set uploaded (by Alaa Sarhan; owner: Alaa Sarhan):
[operations/mediawiki-config@master] Enable Suggestion Constraint Status on Wikidata

Change 508303 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable Suggestion Constraint Status on Wikidata

And announced! Let's keep this task open for a few days, in case people come up with bugs or issues, and then we'll close it.

Michael subscribed.

Should be fine to close now.

Change 721266 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/WikibaseQualityConstraints@master] Add suggestion status to API documentation

Change 721266 merged by jenkins-bot:

[mediawiki/extensions/WikibaseQualityConstraints@master] Add suggestion status to API documentation