Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Community portal
Help desk Village pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

Commons discussion pages (index)

Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?



Proposal to migrate interwiki links to Wikidata (wherever possible)[edit]

For detailed proposal, see

which may be the best place for detailed comments and follow-ups, to keep discussion all in one place.

Essentially, now that the template {{Interwiki from Wikidata}} exists and is in wide use, that preferentially shows interwiki links from Commons categories to Wiki articles if possible, and Wiki categories if not, I suggest that:

  1. Interwiki links held locally be de-materialised from here, wherever they correspond to what would be generated via a Wikidata sitelink, the interwikis held on Wikidata, and the {{Interwiki from Wikidata}} template.
  2. Sitelinks to Wikidata items be created as necessary to enable this.
  3. Sitelinks to go to a corresponding category-type item on Wikidata if such a category item exists; otherwise to an article-type item there.
  4. But care to be taken, and sitelinks not to be added, if there is any detectable ambiguity as to which Wikidata item should be linked to.

I suggest that this would have the following benefits:

  • The interwiki links on Wikidata are more likely to be maintained, and so may be more comprehensive, as Wikidata is the central site where Wiki <-> Wiki interlinks are held.
  • Interwiki links via Wikidata will automatically reflect any merges or editing of the Wikidata items and which Wiki pages they are connected to.
  • Better identification between Commons categories and Wikidata is useful in preparation for Structured Data, for understanding categories here, and for facilitating templates that can draw on Wikidata.
  • In particular, sitelinks are helpful for getting Wikidata-driven templates on Commons to work automatically.
  • It will no longer be necessary to make separate edits here and at Wikidata to link to a new wiki article in a new language.

User:Fæ has criticised me for jumping straight to COM:BR to raise the proposal for discussion, and he's probably right. But as it is there, with more detail that people might like to comment on, it might be best to go on with the discussion there.

Struck, per User:Colin below. Jheald (talk) 19:02, 7 November 2017 (UTC)

In companion to this, I have also proposed at Wikidata project chat to revise the Wikidata notability guideline and explicitly confirm that such sitelinks are appropriate, to bring policy there de jure into line with what has long been the case de facto. Jheald (talk) 18:06, 7 November 2017 (UTC)

  • Symbol oppose vote.svg Oppose There has been insufficient preparation for this proposal. Examples:
    1. The assertion "links on Wikidata are more likely to be maintained" is unproven. With a significantly smaller active community on Wikidata, it is more likely that changes to the category structure on Commons will cause drift from any Wikidata syntactical meaningfulness, and Commons contributors are unlikely to want to be forced to edit Wikidata to correct mistakes there. The likely/unlikely assertions need backup with evidence in advance of this proposal.
    2. "interwiki links via Wikidata will automatically reflect any merges or editing" is a Wikipedia way of thinking, there is no analysis here of how category changes, including amending hierarchies, sub-categorization, mass re-categorization or even category renaming will be maintained via Wikidata's P/Q arcane number systems, nor whether Commons contributors will now be expected to do that Wikidata analysis and changes before they can get on with doing smart quick categorization with cat-a-lot. This is an area that could do with a simple guide and backup analysis of the practical use, before running ahead with proposing mass changes that result in Commons categories being controlled or frozen via Wikidata due to the burden this introduces.
    3. With on-going discussion at Wikidata, the foundation of this proposal is not yet fixed. Wikidata must have its house in order before proposing mass changes on Commons.
    4. "sitelinks not to be added, if there is any detectable ambiguity" there is no agreed guide on how this will be measured, nor even where the locus of future disputes will be.
    Please make a proposal when there is a credible foundation of evidence and best practice to support it. If the changes create an avoidable additional burden on Wikimedia Commons volunteers interested in maintaining categorization, then that is not in the interests of this project. -- (talk) 18:21, 7 November 2017 (UTC)
@: Really? Do these objections really add up?
  • Yes, the Wikidata-specific community is small. But Wikidata is where editors from every community go to manage their interwiki links, via the "quill" icon in the interwiki part of the sidebar. If they want their new page to be sitelinked to any other wiki, they go to wikidata. They do not, I suggest, very often come here. It's what Wikidata was built for, and why interwiki links via Wikidata are likely to be more extensive and less stale than interwiki links here, which according to User:Jarekt he hasn't systematically updated for at least 5 years. No, I don't have any numbers to back that up; but I am sure if anyone is really interested they could look to see how many interwiki links have been added at Wikidata in the last year, and what proportion of those have been added to a category here. Personally I'd be surprised if it was even 5%.
  • In thinking about category changes here, yes all sorts of refinement happens but I submit that it is rare if a category has a role, that that role gets handed to a different category. Yes the category may get renamed or merged, but the software should be able to follow that, and update sitelinks accordingly. More often in hierarchy refinement, cat-a-lot is used to create and populate subcategories, without changing the meaning of the original category. Also worth considering is that if the information on Wikidata is not updated, that will typically break incoming links from Wikis, which tend to follow P373 statements on Wikidata rather than interwikis. The interwikis on Commons currently really only determine links from Commons categories to Wikis. To make sure links in both directions get updated, it would probably be no bad thing for them to be all managed in the one place.
  • "Detectable ambiguity". The different ways I could think of to detect ambiguity are set out in the more detailed proposals I posted at COM:BR (which you criticised as being unhelpfully technical for a policy discussion, which needed to first establish the generalities). If people have thoughts about any further ways to identify abiguities, please do bring them to that discussion at COM:BR.
  • Wikidata policy. Yes, it would be profoundly unhelpful if we were to add sitelinks and Wikidata was to delete them. But I don't think that's going to happen. I think there's broad acceptance in the community there of article-type items sitelinking to categories here, as over half a million such site-links currently bear witness to. It would be useful to confirm that explicitly in Wikidata policy. But it seems to me useful for the two discussions to run in parallel -- I don't see any benefit in holding up this one to wait on the other one. Jheald (talk) 19:00, 7 November 2017 (UTC)
Responding to ping: Thanks for your responses, however you have left the questions open ("likely", "I am sure", "should be", "probably", "I don't think"), apparently expecting others to provide evidence to back up your proposal. The burden of proof is on the proposer. Nobody expects you to do this on your own, but the proposal should only be put to the community when the assertions of benefits or impact made in the proposal can be verified. Without being given those basics, people are voting yes/no on wishes and guesstimates, and we should be able to do better than the type of popularity vote that leads to Brexit and President Trump. Thanks -- (talk) 19:33, 7 November 2017 (UTC)
  • Pictogram voting comment.svg Comment Could I suggest, for crying out loud, that we just have a discussion. You know those things where people try to find some common agreement and work towards a goal? Instead, as seen above, when Commons votes you just get person A saying all sorts of polarised things in favour and person B saying all sorts of polarised things against, rinse and repeat, and we never advance, never progress towards agreement. Despite JHeald's request, we currently have comments/votes on two pages. I would strongly recommend using a community page like this one, rather than an obscure bot page that fewer people have in their watchlists. This isn't really about running a bot (yet) but whether the community thinks the migration of these links is a good thing. -- Colin (talk) 18:38, 7 November 2017 (UTC)
Fine, let's have the discussion here then. Jheald (talk) 19:00, 7 November 2017 (UTC)
Commons<->Wikidata sitelinks if we have both commons gallery and category and Wikidata article-item and category-item.

Symbol support vote.svg Support the idea of retiring old style interwiki links which everybody else stopped using since Wikidata come along. In the past I was the one that occasionally run interwiki update bot, but have not done so for last 5 years since Wikidata project started and everybody else migrated to Wikidata based interwikis. As a result many of the links are likely very stale. So I agree that we need to migrate, but details about how would vary with namespace:

  • File: All interwiki links should be removed
  • User: Old style should remain
  • All the rest except for Category and Gallery. Should rely on Wikidata sitelinks.
  • Gallery: I would suggest using {{Interwiki from Wikidata|Wikidata=Q????}}
  • Category: This one should have majority of links. There are 2 possibilities:
    1. Add {{Interwiki from Wikidata}} without hardwired q-code and rely on having Wikidata sitelink from either article-item or category-item
    2. Add {{Interwiki from Wikidata|Wikidata=Q????}} with hardwired q-code and not use Wikidata sitelinks
Option #1 is much easier to maintain as any correction would have to be done only in one place and you would not have to keep q-codes on Commons in synch with Wikidata sitelinks. The challenge of option #1 is that if you have the usual setup with sitelink from article-item to Commons-category and than someone creates Commons-gallery than article-item sitelink might get changed to the gallery. At this point Commons-category will loose its interwiki links. So option #1 would only work if we agree that sitelinks to Commons categories should take precedence over sitelinks to galleries, and than convince Wikidata Community that that is a good idea. Let me, ping @Multichill, Zolo:, who might also be interested in this discussion. --Jarekt (talk) 20:09, 7 November 2017 (UTC)

Probably best to focus on categories. For me {{Interwiki from Wikidata}} in it's current form is just the start. Maybe spend some time on improving the template so it shows some nice description in your local language based on Wikidata? That would really add benefit from grabbing data from Wikidata. Multichill (talk) 20:38, 7 November 2017 (UTC)

That's the {{On Wikidata}} template. I'm not sure that we really want to take up space in the header of every category though, when there's already a link to Wikidata in the sidebar (assuming the site link variant is used). I thought it had already been the consensus to replace the old-style interlanguage links for years, and I've been deleting them and replacing with site links whenever I see them. It would be preferable for a bot to do it. --ghouston (talk) 04:38, 8 November 2017 (UTC)
  • Gallery, I don't see much value there. Category to main concept is the way to go. — regards, Revi 09:22, 23 November 2017 (UTC)
