Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Xeno (talk | contribs) at 13:02, 13 June 2019 (→‎Allow bureaucrats to quickly re-sysop admins temporarily de-sysoped by WMF for carrying out out community consensus: closing with a pointer to workshop further at WT:ADMIN). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New proposals are discussed here. Before submitting:


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

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)[reply]

Proposal

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)

  • Support as proposer. Thanks. Mike Peel (talk) 18:09, 4 May 2019 (UTC)[reply]
  • 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)[reply]
    @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)[reply]
    @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)[reply]
  • 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)[reply]
  • Support with the general expectation that only the matching values are removed. --Izno (talk) 11:38, 6 May 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support - the Commonscat template should be kept available for non-standard situations. --Robby (talk) 21:22, 6 May 2019 (UTC)[reply]
  • Support this as a sensible next step — Martin (MSGJ · talk) 21:46, 6 May 2019 (UTC)[reply]
  • 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)[reply]
  • Support I don't see any issues. Go on. Sincerely, Masum Reza☎ 04:40, 7 May 2019 (UTC)[reply]
  • Support seems like a smart move -- reduces clutter in the markup, Sadads (talk) 18:13, 7 May 2019 (UTC)[reply]
  • Oppose Per Kerry's extremely well written and reasoned comments above. Beeblebrox (talk) 20:23, 7 May 2019 (UTC)[reply]
  • 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)[reply]
Wikimedia Commons has media related to Something.
  • 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)[reply]
    @Nyttend: You may want to reread the proposal. The box would stay in either case. ARR8 (talk) 00:28, 8 May 2019 (UTC)[reply]
  • Support per nomination. ARR8 (talk) 00:28, 8 May 2019 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support As reduces issues when categories are renamed. -- WOSlinker (talk) 07:50, 9 May 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support. Vulphere 12:26, 11 May 2019 (UTC)[reply]
  • 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)[reply]
  • 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
    PAGE    ) 21:57, 15 May 2019 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Late oppose per Kerry & Keith D. Happy days, LindsayHello 11:24, 31 May 2019 (UTC)[reply]
  • 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 en.wiki 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)[reply]

Discussion (Commons category links)

  • 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)[reply]
    @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)[reply]
  • @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)[reply]
  • 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)[reply]
    @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)[reply]
    I see, thanks. Blue Rasberry (talk) 19:43, 8 May 2019 (UTC)[reply]
  • 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)[reply]
  • @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)[reply]
    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)[reply]
    @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)[reply]
    @Kerry Raymond:, well, at first Wikidata was used by everyone but en.wiki 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)[reply]
    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)[reply]
    I know what you mean, @Kerry Raymond: but Commons is everyday less and less dependent on en.wiki 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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
Oh, I see, Mike Peel has already made above the same point.--Ymblanter (talk) 15:02, 11 May 2019 (UTC)[reply]
@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)[reply]
  • 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).[reply]
  • @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)[reply]
    • But could the WD entry be manually overwritten, thus allowing a vandal to play havoc? - Sitush (talk) 06:39, 18 May 2019 (UTC)[reply]
      • @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)[reply]

Expanding InternetArchiveBot to handle book references

Since May 2015, User:InternetArchiveBot, aka IABot, has been continuously working to restore dead URLs by relinking them to archive snapshots. While IABot primarily links to Wayback Machine URLs, it’s able to handle over 20 different archive services. To date more than 10 million “broken” links have been repaired. This has helped a great deal to enforcing and maintaining WP:VERIFIABILITY.

Today, I am proposing a new feature of IABot to add links to referenced books from Archive.org. IABot will search for books referenced in enwiki articles and link to any it finds available at archive.org. Book references containing page numbers will link straight to those pages allowing editors and readers to more easily verify the contents of an article referencing the book. Here is an example of such an edit IABot would be making to an article.

An example of the benefit of this proposal can be seen on this article: Martin Luther King Jr. where pages from 54 referenced books are now just a click away from readers. For example Citation #1. As can be seen, any book reference with page numbers will make the title and the page numbers link straight to the desired page of the referenced book. References that have the title wiki-linked elsewhere will only have the page numbers linked.—CYBERPOWER (Chat) 17:45, 17 May 2019 (UTC)[reply]

