Talk:Requests for comment/Reimplement info action

Number of watchers
Should the number of watchers be exposed? As far as I know, that information is considered sensitive, because attackers could use it to attack unwatched pages. For example, toolserver rules limit the use of such information. Svick (talk) 21:41, 9 July 2012 (UTC)
 * I've never understood the point of restricting it. Without knowing who the watchers are, it's impossible to know if you have 25 watchers who are inactive or 1 watcher who is actively monitoring the page.
 * That said, it could be placed behind a new user right. Limiting it to a specific group of users might change it from expensive to inexpensive. --MZMcBride (talk) 22:10, 9 July 2012 (UTC)
 * Well, Special:UnwatchedPages requires the  right, normally given only to the sysop group. (Hasn’t also some privacy issues been raised in a similar context before? Not sure.) --Mormegil (talk) 10:08, 10 July 2012 (UTC)
 * Watchlist data is considered private, yes. Only you (or anyone you give your watchlist token from Special:Preferences to) can see your watchlist. There's an expectation of privacy there. But the aggregate numbers aren't very sensitive, in my opinion. Knowing how much a page is watched is a very rough interest metric (i.e., people usually watch a page because they have some interest in it, that's all we roughly know). The side issues about vandals using it are kind of stupid. --MZMcBride (talk) 05:39, 11 July 2012 (UTC)

What is the advantage of displaying this information?
Not to say that I am against it, but it would help if there were user stories or some kind of description of what advantage this provides to people (esp. non-developers) over any current avenues for obtaining such info. Steven Walling (WMF) &bull; talk   22:28, 9 July 2012 (UTC)
 * Can you elaborate on what you mean by "current avenues"? I think if you try to trace the routes needed to get this kind of typical metadata from a page, you'll quickly realize the value of having a dashboard for this info. :-) --MZMcBride (talk) 02:34, 10 July 2012 (UTC)
 * I just meant that unless you've already went hunting for this info, it's not clear whether you can find any of it currently. Stating the obvious might be a bore, but helps show how necessary the change is. Steven Walling (WMF) &bull; talk   20:57, 17 July 2012 (UTC)
 * I agree that example use cases would be useful in order to determine what type of data to include (Sure we could also list how many times the letter e was used on ?action=info, but no one would care.) Bawolff (talk) 19:49, 20 July 2012 (UTC)


 * It took me a while to understand what you meant by this comment, but I think you mean that the "Background" section should be expanded. I agree. Currently, the section only discusses the history of the implementation of the feature (mostly from the code revision view). The section doesn't discuss the possibility or impossibility of retrieving this information currently. For example, some of this information is currently only available on the Toolserver. I'll work on expanding this section a bit, though you're absolutely right that stating the blindingly obvious is painful. :-) --MZMcBride (talk) 01:10, 22 July 2012 (UTC)

Redesign difficulty: audiences
I'm currently working on mock-ups for a redesign of this action, but I'm hitting a wall when I try to consider the different audiences of a page like this:


 * reader
 * editor
 * power editor

For each of these groups, the most important/relevant information is vastly different, I think. I'm hoping that putting all of the desired data points in the mock-up will lead to a revelation about how to lay out and arrange the page. I suppose we'll see what happens. You can use different groupings, you can adjust and tweak the linear hierarchy of the page, you can possibly add some JavaScript collapsibility and a user preference, etc. There are many other options as well.

Just some thoughts here, in case anyone else has a good idea about the layout. I've also considered crowd-sourcing the problem. If I can get the code written, the layout is somewhat irrelevant. The feature can simply be deployed to the English Wikipedia and the users there will quickly tell me how to lay out the page precisely (cf. Cunningham's Law). (o; --MZMcBride (talk) 01:24, 22 July 2012 (UTC)


 * I can't imagine readers caring about any of these, for a number of reasons, except maybe the dates of creation (already available) and last edit. As for the rest, it's not going to be as visible a button as "edit" or "history", and it shouldn't be considered a new toolbar of sorts, entry point of multiple other tools. For this reason, I think it's ok for info related to editing to stay in action=edit, for instance the transcluded templates (which are also available in WhatLinksHere); and for information which help use history to be in the history, as almost all those external tools currently linked from the history legend. There shouldn't be big a distinction between editors and power editors (or between readers who care about the history of the page and other detailed info and editors) and API-like information which a human can immediately see on the page (e.g. if it's a talk with LQT) should be left to API, IMHO. --Nemo 20:50, 22 July 2012 (UTC)


 * I think you're wrong about readers not caring. Readers are often interested in number of edits to a page, number of page watchers, number of recent edits/editors, and they're certainly interested in page view statistics.
 * In other discussions about this page, some people have said it makes sense to focus mostly on editors and power editors here. Provide as much information as possible for now and if it makes sense to make a simpler page for readers in the future, do so. I tend to agree.
 * Some information may be duplicated across multiple places (such as transcluded templates). Or perhaps those will just stay below ?action=edit, though there are tangential issues regarding layout and that long list that really must be addressed.
 * Most of the issues you're discussing have been deliberately split out into separate Bugzilla bugs, so that they can be discussed individually. The relevant bugs should all be linked from the RFC and the tracking bug. You should definitely comment on the specific bugs if you have time. :-)
 * I somewhat agree with LiquidThreads status being obvious, though in some ways it's better to be explicit. I had underlying thoughts about possible gadgets/scripts that could add a (change) link next to some of these items (such as DISPLAYTITLE, DEFAULTSORT, UseLiquidThreads, etc.) and then allow users to easily change their values from ?action=info (click change --> input area pops up, change text, ajax save and refresh). Again, though, these are separate bugs and none of them really depend on any others to be implemented. This includes the UI exposure (which I'm not very fussed about).
 * Do you see the virtue in re-activating ?action=info generally? --MZMcBride (talk) 21:03, 22 July 2012 (UTC)

Applicability to old revisions
Would this allow info about old revisions to be listed (if the  parameter is specified)?

There seem to be three types of info: For example, links can be enumerated from mediawiki tables (in relation to the current revision), or could be calculated from parsing the wikitext for former revisions (at greater burden).
 * 1) data relating to the page itself (regardless of revision);
 * 2) data easily extracted from the relevant revision (old or new);
 * 3) data easily extracted for the current revision but requiring parsing or complex queries to extract for old revisions.

Would it be helpful at this early stage to indicate which items fall into which of the above types? The layout could then reflect this so that it remains coherent and unambiguous if/when the oldid parameter becomes supported.

— Richardguk (talk) 02:06, 23 July 2012 (UTC)