Page MenuHomePhabricator

Increase reach of constraint violation gadget
Closed, ResolvedPublic


We would like to increase usage of gadget for constraint violation to:

  • Test stability and efficiency of caching
  • Get more user feedback
    • Measure acceptance
    • Spot problems and pain points
  • Involve more people from the community in constraints definitions and violations

Possible solutions

  • Make it a beta feature

image.png (335×951 px, 36 KB)

  • Introduce a toggle on Item page
    • Not standard, user may have different expectations.

image.png (114×442 px, 5 KB)

  • Toast to enable gadget
    • Maybe complicated to measure

image.png (179×379 px, 9 KB)

Event Timeline

Jonas triaged this task as Medium priority.Jan 3 2018, 2:01 PM
Jonas created this task.

We had a meeting with @Lydia_Pintscher and @Jan_Dittrich to discuss about these ideas.

First of all, a few numbers; 306 users have the gadget activated so far, including 200 active users. The current number of active users is around 20.000. Which means that currently, 1% of the active users are already using the gadget.

We had a look at the 3 options, but none seems really adapted to what we need.

  1. Enabling a beta feature won't really give more visibility to the gadget. In the end, it's the communication around it that will help getting more users
  2. We don't think that adding a new button to the interface on items is a good idea, the interface is already quite full and it's better to keep all the settings in one place
  3. The pop-up thing should be kept for very important messages: people are already overwhelmed by pop-ups on the internet and we don't want to have that on Wikidata as well

Here's what we suggest instead: a communication operation explaining people what we want to do, and why we need their help. It could contain the following elements:

  • inform that we plan to enable the constraint gadgets for all logged-in users (with a date 4 weeks later)
  • explain that in the meantime, in order to test the resources and the caching and make sure that everything goes smoothly, we would love to have more people using the gadget
  • mention that we're still collecting feedback and people testing the gadget can write any comment about it
  • explain that it is also a good opportunity, while testing the gadget, to clean and improve the constraint definitions and the related messages
  • mention that if someone really doesn't want the feature enable, they should voice it now

The idea behind the last point is that, if less than 5 people say that they don't want it, we write a gadget to allow people to disable the constraint checks. If more than 5 active users say that they don't want it enabled, we should probably delay it while we fix the problems people mentioned.

I really believe that people will understand our reasons to ask for more users of the gadget, and some of them will be ready to help. Being transparent on our motivations will work better than a button or a pop-up and will reinforce the trust we try to keep with them.

Here's the deadline I suggest:

  • communication to the community: January 30th
  • enabling the constraint checks for all logged-in users: February 28th

What do you think?

I wouldn’t judge the extra visibility of a beta feature so low, but sounds good to me as well. I just hope we can meet that schedule :)

Note about the schedule: it's a suggestion for the earliest. If you think that the deployment will happen later, we can delay it without problem. I only want to keep the 4 weeks between announcement and deployment, to let enough time for people to test and fix what is needed.

Yes. For the sake of clarity, let’s assume the schedule @Lea_Lacroix_WMDE suggested initially (if we think we can make it) OR suggest a new date. (Both being fine, I just don't want loose it in unclarity about the "when")

From technical aspect I would still suggest a staged rollout, meaning that we start with limited number of users first and then increase load over time so we make sure the cluster can handle the requests.
The criteria should be transparent so users could check. For example user name starting with 'A' first week, 'B' second week ....

What criteria would you suggest and how should this be communicated?
Has this been done before?

@Jonas @Lucas_Werkmeister_WMDE Do we have have any criteria/method to evaluate if a stages rollout is needed and if, how much stages it needs?

If we determined this and a stages-rollout is needed, I think the username-criterion is a good suggestion since it is transparent and fixed.

We (@Jonas and I) looked through the common user name initials on Wikidata and came up with the following proposal for enabling the gadget:

  • week 1: initial Z (we’re starting at the end of the alphabet because A is a very common initial)
  • week 2: initials Y, X, W
  • week 3: initials V, U, T
  • week 4: initials S, R, Q, P, U, N
  • week 5: initials M, L, K, J, I, H, G, F, E
  • week 6: everyone else (including non-ASCII initials)

This excludes e. g. Cyrillic and Greek user names until week 6, so the announcement should point out that everyone can still enable the gadget if they want to try it out earlier.

(To clarify: week 1 would be the week of February 28th, so the roll-out would be complete in the middle of April.)

Sounds okay?

Change 403459 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Gradually enable constraints gadget for all users

Change 403920 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Gradually enable constraints gadget for all users

Change 403459 abandoned by Lucas Werkmeister (WMDE):
Gradually enable constraints gadget for all users

Abandoned in favor of I6265d45578.

Change 403920 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Gradually enable constraints gadget for all users

Okay, rollout is merged, starting on March 1st (so that new users always start just after the train moved forward). We still need to do the announcement, I’ll try to start a draft.

To clarify, here’s the initial rollout date again for each initial letter (I think according to the code we start on March 1st, not February 28th):

  • 2018-03-01: initial Z (we’re starting at the end of the alphabet because A is a very common initial)
  • 2018-03-08: initials Y, X, W
  • 2018-03-15: initials V, U, T
  • 2018-03-22: initials S, R, Q, P, U, N
  • 2018-03-29: initials M, L, K, J, I, H, G, F, E
  • 2018-04-05: everyone else (including non-ASCII initials)