Support

  • Support, provided that Archive.org's books are available everywhere. It'd be a more universal version of Google Books, although I wonder whether/how it would work for "short form" references. (e.g., given a book "Book" by John Doe, with an entry in a Bibliography but with inline citations of the form "Doe p. 54", would the bot work just on the Bibliography, on each short-form reference, or both/neither?) – John M Wolfson (talk • contribs) 18:06, 17 May 2019 (UTC)[reply]
    John M Wolfson, I just came upon a case with the shortened inline citations, and I don't see a reason why it needs to be supported. Reference 80 for example on https://en.wikipedia.org/wiki/Easter_Island#References reference "Diamond 2005, p. 109". When I hover over the author name, a tooltip pops up displaying the bibliography. I have both The Archive browser extension and The Archive wikipedia gadget installed, which were used to prototype this idea of referencing books with IA. Both of these tools are displaying links to the archive in the tooltip that popped up by hovering over "Diamond 2005". I am not sure if this will also work with IABot, but I think that it's likely considering it works already for 2 other tools that were used to prototype this feature of IABot. Reinischmax (talk) 19:59, 22 May 2019 (UTC)[reply]
    Reinischmax, that's probably because Template:Sfn is used in the refs, which is not always the case with shortened footnotes. I agree that Sfn should pre-empt any IABot activity with the shortened footnotes. – John M Wolfson (talk • contribs) 20:16, 22 May 2019 (UTC)[reply]
  • Support. Vulphere 10:07, 19 May 2019 (UTC)[reply]
  • Support. The Internet Archive is a top-notch, efficient, highly helpful, diligent nonprofit and this proposal would make our references more useful and open for our editors and readers, which is the same as what IABot and the Internet Archive have already been helping us do with web citations. In response to the oppose, IA books that are public domain are accessible for free without registration, and other books can be electronically "borrowed" free of charge (account registration is required in order to fulfill a legal requirement). No money ever changes hands, nor is there any advertising. We're being handed a wonderful service here, and I can't see any good reason not to take it. Making it easier to access references that are otherwise time-consuming and expensive to check will also improve the overall verifiability of our articles. Best, Kevin (aka L235 · t · c) 23:37, 19 May 2019 (UTC)[reply]
  • (Summoned by bot) Support Sounds like a good idea. SemiHypercube 12:24, 20 May 2019 (UTC)[reply]
  • Support. Always great to see non-profit projects working together for the benefit of the users of both and our shared vision of free access to knowledge. This is a no-brainer. Gamaliel (talk) 21:56, 21 May 2019 (UTC)[reply]
  • Support as long as it works in Europe with the copyright laws Atlantic306 (talk) 20:08, 22 May 2019 (UTC)[reply]
  • Support IAbot is great and this looks like an excellent idea. More like this please. – SJ + 15:25, 23 May 2019 (UTC)[reply]
  • Support Good idea. CoolSkittle (talk) 03:06, 24 May 2019 (UTC)[reply]
  • Support Good idea. Will be helpful to readers and will further the project. – Levivich 00:58, 1 June 2019 (UTC)[reply]
  • Support Fantastic idea! TheAwesomeHwyh (talk) 18:41, 2 June 2019 (UTC)[reply]
  • Support Making it easier for readers to view the original book is a great plan, and the implementation makes sense, especially given that IA and WP share a common goal of free and openly accessible knowledge. Siko (talk)
  • Support As per all the supports above, this makes great sense for readers and editors. (Disclosure: apart from being a Wikipedian/Wikimedian, I'm an IA advisor. And being both helps me see how the combination would help the common cause of free and accessible knowledge.) Anasuyas (talk) 20:10, 4 June 2019 (UTC)[reply]
  • Support.S Philbrick(Talk) 00:49, 9 June 2019 (UTC)[reply]
  • Support. SarahSV (talk) 01:28, 9 June 2019 (UTC)[reply]

Oppose

  • Neutral: My opposing opinion was based on misconceptions, so I'm withdrawing that. – Finnusertop (talk ⋅ contribs) 09:09, 24 May 2019 (UTC) Oppose This is part of a paid effort by Internet Archive (Cyberpower678 has declared) to advertise their new book loan service. There is nothing in it for us. The previews are by and large useless (they only display the covers, table of contents, and index), with the suspicious exception of books cited by the Martin Luther King Jr. article: I want to know if Internet Archive or the article has been modified specifically to feature pages that are "just a click away from readers", whereas this is overwhelmingly not the case with Internet Archive's preview with any other set of books. (see my comment below) – Finnusertop (talk ⋅ contribs) 16:58, 19 May 2019 (UTC)[reply]
    Finnusertop, See my response to your comment below. —CYBERPOWER (Chat) 17:11, 19 May 2019 (UTC)[reply]
    To be pedantic, the service isn't new; it's existed for at least a few years. The Open Library, which may or may not be the same service, has existed since 2006. Jc86035 (talk) 17:24, 19 May 2019 (UTC)[reply]
    I might also add that archive.org isn't advertising anything. User's are not required to loan out the book to see the referenced pages on the book. While the standard link only shows the covers of the book, IABot would insert a link going straight to the page of the book that is being used to reference material on an article. User's are however required to checkout the book, which is free, if they wish to access the complete copy, i.e. more than what is being referenced on the articles and the covers.—CYBERPOWER (Chat) 17:28, 19 May 2019 (UTC)[reply]

Discuss

Per my above support concerning various forms of inline citations, such as short-form citations common in FA's, parenthetical citations, and use of Template:Rp. I think the bot could and should work to link such citations as well. Here are some putative examples, using the Main Page as a dummy link:

  • Doe p. 54 -> Doe p. 54
  • (Doe p. 54) -> (Doe p. 54)
  • [1]: 54  -> [1]: 54 

References

  1. ^ a b Doe

I think the above assertion that we should apply the bot to such various cases if this proposal passes is fairly obvious. Less obvious is HOW the IABot would do so. I think it would have to see the text that's enclosed by <ref> tags (less such stuff as page numbers), and look through a section titled "Bibliography" or "Further Reading" to see if the matched text is present in a last name parameter of a template, and then scan the rest of the book data and make the requisite links. I'm not the most technically skilled and I don't mean to be an armchair coder, but just some food for thought. – John M Wolfson (talk • contribs) 18:23, 17 May 2019 (UTC)[reply]

Would there be a check on publication date / edition / isbn? Page numbers and textual contents can change between editions. If shortened footnote citations are used would it be best to leave these alone and only alter the "works cited" listings without the page number links? Thincat (talk) 19:36, 18 May 2019 (UTC)[reply]

Thincat, right now, the idea is to do ISBN matching, but our analysis of the ISBNs shows that this can be problematic sometimes. So we are working to expand beyond ISBN matching. Right now IABot’s dataset is very conservative to ensure more accurate results. —CYBERPOWER (Chat) 18:12, 19 May 2019 (UTC)[reply]

Internet Archive has two kinds of books: Public domain books are immediately accessible to anyone and useful to link to. But that is not what this proposal is primarily about. The rest of the books on Internet Archive only provide highly limited previews. In order to access these books, you need to register and loan the book. Usually, the preview is just the covers, table of contents and index (so parts of the book that are unlikely cited). Extremely suspiciously, the pages that Martin Luther King Jr cites are the only pages those books have on preview. Cyberpower678: have you asked Internet Archive to enable preview of certain pages that are cited at Martin Luther King Jr, or modified the article to cite pages that are offered on preview?

This is a service that the Internet Archive is desperate to advertise on Wikipedia. After their plans to have our citations say "Donate book to Archive.org" fell through, this is probably the next best thing for them – but not us. We would be introducing en masse "convenience links" that simply privilege one provider over countless of others that loan or sell books. For this very same reason, WP:NOTADVERTISING, we don't add "convenience links" to Amazon or any other subscription service en masse. We already have metadata and ISBN, and that's enough for anyone interested in the book to find it through their preferred method, which may or may not be Internet Archive's loan service. – Finnusertop (talk ⋅ contribs) 16:58, 19 May 2019 (UTC)[reply]

Finnusertop, any book being linked straight to a page number is immediately visible to the reader clicking it. Try it out for yourself by inserting a page number into the URL. I am being paid to implement the bot, but I am not being paid to promote archive.org. I'm a Wikipedian first here. Unlike what you claim, I propose to the community gadgets, or bots, that benefit the community. This is not an advertisement whatsoever, as archive.org is a non-profit organization. This is a coordinated effort between the WMF and archive.org to make sources more readily accessible to ANY reader. So your claims of me pushing this out as a last ditch effort is unfounded. It was already planned since before the gadget came out to have IABot blue link books. The gadget was just an intermediate step to make it more quickly accessible to users. Note that we didn't push this after it fell through. —CYBERPOWER (Chat) 17:09, 19 May 2019 (UTC)[reply]
@Cyberpower678: thanks for answering my question and explaining how the preview works with specific page numbers as well as the development process. I'll have to give some thought to this. – Finnusertop (talk ⋅ contribs) 17:28, 19 May 2019 (UTC)[reply]
Finnusertop, Sure. I will be happy to answer any questions for you. Just know, our goal is to serve Wikipedia and the community. Not to advertise on it. Our goal is to make references more readily accessible. FTR, the donate book link was just an experiment to help archive.org expand its free library and in turn provide readers with free access. It will not be a part of this bot task as the very notion of it was rejected in the previous RfC. —CYBERPOWER (Chat) 17:34, 19 May 2019 (UTC)[reply]
How legal is this service for copyrighted books? Wayback gets away with archiving webpages, as does google, and while Google offers some limited book previews, I'm not sure how archive.org's racks up. I know archive.org generally strives to be legal, so I'm not thinking they are purposing violating copyright, but... --Masem (t) 23:55, 19 May 2019 (UTC)[reply]
IANAL, but to my understanding, for non-PD books, the way that the Internet Archive grants access to full books is by asserting that it's a library and merely digitally loaning the book to visitors. (They actually keep all the physical books for this reason.) That's why you have to "borrow" and electronically "return" the book if it's not PD in order to view beyond a snippet preview. Best, Kevin (aka L235 · t · c) 00:51, 20 May 2019 (UTC)[reply]

I don't see anything wrong with this in principle, but I'm a bit worried that it will feed the attitude that seems to be pretty common here that only sources that are freely available on the Internet count towards verifiability or notability. Such an attitude just leads to Wikipedia becoming a mirror of your favourite search engine, rather than an encyclopedia. Phil Bridger (talk) 20:36, 22 May 2019 (UTC)[reply]

Remove "suspected perpetrator" field in Template:Infobox civilian attack

(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)[reply]

(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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)[reply]
          • 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)[reply]
            • 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)[reply]
              • +1. Never lose the dream, even if forced to drop the stick. ―Mandruss ☎ 21:56, 22 March 2019 (UTC)[reply]
            • 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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      • Yes, they need to be in the infobox because this is important information. Ruslik_Zero 13:47, 27 March 2019 (UTC)[reply]
        • +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)[reply]
  • Creating an additional template for suspects and one for perpetrators would remove all the confusion. ~^\\\.rTG'{~ 23:35, 25 March 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]

  • 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 (talk • contribs) 23:35, 18 May 2019 (UTC)[reply]


