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 unwatchedpages 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)

The info action already restricts this information to those with the unwatchedpages right; I don't think there's any real need to change that as part of this rewrite. Madman (talk) 16:52, 2 August 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) • 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) • 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. m: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)

Speaking of page view statistics, the info action already displays this information if wgDisableCounters is false. (Actually, I think there's a bug there; it collects the information in pageCountInfo if wgDisableCounters is false, but will display the information if wgDisableCounters is true.) Where would that information be in your mockup? (I'm working on implementation of some of this.) Madman (talk) 16:55, 2 August 2012 (UTC)

Note, the collected page view stats for Wikimedia is currently not integrated with MediaWiki (and probably it would require some effort to include, although i suppose we could have outside scripts just stuff it in the db, have some hooks to override fetching view data from the page table, and then everything could live in a happy view statistic land with rainbows and unicorns) [actually now that i say that out loud, that sounds like a wonderful idea. We should be doing that, its stupid to have all this data so not integrated with MW. Although internal view counters assume stats are for all time, and not a specific time slice would probably have to be changed]. Bawolff (talk) 19:28, 2 August 2012 (UTC)

Applicability to old revisions

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

There seem to be three types of info:

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.

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).

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)

This reimplementation has only considered acting on the most current information. I'm not sure I see the value in supporting old revisions. As you note, calculating most of this information would be expensive and would introduce a mountain of ambiguity into many of the data points (total number of revisions, e.g.). Is there a good reason to support info about old revisions? --MZMcBride (talk) 05:10, 23 July 2012 (UTC)

Well, some of the information about a specified old revision could very easily be extracted (e.g. page length), and most of it could be calculated with modest effort using fallback queries for non-current revisions (reparsing old wikitext). So, why not? Placeholder error messages could be shown for items not (yet) implemented for non-current revisions, which would keep the layout consistent and be more helpful than failing to provide the subset of information that is easily extractable. Factoring in this consistency at an early design stage would avoid disruption from changing the layout if/when the option were added subsequently.

But my overriding point is that it may be helpful to present the information in a layout which reflects the distinction between page-level and revision-level info (even while oldid is not implemented): to reflect the underlying type of data, and to minimise confusion as to the permanence and currency of the types of data displayed.

— Richardguk (talk) 11:58, 23 July 2012 (UTC)

Its a lot harder to get older information than it would appear at first glance. You can reparse the old wiki text sure - but reparsing the old wikitext of everything transcluded starts to get much more difficult (and that's assuming all the transcluded pages still exist. Things get (rev) deleted, some parsing constructs depend on time/date, some have dependencies on the php side that may change with time etc). However having a minimal of information could certainly be done. Bawolff (talk) 13:13, 23 July 2012 (UTC)

Agreed that some data would fall into the third type above (requiring parsing or complex queries). But, on the particular issue of template lists for old revisions, it should be straightforward to parse the former wikitext and present the result as meaning "these are the templates that would be transcluded if the specified revision were reinstated now" (which is presumably the same basis and method by which section-level previews currently list transclusions for edited portions of a page). Most editors accept that MediaWiki does not attempt to provide point-in-time snapshots of transcluded wikitext. So I think the real issue for template lists is simply whether adapting the existing section-preview code to oldid page-info would require excessive testing or result in excessive server load. — Richardguk (talk) 19:06, 23 July 2012 (UTC)

I imagine we'd want to be clear that the templates transcluded at the time when the revision was live is different from the list being presented. Bawolff (talk) 19:21, 23 July 2012 (UTC)

Hi.

Sorry for the delay in getting back to you. The short answer to the direction question regarding applicability to old revisions is that there is none. In my view, historical data (old revisions) are outside the scope of this requests for comment.

While some data properties (such as page ID, page length, etc.) can easily be calculated, a lot of properties such as the number of subpages, the number of redirects, etc. are all based on current-state. You'd not only need to do a full parse of the wikitext of a particular old revision ID, you'd also need to do *links checks and then try to match the dates of those backlinks to the specified revision time. And even then, you wouldn't be guaranteed accurate data. (Think, for example, about how to display a list of redirects. You'd have to exclude the redirects that didn't exist at the time of the old revision and then you'd have to check the remaining pages to see if they were actually redirects at the time of the old revision. It's a bit ghastly.)

The info action is based on a single input of a current page title. What you're describing sounds neat and interesting, but in nearly any implementation I can come up with, it would be done with a separate action, making it fall outside the scope of this RFC.

What you're suggesting adds a significant level of coding complexity to what is a relatively simple action. My recommendation, if you'd like to pursue this idea, would be to create a separate RFC that can delve into what's needed to grab and display historical properties of a particular page ID or a particular revision ID. This separate RFC should also focus on the use-case of gathering and displaying this historical information. With ?action=info, the feature is geared toward power-editors who need a way to quickly look up particular page properties. With historical data, even power-editors likely won't need much of this information. --MZMcBride (talk) 19:23, 28 August 2012 (UTC)

P.S. I was originally instinctively against this idea as I saw the additional coding complexity as a threat to this RFC and the idea of reimplementing the info action in a timely manner. However, this threat has been mitigated by Madman's work. I think more thought and discussion is needed about retrieving and displaying historical data (and the virtue of doing so), but I firmly believe this is outside the scope of the info action and this RFC.

Thanks for the response. I certainly would not expect the proposal to include information that could not be calculated straightforwardly. But it seems to me that, where relevant fields are included in the revision history table, it would be relatively simple to support action=info in conjuction with a specified oldid. The harder task of providing an oldid template list need require no more than reimplementing the equivalent functionality which is already used to generate template lists to accompany section-edit previews, as editors will (I believe) understand that it is based on a simple parse of the relevant wikitext and not on a full point-in-time reparsing of transcluded pages.

Apologies if the above paragraph merely repeats my earlier points, as it remains unclear to me why this would introduce significant additional complexity.

Nonetheless, I welcome your proposals and coding, which of course leave open the possibility of being extended in future.

— Richardguk (talk) 11:28, 29 August 2012 (UTC)

Section edits do not currently show the templates used in the section, at least not when you first click [edit]; related: bugzilla:878. --MZMcBride (talk) 02:43, 31 August 2012 (UTC)

Maybe not on first click. But previewing a section edit displays a list of "Template(s) used in this preview" (<div class="templatesUsed"><div class="mw-templatesUsedExplanation"><p>Templates used in this preview:</p></div><ul><li>...</li></ul></div>), so somewhere in MediaWiki ad hoc template listing has already been coded, given arbitrary wikitext as input – which is why I thought it would be fairly easy to reimplement in the context of action=info. But no worries if it's more complicated than I've assumed from my superficial analysis! — Richardguk (talk) 20:15, 31 August 2012 (UTC)