Extension talk


From WikiApiary, monitoring the MediaWiki universe

Reduce noise

The "rank" table should, if possible, exclude the biggest wiki farms to reduce noise. --Nemo 07:36, 20 June 2014 (UTC)

I agree. Probably best by adding standalone and farm website count properties to extension pages, then querying/sorting by those (this would remove all farms, not just big ones). Probably also worth splitting some of the reports into farm and non-farm. I'll put it on my to do list, unless someone pops by to disagree/give an alternate plan.--ete (talk) 09:58, 20 June 2014 (UTC)
Yeah, though I do not think that we should remove all farms. "Industry strength" starts probably at about 100 wikis. However splitting into farms and standalone wikis will indeed be nice. Another nasty thing is that currently even the stats for defunct wikis appear in the list. This should be tackled, too while we are at it. --[[kgh]] (talk) 19:11, 20 June 2014 (UTC)
By "biggest" I meant those above 1000 wikis. If, say, wiki-site has 2500 wikis with $random_extension that's not particularly interesting. :) --Nemo 19:29, 20 June 2014 (UTC)
Cutting out defunct wiki stats is also a good idea, will do. It would be possible to leave in small farms, but imo it would be much neater to have standalone, farm, and total stats, and just decide to display the standalone stats first (with links to farm stats, or a table below). Leaving in just language farms or small farms is an option, but I think it would overcomplicate things (e.g. labels, queries, property names), and farms have a kind of disproportionately huge impact. I think separating out farms fully likely would leave interesting but rarely used extensions (because no big farm has picked them up) higher in the ratings, and farm ratings would be available too if people are interested in that.--ete (talk) 19:36, 20 June 2014 (UTC)
Makes sense to me. :) Do whatever is easier for you. --Nemo 19:49, 20 June 2014 (UTC)
Well, why not. We still have to additionally differentiate between small <100 and big >100 farms since the first kind is sometimes just a group of three or four wikis in different langs on the same topic probably in some cases just standalone wikis which happen to share the same domain. I will also make sense to create individual overview pages for the >100 farms. --[[kgh]] (talk) 20:01, 20 June 2014 (UTC)

Thanks for continued work, it's looking very useful already. Some lines are suspicious, for instance "DismissableSiteNotice 2,727 2,486 241" but that extension is enabled on all Wikimedia projects so the farm count should be closer to 800. --Nemo 06:27, 24 June 2014 (UTC)

Yeah, this is true and needs to be investigated. Same for Generator main page which is only showing 294 wikis. --[[kgh]] (talk) 09:29, 24 June 2014 (UTC)
 :) I wonder what's going on with that. Will add some links to queries to make it easy to get farm/independent specific lists for extensions to make it easier to investigate, and see why that's happening. Maybe split the table of sites using each extension into shorter farm and non-farm ones? Edit: Looking closer, it seems ShoutWiki and Referata both have DismissableSiteNotice enabled on their wikis, which should account for the rest of the sites (800 wmf + 1200 SW + 100 Referata is most of the way to 2500, probably a couple of other farms use it). --ete (talk) 10:17, 24 June 2014 (UTC)

What to display on the big table

With the farm and standalone counts it's getting a bit packed. It's fine for my size screen (though description could do with a bit more space), but shrinking down it looks a bit cluttered. I'd be in favor of dropping current version and licence from the main query, since licence is only given by a tiny fraction of extensions and version is not particularly interesting with loads of unversioned extensions and the versioned ones not being very consistent often. These columns do help highlight issues in the MW extension ecosystem, but other than that I don't think they provide a lot of value/interesting info to your average reader. Opinions? --ete (talk) 23:58, 23 June 2014 (UTC)

Yeah, version information though useful should probably go for the time being until we have figured out a way to fetch and update this data automatically. To have a version date with it will be a cool thing, too but even harder to implement. However, this is currently bad information, so ... The information about the license is actually pretty cool too, but it does not need to be in the general overview. Perhaps having separate subpages will be a way to go with it. At the moment the license implementation is broken in core anyway so there is not a single reason for developers to add them as originally intended. --[[kgh]] (talk) 09:37, 24 June 2014 (UTC)
hm.. we could have a report page with extensions by licence as well, which would be handy to check every once and a while to see if there's much info there. And date of latest version would also be cool, but probably quite tricky if not impossible with current data? --ete (talk) 10:17, 24 June 2014 (UTC)