Proposal/RFC: Recoloring page-protection padlock icons to be consistent with the interface

Hello everyone. Padlock icons have been redesigined to be more accessible which is great but they lack one small part, using the consistent color scheme we are using in the interface. Recently, several parts of the interface have been recolored to algin with the software interface. More generally speaking Wikimedia UI style guide. You can see the discussions in Special:Diff/754712927. In short, we use the same blue shade (#3366cc) as much as possible, from "Publish edit" button to the left border of ambox (notice) to color of links in mobile frontend, this blue-ish plus a dedicated set of grays is to give feeling of ink and book and giving a consistent look/experience to readers and sort of brand ourselves with those colors. Lots of small and invisible changes have been made (like chaning background of wikitable and infoboxes) to help aliging with the consistent color scheme. This padlock icon recoloring is a good step too IMO. Most changes are invisible to naked eye and we don't need to agree on all of them, you can shout out that color of padlock "foo" seems wrong to you. You can see the reasoning behind this color scheme in Wikimedia UI style guide.

Type of protection Current design Proposed design
Permanent protection †
Permanently protected
Permanently protected
Permanently protected
Permanently protected
Full protection
Fully protected
Fully protected
Fully protected
Fully protected
Template protection
Template-protected
Template-protected
Template-protected
Template-protected
Semi-protection
Semi-protected
Semi-protected
Semi-protected
Semi-protected
Move protection
Move protected
Move protected
Move protected
Move protected
Pending changes protection
Pending changes protected
Pending changes protected
Pending changes protected
Pending changes protected
Extended confirmed protection
Extended confirmed protection
Extended confirmed protection
Extended confirmed protection
Extended confirmed protection

† No change, added for reference

Do you support this change? Thanks! Ladsgroupoverleg 21:09, 29 May 2019 (UTC)[reply]

  • To my eye, the only padlock that looks different is full-prot. The rest look virtually identical. —A little blue Bori v^_^v Bori! 21:16, 29 May 2019 (UTC)[reply]
  • Support since I can think of no possible negative consequence of this. It's not clear to me that this change does any good, but if there's no real drawback and you think it's helpful, then I'm all in favor. Go for it. Ajpolino (talk) 22:16, 29 May 2019 (UTC)[reply]
  • Semi, ECP, and Pending look almost exactly the same. Move barely changes. Template goes from a pink to a red and Full goes from a gold to an orange. Those last two are the most likely to be controversial. I'd definitely support the first four. --AntiCompositeNumber (talk) 22:32, 29 May 2019 (UTC)[reply]
  • I can see the move icon get notably bluer with the Wikimedia UI color, but otherwise have similar opinions to AntiCompositeNumber. * Pppery * it has begun... 22:43, 29 May 2019 (UTC)[reply]
    For clarity, Oppose full and template, support others. * Pppery * it has begun... 02:09, 5 June 2019 (UTC)[reply]
  • Oppose for full and template only, support others. The full protection and template protection locks look too much like the interface-protected lock vs. under this proposal. We should not be making the locks look identical in the name of branding. —pythoncoder (talk | contribs) 18:10, 1 June 2019 (UTC)[reply]
  • Support these minor changes. I find myself agreeing with User:Ajpolino: There's no obvious harm, and you think it's helpful, so let's do it. WhatamIdoing (talk) 05:35, 3 June 2019 (UTC)[reply]
  • Ambivalent support. Minor changes which don't do any harm (though I can't say any good they do either). – Ammarpad (talk) 05:54, 4 June 2019 (UTC)[reply]
  • I don't feel strongly either way. —TheDJ (talk • contribs) 07:12, 4 June 2019 (UTC)[reply]
  • Oppose full per User:pythoncoder, indifferent/support the rest. – John M Wolfson (talk • contribs) 00:09, 5 June 2019 (UTC)[reply]
  • Oppose the Yellow 30 for full prot, the golden lock just looks better to me and yellow30 seems to "brown", from the reference palette, Yellow 50 seems to bright as well. — xaosflux Talk 03:41, 5 June 2019 (UTC)[reply]
  • Comment What about changing the full protection shackle to be more like the one used at Commons and other wikis, for the sake of consistency? funplussmart (talk) 19:27, 10 June 2019 (UTC)[reply]
  • Oppose for full and template only, support others per pythoncoder.--Vulphere 17:22, 12 June 2019 (UTC)[reply]

Proposal for a new file naming criteria: harmonize extension name

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:

jpg
Extension Count
.jpg 586975
.JPG 39738
.jpeg 20617
.JPEG 309
.Jpg 62
.Jpeg 16
.jPG 1
.JPeG 1
.JpG 1
png
Extension Count
.png 167198
.PNG 9677
.PnG 1
.pNG 1
.Png 1
svg
Extension Count
.svg 25507
.SVG 13
gif
Extension Count
.gif 21548
.GIF 749
tif
Extension Count
.tif 596
.tiff 402
.TIF 17
ogg
Extension Count
.ogg 9294
.OGG 24
.oga 1
Other
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)[reply]

