@cmadeo - Pushing back on the bell notification: this is not actually an Echo notification, so let's please not mix them up.

Subtasks for:
Blue dot
Red dot
Dialog
Notification

@cmadeo -
Please remove image on top of dialog box so that we don't have to build a custom one.
Can you also confirm what tapping on the system notification does?
Also, what is the ordering for the dialog vs. the system notification? Do they come up at the same time?
Primary vs. secondary action in the dialog? Both actions have the same visual weight, so this could be confusing.

In T207333#4725543, @Charlotte wrote:

Please remove image on top of dialog box so that we don't have to build a custom one.

Would it be possible to keep the image on the dialog box? iOS supports an image for dialog boxes so I think that may have been part of why they were introduced in @RHo's designs here.

Can you also confirm what tapping on the system notification does?

My understanding is that tapping on the system notification would open the app to the Edit tasks queue, but I have some questions about the system notification (please see below)

Also, what is the ordering for the dialog vs. the system notification? Do they come up at the same time?

This is a good question that I'm not 100% sure about the answer to. I am wondering now if the system notification was meant to show sometime after the user has dismissed the dialog by selecting 'Maybe later'? My assumption would be that the dialog would show immediately after the user submits their N th Title description edit, therefore the system notification wouldn't make a lot of sense to show on top of the app or in the notification center. Was there a time where we thought that the dialog couldn't be triggered immediately after the user passes the threshold for unlocking the edit action queue? @RHo, would you mind sharing your thoughts on this?

Primary vs. secondary action in the dialog? Both actions have the same visual weight, so this could be confusing.

Updated the mock to move 'Maybe later' to a secondary action

In T207333#4736555, @cmadeo wrote:

In T207333#4725543, @Charlotte wrote:

Please remove image on top of dialog box so that we don't have to build a custom one.

Would it be possible to keep the image on the dialog box? iOS supports an image for dialog boxes so I think that may have been part of why they were introduced in @RHo's designs here.

It is certainly possible, but will require a good deal of work and ongoing maintenance. Unless there is a specific reason we need the image that justifies the extra development time, I would rather simplify by removing it.

Can you also confirm what tapping on the system notification does?

My understanding is that tapping on the system notification would open the app to the Edit tasks queue, but I have some questions about the system notification (please see below)

Also, what is the ordering for the dialog vs. the system notification? Do they come up at the same time?

[...] My assumption would be that the dialog would show immediately after the user submits their N th Title description edit, therefore the system notification wouldn't make a lot of sense to show on top of the app or in the notification center. Was there a time where we thought that the dialog couldn't be triggered immediately after the user passes the threshold for unlocking the edit action queue? @RHo, would you mind sharing your thoughts on this?

This would be good to know - we don't want to overwhelm the users with too much at once.

Primary vs. secondary action in the dialog? Both actions have the same visual weight, so this could be confusing.

Updated the mock to move 'Maybe later' to a secondary action

Thanks!

@Charlotte I checked in with Rita and the system alerts were intended for the case where users would not be approved until after their 'n'th edit wasn't reverted after a waiting period.

For this first iteration will we be able to track revisions?

@Mholloway pinging you on this ticket as we have a technical requirement for tracking revert rates for title description edits (and image caption edits) for this feature.

n.b. Estimated based on the idea that there is a magical back end box that gives us the revert rate.

In T207333#4747272, @Charlotte wrote:

n.b. Estimated based on the idea that there is a magical back end box that gives us the revert rate.

There is no such magic box, unfortunately. Actually, I'm very skeptical about the notion of calculating and/or tracking reversions or revert rates as a requirement for this feature, and here's why:

Reversion is more of a community-consensus concept than a technical capability of MediaWiki, and is broadly defined: "Any method of editing that has the practical effect of returning some or all of the page to a previous version counts as a reversion." (Note that this is defined in an enwiki help page rather than the MediaWiki manual; it's actually not obvious to me that other communities besides the English Wikipedia have the same concept of "reverting.")

The undo and rollback tools are common methods of reverting one or more edits, but their use is only indicated by a tag and a comment to the revision reverting the reverted revision(s) (which will differ by language). There is no property of an edit (revision) that we can look to in the revision table to see whether it's been reverted; rather, to get the revert rate, for each of a user's edits, we'd have to look at every revision to the same page / item occurring after the edit to see whether the content has been restored to the version prior in whole or in part. (As an analogy, think of looking at every post or comment you've ever made on Facebook to see whether someone later commented and disagreed with you.) This isn't a viable thing to do for users with any more than a tiny number of edits.

