Page MenuHomePhabricator

Make sure Category filter can track metrics for local file uploads
Closed, InvalidPublic

Description

Unlike Grant Metrics, Event Metrics provides organizers with statistics about files uploaded to individual Wikipedias (as well as about files uploaded to Commons). Category Filters, in general, find Main namespace changes. We need to make sure that if organizers are using categories to define an Event, the system will track file uploads made to those categories.

From a UX standpoint, the simplest way to do this would be to always search the File namespace. If the effect of doing so on performance is too substantial, we could look at ways to mitigate-e.g., by making users select a preference, either overall or for individual categories.

See T206819 for details about tracking files uploaded to local wikis.

Event Timeline

@MusikAnimal, I wasn't sure I'd stated the problem above properly. Does what I wrote cover it?

So we only want to check for local file uploads when given a category, and not always?

I don't think checking the File namespace will be too bad, it's much smaller than the mainspace. We'll find out when we get there.

T206819 should probably be a subtask not a parent, since it must be done first (or maybe I have the subtask vs parent task concepts reversed?)

So we only want to check for local file uploads when given a category, and not always?

No, I didn't mean to imply that. Always check the File space.

T206819 should probably be a subtask not a parent, since it must be done first (or maybe I have the subtask vs parent task concepts reversed?)

Do what works best for you. Yes, generally a subtask means it has to be done first. But it also means that it is a part of a larger whole, and in this case it seems like this is a part of the overall method required by T206819. (In fact, it's not clear to me we need this ticket at all—should it just be incorporated as a stipulation of T206819?)

In fact, it's not clear to me we need this ticket at all—should it just be incorporated as a stipulation of T206819?

Yeah that was my thought. I will say we should avoid any preferences, methinks, unless we see product value in having one. We'll find out when we get to working on T206819 (hopefully soon!)

So should I close this ticket and just put some of it into T206819?