Last modified: 2012-03-21 22:35:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 21921 - most popular related articles
most popular related articles
Status: NEW
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
: 6689 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-21 23:17 UTC by James Salsman
Modified: 2012-03-21 22:35 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description James Salsman 2009-12-21 23:17:35 UTC
During a #wikimedia-strategy brainstorming session, regarding a Question of the Week:
"What changes to Wikimedia's technology would enable a friendlier and more welcoming 
environment?") it was suggested that the main issues could be addressed thusly:

[20:20] <jimmyps> we could address the first two (tallest) bars on
                  http://strategy.wikimedia.org/wiki/File:091207_QOTW.png
                  simply by publicizing statistics from http://stats.grok.se
[20:21] <eekim> jimmyps: the key question is, how would you publicize it, 
                and how would you measure if you were being effective?
[20:22] <jimmyps> eekim: for each article find the top 10 articles 
                  also in its categories and list them in order on the 
                  sidebar after the interwikis with "x,xxx views/month" 
                  right-justified on every other line after each of the 10
[20:23] <jimmyps> that would indicate to people the most popular subjects 
                  that they are also interested in
[20:23] <jimmyps> this could be done in batch mode
[20:25] <jimmyps> does anyone disagree that listing the most popular 
                  "related articles" with their viewership counts on the 
                  sidebar after the interwikis would address the largest 
                  leftmost two bars on 
                  http://strategy.wikimedia.org/wiki/File:091207_QOTW.png ?

(no disagreements were forthcoming)

Would someone who understands what is and is not possible with bots and MediaWiki please comment on the feasibility of this proposal? Thank you. 99.62.186.125 (talk) 04:49, 9 December 2009 (UTC)

    it would be possible, the best method would probably be a toolserver acc with a javascript function that retrieves the data from the toolserver once we set the rules for what is and is not related. βcommand 04:52, 9 December 2009 (UTC)

        Even better would be to have a statistics tab next to history. With graphs of metrics like readability, bytes size, html size, word count, number of references, incoming link count (backlinks), outgoing link count (links), traffic statistics, and possibly something like history flow. And maybe be able to compare to other pages. If the caching is done right it could be done on the toolserver. — Dispenser 05:41, 9 December 2009 (UTC)\

        Perhaps 'related' is everything wikilinked and everything in the same categories? 99.62.186.125 (talk) 18:29, 9 December 2009 (UTC)

            The same algorithm as related changed I would say. Rich Farmbrough, 09:20, 15 December 2009 (UTC).

Note:  per http://stats.grok.se/about the statistics are not from the toolserver, they are from http://dammit.lt/wikistats/ -- per Brion, the upstream data is from a wikimedia internal source.
Comment 1 James Salsman 2009-12-21 23:19:21 UTC
*** Bug 6689 has been marked as a duplicate of this bug. ***
Comment 2 Priyanka Dhanda 2009-12-29 21:12:13 UTC
After  some discussion on #mediawiki this is what I gathered.
Pageview tracking is disabled on Wikipedia because of performance reasons.
Erik Zachte already does some analysis of Squid logs but I am not sure about the accuracy, frequency and technical details.

So I am adding Roan and Erik to this thread :)  
Comment 3 James Salsman 2010-01-05 00:26:35 UTC
(#mediawiki) rtmprus: domas: is bug 21921 with a round-robin iteration of article space more appropriate for the toolserver, dammit.lt, or somewhere else?
[4:12pm] Platonides: I don't see any work there for dammit.lt
[4:13pm] rtmprus: I don't want to pound its bandwidth if local copies of popularity logs aren't available on the toolserver
[4:13pm] Platonides: it would be a work for the toolserver
[4:13pm] Platonides: or http://stats.grok.se if he wants to do it
[4:13pm] Platonides: the toolserver already downloads copies
[4:13pm] Platonides: they are at a common folder
... rtmprus: oh good
Platonides: I don't completely understand the algorithm they propose, but it
surely can be done
[4:17pm] rtmprus: someone suggested members of the same categories and
wikilinks, and someone else suggested the Special:RecentChangesLinked algorithm
Comment 4 James Salsman 2010-04-04 19:57:35 UTC
Thanks to mikelifeguard, https://wiki.toolserver.org/view/User-store says squid traffic logs live in /mnt/user-store/ on the toolserver.
Comment 5 James Salsman 2010-04-04 19:58:27 UTC
[12:57] <mikelifeguard>  jps: river said "A user has made this available in raw form at /mnt/user-store/stats"

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links