Wikipedia talk:Related Pages extension/RfC

See m:Requests_for_comment/Related_Pages for summary of cross wiki discussions. Alsee (talk) 17:33, 27 May 2016 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

What needs to improve or change in the feature

The initial feedback section does a pretty good job covering the concerns with it. It's basically trying to do our job, and not doing it as well as we do. It's basically relying on high-profile clickbait image-links. I don't think we'd allow it if a random editor started adding these exact same image-links into articles, especially not a things like a Seagate-Brand link in a generic Hard Drive article.

I *would* like this if it were recast like search results, with a "Find Similar Articles" link or button. Then it could return a long list of mixed-quality machine-selected articles instead of putting them into the current article. That could be useful for both readers and editors. Bonus points if the user can select the "quality/popular" boosted list, or obtain an unboosted list of the strictly most similar articles. Alsee (talk) 08:22, 27 March 2016 (UTC)[reply]

Should any changes be made to our plans for testing

Pretty much any sort of limited A/B testing is welcome in general. Anything made available for on-request activation is great. Regarding "partially roll it out on several wikis at a time", I suspect the current version won't be well-received, but you could certainly try it at interested wikis. If it's remade similar to search results, then I doubt there would be any meaningful objection to it becoming a standard part of the surrounding interface. Alsee (talk) 08:56, 27 March 2016 (UTC)[reply]

But there could well be an outcome?

"This is an experimental use of the RFC process and has no outcome other than to generate feedback for the WMF." - This language feels a bit prejudging the discussion. I would have thought that as this is going to be a well advertised RFC - that it may well generate significant feedback and be indicative of consensus on the English wikipedia about the extension in its current state and how the community might want to be consulted before it proceeds. So, it seems possible that there could well be outcomes from this RFC: for example, a consensus may emerge that this feature should not be tested on the english wikipedia without significant changes would be one possibility. AlasdairEdits (talk) 21:20, 28 March 2016 (UTC)[reply]

Yeah, some of the language is rather unusual. Here's the explanation: The WMF recognizes that some past software projects have not gone smoothly and that that there needs to be improvement in community engagement. They are in the middle of trying to figure out how that's going to work. Their usual approach is to post information on WMF wikis and (sometimes) send out notices inviting us to comment there. I'll skip the list of reasons that hasn't worked very well. My idea is that the WMF can let RFCs go to the communities, the communities deal with translating it, the communities can deal with our messy discussions, then the communities can generate and translate a closing summary. Then the WMF can easily deal with a manageable number of English-language community-close-responses. All of that probably seems natural to most community members, but for some WMF staff it's a bit of a scary new idea to invite communities run our own local process. They are embracing this RFC as an "experiment". I did almost all of the RFC drafting, but I carefully deferred to all concerns and requests on how they wanted it. The language is designed to make them as comfortable as possible. Now they have sent it to us and it's in our hands. I would like to remind everyone that how we handle this will have a big impact on whether the WMF embraces or rejects this approach. Let's not fuss over the language here. Let's take this as a step in a good direction, and hopefully they will embrace future local Requests For Comment advising on future software projects before they get built.

Note that they explicitly do not want to push this on wikis that don't want it. It was a sort of experimental project, they are considering running tests to collect data about it, they are considering offering it to us, and they are willing to do some limited work to improve it. Everything is good-will collaboration here. If some sort of consensus arises, if we put some sort of close on this, let's keep the tone friendly collaboration between partners. Alsee (talk) 18:30, 29 March 2016 (UTC)[reply]

'Damaging' results

"For 'damaging' results, which are rare, editors can over-ride results." I don't find that convincing; we have over 5 million articles - who is going to check each for inappropriate results? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:33, 29 March 2016 (UTC)[reply]

'See also' sections

"[See also sections have] less presence on smaller Wikipedias". I don't see how this is relevant to the use of the extension on this Wikipeida. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:36, 29 March 2016 (UTC)[reply]