Survey (file format names)

  • Support new criteria as proposer --DannyS712 (talk) 23:12, 29 May 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose per Redrose and Risker. Thryduulf (talk) 17:43, 3 June 2019 (UTC)[reply]
  • 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 (talk • contribs) 07:17, 4 June 2019 (UTC)[reply]
  • 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)[reply]
  • Oppose per Redrose and Risker.--Vulphere 17:24, 12 June 2019 (UTC)[reply]

Discussion (file format names)

Notified: Wikipedia talk:File names, Wikipedia talk:File mover DannyS712 (talk) 23:12, 29 May 2019 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      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)[reply]
      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)[reply]
      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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
Commons data
jpg
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
png
Extension Count
.png 2473405
.PNG 125542
.Png 34
.pnG 2
svg
Extension Count
.svg 1493642
.SVG 507
.Svg 4
gif
Extension Count
.gif 167101
.GIF 5515
.Gif 16
.gIF 1
tif
Extension Count
.tif 1110594
.tiff 200199
.TIF 3357
.TIFF 16
ogg
Extension Count
.ogg 919282
.oga 7166
.OGG 312
.Ogg 15
pdf
Extension Count
.pdf 443407
.PDF 867
.Pdf 1
webm
Extension Count
.webm 71003
.WebM 36
.WEBM 4
.Webm 1
djvu
Extension Count
.djvu 108225
.Djvu 2
.DJVU 1
wav
Extension Count
.wav 127401
.WAV 26
ogv
Extension Count
.ogv 69589
.OGV 15
mid
Extension Count
.mid 5056
.MID 314
Other
Extension Count
.flac 15305
.mp3 8571
.xcf 1283
.stl 1022
.webp 670
.opus 661

Deprecate WP:VEF?

Tracked in Phabricator
Task T224851

Aside from a couple of replies by a new account with ≈500 edits, no experienced editor has replied to any query at Wikipedia:VisualEditor/Feedback for over a month, and such comments as "I am at my positive and need no other too late but if a person was to gain taxes of factor it would be over seas cause Born Citizens and Naturalized citizens would not play me for a sucker so whay would I complain about taxes in Asia is Kytron in reverse, put the C' Cronyism on his Peck the egg shell-lobster lie-Cow mule Corrupts sigh is code face is cracked at Mission employment machines collapsed" have been left standing for weeks. Meanwhile, new editors are continuing to post queries and comments in good faith, which are languishing until the bot archives them. If the devs are no longer monitoring this page, would it make sense to lock it down and have the "Please click here to report a problem with VisualEditor" and "Please click here to make a suggestion" buttons point either to WP:VPT or to mw:VisualEditor/Feedback, rather than confuse and upset good-faith new editors who won't realise the feedback page is now unmonitored and will likely assume their comments are being read and ignored? ‑ Iridescent 19:52, 31 May 2019 (UTC)[reply]

I'm tempted just do it. --Izno (talk) 20:35, 31 May 2019 (UTC)[reply]
Let's deprecate WP:VE too. --Redrose64 🌹 (talk) 21:28, 31 May 2019 (UTC)[reply]
(re Izno) Normally I'd be tempted to just do it as well, but WP:VEF isn't a typical page; it was created by the WMF rather than by the community, and as you're presumably aware the WMF have been known to massively overreact when we take any action here related to their handling of the VE rollout. At the very least give it a few days to see if any of the Community Engagement people (Whatamidoing, if it's VE related I assume that means you) pop up to explain why this page needs to be kept. (An obvious objection I can see is that if we redirect new editors with queries to mw:VisualEditor/Feedback, it potentially confuses newcomers who aren't aware that mediawiki.org is a separate wiki and consequently try to work out why nothing is showing on their watchlist.) ‑ Iridescent 22:04, 31 May 2019 (UTC)[reply]
As it says at the very top of that page, WP:VEF is no longer monitored by WMF staff. All of the replies that begin with "User agent:" in small type use VisualEditor's feedback link (inside its "?" menu), and it'll take a Phab task to get those sent to MediaWiki.org. (Doable; it's just a config change, but someone's got to do it.) The mw.org feedback pages use Flow, so people will see replies via Echo/Notifications, so that needn't be a concern.
Iridescent, AIUI the WMF doesn't have any particular need to have anything VE-related on this wiki any longer. Presumably stuff should be kept around in archives, etc., as usual, but if you merged and (soft-)redirected a lot of pages elsewhere, I don't think anyone would care. Whatamidoing (WMF) (talk) 05:21, 3 June 2019 (UTC)[reply]

“Thank” button in signature.

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

  • 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)[reply]
    @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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose per others. Millbug talk 03:27, 7 June 2019 (UTC)[reply]
  • Oppose per others.--Vulphere 17:26, 12 June 2019 (UTC)[reply]
@Enterprisey: Did you have some gadget which provided this functionality? I thought that you did. Blue Rasberry (talk) 19:35, 12 June 2019 (UTC)[reply]

Establish a more firm policy about the notability of mass shootings and other events for WP:ITN Suggestion

I noticed that the shooting at Virginia Beach did not get its own blurb in WP:ITN, with the logic being that such an event is commonplace in the United States. True as that may be, further down the ITN there is a blurb about a boat collision which killed 6 less people.

So I think we should probably discuss what makes such a mass-casualty event notable. Should we have a blurb for every shooting that occurs which kills a certain number of people, regardless of location? What about other types of mass casualty events such as a fire or bomb? Should we consider the frequency that such events occur in different locations when determining whether or not we should have a blurb about it? I think having a firm policy in place will help prevent future accusations of bias. I welcome any discussions about this Rockstonetalk to me! 08:11, 3 June 2019 (UTC)[reply]

