Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
 Policy Technical Proposals Idea lab Miscellaneous 

New proposals are discussed here. Before submitting:

« Archives, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159

RfC: Removing locally-defined links to Commons categories if they match the Wikidata sitelinks[edit]

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.

In the previous RfC there was a rough consensus to develop the functionality presented here, but there was no consensus to implement the changes. This RfC asked whether there is now consensus to implement these changes. There is still no consensus to implement these changes. For context, the previous proposal was supported by a roughly 2 to 1 margin (about 15 to 8), this proposal was supported by a roughly 1 to 1 margin (about 15 to 14).

The supporters point out that the proposal would save a good deal of editor effort. When a page on commons is moved the hardcoded links break, but Wikidata is automatically updated. With this proposal, links would no longer break due to page moves. Some point to other benefits such as simplified wikicode and ease of use for newcomers. They contest the opposition argument regarding vandalism, saying that the risk is minimal and the benefits outweigh any such risk.

The general opposition is to the removal of locally defined data. The commons page to which an article links is currently subject to local consensus, and implementing this proposal would result in some pages having content which is not subject to local consensus. Additionally it would make it hard for readers and new users to fix errors because a template with no parameters does not make it clear where the data is coming from. They also disagree that the benefits outwiegh the risks of vandalism, pointing to the consensus against using WikiData for short descriptions and arguing that the benefit of using Wikidata for short descriptions did not outweigh the risk of vandalism.

Given the strong arguments on both sides, and the significant level of opposition in this proposal (especially in relation to the previous proposal) there does not appear to be consensus to implement this proposal at this time. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 08:43, 25 June 2019 (UTC)

Should we remove locally-defined links to Commons categories where they can be provided through the Commons category sitelinks on Wikidata instead? Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)

Proposal (Commons category links)[edit]

While we have been using interwiki links from Wikidata to provide the sidebar links to other language Wikipedias for the last few years, we are still mostly using locally defined links in sister project templates. In an RfC in August 2018, starting to use Wikidata to provide these links in the case of Commons categories was conditionally allowed, with the requirement to return to the community after further testing, which leads to this follow-up proposal.

Since the previous proposal, the following things have changed:

As the next step, I propose to bot-remove the locally-defined Commons category names from the categories and pages in Category:Commons category link is on Wikidata, where they match the Commons sitelinks from Wikidata. If this proposal is accepted, then I will submit a bot request for approval to do this using Pi bot. This change should have no immediately visible effect, but any future changes to the category names on Commons would automatically be updated here. This would not affect any locally-defined Commons category links that are not on Wikidata.

Pinging those that !voted in the last proposal: @Robby, Rhododendrites, Alpha3031, AfroThundr3007730, Johnbod, Jo-Jo Eumerus, Fram, Izno, GermanJoe, Compassionate727, Keith D, Peter coxhead, Ammarpad, Killiondude, Rschen7754, Nihlus, Finnusertop, ARR8, Gamaliel, Bidgee, Bluerasberry, GreenMeansGo, PBS, Wikisaurus, and Nemo bis:

Pinging as well those that modified template Commons category since 2015 and thos e who discussed the same category on it's discussion page: @Ahecht, Redrose64, Fayenatic london, Rich Farmbrough, Pigsonthewing, IJBall, Magnolia677, Andy Dingley, JJMC89, Zhanlang1975, Michael Bednarek, Krinkle, and FunkMonk:

Survey (Commons category links)[edit]

  • Support as proposer. Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)
  • Oppose now – see below. Cluttering articles with links to Commons when these are in the sidebar isn't desirable. However, my support is conditional on the point noted below, that only the Commons category link that matches the Wikidata link is removed. (As has been discussed, here and at Wikidata, many times now, there are problems caused by Wikidata insisting on 1:1 inter-wiki relationships, when for various reasons different wikis, including Commons, don't have 1:1 links – e.g. for monotypic taxa, enwiki has one article, whereas Commons usually has a category for each rank.) Peter coxhead (talk) 09:51, 6 May 2019 (UTC)
    @Peter coxhead: Just to be clear, the proposal is to go from e.g., {{Commonscat|Example}} to {{Commonscat}} where the Commons sitelink on Wikidata is "Category:Example". The template itself would not be removed. Thanks. Mike Peel (talk) 10:32, 6 May 2019 (UTC)
    @Mike Peel: ah, my mistake. Then I now Oppose the proposal. So long as the template is present, then as with {{Taxonbar}}, I think it's better to explicitly document the connection. A tracking category is enough to flag up cases where none of the stated commons cat links matches Wikidata, as happens for {{Taxonbar}}. What I favour is removing the template altogether when the link will be in the sidebar. Peter coxhead (talk) 11:12, 6 May 2019 (UTC)
  • Support - as long as the Commonscat template is kept available for non-standard situations, this should be an unproblematic and reasonable change. GermanJoe (talk) 11:08, 6 May 2019 (UTC)
  • Support with the general expectation that only the matching values are removed. --Izno (talk) 11:38, 6 May 2019 (UTC)
  • Support Pages that link to more than one cat or have special need to keep the local link should be exempted, otherwise this is good. – Ammarpad (talk) 14:28, 6 May 2019 (UTC)
  • Fine by me. I can't comment on the technical details as they're beyond me (as usual). But in principle I don't see any issues. GMGtalk 20:58, 6 May 2019 (UTC)
  • Support - the Commonscat template should be kept available for non-standard situations. --Robby (talk) 21:22, 6 May 2019 (UTC)
  • Support this as a sensible next step — Martin (MSGJ · talk) 21:46, 6 May 2019 (UTC)
  • Oppose: The commons category listed in the Wikipedia article is the "ground truth", that is, users who actively contribute/watch to that article are presumably in consensus that this (or these, where there are multiple commons categories) is the most appropriate Commons category for this article. The information on Wikidata is merely a copy. Users who contribute to articles care about keeping them correct and safe from vandalism and often have real world topic knowledge, users who contribute to the Wikidata Qnumber are acting more in the role of a database administrator and are generally not familiar with the topic. By all means, take a copy of this into Wikidata but do not destroy the original information on Wikipedia. Firstly because that is a generally poor practice to remove authority over information from subject matter experts to database administrators, but more specifically because if someone vandalises the information on Wikidata, it will not show up on the watchlists of those who watch the Wikipedia article and damage will go undetected. It is one thing to exploit Wikidata information where the information starts its life on Wikidata (e.g. as an uploaded data set from some authoritative source). Rather than remove the information from Wikipedia, it would be better to add a template to flag on both Wikipedia and Wikidata where there is an inconsistency between Wikipedia and Wikidata, as I have seen done with coordinates, which is an invitation to investigate the matter and not impose the presumption that what is on Wikidata is always the "truth". We already have the ability for a commons category template on Wikipedia to default to the article title, and I never use that feature as I have seen too many times when the articles is renamed and nobody thinks about the implication of that move on the commons category (which has normally not been renamed). Kerry (talk) 23:50, 6 May 2019 (UTC)
  • Support I don't see any issues. Go on. Sincerely, Masum Reza 04:40, 7 May 2019 (UTC)
  • Support seems like a smart move -- reduces clutter in the markup, Sadads (talk) 18:13, 7 May 2019 (UTC)
  • Oppose Per Kerry's extremely well written and reasoned comments above. Beeblebrox (talk) 20:23, 7 May 2019 (UTC)
  • Oppose - If Wikidata isn't stable & nuanced enough for short descriptions, then I don't think it is for this either. I think it would be better to keep the info locally and have a bot set up a list or drop a notice on the talk pages of articles with differing cats or where only Wikidata has a cat. DaßWölf 22:17, 7 May 2019 (UTC)
  • Oppose. Compare the Commonscat box at right with the Wikidata link in the toolbar, and imagine a Commons link, or any other inter-project link, in the toolbox at left. Which one's more visible? As a longtime admin on both sites, I'm quite familiar with our layout, but I virtually never think of inter-project links appearing on the left, aside from other languages' Wikipedia articles. What about the newbies or those who never edit: do we expect them to find Commons links amid all the other stuff? It's much more reader-friendly to have a sizeable right-side box or an entry in the external links than to bury a link on the left side with lots of other things that are mostly irrelevant to someone who's not editing. Nyttend (talk) 22:44, 7 May 2019 (UTC)
    @Nyttend: You may want to reread the proposal. The box would stay in either case. ARR8 (talk) 00:28, 8 May 2019 (UTC)
  • Support per nomination. ARR8 (talk) 00:28, 8 May 2019 (UTC)
  • Oppose An edit that does nothing but remove local information that is already on Wikidata is functionally cosmetic. Bots performing cosmetic edits are not allowed per policy. * Pppery * survives 00:42, 8 May 2019 (UTC)
    You seem to have mischaracterized Wikipedia:Bot policy#Cosmetic changes. A bot implementing community consensus is specifically allowed regardless of whether the edit is cosmetic or not. Anomie 11:19, 8 May 2019 (UTC)
    @Pppery: As well as Anomie's point, I think it falls under "administration of the encyclopedia" - it's preventative maintenance. Thanks. Mike Peel (talk) 19:04, 8 May 2019 (UTC)
  • Oppose I agree with what Kery has said, to me the bigger issue is creating a process with excemptions as we know from practice that exemptions are rarely accepted once a policy is written, as groups of editors haunting the discussion boards see it as means to enforce uniformity and standidise everything to their preferred format. What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link Gnangarra 05:56, 8 May 2019 (UTC)
  • Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Wikipedia, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC)
  • Support This is safe, raises quality, saves humans from tedious labor, stages content from English Wikipedia to migrate into other languages of Wikipedias, and this small project is a model for greatly scaling up integration of English Wikipedia with automated tools. I am keen on eventually using more automation in English Wikipedia for quality control and monitoring. We do not have the technology to apply automation generally everywhere, but for mundane things like limited category maintenance, automation and integration with Wikidata is a good fit for being unlikely to cause problems and likely to prevent problems. I recognize that people here fear wiki editors developing annoying edit bots, but personally I fear and am seeing bad actors with malicious bots attacking Wikipedia. We are entering an arms race and I want us to develop our technology and also advance conversations about how humans and bots will collaborate to sustain Wikipedia. The bad actors do not follow rules, and I want us to start the slow conversations with good actors and safe cases as we see here. I do not see this primarily as a technical experiment, because this proposal is so small in scope and so safe. Instead I see this as a social experiment for how we negotiate the introduction of quality control bots into English Wikipedia and across Wikimedia projects. I interpret the opposition here as resistance to Wikidata, slippery slope that this change pre-approves future risky changes, and resistance to bots consuming human attention on English Wikipedia. I definitely agree that bots cause stress to humans, but I see the solution to that as research, discussion, planning, and experiments, and not in an ongoing prohibition of this necessary and inevitable change. Relatively low-impact proposals like this are good experiments to get information about how bot-Wikidata-Wikipedia interactions play out. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
  • Support As reduces issues when categories are renamed. -- WOSlinker (talk) 07:50, 9 May 2019 (UTC)
  • Oppose this scope creep of the obscure, poorly monitored Wikidata needs to stop. Plus, Kerry says it well, especially in the discussion below, eg: And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. . - Sitush (talk) 07:58, 9 May 2019 (UTC)
  • Strong support (and actually, for most sister links). The links do often not lead to significant / more information - what is the use of looking on commons if I see exactly the same image or see 11 images on commons while 10 of them are already used in our article. And if there are images there that are of real significance, then they should be used (e.g. in a gallery). Commons categories often contain mostly the images already used in the article (and a promise that the commons category will/can grow is WP:CRYSTAL). I can see that there is sometimes a reason to include sisterlinks, but that should absolutely not be a standard, it should be a well considered and one should be allowed to challenge existing links based on content, not being countered with the argument 'it is standard' or 'we do that always'. --Dirk Beetstra T C 08:23, 9 May 2019 (UTC) I read this wrong, Oppose, this is not removing the sisterlinks from the bottom of the article, this wants all to be done through WikiData. WikiData is poorly monitored, local content should always have preference. --Dirk Beetstra T C 08:26, 9 May 2019 (UTC)
  • Support. Vulphere 12:26, 11 May 2019 (UTC)
  • Oppose per Kerry, and because of problems of consistency when more than one commons link is desirable in a Wikipedia article, which I think would be confusing after this suggested change. I think that Gnan's suggestion "What could could be done is to allow for Qnumbers in {{Commonscat|Q00000}} to make the link", could be worth pursuing as a compromise. -- PBS (talk) 17:01, 11 May 2019 (UTC)
  • Oppose per Kerry. I'm all for flagging pages where the template and wikidata don't match by putting them in a category for manual review, but vandal-fighting over at Wikidata isn't robust enough for us to be trusting it as an authoritative source. --Ahecht (TALK
    ) 21:57, 15 May 2019 (UTC)
  • Support This is a change that will allow us to better serve readers and editors alike by automatically updating data for the 99% of cases where Commons/Wikidata was updated correctly – Instead of preventing 1% of potential incorrectness at the cost of being outdated and likely wrong by default for 100% of cases, with no notification to editors that watch articles to know whether something might need fixing, until someone manually realise it (which is what we do today). There is currently no technology in place to notify us about a Commons category rename. What we do have is Wikidata. Commons users update this for us already (or even automatically, in case of simple page rename on Commons). This data can in turn be queried from articles. In addition, Wikidata has the ability to notify us (as Wikipedia editors) directly on our watchlists whenever such manual or automated change from Commons/Wikidata affects an article we watch. As such, we would still have the ability to review and fix these as-needed. I believe this fits in with a wider theme of giving ourselves more time to focus on the things that matter (e.g. reviewing meaningful changes to articles on our watchlist, improving the quality and breadth of our content), and demand less wasted effort on people manually fixing things that we could have prevented from breaking in the first place using a bit of automation. --Krinkle (talk) 22:35, 15 May 2019 (UTC)
    For those that oppose, I wonder what their opinion would be on a proposal for a bot that updates these templates automatically as an edit whenever the previous value on Wikidata matches the current value on Wikipedia (effectively the same proposal with similar Watchlist events, but more wasteful toward the limited time and resources that volunteer bot operators would spend). --Krinkle (talk) 22:35, 15 May 2019 (UTC)
    Krinkle if we were to run a bot, why would we want the bot to look at Wikidata at all? The bot should directly watch for Commons category moves. I think most opposes would spot that, and see your proposal as motivated by serving Wikidata advocacy itself. Alsee (talk) 00:08, 19 May 2019 (UTC)
  • Oppose now; maybe later. I looked at a few examples from Category:Commons category link from Wikidata to see how well it works at the moment. I found Category:5 Kanal (Ukraine) where {{Commons category}} generates "Wikimedia Commons has media related to commons:Category:Kanal 5 (Ukraine)." Well, that turns out to be a redirect; the Commons category was moved and then merged in October 2018. This demonstrates that the Wikidata links are not currently being adequately maintained. Therefore we should not yet increase our reliance on them. Bots would be better employed in tracing and fixing errors such as that one. – Fayenatic London 09:39, 16 May 2019 (UTC)
  • Oppose The use of a template without a parameter is very confusing for new users who scratch their head wondering where the data comes from. We should be making things easy for users by making it clear what we are linking to and where the data is coming from. It gets even more confusing for uses where there is 2 templates in an article 1 with a parameter and 1 without a parameter. There is also the unreliability of wikidata entries and no visibility that there has been a change to the destination of a link, unless you are also watching wikidata changes on an article. Watching wikidata changes just adds to watchlist length and can cause the limit of 1,000 changes to be reached far to easily. Report differences in the entries by tracking categories (removing the tracking category that it is on wikidata). By the way I did not get either of the pings that this was taking place. Keith D (talk) 12:26, 18 May 2019 (UTC)
  • Late oppose per Kerry & Keith D. Happy days, LindsayHello 11:24, 31 May 2019 (UTC)
  • Support as admin on Commons and heavy Wikidata user. Pushing to the extreme, any interlink template should be deleted in every project as the "Commons" in the sidebar should be enough. The templates on are often filled with obsolete / improper data (i.e.: commons categories which are not the right ones, or that have been redirected to a more appropriate name) and the bots that read those parametres import wrong data to Wikidata. Wikidata has been created to be a centralized archive, not as a double for data present on the other chapters and projects. -- SERGIO aka the Black Cat 13:18, 2 June 2019 (UTC)
  • Oppose - on the grounds that wikidata, whether reliable or not, is outside Enwiki editors view and any incorrect data, whether poor editing or vandalism or anything else, will be unnoticeable. Too much reliance on the external project for invisible functionality is dubious to my mind. GraemeLeggett (talk) 06:01, 15 June 2019 (UTC)

