This allows WMF to train their models with the new training data provided by users here.

Currently we only support auto feed. Therefore, we have less control of the speed. Sometimes it also happens when trying to mark a revision with a Judgement, it shows the next revision, and caused the judgement click on a mistaken card.

We need to update the collection Interactions with an additional field of wikiRevId = ${recentChange.wiki}:${recentChange.revision.new}.

Here is a mongodb shell command to do so.

print("Start...");
db.getCollection("Interaction").find({}).forEach(function(doc) {
  doc.wikiRevId = doc.recentChange.wiki + ":" + doc.recentChange.revision.new;
  db.getCollection("Interaction").save(doc);
})
print("Done!");

Here's the Weekly Digest for xinbenlv/learn-vue-nuxt:

ISSUES

Last week, no issues were created.

PULL REQUESTS

Last week, no pull requests were created, updated or merged.

COMMITS

Last week there were no commits.

CONTRIBUTORS

Last week there were no contributors.

STARGAZERS

Last week there were no stargazers.

RELEASES

Last week there were no releases.

That's all for last week, please 👀 Watch and ⭐ Star the repository xinbenlv/learn-vue-nuxt to receive next weekly updates. 😃

You can also view all Weekly Digests by clicking here.

Your Weekly Digest bot. 📆

We should number of judgements made on the page for total, last 7 days and last month.

Suggestion from User:Fuzheado:

• It would be good to explain when mousing over the icons of faces and cloud what they mean. Right now all I see is "from WMF ORES score" and even though I'm familiar with ORES, I'm not sure what these mean.
• If the username of the person who made the edit in question has no user page, it would be nice to display the name in red (See "User:Jkmistry17") because for vandal fighting, it helps to see whether the person editing is very new and a red userpage link helps in determining this.
• I think I know what "Overriden" means (someone else has acted on it already) though this is a bit confusing. Perhaps a better or more detailed message here?
  Great work though. A really useful tool. -- Fuzheado | Talk 10:55, 9 July 2019 (UTC)

As defined in #23. We determine to keep it in mongodb the collection of Interaction.

{
      userGaId: <userGaId>,
      wikiRevId: <wikiRevId>, // New
      judgement: <judgement>,
      ...
}

FR: support batch request and pagination major APIs: /api/interaction, /api/revision, /api/ores.

We will not create batch api for /api/diff

So people can start instead of empty page showing "please wait for the first vandalism to come up"

Originally we use RecentChangeId because we directly store what we get from EventStream. But it turns out RecentChangeId is not very well supported by Action API to be queried. Instead, RevisionId is. So we want to switch to RevisionId to identify a revision.

In addition, the MediaWiki Wiki Farm relies on a wiki (such as enwiki) identifier to identify which wiki instance is. Therefore, a WikiId + RevisionId will uniquely identify a revision.

• define schema location for wikiRevId
• write to wikiRevId into the database
• databasee migration: create a wikiRevId = `${wiki}:${revId}`
• read and query from wikiRevId instead of _id, dbId etc.
• rewrite _id to random generated id

I think I know what "Overriden" means (someone else has acted on it already) though this is a bit confusing. Perhaps a better or more detailed message here?
Great work though. A really useful tool. -- Fuzheado | Talk 10:55, 9 July 2019 (UTC)

From #26

Debug notes:

1. It only happens when API is being called.
2. The CID keeps getting changed.
3. Probably caused by we are not setting cookies in axios.

Not sure if POST will work, due to axios/axios#1661

Trackers for potential frontend performance issue caused by how we store revisions / recentChange in the frontend.

1. Fix the version number, currently showing vundefined
2. Change to "The tool's edit summary is also a bit off at the moment (containing "vundefined"), maybe it could be changed to a more descriptive "Identified as test/vandalism using [[m:WikiLoop Battlefield|WikiLoop]]"?"

It should be possible for us to fetch the full list of revisions reversion and list of Wikipedia authors who used our tool to revert things directly from Wikipedia articles. For example

For example, in the page of [Crime_in_New_York_City](https://en.wikipedia.org/w/index.php?title=Crime_in_New_York_City&action=history Wikipedia article history shows

 2019-07-30T09:53:15‎ PerinPeron21 talk contribs‎  201,281 bytes -7‎  Undid revision 908582516 by 69.127.235.116 (talk): Identified as test/vandalism using m:WikiLoop Battlefield(version 1.1.0-alpha-1) at battlefield.wikiloop.org. undothank Tag: Undo
 2019-07-30T09:52:41‎ 69.127.235.116 talk‎  201,288 bytes +7‎  undo

1. Get a list of all revisions. We have it in our own database MongoDB collection interaction
2. With the full list of revisions, we can get the page titles of them by making request to MediaWIki Action API similar to this API call

    const fetchUrl = new URL(`${getUrlBaseByWiki(wiki)}/w/api.php`);
    let params = {
      "action": "query",
      "format": "json",
      "prop": "revisions|info",
      "indexpageids": 1,
      "revids": revIds.join('|'),
      "rvprop": "ids|timestamp|flags|user|tags|size|comment",
      "rvslots": "main"
    };
    Object.keys(params).forEach(key => {
      fetchUrl.searchParams.set(key, params[key]);
    });
    let retJson = await rp.get(fetchUrl, {json: true});

3. With a full list of Revision -> Article Title mapping, we can get the full list of Articles being reverted by us. We can query the next revision after the revision we have (because our Revert only work for 1 immediate revision so it must be next one).

4. For these revisions we can filter by comment Text and We can get UserName of them.

In summary this is a hacky-workaround of the following pseudo SQL query

SELECT revId, userName FROM WPRevisions
WHERE comment contains "wikiloop"

We can basically get a list of all our revisions being labeled as vandalism and proceed to make batch query to MediaWiki to get their subsequent revisions to find any comments that has our WikiLoop fingerprint.

Alternatives Solutions pending Feature Request at Wikipedia Instance / MediaWiki Software FR

Alternatively, we can ask the Wikipedia to allow we provide a tag filtering of WikiLoop Battlefield. Currently under approval https://phabricator.wikimedia.org/T226459

Also alternatively, we can ask the MediaWiki to provide revision querying with given text substring / ideally also RegEx. This can be easily provide through https://phabricator.wikimedia.org/T229361

https://github.com/github-changelog-generator/github-changelog-generator seems good

Currently, for a revision, the judgement is a plain array. So when a user click on a button the second time, another judgement will be made to the same revision, from the same user.
We need to remove the previous judgement.

As suggested in
https://en.wikipedia.org/wiki/User_talk:Xinbenlv#Wikiloop

I wanted to point out that you might get quite a few incorrect results as the user's edit summary is currently hidden in Wikiloop's user interface. Edit summaries often contain an explanation for why an edit was made, so it's not really possible to decide if reverting is the right action.

Currently only the home page, or the index.vue supports receiving interaction and update the related RecentChangeeCard to mark what user have updated. We should also do the same in /mark or th emarked.vue to do the same

If the username of the person who made the edit in question has no user page, it would be nice to display the name in red (See "User:Jkmistry17") because for vandal fighting, it helps to see whether the person editing is very new and a red userpage link helps in determining this.

Related to #26

I love using your tool, one possible improvement could be setting languages as filter, as I can be interested for example in reviewing English and Spanish edits, while ignoring the rest, and other users may have other language preferences.

Great work!

Credit to west.andrew.g @westand, we are granted readonly access to the MySQL DB of STiki score.

We will implement the feature to include STiki score as one of the input of scores.

If too long there is no card to review, the editor's time is wasted. We can use their attention to rate some lower risk cards.