From what I see in the discussion, the reason why one went up on ITN and the other didn't wasn't a question of death toll (although the death toll of the boat accident might still increase), but a consequence of the fact that mass shootings are very common whereas (in the western world) such boat accidents aren't. Jo-Jo Eumerus (talk, contributions) 08:24, 3 June 2019 (UTC)[reply]
"I think we should probably discuss what makes such a mass-casualty event notable." That discussion occurs on a near-daily basis. At WP:ITN/C. In this case the view was, correctly, that the shoot-up did not warrant main-page coverage. You say that we should have a "firm" policy--is an ordinary policy not enough?--to prevent "future accusations of bias". There have been no accusations of bias in this matter let alone any rational accusations of that kind. So there is no need for a "firm" but equally macabre policy about minimum death tolls and the like. For what it's worth I wouldn't have posted the boat thing either but wikipedia editors seem obsessed with minor disasters and so be it. --Mkativerata (talk) 10:00, 3 June 2019 (UTC)[reply]
The current policy works well - we consider the quality of the article, the nature of the event, how frequently events of that nature happen in the same and similar locations, how the event compares to other similar events (including, but not limited to, death toll), what (if any) the long term significance of this looks likely to be, how wide the the coverage of the event is, and anything else that makes this event stand out as more or less significant than other events. The Stoneman Douglas High School shooting was posted because that mass shooting had several features that made it stand out from the crowd of similar events (mass shootings in the United States), principally the reactions to it from students and politicians and the impact on the gun control debate. The Virginia Beach shooting has had none of that. The Hungarian cruise ship sinking was an incident in a much smaller field (fatal sinkings of/collisions between passenger vessels on inland waterways in Europe and similar developed countries - browsing through the various lists of shipwrecks articles I can't find another similar incident that has happened worlwide in the last 5½ years; there were 43 mass shootings in the United States in May 2019 - the events are not comparable. The previous posted maritime incident of any I can recall was Sinking of MV Nyerere in September 2018 (overloaded passenger ferry sank in Lake Victoria killing 228). Thryduulf (talk) 13:32, 3 June 2019 (UTC)[reply]
  • If anyone wants a home for sorting policy, I welcome anyone to join Wikipedia:WikiProject Disaster management. To see an automatically updated list of all disasters in all languages, check out d:Wikidata:WikiProject Humanitarian Wikidata. @Rockstone35:, you asked what is common among fires, bombs, shootings, and boat accidents. These projects and other precedents group all such things together and imagine some common policy on them. Any comments or thoughts are helpful. Disasters will always happen, and articles on disasters are among Wikipedia's most popular, best covered, and most quickly produced articles. We have a strange social situation where people who develop disaster articles often only do one, rather than do them routinely, and perhaps for this reason Wikipedia has not established a stable community of people who routinely discuss disasters despite us having so much high quality content in this field. Blue Rasberry (talk) 13:58, 3 June 2019 (UTC)[reply]
  • See WP:CREEP for why some sort of "firm policy" is not a good idea.(this has been suggested and failed before.) Down the road we will have so many "firm policies" that this whole thing will be unworkable and not need participation from us; you can just program a bot to make ITN a news ticker in that case. Each event needs to be judged in context related to many factors as seen by readers/users. 331dot (talk) 14:09, 3 June 2019 (UTC)[reply]
  • I don't think any sort of firm policy in this area is necessary or desirable. Such cases should be decided individually by the good people at WP:ITN, and WP:CREEP plays a role. – John M Wolfson (talk • contribs) 22:36, 3 June 2019 (UTC)[reply]
  • We already have a policy, and it's ignored too often at WP:ITN/C. That policy is WP:No original research. In my view, at ITN/C, editors too often engage in original research to determine the importance of a topic.
    • You see it in the comments here, where a distinction is drawn between Stoneman Douglas High School shooting and Virginia Beach shooting because Stoneman "had several features that made it stand out from the crowd of similar events (mass shootings in the United States) principally the reactions to it from students and politicians and the impact on the gun control debate". The notion that Stoneman is special because of reactions and impact on the gun control debate is just one editor's opinion. I could easily point out that Sandy Hook shooting was exactly like Stoneman in the impact on the gun control debate, as was the Las Vegas shooting, which led to a near-nationwide ban of bump stocks. Similarly, I could say Stoneman is "special" because of the high number of casualties, in which case it would be in the same category as Virginia Beach shooting. Indeed, Thryduulf and I could go back and forth comparing and contrasting this shooting and that shooting, and it would all be impermissible WP:OR.
    • You also see it in the oft-repeated mantra that "mass shootings are common in the United States". That, by the way, is a bunch of WP:OR as well, and it's incorrect. The definition of "mass shooting" changes depending on who you ask. It might mean 3+ dead or 4+ dead. It might include the shooter in the casualty count, or it might not. Yes, if you look at 3+-dead-including-shooter shootings, there are a ton of them. But Virginia Beach shooting had 13 dead, and that happens less than once a year. Which brings us to the question of what does "often" mean. Because some editors felt that something that happens every year happens too often to be important enough to be put on the main page. By that logic, all mass-casualty events with 10+ dead, or 50+ dead, or even 100+ dead, would be excluded, because they happen too often. Using "often" as a dividing line to determine what gets on the main page and what doesn't is WP:OR. One editor can say once a year is often and another can say once a year is rare. Who decides? It should be the WP:RSes, not a majority !vote.
    • Meanwhile, sports championships, even those that happen annually, routinely get on the main page, if not as ITN/C then ITN/R. Editors deciding that a regularly-recurring sports championship gets on the main page because it's regularly-recurring, while a "mass shooting" (as editors define it) doesn't get on the main page because it's regularly-recurring... is, itself, total WP:OR. No reliable source "splits the baby" in this way–you won't find a newspaper that puts the snooker championship on page one for multiple days, while not at all listing a 13-casualty mass shooting. That is an "only on Wikipedia" thing... and probably some snooker magazines.
    • We may not need a "firm policy", but it might help to have a guideline for ITN/C that very closely follows our policies of WP:NOR and WP:V. We should, as in all things, follow the sources. If all of the international media are putting something on page one above the fold, it probably should be on our main page, too (subject to other considerations, like our article quality). If the media is ignoring something, it probably shouldn't be on our main page, either. I do see bias at ITN/C (and I don't participate there much because I don't want to fight with everyone constantly), and that bias is that editors use ITN/C as a way to right great wrongs by downplaying things they think the media over-covers and up-playing things they think are undercovered. WP:NOR is our policy that protects us from our own biases. – Levivich 18:56, 5 June 2019 (UTC)[reply]
Some good points here, but it seems WP:NOR misapplied here to the area of doing research to determine notability and prominence. NOR is about "material—such as facts, allegations, and ideas—for which no reliable, published sources exist." It is not a prohibition on looking at sources to determine appropriateness for ITN. -- Fuzheado | Talk 16:42, 11 June 2019 (UTC)[reply]
  • Mass casualty events are routine occurrences in a world of 7+ billion people. It's depressing to see them on the front page continually. Some are obviously so notable as to be required, but it would good to see periods of rest from this type of article. -- — Preceding unsigned comment added by GreenC (talk • contribs) 19:26, 5 June 2019 (UTC)[reply]
  • The relevant policies are WP:N and WP:NOT. WP:ITN rests on these, and significance is determined by consensus, not a majority vote. Invoking WP:OR indicates that this policy is not understood; is permissible here, as it is in many areas of the project. WP:RS is not used, because what is important is not notability per se (all articles are supposed to be about notable subjects) but prominence. Caution should be taken when assessing news sources for prominence, because most major news outlets provide individualized experiences for each user, based on geography and browsing history. Just as we regard military and light air crashes as unexceptional (WP:AIRCRASH), so mass shootings in the US, which are routine, accepted and tolerated — 43 last month alone according to List of mass shootings in the United States in 2019 — are not regarded as newsworthy. (I like the bit about excluding gang-related killings.) Look at the sources in the list article. Most are local papers. As Thryduulf pointed out, ones with wider implications have a better chance of achieving prominence. Hawkeye7 (discuss) 20:01, 5 June 2019 (UTC)[reply]
    • Well of course I would not say that a random mass shooting which kills only a few people is prominent enough to be listed in WP:ITN, regardless of where it happened. Yes, 43 mass shootings occurred last month, but most did not kill anyone, and relying on the quantity of mass shootings in determining whether a particular mass shooting is notable is disingenuous. Mass shootings which kill many people remain very rare. The scale of the shooting (13 people killed) I think makes that particular shooting stand out. I would not agree that we should consider the location the event happened when determining prominence. If 15 people are stabbed to death in the UK, that should make it ITN, even though knife crime is common there. Rockstonetalk to me! 22:00, 5 June 2019 (UTC)[reply]
    • WP:N is not a policy. And Wikipedia is not a reliable source, so we shouldn't look at List of mass shootings in the United States in 2019, and based on that Wikipedia article, come to any conclusions about whether or not "mass shootings are common". That, to me, is what WP:NOR is exactly about. Don't draw any conclusions about mass shootings based on a list of mass shootings created by Wikipedia editors. If, for example, we want to base ITN decisions on the notion that "a 13-casualty shooting is commonplace", that should be based on the consensus of reliable sources, and not based on Wikipedia editors putting together a list and counting how many items are on that list. That's OR. It's also a pillar that "Editors' personal experiences, interpretations, or opinions do not belong", which is a principle that should apply to ITN decisions, i.e., don't base ITN decisions on editors' interpretations of statistics. – Levivich 21:57, 5 June 2019 (UTC) (ec)[reply]
      • ITN's own guidelines state "It is highly subjective whether an event is considered significant enough, and ultimately each event should be discussed on its own merits. The consensus among those discussing the event is all that is necessary to decide if an event is significant enough for posting.". By nature, the guidelines are subjective, which requires interpretation. If you want that changed, you may need to propose an RFC to do so.--WaltCip (talk) 15:47, 6 June 2019 (UTC)[reply]
        I'm not the right person to propose an RfC to change ITN guidelines, but I would support a change to specify that "significance" should be determined by WP:RSes and not by editors' WP:OR opinions. – Levivich 00:38, 9 June 2019 (UTC)[reply]
    • At ITN we have a fake policy "WP:MINIMUMDEATHS" that we use to indicate that death count is not a sole deciding factor in whether we post news - it is all about context. If we has a confirmed terrorist attack in a location that never has been subject to one, which may have killed one or only none, but receives massive coverage, we may still post it. On the other side, we regularly do not post reports of hundreds killed in flooding in China and India regularly because these types of deaths are too frequent in those areas. And using event notability via WP:NEVENT is also bad because most notability can only be determined well after the event has happened after it fallen out of ITN. It is always going to be subjective at ITN and thus determined by consensus. --Masem (t) 15:59, 6 June 2019 (UTC)[reply]
  • ITN already has WP:ITN#Purpose which guides the selection of articles posted to the template. We could just jettison the whole "significance" criteria and use article quality as a gate, but I think some people like deciding what is "important enough" for the front page of Wikipedia. --LaserLegs (talk) 08:07, 8 June 2019 (UTC)[reply]
  • I think in the end, ITN/C is a reflection of pre-existing biases that exist among the editors, and it's always been like that. I disagree that there should be a given guideline to posting incidents, we have ITNR which fulfils the purpose it is supposed to but that is not something that can be applied here. To put it simply, I disagree with the premise that it was a fault in the first place that the Virginia beach shooting wasn't posted, or that the boat accident was. ITN/C is a way to garner consensus on the newsworthyness of news and whether it (and the article) is suitable for the main page and not anything else. Adding more bureaucracy to a non-existing problem is not the solution. --qedk (t 桜 c) 15:14, 9 June 2019 (UTC)[reply]

Names of articles on subreddits

The current articles on subreddits on subreddits follow the format /r/[subreddit]. This makes no sense to me as they are pronounced r slash [subreddit] and are displayed as r/[subreddit] on Reddit. I already moved r/changemyview as I thought it was an outlier, but I noticed all the other pages that follow the some format. I also noticed that mentions of subreddits are in the /r/[subreddit] and not the r/[subreddit]. I propose we change all mentions of subreddits from /r/[subreddit] to r/[subreddit], including article titles(we can use {{lowercase}} to make the r lowercase). – BrandonXLF (t@lk) 01:10, 6 June 2019 (UTC)[reply]

  • I've had a look at both MOS and prior VP discussions and didn't see anything clear on this. I'd like one of the MOS brigade and/or one of the active reddit page writers to provide their thoughts because there might be some specific reason. You are definitely right as to the standard usage/naming (in effect, COMMONNAME). Nosebagbear (talk) 12:45, 6 June 2019 (UTC)[reply]
  • Speculating: one reason may be that without the initial slash DISPLAYTITLE or {{lowercase}} is needed in order to prevent the title from showing as R/[subreddit], and because that code does not affect the WP URL or how the article appears in categories, those will always have the R if an initial slash is not used. (check out how r/changemyview now looks in its categories.) 14:49, 10 June 2019 (UTC)
  • I've seen both used on Reddit (for example, the /r/subreddit form links just as well as r/subreddit in the code) and the coding issue here is a legitimate concern. Typical readers don't necessarily browse categories, though, so I feel like that's less of an issue. I don't mind either way. -A lad insane (Channel 2) 18:32, 10 June 2019 (UTC)[reply]
IIRC, it used to be (on Reddit) that only /r/subreddit links worked. r/subreddit links were introduced later (a couple of years ago). That's why /r/ links are still used in many places, and both are equally valid. From what I can tell, most official documentation produced by Reddit uses /r/ links, but even they are not completely consistent. rchard2scout (talk) 11:00, 11 June 2019 (UTC)[reply]
  • As from my observation, I've seen both of /r/ and r/ being used across Reddit so I think I will wait for other comments.--Vulphere 17:27, 12 June 2019 (UTC)[reply]

Category:Aristocrats

In a recent CFD I noticed that Category:Nobility is a mess because it's used as a catch-all for things related to "nobles" a term which is not in the common language (we just say "aristocrats"). The main things to notice are that it does not have a clear distinction between living and dead nobility, and its used for nobility the people and nobility the idea, so the category is overused in those two big ways. Any comments? -ApexUnderground (talk) 23:54, 7 June 2019 (UTC)[reply]

  • Aristocracy is probably better due to such confusion, although "nobility" and "aristocracy" are used in that context in approximately the same frequency in the US (which admittedly doesn't have one). – John M Wolfson (talk • contribs) 19:21, 8 June 2019 (UTC)[reply]
I seem to agree, but others seem to prefer the other one (hence the CFD link).-ApexUnderground (talk) 19:25, 8 June 2019 (UTC)[reply]

RfC: Apollo 11 anniversary and the Main Page

Please comment on the discussion at WT:TFA about the Main Page for 50th anniversary of Apollo 11. --- Coffeeandcrumbs 03:33, 8 June 2019 (UTC)[reply]

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

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)[reply]

  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
You miss the point... the curation needs to be done HERE on WP... not at WD. Blueboar (talk) 14:28, 10 June 2019 (UTC)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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): https://tools.wmflabs.org/mix-n-match/#/group/biography Adam Harangozó (talk) 18:05, 11 June 2019 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support per many of the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:19, 12 June 2019 (UTC)[reply]
  • 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)[reply]

