I still need to test this. Sorry about the delay on that. I'm out for a couple weeks after the hackathon so maybe @kaldari can help out at some point?

Marking as Declined as we are not working on the prototype script anymore.

Anything left to do here?

Moving this out of the estimation because it involves making a config change that I can take care of once the remaining tickets are done.

@MusikAnimal Sounds good. So the frontend will be done as part of T192579. I'll repurpose this ticket to add backend support for Wikidata. I think it makes sense to work on this ticket next after T192579.

In T193809#4206564, @kaldari wrote:

Using Turnitin would also avoid the faux pas of depending on a Tool Forge tool. Turnitin is a commercial service so should in theory have reliable uptime.

Hmm, I'd say Google is more reliable than Turnitin. Tunitin has a history of unexpected "maintenance" outages as we've seen with CopyPatrol. They also require us to ask them to give us more credits every few months. There is no guarantee that they wouldn't refuse to do that at some point in future.

@MusikAnimal If I can ask for your thoughts on this one too. :)
Splitting this up as one ticket for frontend and one for backend (similar to Commons support). Does that work? We don't have to include Wikidata edits in the revision browser, so we're good on that.

Okay, so here's how I'm gonna split this --

1. Frontend
2. Backend - model changes
3. Backend - stats generation
4. Adding tests

@MusikAnimal Does splitting this into two tickets - one for backend and one for frontend make sense? I'm wondering if the backend should be split further.

Okay, we'll discuss about filtering at some point. I created T194696: Filtering options for view all data page so we don't forget about it.

Making this high priority as it is blocking unrelated tasks from being deployed.

Curiously, raising the priority created a duplicate task, T194680: EchoDiscussionParserTests failing on patches.

Annnnd deployed! Thanks to @Framawiki for making the patch and scheduling it.

In T190456#4205315, @Shouston_WMF wrote:

@Niharika here are the metrics that WMDE collects: https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2016-2017_round_1/Wikimedia_Deutschland_e.V./Progress_report_form#Program_3:_Software_Development_–_Expand_Wikidata_and_Further_Develop_MediaWiki

Thats way more metrics than grantees usually report though.

But to use their language, I think it's just Items created and Items edited?

@Earwig I still think requiring logins on the copyvios tool would go a long way towards saving us time investigating rogue bots using the tool like this. I don't see any obvious disadvantages to logging in. The user does not have to give the bot permission to access its info every time they login, if that's your concern.

On a scale of A to Z, a D is pretty awesome! (Don't tell me that's not the scale :P)

Yeah, I think we're good with what we've got for now, I do see some failed checks on the PR though. Important?

Looks like this works nicely. @MusikAnimal is there anything left to do in order to have backend support for Commons?

Let's re-estimate this since we updated the mock for it.

In T193825#4200916, @MaxSem wrote:

Figuring out when a category is added or removed from an article is a difficult problem

We have categorylinks.cl_timestamp for that.

Okay, let's do that, @Samwilson!

@MMiller_WMF That'll be hard! Figuring out when a category is added or removed from an article is a difficult problem. The databases or APIs aren't any help there.

@Shouston_WMF We're ready to work on this ticket. Are properties and items created the only metrics needed? What about properties and items edited?

@MMiller_WMF stray thought about this - will it help reduce the clickthroughs to Earwig's tool if we also include a link to the page which Earwig's tool tells us is the copyvio source?
As it stands now, the 10k per day limit is frequently reached: T193559#4172586. @MusikAnimal I can get you more data about current usage of the google api if you need.

In T192854#4199299, @Samwilson wrote:

I've updated the draft that is live on CommTech wiki. http://commtech.wmflabs.org/wiki/Test?action=edit

Though this task is older, the other task has more information.

Here's some quick notes from my meeting with Carolyn about the design changes we'll be doing:

• The info icon will instead be a help link/button in the footer on the main page for the wizard. Footers are already used in VE Template editor and TemplateData editor and other places.
• We'll be doing recently used templates for the first screen. (see T194434)
• The dropdown stays at it is in the mock.
• Popups - we're not sure. Carolyn will draw up another mock to try and appease @Volker_E :)
• The template link icon might or might not change - under discussion.
• Template header part will go away and we'll revert to the design we had before with the template heading on top of the right panel.

Yeah, we might end up with more, who knows! I agree that we'd be able to accommodate more if we have to.
Yeah, it's fine if the index page looks different. I'll try to get Sati's opinion on that.

In T190425#4198522, @MaxSem wrote:

Let's try another test deployment, say on Tuesday after the train?

I made a mock to show what I was getting at:

@MusikAnimal Okay. I think for now, we should keep what we have. I played around with it on the staging instance and it looks good. You're right that at some point we would need a wider array of filters and the tabs won't be sufficient. Let's save filtering options for another ticket when we work on it. I'll remember to refer to ideas we brought up in this ticket then.

@MusikAnimal It's an interesting idea but I really think we should split out the projects. The reason I am saying that is it's misleading to show columns for projects which are never gonna fill up. Like pages improved for commons or pages proofread for wikis. We'd inevitably get some people baffled over what those mean and why they aren't being populated. My other concern is mobile devices. Tables don't scale well in mobile and I was really happy that we were supporting mobile as a place where people can quickly and efficiently use this.
I like what Sati suggested in the meeting the other day - we can pull out the fields that are common to all projects (like # of participants, # of new editors and user retention) and show those on top so we don't have to worry about the totals.
How does that sound?

In T194385#4197626, @Tgr wrote:

• seemingly out of sheer spite, notification-new-unbundled-header-login-fail does not tell you the number of failed attempts, which make it hard to assess whether this was someone misremembering their username or a real attack.

A bit more good faith would be appreciated. :)
As you worked out, it was indeed tricky to get that information readily out of Echo so we resorted to showing 'multiple'. I personally think it might make people panic more if they saw the counter. If I recall correctly, in a one-off incident when LoginNotify was first launched there were 100+ attempts made overnight to login to a single user account.
I'm all for rewording the notifications. Something that came up in a team meeting recently was that people didn't realize that clicking the notification would lead to a help page. To mitigate that, we could add a link to the help page in the notification and link to the change password page from the help page instead of the notification.

"Page" heading doesn't go well with Commons. It can be renamed to "Page/File" to temporarily mitigate that.
Good idea about the filtering options. It seems more like a nice-to-have. For now though we should build the tabs to let them see just the commons edits.
I don't think this will expand to 11+ wiki families ever. 4 or 5 at maximum.