To me, good galleries would be our preferred introduction to a topic from outside -- they would have curated images, and some descriptions. I could see linking both a gallery and a category, I suppose. Carl Lindberg (talk) 14:30, 24 November 2017 (UTC)
You mean linking category and a gallery in same wikidata item? That is technically not possible. It is in Wikidata dev's radar for at least 3 years, and it's still not possible. — regards, Revi 09:57, 2 December 2017 (UTC)
Hm. Prefer a gallery then if it exists, but if not use the category? Some galleries are pretty poor, to be sure, but the good ones should be featured, to me. Is it possible for both a gallery and category page use the same interwiki links from Wikidata? Carl Lindberg (talk) 17:02, 2 January 2018 (UTC)
No, gallery and category cannot co-exist as a sitelink in one item, and fix was requested since the Commons integration to Wikidata was offered in 2013, and it's 2018. I don't think it will be offered in any foreseeable future. — regards, Revi 13:36, 13 January 2018 (UTC)
  • Symbol support vote.svg Support Strongly support, it is only a question of time. In the beginning Commons itself was questionable separate (image data store) project. In time all growth together. In effect the interwiki-links on Wikidata get much much more proven as a single page on Commons (alle projects can data changes on here watchlist and also Commons). Anyway I don't see that problems described by Fæ. So I see really no reason why Commons should go alone separated from WD. -- User: Perhelion 13:17, 11 December 2017 (UTC)
  • Symbol support vote.svg Support This is the reason Wikidata exists in the first place. Regards, Yann (talk) 14:40, 2 January 2018 (UTC)
  • Symbol support vote.svg Support, this would greatly help with creating more structured data on Wikimedia Commons, but Wikidata should be able to host multiple Commonswiki categories and/or galleries per item if possible, but Wikimedia Commons should be supported by Wikidata by default. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 11:38, 3 January 2018 (UTC)
  • Accessing Wikidata with a specified Q number for generating Wikipedia links and other info useful for navigation and disambiguation (one live example here) is IMHO good. But relying on Wikidata to obtain a Q number searching values of Commons category (P373) for the {{PAGENAME}} is ungood, because depends on some kind of search or a cache not controllable directly. It can be also subverted e.g. by a P373 value in a page protected on Wikidata. I do not endorse drive-by deployment of {{Interwiki from Wikidata}}. Note that I didn’t actually read proposals and can’t assess degrees of preparedness. Incnis Mrsi (talk) 14:03, 13 January 2018 (UTC)
  • Question. What happens when existing commons interwiki conflicts with wikidata? Keep / delete / convert to wikilinks ... ? How many commons pages are affected? Retired electrician (talk) 20:22, 13 January 2018 (UTC)
    Local interwiki links override the Wikidata links.--Ymblanter (talk) 00:06, 14 January 2018 (UTC)
  • Symbol support vote.svg Support Interwiki links here are, to be honest, a mess. They're fragmented, and not particularly maintained. Most wikis now use Wikidata for this, and we can benefit hugely by migrating over to that system - as can the other wikis as they can more easily get links to Commons there. I'm happy to help with the work needed to migrate the remaining interwikis over (I've been removing them as I've seen them, but this would be much better done by a bot and then human editing can sort out the oddities). Thanks. Mike Peel (talk) 21:38, 6 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose. -- Tuválkin 10:23, 13 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose linking categories to category items when no gallery exists. For Commons to be useful, the interwiki links on categories should continue going straight to the corresponding articles when they exist, as they always did. Some users on Wikidata don't like this, which is why traditional interwiki links have survived in the first place. There is no urgency to migrate interwikis before Wikidata is ready to embrace the Commons way of linking. --Nemo 13:28, 13 February 2018 (UTC)
  • Symbol support vote.svg Support --Zaccarias (talk) 19:57, 11 March 2018 (UTC)
  • Pictogram voting comment.svg Comment@, Tuvalkin, Nemo bis, Zhuyifei1999: most of your all concerns are about linking styles between categories and main namespace pages (in this site case, that's galleries), which I frankly welcome you to see Phabricator T54971 [Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity, this discussion is de facto increased the scope to Wikimedia permanent duplicated page, and may have possible to apply there, in short: That task aims to sunset the unfair "Wikidata allows only one sitelink per item per language" limitation. --Liuxinyu970226 (talk) 03:53, 16 March 2018 (UTC)

RFC: Change in Scope - Art & the education of intelligent machines (& people)[edit]


EXECUTIVE SUMMARY Considering art's unique role in education, how do we make space for paintings, drawings, non-photographic interpretations of what words mean within wikimedia? One suggestion would be to remove “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” as an example of something that is not in scope and allow artwork to be removed on other grounds.

Background & Context: #SettleForBoth[edit]

I was recently at The Long Now Foundation where members were discussing, “What books would you want to rebuild civilization with?” Most of the contributions were scientific in their practicality with the great tombs of philosophy and government mixed it.  It’s a fun exercise that asks, “What knowledge is important?” But no number, size or weight limit had been placed on the library and I found that, without any constraint, the discussion was sort of useless.  Given the chance wouldn’t we want all books? All forms of knowledge? Even as an artist I’d not argue that Grapes of Wrath is more important than An Edible Guide to Plants but in this theoretical exercise, why not both (#settleForBoth)?

This is a form of the question facing Wikimedia Commons, a community whose purpose is tied to that of the Wikipedia Foundation's to encourage the, “growth, development and distribution of free, multilingual, educational content.”  Specifically Wikimedia Commons’ purpose is as a, “a media file repository making available public domain and freely-licensed educational media content (images, sound and video clips) to all. It acts as a common repository for all Wikimedia projects, but the content can be used by anyone, anywhere, for any purpose.”  It’s scope is defined with the restriction relevant to this discussion defined as, “Must be realistically useful for an educational purpose. The expression "educational" is to be understood according to its broad meaning of "providing knowledge; instructional or informative."

Purpose & Goals: Art's educational value as applied to the removal of "self made artwork without obvious educational value."[edit]

I’d like to make an argument for an expanded view of art’s educational value with the hope of having this view formally adopted by the community particularly as applied to the current practice of removing, "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills.”  

I make this argument in part because I have had my own images, most of them paintings, removed for this reason.  But the relevant context is much larger.  In making this argument I touch upon the purpose of art, art as knowledge, the relationship of art to language and art’s unique role in education while questioning the de facto supremacy of photography as truth’s and education’s medium of choice.  I also argue that this preference for photographic form perpetuates the internet’s product-focused content through which the internet’s great educational and creative potential is increasingly confined to a shopping mall.

Art & Knowledge Gaps[edit]

The question is whether or not my paintings, and others like them, constitute what Wikimedia Commons refers to as “obvious educational use.” The community's current interpretation of “obvious education use” is limited by a preference for text and photography that leads to a less diverse and therefore less complete set of contributors and contributions.  Especially as Wikipedia investigates the demographics of its contributors, one purpose of this writing is to make more obvious the educational use of art and its role in the Wikimedia Commons’s mission.

Artwork Marked For Removal as "non-educational."[edit]

On June 16th, 2017 53 of my images were marked for deletion off Wikimedia Commons as, “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills.”

The cultural/educational vs the commercial internet[edit]

If not to “showcase [my] skills” why was I putting these paintings on Wikimedia Commons? Compared to Google and Facebook, Wikimedia Commons does a decent job of reflecting the diverse and complex world in which we live.  For example, within Google “girl” means a sexualized woman but on Wikimedia the definition is more accurately reflected.  Search engines are getting much more content from sites that are trying to sell us something than sites that are trying to teach us something.

Companies Over Communities, Products Over People and Commerce Over Culture[edit]

Within search engines Amazon is more relevantly a company than a river. Cherokee more relevantly a car before a tribe of people. An internet made for discovery within Google will favor companies over communities, products over people and commerce over culture.  As more of the internet flows through Google and more content creators are incentivized to become relevant, companies with large search engine optimization resources outpace the ability of non-commercial concerns to surface. The results remind us to question: What makes up the internet, where does it comes from, who makes it and what are their motivations? Who is favored? Left out? Ignored?

Wikimedia Commons & Search Engine Optimization[edit]

Images on Wikimedia Commons are correctly structured for search engines in a user-friendly way and therefore have strong presence within search results.  This means Wikimedia Commons is playing an important role in the non-commercial internet through its ability to make content competitive within search engines.  This is especially important now as Wikimedia Commons is involved not just in the education of people but of machines.

Language & Images[edit]

If you feed enough photos of a platypus into a machine learning system it can learn to identify a platypus. It is one thing when you are discussing a word for which a definition is binary, something that either is or is not a platypus.  But what about man? Woman? House vs Home?  When conducting an image search when do you stop getting "yellow" and start seeing "orange", or stop defining as "black" and start saying "white", or "rich" and "poor", "beautiful” and “ugly?”

#accordingToTheInternet: human[edit]

When you search for “human” within and see mostly white men, you can’t say that Google is technically wrong, these images are of humans.  This visual mapping of every word to a set of most relevant images is something old encyclopedias never would have attempted in part because the complexity of many words is failed by visual definition.

Through machine learning and artificial intelligence search engines like Google are learning to identify who is and is not a human based on the current, widely non-diverse data set of online content. Any holes and bias that exist within language are getting automated through machine education into how the world is being defined.  Putting content on Wikipedia Commons is potentially one of the most powerful ways to get diverse, complex and minority perspective into these definitions.  

Photography & "Truth"[edit]

We need to encourage and allow much more diverse set of images on high-value content sites such as Wikimedia Commons to aid in the education of machines, but why not just more photography? What is it about the presence of art-images, especially in non-photographic mediums, that makes them uniquely valuable in the education both of people and machines?

Search Engine Art: Internet Imperialism[edit]

My research has so far led me to conclude that one important approach is to add non-commercial, non-product images online that are structured in a way pleasing to search engines. Part of this initiative involves my method of Internet Imperialism where I create paintings about targeted keywords and then spread these images online with the express goal of modifying universally returned search results.  For example,  when you search “malignant epithelial ovarian cancer” Google now returns my paintings as top results.  

Painting & Perspective[edit]

It is not that within themselves my paintings contain the sole and correct definitions but that the painting medium, as compared to photography, is a great reminder of bias and perspective.  The potential for a diverse and complex interpretation is high. When we, and maybe so with machines, see a painting, and especially a painting within a search engine, we remember more easily that this images is one person’s perspective, not some techno-endorsed truth.  

By preferencing photography over other mediums such as painting and drawing we are drastically over estimating its relationship to truth. Photography too is a form of art through which conscious and unconscious bias are presented. Manipulating photographs is common and easy.  Computer generated graphics and photo realistic painting blur the confining lines of the medium.  Even medical diagrams often convey deeply seeded beliefs in their attempts at impartial truth.  

Art & Education[edit]

This is to say that my purpose for putting these removed paintings on Wikimedia Commons was not to, “showcase [my] skills.”  My purpose was educational.  Having these paintings on Wikimedia Commons allowed me to aid in the education of search engine algorithms, contributing some of the human complexity they are missing in their current product-focused training set.  They also contribute to the education of Wikimedia Commons’ and search engine’s end users.

Art constitutes a unique form of knowledge that often conveys its information through the productive introduction of uncertainty instead of the firming of facts.  When we look at a painting one of the important and often unconscious transmissions that occurs is that the way the world is seen and understood is subject to personal interpretation.  Through art we receive a jarring and expanding awareness of otherness.  Through art we can make machines less sure that they have a complete handle on what it means, and looks like, to be human.  Art can do the same thing for us humans.

Art is educational, outside of it’s contextualization by experts, in large part because through great art we gain a way of seeing the world that is not our own, that which by definition we could not have understood through our own direct experience. Art is the gift of experiences that we ourselves could not have had directly. Through “Starry Night” we get to know the world as Van Gogh knew it, and in that experience we are extended beyond the constraints of our own way of looking and by extension, understanding.

Subject vs Object & "better than words"[edit]

In the same way, Edvard Munch created paintings inspired by personal anxiety that we ourselves did not have to suffer, and in doing so he allowed us to feel, if only obliquely, what he experienced.  For examples like this, some in the Wikimedia Common’s community have argued for keeping images on a “better than words” basis.  

In Art this is the difference between a work’s objects and its subjects. In Munch’s The Scream we see a distorted human figure on a bridge, the objects, but read the subject to be anxiety or fear.  In another example, a painting of an apple (the object) may be about temptation (the subject).  Much of art’s educational value is in what it is about, in its subjects.  My images that were taken off of Wikimedia Commons were paintings about my hometown of Bow New Hampshire, what it was like to grow up there and return as an adult.  These images replaced and live among the top results on Google that were once dominated by for-sale real estate.  

The Difference Between "Of" and "About"[edit]

By allowing only images “of” instead of images “about” words on Wikimedia Commons we limit everything to its lowest common denominator and apply a lens that is fraught with bias on what the essence of something truly is.  When community deals with abstractions, such as emotions, artwork is highly present is submissions acceptable by the community.  This is likely because “sadness” has no image equalicant of “home.” But can not home be both a subject and an object? Isn’t home as a concept complexly related to cultural expectations and feelings? I believe this is an important place for art.  It says, “to the artist, this is a home” instead of, “this is what home is.”  This is central to art’s educational value.  

What is knowledge and how is it conveyed and by whom?[edit]

Ultimately to accept artworks more broadly on Wikimedia Commons is to more deeply consider what is knowledge and how is it conveyed. I believe that art, even poorly skilled attempts at art, tell us something essential about the uncertainty and complexity of things, the variety of ways the world can be seen and understood.

I think there is great complexity and diversity to be gained by the inclusion and encouragement of art within Wikimedia Commons. Especially as we consider its unique presence in the training sets being used by search engines in machine learning. & like with the books to rebuild civilization, why not #settleForBoth and consider these contributions, "useless by harmless." — Preceding unsigned comment added by Gretchenandrew (talk • contribs) 17:14, 19 January 2018 (UTC)

Open for discussion. This is important. What do you think?[edit]

See updated summary below

Considering art's unique role in education, how do we make space for paintings, drawings, non-photographic interpretations of what words mean within wikimedia? One suggestion would be to remove “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” as an example of something that is not in scope and allow artwork to be removed on other grounds.— Preceding unsigned comment added by Gretchenandrew (talk • contribs) 17:24, 19 January 2018 (UTC)

Gretchenandrew (talk) 17:56, 19 January 2018 (UTC)gretchenandrew

  • I think TL;DR. It may or may not be a good proposal, but it's hard to understand with all of that text. Any chance you could shorten it by 99%? --GRuban (talk) 17:22, 19 January 2018 (UTC)
  • would Takeaway who orignally marked my paintings for removal comment? --GretchenAndrew(talk)
  • Would this basically change the scope to be all freely-licensed files, since everything can be considered "art"? Can Commons users even change the scope of the project significantly, or is it set by the Wikimedia Foundation? --ghouston (talk) 01:20, 20 January 2018 (UTC)
    Right. I think we get enough drive-by narcissists dumping their low-quality selfies in Category:Art as it is. No need to legitimise that. So Symbol oppose vote.svg that's a no from me. LX (talk, contribs) 11:22, 20 January 2018 (UTC)
    Hello --ghouston & LX, I understand your point. It seems that we might discuss and potentially agree on something that would be better executed by a different change. I do not believe that images should be removed BECAUSE they are art, or that images should be removed because they are not photographs or diagrams. Considering art's unique role in education, how do we make space for paintings, drawings, non-photographic interpretations of what words mean within wikimedia? Gretchenandrew (talk) 21:32, 20 January 2018 (UTC)
  • Hello --ghouston & LX, In retrospect it may not be so much that "everything can be considered art" but whether art or not mediums other than photography & diagrams have a role in education. The argument is that photography does not have a monopoly on defining what something is and that drawing and painting may better convey / document. We don't even really need to decide if we think it is art or not. This addresses your self example you are concerned about. I drawing of depression may not be categorized as "art" but should be allowed. What do you think? Gretchenandrew (talk) 14:10, 6 February 2018 (UTC)

  • Pictogram voting comment.svg Comment I don't think we need to change the current definition of scope. IMO, art reproductions by non notable artists are in scope if 1. the reproduction is of high quality, 2. if the reproduction can be used to show a specific technic or style. Regards, Yann (talk) 07:26, 20 January 2018 (UTC)
    Hi Yann, what about the educational role of art in portraying non-object concepts like emotions? Could art by non notable artists be possibly useful in expanding under represented world views? My experience is that notable artist come heavily from certain demographics and often become notable by making art that appeals to a problematically non-diverse world view concentrated in hands of very few. — Preceding unsigned comment added by Gretchenandrew (talk • contribs) 18:52, 20 January 2018 (UTC) Gretchenandrew (talk) 21:31, 20 January 2018 (UTC)
@Gretchenandrew: For which under represented world views, techniques, or styles would you want to make the playing field more level?   — Jeff G. ツ please ping or talk to me 01:53, 21 January 2018 (UTC)
@Jeff G.: I find the dead/famous use very restrictive because of the structures through which artists become famous being heavily western and male. Consider how relatively few images of nude women in art were made by women. By allowing only dead/famous artists into this visual definition we get a very constrained, limited, non diverse view of what a woman looks like. Gretchenandrew (talk) 00:14, 22 January 2018 (UTC)
@Gretchenandrew: Yes, but the representations have to be of good quality. BTW, this is already covered in our scope: we don't need to change our scope to upload images like this or this. Regards, Yann (talk) 05:04, 21 January 2018 (UTC)
@Yann: I disagree because images like your example are sometimes removed. The presence of images that have not been removed is a solid argument to show the inconstant application of the interruption. I think making this clearer would benefit the community. Do we or do we not allow images by non-famous artists? Gretchenandrew (talk) 00:14, 22 January 2018 (UTC)
@Gretchenandrew: AFAIK, all images by non notable artists were deleted either because of copyright issues, or bad quality. If you have a different case, please bring it up here, or on COM:UDR. Regards, Yann (talk) 07:23, 22 January 2018 (UTC)
@Yann: Thank you for pointing out how to address images that were removed for reasons other than, "copyright issues or bad quality." But if, as you state, these are the reason to remove images from non notable artists why is this an explicit part of the Wikimedia's not in scope: Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills? I think we may agree! That art is removed for reasons other than the fact that it is art. But when my images have been removed they have been removed and flagged as, "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills." What value, in your opinion, does this add on top of the existing image quality and copyright qualifications? Gretchenandrew (talk) 00:55, 29 January 2018 (UTC)

Could this whole proposal be shortened to the words Gretchen used above: "Considering art's unique role in education, how do we make space for paintings, drawings, non-photographic interpretations of what words mean within wikimedia?"

@Colin: I really like this. My original post was much longer because I wanted to make it clear the variety of ways and motivations from which I had considered the issue. But I am adding this at the top as an executive summary. Thank you for pulling it out! Gretchenandrew (talk) 00:14, 22 January 2018 (UTC)

I think Gretchen is right that amateur photographic art is more acceptable on Commons than painting. For example: Category:Intentional camera movement. For myself, I think File:Bluebells ICM, Ashridge Estate, 2015.jpg represents an old woodland in spring, for British observers at least. A more conventional photograph File:Pryor's Wood Bluebells 2017-04-26-4.jpg has its own qualities, and certainly from the reviews at Featured Pictures, many Commoners thought the latter had more educational value. But the latter image is not representative; it simply is. And that can limit its use if in fact one just wants to convey emotions and memories of old woodland in spring. One might want to do this though art for art's sake, but also to accompany another work, whether fiction or non-fiction. High quality published writring is often accompanied with high quality images, whether photographic or painting, whether realistic or representative. It could be argued that Commons goal of being an educational media repository includes images that convey concepts, words, emotions, memories, etc, and not just provide an illustration of a particular species of bird or the facade of a historic building.

@Colin: I agree. I believe that Common’s educational goals extend beyond the direct illustration of words. If it did not there would be many images that need to be removed. Considering it’s prominence in the visual internet, to not consider this in scope would be the seed creative and educational control of these issues to commercial interests. There is a defensive use of art in education. Gretchenandrew (talk) 00:18, 22 January 2018 (UTC)

But where to draw a line? An artist might create almost anything in their "interpretations of what words mean". One only has to visit a modern art gallery, and read some of the curator guff written on a card next to works of art. A large sheet of grey card means XYZ. Another vague arrangement of tones, with a torn corner means ABC. "If you say so". Does any art become educational because the artist, a curator, or some random observer claims it means, represents or describes a word or concept?

The Wikipedia article on Major depressive disorder is illustrated by several artworks created by famous artists, which we can only use because they are no longer under copyright. The Wikipedia article on The Shard is illustrated by a photograph created by a non-famous photographer and is under copyright, though freely licenced. Why can an amateur Commoner create an illustration for the latter with a camera, but an amatuer Commoner cannot create an illustration for the former with a paint brush. One problem perhaps is that the attibutes that make a photograph high quality for use in an article are relatively easy to determine. Is the exposure good, focus sharp, is it very detailed, does it capture the whole subject, is the camera level, are there few distracting elements, etc, etc. But how to determine what a high quality image on "depression" is? Our restriction to only famous works by dead artists, make the choice easier but sometimes is too restrictive, or the images available are unnacceptable to modern sensibilities. The article on Epilepsy, if published by a commercial publisher, would certainly include artwork representing overactive brain stimulation or neurons firing excessively, but we have none. Perhaps if the artwork is high quaity enough and has an obvious meaning or representation, it would pass our current restriction on "realistically useful for an educational purpose". -- Colin (talk) 11:53, 21 January 2018 (UTC)

  • @Colin: Though to some extend I have made the argument, I am not arguing that artwork should NEVER be removed. At the heart of this I am arguing that “Artwork” should not be called out as a reason for removal. Could we just remove artworks that also fail to meet some other aspect of scope? For example, remove artwork just as we remove photography that is not educational useful. If artwork were to be de facto accepted, as is photography, the contributor still has the opportunity to contest a removal, documenting and sharing the maybe non-obvious reasons why the artwork is tagged with certain words as themes/ subjects. Current scope language has the effect of discouraging the addition of artwork. As pointed out, this is inconsistently applied but definitely used to remove images BECAUSE they are not photographs. This suggestion would mean removing “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” as an example of something that is not in scope. Gretchenandrew (talk) 00:18, 22 January 2018 (UTC)

  • This discussion remind me this case where an artist have sent a permission regarding its paintings but the images were deleted, see User talk:Christian Ferrer#Borrado de imágenes (relative DR), a video of the artist; Are the paintings in scope? although I am often intractable with personal photos (selfies, families vacations photo sets... ect...), personally I will tend to be a little more permissive for paintings and drawings... maybe not for all cases but sometimes yes. Christian Ferrer (talk) 12:27, 21 January 2018 (UTC)
  • @Christian Ferrer: Thank you for pointing out that paintings/drawings are often more accepted in your judgement. Do you see any value in making a clearer policy? Gretchenandrew (talk) 00:18, 22 January 2018 (UTC)
I don't think we should remove "self made artwork without obvious educational value" from our policies, but more add something like "self made artwork without obvious educational value, without illustrative interest, or without any visual qualities". Christian Ferrer (talk) 05:37, 22 January 2018 (UTC)
I don't think "without any visual qualities" is useful because all visual art has visual qualities, and qualities can be both good and bad. I'm not clear on what "without illustrative interest" means if it isn't illustrating for educational purpose (e.g. a diagram of how a cell works), which would pass already. I think the simplest solution would be to stop applying a stricter rule "obvious educational value" to self-made artwork vs self-made photographs beyond the policy scope of "realistically useful for an educational purpose". The former implies such clear educational value that surely nobody would disagree and thus even sending the file to DR implies it is not obvious to at least one person. The latter implies a consensus opinion where people can argue how realistic the chances of educational use is. I appreciate some of the latter arguments can be ridiculously lame (I have seen people argue that a snapshot of a person with white skin, brown eyes and brown hair is educationally useful for an article on white skin, brown eyes or brown hair, and go about aggressively adding a stupid number of such categories to the image to prove their point). There also needs to be an awareness among deleting admins that Commons does not exist simply to illustrate Wikipedia, and that artwork (photographic, painting, drawing, computer generated) need not be a direct illustration of some notable noun, but may be educationally useful if illustrating a mood, emotion, memory, concepts, arguments, beliefs, etc. We can have contemporary art illustrating sadness, joy, childhood, equality, environmentalism, holiness, love, etc, etc. -- Colin (talk) 08:55, 22 January 2018 (UTC)
Webcartoonist's depiction of his own nervous breakdown
@Colin: I agree, we should probably strike the "obvious". I think the image on the right is an excellent example of contemporary artwork by a non-famous artist being able to convey things no photograph ever could. I'd like to see much more of this on Commons, but I'd also like to make very clear that Commons is not DeviantArt. --El Grafo (talk) 16:17, 22 January 2018 (UTC)
@Colin:, @El Grafo: Looking at what makes Wikimedia Commons different from deviantArt is a good place to start. To me, it is content be added with the intention and potential for educational use that makes Wikimedia different. I believe art has a role in this. The contributor applies educational use potential not just by adding an image to the other images online, but in applying labels, words, categories, meta data that allow it to become educationally useful. As long as this step is done properly by the contributor, the image is not restricted in its copyright, and the photographic image is of high quality, as well as meeting all other standards applied to images on wikimedia why do we care if it is a a painting or drawing by a non notable artist? Given this, what do you think we should do with, "“Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills.” Gretchenandrew (talk) 00:55, 29 January 2018 (UTC)
Pictogram voting comment.svg Comment Yes, these paintings are a good case in point. The paintings are themselves of bad quality (i.e. File:"Parlament Català".jpg), and the photos are not very good either. We can certainly have this kind of artwork if it is done properly: photographed with good lighting and a DSLR, of high resolution (12 Mpixels), etc. Regards, Yann (talk) 15:20, 22 January 2018 (UTC)
Pictogram voting comment.svg Comment Pinging @Dvdgmz: you might have some more thoughts on this discussion based on WikiArS...I recall that project had some similar experiences with drawings being deleted or considered lower-quality just because they were not photos, but I'm not sure whether you think that's a result of the policy or people's bias in interpreting policy. What Commons considers "educational" definitely feels like a somewhat murky judgement call to me at the moment. Some contributors persist in gathering hundreds of freely licensed images of naked women in specific poses - e.g. Category:Nude or partially nude women facing right - and I'm still not sure why those should be considered inherently more educational than drawings of people, things, or concepts that we have 0 photos for! Seeeko (talk) 00:19, 23 January 2018 (UTC)
This point of @Seeeko:'s is central. Why are we considering drawings and paintings to be artwork, and not photography, and applying a different standard or application of what is educational to these mediums? Those opposing the removal of, "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills," I would be interested to hear your thoughts on this! Gretchenandrew (talk) 00:55, 29 January 2018 (UTC)
  • Pictogram voting comment.svg Comment the Scope of Wikimedia Commons is as vague as it can get, for example File:Sikh man, Agra 10.jpg is a featured picture 📷 (and rightfully so, I might add), but if this same image was uploaded with "Abeer Hassankhan posing in front of a camera" thus file would've been deleted as being "out of scope", I think that there should be a more general discussion about Commons:Scope to address these double standards and idiosyncracies. I believe that pictures with educational value should be permitted but what constitutes "educational value" is often left to the whim of the closing admin which is why almost all "pornographic" images get deleted by default even if they are fully within scope. Art is no different, sure Wikimedia Commons can be used as a medium for self-promotion for new artists but the same can be said about "amateur photographers". --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 12:00, 30 January 2018 (UTC)
  • @Donald Trung: Hello - what is the best way to, as you suggested, have a more general discussion about scope's idiosyncrasies? To me, with medium, it is an easy win to remove "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills" maybe instead adding, "Images uploaded for self promotion." Gretchenandrew (talk) 14:16, 6 February 2018 (UTC)
  • Pictogram voting comment.svg Comment All paintings can be used with an educational value, given that 1) the photo has a good resolution, 2) the artwork is correctly categorised. The categories that matter here are the style of painting (e.g. abstract art), the support (e.g. canvas), the material (e.g. oil), and eventually what it represents (in view of Structured Commons). Without information, the upload of a painting file is usually simply an ADVERT for contemporary (and unknown) artists. --Ruthven (msg) 17:41, 2 February 2018 (UTC)
  • @Ruthven: Hello, I agree. Proper categorization is necessary for paintings/drawings/art and all images on The Commons. What do you think the value is of having the current scope defined as it is? "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills" maybe instead adding, "Images uploaded for self promotion." Gretchenandrew (talk) 14:16, 6 February 2018 (UTC)
    • @Ruthven: Great point. Thank you for bringing to my attention. Can we remove "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills" on the grounds that all artwork that should be removed within this category can be removed for another reason? Gretchenandrew (talk) 16:54, 6 February 2018 (UTC)
      They are redundant, but I think that's better recall that Common's is not a free hosting website (for art, but also for all the rest). --Ruthven (msg) 16:56, 6 February 2018 (UTC)
  • Oppose proposal. As already said, anything can be considered "art" and we would have to keep everything on that ground. There is plenty of famous "in scope" artwork that suit our purposes. Moreover, the proposal is made by a user who has an ulterior motive: to influence the discussion of Commons:Deletion requests/Files uploaded by Gretchenandrew. Not sure why he is going through such extent trying to publish on Commons when there are numerous other sites for that. --P 1 9 9   19:06, 16 February 2018 (UTC)
  • Symbol support vote.svg Support. I think this proposal has merit, though it needs to be focused a little more.