Rollback

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)[reply]

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)[reply]

Create Wikipedia:Portals for Deletion or Wikipedia:Portals for Discussion

Miscellany for Deletion mostly consists of deletion discussions on portals. There are currently 35 portals nominated at MfD at the time of writing this. Compare that to Files for Discussion, which only has 14 discussions at the moment. Considering the fact that Wikipedia:Miscellany for deletion no portals exists, I'd think people would want this. InvalidOS (talk) 13:28, 12 June 2019 (UTC)[reply]

Seems like a solution in search of a problem - MfD seems to do reasonably well at the job. On a more cynical note, at the current rate we'd end up with an inactive XfD within a few more months Nosebagbear (talk) 15:00, 12 June 2019 (UTC)[reply]

Allow bureaucrats to quickly re-sysop admins temporarily de-sysoped by WMF for carrying out out community consensus

Closing as no consensus with an invitation to workshop further at Wikipedia talk:Administrators#Restoration of access following involuntary desysop by WMF Office. I would suggest working on a more comprehensive amendment to address more than the present case. –xenotalk 13:01, 13 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.

I propose the adoption of the following policy:

If a Wikipedia administrator is temporarily relieved of their administrator status by the Wikimedia Foundation for carrying out an administrative action for which local consensus had been established, their administrator status may be restored by any Wikipedia bureaucrat without further process, upon request from that editor immediately upon expiration of any period of de-adminship specified by the Wikimedia Foundation.