Discussion (Commons category links)[edit]

  • I think we have cases when one article has two commonscat templates pointing to two different categories. I suggest that these cases be kept. If there is only one commonscat template, I agree with the proposal to remove it. Whereas we do have vandalism instance at Wikidata, in which case the sitelink disappears or is invalid, we have way more cases of commonscat templates pointing out to redirects just because the Commons category was moved and the template has not been updated.--Ymblanter (talk) 18:24, 4 May 2019 (UTC)
    @Ymblanter: In cases where there are multiple commonscat templates in one article, this proposal would only remove the local text from the one that matches the sitelink. I can add an exception to avoid those cases if that's what we want to do, though. With that type of vandalism, that would be a cross-project problem to fix, and it would be caught by tracking categories both here and on Commons. Thanks. Mike Peel (talk) 18:39, 4 May 2019 (UTC)
  • @Mike Peel: FYI, I didn't receive your ping, and I assume the rest didn't either. Probably you've not signed the edit with the mentions. – Ammarpad (talk) 04:58, 6 May 2019 (UTC)
  • Request for example @Mike Peel: Can you provide an example where this proposal would change things? Can you talk through what the bot would check in that case to determine the need for a change? Blue Rasberry (talk) 13:55, 6 May 2019 (UTC)
    @Bluerasberry: For example, Category:2012 in the Maldives linked to commons:Category:2012 in Maldives, which was correct until the commons category was renamed. That was automatically updated on Wikidata, but required a bot edit here rather than updating automatically (as it would have if the locally defined text didn't exist). You can look through the edits of Pi bot to find many more examples like this. You can also dig through the other commons category tracking categories to find cases where the bot hasn't managed to catch it for some reason. The new bot would check for cases where the commons sitelink exactly matches the locally defined one, and would only remove it if that was the case. Thanks. Mike Peel (talk) 19:21, 8 May 2019 (UTC)
    I see, thanks. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)
  • When pulling from Wikidata, is there a link to the page where an edit may need to be made to correct the issue of a bad link (whether that's the same item or the category item)? --Izno (talk) 18:56, 7 May 2019 (UTC)
  • @Kerry Raymond: A sensible argument. If there were only the two sites, Wikipedia and Wikidata, then it could be said that Wikipedia, as the more active site, would be a good place to keep the data, since more people will monitor it. But consider: there are more than two sites. Besides the English Wikipedia, there hundreds of other Wikipedias, not to mention sister projects and all of their languages. Is English Wikipedia really the more active site for every page? Many of our pages are stubs, and some of those same pages are flourishing on other language editions. Wikidata is the natural central location to keep all of these links, so all of the Wikimedia family wikis can benefit from each others' work. ARR8 (talk) 00:34, 8 May 2019 (UTC)
    Is this RfC occurring on all Wikipedias and only proceeds if all WPs agree? This village pump can only decide policy for en.WP and not impose it on other Wikipedias and vice versa, so I don't see this as a relevant issue unless it's a global proposal. I don't have a problem with a Commons category being suggested based on information held in Wikidata but not to impose it. Kerry (talk) 02:01, 8 May 2019 (UTC)
    @Kerry Raymond: This RfC is enwp-specific, I'm not sure there's a good place to raise it globally across the different Wikipedias? But regardless of that, I'd contest that the 'ground truth' of this is now the sitelinks on Wikidata, not the locally defined text here. The sitelink is used on Commons to add the interwiki links to the various Wikipedias in the sidebar (the same as interwikis work here), and to display information from Wikidata about the topic of the category (through the infobox there). If that sitelink is wrong, then a Commons editor can fix it by editing Wikidata. However, that won't currently fix the link to the category from here, unless they also come to enwp to fix it, which they won't if it's a topic in a non-English country (I know you mostly edit about Australian topics, but think about editors that work on Portuguese or Spanish content both on their language wikis and on commons). Vandalism of the sitelinks is possible, but it's not trivial - you have to change the sitelink to point to a different, existing, category (compared with just changing some text in an article), so it's unlikely. For the cases that this RfC is concerned about, the information here is merely a copy that can easily go out of date. I'm out of energy to argue about your other points now, I'll follow up on them another day. Thanks. Mike Peel (talk) 19:39, 8 May 2019 (UTC)
    @Kerry Raymond:, well, at first Wikidata was used by everyone but users, who seemingly didn't believe very much in that project at begin :-) BTW I can assure that, as Commons admin and 'Data heavy user, the use of parametres in Commonscat is annoying/problematic for the correct maintenance of the categories on Commons. I'll omit the cases in which commonscat links to a whole improper category (this or this, for example); but there are a lot of Commonscat templates filled with Commons categories that either no longer exist or have been redirected. It's not a mattere of data authority (anyway, as a matter of fact, Wikidata users have to reference data too, thus 'ground truth' is a false argument. If you have a solid source for the data migrated on Wikidata, include it in the property on the Wikidata item, there are fields created just for that purpose, and the chain won't be broken...). -- SERGIO aka the Black Cat 08:06, 3 June 2019 (UTC)
    The Commons category named in an en.WP article represents at the time it was asserted the current consensus of which Commons category(s) best correspond to the article content. I agree entirely that changes on Commons can take place without alerting anyone on en.WP interested in that article. I would welcome some system of notifications so such relevant changes correctly propagate through the notification system cross-project so the changes to the Commons category can be reviewed by interested en.WP contributers (and of course vice versa). This proposal increases the existing problem by additionally allowing changes on WikiData to silently override the intentions of contributors on local projects. Each project controls its content; where we have dependencies between the projects, we need to find ways to manage such dependencies. Just as WP articles may reference a Commons category, many Commons categories contain links back to a Wikipedia article to provide a description of the topic in a specific language, so often there is mutual co-dependency. Right now we don't have any agreed social or technical process to notify and resolve cross-project dependencies, but I would like to think consensus from all affected projects would be the overarching principle. This proposal (not being discussed on Commons or any other WPs which allegedly benefit from it) will bypass consensus on other projects by silently automating and implementing a decision made on Wikidata. Wikidata right now is full of bad modelling and inappropriate population of data based on the presence of a certain template. One that directly affects me is Queensland place ID (P3257) which has incorrect constraints and has been populated incorrectly, resulting in hundreds of constraint violations for which I have asked "to fix the problems on Wikipedia", but Wikipedia is not the problem here, the problem is on Wikidata, but nobody on Wikidata will take responsibility for fixing the problem. If Wikidata contributers had bothered to discuss with Wikipedia contributors who use these place IDs in articles in the first place (i.e. created a cross-project consensus), we could have avoided the problem. As far as I know, there may be ongoing automated processes continuing to make this problem worse (I create new Queensland place articles all the time). Imagine if someone said "let's transclude the value of the Queensland place ID held on Wikidata automatically into Wikipedia articles", we would trash thousands of article and their citations with bad data. How does such a proposal differ from this one? Both are based on the unquestioned assumption that Wikidata has it "right" (or at least "more right" than any other project); well, I am questioning that assumption. Nobody has explained how having copied and removed the Commons category from an en.WP article, what keeps that data safe on Wikidata (whether from vandalism or the result of poor-quality modelling/population as I illustrate above) resulting in erroneously changed values on Wikidata being silently transcluded back into a rendered Wikipedia article bypassing those people on Wikipedia who maintain that article. I am not anti-Wikidata in concept, but I have developed an increasing concern about what is happening in practice given the apparent indifference to quality modelling and quality "scraping" from other projects. We need a cross-project dependency notification system and once we have that, we have a better basis for the kinds of automated transclusions being proposed as contributors on local projects would be aware of it, just as if it was manually changed on that local project. Kerry (talk) 09:26, 3 June 2019 (UTC)
    I know what you mean, @Kerry Raymond: but Commons is everyday less and less dependent on referencing, since there are templates like "Wikidata Infobox" or "Creator" that take data directly from Wikidata, and wikidata itself relies less and less on data imported from regional chapters (for example, all the data I upload on Wikidata come from reliable third party sources), and this will be the future of Wikidata: no longer a recipient of data collected from the local chapters but a centraliser of data collected from reliable sources. Further, consider that you can have on Commons a category on an item that doesn't appear in any Wikipedia, because Commons and Wikipedia have two different goals... -- SERGIO aka the Black Cat 08:49, 8 June 2019 (UTC)
First, I note it has not been raised on Commons:Village_pump/Proposals and that's just one place, but if the benefits are for all WPs as sugggested above, surely all WPs should be in this conversation. Kerry (talk) 23:22, 8 May 2019 (UTC)
Second, I don't think you understand what is meant by "ground truth", which Wikipedia defines as "information provided by direct observation (i.e. empirical evidence) as opposed to information provided by inference". In science, the ground truth is the laboratory notebook; you never destroy them, just because the information has been copied elsewhere, because in the event of questions/dispute, you always go back to the lab notebook. When it comes to Commons categories, the ground truth is the decision/consensus of editors on Wikipedia. Are you seriously proposing that Wikidata editors should decide from now on which Commons categories should be added to a new article and not Wikipedia editors? How will it work in practice? Let's say I have an article on the Marian sugar mill which has its commons category set as Category:Sugar mills in Queensland. Let's say someone takes a lot of photos of that mill and creates a sub-category on Commons called Category:Marian sugar mill, which is a better commons category for the article to use. Who will update it and how? A Wikipedian do so by updating the template in the Wikipedia article to add the new category, or will they be forced to go to Wikidata to do this? Can we have this proposal spelled out for the whole lifecycle please, currently all it deals with is taking existing information away from Wikipedia and does not explain what happens next, how updates will be oversighted, how and where disputes will be conducted. If we go down this path, I think we need Wikidata watchlist notifications that affect the Commons category to be propagated through into the watchlists of Wikipedia articles (on all WPs) that are affected by it. Not *all* Wikidata updates to the Qnumbered thing, just the ones affecting Commons category. If the watchlist situation can be resolved and the ability to update the Commons category locally from Wikipedia (and not having to learn anything about Wikidata), then I would be much less worried. Because who on Wikidata is putting their hand up to watch the Queensland sugar mill edits that I would normally watch on Wikipedia? And please don't bother to say that Wikipedians can watch directly on Wikidata, because that is unlikely to happen and we all know it. In IT it is never a good idea to remove the authority over data from the subject matter experts to database administrators, as it usually disengages the subject matter expert and then data quality falls as a result of the disengagement. Kerry (talk) 23:22, 8 May 2019 (UTC)
@Kerry Raymond: I'd be happy to point this proposal out on Commons and elsewhere, but then I'd probably be accused of WP:CANVASS. :-/ With most of what you say, substitute 'Commons' in place of 'Wikipedia', and it changes the perspective. The point is that Commons editors also play an important role in linking Wikipedias<->Commons, and using Wikidata to do this in one place is a lot better than doing it in multiple places. I'm not proposing to remove the ability to set a local link here if needed, so in the example you give you could still define that manually, I just propose to remove the duplication of exact data. There are over 2 million commons sitelinks now, and the 600k or so here is just a subset of that. Thanks. Mike Peel (talk) 06:08, 9 May 2019 (UTC)
It's only canvessing if you do so in a way to influence someone and, yes, the RfC as written does run that risk as it is supposed to be written to be NPOV. So rewrite the RfC to be NPOV and then advertise it on other sites that it affects. Kerry (talk) 07:20, 9 May 2019 (UTC)
In practice, I see a lot of Commons categories which were set here on the English Wikipedia long time ago and then moved on Commons. Our template leads nowhere (or sometimes to a category redirect) because nobody cared to go here (and to 200 other Wikipedias) and update the commonscat template. However, if a category has been moved on Commons, the record has been automatically updated on Wikidata, and the sitelinks in the same articles are usually correct.--Ymblanter (talk) 15:00, 11 May 2019 (UTC)
Oh, I see, Mike Peel has already made above the same point.--Ymblanter (talk) 15:02, 11 May 2019 (UTC)
@Ymblanter: It's a good point, worth repeating. :-) A lot of the work I've been doing here recently has been to try to fix these (by bot/manually), but it takes time, and it would be better if the problem didn't exist in the first place, hence this proposal. I hope you consider !voting on it. Thanks. Mike Peel (talk) 15:38, 11 May 2019 (UTC)
  • One of the concerns with {{Commons Category|<no parameter>}} was that if the article was moved, the category would then be wrong. This is the reason we have been adding parameters. Ideally this would track moves of the Commons category too. I'm not sure if this proposal addresses the first issue. All the best: Rich Farmbrough, 12:59, 16 May 2019 (UTC).
    • @Rich Farmbrough: - Yes, that's the idea. If things work correctly (they don't always), when you move a page on a local project that is linked to Wikidata, the software will automatically update WD with the new location. This applies equally to local moves here and it does on Commons. GMGtalk 13:05, 16 May 2019 (UTC)
      • But could the WD entry be manually overwritten, thus allowing a vandal to play havoc? - Sitush (talk) 06:39, 18 May 2019 (UTC)
        • @Sitush: How do you mean? The sitelink must link to an existing page, which should avoid most vandalism. Thanks. Mike Peel (talk) 16:30, 18 May 2019 (UTC)
  • @Fayenatic london: Cases like that are caught at d:Wikidata:Database_reports/Complex_constraint_violations/P910#Items_that_link_to_a_Commons_category - there's more of a backlog there than I thought, I'll look into it. Thanks. Mike Peel (talk) 18:45, 16 May 2019 (UTC)
    @Fayenatic london: Thanks for pointing this out. I've written some code to work through the cases where one of the sitelinks redirects to the other. It's also finding more cases here where the manually-defined text links to a redirect category, e.g., at Sierra de Grazalema Natural Park - those would be automatically fixed if this proposal passed, but as it stands they'll wait until pi bot next runs through the maintenance categories. There are also more complex cases that will take time to resolve, either manually or through more code. Thanks. Mike Peel (talk) 17:36, 18 May 2019 (UTC)
  • I've asked for a formal closure of this at Wikipedia:Administrators'_noticeboard/Requests_for_closure#Wikipedia:Village_pump_(proposals)#Survey_(Commons_category_links) - hopefully that will happen soon. Thanks. Mike Peel (talk) 19:11, 7 June 2019 (UTC)
    • Any volunteers to close this? @AGK: since you closed the last one, could you perhaps have a look at this? Thanks. Mike Peel (talk) 17:32, 21 June 2019 (UTC)

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.

Remove "suspected perpetrator" field in Template:Infobox civilian attack[edit]

(Discussion moved from Template talk:Infobox civilian attack#Suspected perpetrator field? on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at Christchurch mosque shootings and the contention over how prolific suspect Brenton Tarrant's name should be (see ongoing RfC about keeping suspect's/suspects' name in lead), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. U-Mos (talk) 03:28, 22 March 2019 (UTC)

(Comment copied from original discussion) I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. TompaDompa (talk) 08:17, 22 March 2019 (UTC)
  • I agree. This gets into NOTNEWS territory. We have to be aware that a reported “suspect” can be falsely accused (for example: the reports that Richard Jewell was a suspect in the bombing that took place during the Atlanta olympics). At a minimum, we need to wait until a “suspect” is actually charged with the crime before we report names. Blueboar (talk) 12:59, 22 March 2019 (UTC)
  • I also agree. If suspects are to be named in the article then we can word things to make it clear that they are only suspects, and to say whether they have been charged or prosecuted, but an infobox entry is too blunt an instrument for such sensitive content. Phil Bridger (talk) 13:33, 22 March 2019 (UTC)
  • The idea makes sense, but I know from how less experienced editors see infobox fields and if you took out the suspected perp field, they will want to fill the name in on the actual perp field because they feel it would complete the infobox (unaware of the implications of this towards BLPCRIME). --Masem (t) 13:36, 22 March 2019 (UTC)
    • Well, that gets us into the murkier question of what fields should be included in an infobox in the first place. Perhaps we shouldn’t even have a “perpetrator” field. Indeed, when it comes to this sort of topic, we probably need to question whether an infobox is aporopriate at all. Is an infobox an appropriate method for conveying information in an article about a mass killing? Blueboar (talk) 13:55, 22 March 2019 (UTC)
      • Arguably yes, it just shouldn't be filled in until after conviction. (Contrast that to a religon= field in the BLP infobox ) Its that well-intentioned editors unaware of why the field is blank will think to fix it blindly. --Masem (t) 14:09, 22 March 2019 (UTC)
        • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)
          • That would of course mean that when the perpetrator dies and there is no trial, there is nowhere to add them. Which is not necessarily a bad thing. TompaDompa (talk) 17:28, 22 March 2019 (UTC)
            • I think we should find a way to identify the perpetrator in some such cases, for example if there is a mass shooting that ends with the perpetrator killing himself (it's nearly always a "him"). The best way to deal with this whole issue would be for Wikipedia to stop trying to be a news service and only to have articles about events when good secondary sources (which breaking news reports are not) exist, but people putting forward that point of view always seem to get shouted down by people saying, "of course it's notable, it's front-page headlines in all the newspapers." Phil Bridger (talk) 17:50, 22 March 2019 (UTC)
              • +1. Never lose the dream, even if forced to drop the stick. ―Mandruss  21:56, 22 March 2019 (UTC)
            • And in cases where the perpetrator dies and there is no trial I believe that there's a difference between jurisdictions. In some places an inquest into the death of a victim will name in its verdict the person who caused the death, and in others it will not. Phil Bridger (talk) 17:54, 22 March 2019 (UTC)

I support changing "perpetrator" to "convicted" - feels more appropriate for factual record rather than mere description of an event, and hypothetically if there was an appeal in process or new doubts over a historical case it wouldn't invite any unnecessary infobox changes. U-Mos (talk) 06:23, 23 March 2019 (UTC)

Changing Wikipedia's infoboxes because some politicians want to play damnatio memoriae is not a good idea. Offering a choice of a "convicted" field per User:U-Mos is reasonable, but a plain "perpetrator" field should remain as an option even so. Because sometimes, for example, a widely known perpetrator might flee to ISIS territory or the next equivalent and not be prosecutable. Suspected perpetrators also should be described when sources widely describe the accusation. (WP:WELLKNOWN) Wnt (talk) 07:42, 23 March 2019 (UTC)

I don't see how describing suspected perpetrators in the infobox, where the room for nuance is scant to none, would be helpful. In prose is a different matter. TompaDompa (talk) 10:34, 23 March 2019 (UTC)
Why not? There are a lot of cases where the perpetrator is known beyond reasonable doubt but will never be convicted. Judicial sentences are not the only reliable source of information. On contrary there are cases where the person convicted is known not to be the perpetrator! Would not it be helpful to describe convicted but not guilty persons in the inforbox where the room for nuance is scant to none helpful? You seem to put to much trust in formal convictions. In addition, what is conviction? There is no clear definition of this term. Ruslik_Zero 08:45, 24 March 2019 (UTC)
That a convicted person may not be the perpetrator seems a very good reason for the change to me. Having the field as "convicted" removes any form of supposition, leaving any nuances or complications to the prose where they can be outlined in all necessary detail. U-Mos (talk) 08:53, 24 March 2019 (UTC)
This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)
  • Convicted is not quite the right answer. If the perp dies he is not convicted. If he confesses or brags/claims responsibility we can name without conviction. I'd venture that at least half the places this box would be used never see a conviction. Legacypac (talk) 09:28, 24 March 2019 (UTC)
    • Why's that an issue? If they die, and are therefore not convicted, do they need to be in an infobox? U-Mos (talk) 23:05, 25 March 2019 (UTC)
      • Yes, they need to be in the infobox because this is important information. Ruslik_Zero 13:47, 27 March 2019 (UTC)
        • +1 to LegacyPac's point about conviction being the wrong standard for this, with suicide bombings and most unprosecuted war crimes being two obvious cases where the perpetrator is known with certainty but there is no judicial process confirming guilt.--Carwil (talk) 17:15, 1 April 2019 (UTC)
  • Creating an additional template for suspects and one for perpetrators would remove all the confusion. ~^\\\.rTG'{~ 23:35, 25 March 2019 (UTC)
  • Oppose. In some cases it is appropriate for us to name the perpetrator prior to his conviction (e.g. when extremely widely reported in highly public events, or when the suspect evaded capture and trial (which in many places can't be done in absentia) - but it known with a high degree of certainty). In other cases - e.g. historic cases, events in warfare, etc - while we might not have a definite perpetrator it might still be appropriate to name in the infobox those covered extensively in RSes. Icewhiz (talk) 11:45, 2 April 2019 (UTC)
  • The template should first be merged into {{Infobox event}}; then the parameters should be rationalised. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 2 April 2019 (UTC)

Note: This proposal was restored from the archive for the purpose of consensus being assessed and the discussion closed. TompaDompa (talk) 22:31, 18 May 2019 (UTC)

  • Not sure if this means it's still open for votes, but if so support per WP:NOTNEWS, etc. Any time it's actually warranted can be covered in article prose. – John M Wolfson (talkcontribs) 23:35, 18 May 2019 (UTC)

Proposal for a new file naming criteria: harmonize extension name[edit]

Hi. I recently came across some oddly named files, and it prompted me to do some digging. Below is a table of the number of images hosted locally on enwiki by file extension in the name:

Extension Count
.jpg 586975
.JPG 39738
.jpeg 20617
.JPEG 309
.Jpg 62
.Jpeg 16
.jPG 1
.JPeG 1
.JpG 1
Extension Count
.png 167198
.PNG 9677
.PnG 1
.pNG 1
.Png 1
Extension Count
.svg 25507
.SVG 13
Extension Count
.gif 21548
.GIF 749
Extension Count
.tif 596
.tiff 402
.TIF 17
Extension Count
.ogg 9294
.OGG 24
.oga 1
Extension Count
.pdf 476
.mid 146
.ogv 91
.bmp 65
.webp 48
.webm 40
.wav 31
.mp3 19
.xcf 15
.opus 9
.MID 7
.flac 2
.pov 1

You can see, for example, that JPEG files are split between .jpg, .JPG, .jpeg, .JPEG, .Jpeg, .jPG, and .JPeG, .JgP, while PNG files are split between .png, .PNG, .PnG, .pNG, and .Png. Even if the "jpg" vs "jpeg" shouldn't be standardized (I think it should be), I believe that the differences in capitalizations should be resolved, since file names are case sensitive. Thus, I propose the following new criteria, to be added to WP:FMV/W:

  • Harmonize file extension format names to ease their usage

With the following formats prefered: .jpg, .png, .svg, .gif, .tif, and .ogg. This is not a proposal to prefer a specific format over another, but rather to standardize the suffixes for files already of the same format. --DannyS712 (talk) 23:10, 29 May 2019 (UTC)

Survey (file format names)[edit]

  • Support new criteria as proposer --DannyS712 (talk) 23:12, 29 May 2019 (UTC)
  • Meh for most feel free to clean up the obvious ones with very low populations, but I really don't care to see 40,000 files renamed from JPG to jpg for example. — xaosflux Talk 23:40, 29 May 2019 (UTC)
  • Oppose First, please establish a need for the change - for instance, does a variant extension mean that a file becomes undisplayable? Second, you say "harmonize file extension format names to ease their usage" - in what way would usage be eased? Third, this is unenforceable, since there are far more images hosted at Commons than here on English Wikipedia, and we cannot make a decision here that would change policy on Commons. --Redrose64 🌹 (talk) 10:15, 30 May 2019 (UTC)
  • No thank you. I can appreciate the desire to keep things tidy and organized, and I give the OP credit for doing the research and crunching the numbers. But if the name/extension of a file isn't impeding its use in any way (and I don't see how it can be), then this is a make-work project that will annoy all the thousands of users who uploaded images to Enwiki with the "wrong" file extension without any improvement to the file, to its use in articles, to its usability. More importantly, the overwhelming number of files used on English Wikipedia are hosted on Wikimedia Commons, which does not have such criteria for files. In other words, there are still going to be tens to hundreds of thousands of images that *still* have the "wrong" file extension. It's not possible to enforce consistency on this. Risker (talk) 16:46, 30 May 2019 (UTC)
  • Support - making the format names consistent will help in some situations where users might "fix" image files without realizing that the formats are case sensitive (because of course they are...), and as Danny says might also help users find files in some situations. There really is no down side to this. The "mark-work" is not placed on anyone, as I'm pretty sure Danny, as a person that helps out with bot requests, will do this themselves, and users should feel no more annoyed by this, as they would if an article or template was moved. Also, specifically, I'd hate to see files like "pNG" in a FA. Now that's annoying. --Gonnym (talk) 17:18, 30 May 2019 (UTC)
  • Oppose per Redrose's comment about the proposed change not syncing with Commons and Risker's comment about make-work that annoys thousands. It was interesting to see the data about enwiki though, so thank you for posting them. Killiondude (talk) 19:34, 2 June 2019 (UTC)
  • Oppose per Redrose and Risker. Thryduulf (talk) 17:43, 3 June 2019 (UTC)
  • I see no good reason for this honestly... Maybe the mixed case versions would be acceptable to me, but the rest... It's just not an issue i regularly see people struggle with. —TheDJ (talkcontribs) 07:17, 4 June 2019 (UTC)
  • Support basically per Gonnym. I see this as basically like an MOS-type thing. The source (the user who uploaded the file) may do things however they want in their personal usage, but Wikipedia will harmonize usage for itself. --Khajidha (talk) 22:10, 7 June 2019 (UTC)
  • Oppose per Redrose and Risker.--Vulphere 17:24, 12 June 2019 (UTC)
  • Support. Having spent a considerable amount of time on the related project of moving non-descriptive TLA-titles for Commons files to names descriptive of the file contents, it was surprising and unpleasant the degree to which file names for completely unrelated things could be identical but for capitalization of the filename extension. It is not technically difficult to make every filename unique irrespective of this capitalization, and we should do it. bd2412 T 02:07, 17 June 2019 (UTC)
  • Weak Support - having been tripped up many times by suffix variations, and resolved several troubleshooting requests by new users who couldn't get an image to display (for this reason), I would appreciate this. That said, I think all of those cases I've been involved with were on Commons, not here. It would be ideal for this to happen there, too, but I just don't see any downside here. Assuming Danny is willing to tackle the particulars, I see no reason to get in the way. I don't really see "annoyance" as a reason not to do this, either. Anyone dedicated enough to their watchlist to care about such a thing should know how to hide bot edits. — Rhododendrites talk \\ 18:00, 23 June 2019 (UTC)

Discussion (file format names)[edit]

  • See also: c:Commons:Village pump/Proposals/Archive/2018/12#Normalize file extensions for new uploads
  • @Redrose64: file extensions are case sensitive - for the 749 .gif files that are named as .GIF, users must remember to capitalize the file extension. The data above only deals with files that are hosted locally, and it would be easier to use local files if extension names were consistent. --DannyS712 (talk) 16:10, 30 May 2019 (UTC)
    • I'm having a hard time wrapping my head around this explanation. Do people *really* enter the entire file name by hand including extension when searching for/inserting a file? They don't use the search function? They don't copy/paste the file name? Risker (talk) 16:39, 30 May 2019 (UTC)
      I do, and others probably do so too, or even if they don't it would be easier to do so if extensions were standard --DannyS712 (talk) 16:41, 30 May 2019 (UTC)
      I don't see how this would make copying and pasting any easier or harder than it is with inconsistent names. Phil Bridger (talk) 18:04, 30 May 2019 (UTC)
      File extensions are case sensitive on Wikipedia and some operating systems like Unix. But on Windows-type setups, they are case-insensitive. If you use a Windows application like MS Paint to create an image, then when you come to save the file for the first time you get a dialog box which includes a selection for the file type. The selection that you make will set the file extension, and it's always uppercase (you can use Explorer or similar to rename the file with a lowercase extension later on, and it won't make any difference as far as Windows is concerned - but not all users will bother to do that). Who are we to say that lowercase is the only correct form? Do Unix browsers reject uppercase file extensions? --Redrose64 🌹 (talk) 22:18, 30 May 2019 (UTC)
      @Redrose64: I don't use a unix system, and I am explicitly not saying that lowercase only is the correct form. All I suggest is that the extension formats be consistent. This should make absolutely no difference to users (such as yourself) that copy-and-paste the file name, but for users that want to type the file name, it should be consistent. If (not a part of this proposal) a bot were to execute the file moves, meaning that there wouldn't be any extra work for users, what downsides would you see from harmonizing the formats? I understand where the differences come from (thanks for that explanation by the way) but that doesn't mean that they should be kept. --DannyS712 (talk) 07:20, 17 June 2019 (UTC)
  • I really don't see any value to this proposal, other than making things look tidy, which, if you looked at my desk, you would see is not something that I rate highly, so it would be better if people spent their time on doing something that actually improves the encyclopedia rather than on such make-work projects. Phil Bridger (talk) 18:04, 30 May 2019 (UTC)
Moving the file to the consistent file names could be automated by a bot (leaving a redirect), except if the filename is already in use. --Chanc20190325 (talk) 18:05, 1 June 2019 (UTC)
But why do it? What benefit does this bring to Wikipedia, especially when most of the files we use are are hosted at Commons? Phil Bridger (talk) 18:48, 1 June 2019 (UTC)
To clarify: the above data is for images that are hosted here on enwiki. I've added the data for commons below. --DannyS712 (talk) 06:03, 3 June 2019 (UTC)
Commons data
Extension Count
.jpg 38954436
.JPG 7115025
.jpeg 722895
.JPEG 7176
.Jpeg 961
.Jpg 583
.jPG 47
.JPg 24
.jpG 15
.JPeG 7
.jPeG 7
.JpEg 5
.JpG 3
.jPg 2
Extension Count
.png 2473405
.PNG 125542
.Png 34
.pnG 2
Extension Count
.svg 1493642
.SVG 507
.Svg 4
Extension Count
.gif 167101
.GIF 5515
.Gif 16
.gIF 1
Extension Count
.tif 1110594
.tiff 200199
.TIF 3357
.TIFF 16
Extension Count
.ogg 919282
.oga 7166
.OGG 312
.Ogg 15
Extension Count
.pdf 443407
.PDF 867
.Pdf 1
Extension Count
.webm 71003
.WebM 36
.Webm 1
Extension Count
.djvu 108225
.Djvu 2
Extension Count
.wav 127401
.WAV 26
Extension Count
.ogv 69589
.OGV 15
Extension Count
.mid 5056
.MID 314
Extension Count
.flac 15305
.mp3 8571
.xcf 1283
.stl 1022
.webp 670
.opus 661

Thank” button in signature.[edit]

I suggest adding a “thank” button in the Wikipedia signature to be able to thank faster without searching the revision history. Example: –Chanc20190325 (talkthank) 13:55, 2 June 2019 (UTC)

  • Oppose. Benefit: Saving of perhaps 20–30 seconds for most thanks, for the small fraction of comments that receive thanks. Cost: About 35 characters of additional markup in the wiki editor window, for every comment posted by a registered editor using the default signature. Cost exceeds benefit. AFAIK there is nothing currently in signature policy to preclude this in a customized signature. ―Mandruss  14:34, 2 June 2019 (UTC)
    @Mandruss: Except from a technical standpoint, thanks depends on REVISIONID data, which can not be substituted. So while you could link a link to thank me for something static I did in the past (e.g. (CLICK HERE TO THANK ME FOR BEING THE BESTEST) you wouldn't be able to thank me for the edit related to that instance of the signature. — xaosflux Talk 16:07, 2 June 2019 (UTC)
    I think you're saying that this would be impossible in a customized signature. I can live with that. ―Mandruss  16:40, 2 June 2019 (UTC)
  • Oppose. I really do not think it's necessary, maybe it will save you a few seconds, but I think the editors are here to improve Wikipedia and not for recognition.--AnbyG (talk) 08:41, 3 June 2019 (UTC)
  • Comment - I like the idea, but also get that adding additional markup/text in each instance of a signed comment could add up to a lot. I wonder if there's a way to handle this with a script for those who want it? Perhaps pulling a diff based on the timestamp/name? — Rhododendrites talk \\ 20:18, 4 June 2019 (UTC)
  • Oppose per others. Millbug talk 03:27, 7 June 2019 (UTC)
  • Oppose per others.--Vulphere 17:26, 12 June 2019 (UTC)
  • @Enterprisey: Did you have some gadget which provided this functionality? I thought that you did. Blue Rasberry (talk) 19:35, 12 June 2019 (UTC)
  • Leaning oppose. The vast majority of times that I thank someone, it is because I am already looking at the specific diff to see what they've added. I don't know if this is the common experience, but surely I can't be the only one doing that. bd2412 T 02:10, 17 June 2019 (UTC)
    I'm the other one, you're not crazy. InedibleHulk (talk) 02:40, June 24, 2019 (UTC)
  • Oppose, but might be a good idea for a user script. Anne drew 14:02, 19 June 2019 (UTC)
  • Oppose The easier it gets to thank people, the less genuinely thankful other people need to be to instaclick a button, and the more our notification feed is oversaturated with platitudes from merely suggestible folk. You think Kanye West feels any sort of joy when he gets a like, thumbs up or booty call anymore? It could happen to any of us in the public eye, best to set a simple impulse barrier, like we have. InedibleHulk (talk) 02:35, June 24, 2019 (UTC)
  • This could definitely be written, but the script would have to dig through the page history to figure out when a particular comment was added. If there's enough demand, let me know. Enterprisey (talk!) 05:14, 24 June 2019 (UTC)

A new use for Wikidata external IDs in Wikipedia (template)[edit]

I would like to propose a new template which would make a more visible use of the external identifiers contained by Wikidata. Similarly to Authority control and Taxonbar, it would collect the IDs leading to pages which expand on the subject with additional text (so not only data) like encyclopedias, biographies, etc. This would create a condensed portal to trustworthy sites and could:

  • encourage further reading
  • propagate and show reliable sources
  • make Wikidata more visible
  • add depth to article stubs, help finding sources for expanding them

Visually, I would imagine that the template could follow (or be part of) the infobox or it could be a sidebar next to the External links section. It could also be set as default to the language of the Wiki it is used in so in the German Wikipedia it would only list (or prioritise?) German language sites.

Two examples for what the template would contain (here without the language setting):

From the side of Wikidata I think it would require:

  • labeling external IDs according to content type (new property)
  • labeling language of external IDs (mostly done)

From the side of Wikipedia:

  • template coding, design
  • documentation of the template

What do you think? Please also indicate if you would like to help in the development. - Adam Harangozó (talk) 13:04, 9 June 2019 (UTC)

  • Mixed opinion - I have no problem with templates that export data from Wikipedia TO Wikidata... I continue to oppose templates that would automatically import data FROM Wikidata. I see no benefit to our project in this proposal. Blueboar (talk) 13:15, 9 June 2019 (UTC)
    Does it follow that it takes use cases that show how Wikipedia will benefit from data FROM Wikidata or is it just that you are against? Thanks, GerardM (talk) 17:31, 9 June 2019 (UTC)
    Blueboar, if you see no benefit for Wikipedia readers to get curated links to high-quality third-party sources, then perhaps the problem is your vision, and not Wikidata? --Magnus Manske (talk) 08:35, 10 June 2019 (UTC)
    I see great benefit to including curated links... but the curation has to be done manually, here on WP... not automated through WD. Blueboar (talk) 11:14, 10 June 2019 (UTC)
    What makes you think curation on WD is "automated"? There are certainly more bots and tools involved, but mostly because WD is easier to edit through those. Tools like Mix'n'match do a combination of manual and automated (where highly reliable) curation. Claiming WP is, overall, better at curation is insulting at best. --Magnus Manske (talk) 14:05, 10 June 2019 (UTC)
    You miss the point... the curation needs to be done HERE on WP... not at WD. Blueboar (talk) 14:28, 10 June 2019 (UTC)
    The first round of curation is done on Wikidata: already the fact that there is a property for that external ID means that there was a consensus about its importance. Also, if we label it there as having descriptive text is another round of filtering. After this the export would be automatic but I think there should be an option to manually exclude IDs from the template in the article. Adam Harangozó (talk) 17:54, 11 June 2019 (UTC)
    ”The first round of curation is done on Wikidata”... exactly... that is what I object to. Blueboar (talk) 22:30, 18 June 2019 (UTC)
  • Oppose any further automatic import from Wikidata. To pick up Magnus Manske's phrase, the problem is that a lot of links in Wikidata are not curated links to high-quality third-party sources. The "curation" is far less than here, as there are far fewer active editors. There's isn't the body of long-established and widely discussed policy which defines what a "high-quality third-party source" is, as opposed to the policies on sourcing here. Peter coxhead (talk) 09:07, 10 June 2019 (UTC)
    I protest this (deliberate?) mis-quote. The display of WD data on WP would be automated. The curation on WD is a mixture of manual (as here on WP, but with better tools) and automated (where highly reliable). Please change to Support, or remove me as your reasoning. --Magnus Manske (talk) 14:08, 10 June 2019 (UTC)
    I believe that most of the external IDs collect reliable sources but even if there are exceptions this could be sorted out when labeling their content type on Wikidata and any problematic source could be removed manually from the template later. An overview of some of the sites that are being worked into WD (here only the biographies): Adam Harangozó (talk) 18:05, 11 June 2019 (UTC)
  • Support: I believe this is an important step towards the main goal of Wikidata: to feed sister projects with structured data. --Hjfocs (talk) 09:08, 10 June 2019 (UTC)
  • Support: but with a couple of caveats. Number of external IDs (too much ?), language of external IDs (Russian or Italian less helpful in WP-En), probably this project would benefit from some design and curation work on the WD side. Kpjas (talk) 09:24, 10 June 2019 (UTC)
    • probably this project would benefit from some design and curation work on the WD side – yes, but that's the problem for me. Who is going to do this work? Consider {{Taxonbar}} as an example. This template is now present on the great majority of articles about organisms. My experience is that when I create a new organism article (I mostly work on plants and spiders), on average I have to spend quite a bit of time (perhaps one third to half the time to create a "Start" class article) fiddling with Wikidata items to get the taxonbar to work as it should in our article – and quite often it's not entirely possible, because the design principles of Wikidata are not compatible with ours (e.g. insisting on 1:1 relationships between wiki articles and Wikidata items, when this is not how it actually is). So the odds are that if the curation of Wikidata were done well, it would involve considerable continued input from editors here, which distracts from the main goal of building an English language online encyclopedia. If there were lots of receptive editors at Wikidata, open to discussions, it would be a different matter. But that's not my experience. Peter coxhead (talk) 10:06, 10 June 2019 (UTC)
      • I really think this could be more constructive. Of course there might be issues but WD are WP are for each other not against. The 1:1 relationship would work with articles about individual people, and the others we might need to work on more - from both sides. Also, please check Elmidae's opinion below. Adam Harangozó (talk) 18:22, 11 June 2019 (UTC)
    • The number of IDs shown is a design question regarding the template on Wikipedia (sidebar, navbox, collapsing, etc.). The languages have to be tagged in Wikidata but as I said I think the template should only show IDs that are in the language of the WP article. (This would also keep the numbers at bay.) Adam Harangozó (talk) 18:22, 11 June 2019 (UTC)
  • Oppose per Peter coxhead. This scope creeping by Wikidata aficionados needs to stop and they need to get their own house in order. We have enough maintenance problems here without importing more from somewhere else. - Sitush (talk) 10:50, 10 June 2019 (UTC)
  • Neutral middleground Hi all, there is a grant project that could help out here called GlobalFactSync (GFS). The major problems are: (a) On the one hand, Wikidata is not considered good enough yet to be imported into WP-EN, so GFS tries to sync all info from WP-EN into Wikidata to improve it. (b) On the other hand, Wikidata is used in exactly the proposed way in the Italian Wikipedia, see Usain_Bolt#Collegamenti_esterni GFS just started, but discussion as such seem very relevant. We are looking for 10 concrete sync targets. One will be the domain of Albums/Singles with MusicBrainz. So another one could be the links to the external sites mentioned above. The goal is to improve Wikidata in these sync targets to a level that meets WP-ENs standards and then make it much easier to maintain, so quality stays better than now and work becomes less. GFS just started, so we will still need good feedback. SebastianHellmann (talk) 12:08, 10 June 2019 (UTC)
    • Thanks, I'll check this out. Though I think it would be important to have this as a separate template and not to mix it with the external links section. Adam Harangozó (talk) 18:25, 11 June 2019 (UTC)
  • Support. Please inform yourself about Wikidata before tossing a vote because you heard your buddy say "WD is bad". Don't make this another Brexit referendum; there, it was all the EU's fault... --Magnus Manske (talk) 14:11, 10 June 2019 (UTC)
  • Support. Indeed a good idea and it is definitely too simple to claim one wiki project to have in general beetter quality than another one it just depends on the topics and often just the individual item or article. Unfortunately users tend to see the projects they are deeper involved with in a much more positive way than other projects they are less involved in. Robby (talk) 16:22, 10 June 2019 (UTC)
  • Weak support I share the concerns about the reliability and curation of Wikidata. This does not reflect on the work of the editors on that project, but on the fact that there are so many fewer eyes on harder-to-curate material. For most purposes, WD import into WP still seems like a dangerous proposition. - Having said that, this particular proposal sounds largely innocuous to me. As with WP, the main issue with misleading material in WD is statements that are not backed up by sources. Bypassing any import of statements and directly linking to sources avoids this step (and it is the step where shit mostly happens, if it does); and readers must always be capable of assessing sources for themselves. This would in effect work like an extended "External links" section, and probably of overall better quality than that. --Elmidae (talk · contribs) 18:04, 10 June 2019 (UTC)
  • Too soon to ask. I think this proposal, while well-intentioned, needs some more workshopping before we can come to a reasonable conclusion. For example, is the proposed new property of external ID content type something that Wikidata wants, and how will this be implemented? What types of IDs would we import and what types would we exclude? What happens if someone disagrees about importing a particular ID? Will it be possible to exclude it on the article level, on a more global level? Would there be overlap with the existing {{authority control}}, which already imports some external IDs from Wikidata? How will this proposal interact with WP:EL? Will there be a max number of links imported? For the moment until some of these questions are answered I will oppose the proposal, but I'd encourage some more work in conceptualization with an eye to a future proposal. I'd also expect that such a template would need a broad RfC before widescale implementation. Nikkimaria (talk) 00:51, 11 June 2019 (UTC)
  • Support per many of the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 12 June 2019 (UTC)
  • Oppose would directly violate WP:EL - which requires external links are justified on-wiki on their merits. A template drawing through whatever Wikidata is deciding to host today doesnt fulfil our editorial criteria. Most of the examples above would fail point 1 of WP:ELNO. As an aside two of the links above triggered my virus scanner for malware/popup-ads. Only in death does duty end (talk) 21:30, 12 June 2019 (UTC)
  • Oppose. The issues I list below range from "difficult" to "effectively impossible" to resolve, and the list clearly incomplete:
    • Wikidata content is not subject to Wikipedia policies and guidelines, including but not limited to WP:EL. Challenged External Links are removed and stay-out unless there is an active consensus for inclusion.
    • Any such content needs to be administered on Wikipedia.
      • Even non-autoconfirmed editwarrior or vandal can go to Wikidata and BYPASS Full page protection. An IP editor could even bypass Superprotect (if it were redeployed). This is a fundamental design problem with Wikidata integration.
      • Page protect at Wikidata can prevent us from repairing policy violations on our articles, even if Nazism or pedophilia related content is maliciously placed on the biography of a living politician.
      • It bypasses our editfilters and link blacklists.
    • Any such content needs to be curated on Wikipedia.
      • It's impossible to find (and potentially clean up) these links, as they don't show up in search results.
      • A significant number of editors here are are uninterested or unwilling to go to Wikidata to edit.
      • It makes things more difficult for new users - and even for many experienced editors. The content magically appears in the article, and it can be confusing to figure out where the hell it's coming from. And once you do find where it's coming from, Wikidata imposes a different and potentially confusing interface that is (in my experience) functionally deficient. To anyone who is happy with Wikidata and the Wikidata interface: Good for you. Not everyone agrees with you, and it creates an additional and unnecessary hurdle for those who don't agree with you.
    • The majority of Wikidata edits are essentially a bot-farm, with some human edits intermingled. Note: Wikidata "editor" statistics are wildly inflated. For example when a page tracked by Wikidata is moved, that edit gets mirrored as a Wikidata edit by that user.
    • We really don't need the headaches of cross-language editwarfare. In particular, there's currently major drama at Meta involving a language-wiki where essentially the entire admin corp are waging "information warfare" of genocide denialism. Note that Google Translate for the language is abysmal and often reverses the meaning of a sentence, making any sort of discussion almost impossible. Alsee (talk) 07:22, 16 June 2019 (UTC)
    • The huge RFC on Wikidata-in-infoboxes ended with approximately half of the community wanting Wikidata gone from infoboxes. We should not be rolling forwards major Wikidata integration until we can reach some consensus on whether we want to keep or eliminate the existing integration. Alsee (talk) 07:22, 16 June 2019 (UTC)
    • Again: The proposal is for links to a set of sites curated here on Wikipedia, much as is already done in {{Authority control}} or {{Taxobar}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:57, 18 June 2019 (UTC)
  • I love the idea of using Wikidata more on Wikipedia. I've read through your proposal a few times, and I'm not really sure exactly what it is you're proposing; could you produce a few mockups to illustrate your idea? --Deskana (talk) 21:15, 16 June 2019 (UTC)
  • Support.--Vulphere 05:52, 27 June 2019 (UTC)


I propose making rollback available on mobile devices (cell phone, iPad, etc...). I originally applied for rollback thinking that it would appear on a mobile device diff the same way it does on a computer. However, at this time, rollback is only on computers. I think it would be better to make rollback available on mobile devices is for convenience. LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 14:45, 9 June 2019 (UTC)

This will be available as part of feature-rich mobile history page being developed as part of mw:Advanced mobile contributions project. A beta version has already been deployed on some wikis; see prototypes in this task. – Ammarpad (talk) 09:34, 11 June 2019 (UTC)
On mobile you can switch to the desktop interface. The writing is tiny, and you may have to zoom in to be able to touch the right link, but it can work. Graeme Bartlett (talk) 08:22, 14 June 2019 (UTC)
Plus it confirms that you meant to click on the rollback link to avoid accidental rollbacks.--Breawycker (talk to me!) 00:09, 17 June 2019 (UTC)
@Graeme Bartlett: you said that I can switch to Desktop Interface on mobile devices. How do I do that? LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 05:41, 21 June 2019 (UTC)
Scroll to the bottom of any page in the mobile view and you can click on the link that says, "Desktop". Killiondude (talk) 05:43, 21 June 2019 (UTC)

RfC: Deprecate aka WebCite[edit]

This RfC is to allow editors and archive bots the voluntarily leeway to stop using and replace existing URLs with other archive providers where available. To begin divesting from WebCite. 14:49, 13 June 2019 (UTC)


  • Approximately 5% of Enwiki archive URLs are to, 5% to, 2% to "others" (Library of Congress, etc), and 88% to - in raw numbers there are about 5 million archive links of which about 250,000 to are to
  • is unreliable. Talk:WebCite#Service_outages lists known outages and there have been others. Outages can last for days and weeks.
  • WebCite is a non-profit and almost shut down in 2013 due to lack of funding. The site has not changed since - documents, features, bugs etc.. no evident development of the service or changes to the website in years. Bug reports go unanswered and unresolved. It appears to be the work of Gunther Eysenbach and not a full-time occupation.
  • WebCite is one of the oldest archiving services. It was unique for archiving on-demand vs. automated crawling. On-demand archiving is now available at Wayback, etc.. a standard feature at most archive services. There is nothing that sets WebCite apart that other archives can not do, and do better.
  • WebCite uses a system of accepting archive requests, returning an archive URL, backgrounding the job then emailing if the archive was successful or not. Often users submit a job and get the URL and paste it into Wikipedia without waiting to see if the archive request was successful. As a result:
  • WebCite has the highest rate of archive link rot. My bot WaybackMedic monitors archive links and WebCite is the leader in terms of raw numbers of links that need replacing with other archives, despite only representing 5% of the total archives.


  • Archive diversity is important. WP:WEBARCHIVES lists about 20 archive providers currently in-use on Enwiki. Plus, not every archive has every page, some will have a page that others do not (eg. does not have everything). In the end it is up to users which archive provider they choose.
  • This RfC would demonstrate a general best practice of avoiding and/or changing WebCite URLs to other archive providers. Deprecate does not ban the site or make a hard red-line rule. It would give users and bots some leeway to begin changing URLs and point to this RfC as a rationale. It would change the documentation to encourage users to use a different provider. Users who still wish to maintain a WebCite URL can add {{cbignore}} to keep bots away and act as a notice to maintain the URL. If WebCite is the only source for an archive it should obviously be kept and not converted into a {{dead link}}. -- GreenC 14:49, 13 June 2019 (UTC)

Survey (deprecate WebCite)[edit]

  • Support per above and survey bump. -- GreenC 14:49, 13 June 2019 (UTC)
  • Support I used to use WebCite but Wayback does everything it did, and better.-- Pawnkingthree (talk) 16:34, 13 June 2019 (UTC)
  • Support per the above. Kudos to the initiator for one of the best written proposals I've seen on Wikipedia. Thryduulf (talk) 21:43, 15 June 2019 (UTC)
  • Support. It's clearly beneficial both to readers and editors to prefer archive sites which are more stable and actively maintained, if they are equivalently archiving the content. Alsee (talk) 06:06, 16 June 2019 (UTC)
  • Support It is out of service again and is unreliable due to its outages. The archive for links that are dead needs to be reliable. AhmadTalk 16:29, 16 June 2019 (UTC)
  • Support its better to use a archive website which is more reliably up, so that our readers can nearly all of the time see the archived source. I agree that outright banning of WebCite is a bad idea, as diversity in archive websites is a good thing, but conversion to Wayback is something which (unless WebCite becomes more reliable) needs to be done. Dreamy Jazz 🎷 talk to me | my contributions 21:16, 18 June 2019 (UTC)
  • Support - per above. ___CAPTAIN MEDUSAtalk 17:58, 19 June 2019 (UTC)
  • Oppose for the reasons I wrote below. All of the arguments given here are why other archivers are better than WebCite. They aren't reasons why WebCite is useless or detrimental except insofar as there is a better alternative. My position is that the best solution would be making it so that we can use multiple archivers. Redundancy. A citation has a WebCite archive? Add one for and There are problems with all of them. That's not to say that the others aren't overall better, but that it doesn't need to be a choice. If we can use multiple, nothing is gained by removing WebCite. — Rhododendrites talk \\ 05:16, 20 June 2019 (UTC)
  • Support; at the very least, using WebCite to save pages that are currently live should be discouraged since better options are clearly available. Jc86035 (talk) 10:48, 20 June 2019 (UTC)
  • Support - Seems like a reasonable proposal. Editors can continue to use "WebCite" if they wish, it just wont be via bot. - Knowledgekid87 (talk) 16:25, 20 June 2019 (UTC)
  • Support - There are no indications that the situation with WebCite will improve in the future; instead, it is reasonable to expect further deterioration. — kashmīrī TALK 09:54, 22 June 2019 (UTC)
  • Support - I think that WebCite has to be given full credit (with citations :)) for (apparently) being a pioneer in on-demand URL archiving. I'm not sure how to do that, apart from solidifying its Enwiki entry. But unless the WebCite maintainer(s) very quickly inform Wikipedia (or the world) about a major overhaul and long-term sustainability project and convince us that the probability of future down time will drop to very low, this proposal makes sense. The world of knowledge should not be dependent on a single well-intentioned, hardworking individual. See the discussion section below for a related proposal of implementation, which seems to implement Rhododendrites' point above: add archive1url, archive1date, dead-archive1url, archive2url, archive2date, dead-archive2url, ... parameters to the standard citation template; possibly retain the WebCite urls but convert them to archive2url, archive2date, dead-archive2url=yes. [Comment: I have added a huge number of WebCite urls to Enwiki and I'm hoping that webcitation will return to online status at least long enough to make sure that alternative archival backups can be created. A lot of articles risk being greatly weakened without archival references, and this especially affects WP:BIAS.] Boud (talk) 16:43, 22 June 2019 (UTC)
  • Support per above.--Vulphere 05:50, 27 June 2019 (UTC)

Discussion (deprecate WebCite)[edit]

  • Comment Could we have a list of the other web archiving sites available? Personally, I am only aware of In my experience it's not true that they all do everything. Some may capture greater depth in terms of links off the selected url which may be necessary for context. They also don't all capture the same content, for instance, webcite captures pdfs, unlike Philafrenzy (talk) 22:00, 13 June 2019 (UTC)
    • Wikipedia:List of web archives on Wikipedia Graeme Bartlett (talk) 23:16, 13 June 2019 (UTC)
      Thanks, the number on that list allowing on-demand archiving, which is what we are principally concerned with here, is small is it not? Philafrenzy (talk) 01:13, 14 June 2019 (UTC)
    • captures PDF so does (ie. and most of the others. This RfC concerns which does not work at all. Like, right now. It is a dead site, forcing 250,000 links on Enwiki offline. For about a week and counting. This is not the first or even fifth time. It is unadvised to use it if other equally good options are available. -- GreenC 00:42, 14 June 2019 (UTC)
  • @GreenC: This RfC is not showing properly at Wikipedia:Requests for comment/Wikipedia technical issues and templates, so in accordance with WP:RFCBRIEF (sentence beginning "If the RfC statement is too long"), please provide a brief and neutral opening statement. --Redrose64 🌹 (talk) 22:12, 13 June 2019 (UTC)
    User:Redrose64: This RfC is to allow editors and archive bots the voluntarily leeway to stop using and replace existing URLs with other archive providers where available. To begin divesting from WebCite.
    -- GreenC 00:31, 14 June 2019 (UTC)
    OK, after JJMC89 (talk · contribs) did this, the effect is this. --Redrose64 🌹 (talk) 15:57, 14 June 2019 (UTC)
  • Is there a reason that we shouldn't add the website to the blacklist at this time? Replacement first? --Izno (talk) 00:31, 14 June 2019 (UTC)
    (moved from survey section). There are times it is the only archive provider for a given page, it is worth keeping in the toolchest, for now, but make it a last resort and begin the process of moving away where possible. -- GreenC 00:51, 14 June 2019 (UTC)
    • Also, adding to the blacklist can have the effect of making it difficult to edit any article that includes a link to this site. Risker (talk) 21:54, 15 June 2019 (UTC)
  • Comment WebCite has one very important feature: it allows you to request archiving a page, and returns an archive URL. To the extent I know, does not have an on-demand archiving feature (and I'm not sure if any of the other alternatives have this feature either). In light of this, I don't think banning WebCite is a great idea. hujiTALK 18:49, 16 June 2019 (UTC)
    • @Huji: does have an on-demand archiving feature (go to and use the "save page now" option in the bottom right). (AKA also does archiving on demand (from the main page of that site). I'll do them for this page immediately after this comment and add the links in my next edit. Thryduulf (talk) 23:30, 16 June 2019 (UTC)
      • links: Thryduulf (talk) 23:32, 16 June 2019 (UTC)
        • @Thryduulf: sorry, I meant to say that it does not have an "automatable" way of requesting pages. For instance, on fawiki we are currently using the webcitation Python library in this Pywikibot script to archive all links on pages that are being promoted to GA or FA (so that future readers of our "best" articles will have a way to access their references in the future). This cannot be done robotically using because (to my knowledge) it does not have an API for requesting page archives. hujiTALK 23:37, 16 June 2019 (UTC)
          • user:InternetArchiveBot has options that I think might be what you are looking for (submitting live links to the internet archive), Cyberpower678 is the person to ask about that I believe. [1] also seems to suggest APIs are available. Thryduulf (talk) 00:22, 17 June 2019 (UTC)
            Thryduulf, Yes. IABot has authorized access to the advanced SPN2 APIs. Regular users have open access to the SPN APIs. allows for automated archiving of weblinks. Also already does this for all 900 WMF wikis. —CYBERPOWER (Chat) 00:29, 17 June 2019 (UTC)
  • Comment - It seems like the best approach would be to allow use of as many of the archives as possible, no? has its own problems, after all (previously blacklisted, with multiple RfCs ending in its allowed use, preferred by some users while avoided by others, etc.). Wouldn't discrete parameters and redundant archives be the surest bet against linkrot? — Rhododendrites talk \\ 19:41, 16 June 2019 (UTC)
@Rhododendrites: (moved from the survey to discussion section). Yes the RFC proposal says exactly this, you can use WebCite, if you want. But there are good reasons to deprecate. Deprecate does not mean "you must not use" or blacklist, it means archive of last resort and default switch to others when possible. It isn't about picking favorites, I really do wish WebCite were available and reliable. -- GreenC 01:37, 17 June 2019 (UTC)
Aside: not sure why, but this didn't generate a notification for some reason? Yes the RFC proposal says exactly this ?? I said we should allow use of as many archives as possible. This is a proposal to not use a particular archive. Regardless of whether it's a suggestion or a hard rule, all of the reasons are predicated on the idea that we shouldn't use it because others are better. I say we shouldn't have to choose one over another. The best solution is finding a way to take advantage of all of them. WebCite may not be as good as another service, but WebCite and that other service is better than either one. If you see a WebCite citation, supplement it with an and/or; none of these are reasons to replace. — Rhododendrites talk \\ 05:10, 20 June 2019 (UTC)
@Rhododendrites: WebCite is offline. is dead. Maybe they will come back? These extended outages are not new, though I've never seen it go this long. The outages are getting longer, more frequent, the site is not maintained or updated.. no updates or news on Twitter or anywhere about what is happening. Emails to the owner go unanswered (as always). So I'm confused why you said "all of the reasons are predicated on the idea that we shouldn't use it because others are better". Unless by better you mean "not dead". -- GreenC 16:07, 20 June 2019 (UTC)
@Rhododendrites: It seems to me you're making a proposal for a modification of Wikipedia:Citation templates: allow the use of multiple archival parameters, e.g. archive1url, archive1date, archive2url, archive2date, ... The more critical a Wikipedian thinks that the reference is, the stronger his/her motivation to list at least two archived copies of the reference. A maximum number of archives should probably be set - 2 or 3? By default, the second and subsequent archivenurls would be hidden or semi-hidden from the reader; if the archive is long-term dead, then a bot could easily swap between them. A simpler possibility could be to add a dead-archive1url, dead-archive2url, ... parameter, similar to the present dead-url=yes|no. This proposal might let robots add new archive1urls while converting existing Webcite archiveurls to archive2urls with dead-archive2url=yes, rather than deleting the webcite urls. This would be useful for cases where Webcite has a good quality copy (in terms of avoiding javascript rubbish, zillions of external scripts, and so on) but the other archiver doesn't. Boud (talk) 16:28, 22 June 2019 (UTC)


This already exists with {{webarchive}} which supports up to 10 archive URLs and was made for this purpose.
{{cite web |url= |title=Example website |archiveurl= |archivedate=2019-01-01}} {{webarchive |format=addlarchives |url= |date=2019-06-09 |url2= |date2=2019-06-21}}
"Example website". Archived from the original on 2019-01-01. Additional archives: 2019-06-09, 2019-06-21.
To be honest though few people use it, and not many people add archives at all much less worry about redundancy. I wouldn't worry too much about it, bots can replace dead archive URLs with other archive URLs. My bot could fix the WebCite problem in a couple weeks if needed and so can IABot. We have bots for this. The only question is how many of these URLs are unique to WebCite that no other archive provider has, thus are irreplaceable. This is an open question that will be answered once the bots start replacing URLs. -- GreenC 16:57, 22 June 2019 (UTC)
Thanks for sharing this. First time I've seen {{webarchive}}. I think it would be better built into the citation templates, but that the functionality exists is good to know. I do still feel like we (or maybe just I) don't have the sufficient information to write off WebCite for good. Unless we know it's gone forever, if it's the lone archive of a page, a temporary broken link seems preferable to none. If it's not the lone archive, it would be just as easy to supplement it with another archive as it would be to replace it. — Rhododendrites talk \\ 18:05, 23 June 2019 (UTC)
It's nice to know this already exists. I don't expect that I'll be paranoid enough to use it often - it's enough work to add a single archive for each reference. But we'll see: I wasn't paranoid enough to expect webcite to have such a long down time... Boud (talk) 00:56, 24 June 2019 (UTC)

Share your Input on Convergent Community Values about Algorithms on Wikipedia[edit]

We are a group of researchers at the University of Minnesota collaborating with the Wikimedia Foundation to improve ORES, a machine learning-based algorithmic service designed to automate critical wiki-work (e.g. vandalism detection and new page patrolling). Our research team is carrying out a Value-Sensitive Algorithm Design (VSAD) process in order to engage Wikipedia community members and incorporate their tacit values, knowledge, and insights into how ORES should work in the future. You can find the full study description here.

Our team has completed interviews with 16 stakeholders, including five (5) Wikimedia Foundation employees, two (2) external researchers who use ORES in their work on Wikipedia, two (2) volunteer developers who have built ORES-dependent applications, and seven (7) editors with varying degrees of experience on Wikipedia.

Our interview data indicate that there is broad agreement across stakeholder groups about what is most important when it comes to designing machine learning algorithms, and applications that depend on those algorithms. We have derived five major values that should guide future development efforts related to how algorithms ought to operate on Wikipedia. The purpose of this post is to give the broader Wikipedia community a chance to weigh in on our interpretation of the data.

If you are interested in viewing our derivation of these values from our interview data, please view and comment on the current draft of our results here. (We will eventually publish these results in an academic, peer-reviewed venue.) The five “convergent community values” are as follows:

  1. Algorithmic systems should reduce the effort of community maintenance work.
  2. Algorithmic systems should maintain human judgement as the final authority.
  3. Algorithmic systems should support the workflows of individual people with different priorities at different times.
  4. Algorithmic systems should encourage positive engagement with diverse editor groups, such as newcomers, females, and minorities.
  5. Algorithmic systems should establish the trustworthiness of both people and algorithms within the community.

Feel free to share your thoughts here, or leave comments on the google doc draft, or talk us at my or Estelle's talk pages. Thank you for your time and thoughtful consideration!

Bobo.03 (talk) 20:44, 14 June 2019 (UTC)

  • I particularly like your CCVs. I also like the demonstration of what happens when individuals with different views talk to each other. Nosebagbear (talk) 19:50, 15 June 2019 (UTC)
  • I am extremely wary of the use of algorithmic systems in Wikipedia (I have seen too many cases where relying on algorithms resulted in unintended consequences)... so I am very pleased to see the second value listed above. Indeed, I am not sure it goes far enough. Humans can certainly use algorithmic AI as a tool, but we need to keep human judgement in the forefront. Blueboar (talk) 22:31, 15 June 2019 (UTC)
    • Thank you for expressing your wariness Blueboar. Yes, the second value emerged very clearly and repeatedly in our data. When you say it does not "go far enough," I wonder how the expression could "go further" to really capture the essence of what you're getting at? Our WMF employee participants were especially wary of unintended consequences, as you mention. Perhaps we need to highlight that more... FauxNeme (talk) 14:21, 16 June 2019 (UTC)
    • @Nosebagbear: @Blueboar: Yes, we do value having humans especially with different views in the process a lot. One of our current projects is working to develop an interface tool that can visualize algorithm/model tuning for different value trade-offs, e.g., error v.s. fairness, thus individuals with different views (or different stakeholders) can select a model that can address their primary concerns and discuss to make a collective decision about the model to be deployed in the community. Bobo.03 (talk) 14:28, 16 June 2019 (UTC)
  • The document appears to show an impressively high understanding of, and respect for, the needs and values of the community. In particular I believe editors will particularly appreciate the comments of P1 (a staff member), about keeping the balance of power in the hands of the editors using the systems.
    I'd like to note that any efforts at "establishing the trustworthiness of people" is a particularly sensitive area, and any ideas in that area would most particularly require careful consideration by the community. Regarding "diverse editor groups, such as newcomers, females, and minorities": I definitely support the goal itself, however aspiration for that goal often needs to be counterbalanced by critical consideration of proposed means for pursuing that goal. It is an area where I've seen too few positive results and a few too many metaphorical roads to hell paved with good intentions. It can lead to conflict when people let that ideal come into conflict with the ideals of Wikipedia policy. To cite an existing area of tension: Most editors welcome more articles on women and minorities, but most editors also oppose giving such articles a privileged pass in deletion-discussions. Favoring inclusion of obscure (non-notable) biographies is generally not considered an acceptable means of pursuing the goal. Alsee (talk) 11:13, 16 June 2019 (UTC)
    • Hi Alsee, you raise an excellent point. When I make an editing pass on the document after this discussion is over, I will do my best to incorporate your feedback and note the tensions you have pointed out. FauxNeme (talk) 14:21, 16 June 2019 (UTC)
    • @Alsee: Thanks for sharing your thoughts. Would you like to provide more insights about the conflicts of creating more articles on women and minorities. The goal of one of our ongoing projects is to promote gender diversity in Wikipedia contents, by creating a tool to help editors identify articles that are for instance more female related but may be underdeveloped. Does the idea sound appealing to you? Bobo.03 (talk) 14:37, 16 June 2019 (UTC)
      • Bobo.03: Helping editors identify articles of interest to work on shouldn't raise any issues, other than the routine stuff that arises when editing anything.
        Regarding new articles, I don't want to overstate the issue but I have seen some ugly messes crop up. (Ugly cases draw mountains of attention.) I have to cover a few points first, to explain what can go wrong. One of the things that allows us to function in a world filled with controversy is that we have policies and practices that isolate Wikipedia as a neutral non-participant in those issues. Some people think one political party is a noble cause, other people think the opposite political party is a noble cause. There is little tolerance for putting any cause ahead of Wikipedia policies. Wikipedia's job is create an accurate summary of all subjects (and all sides of controversies) that are published out in the world. Wikipedia is not a place to fight those battles. Wikipedia is not a place to try to fix the world's problems. Wikipedia isn't to be used to serve anyone's pet causes. If someone has a cause, our answer is for them to go fix it out in the world and afterwards we will update the encyclopedia to reflect that success. That unyielding approach means Wikipedia is almost equally intolerant of noble-cause crusades and bad-cause crusades. One of Wikipedia's rules is Notability - a topic (or a biography) is only allowed to have a Wikipedia article if there are sufficient sources of an acceptable quality. If someone is on a noble-cause to create lots of women biographies, they're not here motivated to write about a specific famous woman, they're here to dig up a bunch of random women to write about. Notice that the priority there is backwards, the femaleness of the article-subject precedes and takes precedence over how famous or Notable the person is. As long as all the new biographies are clearly notable, there's no issue. When the notability of one of those articles is questioned and a discussion is opened to consider possible deletion, there have been cases where the article-author interpreted that as an attack against the Noble Cause. Anyone seen as attacking the noble cause is, almost by definition, evil. Then there's a risk that someone, usually the article-author, calls in allies for the noble-cause. At this point normal debate about the sourcing and acceptability of the article goes out the window. It can turn into a warzone for the noble cause. People may show up to vote keep just because it's a female biography, disregarding Wikipedia article standards. People who argue the article fails our policy-standards may be accused of sexism (for opposing the noble cause). Good people end up battling against good people. Big ugly drama ensues.
        Back to the main topic, "positive engagement with diverse editor groups, such as newcomers, females, and minorities" is a good goal, but how do you accomplish that? The first obstacle is that On the Internet, nobody knows you're a dog. And beyond that, we haven't had much luck finding simple or easy solutions. We could give biographies on women/minorities privileged immunity to deletion-discussion, but I'm pretty sure most editors are opposed to padding Wikipedia with "junk biographies" to (poorly) serve a cause, no matter how appealing that cause is. Ideas for pursuing this goal likely need some level of community review. There may be policies or ideals that raise non-obvious concerns. Alsee (talk) 21:00, 20 June 2019 (UTC)


Why is there no article yet on Solomon's harem? Reportedly it was a populous place. -ApexUnderground (talk) 01:47, 16 June 2019 (UTC)

See the section entitled “wives and concubines” in the Solomon article. It may be that there are not enough scholarly works written about it to support a full article. Blueboar (talk) 01:56, 16 June 2019 (UTC)
I'd like to see one on Solomon's mines, but I think there's a lack of sources there too, Solomon doesn't mention anything outside pop-cult. Gråbergs Gråa Sång (talk) 22:56, 16 June 2019 (UTC)
see King Solomon's Mines, and In Search of King Solomon's Mines and there are also several articles about the films. eg The Search for King Solomon's Mines. Graeme Bartlett (talk) 11:46, 21 June 2019 (UTC)

Adding "supressredirect" right to File mover[edit]

As a file mover, I find that I often have to request the deletion of redirects made by me moving a file from a meaningless file name to a proper one. It would really be a lot of help to have the ability suppress the creation of redirects when moving files. It wastes both my and the deleting admin's time doing this and I believe that those entrusted with this user right can be trusted not to abuse this power. Obviously, file movers would have to know that they shouldn't use it when moving non-files, but I don't think this will be much of a problem.--Breawycker (talk to me!) 00:07, 17 June 2019 (UTC)

Surely file redirects from meaningless names should not usually be deleted. See wp:FILEREDIRECT. Thincat (talk) 08:10, 17 June 2019 (UTC)
File redirects are generally kept for attribution reasons, especially if the files are likely to have been reused elsewhere. However, most of the files requiring renaming right now shadow Commons, and should be handled with the help of suppressredirect. I'll note that this has been proposed before (1 2 3), including at the time of the introduction of the right. --AntiCompositeNumber (talk) 10:50, 17 June 2019 (UTC)
If you have a sufficient tenure and are regularly running in to this, you can request pagemover access just for this use case, as it already includes that permission. (It is redirectsuppression criteria 5) — xaosflux Talk 12:01, 17 June 2019 (UTC)
Yeah, I just was going to say that - also, Breawycker, WP:G7 does not apply to redirects created by a move (unless you uploaded the file/created the page), so you shouldn't be tagging redirects left behind by a WP:FNC#2 for speedy deletion as WP:G7 (nor should admins be deleting it, but sigh..) Galobtter (pingó mió) 12:59, 17 June 2019 (UTC)
File mover is pretty useless honestly, may as well combine it into the page mover userright Satellizer el Bridget (Talk) 01:06, 19 June 2019 (UTC)

Manual of Style for fictional characters?[edit]

Hello. Back in 2012, we discussed a possible MoS proposal on fictional characters at WP:MOS/VG and Sergecross73 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) and I made a proposal for fictional characters, using the WP:MOSANIME as a reference. A few months ago, I also proposed and withdrew an RFC here. Long story short, one of these suggestions is to propose some sort of manual of style for the fictional characters. I'm planning to open a centralized discussion to see how we can manage a MoS regarding all fictional characters (i.e. Video games, anime, novels, TV series, films, etc.). Thoughts? Lord Sjones23 (talk - contributions) 22:46, 18 June 2019 (UTC)

  • Is this meant to solve some actual problem not already covered by the MoS or some other guideline? Curly "JFC" Turkey 🍁 ¡gobble! 22:58, 18 June 2019 (UTC)
    Yes, there are a lot of disputes related to whether or not fictional characters should have their own article spun out, and there have been for many years now. It aims to give guidance with that. Sergecross73 msg me 23:08, 18 June 2019 (UTC)
    Sergecross73 how is that a MoS issue? MoS doesn't deal with content. Curly "JFC" Turkey 🍁 ¡gobble! 00:28, 19 June 2019 (UTC)
    Look, I don't care where its hosted, or even if my guidance in particular is used. I want there to be a wide-ranging discussion where we can get an enforceable consensus, because the recurring disputes in the area are both a massive time sink and a source of sour feelings among many disagreeing-but-very-good-editors. Sergecross73 msg me 01:00, 19 June 2019 (UTC)
    What are the recurring disputes? Why would having a character MOS be more effective at preventing them than letting the MOS for the various media set their own guidelines? Argento Surfer (talk) 13:10, 19 June 2019 (UTC)
    My two comments above just explained the problem and what I wish to accomplish. I don’t understand why this is so hard to understand. I’ve observed years of disputes and I wish to cut down on them. This is all very bizarre. I’ve never encountered so much skepticism for a desire to solve a problem while having complete openness on changing their stance. I’d get it if I had a controversial stance. But I just want resolution of any kind. Sergecross73 msg me 23:13, 19 June 2019 (UTC)
    I re-read your comments twice, and maybe I'm blind, but I do only see you talking about "recurring disputes" without links or descriptions. Do these disputes have recurring themes? Do they often end with outcomes that conflict with similar, earlier discussions? Without details like that, it's I find it impossible to evaluate the potential impact of your proposal. Argento Surfer (talk) 13:05, 20 June 2019 (UTC)
    • At least to me, yes. Our articles on notable fictional characters particularly in any form of serial work often focuses far too much on primary material. For example Rick Grimes (which actually has a decent "out of universe" set of sections but still has far too long in the tooth on the fictional biography), and I'm sure I can find more with some time. People writing these fictional biographies tend to want to go by breaking it up by each serial element (episode, comic issue, etc.) rather than describe the broad trends. No existing MOS or P&G really says anything against this, barring the lack of secondary sources for notability. Because we tend to allow works of fiction to serve as sourcing for themselves, these articles seem to get away with excessive reliance on primary sourcing.
    • I would then probably add that the focus of these articles should be on the out-of-universe facets more than the in-universe ones. How was the character conceived? How has the character changed over the years? How have they been received in the world of critics? etc.
    • Then another whole thorny issue is when you have multiple iterations/versions of the same character, ala something like Robin (character) especially when it comes to NFC use. That's a whole pickle that we really haven't touched on. --Masem (t) 00:17, 19 June 2019 (UTC)
      • "How have they been received in the world of critics?" Why? This is at best a trivial aspect of the topic and of minimal interest to a reader. I have a few relatives (my sibling, a few cousins, and a niece) who are Wikipedia readers, but not editors. They only read the plot sections and just ignore whatever "critical" opinion is added as indifferent. Dimadick (talk) 16:19, 22 June 2019 (UTC)
        • So, because people misunderstand the purpose of Wikipedia, and misuse it accordingly, we need to accommodate that? Wikipedia isn't supposed to be Cliffs Notes For Pop Fiction. -Jason A. Quest (talk) 16:28, 22 June 2019 (UTC)
  • To clarify, is the text of User:Sjones23/Proposal what is being proposed here? Satellizer el Bridget (Talk) 00:47, 19 June 2019 (UTC)
  • Support at least some set of guidelines. I would estimate that we have tens of thousands of articles on fictional characters, mostly comic book characters. bd2412 T 00:54, 19 June 2019 (UTC)
  • Support I think this is a great idea.Blue Pumpkin Pie (talk) 01:01, 19 June 2019 (UTC)
  • Oppose as instruction creep, until it can be demonstrated this will solve concrete problems our guidelines don't already address, rather than be a collection of pet prescriptions. Curly "JFC" Turkey 🍁 ¡gobble! 01:55, 19 June 2019 (UTC)
  • I think Masem does bring up some good points. I give the example of Sansa Stark, a major character that appears in two different mediums, and with two very different storylines. Right now the article is 75% in-universe retelling of her story by book and by season (all unsourced, naturally) and only then comes the real life coverage of the character. This is excessive reliance on primary sourcing even on a well-known character with a number of reliable sources available. I think WP:PLOT argues that summary descriptions of works should be limited, yet it's not being done in many (most?) character articles. Then there's the whole issue of having hundreds of articles like Griffin Castillo, AJ Chandler, Nick O'Bannon, Nitro (comics), A. J. Chegwidden and Natalie Marlowe that obviously fail MOS:REALWORLD on a whole (as in, there's no independent sourcing on these characters). I think that the rules do exist regarding coverage of fictional elements in wikipedia voice but I'd personally welcome some discussion regarding what we should reasonably expect from an article about a fictional character (development, reception, difference between original work and adaptations, merchandise, casting, etc.). RetiredDuke (talk) 18:23, 19 June 2019 (UTC)
  • I also think this could be expanded to articles that handle more than one character and List articles that handle characters.Blue Pumpkin Pie (talk) 21:42, 19 June 2019 (UTC)
    I would definitely think that we can include "list of characters" as part of a MOS for fictional characters in general. We're not talking notability here (there is no specialized notability for fictional characters, they are expected to meet the GNG), but the biggest issue in both single character and character lists is that the content from primary seem to be around 90% of the article, ideally it should be 50% or lower. Outside of WP:NOT#PLOT, and the little that is in WP:WAF, there is nothing to help with this imbalanced primary/secondary ratio. --Masem (t) 23:20, 19 June 2019 (UTC)
  • Don't support the current wording of User:Sjones23/Proposal, if this is what is proposed, but do support a centralized MoS guideline, as currently TV has Wikipedia:Manual of Style/Television#Character article structure, WikiProject Fictional characters has Wikipedia:WikiProject Fictional characters/Style guide, Video games have Wikipedia:Manual of Style/Video games#For characters, comics have Wikipedia:Manual of Style/Comics#Characters 2 and there are probably others. This needless fork of guideline has in certain situation also conflicting style guides. --Gonnym (talk) 00:07, 20 June 2019 (UTC)
    I plan to merge all of the guidelines there into a single MoS guideline. Lord Sjones23 (talk - contributions) 05:57, 21 June 2019 (UTC)
  • Oppose per WP:CREEP. I just had a look through the FAs of this sort. To start at the top, consider the vexed question of infoboxes. Should fictional characters have an infobox like Jabba the Hutt or not, like Tom Swift? There's no practical consensus on this, is there? Andrew D. (talk) 09:04, 20 June 2019 (UTC)
  • Oppose as instruction creep, the question of standalone notability for a fictional character should be determined by WP:GNG on a case by case basis, while the MOS is not the right area for such decisions, thanks Atlantic306 (talk) 11:54, 20 June 2019 (UTC)
  • Oppose per User:Atlantic306 and User:Andrew Davidson's rationale. Would've supported per WP:NOTCREEP however the matter seems a lot more complicated and integrated into wikipedia. Consensus would seem very mixed on the matter too so, echoing Atlantic306 I'm going to emphasize his/her argument that "Standalone notability ... should be determined by WP:GNG on a case by case basis."
  • Oppose I made an essay in 2016, which is linked as WP:A&M/CHARACTER based on common layouts found on GA and FA anime and manga related character articles. This being said, we already have so many projects doing their own thing here. In theory its a good idea, but implementing it across Wikipedia is another matter. - Knowledgekid87 (talk) 15:57, 20 June 2019 (UTC)
  • As seen by what Gonnym pointed to, we already have style guides for fictional characters. And we have Wikipedia:Manual of Style/Writing about fiction. Flyer22 Reborn (talk) 05:12, 21 June 2019 (UTC)
    • That doesn't solve a lot of problems with fictional characters. In recent months I've seen various problems for which there have been no specific answers, even for simple things like how you should write the chaacter's name in the lead sentence. A common thing that I see is editors not being able to separate fiction and reality. They like to add birth dates, often based on OR, or claim citizenship for particular characters based on how it applies to the real world. When you try to refer to WP:WAF or other guidelines to resolve the problem, there is no guidance in the area. We really do need something specifically for fictional characters. --AussieLegend () 06:22, 21 June 2019 (UTC)
      • So which MOS or essay do you propose we go by? We have an MOS mention for comic book characters, an MOS mention and essay for anime characters, a style guide for fictional characters, an MOS mention for television characters, and an MOS about writing about fiction. - Knowledgekid87 (talk) 15:23, 21 June 2019 (UTC)
        • I would start by looking at what you've mentioned and improve those if necessary. Then, look at what is common to all and create a MOS based on that. --AussieLegend () 08:31, 22 June 2019 (UTC)
  • SMcCandlish and I have previously discussed a centralized MOSWORKS (see also Talk:Virtual Pool 3). It would be a massive undertaking. I'd be willing to work with other editors to consolidate our guidance on works, fictional and otherwise, of which the characterization is a part. That said, I would reject the 2012 Sjones page out of hand. --Izno (talk) 16:26, 22 June 2019 (UTC)

RfC: Ending the system of portals take 2[edit]

Should the system of portals be ended? This would include the deletion of all portal pages and the removal of the portal namespace. This of course does not include our main page or other portal style pages as they are not in the portal namespace.....with the current event portal being moved--Moxy 🍁 03:41, 19 June 2019 (UTC)

Rationale discussion[edit]

It's clear that the portal space is no longer support by the community. Since the last rfc to retain portals and desire to try improve what we had...and then mass creation of automated portals; we have had 4000 plus portals deleted in the past 6 months with very little opposition and participation in those talks. Many portals have been deleted with just a few votes with most having zero improve attempts. At this point with only 900 or so left we should consider the fact it's over. What do others think? Should we just keep deleting one by one or does the community except that it's a failed experiment and our resources can be better used.--Moxy 🍁 03:35, 19 June 2019 (UTC)

Regarding "with just a few votes" - When I look at any xFD if the nom makes a good case and all the !votes are to delete (even if there are only one or two of them) then I don't usually bother to !vote. Many other editors may do similar. DexDor (talk) 05:25, 19 June 2019 (UTC)
The vast majority of editors do not go to, or even know about, xFD, so removing things via that route probably doesn't give an accurate picture of true feelings of the community. Randy Kryn (talk) 13:19, 19 June 2019 (UTC)
The vast majority of editors do not go to, or even know about, any type of Wikipedia discussion. ―Mandruss  14:41, 19 June 2019 (UTC)
Those at the isolated deletion board don't care about the last Rfc and they have littld interest in updating any or even giving the community a chance to fix them. If there is any desire to retain portals we will need content editors to step up and update the portals. As of now portals are being deleted bases on views or the fact a topic like the military of the United States is considered not a broad topic. If no one is will to help there is no point in having they will all be gone soon anyways. I voted last time to end portals...but now find myself trying to explain that back door deletion is not what the community intent was in the last Rfc. I still think they should be deleted overall...but am not a fan of the non policy bases they are being bandwagon deleted.--Moxy 🍁 19:09, 19 June 2019 (UTC)\
Well, I have occasionally looked at some portals since the last RfC and they looked fine. It's rather a mystery why some people would want to trash every portal that might interest others and the last RfC suggests rational people do not. It's fine to trim, but 900 is just not that many pages and neither is 4000. Alanscottwalker (talk) 19:51, 19 June 2019 (UTC)
  • I think this proposal is too rash and misses a lot of points that would help build consensus. Given the lack of consensus in the previous RfC, the next step is not to propose all or even most portals be deleted. The recent mass portal deletions were in response to what was as much a conduct dispute as a content dispute. The XfD discussions were largely because a proposal for a new speedy deletion criterion applying to all portals created by a single user failed to gain consensus. Pointing to those to say that there is consensus to delete all portals is not a good example. The AN discussion has over 10 proposals on how to handle portals, some of which, like proposals 7 and 13, seem like they might actually find consensus.
If anything, the problems pointed out regarding the upgrades to portal maintenance can at best show that we should not create any more portals as they are likely to wind up unmaintained and just as complex as before. I think a proposal to mark WP:PORTAL historical but maintain what we have for the time being is far more likely to gain consensus than deleting portals en masse. Lots of people believe there are portals which still have value and are actively maintained and so blanket deletion is not going to find consensus because of that.
I fear that this discussion is only going to harm consensus building by making people more entrenched in their positions. It's unlikely to pass and those who support portals will be more likely to view further good faith attempts at consensus building as attempts to delete all portals. I suggest this be withdrawn or closed in favor of a more nuanced proposal. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 21:25, 26 June 2019 (UTC)

Voting discussion[edit]

  • Oppose: I think we should keep portals, because they're useful for organization, navigation, and bridging between reading and project space. Benjamin (talk) 06:36, 19 June 2019 (UTC)
  • WP:ENDPORTALS: Electric Boogaloo? Moxy, I would suggest pausing this a bit to work on the wording of the RfC, at least. The last RfC got muddled up with Wikipedia:Community_portal and Portal:Current_events (with the intention being that the current events portal would be moved to Wikipedia space), and with some opposition to full deletion (with preferrence a slower process than Nuking the whole space). So I would suggest some rephrasing of the RfC question or changes to the format to allow a consensus for a less dramatic step. Galobtter (pingó mió) 12:32, 19 June 2019 (UTC)
    Done I guess we should make it as clear as possible.--Moxy 🍁 19:30, 19 June 2019 (UTC)
  • Oppose, this was fully discussed in the last well-attended and novel-length RfC. Some editors have worked diligently on the collection since then. Randy Kryn (talk) 13:13, 19 June 2019 (UTC)
  • Not now per Galobtter. I think you're right that recent developments might have changed consensus. I agree with the spirit of the proposal, but per the last RFC, Community portal and Current Events are going to be stumbling blocks to consensus unless there's an explicit plan to deal with them from the beginning. I think you should withdraw this and consider a better compromise than deleting portals which I don't think will find consensus. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 14:41, 19 June 2019 (UTC)
    Note: Wikipedia:Community portal probably isn't relevant - it isn't in portal namespace, isn't a WP:Portal and was only mentioned once in the previous RFC. DexDor (talk) 18:15, 19 June 2019 (UTC)
    Have amended wording for those not familiar with topic portals.--Moxy 🍁 19:30, 19 June 2019 (UTC)
  • Oppose The major portals still appear on the main page and that's not a problem. People bickering about lesser portals is typical disruption per WP:LIGHTBULB. Tsk. Andrew D. (talk) 22:36, 19 June 2019 (UTC)
  • Oppose I have been appalled by the tone of the discussions at MFD but I simply haven't have the inclination to take part. All the same, I think portals should continue. Thincat (talk) 08:03, 20 June 2019 (UTC)
  • Strong Oppose - We already had a lengthy discussion on the matter that has its own subpage saying there is a "strong consensus" to retain the portals, no need to beat a WP:DEADHORSE. - Knowledgekid87 (talk) 16:02, 20 June 2019 (UTC)
  • Oppose That there was consensus to delete some portals does not imply consensus to delete all portals. Articles are deleted every day at AfD but this does not imply a consensus to delete the article space. Hawkeye7 (discuss) 19:46, 20 June 2019 (UTC)
    Going by the reasons for deletion that I see most days I think that there are some editors here who would like to make this place neat and tidy by deleting the whole of article space, so they would be able to argue about things without having that messy encyclopedia to worry about. Phil Bridger (talk) 20:38, 20 June 2019 (UTC)
    This just goes against WP:IMPERFECT (which is a policy), no amount of deletion cleanup will ever be enough to please everyone. Things that hinder editing I can understand, but to go after things just to go after them is wrong in my opinion. - Knowledgekid87 (talk) 15:16, 21 June 2019 (UTC)
  • Oppose I'm against deleting high level portals such a those on the main page and Portal:Contents, plus any others which don't duplicate article content such as Portal:Current events and Portal:Featured content. I would be happy to consider proposals to drastically reduce the number of portals but not get rid of them entirely. Hut 8.5 12:53, 22 June 2019 (UTC)
    My guess is this is the plan...deleted all but main portals..--Moxy 🍁 12:00, 24 June 2019 (UTC)
  • Strong support. I feel that portals are long obsolete and that their removal is inevitable and would benefit Wikipedia. Also, in response to those who note that we have had a discussion on it before, I remind you that that was over a year ago and that consensus can change. Having said all that, I get the feeling that consensus does not currently support the eradication of the namespace, so I will support the form of consensus that is closest to it (such as removing all but the main-page portals, etc.). EDIT: After thinking it over for a little bit I realize that I've been a bit overly harsh on portals. I still see no use for them personally, and would not oppose deleting all but the main-page and non-article-duplicating portals, but those who really want to maintain the portalspace should be able to do so provided that they don't spam with cruft and, most importantly, help the encyclopedia. – John M Wolfson (talkcontribs) 18:02, 26 June 2019 (UTC)
  • Strong oppose. Look, there are a lot of useless portals. If that makes the whole system useless to you, fine, ignore them. If you think it could be useful but it isn't because of the cruft, then decide whether it's worth your time to help clean it up. If it is, then do it. If it isn't, see sentence 2.
    The "resources" argument is fundamentally misbegotten. There is no common pool of resources that we draw on. There are volunteer contributors, who allocate their resources as suits them. --Trovatore (talk) 19:51, 26 June 2019 (UTC)
Would be nice but efforts to improve are just just a few editors voting rrsulting in deletion of thousnads of portals.--Moxy 🍁 21:41, 26 June 2019 (UTC)
  • Oppose Portals are useful.--Vulphere 05:48, 27 June 2019 (UTC)

Infobox style[edit]

Is there a particular reason why various infoboxes use different words to portray when the thing in question was founded? For example, Infobox university uses "established", Infobox organization uses "formation" and Infobox company uses "founded". For consistency, wouldn't it be better to agree on a common term and use it across all infoboxes. Perhaps "founded"? Morris Schaffer (talk) 18:19, 19 June 2019 (UTC)

The terms aren't synonymous. To found is to originate, create, initiate (something which continues to exist thenceforward); to establish is To set up on a secure or permanent basis; to form is To give form or shape to (all three from OED). A university is intended to last forever; a company is intended to last until it goes bankrupt or is absorbed by another company; an organisation isn't necessarily intended to be permanent, as they often have a specific objective and are dissolved once that objective is met or becomes unattainable. ‑ Iridescent 20:02, 19 June 2019 (UTC)

running a bot to upload pdf versions of Wikipedia books to Wikipedia[edit]


since there is currently now way to download PDF versions of books from the Book: namespace and there are currently no plans to implement such a feature I propose that I run a bot to create such PDF versions and upload them to Wikipedias File: namespace. This way users can directly downloaded them from the pages in the Book: namespace. I expect to update each of them once in 200 days.

The following examples show how PDFs will look like:

This proposal was started in idea lab on 19 May 2019:


Dirk Hünniger (talk) 21:25, 19 June 2019 (UTC)

Category:Wikipedia books (community books) shows about 6,700 books is that how many would be added to File: space? -- GreenC 16:32, 20 June 2019 (UTC)
My goal is to add all of them. Still there might be some unforeseen effects. So I expect something like 90 % within the first two years to be quite realistic. I currently expect a disk usage of around 300 GBytes in total. Dirk Hünniger (talk) 16:47, 20 June 2019 (UTC)
Thanks. Seems like a reasonable idea. My only thought was Commons but since this is specific to Enwiki makes sense to organize files locally. -- GreenC 17:23, 20 June 2019 (UTC)
Question... I am unclear as to the purpose of the bot... How do you envision our editors using it in an article? Blueboar (talk) 17:15, 20 June 2019 (UTC)
It's not a user run bot. It creates PDF files of Wiki Books and uploads them to File: space. It's so end-users can access Wiki Books in PDF format. -- GreenC 17:23, 20 June 2019 (UTC)
Ok... but why do our editors need to access Wikibooks in PDF format? Do you see it helping with citations or something?
I get that you want to use Wikipedia as a host for these PDF files, but I’m not sure if that is our function. I don’t see how hosting these PDFs benefits Wikipedia and our function as an encyclopedia. Blueboar (talk) 17:35, 20 June 2019 (UTC)
FYI it's not my proposal ("you want to"). We already hosts these books in the Book: namespace. There is consensus for this content to be hosted on Wikipedia. I don't see a problem making it available in PDF format. -- GreenC 17:58, 20 June 2019 (UTC)
The value of these PDFs is that they reflect the current version of the articles. Having fixed PDFs would be rather pointless. Headbomb {t · c · p · b} 18:25, 20 June 2019 (UTC)
The PDF are going to be updated regularly. The update frequency is a question of computational resources, and thus money. The advantage is that the PDFs can be downloaded in seconds even for large books containing hundreds of articles, while the PDF generation might take hours in such cases. I am planning to add a link to the PDF file of each book on the page of the book in the booknamespace. So there is nothing changed in the experience of our editors. Its just going to change the experience of end users who are in need of getting a full copy of book in the book namespace. The on demand rendering is already available here: Dirk Hünniger (talk) 18:49, 20 June 2019 (UTC)
How do you plan to license these? Specifically, are you going to include all authors in the book? Are you going to exclude fair-use images? — xaosflux Talk 17:41, 20 June 2019 (UTC)
Yes as you seen the PDF I provided as examples above there is a list of figures and a list of contributors at the end of each PDF file. The files will be licensed under the same license as Wikipedia itself. Currently fair use images are included, but it is easy to exclude them in case there a consensus decision to do so.Dirk Hünniger (talk) 18:49, 20 June 2019 (UTC)
@Dirk Hünniger: I don't normally follow third party file hosting links, you could put your example here for better accessibility. — xaosflux Talk 18:51, 20 June 2019 (UTC)
Hi, its a bit of funny since I think I am not supposed to upload such a file to Wikipedia and I am just requesting to upload such a file in this very discussion. So a very nice case of recursion. But fortunately someone else has already done so, although its just a single article: File:Ion Keith-Falconer from German Wikipedia converted with MediaWiki2LaTeX.pdf
Thanks, so assuming these are not going to try to include fair-use images - wouldn't you just put these on commons? — xaosflux Talk 19:06, 20 June 2019 (UTC)
Well for now, I include fair use images. And as long as there is no consensus decision to exclude them I am going to keep the included. And this why I am currently proposing to upload on the English Wikipeda.Dirk Hünniger (talk) 19:10, 20 June 2019 (UTC)

Proposal concerning padlocks[edit]

This is based partly on my own experience, but regardless I think it has merit. When a registered and qualified Wikipedian logs in to a semi-protected article, or any other relevant protected article, for that matter, I would like to see the padlock/s automatically disappear. That would make it clearer, (especially for newbies) in my opinion. Obviously, it would not apply to registered and unqualified or unregistered users. Editrite! (talk) 02:26, 22 June 2019 (UTC)

Let's say a suitably-privileged user adds a padlock to a protected page. How would they test that the padlock was actually being displayed? --Redrose64 🌹 (talk) 20:00, 22 June 2019 (UTC)
Should be doable via gadgets/scripts or something, but it's not something that should be on by default. Headbomb {t · c · p · b} 21:01, 22 June 2019 (UTC)
But an editor can already find out whether they can edit a page by the state of the Edit button (for example whether it says "Edit" or "View source"). However, if an editor wants to find out whether a page is protected, how are they going to do that if the padlocks are invisible to them? – Uanfala (talk) 22:24, 22 June 2019 (UTC)
In answer to both Redrose64 and Uanfala, the padlock/s ONLY disappear when you LOG IN, so in other words, when you log out they will automatically reappear, or alternatively they will appear BEFORE you log in, as if you were unregistered. It's true that there is an Edit button but here's the thing. When I registered and qualified as an editor, because the padlock was still displayed on protected articles after logging in, I mistakenly assumed that meant I was still not allowed to edit. Hence my proposal to avoid ambiguity. I doubt that I was the first, or will be the last to experience this situation while the padlock remains all the time. Editrite! (talk) 05:11, 23 June 2019 (UTC)
If a page is protected, a padlock icon can only be added by a person who has the matching (or higher) editing right, and logged out users have none of these rights. Imagine that somebody locates a page that is protected because of vandalism, but has no padlock. They log in (if not logged in already) and add a template like {{pp-vand}} to the page. But nothing then displays, because you (Editrite!) don't want that person to see anything. They then think that they made an incorrect edit, and remove it again. Nothing is solved. --Redrose64 🌹 (talk) 13:54, 23 June 2019 (UTC)
I honestly wouldn't put this as a high priority for implementation or even discussion. But we could display a locked padlock for users that do not have the required rights, and an open padlock for users that have. And no padlock for unlocked pages... --Stephan Schulz (talk) 14:17, 23 June 2019 (UTC)
1. Mouseover the padlock and it explains that the article is protected. It doesn't say that the article is protected from you. Use information resources that people have gone to some effort to provide you, and you will be less likely to "mistakenly assume". 2. In real life, padlocks don't disappear for those who have a key. 3. We generally require a demonstrated cost-benefit case, which means evidence that a proposed change would save editors enough time or mental energy to justify the cost of the change. We don't mistakenly assume that all editors are like us. ―Mandruss  14:48, 23 June 2019 (UTC)
I wouldn't put any priority on this except as an opt-in user script. The padlocks are to convey information about the protection levels of the article. I'm a template-editor, but knowing if a template is unprotected, semi- or template-protected is still useful because it lets me know who else can or can't edit the template. Same for articles. Headbomb {t · c · p · b} 16:38, 23 June 2019 (UTC)

Some of the comments that I have received here are bizarre, to say the least, for example comparing online with "real life". Are you serious? They show that you didn't read, understand or even worse still, distorted what I said. The only issue here, if there is an issue is cost. The software gurus shouldn't have any trouble coming up with an answer quickly, but in the unlikely event that they can't and it's not viable, (Wikipedia being a non-profit organisation) then obviously it's not a proposition. No system is perfect. The subject of vandalism is always a problem, and no matter what you do, you can only minimise it not eliminate it. As for the assertion that it's only for my benefit, or "assume that all editors are like us", nothing could be further from the truth, and I've made that clear. If you can't or won't see the bigger picture, then I can't help that. Just to be clear, what I am proposing is that ONLY while you are logged in to a semi-protected or protected article, as a registered and qualified user, will the padlock not appear i.e. it's only temporary. When you are not logged in, or you have logged out it will appear as normal, so it's easy to tell if it's protected or not. Editrite! (talk) 06:04, 24 June 2019 (UTC)

Calm down. People understand what you're proposing but disagree that it's a good idea. The fact that a page is protected is important information. For example our protection policy states that "Protected pages may not be edited except to make changes that are uncontroversial or for which there is clear consensus" so as an admin I need to know if a page is protected before I try to edit it.
Nonetheless, if you insist this feature is useful to you it can be done with a single line of javascript added to your common.js file:
if ( mw.config.get('wgIsProbablyEditable') ) { $('[id^=mw-indicator-pp]').hide(); }
the wub "?!" 13:19, 24 June 2019 (UTC)

@thewub Thanks for your input. There seems to be a perception that my proposal is for purely selfish reasons, but that's not how I operate (it would have been useful as a newbie to avoid confusion which was the point I was making, but not now). I'm more interested in constructive suggestions that benefit others. Nevertheless, I am willing to accept your interpretation that the handful of contributors here do not agree with my proposal at this time, and leave it at that. It's a pity . . . but that's life. Editrite! (talk) 22:56, 25 June 2019 (UTC)

FPC needing feedback[edit]

Hi all! I proposed an image on WP:FPC and it didn't reach the quorum for one vote. For days it was on "FPC needing feedback" yet it didn't work. Any idea?, shouldn't FPC needing feedback receive a further time to reach consensus? Thanks! --LLcentury (talk) 15:08, 23 June 2019 (UTC)

@LLcentury: You seem to have nominated a number of images at WP:FPC. Which one are we talking about? --Redrose64 🌹 (talk) 15:31, 23 June 2019 (UTC)
@Redrose64:, sorry for not being clear Wikipedia:Featured_picture_candidates/Byun_Yo-han. --LLcentury (talk) 15:33, 23 June 2019 (UTC)
This was closed by Armbrust (talk · contribs). Have you asked them why they reached that decision? In any case, I don't see why this is a WP:VPR matter: are you proposing a new process that would be different from the processes that already exist? --Redrose64 🌹 (talk) 15:59, 23 June 2019 (UTC)
The nomination failed because it didn't reach the necessary quorum (5 supports) during the voting period (10 days). As an image can be renominated at any time, I don't think expanding the voting period is needed. Armbrust The Homunculus

No no just a proposal to expand the time of those pictures needing feedback. Sorry my English is not expansive. --LLcentury (talk) 16:00, 23 June 2019 (UTC)

Display A class as a top icon[edit]

Withdrawn as A class may or may not be better than a GA depending on each project's handling. NoahTalk 12:27, 26 June 2019 (UTC)
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.

Currently, we only display two article qualities as top icons... GA and FA. I propose we change this and show A-class as well. My reason behind this is that A-class articles are inherently better than a GA. A-class basically approaches FA but falls just short. Considering A-class has multiple reviews that are likely more thorough than what it received at GAN (if it went through the process), I see no reason why we shouldn't display a top icon on A-class articles. NoahTalk 16:06, 24 June 2019 (UTC)

"Inherently better" Not really. A-class is not required to be reviewed by the community and is not generally required to have more than one reviewer. Maybe this is something to discuss on WP:VPI instead, but I do not think it will be likely to be accepted by the community. --Izno (talk) 17:36, 24 June 2019 (UTC)
@Izno: Well... maybe we need to discuss implementing a hard process for A-class articles. According to the current A-class criteria, it must be reviewed by at least 2 impartial reviewers. Would it be okay to just move this whole section over to the idea lab then? NoahTalk 17:49, 24 June 2019 (UTC)
Hurricane Noah, Some WikiProjects already have one, such as Wikipedia:WikiProject_Military_history/Assessment#ACR. Adam9007 (talk) 19:06, 24 June 2019 (UTC)
@Izno: A-Class is inherently better, at least in the sense that it's a higher grading than GA. It makes little sense to skip a grade with top icons. – Finnusertop (talkcontribs) 11:42, 25 June 2019 (UTC)
Uh, no. A and GA are strictly unrelated. One is a WikiProject grading and one is a Wikipedia grading, and the requirements for each differ accordingly. --Izno (talk) 13:47, 25 June 2019 (UTC)
Izno, Then the grading table needs changing. Anyone reading it would think that A-class is a step above GA. Adam9007 (talk) 00:37, 26 June 2019 (UTC)

─────────────────────────@Adam9007 and Izno: If you even look at the main content assessment page, an article is not complete until it reaches A-CLASS... GAs may have weak areas according to one of the description boxes while an A-class is a nearly complete rendering that will leave non-experts wanting no more. Therefore a GA is an incomplete article, while an A-class article is. That means that A-class is above GA. NoahTalk 01:09, 26 June 2019 (UTC)

  • Support Per nom. For the few WikiProjects that actually do A-class, it's listed a grade above GA and has a higher standard and articles go through more scrutiny. It thus makes no sense to display a badge of honour for GAs but not for A-class articles. The only problem with this is that an article can be part of a WikiProject that does A-class and another WikiProject that doesn't. Perhaps being A-class one of the applicable WikiProjects would be enough to display the badge? Adam9007 (talk) 18:57, 24 June 2019 (UTC)
  • Support. Our current practice of skipping a grade with top icons makes little sense. A-Class is definitely a badge of honor, not shame, as the process is quite rigorous and results in quality content. – Finnusertop (talkcontribs) 11:48, 25 June 2019 (UTC)
  • If we want to use bold, oppose. Supporters are under some misapprehension about how these rankings interrelate. If they personally are interested in knowing what the class is without visiting the talk page, there's a gadget for that. --Izno (talk) 13:48, 25 June 2019 (UTC)
    Izno, By that logic, we should do away with having GA and FA top icons. I can't see that ever happening... Adam9007 (talk) 23:38, 25 June 2019 (UTC)
    I have corrected the misapprehensions above. If you are interested in responding to what those misapprehensions might be, above is the correct place so that we don't split the discussion. --Izno (talk) 00:25, 26 June 2019 (UTC)
  • Oppose. A may be placed between GA and FA in the table at WP:ASSESS, but I don't see them forming a strict hierarchy. For example, if you look at the criteria at WP:ACLASS, you'll find that they're not a superset of WP:GACR. Also, A/B/C grades are assigned by Wikiprojects. How they determine those grades is basically up to the individual Wikiproject. GA/FA are determined by independent editors following a very well-defined process (they also have well-defined processes for reviewing/revoking the status after it's been given). Also, even if you could fix the A criteria/processes such that they were clearly comparable to GA/FA: I don't see the need for another level of granularity. The difference between GA and FA is not huge. And for a casual reader, grokking the difference between GA and FA is probably already confusing enough. Colin M (talk) 23:31, 25 June 2019 (UTC)
@Colin M: If the difference isn't that great, why don't we just abolish A class entirely? Why not abolish B class while we are at it since there isn't much difference between it and GA? If you read the difference between GA and A, you will see there is a decent gap there. A GA may still be incomplete and lacking in areas while an A-class is required to be a nearly complete treatment of the subject. There are some GAs that are absolutely horrible and would warrant a withdraw if submitted for a FAC. The wikiprojects that actually do A-class reviews (makes up at least a majority of the current A-class articles) do a pretty good job at it. I'm pretty sure quite a few projects review according to FA standards as well. To say A-class is worthless and there isn't much of a difference just means you haven't gotten a lot of experience with those processes under your belt yet. I have gone through the GAN process several times and have two incumbent FAs. Trust me when I say there is quite a large difference. NoahTalk 00:50, 26 June 2019 (UTC)
  • While I might be misunderstanding something, from what I understand A-Classes are assessed by WikiProject and thus subject to local whims, so what may constitute A-class in one WikiProject may not be so for another. This is in contrast to FACs, which are assessed by a project-wide panel, and GANs, which have universal criteria. While I won't adamantly oppose this proposal I am skeptical of it, especially if one WikiProject assesses it as A-class but other relevant WikiProjects either don't have such a mechanism or view it only as a GA or even lower. (I've also never quite grasped the concept of A-class in general; from what I understand it's something in between GA and FA, but I've never really gotten how that works or what the criteria are as opposed to either respective grade. That is irrelevant here, though.) – John M Wolfson (talkcontribs) 06:31, 26 June 2019 (UTC)
@John M Wolfson: A discussion needs to take place for either the refinement or abolishment of A-class based on arguments above. I am archiving this as it is clear said discussion needs to take place before this. NoahTalk 12:26, 26 June 2019 (UTC)

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.

Proposal for a policy to speedily move advert/COI pages to draft[edit]

We have over 18,000 pages tagged as {{advert}}, and nearly 13,000 tagged as {{COI}}. Some of these are actually in reasonably good shape, but need to be slightly more balanced and have some puffery removed, while others are barely more than a resume or a page of promotional jargon. In the middle ground, there are a substantial number of pages that are for individuals and entities that are probably notable, and which are not fit for speedy deletion under CSD:G11 as unambiguous advertising or promotion, but which also are not in a shape to properly serve our readers. As an administrator, I probably deal with more of those than the average editor. I would like to be able to speedily move pages that are farther towards the bad end to draft space. I propose the adoption of a policy structure along the lines of CSD:G11, but directed at articles that are theoretically fixable, but predominated by advertising, promotion, or clear COI content to the point that they require substantial revision to be a useful and credible part of the encyclopedia. bd2412 T 00:50, 27 June 2019 (UTC)

I agree with this concept. In borderline cases where there is some genuine encyclopedic content, it is better to preserve it as a draft than to delete it outright. Any good faith editor can do cleanup work and then move the draft back to main space. Cullen328 Let's discuss it 04:16, 27 June 2019 (UTC)
I would support this in principle. My main concern is in borderline-borderline cases where there are roughly equal amounts of promotion and content, but I think such concerns could be ameliorated and are not fatal to the idea. – John M Wolfson (talkcontribs) 05:27, 27 June 2019 (UTC)