This is a recurring discussion usually started by people who didn't participate in the old discussion. This is not going to happen. The software won't be changed because this goes against the core data model of Wikidata. Multichill (talk) 12:57, 28 May 2017 (UTC)[reply]
Basically in the linked discussion there are 16 moves in favor of allowing redirects and 4 votes against. Are you seeing that even through the Wikidata community wants site-links the conviction of the Dev time that redirect shouldn't be allowed is strong enough to ignore the wishes of the Wikidata community and it basically doesn't matter what the Wikidata community wants? ChristianKl (talk) 20:00, 28 May 2017 (UTC)[reply]
It seems that this is frequently brought up by users who don't participate in maintenance of Wikidata. --- Jura22:11, 28 May 2017 (UTC)[reply]
I don't see how maintenance experiences lead me to believing that the status quo makes sense. At the moment I'm looking at cleaning up Anglican Bishop of Exeter (Q465869). The German Wikipedia doesn't have an article on "Bishop of Exeter" but has a "List of Bishops of Exeter". According to our ontology, both don't belong in the same Wikidata item but it makes a lot of sense to have interwiki-links between them. This encourages people to link them together, even though that's not optimal. It's my impression that it regularly happens that Wikipedians engage in actions that violate our ontology to get the interwiki links working. If you have different experiences, with experiences make you believe that the current system works well? ChristianKl (talk) 09:26, 29 May 2017 (UTC)[reply]
While I'd prefer that links to redirects be allowed, I'm happy enough using a hack to work around the limitation. I'd be seriously opposed to having a bot go remove them all. That's just obnoxious. StevenJ81 (talk) 20:24, 30 May 2017 (UTC)[reply]
When discussing policy it's worthwhile to distinguish words like may and should. My proposal doesn't advocate that any editor should do something but that they may do something. I advocate that people may add redirect without jumping through hoops.
I don't think that we need technical bans on preventing all forms of redirection. I think it's valid to ban bit.ly and similar websites as they don't provide value.
"Archive.org" is something like a redirect to the original page and I think there are many cases where it makes sense to link it.
When deciding on how to model external-id's there's sometimes websites with urls that end in "id=12345+Jon_Doe". When you enter just "id=12345" you get redirect to "id=12345+Jon_Doe". I think it makes sense to call "12345" the ID towards which we want to link and let the website redirect. In general in cases where it's reasonable to assume that the redirect is more stable than the direct link to the actual content, it can make sense to link to the redirect. ChristianKl (talk) 21:46, 28 May 2017 (UTC)[reply]
User:Steak wrote: "If Bonnie Parker has no interwiki link to en:wp, so what? Since our notability criteria are not limited to items having an interwiki link, there is no need to artificially add an interwiki link."
Let's say a person looks up Bonnie Parker record on VIAF and they want to have more information about her. If they go to Wikidata from VIAF they benefit from having a link to the Wikipedia article in which Bonnie Parker is discussed. A data-reuser like a library might also want to be able to directly link to the Wikipedia article that discusses Bonnie Partner when they have the VIAF record of Bonnie Parker.
As far as notability goes, our standards don't require interwiki links but if there's an item with one statement and two translations it currently gets flagged by the automatic procedures. I personally created the item fingerless glove (Q10700095) with just the German and English name and subclass of (P279) and a link to an EnWiki redirect. Without the redirect, the item would get flagged. It hopefully wouldn't get removed but it would still take review work. For fingerless glove (Q10700095) it's quite clear that it's a notable item but there are other items about very specialized vocabulary where a person who reviews the item might need to do a Google search. If there's a link to the article that discusses the concept on Wikipedia the likelihood that items like this don't get accidentally removed is higher. – The preceding unsigned comment was added byChristianKl (talk • contribs).
@ChristianKl: Did you think on adding more statements or even using it in another entity? I can understand nearly empty and unused entities like that being flagged, and having sitelinks to a redirection on enwiki and a stub article in svwiki doesn't change the fact that the only info the entity has is that it's a subclass of glove (Q169031) and a picture. -- Agabi10 (talk) 10:03, 29 May 2017 (UTC)[reply]
No, and the item still has value and is notable according to our standards. I created this specific item after searching the internet for the German to English translation of "fingerless gloves". A bit later someone merged the Swedish item into it, so the translation now works in three languages.
It's a concept that the good German-English dictionary Leo doesn't know. There are many fields with specialized vocabulary that you don't find in your average dictionary but where it can be very useful to have the translation. Wikidata is great for knowing how anatomical concepts are called in different languages. ChristianKl (talk) 10:34, 29 May 2017 (UTC)[reply]
Let's say I'm writing an article on Charles Robert Parker (1884 – 1914) and I want to auto-populate his infobox from Wikidata. Let's assume he is sufficiently notable to have a Wikidata entry, and that the statement child (P40) contains the value Bonnie Parker (Q2319886). What happens when the code tries to fetch the English site-link from Wikidata to make the link to en:Bonnie Parker? If you refuse to allow the site-links on Wikidata for Bonnie Parker to link to en:Bonnie Parker, for no other good reason than it's a redirect, you frustrate any efforts to make use of Wikidata in a sensible way. Anyone reading an enwiki article about Charles Robert Parker would expect to be able to follow a link to his daughter, en:Bonnie Parker. The fact that it turns out to be a section of en:Bonnie and Clyde cannot possibly be a sensible reason for failing to make the site-link available to be retrieved programmatically. --RexxS (talk) 19:17, 30 May 2017 (UTC)[reply]
Oh, I can simply program it, can I? You're sure that every time I need a sitelink for a Wikidata entity that corresponds to an enwiki redirect, there is guaranteed to be another property available that will take me to the correct destination? The concept of the "Bonnie & Clyde" problem is meant to be illustrative of a general problem, and I need a generic solution, not just one that works for Bonnie Parker: I'm not just writing code to fetch one property from one Wikidata entity. Even if your approach could possibly work, I'd need a look-up table the size of a planet to hold all the possible combinations of properties and their alternatives on an article-by-article basis. --RexxS (talk) 20:05, 30 May 2017 (UTC)[reply]
Such a look-up table is guaranteed not bigger than the list of all redirects. If you add a redirect to Wikidata, you only solve the problem for one article in one language. If you have a look-up table, you solve the problem for all infoboxes using the same property in all languages. --Pasleim (talk) 20:20, 30 May 2017 (UTC)[reply]
just as a note: English Wikipedia has 7,807,424 redirects in the main namespace. Creating a property fallback-chain for each property will definitely be a smaller effort than maintaining all these redirects. And a property fallback-chain could be used by all 600+ Wikimedia projects and not only by English Wikipedia. --Pasleim (talk) 20:31, 30 May 2017 (UTC)[reply]
@Pasleim:The tool you recommend works for the Bonnie and Clyde but not for every case. If I take the example of fingerless glove (Q10700095)sv:Torghandske wants an interwiki-link. It's not clear that every article about gloves in every language happens to write something about fingerless gloves but the English Wikipedia happens to have the article. If you simply create interwiki links with subclass of (P279) you will create a lot of links to articles about gloves that don't contain any information about fingerless gloves. It takes human attention to decide that the English Wikipedia contains a paragraph about fingerless gloves.
The human created redirect also provides the user more value, because it can link him to the paragraph that discusses fingerless gloves. A redirect can direct the user to the specific paragraph in which the information he seeks happens to be. A property fallback-chain can't do the same thing.
Even for the case of part of (P361) I would expect that you produce a bunch of false positives where the article towards which you point contains no information about the concept you care about. ChristianKl (talk) 20:59, 30 May 2017 (UTC)[reply]
My point was about distinguishing "virtual redirects" that get calculated on the fly from redirects that can be edited by humans to decide whether they are appropriate. ChristianKl (talk) 22:39, 30 May 2017 (UTC)[reply]
Sorry, I am a noob who just started using Wikidata a week or so ago. Is there a simplified explanation of why linking to redirects is a bad thing? I am unable to understand the comments I've read so far. SharkD (talk) 04:26, 31 May 2017 (UTC)[reply]
People using data from Wikidata are assuming that each real world thing has exactly one item on Wikidata. This is an important assumptions, especially if you write querries. In some cases duplicates may exists if an article exists in two languages and for both articles a separate item is created. If we allow redirects, this problem gets strongly amplified. Let's say somebody writes an Wikipedia article about "2050 Summer Olympic". A bot will create an item for this article and will fill the item with a few statements it can parse from the article text. A few days later somebody will realise the spelling mistake in the title and will move the article to "2050 Summer Olympics". Somebody else will create a new item and we end up in a duplicate. Given that evereyday thousands of articles get moved around, this can fast lead to an huge maintenance problem. --Pasleim (talk) 07:05, 31 May 2017 (UTC)[reply]
One problem is that we do not always agree what a "real world thing" is. I for example think Nm, J and Ws are three different things, while other think it is the same. Yes, I agree they are equivalent, but I do not think they are the same thing. -- Innocent bystander (talk) 07:21, 31 May 2017 (UTC)[reply]
@Pasleim: Where is the item for the redirect created in the scenario you described? The sitelink is moved automatically with the page move and then the items are merged when someone notices.
One actual problem would be allowing editors to link to arbitrary redirects, without knowing what they're doing or the redirect being a plausible page title for something. I assume there could probably be a user permission for this? Jc86035 (talk) 07:38, 31 May 2017 (UTC)[reply]
@Jc86035: A more common thing is when both "2050 Summer Olympics" and "2050 Sommer Olympics" have an article on xyz-wiki. Since they are separate articles, they have separate items. A random user on xyz-wiki discover this duplicate and merge the articles and keeps a redirect. Since (s)he know nothing about Wikidata, the item to the created redirect is kept.
We have hundred, possibly thousands of such unintentional redirect-sitelinks from the Lsjbot-project on svwiki. Lsjbot created many duplicates, and many of them can be kept, but most of them should be deleted. One problem is that cebwiki still has most of these duplicates. -- Innocent bystander (talk) 07:54, 31 May 2017 (UTC)[reply]
@Innocent bystander: I assumed the Wikidata item usually doesn't get created until a sitelink is made. I still think links to redirects should be allowed, but maybe it should be required for them to be deliberately created rather than being the result of redirected articles. Jc86035 (talk) 07:57, 31 May 2017 (UTC)[reply]
@Jc86035: The problem is that the person or bot who created the duplicate article and item about "Summmer Olympics 2050" do not know about the other article/item. And when the problem finally is fixed on Wikipedia, it is today not automagicly solved here, if the user who did the WP-merge wasn't an experienced Wikidatian. -- Innocent bystander (talk) 12:30, 31 May 2017 (UTC)[reply]
If I understand your example right, it describes how some redirects are created in the status quo. In the example, nobody seems to make a decision to create a link to a page that's a redirect at the time the link is set. It seems to me that this doesn't cause a big problem at the moment. The problem that en:"2050 Summer Olympic" and en:"2050 Summer Olympics" are about the same concepts seems to me very similar to determining that they are the same as de:"Olympische Sommerspiele 2050". Sometimes we can detect this automatically via authority control or similar mechanism, other times it takes manual labor. I don't see how the creation of manually created Wikilinks is a problem here. ChristianKl (talk) 10:22, 31 May 2017 (UTC)[reply]
Neither do I, it is the unintentional creations of such links that is a problem. It would be helpful if we could mark which sitelinks are to redirects and which of those who are intentional. -- Innocent bystander (talk) 12:14, 31 May 2017 (UTC)[reply]
If redirects are allowed this is no longer guaranteed. How should the software know if a redirect has to be resolved because it's only a spelling mistake or if a redirect has to be kept because there are two differenct concepts? --Pasleim (talk) 17:35, 31 May 2017 (UTC)[reply]
The default would be to update the sitelink to follow the move, as now.
But if somebody then wanted to over-rule that manually, and keep the item linked to the redirect, rather than the new article name, it would be easier if they could just do that, rather than having to work around the software's protectiveness as they have to at the moment. Jheald (talk) 17:52, 31 May 2017 (UTC)[reply]
Wikipedians desperately want redirects as sitelinks; it solves a problem they observe in connection with Wikidata’s services for them, and they don’t care much about the damage this would do to the Wikidata content model.
Wikidatians desperately reject redirects as sitelinks; they care about the potential damage, while to some extent they do at least acknowledge the problem for Wikipedians.
We should aim for another solution which considers both positions. User:Succu has coined the term “virtual sitelinks” in the voting, which I find valuable to discuss. From Wikidata’s perspective, would it be possible to have a second handle for sitelinks in the data model (and as well in the UI)? It should only hold redirects, and we could potentially add multiple ones per project, if necessary (Bonnie and Clyde (Q219937) could have virtual sitelinks to enwiki redirects en:Bonnie Parker and en:Clyde Barrow, thus solving the “Bonnie and Clyde” problem in the difficult direction).
It would be up to the Wikidata community to regulate which redirects are permitted (in order not to overcrowd this “virtual sitelinks” section), and up to the Wikipedia communities to properly use this data. At the same time we could keep clean real sitelinks that we have right now. —MisterSynergy (talk) 10:52, 31 May 2017 (UTC)[reply]
I don't think that's a fair summary. I'm mainly a Wikidatian and not a Wikipedian and there are others who are very active on Wikidata on the supporters list as well. I think it's very unfair to say that people like Andy Mabbett, ArthurPSmith, Lymantria, Jheald and myself to invest a lot of effort into getting new properties rights don't care about the Wikidata content model. ChristianKl (talk) 12:03, 31 May 2017 (UTC)[reply]
This is intentionally a catchy summary to indicate the contradicting positions and interests in this RfC, certainly not meant to judge any of the voters. I apologize if that wasn’t clear. —MisterSynergy (talk) 12:11, 31 May 2017 (UTC)[reply]
As far as I understand the term "virtual sitelinks" they are one's that are dynamically created when the need arises based on predetermined rules like "part_of" relations. It's a different proposal than having sitelinks with handles that are stored in a database. If you would be okay with sitelinks to redirects that are separately, why do you have a problem with the idea of simply giving the sitelinks that are redirect badges (and a status that makes them queriable via SPARQL : It would even be possible to make the redirect location accessible via SPARQL)?ChristianKl (talk) 12:10, 31 May 2017 (UTC)[reply]
You still cannot allow multiple redirects to one project with this badge-based method, which would solve an important and difficult part of the BC problem. To my knowledge you need a separate handle in the data model which allows multiple links.
I highly doubt that any automatism based on property statements such as part of (P361)/has part(s) (P527) works. Redirects on Wikipedia side are used for many very different types of relations (which is okay, since a redirect by itself does not carry any semantic meaning) which go well beyond our properties.
The only property-based solution I could imagine was to have a new property “related Wikimedia sitelink” (akin to described at URL (P973)) which holds as values all redirects to Wikimedia projects. A separate handle for redirects would be much nicer to my experience.
To be honest, I do not care much about Interwiki at all. I care more about how infoboxes are designed. We do not have articles for every unit like "centimeter/millimeter/hektometer". But it would be useful to have a simple way to create links to those redirects, and thereby indirectly linking to "meter". -- Innocent bystander (talk) 12:24, 31 May 2017 (UTC)[reply]
I’m sorry, I don’t really understand your point as I did not consider infobox coding in this context until now. Could you please elaborate this use case? Thanks, MisterSynergy (talk) 12:35, 31 May 2017 (UTC)[reply]
@MisterSynergy: If you look into sv:Ängesbyn you there see an infobox that is partly Wikidata-based. The area of "Ängesbyn" was 2015 77 hectare big. That information comes from Wikidata. On svwiki we have an article about hectare, so the link in that page is linked to that page. If we had no article, but a redirect with sitelink, this would still have linked to something like "squaremeter". If there is no sitelink, no link can simply be generated. How much coding you can add into an infobox is strictly limited. The infobox in sv:Stockholm (tätort) is more or less the same, but the amount of information in that infobox was too much for MediaWiki to handle. Looking into a tree of "part of" and such stuff for every thing here is today far too expensive for MediaWiki. -- Innocent bystander (talk) 12:57, 31 May 2017 (UTC)[reply]
I don’t have an overview of the template and module situation at Wikipedias, thus I cannot really provide a solution here. My experience from dewiki is that Wikidata usage in templates has a surprisingly low level of abstraction, i.e. each template implements a lot of functionality by itself, rather than to rely on a library of standard functions. This consequently leads to the implementation of low-level solutions, way below what would potentially be possible. I am not sure whether abstraction would solve the problem here, but it could definitely help. In this context the lack of a global module repository is a serious problem, since skilled lua coders are rare for some reason.
You will not be surprised that I am still (strongly) in favor of a rejection of redirects as sitelinks. But I think that a separate section for redirects (“virtual sitelinks”) would be valuable for “simple” data retrieval from Wikidata in templates as well. —MisterSynergy (talk) 13:21, 31 May 2017 (UTC)[reply]
@MisterSynergy: The level of abstraction in our main Lua-module on svwiki is fair. It for example by itself look up if the unit used is convertible to SI-units, and also converts if required. It can by itself create external links for random external identificator and it by default prefer anything that has "language:Swedish/script:Latin" as a qualifier. That made hectare shortened to "ha" instead of "га" in the example above. It even have an extended "fallback" installed if the standard fallback fails. I am also pleased that it can handle several ways to use references. Depending on the users preferences, you can exclude "imported" data and prefer to show references of better quality. We have also limited the displayed number of references in each claim to make the infoboxes less overwhelmed by notes.
The large problem here is that the WD-supported templates we have on svwiki mainly are hybrid-templates. The whole item has to be loaded and analysed several times in each infobox. I have proposed that the chapter should hire somebody who can replace our monster geobox with a pure Lua-alternative. But good programmers can often find more well paid jobs in other places. -- Innocent bystander (talk) 14:03, 31 May 2017 (UTC)[reply]
@MisterSynergy: I talk about sv:Modul:Wikidata2. It has been developed further after local requests, since the development of Module:Wikidata halted in the early days of Wikidata, and did not have the functions that was locally requested. Unfortunately, they have relied a little too much on me, who learned programming on a ZX Spectrum (Q23882) in the 1980's. I have no professional schooling or experience in this field, I'm afraid. But I am still surprised how well it works. -- Innocent bystander (talk) 18:30, 31 May 2017 (UTC)[reply]
There are two separate issues: ① Which data structure should we have? ② How should the UI display that data-structure.
For use-cases such as the infoboxes or interwiki links it's good if there's either 0 or 1 link, because either there's a link or there isn't. It's therefore not useful for our data structure to allow a sitelink and a redirect link at the same time. This means that it makes sense to have one column with the links in the database and another column that contains information whether or not the link is a redirect. The UI can display that information with a badge. It can also have a toggle to hide redirects or list the redirects separately. ChristianKl (talk) 13:49, 31 May 2017 (UTC)[reply]
As far as I understand, Innocent bystander’s use case could deal with many redirects to the same project as well. But there might be situations where this would be a problem, particularly in the example with affiliations given by RexxS. However, this is another example why a Wikipeda-centric perspective is not useful in this question. According to the infobox scenario, exactly 0|1 or in other cases even n redirect sitelinks would be useful to simplify work on Wikipedia’s side. On the other hand, the Bonnie and Clyde problem—the origin of this entire discussion of 4+ years—would not even be solved by the permission of redirect sitelinks. Wikipedia needs somtimes contradict themselves, we are not able to provide solutions to all of their requests. Even now we are painfully tolerating some data tweaks and redundancies that would not be there in a pure Wikidata—just because it simplifies Wikipedia template coding. Unfortunately our workforce is limited, and particularly Wikipedia-centric properties are in really bad shape already now. —MisterSynergy (talk) 14:12, 31 May 2017 (UTC)[reply]
I don't think, saying 'our workforce is limited' to reduce the amount of work, is a good strategy. Allowing links to redirect encourages Wikipedians to come to Wikidata to do work on Wikidata. That means it encourages Wikipedians to become part of the Wikidata workforce. The strategy of deletionism where Wikipedia tries to reduce the amount of work leads to fewer editors who in turn do less work.
Simply allowing redirects would only solve half of the Bonnie and Clyde problem but the other halve could be solved the way I describe in the RFC under the section "Possible complaints that can be fixed with code". ChristianKl (talk) 10:50, 1 June 2017 (UTC)[reply]
Our workforce is in fact limited, look at all the open maintenance tasks we need to work on (sitelink-related: merging & deletion backlog; property-related: enormous constraint violation lists; item-related: large amount of (nearly) empty items; etc …). The Wikipedia-centric way of modelling data here tends to “everything-links-to-everything” situations which are nasty to deal with for maintenance and, even more important, data usage/queries. I have meanwhile developed a strong opposition to changes that should just make a Wikipedian’s life easier at the expense of Wikidata. “Redirects as sitelinks” is definitely one of those ideas, but certainly not the only one.
At the same time, I do of course want Wikipedias to use our data. If it is too complicated right now, we need to invent solutions that both sides can live with. The intention to start this talk page topic was to open another path for a solution that makes Wikipedians’ lifes easier, while not disturbing Wikidata too much. —MisterSynergy (talk) 11:38, 1 June 2017 (UTC)[reply]
My main reason for participating in this project, is to make the data useful in the clients. And queries are not useful in any way in our templates at Wikipedia or in any client today. But I do use them, as maintenance-list. -- Innocent bystander (talk) 12:53, 1 June 2017 (UTC)[reply]
We do have backlogs and Wikipedia also always had various backlogs but that's okay. Having a backlog isn't a problem for the project. Especially the merging & deletion backlog doesn't cause many practical problems. From my perspective, it's a lot more important to have ways to encourage new people to come into our project. Most of the people who come to Wikidata will do one edit and leave afterward but some will stick around and help with other work.
As far as the deletion backlog goes, having links to redirects helps reduce the backlog because items like "fingerless gloves" can be created in a way where our scripts don't put them in the que of items to check for deletion. When it comes to merging, I see how links to redirects that look the same as normal links can produce a problem but that's an issue that's solvable. We can have a badge, we can have a gadget that provides a toggle to hide the redirects so that Wikidata users who work on the merging backlog don't have to see them if they think seeing them hinders them. Having the redirects also provides scripts who seek good merge candidates more information to make good decision about which items should be merged. ChristianKl (talk) 13:46, 1 June 2017 (UTC)[reply]
There are two meanings of "need". One is that you say that there a policy that violated by the class not having a description. If you think there is, please point to one. The second is that you prefer it to have a description. If you have that preference it's a Wiki and you can add it.
By the way the existing consensus of the last RFC wasn't to ban these links but allow them, but to allow them, so you have no justification for removing the link that exists. ChristianKl (talk) 22:07, 1 June 2017 (UTC)[reply]
There was never a consensus that allowed redirect to a section of an article. And the "need" for a definition is demanded by the general principles of ontology design. --Succu (talk) 18:22, 2 June 2017 (UTC)[reply]
Where redirects can link is Wikipedia policy business and not Wikidata policy business. The 2013 RFC says "Allow wikidata links to Wikipedia redirect pages". It doesn't say that only some redirect links should be allowed.
Plenty of academic ontologies don't have definitions for all their items. Just because you have personal opinions of how you think ontologies should look like doesn't mean that those personal opinions are Wikidata policy. ChristianKl (talk) 18:51, 2 June 2017 (UTC)[reply]
ontology (Q324254) are not about items, but classes and their relationships etc. Basic Formal Ontology (Q4866972) is one of them. I never said it is a „Wikidata policy“. A redirect should not define the meaning of a class. A redirect to section of an article can vanish every moment. And with it the intended meaning of this potential class. --Succu (talk) 19:20, 2 June 2017 (UTC)[reply]
① I'm not aware of any rule in BFO that every item or class has to have a description. ② Wikidata's ontology doesn't separate the world into items that are classes and items that aren't. ③ The words have meaning even without the redirect.
To the extend that you want an item to change in a way that's not required by our policies you are free to add additional content. ChristianKl (talk) 20:09, 2 June 2017 (UTC)[reply]
What is Wikidatas ontology™? Is it fixed by some „Wikidata policy“? A word (=label of an item) can be ambiguous. Therefore we have (multilingual) descriptions (or in a narrower sense defintionions) to make clear what a universial or particular is about. This allows us to establish stable relations between universials or particulars. --Succu (talk) 20:34, 2 June 2017 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
On behalf of the Fashion project, I will be happy to add a description to "fingerless gloves" and even to distinguish them from mitt (Q29199982). - PKM (talk) 06:43, 24 July 2017 (UTC)[reply]
is that Sinksundet (södra delen) (Q30107208) without its current redirect-sitelink, will be merged with Sinksundet (Q18332539). It fulfils the "clearly identifiable conceptual or material entity"-criteria, but it is often hard to keep users who are too trigger-happy on the merge-button to leave such an item in peace. (I have problems with such users from time to time.) This item is a typical subject who is too poor to be notable on WP on its own. It is only mentioned with a sentence in the article about its neighbour and is mentioned in some lists. -- Innocent bystander (talk) 10:56, 2 June 2017 (UTC)[reply]
For such an important RFC there should be imposed some eligibility criteria for users to have the right to participate. This is not a simple voting, and we should be sure that anyone participating in this RFC was involved enough in WD maintenance and development. Participating users should have a decent number of contributions to WD (several thousands at least), and it should comprise addition of claims (thousands; including tens of items improved individually manually, not only in mass), merges performed (at least several tens), etc. Gathering most of edits by simply connecting in Wikidata pages from client wikis isn't enough! Every participating user should be aware of the impact of sitelinks to redirects in Wikidata. XXN, 10:05, 10 June 2017 (UTC)[reply]
I don't think it makes sense to have a process that decides for every RfC having a different eligibility criteria. I think there's an argument to be made to have generally a higher eligibility criteria, but I don't think this is the place to discuss what the eligibility criteria should be. Changing our eligibility criteria needs it's own RfC. ChristianKl (talk) 17:19, 10 June 2017 (UTC)[reply]
actually, I think we've been waiting on some sort of commentary from the development team. While there's clearly a consensus to make a change along these lines, it's not entirely clear what is practical to request to be changed. @Lydia Pintscher (WMDE): is there any prospect of some input on this soon? ArthurPSmith (talk) 14:27, 22 September 2017 (UTC)[reply]
It's closed now for a while, but it seems that nothing happens. Most users voted for sitelinking to redirects. So, please make this possible without forcing people to do ugly hacks! --Arch2all (talk) 16:12, 19 December 2018 (UTC)[reply]
Short description and Redirect with possibilities templates[edit]
I draw the attention of anyone interested to the existence of these templates on en:Wikipedia. They are not universally used, but might have some usefulness in this problem.
{{Short description}} is a short statement of what the topic is about. If it is added to a redirect it generally means that the redirect topic is not the same as the target topic.
{{R with possibilities}} indicates that the title of the redirect is likely to be worth an article if enough content is accumulated to justify a split from the target. This usually goes with a {{R to section}} which indicates a redirect to a section which discusses the redirect topic in some detail.
