Topic on Talk:Edit Review Improvements/New filters for edit review

Suggestion:Order namespace filters more usefully (alphabetically or by importance)

10
197.218.83.82 (talkcontribs)

Issue:

Namespace dropdown is not ordered in a way that makes sense for the average user. It is neither alphabetical nor based on importance.

Background:

The current (original recentchanges) namespace dropdown also orders it based on namespace id. However, it is superior to the new filters because it is smaller, and users can see it most of at a glance, which makes it less of an issue.

Concrete issues:

  1. Contains unnecessary options
    1. "Special" namespace which can never have edits - although at least it can have logs
    2. Media namespace - This is an alias for the File namespace, and there will never be any edits on the media namespace
  2. Not ordered based on importance

Proposed solutions:

  1. Remove or combine:
    1. Special namespace is just weird over there - It is not in the older interface, and could probably just be removed. Although it still shows useful info.
    2. Media namespace - this serves no purpose, and should just serve as an alias for file
  2. Either order them:
    1. Based on importance - most important is the content namespaces, followed by file, template or project or user namespaces, then the rest; or
    2. Alphabetically - this is sensible for new users (but possibly annoying for experienced users). This is probably the least desirable option, but easiest to implement.

Flow's topic namespace seems to be the odd man out on wikis with it, because its board has a separate namespace. All namespaces could potentially contain flow, so it might make sense to have a filter specifically for flow because namespace logic doesn't make any sense when it comes to flow.

197.218.83.82 (talkcontribs)

Also, the Media namespace filter doesn't really output any results. It is pretty pointless.

Trizek (WMF) (talkcontribs)

I've asked to remove Media namespace, good catch!

Concerning order of namespaces, the filter list follow the ID of each namespace: 0 is main, 1 is talk:... Order them would be possible, but each solution has potential advantages and inconvenient:

  1. importance is relevant, but requires to know which ones are more important. Prioritize main namespace first would be ok, but not on Commons or Wikisource. It is a configuration change to define with each community, which is a significant amount of work. Maybe there is a way to know the activity on each namespace, but it may also be pointless for some reasons (Translations: namespace on Mediawiki has a huge number of changes which are language specific).
  2. Alphabetically order has inconvenient you have listed. And what would happen if someone has a different input language changed while filtering? At least, we can expect advanced users to search for the filters.

I've created a ticket to explore that question.

Concerning Flow, I've replied on the content model topic.

197.218.89.141 (talkcontribs)

> importance is relevant, but requires to know which ones are more important.

Content namespaces are the most important, they are clearly defined on every wiki and easy to get, e.g: see Manual:$wgContentNamespaces, there is also the Manual:$wgNamespacesToBeSearchedDefault. See also Module:Namespacedata/doc .

One simple solution is to sort by content namespaces (along with their talk pages first), then search namespaces (if they differ from content), then everything else by namespace id. As long as the most used options are on top, the rest don't matter that much because it is easy to search for them.

2. It is indeed less convenient, which is why is it secondary option.

197.218.81.144 (talkcontribs)

You can actually see a good example of this in the new pages feed: https://en.wikipedia.org/wiki/Special:NewPagesFeed

If you change anything you can immediately note the results. It is also quite easy to identify bugs or mistaken assumptions about the returned results. In fact, there should be no report (aside from those very specific to new pages or curation) from that interface that should be impossible with recent changes.

One significant difference is that newpages goes beyond 30 days, while recent changes doesn't. Even so, reporting counts related to all changes relative to 30 days makes a lot of sense. It becomes easy to answer questions like, how many pages were created by newbies , how many pages were deleted, how many edits were by anonymous users, how many bot edits by X bot. Maybe a bot malfunctioned, maybe an admin went nuts and deleted a of pages (this happened recently), or maybe new editors were attracted or new vandals.

For big wikis some of these stats may be insignificant, but for smaller ones it is rather interesting.

Trizek (WMF) (talkcontribs)

I've reported the idea of using $wgContentNamespaces or $wgNamespacesToBeSearchedDefault to sort the namespaces.

Concerning Special:NewPagesFeed compared to Special:RecentChanges, the two pages have indeed similarities but also differences.

On Special:NewPagesFeed, you only list new pages, for the last 30 days, based on the API. It is a query on existing pages.

On Special:RecentChanges, you list all edits as they come, with two limits: everything from the last 30 days or all last 500 edits. The filters will work on the last 500 edits, limited to 30 days. On big wiki, you will first get the 500 edits (this is why English Wikipedia has Special:RecentChanges). On a smaller wiki, you will hit the 30 days limit.

Maybe we should add a warning?

197.218.90.94 (talkcontribs)

> On Special:NewPagesFeed, you only list new pages, for the last 30 days, based on the API. It is a query on existing pages.

That's incorrect, the newpagesfeed lists pages created years ago. (click the oldest checkbox). You are probably confusing it with special:newpages https://en.wikipedia.org/w/index.php?title=Special:NewPages&dir=prev&limit=500which does seem to have the 30 days limit, but not the 500 entries limit, since one can continue seeing more results.

The difference is that newpagesfeed also contains new pages, from either the user or main namespaces. That's how they can accurately monitor their backlog, and that's probably also why it isn't so slow (see Page Curation#Easement of 30 Day Expiration).

Special:recentchanges is limited to 1000 entries (not only edits, also logs, etc) and 30 days

>Maybe we should add a warning?

Not a warning, but a notice as described here:

Topic:Tywpj189d7btyda5

Basically something like:

Showing 235 filtered results

As far as the main topic of this thread is concerned. The most edited / viewed namespaces will also likely be the most important, and so that can also be used to sort results, by analysing the usage across wikis.

For example, Help: namespace is probably not edited a lot, but users often consult it, and may want to know when something changes. Vandalism or new features ...

Trizek (WMF) (talkcontribs)

While reading your reply I was like "what I've written is wrong". The part about Special:NewPagesFeed limited to the last 30 days is a typo I've made. I've rephrased a lot my reply before posting it and I forgot to make an ultimate re-reading.

197.218.90.94 (talkcontribs)

>Maybe we should add a warning?

Now that I think of it, yes a warning will be good:

123 filtered results . Note: Results only go up to 2 September 2017.
Reply to "Suggestion:Order namespace filters more usefully (alphabetically or by importance)"