The policy being discussed comes from here: COM:EDUSE and COM:NOTUSED, where "educational" is very broadly defined there as
"providing knowledge; instructional or informative".
With this definition in mind, the example given further down the page
"artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills"
should be softened a little bit more as per the comments above from Colin (talk · contribs), El Grafo (talk · contribs), Christian Ferrer (talk · contribs), Donald Trung (talk · contribs), and Ruthven (talk · contribs) to something like
"artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills"
or even
"artwork without educational use, including non-educational artwork uploaded to showcase the artist's skills".
I think the "obvious" part of that example becomes too high of a standard for non-traditional media that is not photography.
I think this starts to get controversial because, in theory, any seriously considered artwork, regardless of the subjective opinion of the artists' skills, could then be argued to be kept as long as there was a reasonable instructional or informative educational rational for the artwork in question. It is important to recognize (and properly justify) that by proposing this change, some editors think it is a fairly radical change to Commons policy compared to how most people have interpreted the policy historically. I think the concern is the change could lead to a large increase in the number of images hosted on the Commons, but I don't think that concern is a fair reason to dismiss this proposed change. I think it is important to emphasize that all other policies would still need to be followed for these potential new images, including COM:ADVERT. Beyond the reasonable educational explanation, each image would need to be appropriately categorized according to that explanation and otherwise presented and described properly.
Unfortunately, I'm not very active on the Wikimedia Commons, and so I'm not able to point to any other specific policies or guidelines that support this view. But based on this rationale, I think the example should be changed to better reflect the potential educational value of non-photographic images when explained appropriately. ~ PaulC/T+ 15:02, 18 February 2018 (UTC)


Art is an underrepresented knowledge form that has an important role in the education of people and intelligent machines. Its systematic disclusion and deletion from Wikimedia Commons, both as a matter of official scope and dramatically different interpretations of official scope, perpetuates knowledge gaps that serve to limit the usefulness, diversity, and impact of Wikimedia. Mainly for this reason I believe we should remove “Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills” from OUT OF SCOPE.

Those that oppose this change have argued that:

Such a change would legitimize, “low-quality selfies in Category:Art.”@LX:
Not true. Low quality selfies could still be removed for “bad quality” or as “Private image collections.”
Wikimedia is not a Deviant Art like site and should not become one. @El Grafo:
REPLY “I think the concern is the change could lead to a large increase in the number of images hosted on the Commons, but I don't think that concern is a fair reason to dismiss this proposed change. I think it is important to emphasize that all other policies would still need to be followed for these potential new images, including COM:ADVERT. Beyond the reasonable educational explanation, each image would need to be appropriately categorized according to that explanation and otherwise presented and described properly.” @Psantora:
Anything can be considered art! @Ghouston:
While this is true it is not relevant. I am not suggesting that we keep files just because someone calls them art but that we not delete files because they are in a non-photographic medium, particularly when they address a subject in a non-immediately illustrative way such as when emotions/ mental illness are portrayed via paintings. This debate is not about what is and is not art, and who does and does not get to decide. This is not about allowing anyone’s and all drawings being uploaded and tagged as “art” but about drawings/paintings being tagged with their subject.
Images are not removed for this reasons, @Yann:
Not true. The debate on my recently uploaded images show this is not true.

Those that see the current status as an issue have argued that:

“There also needs to be an awareness among deleting admins that Commons does not exist simply to illustrate Wikipedia, and that artwork (photographic, painting, drawing, computer generated) need not be a direct illustration of some notable noun, but may be educationally useful if illustrating a mood, emotion, memory, concepts, arguments, beliefs, etc. We can have contemporary art illustrating sadness, joy, childhood, equality, environmentalism, holiness, love, etc, etc.” @Colin:
Category:Nude or partially nude women facing right - and I'm still not sure why those should be considered inherently more educational than drawings of people, things, or concepts that we have 0 photos for! @Seeeko:
I believe that pictures with educational value should be permitted but what constitutes "educational value" is often left to the whim of the closing admin which is why almost all "pornographic" images get deleted by default even if they are fully within scope. Art is no different, sure Wikimedia Commons can be used as a medium for self-promotion for new artists but the same can be said about "amateur photographers" @Donald Trung:
I think the "obvious" part of that example becomes too high of a standard for non-traditional media that is not photography. @Psantora:

Gretchenandrew (talk) 16:39, 10 March 2018 (UTC)

Updated summary of Gretchen's proposal:[edit]

  • Thanks for the summary, Gretchen. This hopefully will make it easier for others to comment. An even more concise summary, if I may:
    Proposal: Remove Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills from the second example given under the header Examples of files that are not realistically useful for an educational purpose: in COM:NOTUSED.
    Rationale (as described by @Gretchenandrew): Art is an underrepresented knowledge form that has an important role in the education of people and intelligent machines. Its systematic exclusion and deletion from Wikimedia Commons, both as a matter of official scope/policy and dramatically different interpretations of official scope/policy, perpetuates knowledge gaps that serve to limit the usefulness, diversity, and impact of Wikimedia.
    Arguments against (with rebuttals):
    • Paraphrased from @LX: Such a change would legitimize, “low-quality selfies in Category:Art.”
      Rebuttal from @Gretchenandrew: Low quality selfies could still be removed for “bad quality” or as “Private image collections”.
    • From @El Grafo: Wikimedia is not a Deviant Art like site and should not become one.
      Rebuttal from @Psantora (me): I don't think that concern is a fair reason to dismiss this proposed change. I think it is important to emphasize that all other policies would still need to be followed for these potential new images, including COM:ADVERT. Beyond the reasonable educational explanation, each image would need to be appropriately categorized according to that explanation and otherwise presented and described properly.
    • From @Ghouston: Anything can be considered art!
      Rebuttal from @Gretchenandrew: While this is true it is not relevant. I am not suggesting that we keep files just because someone calls them art but that we not delete files because they are in a non-photographic medium, particularly when they address a subject in a non-immediately illustrative way such as when emotions/mental illness are portrayed via paintings. This debate is not about what is and is not art, and who does and does not get to decide. This is not about allowing anyone’s and all drawings being uploaded and tagged as “art” but about drawings/paintings being tagged with their subject.
    • Paraphrased from @Yann: Images are not removed for this reason.
      Rebuttal from @Gretchenandrew: The debate on my recently uploaded images show this is not true.
    Arguments in favor:
    • From @Colin: Commons does not exist simply to illustrate Wikipedia, and that artwork (photographic, painting, drawing, computer generated) need not be a direct illustration of some notable noun, but may be educationally useful if illustrating a mood, emotion, memory, concepts, arguments, beliefs, etc.
    • From @Seeeko: I'm still not sure why those [Category:Nude or partially nude women facing right] should be considered inherently more educational than drawings of people, things, or concepts that we have 0 photos for!
    • From @Donald Trung: I believe that pictures with educational value should be permitted but what constitutes "educational value" is often left to the whim of the closing admin which is why almost all "pornographic" images get deleted by default even if they are fully within scope. Art is no different, sure Wikimedia Commons can be used as a medium for self-promotion for new artists but the same can be said about "amateur photographers"
    • From @Psantora (me): I think the "obvious" part of that example becomes too high of a standard for non-traditional media that is not photography.

End of summary

  • The way I'm reading this, there is too much variation and unfair judgement for what is determined to have an "obvious educational use" and it is used as a catch-all for practically any file to be deleted. In general, this is more obvious with files that are not photographic images. As a result, non-photographic images (and art in particular) are more likely to be casually deleted without any real debate or discussion as to their merit on Wikimedia. Amending policy by removing or softening Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills will force these discussions to have more substantial arguments for why these underrepresented images should be removed from the project. It is also important to again emphasize that this does not mean that Wikimedia will turn into Deviant Art or an image host. All other policies and rules regarding content would still need to be followed, it just would require an actual argument as to why a questionable file doesn't belong beyond just relying on the crutch of it needing to have "obvious educational use".
  • In addition, I contend the example in question does not actually support the policy it is supposed to represent. The policy as currently written is Must be realistically useful for an educational purpose and "educational" is defined according to its broad meaning of "providing knowledge; instructional or informative". There is nothing about the use being obvious.
  • Given these points and the argument summarized above, I think it is reasonable to change the example Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills to something that does not include obvious or even remove the example entirely. Here are some options:
    My suggestion:
    1. Remove the example entirely.
      Suggestion from @Colin:
    2. Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills.
      Suggestion from @El Grafo:
    3. Artwork without educational use, including non-educational artwork uploaded to showcase the artist's skills.
      Suggestion from @Christian Ferrer:
    4. Self made artwork without obvious educational value, without illustrative interest, or without any visual qualities, including non-educational artwork uploaded to showcase the artist's skills.
  • I think any of the above changes would benefit the project, though I would prefer one without "obvious" in it. ~ PaulC/T+ 16:51, 17 March 2018 (UTC)

Proposal to rename account creator group to batch uploaders[edit]