Agreed. On the English Wikipedia the "See also" section has been part of the layout guidelines for a long time, and having the links be curated manually by editors is one of the site's strengths. Having links selected automatically can only detract from the experience of navigating the site, in my opinion. The guidelines say that "Whether a link belongs in the 'See also' section is ultimately a matter of editorial judgment and common sense", and exercising editorial judgement and common sense is a tall order for a computer. While this extension may make sense on smaller wikis with less navigational links, I don't think it makes sense to deploy it here. — Mr. Stradivarius ^{♪ talk ♪} 06:19, 11 April 2016 (UTC)[reply]

A little aside: As an attempt to tackle this issue on Bohemia Interactive's MediaWiki Wiki, I built the unified see also which although working and in use, was sadly not appreciated or understood, so it's still not widely depolyed.

It isn't perhaps an ideal solution, but its heart is in the right place (puns all around). The ability to centralize and organize article relationships is a nice feature to have. fredgandt 03:26, 16 April 2016 (UTC)[reply]

This is good. More like this please.

Bottom line, I think this is great and you should deploy it ASAP. An article recommendation engine for readers (not SuggestBot for editors) is the world's most obvious thing that Wikipedia should have but doesn't, and this is a good step in that direction. I just turned this on and have a few suggestions:

Don't show related pages for brand-new articles. Either wait a fixed amount of time (days to a week), or only display them on pages that have been patrolled.
Don't show articles with certain types of tags in the related pages list. Ideally the exact criteria for exclusion would be configurable locally, but hoaxes and copyvio and BLP violations should stay out. There should be a way for the community (bundled into the admin tools, I guess?) to mark specific pages as ineligible for the related pages display.
There are a few health-related linkages I'm not too comfortable with - e.g. suicide has the related page bupropion (an antidepressant).
Very obscure articles are showing overly general related pages - e.g. Chou-Fasman method, an obsolete method of predicting certain properties of proteins, has protein and DNA. Consider dropping items rather than stretching so far to fill in three boxes.
On the other hand, many topics have more than three related articles; a "find more similar pages" button would be useful. Opabinia regalis (talk) 06:20, 30 March 2016 (UTC)[reply]

In addition to blacklisting tags, I think we should have a "category backlist", where any page out of such a category won't be permitted to show a page in that category. So if we were to blsacklist Category:Anus, that would prevent Anus from showing up at Korur language without any need for someone to override the suggestions. עוד מישהו Od Mishehu 04:45, 11 April 2016 (UTC)[reply]

Blacklists are not an option. (1) that would prevent Anus from showing up at an article such as Colon, and (2) WP:NOTCENSORED, there is no way we're going to open endless mudfights over what is/isn't offensive and does/doesn't get blacklisted. A link to a hardcore porn movie is perfectly appropriate on the article of an actor who starred in that movie. Alsee (talk) 06:24, 11 April 2016 (UTC)[reply]

Don't show on redirect pages

I generally echo the comments made by Opabinia regalis, but I would suggest disabling this feature on redirect pages. There just isn't enough text to show meaningful suggestions. SSTflyer 14:22, 6 April 2016 (UTC)[reply]

We need a better algorithm for producing results

I've just checked a few articles for the quality of their links. The results were bad - for Israel, only one was a good one, Palestine (region); the other 2 were about the State of Palestine, not about Israel. I also checked a few of the recent Israeli prime ministers - Ariel Sharon, Ehud Olmert, Ehud Barak and Benjamin Netanyahu. For each of them, Yasser Arafat was one of the 3; he shouldn't be given for any Israeli prime minister. The others given for Sharon and Olmert were good - Israel for both; and Likud, Sharon's party, for Sharon and the Holyland Case, for which Olmert and several others were convicted, for Olmert. However, the Netanyahu and Barak results are worse - for Netanyahu, Barack Obama is also given; and for Barak, the other 2 are individuals who he ran against in some election - Amir Peretz for head of the Labor Party, and Netanyahu as prime minister. If for these 5 cases the results are this bad, I think we need a better algorithm. עוד מישהו Od Mishehu 15:25, 11 April 2016 (UTC)[reply]