For no particular reason, I just think this would be good policy to have around in case the WMF happens to de-sysop an admin for carrying out a consensus-based action, and specifies a time limit for the expiration of this penalty. bd2412 T 19:31, 12 June 2019 (UTC)[reply]

  • To quote myself from Wikipedia talk:Administrators

    Adminship on this project is a measure of the community (and the Arbitration Committee)'s trust in an editor, not a measure of the Wikimedia Foundation's trust in that editor. Thus, unless there's some indication that the office-desysopped admin has lost the community's trust (which is clearly not the case for both of the admins the WMF desysopped recently), then there is no cloud and their admin rights should be restorable on request. * Pppery * it has begun... 01:41, 12 June 2019 (UTC)

    Hence, Support * Pppery * it has begun... 19:33, 12 June 2019 (UTC)[reply]
  • Support duh. Frankly, I'm not sure this even goes far enough. Lepricavark (talk) 19:36, 12 June 2019 (UTC)[reply]
  • Support the events of the last two days shows the need for this. MarnetteD|Talk 19:49, 12 June 2019 (UTC)[reply]
  • Procedural close per WP:CONEXCEPT AdA&D 19:52, 12 June 2019 (UTC)[reply]
    • There is no recent consensus that is contrary to this proposal. bd2412 T 19:55, 12 June 2019 (UTC)[reply]
    • I misread the proposal. If you are suggesting people should be immediately resysoped after a temporary desysop by an office action, the I oppose. They should have to go through RFA to see if they still have the trust of the community like anyone else who loses their admin priviledges. AdA&D 20:02, 12 June 2019 (UTC)[reply]
  • Oppose as written above, at the very least I'd want to see the person that access will be added to acknowledging that they want the access added to their account, such as a request at BN. — xaosflux Talk 19:53, 12 June 2019 (UTC)[reply]
    • Additionally, the "time limit" could be anything - "temporarily for 10 years" is still "temporary", and the editor could no longer be other wise fit or eligible. As a bright line, I'd only want to see something like this applied for short term (i.e. less than 1 year) events. — xaosflux Talk 19:55, 12 June 2019 (UTC)[reply]
  • Oppose Local consensus cannot be determined in one or two days. There was no consensus in the case with Floq, which IMO shows bad decision making and has made me lose confidence. In addition, the reasons for WMF to be involved at all apparently have to do with legal and safety issues which we should not get involved with. I encourage discussing the issue with WMF, but for us to just reverse everything we don't like is wrong. Megalibrarygirl (talk) 19:58, 12 June 2019 (UTC)[reply]
  • Oppose per Xaosflux, but would support if "upon request from that editor" were added. Seraphimblade Talk to me 20:03, 12 June 2019 (UTC)[reply]
  • Support Xaosflux’s version as a partial defense against WMF idiocy. —pythoncoder (talk | contribs) 20:11, 12 June 2019 (UTC)[reply]