Per COM:VP#Abolish the 380 images upload rate for non-admins, high content contributors can on occasion run into the 380 uploads per 72 minute rate limit. The right that overrides this is noratelimit. This right is currently assigned to admins/'crats/stewards as well as the account creator and bots groups. Currently there are only two account creators and Effeietsanders. This right is also only assignable by stewards at meta. This right is only assignable by 'crats or by stewards at meta.


  • Rename the account creator group to Batch uploaders
  • Add the ability to add and remove the group to the administrator group
  • Both of the current account creators are trustworthy enough to be grandfathered into this new group.


  • Batch uploaders need to show that they understand copyright through a history of good uploads.
  • Individuals looking for this right should show that they have use for it by having a history of batch uploading (via Flickr2Commons or similar gadgets).
  • A 10,000 edit minimum was mentioned at VP but I'm not all that convinced that that is necessary (please discuss this below).
  • A simple request at COM:PERM detailing why you need the right can be made for this flag.


  • Symbol support vote.svg Support As proposer. --Majora (talk) 03:29, 27 January 2018 (UTC)
  • Fully supported, note: while name change can be simply done by changing group name via MediaWiki NS config, granting/revoking permissions to sysops (currently 'crats) require config change. (I can do this. Just FYI.) Sysops, global rollbackers, stewards, crats, does not require this flag. — regards, Revi 04:17, 27 January 2018 (UTC)
  • Symbol support vote.svg Support   — Jeff G. ツ please ping or talk to me 23:42, 28 January 2018 (UTC)
  • Symbol support vote.svg Support, this is good. Artix Kreiger (talk) 02:08, 29 January 2018 (UTC)
  • Symbol support vote.svg Support As one the few people with this right, I'd like to point out that it makes very little difference to uploaders. I believe the 380 image limit has almost nothing to do with this right, based on the fact that I uploaded over 3 million images without running into the limit before being given the 'noratelimit' right. It might be that the problem needing solving (380 limit) is a bit tangential to waiving limits, and is probably better solved by such a person reading up on how to use GWT or similar tools. It should remain an extremely rare request based on need, and my need was based on moving pages not uploading images, plus I probably can be considered trusted to take a great deal of care over how fast I run mass actions or automation. Very, very few people have a good reason to exceed the normal limit of, I think, 8 images per minute upload - that includes almost every batch upload project I can think of. This basic upload limit means that an upload of 100,000 images takes just over a week. If someone wants to upload, say, a million images in a day or a week, that should require a proper community discussion and some testing before such a remarkably fast run that could make a huge mess even if highly experienced uploaders are doing it. Sorry to dampen the parade, but anyone requesting this should be able to demonstrate that they really do seriously know how to run a Commons project, and having a minimum 10,000 edits as a precursor would be a trivial part of that. -- (talk) 22:11, 29 January 2018 (UTC)
  • Symbol support vote.svg Weak support I say this as someone who doesn't see a need for this right personally. If someone wants to upload 100,000 images this can already be done in over a week as Fæ at aptly pointed out. So saying this will unleash mass uploads wouldn't be right. If someone wants too they will find a way. My real concern is for License Reviews being flooded with images. More then once I've spent the better part of an afternoon doing LR's, checking them each and following policy until I wake up the next morning and there are more then a thousand new images needing review in the PD images alone. As long as Fæ's words are taken to heart "It should remain an extremely rare request based on need" then I wouldn't have a problem with this. Honestly I'd rather see this limited to License Reviewers but I can see how this would be useful to some who have no interest in helping review licenses. -- Sixflashphoto (talk) 23:09, 29 January 2018 (UTC)
  • Symbol support vote.svg Support This will probably also reduce the huge backlog at requested batches. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 11:54, 30 January 2018 (UTC)
  • Symbol oppose vote.svg Oppose in this form. "Batch uploader" is just as misleading as the current "account creator" name, as this user group also has some other limitations lifted that are not related to batch uploading or account creation (see answers to my question below). However, I'd Symbol support vote.svg Support a re-name to another, more suitable name. As noratelimit seems to be the only user right assigned to this group, why not simply use that for naming the group? --El Grafo (talk) 13:01, 1 February 2018 (UTC)
    You are correct. The name is completely irrelevant. The most important part of the proposal is assigning the ability to give and remove this right to admins and the actual requirements for obtaining the right. The name is secondary and noratelimit seems like a fine group name in my opinion. I just didn't want to change the header and actual proposal halfway through since people have already opined. --Majora (talk) 21:56, 1 February 2018 (UTC)
    The new name sounds a lot better if it's "Noratelimit" as that name would simply explain exactly what it does. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:53, 10 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose, I think it is a bad idea to get rid of dedicated account creator group at least until there is a better solution provided for wikimarathons (such as a userright allowing to lift throttle for a specific IP from wiki interface on spot). I realise that the current history of actual usage of account creator group is small, but nevertheless. I am absolutely Symbol support vote.svg pro a separate mass upploader flag. I realise that technically they will contain the same userrights, but I think semantics and entailment of different requirements for obtaining and usage matter. --Base (talk) 17:52, 11 February 2018 (UTC)
    Would you rather it just be called "noratelimit" and it apply to both situations, Base? This would also allow normal admins to apply and remove it. As opposed to the current situation of 'crats and stewards. Having two user groups with the same rights but different names seems a tad overkill. --Majora (talk) 00:55, 13 February 2018 (UTC)
    we already have an example. German wikipedia already has two group example. de:spezial:listgrouprights shows account creator and a "noratelimit" group that has the same user right. Artix Kreiger (talk) 01:16, 13 February 2018 (UTC)
    Look again. They have different rights. The "Limit Except" group also have autopatrol. And I stand by my statement. Even if the Germans did do that, which they don't, I find that a tad excessive and a waste of developer time to put that into the configuration when you can just call it something more general and catch all. --Majora (talk) 01:19, 13 February 2018 (UTC)
    That is certainly an option to have a group called 'noratelimit' and have to separate sets of valid ways to get it — huge number of good faith contributions as proposed for the mass uploader group and evidence that user is involved in conducting some workshops (e.g. an active affiliate member) and has good enough understanding of policies while might not have a huge number of uploads themselves. That being said I personally prefer two flags option or Nemo's variant of lifting upload rate limit for non-new accounts (or even all accounts arguably). As to developers' time, come on, what are you talking about. Creation or changing rights is a matter of editing MW configuration file, and it is even possible to do it right on Gerrit. --Base (talk) 13:26, 17 February 2018 (UTC)
  • I'd rather remove the rate limit for uploads than enshrine upload castes in user groups. --Nemo 13:34, 13 February 2018 (UTC)
    • Symbol support vote.svg Support large amounts of abusive uploads only exclusively happen with new accounts and can easily get mass-deleted with the current tools, there really isn't a use for the current rate limit, nor does it currently stop malicious bots from uploading a lot of bad content, I think that the only people ever disadvantaged by the current rate limit are good faith uploaders, if I'm wrong than anyone can feel free to correct me, but I can't remember the last time that I saw a malicious uploader upload a large amount of files, it's usually that they use Wikipedia-zero to upload films and such which only account for a single file 📁 each, despite their size. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:16, 14 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose expansion of privileges of sysops (see also Fæ’s comment) – Commons has currently 8 bureaucrats. At least, do not allow sysops to turn on this privilege. As for naming, see the subsection below. Incnis Mrsi (talk) 07:31, 27 February 2018 (UTC)
  • @Incnis Mrsi: Do you support the proposal without the expansion of sysop privileges or still an oppose regardless? Looking for clarification for consensus. ~riley (talk) 05:33, 6 March 2018 (UTC)
  • If granting this right will be strictly controlled and abuses promptly curbed, then I do not oppose anything. Let users with more experience in the field decide now to name this user group. Incnis Mrsi (talk) 09:09, 6 March 2018 (UTC)


Question. has the account creator group been used in upload marathons? Artix Kreiger (talk) 03:35, 27 January 2018 (UTC)

Since 2004 the right has been assigned a total of 8 times. Information per --Majora (talk) 03:41, 27 January 2018 (UTC)
The German Wikipedia has a right just called "noratelimit", aside from account creator. Would that be something to consider? also, special:listgrouprights says that bureaucrats can assign account creators. Artix Kreiger (talk) 04:08, 27 January 2018 (UTC)
Well then. COM:Account creators lied to me. I've modified the background and I'll have to do some more research to see if this right was ever assigned here by 'crats. Give me a moment. --Majora (talk) 04:13, 27 January 2018 (UTC)
(Edit conflict) Yes. It was assigned twice here by a 'crat and removed twice by a 'crat. One of which was a self-change (by a 'crat to themselves). So it has been assigned a total of 10 times either here or on meta since 2004. My personal view on the matter is that a right called "account creator" isn't all the necessary here on Commons. We aren't creating accounts here. The only useful thing is the rate limit override and having two different group with the same set of rights seems a little silly. The idea of a "batch uploader" group on a project that deals with multimedia uploads seems much more logical. I'd also be ok with just changing the name to "noratelimit" and be done with it. --Majora (talk) 04:21, 27 January 2018 (UTC)
(Edit conflict) Yes, crats can do it, and there was new accountcreator this month. I think renaming accountcreator to something 'noratelimit' blah blah would be sufficient. — regards, Revi 04:17, 27 January 2018 (UTC)

Pictogram-voting-question.svg Question What's the "normal" purpose of making someone an "account creator"? Commons:Account creators says "The account creator user right alleviates restrictions in relation to creating new accounts." What exactly does that mean? That doesn't sound like something a batch uploader would need? --El Grafo (talk) 13:46, 29 January 2018 (UTC)

I think there is a rate limit on how many accounts you can create. I don't know number. However, it gives the noratelimit which removes rate limits of everything, not just accounts. — Preceding unsigned comment added by Artix Kreiger (talk • contribs) 20:48, 29 January 2018 (UTC)
@El Grafo: There are various speedrate limits, to protect wiki from users (with good or bad intention) changing stuff too quickly. One of them is account creation limit, others include move limit (including file move), rollback limit, etc etc. — regards, Revi 16:44, 29 January 2018 (UTC)
Right. The name of the group doesn't really mean anything. You have to look at what rights are assigned to that group to really understand what someone could do with it. The only thing assigned to account creators is the noratelimit right per Special:ListGroupRights. That is what would be helpful for individuals who batch upload large amounts of files. --Majora (talk) 21:55, 29 January 2018 (UTC)
@El Grafo: Wikimedia projects only allow 6 new accounts to be created per IP address per day, Account Creators can also bypass the blacklist and create accounts with similar names to existing usernames. This right is essential if you are running Wikimedia events (i.e. workshops) and will be having several people creating accounts in one day or if you assist with the Account Creation process for people that cannot read CAPTCHAs, have a name that hits the blacklist (i.e. JamesSteward; steward is blacklisted) etc. ~riley (talk) 05:38, 6 March 2018 (UTC)
I don't think that is true on this project ~riley. Per Special:ListGroupRights the only right account creators currently have is the rate limit bypass. The ability to override the blacklist is contained within the tboverride right. Which account creators on this project do not have. Account creators on other projects do have that right however. --Majora (talk) 05:44, 6 March 2018 (UTC)
Oh and the ability to override the similar name check is the override-antispoof right. Just for reference. --Majora (talk) 05:47, 6 March 2018 (UTC)

@: You have license reviewer, and license reviewers have different upload limit (virtually none) — regards, Revi 02:40, 30 January 2018 (UTC)

Yes, though I cannot remember any issues before having 'image reviewer' and it may have come without other rights back then. It seems a long time ago. -- (talk) 09:08, 30 January 2018 (UTC)


Discussion extended: 30 days to gain further community consensus due to current lack of community input. ~riley (talk) 23:22, 26 February 2018 (UTC)

Wiki Loves Transportation[edit]

I suggest to create a new annual event. Wiki Loves Transportation - a competition of photos of cars, trucks, buses, locomotives, vessels, airplanes, other vehicles etc.
Why it is important: vehicles have the short term of active use. Old models are utilized (scrapped) and replaced with new.
We can keep images of vehicles for history.
Please, add Your comments and vote below. --George Chernilevsky talk 19:28, 30 January 2018 (UTC)

  • Symbol support vote.svg Provisional Support I would be all for this but it would require a lot of organization. For instance, in which countries would this take place? Wiki Loves Monunments and Wiki Loves Earth are country/regional specific. Who would judge? How would it be organized? I could think of more questions but I believe I have established my point. Don't misunderstand me, I think this is a fine idea, I just would like more details. -- Sixflashphoto (talk) 20:07, 30 January 2018 (UTC)
  • Symbol support vote.svg Support, For this, organization needs work and scope needs refinement before things happen. Aside from that, this is a good idea to work with for information. Natural progression of change should be documented and will serve people well. Artix Kreiger (talk) 00:48, 31 January 2018 (UTC)
  • Symbol support vote.svg Support, I regularly upload images of vehicles (though as I am not knowledgeable in most brands and their sub-categorisations I refrain from seeking them out), and it's quite common for vehicles to be missing. I also suggest a competition for “corporate vehicles” (which might now be deleted as “spam” or “obvious COI’s”, but as many companies go bankrupt these images could serve as historical preservation), or training vehicles (another category horribly underrepresented). Most automobile 🚗 models are notable enough to have entries on various Wikipedia’s, but it's quite common for there to be almost no images of a certain model here so giving people more incentive to photograph more vehicles (or just photograph more in general) is always a win 🏆. --Donald Trung (Talk 💬) ("The Chinese Coin Troll" 👿) (Articles 📚) 08:51, 1 February 2018 (UTC)
  • Symbol support vote.svg Support Christian Ferrer (talk) 17:34, 1 February 2018 (UTC)
  • Symbol support vote.svg Support I like this idea very much. Also I hope to see some writing contest about railway which is interesting for me. --Visem (talk) 19:37, 1 February 2018 (UTC)
  • Symbol support vote.svg Support I like the idea. Fully supporting this! — D Y O L F 77[Talk] 02:13, 2 February 2018 (UTC)
  • Symbol support vote.svg Support Good idea. De728631 (talk) 04:21, 2 February 2018 (UTC)
  • Symbol support vote.svg Support Good idea. Second International wiki-project from Ukraine. :-) --Nickispeaki (talk) 17:51, 3 February 2018 (UTC)*Symbol support vote.svg Support
  • Pictogram voting comment.svg Comment Who's going to do all the category cleanup? Transportation images tend to have a more complex and detailed category structure than much of the rest of Commons. For example, identifying the model of an automobile is a difficult task. This sounds like something that will end up with a lot of images in top-level categories, making them not particularly useful, unless there is a great deal of organization to ensure good category sorting. Pi.1415926535 (talk) 19:32, 3 February 2018 (UTC)
  • Pictogram voting comment.svg Comment I agree with Pi. There are all sorts of subjects that individuals love and could base a project on. On the small scale, I think Photo Challenge would be more appropriate, especially if you pick just one category (e.g. scooters). The "Wiki loves" is on the other scale and can involve a huge amount of volunteer effort. Even though WLM does generate a large number of images, in some countries the results are disappointing such that for all the effort put in locally, a year's competition produces not even one image worthy of FP. I don't know about other countries, but in the UK WLM is aided as the historical buildings are already plotted on a map so you can click on it and upload and it will be identified correctly. Even for less advanced systems, it is usually not hard for the photographer to state correctly what building they are looking at. Whereas I wouldn't have a clue which model of train engine or bus I see, and while I can identify a modest number of cars, I wouldn't be specific enough to know it was the 2011-2015 model, say, and there are plenty people who's identification abilities go no further than "red car". Add to this the problem that reviewing/judging the candidates can be a long and tedious job. It is fine if the quality is high and there is variety, but if we lack both then it becomes very dull. Some people on WLM just seemed to upload their camera's memory card. For transport, I could see someone standing beside the road snapping everything that went by and uploading all of that. Perhaps the first step would be to create some kind of WikiProject Transport for Commons where you get enthusiastic people together and encouraging each other. That may be sufficient, and may also help to set some standards, both in terms of documentation and approach to photography, but also standards of what quality and style of image we best need. -- Colin (talk) 08:15, 15 February 2018 (UTC)
  • Pictogram voting comment.svg Comment I think it doesn't make sense to !vote on this until some interested people have spend some time to actually work out a concept. Until then, I'll remain sceptical, as I share the concerns expressed by Pi and Colin above. What could work, though, is focusing on immobile transport-related objects such as train stations or aerodromes. They are easily identified by non-enthusiasts; and there are lists available that could be used in a similar way as monument lists are used for WLM. --El Grafo (talk) 16:15, 15 February 2018 (UTC)
  • Suggestion: why not have a transportation photo challenge at Commons:Photo challenge every year or 6 months? --P 1 9 9   21:12, 16 February 2018 (UTC)
  • Symbol support vote.svg Support, there are lots of existing photography groups who like taking photos of trains, cars, planes etc that could be engaged who probably have very large back catalogues. My experience is that people who like taking photos of transport tend to know the names of makes and models so I can't see a huge amount of images being added to top level categories, I guess there will need to be some work on creating new categories for new things we don't have photos of. John Cummings (talk) 14:47, 21 February 2018 (UTC)
    • John, that's the thing, though. People who are already motivated to photograph and accurately record transport don't need WLT, though they might enjoy a wiki project. Huge WL* competitions just attract thousands of noobs and would indeed fill the top level categories and also end up with images in proportion to the popularity of a vehicle rather than in proportion to how much Commons lacks that model. Large competitions need to be designed to create optimal content, whereas I suspect this will actually decrease the average quality of transport images on Commons. -- Colin (talk) 19:12, 21 February 2018 (UTC)
@Colin:, this exactly my point, a very small percentage of photographers contribute images to Commons, attracting 'noobs' (new contributors who may already accomplished photographers) is very good way of getting more images and the only way to grow the community. They are unlikely to 'fill up' top level categories, more create new ones for content we don't yet have images of. The success of the competition very much depends on who takes part, there are many existing communities who can be engaged with excellent images. John Cummings (talk) 19:33, 21 February 2018 (UTC)
And WLM achieved that? If you exclude the Commons regulars who contribute to WLM, and who would have contributed anyway, the quality of photos is generally poor. You get a handful of serious photographers who enter the competition with (usually downsized) images but don't contribute anything else. They treat it like someone entering any competition with half a dozen photos and then forgetting about it till next year. WLM made identification easy, whereas this makes accurately recording the subject (a vehicle) rather hard. I couldn't tell you accurately what precise model my own car was. Photo challenge is more successful at attracting and retaining noobs and it only needs a few people to run and organise it, rather than hundreds, and there's no prize money. -- Colin (talk) 21:43, 21 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose I'm not a fan of all this inflationary "Wiki Loves..." copying (there is plenty of, but none of that has ever been as successful as Monuments; not even Earth). But who actually says that Photo Challenge topics cannot be repeated? Just run transportation challenge one time each year, that's the same. --A.Savin 14:57, 25 February 2018 (UTC)

Portraits of Wikimedians[edit]

A proposal: each positively contributing Wikimedian has right to keep one photo of self on Commons, not necessarily used on any wiki page within Wikimedia. Sufficient conditions for “positive contributions” should be one C-class (at least) article or few dozens good essential edits (not just spelling/grammar fixes). Here was a portrait of the guy who wrote Anumantharayan Kottai. Not really a huge contribution, but let’s stop, at last, this vandal deletionist DoS attack by the infamous troll condoned and even overtly supported by certain elements among legitimate Commons users. Which Wikimedia members does the community respect: those who build something, or those who destroyed others’ works and made provocations during their career? Incnis Mrsi (talk) 19:27, 16 February 2018 (UTC)

So you want to modify COM:INUSE? I'm perfectly fine with allowing personal images if they are used on user pages for identification purposes. That has long standing agreement and I'm all for that. I also for making exceptions. This particular case seems like a tad much though. If I'm getting everything right you are talking about Lalwilson007 who has all of four edits to Commons and a total of 16 edits across all projects. Tying it to article ratings is also not really going to work as those are not monitored and completely subjective based on the whims of whomever rates the page. I understand the DENY aspect of trolls. And to be honest, I'm not really all that comfortable with someone else taking over their requests. But that doesn't mean we should stop all such requests. Else the trolling can cause a lot more damage the other way. In short, if a legitimate user brings this to the attention of the greater community I'm not quite sure I'd agree with your point of view here. The photo wasn't even in use and it doesn't appear that the person has edited any project since May of last year. Again, I'm all for making exceptions but not really in this case. Blanket changes to policy like this are probably not the best option here. If you come up with a more tailored approach I'd probably support. Sorry. --Majora (talk) 19:46, 16 February 2018 (UTC)
  • Oppose. If a personal photo is not used in any wiki, what possible purpose does it serve then? --P 1 9 9   21:19, 16 February 2018 (UTC)
    If a photo is described correctly and categorized, then it can be found. It can be used now to make some impression of Wikimedia contributors and their diversity. Moreover, it will be of great use for future wiki archeologists (we can’t be sure whether deleted Wikimedia files or pages will be kept in databases indefinitely). Which purpose serve files, for example, from this category? Have they necessarily to be arranged in a gallery to be deemed useful? Incnis Mrsi (talk) 21:37, 16 February 2018 (UTC)
  • Symbol support vote.svg Support, coincidently I wrote User:Donald Trung/Proposal on how to deal with personal images a couple of days earlier to propose here. --Donald Trung (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:24, 17 February 2018 (UTC)
  • How would you know, when looking at a photo, if it's the only one? There are already a lot of unused personal photos of Wikimedians, often large collections of them, which seem to be considered in-scope, e.g., if they are taken at a Wikimedia event, photos like File:Wikimania 2013 by Béria Lima 39.jpg, to pick a random example. --ghouston (talk) 03:14, 18 February 2018 (UTC)
    Mistakes due to incomplete information can happen. Had we a good-quality photo of Lal wilson J, I wouldn’t consider deletion of a portrait of him an indignified treatment of a Wikipedia contributor. But while nobody can present any evidence that Lal wilson J attended events extensively covered by Wikimedia, we should deem this photo very probably was unique. Incnis Mrsi (talk) 09:27, 18 February 2018 (UTC)
  • Pictogram voting comment.svg Comment The amount of personal images uploaded to commons in a given day and not in use, or connected to a user page with no edits outside of that user page, in essence using commons as a webhost for personal files vastly outweighs the amount of personal files uploaded by active contributors regardless of the metric of "active" -- Sixflashphoto (talk) 19:41, 20 February 2018 (UTC)
    @Sixflashphoto: you appear to get the point missed by P199. Indeed, a vanity-only user may upload a portrait, set up a user: page and, if that page is not blatantly promotional, this portrait will linger indefinitely. Whereas a portrait of Lal wilson J was deleted on the INUSE technicality thanks to the troll’s activity. Incnis Mrsi (talk) 20:24, 20 February 2018 (UTC)
I agree with P199. If a personal file is uploaded by a user who is not active in any project it should be deleted. We are not and should not be a social media site. I nominate a lot of personal files for deletion, I just don't nominate any in use in any project. Personal files from vanity uploaders are not within the scope of the project. Really a lot of this could just be soled by carefully checking a DR before closing it as Delete. For instance say someone uploades a file having no contributions and not connecting the file to any project whilst within the week starts making a large amount of good edits to a project and connects the file to the User page. The nominator was not wrong for nominating the image (but should withdraw the nomination if new facts are presented) but the file should still be kept. As far as Lalwilson007, this user has 16 total edits across all projects-on en:wp only 3 were in the mainspace and on commons 1 file was not a photo of a person. The 2 photos of a person are not in use. This is not the hill to die on. Your other 2 case studies are better. -- Sixflashphoto (talk) 20:52, 20 February 2018 (UTC)
Meh, or apply commonsense, stick to being Mellow, and not delete everything it is possible to delete, especially when an inactive user seems to have always acted in good faith and the releases are correct. I'm pretty good at guesstimates, I'd say we were talking about perhaps 0.03% of the images on Commons might be described this way. If anyone wants to seek out media to delete, how about focusing on copyvios that are a problem that is a thousand times larger? -- (talk) 21:07, 20 February 2018 (UTC)
  • Oppose as written, but agree that it would probably be sensible to introduce a new CSD criterion (i.e. F10) which would allow for:
F10: deletion of personal images either unused or used only by a single user's namespace (in any number of projects), if that user is not also autoconfirmed in at least one project. This would be a minimum threshold, obviously, and others may be suitable for DR rather than CSD, but the objective criterion combined with existing definitions of "personal image" would likely cut down on a lot of the social media-style content we see uploaded on a daily basis. It also operates under the assumption that the autoconfirmed user right is implemented on most, if not all, projects (I believe it's a MediaWiki default, but could be wrong). — Rhododendrites talk |  00:50, 21 February 2018 (UTC)
@Rhododendrites: It appears to be a WMF default, please see the last paragraph of m:Registered user.   — Jeff G. ツ please ping or talk to me 02:21, 21 February 2018 (UTC)
Most projects define an autoconfirmed account as "existing" for four days. No edits required. I'm not entirely sure that is a good threshold here as it requires nothing more than an account on one of the projects that give out autoconfirmed that way. --Majora (talk) 02:40, 21 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose the actual policy is fine IMO Christian Ferrer (talk) 18:36, 21 February 2018 (UTC)
    The actual policy is a disgrace for “obscure” Wikimedians, a loophole for vanity mongers, and a boon for trolls. An irresponsible approach; especially sadly to see it from a Commons admin. Incnis Mrsi (talk) 19:19, 21 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose yet more deletion drama - don't trust DR? don't want a consensus? "this" is a disgrace? i guess we have different views of what commons should be ashamed. Slowking4 § Sander.v.Ginkel's revenge 14:07, 23 February 2018 (UTC)
  • Pictogram voting comment.svg Comment @Incnis Mrsi: I would suggest something different. No strict "1 picture" limit, but a FUP. Users who have contributed a lot could have more non-educational images than new users. In addition: if a user decides to upload a photo of themselves, they must (also) upload one photo on which we can see the user is aware of Commons. This could be achieved in various ways, for example the user could write "Commons" on their hand and make a selfie which includes that hand, or we could agree on some hand gesture. But there is an infinite number of ways. I don't want another Ameily Radke. Admittedly this won't make any difference for existing images. - Alexis Jazz 18:38, 23 February 2018 (UTC)
    Alexis’s concern about “… es vato” pictures is grounded on personality rights and privacy. I advocate another cause, namely, to stop disparaging and disrespectful treatment of genuine Wikimedia contributors—who have hence a low probability to commit deliberate privacy violations and hoaxes. Whereas photoshops uploaded—with unspecified sources—by blatantly promotional zero-merit accs are frequently kept by certain sysops. Incnis Mrsi (talk) 18:58, 23 February 2018 (UTC)
    Partially. I may not have been completely clear, but if there would be a photo included on which it is made clear the person pictured is aware of Commons (or, for example, a photo exists of a Wiki meeting that also shows the person) that would make the pictures of that user ineligible for deletion, within a FUP. So it also achieves part of what your goal is, it just offers no solution for all the images from abandoned accounts uploaded so far. To be honest I'm not sure how useful it is to have those images around. I see no reason to delete them (they are not removed from the WMF drives, they still take up space) but I can't think of any good reason to keep them either. May I ask: why should such images be kept? If there is a good reason (for example, if the trolls are partisan when nominating abandoned pictures) I may support your proposal. - Alexis Jazz 19:27, 23 February 2018 (UTC)
  • Perhaps 1 unused personal photograph per 100 or 1000 edits? Anyhow I would Symbol support vote.svg Support this as the policy needs updating. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:26, 6 March 2018 (UTC)

Proposal to explain the official view of Commons regarding photos on coffins in the de minimis policy[edit]

It's quite common for a photo to be placed on a coffin, but it's not clear to me if Commons considers that photo in a photo of a coffin-with-photo to be DM or not. In more clear words: I mean the case where somebody makes a free photo of a coffin, but there is a photo placed on top or near of the coffin which can be seen as well and which is nonfree. I would find it useful if the de minimis policy would deal with this. - Alexis Jazz 00:12, 23 February 2018 (UTC)

I don't think we should add that in the policy. It depends very much on the original picture, and how the photo of the coffin is taken. We should just use common sense (and if you are the photographer, do not focus on the original). Regards, Yann (talk) 04:14, 23 February 2018 (UTC)
I agree with Yann. Generally such photos are de minimis, but the uploader can also decide to blur it or mask it in a similar way. --Ruthven (msg) 10:16, 23 February 2018 (UTC)
Alright. But perhaps a note in some form could be added. I personally feel it is generally disrespectful to remove/blur the photo from such images. In a similar image that shows a photo in the image with similar size and focus but where the subject is a book signing instead of a funeral, I don't have many issues with removing or blurring the photo. It is quite common for photos to be placed on or near a coffin and photos taken of coffins are typically in scope. I think we should be slightly more lenient in allowing them as DM. I'd be OK with making the {{de minimis}} template a requirement for that. My point is that if we are just as strict on these coffin photos as we are on (for example) photos of book signings, it could be hard for Commons to continue hosting funeral photos. I believe we already are more lenient on this subject and I would like to see some sort of note on this in the policy. I agree no universal ruling could be developed, I'm not asking for that. - Alexis Jazz 11:00, 23 February 2018 (UTC)
I agree that picture is less likely to be within the scope of DM. I added DM to it anyway because it's not the main focus of the image (to me) and to inform anyone who wants to reuse it. If somebody nominates that file for deletion I won't strongly defend it: it is not used and we have similar photos of the same funeral that focus less on the coffin photo. So from an educational point of view, we don't really need it in this case. - Alexis Jazz 11:00, 23 February 2018 (UTC)

Merge the function of two templates[edit]

Can we import the unique functions of {{PeopleByName}} into {{wikidata person}}, they duplicate a lot and it would be best to just have one template to add to a new biographical category. Wikidata person can become {{wikidata person|Q2092869|McGillivray|Perry}} By adding the sortkey function of PeopleByName to wikidata_person. We can skip the adding of "M" and "F" and import the gender from Wikidata. PeopleByName adds a sortkey on the fly "McGillivray|Perry|M" and one or two categories currently missing from wikidata_person. They both generate categories based on Wikidata information on the fly, as opposed to typing them in, so that when Wikidata is corrected the categories are automatically updated, the categories aren't really there when you hit the edit button. Wikidata_person was recently updated with functions from other templates and was originally based on template:Creator. The template wikidata_person and the information at Wikidata have recently improved image search on Google by including more biographical data in the categories, especially for people with commons names. Google Image distinguishes better John Smith, the baker from John Smith, the barber. RAN (talk) 19:09, 23 February 2018 (UTC)

@Richard Arthur Norton (1958- ): Or there's {{Wikidata Infobox}}. ;-) I've now added support for all of {{PeopleByName}} using info entirely from Wikidata, see [1] for an example of it in action. So if the category has a sitelink on Wikidata, and the relevant info is in the Wikidata entry (sex or gender (P21), given name (P735), family name (P734) at least, date of birth (P569) and date of death (P570) for the full set), it should just do everything by adding {{Wikidata Infobox}}. If there are any problems, please let me know and I'll look into them. Thanks. Mike Peel (talk) 22:45, 23 February 2018 (UTC)
@Richard Arthur Norton (1958- ): P.S. if the category isn't linked to the Wikidata entry, then you need to make an edit like [2] to link it. Category:Willard Dickerman Straight should work now. ;-) Thanks. Mike Peel (talk) 23:08, 23 February 2018 (UTC)
Excellent work. {{Wikidata Infobox}} is more vertical and {{wikidata person}} is more horizontal, each good in their own way. Are you going to update {{wikidata person}} also with your category and sort key changes? {{Wikidata Infobox}} now performs all the functions you would need when you create a new category. Now when Wikidata is updated, the categories will be adjusted, we have over 10,000 records where we have only the year of birth for a person, and roughly half of them are off by a year. They are generally calculated from the person's age in an obituary, when the exact birth is unknown. RAN (talk) 23:22, 23 February 2018 (UTC)
Thanks. :-) I'm not planning on editing {{wikidata person}}, but you can see the code I wrote to do the {{PeopleByName}} include at [3], maybe @Jarekt: would like to incorporate it in {{wikidata person}}. Personally, I'd like to merge that template into {{Wikidata Infobox}} at some point, as I think the latter is formatted better and it also works with categories that aren't about people, but we need to discuss that. With regards vertical and horizontal, personally I don't care, but I think we should standardise on one of the two and use that uniformly in categories. Thanks. Mike Peel (talk) 23:34, 23 February 2018 (UTC)
RAN, {{PeopleByName}} and {{wikidata person}} are quite different. {{PeopleByName}} is meant to be substituted and {{wikidata person}} does not. Also adding extra parameters to {{wikidata person}} would make it much harder to use, as it's main feature is that it does not take any inputs other than item ID. I do not want to add surname and given name categories as they are added only if such categories exist. The code would have to be constantly checking that. I also do not like gender based categories, like Category:Men by name and would prefer not to use them. --Jarekt (talk) 05:36, 24 February 2018 (UTC)
Then why do we have {{PeopleByName}} and why do people add it to categories? We need to be consistent so when people look at a list everyone they are looking for is included. If we should not have gender specific categories, then we should get consensus to delete/retain them. If the surname category does not exist, it takes about 7 seconds to make it a subcategory of Category:Surnames and the red link is now blue. {{wikidata person|Q2092869|McGillivray|Perry}} is no needed, Mike Peel cleverly coded the sort key based solely on the Wikidata Q number in {{Wikidata Infobox}}, the vertical version of the category infobox. Men by name and Women by name, honestly no one actually uses it to search for a person, it is there more for web crawlers than actual human utility. RAN (talk) 05:49, 24 February 2018 (UTC)