In my opinion, simply looking at the number of edits for the type of content in question (title descriptions or image captions), without worrying about the revert rate, should suffice. My sense ({{citation needed}}) is that by far the majority of wiki vandals tend to make one or two abusive edits and then get bored and move on in life; and if not, they get their accounts banned. (Furthermore, as @Dbrant pointed out, there are other ways for a clever and determined individual to game the system proposed here, such as by quickly adding a high-quality title description one letter at a time.)

I can imagine ways of making the search for "reverts" somewhat more tractable, such as by limiting the search to software-generated undo/rollback comments or tags, and limiting the search only to the following edit; still, for an MVP I'd strongly recommend the more modest approach of keeping a simple tally of the number of relevant edits in the app itself, and not overcomplicating the matter by worrying about reverts.

hi @Mholloway - apologies for not being clearer on the original design doc but the idea did not require tracking a "revert rate" per user per se. Rather, once we determine the amount of edits to 'unlock' (let's say it's 20 edits), then when a user makes the 20th edit, we wait for a set time (eg., 48hrs) to see if there is *any* revert activity. If there is not, we will unlock the next task queue.

Since we do send a special notification to the user when their title description has been reverted (T150477), can the check basically be if this notification is *not* triggered during the determined timeframe?

Ahh, thanks for clarifying, @RHo, that sounds a lot better. So, just to be clear, am I correct in thinking that the user edit tracking piece would look like this, and not require any special backend?

• The app records a tally of qualifying edits by the user
• When the user hits magic number n edits of the relevant type, an in-app timer kicks off
• If no revert notification is received within t + 48 hours (or whatever), the app unlocks the editing feature

(As an aside, it looks like the revert notification is indeed hooking into undo/rollback actions.)

If we wanted to sync the qualifying edit count across devices, rather than have it be specific to a single device/installation, we could store it in user json along with whatever other user preferences we're currently syncing. If for some reason we need to store more than a simple count for a small number of edit types (such as info about the specific revisions), then we might have to think about a more serious backend, but based on what I've seen there wouldn't seem to be any need for it.

In T207333#4754569, @Mholloway wrote:

Ahh, thanks for clarifying, @RHo, that sounds a lot better. So, just to be clear, am I correct in thinking that the user edit tracking piece would look like this, and not require any special backend?

Yes thanks!

• The app records a tally of qualifying edits by the user
• When the user hits magic number n edits of the relevant type, an in-app timer kicks off
• If no revert notification is received within t + 48 hours (or whatever), the app unlocks the editing feature

(As an aside, it looks like the revert notification is indeed hooking into undo/rollback actions.)

If we wanted to sync the qualifying edit count across devices, rather than have it be specific to a single device/installation, we could store it in user json along with whatever other user preferences we're currently syncing. If for some reason we need to store more than a simple count for a small number of edit types (such as info about the specific revisions), then we might have to think about a more serious backend, but based on what I've seen there wouldn't seem to be any need for it.

I agree about keeping it simple for now. There might be some implications for privacy opt-in requirements if we start tracking more info.

@Mholloway The app should not be tracking the tally of qualifying edits, because if the user deletes their phone data they will have to start again. So user json sounds like a better option here - and has the added benefit of tracking cross-device while keeping the requirements simple and lightweight. Otherwise I think we're set here. Huzzah!

cc @Jhernandez - Fortunately this answers what we just spoke about!

Just FYI, there is some ongoing conversation in an email thread with the engineers about the specifics of this part 👍

Change 480263 had a related patch set uploaded (by Dbrant; owner: Dbrant):
[apps/android/wikipedia@master] [WIP] Add dialog that's shown when editor tasks list is unlocked.

https://gerrit.wikimedia.org/r/480263

For future reference from here, there's an open task for adding methods for revert detection to MediaWiki: T152434: Add method to Revision to check if it was a Revert, and whether an edit was Reverted. It discusses some of the same difficulties mentioned above and contains quite a bit of other useful info.

Change 480263 merged by jenkins-bot:
[apps/android/wikipedia@master] Add dialog that's shown when editor tasks list is unlocked.

https://gerrit.wikimedia.org/r/480263

Moving this back to the “Needs Design/Design doing“ column since notifications will be reconsidered. And there will be modifications to the flow/screens based on feedback from usability testing.

This is a legacy task for “Editor tasks“ prototype. All changes will be addressed in T215630. Moving this to “Ready for signoff“.