Here's an even worse example: Moshe Katsav, who was convicted of rape while he was president of Israel, is linked to Women in Israel. He does get a brief mention, but nothing more. עוד מישהו Od Mishehu 15:31, 11 April 2016 (UTC)[reply]

עוד מישהו, not saying the algorithm ca not get better - I tried it for a while and I came here precisely to say that it can get much better. But Arafat IS related to many Israeli prime-ministers. So is Obama. And a link to Women status in Israel from high profile Israeli convicted for rape (of a woman I presume) also seems a reasonable choice. Even if not the best. I think that linking in a tight short-circuit would be much worse. It happens a lot on, e.g., YouTube suggestions; if ws go into a subject with lots of videos we get stuck with series of tens of suggestions of ONLY almost exactly the same subject again and again - to me it it happens with some musical bands. Again, not saying it can not be improved, but short-circuiting is not good either - Nabla (talk) 01:30, 16 April 2016 (UTC)[reply]

We need metrics to compare this to "See also"

I'm sure the team working on this is already aware of the objection that Related Pages (RP) is redundant to "see also" (SA) sections in articles, and the concomitant issue of replacing or overshadowing manually-curated links with automatic ones. Sure, I can see the value of generating automatic suggestions for small Wikipedias or on pages without SA sections, but when there's a well-thought-out list already in the article, it's borderline insulting to editors, especially as a feature imported from mobile (which has a worrying habit of all but ignoring the editing community, but that's another story).

The testing used to support the utility of this feature has been based around clickthrough rates. There's the obvious objection that it's a poor metric for utility, but more relevantly, to my knowledge there has been no comparison of RP with SA to measure whether the presentation is a factor. That is, related pages have a number of differences that may affect their click-through rates, particularly relative to SA sections:

They are at the bottom of the page, which might be better placement for people looking for more to read
They include PageImages-based preview images, which might catch the eye
They include Wikidata-based descriptions, which might stimulate curiosity

What if we merely applied these as improvements to SA sections? We should test whether "enhanced SA" does better than RP. I would strongly support pivoting RP as an enhancement to SA, such that articles get automatic suggestions iff they don't have manual ones (which would maintain the benefit to smaller Wikipedias). As a bonus, this could also be a test of content structure; we currently trail with external links, but if people look for new places to go only when they reach the very bottom of the page, then perhaps that's a hint that we should rethink article layout a bit. {{Nihiltres |talk |edits}} 15:06, 15 April 2016 (UTC)[reply]

Display

Placement and style

At this time of posting, the parent CSS

.ra-read-more {
	margin: 0 0 0 10em;
	padding: 1em;
}

leaves a lot to be desired. It looks adrift and ironically unrelated. I've added

aside.ra-read-more {
	margin: 0 2em;
	padding: 0;
}

to my common.css ( this is yours ) and consider the result far more pleasing. fredgandt 23:38, 15 April 2016 (UTC)[reply]

Content

Each of the stingy three links, is sparsely populated at best, with an image, the title, and occasionally a line of description text. That's a lot of extra GUI for little actual content. I'd like to see more links with more content; perhaps the suggestions could be more like Hovercards/Navigation popups? fredgandt 23:38, 15 April 2016 (UTC)[reply]

Haemophilia in European royalty

An other article where the results seem wrong is Haemophilia in European royalty. The first article, Haemophilia, is clearly correct. However, I would have expected that people who actually had the disease (all of who were male) would show up before Queen Victoria and her daughter Princess Beatrice of the United Kingdom, who were just carriers. עוד מישהו Od Mishehu 11:29, 21 April 2016 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.