Don't notify a user if their edit on a user talk page is undone by the owner of the talk page[edit]

When an edit on a wiki is undone, it usually means you've done something wrong. Or someone else before you did and your edit was part of the rollback as well. It makes sense to notify the user so they can try to figure out what they did wrong, or see if they need to re-add an edit that was collateral in a rollback.

Some users have a habit of using the "undo" function as a way of a "got it, archive to nowhere" button. Which is perfectly fine except the user who made the edit or made the DR for a file that the user uploaded gets a useless notification that their edit was reverted. For new users who are not familiar with this practice this could also lead to confusion - have I done something wrong? Should I not have nominated that file for deletion?

Notification for an undo/rollback on a user talk page is always useless. If it's a user saying "got it, archive to nowhere" there is no need to notify. If a user has done something very wrong on a user page, a message should be left on the talk page of the offending user to explain what they did wrong. That is if it's not taken straight to the vandalism board. The undo notification is useless for either case.

An alternative is to create an extra "got it, archive to nowhere" button. I think that'll just add to the clutter so disabling the undo/rollback notification when an edit on a talk page is undone by the owner of the talk page makes more sense to me. But I would be happy with either way. - Alexis Jazz 04:56, 24 February 2018 (UTC)

I agree the notification for rollback/undo is disruptive for many wiki practices. I always disable it. It tends to encourage edit wars too, so I wouldn't oppose a feature request to disable it for all users on Commons. Would somebody miss it and why? --Nemo 14:41, 24 February 2018 (UTC)
I know of a good few editors who have disabled revert notifications for that very reason. They feel that the 'red-mist' these messages can inspire may make them more likely to edit-war or respond rashly, so they prefer to just rely on the watchlist because they feel that results in more sedate, considered responses. At least a couple of them, which I recall, have also said it's been "the best thing they ever did with notifications" or something similar. I can see their point, too, but I think it should remain a matter of personal choice for those like Jeff below, who prefer to receive them. I leave them switched on myself. -- Begoon 16:04, 24 February 2018 (UTC)
@Alexis Jazz, Nemo bis: Use of rollback against community translated templated user talk page messages on one's user talk page that are not clearly mistaken or self-generated (that is, constructive edits) is actually misuse per COM:RB (as such implies that the original messages were vandalism), and could result in loss of the rollback permission via COM:AN or the action of a single Administrator. I certainly want to be notified if someone else rolls back my such messages, but I don't care so much when someone undoes them, which action would just be antisocial and obfuscatory.   — Jeff G. ツ please ping or talk to me 15:10, 24 February 2018 (UTC)
Antisocial and obfuscatory to remove a templated message which one has read? Sometimes I can do nothing but shake my head at the things I read here. -- Begoon 15:56, 24 February 2018 (UTC)
I don't think that's what Jeff meant. If you edit the page and remove the message that way to perform the "archive to nowhere" I doubt anyone would have any problem with that. That will not send a notification and is also not tagged as "undo". And "undoing", at least from the outside, really seems like making something like it was never done. I know you don't mean it that way, but it can come across like that. Especially to users who are not familiar with how "undo" gets used here. - Alexis Jazz 17:13, 24 February 2018 (UTC)
Yeah, well that may be a fair point - I suppose I'd rather not trigger a notification in those circumstances and potentially upset or confuse someone. That covers "antisocial", in a way, and a couple of extra clicks is no issue. But hang on, now I'm being even more "obfuscatory" aren't I, by doing it quietly? My head is shaking less, but it's not completely still yet... -- Begoon 17:32, 24 February 2018 (UTC)
Ideally you would also enter "Got it, thanks" in the edit summary. Perhaps it's possible to create a script that saves a few clicks and keystrokes to do that. - Alexis Jazz 17:43, 24 February 2018 (UTC)
Ideally, yes, and I shall henceforth do it just like that. I do still have to say, though, that equally ideally folks would try not to throw around terms like "Antisocial and obfuscatory" and use some common sense - but we'll see how that goes... -- Begoon 17:52, 24 February 2018 (UTC)
Regarding Alexis' idea itself, it's maybe not altogether a bad idea, but I suspect that doing this solely for "own talk page reverts" might be difficult to "sell" as a concept in a feature request. It might be viewed (or "brushed off") as an overly complicated solution to a debatable problem. Nothing to stop someone asking, though... -- Begoon 16:14, 24 February 2018 (UTC)
If some people here would say "Yeah, makes sense" that would be a great support for a feature request. If everyone here is more like "meh", I don't see it happening. - Alexis Jazz 17:13, 24 February 2018 (UTC)

Proposal to bot-deploy Wikidata Infobox[edit]

Lovell Telescope 
Lovell Telescope 5.jpg
Radio telescope at Jodrell Bank Observatory, Cheshire in the north-west of England
Instance of Radio telescope,
parabolic reflector
Part of Jodrell Bank Observatory,
European VLBI Network
Named after
Location Cheshire East, United Kingdom
Heritage designation
  • Grade I listed building
Service entry 2 August 1957
official website
Authority control
National Heritage List for England number: 1221685

{{Wikidata Infobox}} displays a small box containing basic information drawn entirely from Wikidata, such as the one on the right for Category:Lovell Telescope. It is inherently multilingual - change the language you're browsing Commons in, and the info in the box will be shown in that language. It works in commons categories (and also galleries) that have a Commons sitelink on Wikidata, and it's been designed so that it should work for any subject (with a special switch to handle humans, including auto-categorisation through {{PeopleByName}}). It also sorts out interwiki links for categories linked to a Wikidata category item (through auto-including {{Interwiki from wikidata}} when needed). Suggestions for improvements and reports of bugs are welcome on the template talk page.