@BD2412: this same discussion was pretty much already started at WT:ADMIN, I suggest combining these. — xaosflux Talk 19:51, 12 June 2019 (UTC)[reply]
Restored this comment that was summarily removed by User:Anne_drew_Andrew_and_Drew with a reason of "nah". If you object, just say so. — xaosflux Talk 20:18, 12 June 2019 (UTC)[reply]
Whoops, an honest mistake. Edit conflict or something. AdA&D 20:55, 12 June 2019 (UTC)[reply]
  • Since this affects me, I thought I'd comment. I was fully aware that this would likely result in my desysop, so I don't think I deserve the admin bit back, and I'm happy to defer to whatever the en.wiki community decides. A couple of notes:
    1. WMFOffice's description of how I get the bit back after a month is unclear. I suspect because they don't know how en.wiki works. They say "a RfA can be opened once 30 days elapse, and the community may decide on the request at that time in such or another way" (emphasis mine). I interpret this as saying that any process the community decides on is OK. But I might be biased.
    2. If they actually meant that an RFA is required, I don't think WMFOffice should be able to specify how I get the bit back after a temporary desysop expires. If they wanted it permanent barring a new RFA, they should have made it permanent. If the consensus of the en.wiki community is that no RFA is required, I will not be following that particular specification in WMFOffice's sanction (if that's what they meant).
    3. I do not plan to ask for my bit back until (a) Fram is unbanned, or (b) Fram's ban is confirmed by an en.wiki process
    4. If it is determined here that an RFA is required, I will probably just remain a non-admin. That may change depending on circumstance and how I feel after a month. But right now I feel too old to go thru that shit again.
    5. Perhaps those who confidently throw around the accusation that I'm just interested in "protecting an abuser" will notice a pattern in the words I choose to highlight here.
    --Floquenbeam (talk) 20:51, 12 June 2019 (UTC)[reply]
  • Oppose This would not be helpful - it would only increase tensions in any situation where it is invoked, rather than leading to a solution. Mike Peel (talk) 20:53, 12 June 2019 (UTC)[reply]
  • Good in principle but oppose This puts a huge interpretation task on the 'crat to interpret "local consensus" and "temporarily" and make the resultant decision to override WMF. If WMF does stuff that is so stupid that a quick override decision by a single 'crat is called for, that's pretty crazy. North8000 (talk) 20:58, 12 June 2019 (UTC)[reply]
    • To be clear, I'm fairly sure the proposal is for what to do after the WMF desysop expires. --Floquenbeam (talk) 21:10, 12 June 2019 (UTC)[reply]
  • Oppose. Wheel-warring with WMFOffice is a horrible display of poor judgement, especially when it is done in defense of someone banned by the WMF for "harassment and/or abusing others", based on evidence you are not party to. If the Office didn't desysop, presumably ArbCom would have, which is a cloud. If you think they still have the community's confidence, send them through RfA. ~ Rob13Talk 21:12, 12 June 2019 (UTC)[reply]
  • Oppose. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 12 June 2019 (UTC)[reply]
  • Unnecessary A "temporary desysop of X days" is by definition temporary, ie, the Office or bureacracts (as the case may be) are obliged to restore the bit at the end of the period unless Office/Arbcom decide to up the penalty in the meantime. Barring that last scenario, we don't need an RFA; we don't need the admin to be "carrying out an administrative action for which local consensus had been established"; and we don't even need the ex-admin to place a request. Compared with a time-defined block, the only difference is that the the available interface (afaik) does not allow for a pre-scheduled change of user-permissions and therefore the mechanical action of restoring the bit needs to be carried out by persons with the technical ability. But this should not blind us to the fact that the decision to restore the bit has already been made by the authority who imposed the "temporary desysop of X days". Abecedare (talk) 21:30, 12 June 2019 (UTC)[reply]
  • Symbolic "support". I realize that this is never going to happen, but I want to express my support for the idea that this desysop was handled abysmally by the WMF. --Tryptofish (talk) 12 minutes ago
Comment restored after unexplained rollback by Mojo Hand -- AdA&D 21:37, 12 June 2019 (UTC)[reply]
  • Oppose - If for some reason an admin has been desysoped by the WMF, even temporarily, it is likely that they have done somethig that may call into question the community's trust. If they haven't, they should be able to pass an RfA, StudiesWorld (talk) 21:41, 12 June 2019 (UTC)[reply]
    This is not true. Floquenbeam's unblock of Fram clearly did not indicate a loss of the community's trust. * Pppery * it has begun... 23:11, 12 June 2019 (UTC)[reply]
    I don't trust him worth a damn, at the moment, and based on conversations I've had with others who are trying not to wade into things, a good many others don't as well. If you believe Floq has the community's trust, why are you (supporters collectively, not just literally you) so afraid to put that to the test at RfA? ~ Rob13Talk 04:37, 13 June 2019 (UTC)[reply]
  • Support. Benjamin (talk) 23:08, 12 June 2019 (UTC)[reply]
  • Support – If the community loses trust in an admin, we have ways to handle that. Maybe they aren't very good ways, but that's not the issue here. The community grants adminship indefinitely to trusted editors without condition except that they keep the trust of ArbCom and the community. RFAs do not expire. We do not require admins to have or keep the support of the WMF, and our policy should assume good faith on the part of admins even where the WMF concludes they were wrong, unless the ArbCom or the community does too. This is different from some other types of desysoppings in that it doesn't mean either has changed its mind, and it should be treated like other desysoppings of admins we still trust. To respond to some points above, I don't think many people would disagree that holding more RFAs is not likely to decrease tensions. It is not wheel-warring to undo an action after it was intended to expire. I think we can assume that when an office action expires, the WMF has determined that there are no legal or safety implications we should be concerned about with undoing the action. KSFT (t|c) 00:29, 13 June 2019 (UTC)[reply]
  • Oppose seems reactionary and poorly thought through. If we want to resysop Floq, we have WP:IAR which I recommend doing. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 02:54, 13 June 2019 (UTC)[reply]
  • Oppose this seems unnecessary and vague. It was clearly meant to apply to Floquenbeam, except that it doesn't seem to clearly apply to Floquenbeam without further discussion. As I explained in detail here [1] it's thoroughly unclear if Floquenbeam was even carrying out a consensus based action. Nil Einne (talk) 03:13, 13 June 2019 (UTC)[reply]
  • Support T&S shouldn't be fiddling with advanced permissions, temporary measures, or local sanctions. They should have only the one tool that they have ever needed for their legitimate purpose of ToU enforcement of serious, legally necessary sanctions: the global permanent ban. And that should be appealable to Jimbo, a remit he may delegate on a case-by-case basis to specific projects' arbcom-equivalent body, if he so chooses. EllenCT (talk) 03:15, 13 June 2019 (UTC)[reply]
  • Oppose. The proposed policy does not explain how to determine whether "local consensus had been established". Many editors associate the term local consensus with Wikipedia:Consensus § Levels of consensus (WP:LOCALCONSENSUS), which states, "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale." WP:OA and WP:CONEXCEPT prohibit overriding office actions, and any policy of this nature should require community-wide consensus, not just local consensus. — Newslinger talk 07:05, 13 June 2019 (UTC)[reply]
  • Oppose - I'm concerned that this might be an example of hard cases make bad law. Evidence and discussion is in a very dribbling sense. Thirdly, RfAs have a much wider footprint - they're watchlist advertised. It wouldn't be unreasonable for some individuals to say they weren't aware - at least in the case of "unaware of the idea of resyopping an admin without an RfA", even if they were aware of the initial issue. Personally I suggest an alternative, not needing a rule change (obviously assuming Floq's criteria had been met). Start the RfA 24 days after his desysop - allowing a close as soon as it's finished. Nosebagbear (talk) 09:11, 13 June 2019 (UTC)[reply]
  • Oppose any change to policy, as on the rare occasions this situation will arise, each case will be different. ‑ Iridescent 09:27, 13 June 2019 (UTC)[reply]
  • Oppose per Iri. Hard cases make for bad law. ∯WBGconverse 09:36, 13 June 2019 (UTC)[reply]
  • Oppose We need a full RFA to decide if such admins should have their tools restored. — BillHPike (talk, contribs) 10:37, 13 June 2019 (UTC)[reply]
  • Oppose Per others. An RfA is really the best method to determine if the actions that lead to the desysop are truly supported by community consensus. --AntiCompositeNumber (talk) 11:58, 13 June 2019 (UTC)[reply]
  • Oppose We must have very different definitions of "clearly". I'm not seeing clarity or consensus here. Hawkeye7 (discuss) 12:55, 13 June 2019 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=901665843"