Since I started it just over a month ago, we've had a very positive village pump discussion about it, and it's now been manually added to over 1,000 categories across a wide variety of topics by a number of editors. We can continue to manually deploy it, but as it just relies on the existence of a Wikidata entry with a commons sitelink, we could also bot-deploy it to categories that have such a sitelink. We could either do that for all categories that have such a sitelink (which would be circa 2 million, as that's how many times P373 is used on Wikidata) - obviously, in steps, not all at once! Or we could pick category trees to add the box to, and do it one topic at a time. We can avoid categories that use other approaches (such as {{wikidata person}}, add it alongside other templates that offer similar functionality (e.g., {{authority control}}) and/or we can replace them with this one.

What does everyone think? I can write the bot code and start a bot request, if that's what we want to do, but we need to discuss it here first as this is a broad, and fairly fundamental, topic.

(pinging those that participated in the previous VP discussion: @Strakhov, DarwIn, Jheald, Pigsonthewing, Jmabel @ערן, Christian Ferrer, Rama, John Cummings, Jeff G. @Llywelyn2000, Donald Trung)

Thanks. Mike Peel (talk) 22:54, 25 February 2018 (UTC)

Symbol support vote.svg Support I like it. Useful, low-impact, and promotes Wikidata. Sebari – aka Srittau (talk) 23:13, 25 February 2018 (UTC)
Symbol support vote.svg Support Very useful, Mike is the right person to do it. John Cummings (talk) 23:20, 25 February 2018 (UTC)
Symbol support vote.svg Support It provides good information in a nice, standardized format. Currently, information on category pages are ad hoc and, as far as my experience goes, may be outdated. I am happy this possibility is being put forward, as I believe it really helps. I also like the maps a lot. Mike, full support to your bot request! --Joalpe (talk) 23:38, 25 February 2018 (UTC)
Symbol support vote.svg Support - Jmabel ! talk 23:52, 25 February 2018 (UTC)
Symbol support vote.svg Support, of course. I would also like to see discussion of merging with other templates: {{Wikidata person}}, {{Authority control}}, {{Object location dec}}, et al. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:14, 26 February 2018 (UTC)
  • I like it and I think Mike Peel did great. I have concerns with replacing templates that already use wikidata codes, because of some potential issues I shared with Mike Peel. Leaving aside that, I Symbol support vote.svg Support bot-adding {{wikidata infobox}} to categories not using "...wikidata person, wikidata place, authority control, objet location ..." right now. Merging them it's desirable in the medium term, but we can wait to see how the deployment develops, we are not in a hurry after all. strakhov (talk) 01:57, 26 February 2018 (UTC)
Symbol oppose vote.svg Oppose Warning: Default sort key ", Henri" overrides earlier default sort key "Demonchy, Henri". - Alexis Jazz 02:41, 26 February 2018 (UTC)
@Alexis Jazz: This one is now fixed. Thanks. Mike Peel (talk) 11:07, 26 February 2018 (UTC)
Symbol support vote.svg Support - it will translate into every language under the sun, it's useful, compact, without drawing attention to itself. Great stuff! Llywelyn2000 (talk) 06:19, 26 February 2018 (UTC)
Symbol support vote.svg Support The sort key issue has to be fixed, but I don't think it should not prevent the deployment. Regards, Yann (talk) 06:23, 26 February 2018 (UTC)
Symbol support vote.svg Support Generally this is good idea and would be nice to see short additonal info on the topic based on Wikidata using this template. We should take care when depoloying the issue Alexis pointed above - either skipping pages that contain keys for now with the bot, or merge it with the template as parameter. Eran (talk) 06:34, 26 February 2018 (UTC)
Symbol oppose vote.svg Oppose, supporters cut short this discussion but came here now. Incnis Mrsi (talk) 06:56, 26 February 2018 (UTC)
Symbol support vote.svg Support with reservations. You may carefully proceed with deployment, but may not refer to this proposal as to sanction to override objections mounted for each particular case (such as classes of objects where sorting is important). Incnis Mrsi (talk) 11:18, 26 February 2018 (UTC)
@Incnis Mrsi: This was about whether we should have local copies of the Q-numbers. I thought this discussion had run its course, particularly since using the sitelinks is computationally cheaper than using local qids, but we can continue it if you'd like - I'd suggest at Template talk:Wikidata Infobox rather than my talk page. Thanks. Mike Peel (talk) 11:13, 26 February 2018 (UTC)

Pictogram voting comment.svg Comment

So that needs to be sorted first anyway. If it does get sorted, I'm not entirely sure. It feels like it doesn't nicely fit in the layout. I'm also not sure I will find it useful. Perhaps some good examples can convince me.
Another issue I have is that this error occurs on 71 category pages out of 1078. That's 6.59% of all category pages yet this bug was not spotted. This thing needs way more thorough testing before deploying it on two millions pages. - Alexis Jazz 07:14, 26 February 2018 (UTC)
Alexis Jazz: This list is useless. Please create a maintenance category instead. Regards, Yann (talk) 09:06, 26 February 2018 (UTC)
You tell me I "make a mountain out of a molehill" in response to my perfectly sane proposal and you call a useful list (you can't easily search for these errors) useless. With this list you can more easily pinpoint all possible causes for this issue. If you want a list that also links the category in question, no problem, you would have only had to ask.
So far I have been (and will be, at least for some time) constructive on this wiki. But you create vandals. You treat people this way while being an administrator, you make people want to break this wiki. - Alexis Jazz 10:31, 26 February 2018 (UTC)
@Alexis Jazz: Thanks for catching this error; this part of the code was only added very recently. The ones with the missing surnames should now be fixed (I added an extra if statement to avoid auto-categorising these). The others, I'd appreciate feedback on - they are due to mismatches/errors in data here and on wikidata, so they can be resolved individually by an edit here or on Wikidata, or I can remove the defaultsort code from this template, I'm happy with either approach. Thanks. Mike Peel (talk) 11:07, 26 February 2018 (UTC)
Very good. I see for example Category:Ángel Ganivet indeed still shows the error due to the difference between "Angel" and "Ángel" and it takes a human to figure out which is right. What are the implications of removing the defaultsort code from the template? Will this cause problems, either now or at a later time? What is the reason this code is currently part of the template?
I think the infobox should not be added when it can cause this error which requires a human to fix it. If allowing these inconsistencies to exist is a bad idea (and I suspect it is) you could perhaps generate a list of the categories where this error occurs. (or add a hidden cat to those categories) When (human) users feel like it they can make the data consistent and enable the infobox. - Alexis Jazz 11:27, 26 February 2018 (UTC)
@Alexis Jazz: Defaultsort was added through the use of {{PeopleByName}} (see the discussion at #Merge the function of two templates above). I've now copied that code into this template, which gives more customization options. I've added a "defaultsort=no" parameter that, if set, will hide the defaultsort from this template and add the page to Category:Uses of Wikidata Infobox with defaultsort suppressed for tracking purposes. The plan would be that the bot would set that if it detects a conflicting defaultsort already in the category. How does that sound? Thanks. Mike Peel (talk) 22:06, 26 February 2018 (UTC)
@Mike Peel: That sounds good, I think some more implementation is in order.   — Jeff G. ツ please ping or talk to me 00:12, 27 February 2018 (UTC)
Symbol support vote.svg Support Very much agreed with Sebari. Rama (talk) 09:11, 26 February 2018 (UTC)
+1, also helps editors focus on non-duplicative work to improve our metadata. --Nemo 11:21, 26 February 2018 (UTC)
Symbol support vote.svg Support Obviously, tread gently. Move slowly into new areas of categories for new types of things. Be aware that these may reveal issues, that will then need adaptations to resolve. But in general, I support; and I have great confidence from what I've seen so far, that the team behind this (namely Mike!) are indeed very sensible and highly responsive. Widespread infoboxing will add greatly to the informativeness of category pages for all, as well as making Commons far more multilingually friendly. If it also adds an incentive for editors to add more sitelinks from Commons categories to items on Wikidata, that would be a valuable thing just in itself. Jheald (talk) 13:59, 26 February 2018 (UTC)
Symbol neutral vote.svg Neutral Changing my vote from oppose to neutral. I just don't know if I will find these useful personally. Maybe I will, I just can't think of any case right now where I would wish there was an infobox. If there would be an option to somehow disable these infoboxes just in case I don't like them, I would change my vote to support. I do mean actually disabling them, not just hiding, because something could happen that somehow slows down page loading. Hiding won't help in that case. - Alexis Jazz 14:14, 26 February 2018 (UTC)
@Alexis Jazz: Hiding's the best I can do, I'm afraid. If you add "#wdinfobox { display: none;}" to User:Alexis Jazz/common.css, that will hide the infobox. Thanks. Mike Peel (talk) 22:17, 26 February 2018 (UTC)
Thanks. I will stick with the neutral vote, simply because I am personally not sure I will be using it. Maybe it'll grow on me, who knows. My support won't be needed for this anyway so it makes no real difference. - Alexis Jazz 10:41, 27 February 2018 (UTC)
Symbol support vote.svg Support I was skeptical at first and resisted the early iterations because I had my own fave infobox format that used a horizontal format. Now this is my preferred. It replaces the 6 items I would use to create a new category, each requiring me to fill in information by hand. It also helps catch incorrect people by supplying their short descriptions from Wikidata. So when you see an image of a guy wearing boxing gloves and the infobox says he is a politician, you know to double check that two people have the same name and are being mixed up. Or if you see a contemporary photograph and see that the person lived in the 1800s. RAN (talk) 14:54, 26 February 2018 (UTC)
  • Symbol support vote.svg Support   — Jeff G. ツ please ping or talk to me 00:12, 27 February 2018 (UTC)
  • Symbol support vote.svg Support, this work would be too tedious for human volunteers anyhow. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:15, 27 February 2018 (UTC)
  • Comment. I do not have a strong opinion either way (I guess mild support would be the best expression of my attitude), but I think the discussion participants should be aware of an argument which is often brought up in these discussions but so far has not been brought up here. The argument is that so far the Wikidata community was not able to consistently fight vandalism, and it is not uncommon to have vandalism to stay hours even in the most popular Wikidata items such as countries and for days in less popular items. These instances of vandalism will be translated via the template and will not show on any watchlists.--Ymblanter (talk) 10:05, 27 February 2018 (UTC)
  • Symbol support vote.svg Support, but not for categories connected to P31 Q4167836 items without P301.--Jklamo (talk) 15:17, 27 February 2018 (UTC)
  • Symbol support vote.svg Support Changing my vote again, to support as I found a use case: Category:Saint Catherine. Saint Catherine? Who? What? Is it a city? Is it a person? Is it a church? Is it a school? Airport? Hospital? Sport club? Lake? Painting? All of the above? An infobox would be welcome here. Although the category itself is probably just a mess, but still. - Alexis Jazz 19:24, 27 February 2018 (UTC)
    @Alexis Jazz: more such cases can be found (esp. ambiguous toponyms, such as Lez River. But lending an unconditional support to these botmasters you will be responsible for many thousands cases of wikidata-driven mess and irritating visual clutter projected to pages over objection of local editors – it comes instead of few hundreds cases of grossly ambiguous categories. Incnis Mrsi (talk) 08:43, 28 February 2018 (UTC)
Um, if I support eating meat (instead of being a vegetarian) I will be responsible for millions of animals being slaughtered and incredible animal cruelty all around the world every day. I will be solely responsible for all that because I support it. And because I support lighting some fireworks on the Fourth of July, I am responsible for tens of thousands of people who get seriously injured every year in accidents all over the world. And imagine the implications of having the wrong stance on gun control.. I must be a very bad man. - Alexis Jazz 11:14, 28 February 2018 (UTC)
  • Symbol support vote.svg Support, but cautiously. I've added this template to a few categories (mostly places), and when it works it's magical. It interacts slightly poorly with some other templates, though, so I'd start by adding it to categories whose pages contain only parent categories and work up from there. --bjh21 (talk) 19:13, 1 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose for implementation reasons only. Striking oppose per threaded discussion. I'm normally not fond of adding more content to categories than is necessary to identify it, but this concept is so good for internationalisation that I have to drop my objection. Adding them manually, therefore, sounds like a great idea. But how is a bot supposed to know what's what? Sounds like you're adding it to a category that merely has a link to a Wikidata item; what if a category has a link as a means of clarifying something else, e.g. "Place X is a town in Galicia"? You wouldn't want to end up with the Galicia (Spain) data just because someone included a link to d:Q3908, its data page. Nyttend (talk) 11:50, 3 March 2018 (UTC)
    • @Nyttend: The bot would only add it to pages that have a commons sitelink on Wikidata, not just a link to Wikidata. That's the same sitelink that causes the interwiki links to appear in the left-hand bar. So for Galicia, it would add the infobox to Category:Galicia (Spain) as that's what is sitelinked - not any other page that happens to link to Q3908. Thanks. Mike Peel (talk) 14:05, 3 March 2018 (UTC)
      • Mike Peel, so you mean that it wouldn't get added unless the data page's "Commons category" section linked to the category in question? If that's the case, no complaints. Nyttend (talk) 16:21, 3 March 2018 (UTC)
        • @Nyttend: It's the 'Commons' link under 'Other sites' on the right (the other one is a property, not a sitelink), and it's only if that points to a category. But basically, yes. Thanks. Mike Peel (talk) 16:27, 3 March 2018 (UTC)
          • Okay, since it's merely doing it with pages that are already linked to the Wikidata record, you've shown my objection to be baseless. Thank you :-) Now that I understand it, I can see that it should be simple to implement. Nyttend (talk) 19:03, 3 March 2018 (UTC)
  • Note Given the support here (thank you all!), I've drafted the bot code and started a bot request at Commons:Bots/Requests/Pi bot 1 to ask for feedback on the code and any potential technical issues. Of course, this discussion is still running, and the bot run won't start until this discussion reaches a conclusion. Thanks. Mike Peel (talk) 23:57, 3 March 2018 (UTC)

Change to text of Commons:File renaming policy[edit]

"Files with copyright issues should NOT be renamed until copyright issues are resolved. There is no reason to rename a file if it is going to be deleted on copyright grounds."


"Files that do not appear to comply with Commons policy should not be renamed and instead be nominated for deletion if they haven't been already, speedy where applicable. When a file was nominated for deletion but the file mover deems this nomination to be unlikely to result in actual deletion, the file can be moved." - Alexis Jazz 13:37, 28 February 2018 (UTC)

  • Symbol oppose vote.svg Oppose Though renaming while a DR is open is considered poor practice, there are times when it is reasonable to do so, such as when the title may be defamatory. For this reason I would rather see the section changed to be weaker, it's stating a norm not a policy. The proposal wording does not specify which policy is the one not being complied with. It reads as if any file needing to be renamed would be deleted. -- (talk) 13:52, 28 February 2018 (UTC)
"It reads as if any file needing to be renamed would be deleted." I don't see this. Can you elaborate?
I will clarify what triggered this proposal. It was File:Faith Hill on the Jumbotron (3972893368).jpg. I nominated it as it didn't even state which stadium this was so it seemed to be just a file for Faith Hill. After a comment in the DR I did some research, improved category/description and blurred Faith Hill. It is now a useful image, but it is no longer "Faith Hill on the Jumbotron". The renaming request was however denied because there was a open DR.
This means I would have to wait for the DR to be closed before I can have this file renamed. That could have taken weeks or even months and I could easily forget all this in that time. In this case as I've just learned I can close uncontroversial DRs myself I have done that. But it would be very reasonable to just rename the file. - Alexis Jazz 14:40, 28 February 2018 (UTC)
  • Symbol support vote.svg Support Contrarily to , files can violate any number of Commons policies and guidelines which can lead to deletion. Typically, these include COM:L, COM:SCOPE, COM:TOO, COM:PRP, COM:FOP, COM:CRT, and the requirement in many source country licensing templates to have a corresponding template indicating the file is also free in the US. The majority of good faith DRs lead to deletion, and renaming a file subject to one of them can cause confusion in which the redirect is deleted but the renamed file survives, or a bluelink redirect to a deleted file is left in a DR. This proposal removes copyright as the single named specific reason not to rename, to the exclusion of all others.   — Jeff G. ツ please ping or talk to me 14:21, 28 February 2018 (UTC)
If a file fails to be deleted as a result of a move that is a software problem and a bug report should be made. Of course, there are more reliable ways of making this happen. - Alexis Jazz 14:40, 28 February 2018 (UTC)
Huh? "Contrarily to [me]" seems unrelated to what I wrote above. There are many policies related to deleting files, why anyone would think that I was denying this seems weird. -- (talk) 15:11, 28 February 2018 (UTC)
I don't know for what reason Jeff said it, but "The proposal wording does not specify which policy is the one not being complied with." can imply there must be one specific policy the file does not comply with in order to refuse a rename. I don't see the point of that, if a file is not copyvio but it is out of scope, why would you bother renaming it? - Alexis Jazz 15:20, 28 February 2018 (UTC)
@: What I meant by "Contrarily to " was that you were opposing, meaning you were for the status quo, which specifies only copyvios can prevent renaming. I also do not understand your conclusion "It reads as if any file needing to be renamed would be deleted" - can you please explain that conclusion and what led to it? — Jeff G. ツ please ping or talk to me 18:55, 28 February 2018 (UTC)
@Jeff G.: Fixed your signature.. I really suspect that what we have here is a case of The dress. You read the same thing I read, Fae and Steinsplitter are reading something completely different. It's nearly impossible for us to figure out on our own what they are reading. - Alexis Jazz 19:45, 28 February 2018 (UTC)
I am not for the status quo and I am against this proposal, these are not mutually exclusive. Criteria 4 of FR would be better removed entirely. A red flag that policies or guidelines are badly written is the inclusion of "deems" when the "deemer" has no defined authority. It would be nice to see proposals that reduce our bureaucracy. Most users and, based on their actions, many administrators, find the current guidelines and policies hard to follow or are not interested in following them as written. -- (talk) 19:56, 28 February 2018 (UTC)
@: I get your point but I don't fully agree. The "deemer" in this case is a file mover. (or admin etc) They are not asked to make a ruling on the deletion of the file. It merely asks them to use some common sense (I'm aware sense ain't common but you get my point) to determine that if they move a file despite the fact there is an open DR for it, they are making a constructive edit.
If your point is that moving a file that the file mover suspects will be deleted anyway for whatever reason is so stupid it should not require being pointed out in the guidelines I understand that. I will be happy to support a proposal to remove criteria 4 or replace it with "Never forget to use common sense when trying to determine if a file should be moved." or something like that. - Alexis Jazz 21:43, 28 February 2018 (UTC)
@Steinsplitter: Can you or anyone else please explain to me what the issue is that Fae has? And why a request to rename a file that is out of scope should be carried out but a rename for a copyvio should not? - Alexis Jazz 17:03, 28 February 2018 (UTC)
See Fae's oppose, he explained it very well. --Steinsplitter (talk) 17:21, 28 February 2018 (UTC)
If this is a joke I don't get it. I had already replied to that. I did read it. I don't get it. I ask for somebody (Fae or anyone who understands it) to explain it. Maybe I'm reading it wrong. Maybe you and Fae are reading the proposal in a way different from me and Jeff. Maybe it needs to be reworded yet again. But "per Fae" does not help me to do that.
It's like I just walked into the Twilight Zone. - Alexis Jazz 17:34, 28 February 2018 (UTC)
  • Fae explained and I now understand the confusion, so this proposal is no good. @Steinsplitter: how do you feel about getting rid of criteria 4 (the thing we discussed) altogether? - Alexis Jazz 01:31, 1 March 2018 (UTC)

Proposal to stop Special:Upload and Special:UploadWizard from adding headers to file description pages automatically[edit]

The first annoying header uses code "== {{int:filedesc}} ==", which evaluates in English to "Summary". It only makes sense to have it if you have other headers.

The second annoying header uses code "== {{int:license-header}} ==", which evaluates in English to "Licensing". Licensing should be in the information or other template's Permission parameter.

This proposal builds on the work of multiple authors of COM:VP#Upload automatically adding section headings, including @Nyttend, Begoon, Perhelion, and is related to phab:T187302, wherein @ noted a lack of consensus for addition of such headers the first place.   — Jeff G. ツ please ping or talk to me 13:56, 28 February 2018 (UTC)

By "headers", I mean section headers or headings.   — Jeff G. ツ please ping or talk to me 19:02, 28 February 2018 (UTC)

Headers proposal !voting[edit]

Symbol support vote.svg Support It's rather unclear to me where I'm supposed to stick my {{Trademarked}}, {{De minimis}}, license etc anyway. I think it looks better when those are in the permissions field of {{Information}}. - Alexis Jazz 14:44, 28 February 2018 (UTC)

Symbol oppose vote.svg Oppose, at least in respect of Special:UploadWizard. The Upload Wizard constructs its own wikitext, and I think it's perfectly reasonable that it should include these headings, since doing so is in keeping with common practice on Commons. I'd need to investigate the behaviour of Special:Upload a little more to have an opinion on it, but I think it should be possible to use it in a way that causes the created page to contain precisely the text typed (or pasted) into a single text area. --bjh21 (talk) 16:39, 28 February 2018 (UTC)

@Bjh21: but these common practices are only common because that's what the upload pages do. We cannot make Y common practice because X is common practice. - Alexis Jazz 17:08, 28 February 2018 (UTC)
True. In that case my argument is simply that there's insufficient rationale given for causing a change in common practice. --bjh21 (talk) 17:43, 28 February 2018 (UTC)
@Bjh21: I am not proposing a change in how humans construct file description pages, only in how two pieces of automatic software do it. I think it is already acceptable for humans and other pieces of automatic software to avoid the section headers and put licenses in the permission fields.   — Jeff G. ツ please ping or talk to me 19:00, 28 February 2018 (UTC)
  • Symbol support vote.svg Support unless you're using some setup that automatically adds headers. For example, if you're using Special:Upload and you don't specify a license in the free-text area, but you pick a license from the dropdown, it automatically adds a "Licensing" header, and in that case, the "Summary" header is useful. Surely it's not that hard for the system to detect whether the system is doing something. And if I understand rightly from Bjh21, the UploadWizard automatically has section headers, so that makes sense. But bjh21, I always paste my content directly into the Special:Upload box (I write it up in a Notepad file, and when I'm done I paste it in), and I'm always still getting the header. It's now impossible to avoid. Nyttend (talk) 22:55, 28 February 2018 (UTC)
  • Symbol oppose vote.svg Oppose, these headers make it quite easy for novice users (especially for the UploadWizard), but if users with more non-conventional licenses and descriptions then this be able to be optionally removed, but not by default. --Donald Trung 『徵國單』 (Talk 💬) (WikiProject Numismatics 💴) (Articles 📚) 00:55, 1 March 2018 (UTC)
@Donald Trung: A user who uses the Upload Wizard never even sees these headers? - Alexis Jazz 01:25, 1 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose I like structure. That's why we have categories. I'm not keen on huge undemarcated blocks of text. But licensing is not only highly important, it is critical to Commons. That's why it should have its own visible paragraph on the page, with an appropriate section header, rather than being buried in the information about location, description, photographer, source etc. I don't see a compelling case to change what we do, because I suggest it is helpful. Rodhullandemu (talk) 18:32, 1 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose I find useful the "edit" and "edit source" options this header displays ...when I need to fix something in the {{Information}} template. They come in handy. I'm used to embedding permission/licensing templates in {{Information}}, though. strakhov (talk) 18:39, 1 March 2018 (UTC)
  • Symbol support vote.svg Support There is a long history behind these useless sub-headings. We can see in the documentation of Template:Information that "license" was initially placed in "permission". But when people started to use custome license tags which are big, some people in Commons didn't like it. They decided to move it outside the template "information" and "permission" is remained for uses like OTRS and other markings. This makes the permission parameters split into two places and less informative to re-users. Who knows what the difference between "permission" and "license" with entirely different information in two different places? Fortunately I'm using cusom upload templates and place all licensing information (license, other non-copyright warnings, FOP and any other information) in one place "permission". Jee 06:51, 2 March 2018 (UTC)
    @Jkadavoor: Right, the licenses available for selection by users using these tools should not be so big as to require placement outside the "permission" field.   — Jeff G. ツ please ping or talk to me 10:31, 2 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose I find much better to separate legal information (license, trademark, FoP template, etc.) outside of the description. The headers could be displayed or hidden automatically with CSS when we will have structured data, but keep them for now. Regards, Yann (talk) 08:27, 2 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose - the license does not belong to the permission field. Did you know that is disappears when using the script for an OTRS tag if the license is there? The permission field is for permission information. - Jcb (talk) 08:35, 2 March 2018 (UTC)
    @Jcb: That would be a bug in the script for an OTRS tag.   — Jeff G. ツ please ping or talk to me 08:47, 2 March 2018 (UTC)
    If you want to place license out side of "information template", please place the OTRS permission, license review, etc. too below it. Please don't put related information scattered into several places so that reuser need to be a gymnastic to club all these pieces of information. We have plenty of license tags with OTRS and/or license review merged with it. Jee 09:36, 2 March 2018 (UTC)
    I did not write the scripts, but the current situation (already for years) is that if you apply an OTRS received or PermissionOTRS tag with the script from the 'tools' menu, that the tag lands in the 'permission' field. Jcb (talk) 09:41, 2 March 2018 (UTC)
    @Jcb: I reported your 08:35 statement above in a bug report at MediaWiki talk:Gadget-PermissionOTRS.js#Removal of old contents of "permission" field.   — Jeff G. ツ please ping or talk to me 10:08, 2 March 2018 (UTC)
    (Edit conflict) I know. That's why I wrote above "there is a long history behind these useless sub-headings." It was not thus in the beginning; but introduced later without knowing the copyright requirements that TASL (Title, Author, Source and License) should be clubbed together to provide ideal attribution. Only recenty we started to take care of proper attribution. Many of us feel that current "information template" is inadequate and started using Template:Credit line to override this limitation. But it is difficult to inject that template in all our pages; the better solution is to keep "TASL" together in information template. Jee 10:19, 2 March 2018 (UTC)
  • Symbol support vote.svg Support you can already do almost all what you want with the current template (or with one of its derivatives). No need of any header. Furthermore there is no TOC in files page, no need of different sections, even for a structural page concern. If the current template is not sufficient or not visually good, then develop it. Christian Ferrer (talk) 17:31, 2 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose, i see no harm. --Steinsplitter (talk) 17:44, 2 March 2018 (UTC)
  • Symbol oppose vote.svg Oppose, per Yann and Steinsplitter. -- Tuválkin 15:51, 3 March 2018 (UTC)
  • Symbol oppose vote.svg little oppose, if there's a way to make it possible in another way on mobile (I don't like the unofficial app, as I'm a fan of MobileFrontend view) I may consider support. --Liuxinyu970226 (talk) 13:01, 12 March 2018 (UTC)

Headers proposal discussion[edit]

No, I've not. In fact this is the tool that, after to have generate all the appropriate templates and links, lead me to Special:Upload basic, I've not the choice. But my problem is minor, I just have to remove the header that is too much. It's really not much to do. Christian Ferrer (talk) 05:13, 2 March 2018 (UTC)
  • Pictogram voting comment.svg Comment - This whole discussion seems to have been prompted by a couple of comments by Nyttend and myself to the effect that we didn't think Special:Upload (the manual form) should be adding the int:filedesc heading to every upload, because it's, you know, the manual form, and folks who use it really expect just what they put in the freeform field to be used, just as it used to be. Like Nyttend, I copy/paste wiki-text and having this unavoidable automatic addition is a bit inconvenient sometimes. At that point we were only talking about one thing that just started happening, just with the manual form. Somehow that has expanded to a discussion about the wizards, where licenses should go, OTRS scripts and all sorts of other things. It's all very interesting, if somewhat tangential to the point that seems to have initiated it... -- Begoon 16:45, 2 March 2018 (UTC)

Flow - WMF's proposal[edit]

There was a recent consensus to uninstall Flow, as was done on EnWiki and Meta. The WMF is offering a new and different proposal.

When Flow is uninstalled it leaves behind broken log entries. At this time, the Wikimedia Foundation does not consider the broken log issue serious enough to fix for EnWiki, Meta, or Commons. However the Foundation has indicated that they will not oppose any volunteer developers who wish to work on fixing the the log issue (Phabricator task T188577). At this time, the Foundation position is that they do not want to uninstall Flow so long as the log issue exists.

The WMF has interpreted the uninstall consensus as a request to expand and improve Flow. Specifically they began work on a new Flow feature, adding a read-only mode (Phabricator task T188577). This mode would ensure that the WMF, or anyone with global Flow-creation-rights, cannot inadvertently create a Flow page here without first removing the read-only setting. The WMF believes this satisfies the goals of the existing consensus.

The WMF proposes completing work on the Flow improvements and deploying the new read-only Flow mode to Commons.[5]

Is there a desire to convert Commons-Flow to the new mode? Alsee (talk) 14:36, 11 March 2018 (UTC)


  • No. The WMF's proposal is worse than useless. I trust the WMF not to create new pages here, and if such a page were to appear it can just be speedy deleted per existing consensus. Once the logs are fix we can reconsider uninstall.
    I'd like to quote Jdforrester, a lead project manager at the WMF: "Custom configurations for each wiki slightly slow down the sites for every reader and editor, and complicates Ops' work", and he further describes such custom configurations as "a security risk".[6] Commons is the only site slated to use this Flow configuration. (Note: The WMF's 'technical' arguments have been rather POV-driven. The WMF opposed uninstall based on the above "custom configuration" argument, however uninstall would only make Commons conform to the largest wiki (EnWiki) as well as our global hub (Meta). Then the WMF wants to put Commons into a unique new configuration in order to prevent uninstall. As Jdforrester explained, there are solid technical reasons not to do that without a good reason. Then WMF tries claim the logs are serious enough to prevent uninstall, while simultaneously claiming the issue is too insignificant to fix for EnWiki and Meta. Then the WMF wastes work building a useless new Flow mode instead of just fixing the logs.) Any work to build, test, apply, or maintain this custom configuration would be a complete and utter waste. I am not afraid new Flow pages will appear, and if they do appear we already have a delete button for unwanted pages. This only serves to make Flow bigger and more complex.
    The new Flow feature claims to achieve the goals of the original proposal. As the WMF appears interested in those goals, and appears to have difficulty understanding those goals. I will attempt to list some goals, as I view them. This list is not necessarily complete. The new Flow mode does nothing to address:
    1. Eliminate all side-effects of the Flow installation, including but not limited to an entire namespace (Topic).
    2. As long as Flow is installed the code continues to execute, listening-for and handling all Flow-commands sent to it over the internet. The new Flow code merely adds another layer of complexity to processing commands sent to Flow. As Flow is unused here, there is no justification for Commons to be subject to undiscovered bugs that currently exist in Flow. There is also no justification for Commons to be subject to bugs in ongoing changes to that code. The fact that the code is running and processing incoming internet messages opens an additional door for security threats. There's a very good reason standard computer security practice is to remove code that isn't being used, most importantly anything that is listening for commands from the internet.
    3. Developer time is a valuable commodity. There's an endless backlog of things that we want and need. Every dev-hour spent expanding or maintaining Flow is a dev-hour diverted away from things we do want and need. Wasting time building an utterly useless new Flow mode just compounds the problem.
    4. Hoping for the WMF to stop persistently and pathologically re-interpreting every criticism of Flow as a community request to expand work on Flow. The WMF's current proposal a painfully ironic repetition of this.
    5. Another hoped-for goal is for the WMF to stop refusing to improve talk pages, and the continual response that we have to switch to Flow if we want anything. Yes, we want improvements, no Flow is not an improvement. Either improve talk pages, or start a new project from scratch. Having Flow installed everywhere is fueling ideas that Flow is progressing towards globally replacing talk pages. Any improvement to talk pages are treated as wasteful and directly undermining an eventual switchover to Flow. Flow is resulting in sabotage-by-neglect of talk pages.
    6. In case I missed anything, I suggest the WMF consider how they would respond to a request for LiquidThreads to be installed and left unused, while people were writing and deploying major changes to that code. It's a zombie project. Flow is LiquidThreads2. Having unused Flow installed here is nothing but a hazard and pure technical debt.
      Alsee (talk) 14:36, 11 March 2018 (UTC)
  • Yes and I find the title here totally disingenuous. The "new mode" is a complete disabling, functionally equivalent to removing Flow. The developers say they have more confidence in the stability of the system by doing this than by physically removing the code, and I se no reason not to extend them good faith. As remarked above, "Developer time is a valuable commodity." If they say this way of achieving the desired functional result is expected to require less developer time, I don't see any reason to doubt them. - Jmabel ! talk 16:29, 11 March 2018 (UTC)
  • Meh (but more importantly, Objection to the absurd rhetorical framing of this section) - "The WMF has interpreted the uninstall consensus as a request to expand and improve Flow" is a bizarrely misleading frame to put on this question. That makes it sound like they said "nevermind what you all want, we're going to keep making Flow BIGGER and MORE INTRUSIVE" as opposed to reality which is that putting it in read-only mode is specifically to accommodate the community's request not to use Flow on Commons without creating those log issues. Whether it's the best approach, I don't know (mainly per my comments in the other thread). — Rhododendrites talk |  15:47, 17 March 2018 (UTC)
  • I feel as Rschen7754 below, but overall I object as this is not what was requested and decided. The English Wikipedia had hundreds of topic pages, all of them got removed and the wiki is up and running without issues. Meta-Wiki problem was that they wanted a Flow board migrated, they did so and removed the extension and Meta-Wiki is also up and running without issues. As for Commons: similar situation as was with Meta-Wiki, except that there are no Flow boards to migrate and every Flow board can go. I'm (and others) are still waiting for a convincing reason why Flow cannot be removed in the same fashion as enwiki and metawiki. People with tech knowledge on the Phabricator task is also arguing about the lack of reasons not to do the same here. Thanks, —MarcoAurelio 18:22, 17 March 2018 (UTC)


  • Pictogram voting comment.svg Comment I don't see any need to "delete" or to "uninstall" anything, if the community don't want a development of this tool, it's fine. Just let the things as they currently are, a test, and forgot these pages as a dead project, that's all. Again some work and potential technical issues for nothing, IMO. Christian Ferrer (talk) 17:23, 11 March 2018 (UTC)
  • Pictogram voting comment.svg Comment In the conversation that we've been having this week, I said that the WMF is happy to support the goal of these proposals, which is to remove Flow from Commons. We're going to do that by deleting the existing Flow pages, and then deploying a config change that will ensure that nobody is able to create any new Flow pages or posts. This is what Alsee describes above as an effort "to expand and improve Flow," which I find puzzling; it's actually doing the exact opposite of that. We agree that Flow should be removed from Commons, and that's what we're doing. The specific technical implementation of how the developers will achieve that goal isn't up for community consenus. Choosing the best technical solution for a problem is a job for the experienced developers on the team. I look to them for information and judgment on how to implement a solution; that's what they're for.
However, as Alsee has offered six more goals for the project, I'll respond to each one.
    1. "Eliminate all side-effects of the Flow installation, including but not limited to an entire namespace (Topic)." In the plan that I've described, the Topic namespace will be deleted and disabled; nobody will be able to use it anymore.
    2. Alsee is concerned that deleting and disabling Flow will still leave Commons open to experiencing bugs related to the Flow code. That's not the case; bugs that affect Flow shouldn't affect wikis that aren't using it. He's also concerned that there are security risks involved in code that is "listening for commands from the internet." Security risks in the code are evaluated and handled by our senior developers.
    3. "Developer time is a valuable commodity... Wasting time building an utterly useless new Flow mode just compounds the problem." It's true that developer time is expensive. Our senior developers have determined that deleting and disabling Flow is the most efficient way to achieve the goal of removing Flow from Commons. Uninstalling the Flow extension would take a lot more time, and would involve more risk.
    4. "Hoping for the WMF to stop persistently and pathologically re-interpreting every criticism of Flow as a community request to expand work on Flow." I believe that goal is being met; criticism of Flow on Commons is resulting in the removal of Flow from Commons.
    5. Alsee wants the WMF to work on fixing problems with talk pages, rather than deflecting those conversations in order to support the Flow project. I agree with this goal. We're currently finalizing the Annual Plan that will be submitted for the 2018-2019 fiscal year, and the plan includes a large-scale community consultation about fixing talk pages -- starting from the beginning, by coming to consensus on the problems that we all agree need to be fixed. This conversation that we're having right now isn't the proper venue to have that discussion; it'll happen during the 2018-2019 year. The action that we're taking to remove Flow from Commons doesn't affect that future consultation one way or the other.
    6. "I suggest the WMF consider how they would respond to a request for LiquidThreads to be installed and left unused, while people were writing and deploying major changes to that code." That would actually be perfectly fine; I'm not sure why Alsee thinks that would be a problem. Again, the decisions about technical implementation should be made by our senior developers.
I believe that addresses all of the concerns, but I'm happy to continue discussing it, if people want to. -- DannyH (WMF) (talk) 19:27, 11 March 2018 (UTC)
  • I think that the desire of Commons to have the extension completely uninstalled should be respected. But, it does not have to be done today. If this "kill switch" is to be used as an interim solution, then so be it, but it should not be the permanent solution. --Rschen7754 19:54, 11 March 2018 (UTC)
  • DannyH (WMF) it was just announced that the new mode is scheduled for deployment on Commons the day after tomorrow. I'm really hoping you can tell me this is simply due to a communication gap, and that the WMF isn't deliberately deploying the mode here while there's an RFC underway. Thanx. Alsee (talk) 14:13, 17 March 2018 (UTC)
Alsee, as I've said before, the specific technical implementation for how we remove Flow from Commons is not up for community consensus. It's a technical decision, which is made by the senior engineers. We're following the community consensus to remove Flow from Commons. -- DannyH (WMF) (talk) 15:26, 17 March 2018 (UTC)
DannyH (WMF) is there a communication problem here? We are not discussing the previous consensus. We are discussing a new one. (The RFC is currently running neutral, and the result could go in either direction.) Are you saying that the Read-only-mode is MANDATORY, PERMANENT, AND IRREVOCABLE? Are you saying that the WMF preemptively refuses any and all future consensus result to remove read-only status? Are you asserting that once read-only status is applied, that there is some technical reason that it would be dangerous to ever remove it? Alsee (talk) 06:55, 18 March 2018 (UTC)
Alsee, we are following the consensus to remove Flow from Commons. The specific technical implementation for how we do that is up to the engineers, and is not up for community consensus. We're going to remove Flow by deleting the two existing Flow pages and disabling the feature. We've exported all the conversations from those two pages, and I've posted them here: User:DannyH (WMF)/Commons Flow export and User:DannyH (WMF)/Flow tests export. Then we're going to use the "kill switch" config change to make sure that nobody can create any more Flow pages or Flow posts. This RfC is objecting to the config change. As I said, the specific technical implementation for how we're going to remove Flow from Commons is not up for community consensus. -- DannyH (WMF) (talk) 18:03, 18 March 2018 (UTC)
DannyH (WMF) you are not answering the question that was asked. Do you not understand me, or are you deliberately not answering?
I'll try to make it clear and easy for you. If two years from now, Commons has a consensus that Flow is better and we want opt-in Flow userpages like Chinese Wiki has, will the WMF enable it here? Alsee (talk) 18:41, 18 March 2018 (UTC)
Alsee, I guess I didn't understand you; thanks for the clarification. Yes, if Commons wants to use Flow later on, it will be possible to undo the config change. The same is true if we uninstalled the extension; it would still be possible to reinstall it. Does that help? -- DannyH (WMF) (talk) 22:19, 18 March 2018 (UTC)
DannyH (WMF) now we are making progress. As you just said, a second consensus can lift the read-only config. This is RFC on whether read-only config should be applied on Commons. If the config is applied while the RFC is in progress then it may result in consensus to immediately lift that config.
Actively forcing out an unwanted config would be far worse than passively doing nothing in response to the previous consensus. Alsee (talk) 05:13, 19 March 2018 (UTC)
Alsee, the current consensus is to remove Flow from Commons. We're following that consensus, and the specific technical implementation that we're using is to delete the pages, replace them with wikitext exports, and then use the config setting to disable Flow completely. At that point, if the Commons community had a consensus to bring Flow back to Commons, we would follow that, and the technical implementation that we would use is to remove the config setting and allow people to create more Flow pages. In both cases, the technical implementation would be up to the senior engineers to decide, and isn't up for community consensus. If you would like to restore Flow to Commons, then you should start an RfC about that instead. -- DannyH (WMF) (talk) 05:23, 19 March 2018 (UTC)
@DannyH (WMF): The problem is trust. Trust in the reasons given here and the motives behind that reasons.
Flow was advertised as a software, that has no negative implementations if it would be removed. Now you say, that it has so massive negative impact if you uninstall it even on a wiki, where it had only two pages for testing purpose, that it must not be uninstalled, in other words: it's a very dangerous peace of software, that must not be deployed anywhere else until this proclaimed danger is eliminated. If the software is really that dangerous as you and the devs proclaim here, why didn't you pull the emergency brakes asap as you noticed it, and stopped any deployment anywhere else? Why do you want to infest projects with this, as you say, dangerous piece of software, if they only want to test something? An imediate stop of deployment would have been the first step, if you really regard this software as unretractable. And as you didn't do this, there are two possible motives: You didn't want to compromise a pet project by some devs even against known dangers, like it ad been done with VE and MV, or your claim about the danger is just overblown to keep it installed with some strawman reasons.
A piece of software, that is as dangerous as you proclaim that Flow is, should raise red alerts as soon as the danger is known, but nothing has happened from the devs, it was all up to the community to react. Why was this so? Sänger (talk) 05:41, 19 March 2018 (UTC)
DannyH (WMF), while I agree with Sänger's comment above, I fear it is creating confusion when uninstall arguments are mingling with the read-only topic. I request that you carefully note that I am trying to draw a line between the two topics.
You can't claim to be following an older law if you directly violate a newer one. You can't claim to be following a boss's older instruction when you directly violate a newer one. If the result here is that Commons doesn't want to be configured read-only, you can't claim you are following an older consensus. That is obviously invalid.
You can stand on the bad-ground that the WMF is unwilling to spend money fixing the log issue and therefore unwilling to uninstall Flow, but you cannot claim an older consensus trumps a newer one. You can't claim Commons is set to read-only because of an old consensus if the newer result doesn't want read-only. That would be compounding passive-disregard for the first consensus with an active assault against consensus. Alsee (talk) 16:01, 19 March 2018 (UTC)
Sänger: There's no practical difference between "uninstalling" Flow (as we did on English Wikipedia) and "disabling" Flow (which is what we're going to do on Commons). In both cases, the Flow pages are deleted, and there's no way to access them or create any new ones. The only difference is what the backend code looks like, and it's up to the engineers to determine that. Roan says that the redlinks for deleted Topic pages throw errors when the software doesn't know what Topic pages are anymore, and the team had to invest unnecessary time in dealing with that when they uninstalled Flow from English Wikipedia. This isn't a crisis that requires global action; it's just the engineers determining the best way to accomplish a goal.
For your larger point, I know that you're saying that you don't trust my word or the word of the engineers, and that you suspect that we're lying in order to protect a pet project. I agree with you that sometimes WMF product teams have not been honest about their motivations in the past, and that has been damaging and unnecessary. I'm not doing that here, but I'm not surprised that you don't believe me. All I can do is act in a trustworthy way. In this case, that means that we're removing Flow from Commons, and uninstalling it from wikis that haven't used it. We don't want to uninstall it here, because as I said, it's a lot more work for no practical benefit.
Alsee: What I'm saying about the RfCs is that the specific technical implementation of how we remove Flow from Commons is not bound by community consensus. We're removing Flow from Commons, which I believe is the outcome that you want. The specific way that we accomplish that goal is not determined by this RfC. -- DannyH (WMF) (talk) 17:24, 19 March 2018 (UTC)
There's a huge difference: Either to get completely rid of Flow, or to just insert a software switch to disable Flow for now. Is there a possibility to restrict access to the software switch to commons bureaucrats, and completely lock out every single dev and functionary from the WMF? That would be a fine solution, but as long as everything stays as it is, and only a weak software switch, that any dev can change at will, I don't trust the solution. I've seen what evil dev can do with the horrific stuff Eric perpetrated with superprotect. IIRC he was not sacked for this despicable behaviour, not even officially reprimanded. <pa censored> If the WMF gives up completely about Flow, and really, even technically, surrenders to the community, a simple software switch is not enough. Sänger (talk) 18:25, 19 March 2018 (UTC)
Sänger: The ticket for the "kill switch" disable-Flow setting says that nobody can create Flow pages, regardless of user rights. Bureaucrats, stewards, etc won't be able to do that. The only way to enable Flow will be for the engineers to turn off that config change. This is also the case for uninstalling Flow -- again, the only way to enable Flow would be for the engineers to reinstall it. Both methods are functionally the same. For the other issues: I agree with you that superprotect was a bad idea, and in the past, product managers have made other foolish errors, including me, unfortunately. I'm working to make sure that we learn from those mistakes. Erik and Fabrice haven't worked here for several years. But the people who are here now need to earn trust, by being trustworthy people. -- DannyH (WMF) (talk) 18:40, 19 March 2018 (UTC)
That "Kill Switch" is inserting a meagre line of code somewhere, that can be removed at whim. It's not a de-installation of that unwanted stuff. How can devs be barred from being able to change that line without community consensus? Methinks the re-deployment of Flow is a bigger effort than just removing/disabling a line of code. Sänger (talk) 19:16, 19 March 2018 (UTC)
We don't have rogue engineers who will re-enable Flow on Commons for no reason. I think everybody agrees that the question of whether Flow is on Commons is a big deal, and not something that someone would do lightly. We're removing Flow from Commons now, and I don't see any reason why that would change without serious discussions. -- DannyH (WMF) (talk) 00:33, 20 March 2018 (UTC)

And a heads up in general: I posted on the thread at Commons:Village pump that we've deployed the two tickets that we've been discussing: the Flow "kill switch" and "uninstall Flow from wikis that aren't using it". We're doing this as part of the consensus to remove Flow from Commons. Obviously, I know that Alsee has been opposing the "kill switch" config change, but that's an issue of the specific technical implementation of the remove-Flow consensus, which is up to the engineers to decide. -- DannyH (WMF) (talk) 18:53, 19 March 2018 (UTC)

DannyH (WMF) if the application of read-only turns out to cause any problems and it has to be lifted, are you willing to give your personal assurance that it will not be reapplied without an explicit consensus to reapply read-only? Alsee (talk) 22:49, 19 March 2018 (UTC)
Alsee: I'm sorry, I don't think I understand your question. "Read-only" isn't a feature of the product, it's the mechanism we're using to remove and disable Flow on Commons. Using that specific technical implementation step is up to the engineers, and isn't up for community consensus one way or the other. Does that answer your question, or am I missing something? -- DannyH (WMF) (talk) 00:33, 20 March 2018 (UTC)
DannyH (WMF) what you are missing is that the WMF deployed read-only in a disruptive state. The two pages could not be removed from the maintenance category for active deletion workflows. The false categorization could not be removed by non-admin workers, it could not be removed by administrators, it could not even be removed even by WMF staff without invoking a site-reconfiguration to lift read-only first. However that problem appears to have been circumvented when the deletion-result was unexpectedly changed from keep to delete. Deleting the entire page indirectly eliminated the irremovable workflow category. I will be quite unsurprised if other problems, potentially more serious, arise from this read-only kludge. I really don't want to pile on yet another lie / broken-promise from the WMF when your claims turn out to be false that read-only is functionally equivalent to uninstall. Flow pages were deployed here without consensus to do so, and based on a claim that there were "minimal ramifications from enabling two testing pages".[7] Yet here you are saying that the ramification of creating even a single Flow page is that the extension is permanently unremovable. Of course that is also false. Whether it's 2 years or 20 years or more, the software is eventually going to be removed as obsolete. All of the work building read-only, and all of the time spend arguing over it, will be nothing more than pure-waste. All of that time and effort wasted, just to expand and perpetuate the technical debt of an eventual uninstall. Alsee (talk) 18:56, 20 March 2018 (UTC)
Alsee: Well, it sounds like the immediate issues here have been solved. It sounds to me like your concerns are more about what might happen in the future -- an unexpected deployment decision, or technical issues that might arise from the config change. I guess we can pick up that conversation later on, when something changes. -- DannyH (WMF) (talk) 19:04, 20 March 2018 (UTC)
DannyH (WMF) the fundamental problem for years has been a bad WMF-Community interface. You have abundantly acknowledged past problems above, and for the 300th time we're being told we can't fix the past but you'll do better today. You say above how you want to build trust, yet today you're repeating the same exact problems.... and even managing to find new areas to further destroy almost non-existent trust.
One of the repeating themes is that the WMF builds code in secret, or builds code after being strongly alerted that there is a problem, and then the WMF gets locked into destructive modes of doubling down on the already-built code. And look what's happening again. Read-only got built in secret. It was actively kept secret, while people were banging on the doors asking what was going on behind those secret doors. You tell me, does building code in secret build trust? If the software had been built in good-faith, you would have offered the solution. Instead the WMF entered trench warfare mode, doubling-down on that the code had to be used whether it was wanted or not. You explicitly stated that you would ignore any consensus to lift read-only mode. You tell me, does a declaration that you are going to ignore the community build trust? And here's my main question:
If there is a newer consensus lift read-only, why are you entering battle mode against it? Can you cite any technical reason that the wiki can't be left with no Flow pages and without read-only? It doesn't even have to be a technical reason, can you cite any non-technical reason that you would actively oppose the community if it wants read-only lifted? The only rationale you offer (repeatedly) is that you are claiming to be following an older consensus. That is either a gross misunderstanding of consensus or it's an empty excuse. A newer consensus always takes precedence over any older consensus. You have verbalized no comprehensible reason for doubling-down read-only. Of all the reasons I can imagine for you to oppose liffing read-only, none of them are good. Please, help me stop imagining bad reasons. Please, offer me one good reason that you would actively oppose a consensus to lift read-only. Alsee (talk) 21:22, 20 March 2018 (UTC)
Alsee, I think one problem here is that you're seeing "read-only" as a feature that matters. It's intended as an extra lock on the door, so that we could delete all the Flow pages and make sure that nobody will try to create any new ones. I don't think anybody is interested in doing that, but we figured it would help people breathe a little easier, knowing that the door is double-locked. Besides that extra security, it doesn't do anything. So I can't imagine a reason why someone would want to remove the double-lock, and still keep Flow deleted. It wouldn't serve any purpose. So I don't understand what the practical reason is for why you want to remove that lock. I do understand the principles that you're talking about -- that WMF product teams should be communicating more, there should be less done in secret, product teams should be more up front about plans and motives. I feel like I've been doing that. We removed Flow from Commons because Commons doesn't want to use it. We double-locked it so that everyone would know that it wasn't being used here anymore. We didn't do the "uninstall" because it would have been a waste of time and money, for no practical purpose. That's it. I'm not in battle mode, because there isn't anything to battle here. You wanted Flow off Commons. Flow is off Commons. I'm pretty sure we can just move on and work on something else. I'm sorry if there's something I'm not seeing, but I don't think there's anything to fight about. -- DannyH (WMF) (talk) 23:09, 20 March 2018 (UTC)
DannyH (WMF): "we figured it would help people breathe a little easier, knowing that the door is double-locked" that is certainly a reasonable thought, however what happened is that the WMF locked us out of the room and decided among yourselves what to put in our heads. If there had been open communication we could have discussed the available options, and only built read-only if it was actually worth doing. And please note that you did not answer my question. You say that you don't think there's anything to fight about, but you're here declaring that the WMF will ignore any consensus against read-only. If the community considers read-only to be worthless or even detrimental, why push it out and then fight against removal?
I see that you are making a major effort to engage here. But are you here so that the WMF and community to work together to figure out what we're going to do? Or are you here on a PR mission to smooth over rollout of the secret internal decision? It's hard to have a constructive discussion when you're saying that the secret-discussion result is irrevocable and the community will be ignored. Alsee (talk) 03:16, 21 March 2018 (UTC)
Alsee: I want to go back to a separation I was talking about earlier: the Goal and the Implementation. What I mean by "Goal" is the actual, practical outcome that people will notice -- what happens on the user end. In this case, the goal was to get rid of Flow on Commons. That goal was achieved by deleting the pages, replacing them with wikitext exports, and making a config change so that nobody can create any new Flow pages. That's done now; goal achieved.
What I mean by "Implementation" is the code that the developers use to reach that goal. In this case, the config change that you're referring to as "read-only" is a change in the code. You can't see it from your end.
During this conversation, I've said something several times: the specific implementation that the engineers use is not a matter for community consensus. The community does not vote on what happens in the code. That is something that the engineers do. You absolutely get a say in what happens on the site -- in this case, Flow not being on Commons anymore. But you don't get a say in what the code looks like. The config change is part of the code, and you do not have power over what happens in the code. So when you say that you want to hold RfCs for or against a specific piece of code, then I have to say no, we will not respect community consensus either for or against specific lines of code. We don't write code by community vote. I'm not battling over it, because it's not something that you and I battle over. It is not a thing that you influence.
As for my motives, and why I'm engaging: I'm here talking to you because it seems like you're really upset, and I wish that I could reassure you that things are actually okay. I understand why you're suspicious that you're being lied to -- in the past, people have lied to you. I'm not lying to you now, but I get why you think I would be. But I know that there's nothing underhanded happening here. Flow has been removed from Commons. We can really just move on. But you're having a hard time, and it's obviously just you and me paying attention to this conversation, so I figure I'll keep talking and maybe it'll help you feel better. -- DannyH (WMF) (talk) 03:40, 21 March 2018 (UTC)

The problem with trust and Flow is, there is not that much trust about Flow, as it's sold to the communities with false presumptions, a non-existent dichotomy between VE and Flow is propagated by the marketeers of Flow. There was even a "survey" about Flow, where against the facts this dichotomy was very central, used as a promotion for Flow. This "survey" was as well deliberately sent only to proselytes to bend the outcome towards Flow even more. If you don't stop spreading falsehoods about VE on talkpages just to promote Flow (and the renaming of Flow to "StructuredDiscussions" for pure promotional reasons against the fact that current discussions like this are structured as well, just more flexible, is part of that enterprise), why should we trust the devs and the marketeers in the WMF about Flow? Sänger (talk) 05:30, 21 March 2018 (UTC)

Sänger: I agree, there's been a lot of hype for Flow that was not really honest, and that made it counter-productive, just frustrating people and doubling down on arguments that don't go anywhere. I became the Director of the Contributors team a couple months ago, and one of the things I'm doing is helping all the teams move away from that style. WMF product teams need to communicate a lot more, and a lot earlier, and we need to take criticism seriously. When people are upset, we need to reflect on our own motives and behavior, and make sure that we're doing the right thing and telling the truth. We're working right now on documenting those principles, and posting them on mediawiki. But I know that's not a thing that I can say, and have people instantly believe us and trust us. Trust is something that you earn, and I'm actively working with the product teams on earning that trust. -- DannyH (WMF) (talk) 16:44, 21 March 2018 (UTC)
OK, it's a bit hard to believe as long as in topics like this one the devs wanted to close with false reasons, just to let the discussion die and still ignore, are still without a valid answer, and this post by me in that thread was hidden by an IP-vandal, and nobody tried to undo that (I can't, because they banned me first for my (perhaps a bit too) outspoken opposition against Flow, and a month later for no reason at all). In this topic the devs make the false claim, that a structure is not a structure, and that machine readability is something most desirable for talk pages, where primarily humans interact and machines are not even secondary. They simply don't listen to anything that affects their project in a possible negative way but insist on their rose-coloured perspective. It's quite frustrating to see, that any valid argument is just brushed away, even with proven falsehoods, and you get banned obviously for saying so.
It would be a bit more believable, if those who spread those stuff in the past to promote this project would show signs of re-evaluating their attitude and start listening to the communities, and not only the proselytes. Sänger (talk) 19:02, 21 March 2018 (UTC)
Sänger: Yes, those are examples of the kind of behavior that I am working to change. Some of the people involved in those discussions no longer work in that capacity. I'm working with everyone to learn from those mistakes, and stop acting that way. It's a long-term goal that will take a lot of work. I agree with you that that is not the way that Foundation product teams should respond to members of the community. -- DannyH (WMF) (talk) 01:50, 22 March 2018 (UTC)
DannyH (WMF) you said teams should be more up front about plans and motives. Do I need to note again that you are not being up front about your motives? You're not gaining any trust when you don't live up to your own words, when you're being glaringly evasive. Do I really need to ask again why you care if read-only is active?
You said above "one problem here is that you're seeing "read-only" as a feature that matters", implying that it does not matter. Then why do you care if read-only is active? I'd really like to get back to more substantive matters, but we're stuck discussing why you are unwilling have those discussions. We're stuck discussing why you're being glaringly evasive. Alsee (talk) 09:50, 21 March 2018 (UTC)
Alsee, I feel like you're not understanding the main point that I'm making. I really am answering your questions, but there's a disconnect that I can't figure out how to bridge. Please tell me if the following sentence makes sense to you: WMF engineers and product teams make decisions about writing and maintaining backend code, and those coding decisions are not up for community consensus. Can you tell me if you understand what I mean? -- DannyH (WMF) (talk) 16:44, 21 March 2018 (UTC)
DannyH (WMF) I think I do understand you. In a better universe we would be working as partners in good faith with abundant trust and abundant understanding. When it comes to technical, legal, and consensus: Technical and legal should only be pulled out as trump-cards in good faith, when there are indeed technical or legal issues that override all other concerns. And in those cases, that should be the end of that. As you noted, sometimes WMF product teams have not been honest about their motivations in the past. A supposedly technical decision that is driven by non-technical motives is not a technical decision. That is a decision on the non-technical agenda. I think only case where a good-faith technical decision would require covert motives is when there is an unresolved security hole.
The conversation you are trying to have is that technical trumps consensus. The conversation I am trying to have is that there is no technical claim here. There is no pressing technical reason why Commons should or shouldn't be set as read-only. As I see it, your refusal to offer a motive for refusing to remove read-only is effectively an acknowledgement that there is no pressing technical justification.
We both agree that there have been problems in the past, and that the best we can do is try to rebuild trust and collaboration today. However when today you try to assert a "technical trump card" that is either invalid or has the appearance of being invalid, you paint the WMF into a corner where we can't trust the WMF in the future. There is no technical claim to whether read-only should be active or not. Furthermore the covert discussions about uninstalling Flow were either covert because they were driven by non-technical motives, or they were pointlessly covert and it created an inescapable impression that they were driven by non-technical motives. In either case I believe it warrants revisiting that discussion in a more open manner. Alsee (talk) 22:47, 21 March 2018 (UTC)
Alsee, I don't think you understand me. What I'm saying is that the config change that you call "read-only" is a technical decision. It is a piece of code, a method of solving a problem. When I talked with Roan about how we handle removing Flow from Commons, the technical decision that he made was to use that piece of code. When you say that you want him to remove that piece of code, you are trying to interfere with a technical decision that is Roan's job, and not yours.
As for the secret discussions: when there is a community request that involves a technical change, the correct way to handle that is for me to talk to the team. We discuss possible methods of handling the situation, and if it's a difficult decision, we gather more information and look at pros and cons. This happens outside the view of the community because that's the way that people's jobs work. We have meetings and talk about things. That is not sinister, it is routine.
I think that your concern about covert discussions started because I went on vacation for a few days. Roan and I talked on Monday and decided what we would do, and then I went to Disneyland on Tuesday with my husband to celebrate his birthday. I was there until Thursday, and came back to work on Friday. I had decided to not post about the technical decision on Monday because I knew that there would be discussion about it, and I didn't want to disappear for three days in the middle of that. I waited until I got back on Friday to post about it.
Obviously, I know that I'm not going to convince you that Roan and my husband and Walt Disney and I are just going about our normal business, and not scheming against you or the Commons community. I'm just saying that's what happened. -- DannyH (WMF) (talk) 01:45, 22 March 2018 (UTC)
DannyH (WMF) it sounds a lot like you're saying that promoting one political party to the top of search results is a "technical decision" if the keywords are written in a config file. An effective way to wrap up the "technical" topic is if you can use the word in a sentence resembling "The technical reason Commons can't have the same config as other wikis is...". Is there any remotely credible claim that it would interfere with back-end operations? If you left your read-only code in place, but just didn't config Commons as read-only? You won't give any rationale at all.
You said I think that your concern about covert discussions started because I went on vacation for a few days. No, no no. That's a serious misunderstanding. The timeline begins Feb 6 when Mattflaschen effectively put a veto (-2 code review) on the Gerrit Patch. The comment was Under discussion by the team. Do not merge at this time.[8] Ok. Fine. Exactly one week later I posted a polite request on Phab: It's been a week since progress was halted without explanation. Could you or anyone explain the holdup?[9] And it was not just me. For weeks, several people were asking on Phab and on Gerrit. Even developers were given brick-wall non-responsive replies. You showed up at the THREE week mark. You stated that the WMF's non-communication was going to extend to the FOUR week mark. Aklapper then slapped me with a Phabricator code of conduct warning for unrealistic expectation that questions asked by individuals will have to receive a [quick] response.[10] Then, after four weeks of WMF-non-communication, you made the situation worse. You announced that the WMF was never going to engage in dialog. Any scraps of information you did offer were explicitly useless. After four weeks of the WMF being unwilling to talk, you declared that the WMF was now unwilling to listen. As much as you may believe that the WMF has improved, though this entire process the WMF has refused to engage in any dialog. Zero. Zero is not an improvement. You're here talking about the aftermath, but this discussion is hollow if you insist it will not have any effect. Alsee (talk) 22:46, 22 March 2018 (UTC)
Okay, I can go back to January, if it'll help. This is what I posted in early March: "re: the communication problem. I do apologize for taking so long to respond, it was rude on my part. The explanation (not a good excuse) is that there was a change in leadership in the Product team in late January, and then we jumped into annual planning and budgets, which took my eye off this response. But, yeah, that was rude of me, and not your problem. Sorry again."
If you want more details, I can supply them. I got the position as Director of Product for the Contributors team in mid-January. This position has a lot more responsibility -- instead of just leading the Community Tech team, I'm now responsible for six teams. So I spent a lot of January getting to know all the other teams, and finding out where there were problems that I could help fix. Also, for the last week of January, we had the annual All Hands meeting, which I was helping to run. Immediately after All Hands, we started working on the Foundation's annual plan, which is a lot of work, especially since I just started leading the team three weeks ago. It was a crazy busy time for me.
In early February, I had a discussion with the Collaboration team about this request to uninstall Flow from Commons. It was sensitive and complicated, so I wanted to be involved in the discussions, but we didn't totally agree at the end of the first conversation, and we set up more time to talk later. So I was the bottleneck in early February -- I just had too many things to take care of, and I needed to focus on the annual plan and the budget. I didn't get back to talk to the team about this for another couple weeks. So the team was waiting for me, and they probably didn't want to say "we're waiting for Danny, who keeps blowing us off," which was kind of them. I finally got back to the team at the end of February, and we figured out a response, and then there was the Disneyland trip for three days, so I saved the post for when I got back on March 3rd. I know that it was aggravating to wait for me all that time, and not know what was going on. I did apologize for it, and I apologize again, it was thoughtless of me.
You also say that through this process I've refused to engage in any dialogue, which I have to say, I kind of have engaged in that. That is the thing I've been engaged in since March 3rd. -- DannyH (WMF) (talk) 23:14, 22 March 2018 (UTC)

Gallery pages[edit]

I started a discussion about policy on the use of gallery pages at Commons talk:Galleries, concerning usability and linking to categories. Comments welcome. Cnbrb (talk) 16:42, 13 March 2018 (UTC)

SVG diffs[edit]

SVG is a text based format. It would be nice to easily see diffs between versions of SVG files. Palosirkka (talk) 09:27, 15 March 2018 (UTC)

I don't think anyone would be opposed to this, but it's more of a Mediawiki feature request than a community decision and therefore belongs in Phabricator rather than here. In fact, it's already there – twice (phab:T44566 and phab:T154176 look like duplicates to me). But WMF developers are busy with things we don't want like Media Viewer, Visual Editor and Cross-wiki Copyvios, which means things we do want (like this) gets the priorities "Low" and "Lowest". LX (talk, contribs) 20:00, 15 March 2018 (UTC)

Empower Bureaucrats to revoke Administrator and Bureaucrat bits[edit]

Bureaucrats should be empowered to revoke Administrator and Bureaucrat bits, as they may currently grant those bits per COM:CRAT. Currently, only Stewards may perform this function, and such actions and requests for them are only logged on Meta. See also this edit by Steward @Ajraddatz:.   — Jeff G. ツ please ping or talk to me 17:09, 17 March 2018 (UTC)

Could this be qualified more clearly? In theory, desysop or decrat only happens after a self-request, a formal community vote, after the account has been blocked due to violations per BP (though a desysop vote may still be needed if the circumstances remain controversial), or due to going past the agreed inactivity limits. Are there any more than these four scenarios that a Bureaucrat might remove these rights and stay within policy? -- (talk) 18:05, 17 March 2018 (UTC)
@: There are also emergencies, such as rogue admins and hacked passwords. Allowing crats to perform this function as they close requests removes complexity and lessens workload for both crats and stewards.   — Jeff G. ツ please ping or talk to me 05:39, 19 March 2018 (UTC)
The role of Bureaucrats is not one that handles emergencies, either in theory or practice. Typically, requests at BN wait for days rather than minutes for a response. Both rogue use of sysop tools and suspected hacked accounts require solutions that get applied in the shortest time possible. -- (talk) 20:00, 20 March 2018 (UTC)
  • Requesting it at meta is creating some kind of "separation of powers" and therefore status quo should be keept imho. --Steinsplitter (talk) 18:09, 17 March 2018 (UTC)
Symbol oppose vote.svg Oppose: 'Crat removing 'crat bits. My opinion is that there has to be a level of separation there for security purposes. I'm more meh on 'crat removing administrator bits provided they are doing so in a purely "paperwork" capacity, with notification (at COM:BN), and after ensuring it meets policy. That is how it is done on other projects and it seems to work fine. --Majora (talk) 18:11, 17 March 2018 (UTC)
Symbol oppose vote.svg Oppose; no need, current system is working just fine. —MarcoAurelio 18:15, 17 March 2018 (UTC)
Symbol oppose vote.svg Oppose Given the controversies involving bureaucrats in recent years, no thanks. --Rschen7754 18:25, 17 March 2018 (UTC)
Symbol oppose vote.svg Oppose first of all I doubt the proposal here is intended to only apply on Commons. General discussion of the idea can happen anywhere, but an effective proposal would need to be handled at Meta. Secondly, the capability to remove a bit has much more serious security implications than the capability to add a bit. The very first action by a compromised or rogue account could be to revoke every other bureaucrat and admin. That would instantly kill off the entire population of defenders. In fact I would suggest serious software-enforced rate-limits on any account (even staff accounts) with the ability to remove high-ranking bits. The ability to add bits should also be rate-limited, so a horde of privileged sockpuppet/meatpuppet accounts can't be instantly raised. Is there any valid case where someone should to create or revoke a dozen bureaucrats on one day? Or create or revoke a hundred admins in one day? Security for that sort of mass-change should be rooted in tech staff who have a physical presence at the machines. Alsee (talk) 19:39, 20 March 2018 (UTC)

Proposal to import the English Wikipedia's version of the Module/Template for Reply[edit]

This would involve importing:

{{{{{|safesubst:}}}#invoke:Reply to|replyto|<noinclude>example=Example</noinclude>|max=50}}<noinclude>

The current template is limited to 5 recipients, does not display an error message when cutting off remaining recipients, does not support a chosen display name, and does not use a prefix. With this import, we would be able to: "reply to up to 50 people at once" (if 50 is too high, we could discuss another number) rather than just 5; ping a user & add her/his chosen display name, instead of her/his user name; and specify prefix (specified in the doc, but nonfuctional) parameter, like in en:Template:Reply to. Also, 5 is a low (and odd) number, and ideally there should be an error message displayed when you try to ping more than the supported number, too.

This proposal borrows heavily from Template talk:Reply to. I have brought it here to reach a larger audience. You may be more familiar with one of the following redirects: {{Re}}; {{Ping}}; {{Mention}}; {{RE}}; {{Rto}}; {{Reply}}; {{Replyto}}; {{Reply-to}}; or {{Antwort}}.   — Jeff G. ツ please ping or talk to me 03:53, 20 March 2018 (UTC)