Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Community portal
introduction
Help desk Village pump
copyrightproposals
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?

 

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

RFC/ PROPOSED CHANGE: ART AND 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.

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

NEW SUMMARY OF DEBATE ART & WIKIMEDIA COMMONS[edit]

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[edit]

  • 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):
    1. Remove the example entirely.
      Suggestion (2) from @Colin:
    2. Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills.
      Suggestion (3) from @El Grafo:
    3. Artwork without educational use, including non-educational artwork uploaded to showcase the artist's skills.
      Suggestion (4) 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)
  • Symbol oppose vote.svg Oppose per all the opposes above. Also, to be in scope, a file has to be realistically useful in another WMF project. Where would such files be realistically useful?   — Jeff G. ツ please ping or talk to me 23:08, 24 March 2018 (UTC)
    • Without weighing in on any other issue here, @Jeff G.: I believe you are wrong at that. While use in another WMF project is sufficient for a file to be in scope, even the potential for such use is by no means necessary. For example, we're more than glad to have thorough photo documentation of the public activities of a member of a national legislative body, even though typically only a fraction of those have any potential for reuse on another WMF project. - Jmabel ! talk 04:24, 25 March 2018 (UTC)
      • @Jmabel: Wikipedia has articles on such bodies, their members, their legislation, and their indiscretions. There is no such use case for the OP's works (and the works of others similarly situated), I'm afraid.   — Jeff G. ツ please ping or talk to me 04:37, 25 March 2018 (UTC)
    • To be clear, while this proposal was raised by Gretchenandrew, it is not about their "works". It is about correcting ambiguous and inconsistently applied policy. Whether Gretchen's work would qualify is a completely separate discussion. Striking "obvious" from the example wouldn't then mean that anyone could upload anything for any reason. All other guidelines would still need to apply, including "Must be realistically useful for an educational purpose", as you noted. A very generous reading of your comment could be seen as being in support of option 2 above: Change "Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills." to "Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills." ~ PaulC/T+ 05:55, 25 March 2018 (UTC)
  • Symbol support vote.svg Support El Grafo’s variant. The word “obvious” obviously prompts deletionist trolling. Incnis Mrsi (talk) 06:35, 25 March 2018 (UTC)
    • Just to clarify, do you mean #2 or #3 above? ~ PaulC/T+ 13:45, 26 March 2018 (UTC)
  • Symbol support vote.svg Support El Grafo’s variant. Clarification: Support language such as "Artwork without realistically useful educational use, including non-educational artwork uploaded to showcase the artist's skills." Commons shouldn't be a Deviant Art type repository for artwork with no credible purpose, however the word "obvious" is clearly incorrect. Content is in-scope if there is a legitimate and credible in-scope purpose for re-use, even if that purpose was not immediately obvious. When content is challenged as out-of-scope, a credible rationale is required for how the content is in-scope. Non-notable artwork by a non-notable artist does not, in itself, have any credible purpose for re-use. I'd also like to note that diversity and topic-coverage is relevant. For example the content in Child art is clearly valuable, however there is diminishing value in each additional drawing. In particular, there is approximately value in retaining multiple drawings by the same child. Alsee (talk) 20:26, 25 March 2018 (UTC)
  • Pictogram-voting-question.svg Question Sorry, still not clear. Can proponents of the change give an example of a file that would be allowed with their change that is not allowed now? --GRuban (talk) 14:26, 3 April 2018 (UTC)
    • My understanding is that the arguments for deleting these files are too general. I don't have any specific examples, but I'm sure others that are more familiar with image deletion on Commons can bring some up. I'm hesitant to point to anything uploaded by Gretchenandrew, since that would cloud the debate further. My point is that all other policies would still apply, so why not remove the ambiguous and contentious example if it isn't necessary? ~ PaulT+/C 02:58, 6 April 2018 (UTC)
  • After thinking about this, I don't see the problem with the word "obvious". In fact, this makes the example more restrictive, meaning artwork can only be proposed for deletion if its lack of educational use is obvious (e.g. a personal doodle). By removing this word, any artwork lacking educational use can only be proposed for deletion, not just the obvious ones. So the problem is not the word "obvious" but the subjective term "educational use". We likely can never agree on what is educational or not, so it is better to discuss this on a case-by-case basis. For this reason, I Symbol oppose vote.svg Oppose any change. --P 1 9 9   15:32, 3 April 2018 (UTC)
Well said, the current wording allows a human decision on a case-by-case basis, and that's fine. Christian Ferrer (talk) 17:20, 3 April 2018 (UTC)
Here is the full text of the example in question: Examples of files that are not realistically useful for an educational purpose: Artwork without obvious educational use, including non-educational artwork uploaded to showcase the artist's skills. The key here is "not realistically useful". The word "obvious" makes the example more expansive. That is, it purports that the file should be deleted if it isn't obviously educational. The actual policy states the opposite: The expression "educational" is to be understood according to its broad meaning of "providing knowledge; instructional or informative". There is nothing about the use being obvious. It is a little confusing because of the negative, but that is exactly the point. The example is a poor one and I think it should be removed. ~ PaulT+/C 02:58, 6 April 2018 (UTC)
OK, I see why you would read it that way. But even if we remove the word "obvious" (or rewrite it to "obvious artwork without educational use" - the way I read it), it won't change anything. Educational use would still need to be discussed on a case-by-case basis... --P 1 9 9   18:16, 10 April 2018 (UTC)
I don't see how your rewrite is any better, P199. The word "obvious" is not part of the policy, but "educational" is. Since "obvious" is not policy it should be removed from the examples. It is not any different from having a policy that states "only colorful flowers are allowed" with an example that states "flowers must have obvious color" and then people argue if a flower with shades of light-blue/grey "has obvious color" and since it is not obvious it is therefore against policy and should be deleted. Technically light-blue/grey is a color and the flower is therefore colorful, it just isn't obvious.
People by nature will use the easier to cite (and more restrictive) example instead of the policy, defeating the whole purpose of the broad policy in the first place. In this area the policy is intentionally broad, as stated directly in the explanation of the policy: The expression "educational" is to be understood according to its broad meaning of "providing knowledge; instructional or informative". There is nothing about how obvious the providing of knowledge needs to be, just that it is being provided. Having said that, "realistically useful" is part of the policy. This is not the same as obvious. Lots of things can be realistic but not obvious. (Sadly, I'm currently too tired to find a way to extend my colorful flower analogy to cover this distinction as well.) ~ PaulT+/C 04:06, 13 April 2018 (UTC)
  • I do not see why an unknown (and potentially bad) artist should have his place here; at least this is what I read in the sentence "…including non-educational artwork uploaded to showcase the artist's skills." If it's Picasso, fine, but if it's the husband of my cousin, I'd rather not have his artworks here. --Ruthven (msg) 20:19, 3 April 2018 (UTC)
    • I don't see an argument based in policy. How well known a creator is doesn't really matter as long as the file has an educational use and is allowed under other policies (see also child art). ~ PaulT+/C 02:58, 6 April 2018 (UTC)
Happy that is has been pointed out, and I echo, that the debate about whether or not my particular paintings are educationally useful is a separate, though related, conversation. Removing "obvious" would be an "obvious" first step. Unresolved would be the preference for photography, subject vs object, and the connection to the education of intelligent machines. Maybe another way of raising that would be to say that not all painted images are "art." But I very much support the taking of a first step and removing "obvious." Gretchenandrew (talk) 01:05, 12 April 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)
  • Symbol oppose vote.svg Oppose changes to policy. Commons:Project_scope clearly states that "The uploading of small numbers of images (e.g. of yourself) for use on a personal user page of Commons or another project is allowed as long as that user is or was an active participant on that project." and I think that policy is sufficient. I would not have closed Commons:Deletion requests/File:Lal wilson J.jpg as "Delete", but I was not the one closing it. I assume it was deleted because it was not in use and did not meet requirements of the policy. However If someone wanted to actually use it, I think it would be fine to re-upload. --Jarekt (talk) 16:52, 3 April 2018 (UTC)
  • Symbol oppose vote.svg Oppose the policy change. It's true that a well-categorized photo can be found without being on a user page, but if categories are the only place it exists, it seems like its usefulness is so limited that it's not worth bothering with. If this were to become policy, then image patrollers would have to waste their time perusing people's contribution histories to decide if their contributions are "good enough". It also creates an unnecessary gray area—I can foresee deletion requests where people are debating whether or not a user has made enough positive contributions. This is a silly thing for us to waste time on, especially since the user could just take 5 seconds to put the image on a page, and the whole discussion would become moot. –IagoQnsi (talk) 15:16, 12 April 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)
  • Symbol oppose vote.svg Oppose I prefer file pages with clearly delineated description and license sections. --Jarekt (talk) 16:28, 3 April 2018 (UTC)
  • Symbol oppose vote.svg Oppose, very helpful --Schlurcher (talk) 03:29, 5 April 2018 (UTC)
  • Symbol support vote.svg Support, in Special:Upload. I know I've been caught by the automatic adding of those headers before. It would be great if this more advanced form worked in a more predictable way. I have to abstain from any change one way or the other for Special:UploadWizard because I'm not as familiar with it, though I am inclined to vote to remove the automatic headings from there as well. ~ PaulT+/C 04:01, 16 April 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.[2]

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

Responses (Flow)[edit]

  • 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".[3] 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)
  • I agree with Rschen7754. With all due respect but I find the WMF's defence a bit odd. If uninstalling flow really creates so much problems. Why do it a second time. I would appreciate a statement that there will no more pilots with invasive and hostile software in the future. And let's stop pretending that uninstalling and using a kill switch are the same thing. Perhaps they are the same in developers-jargon but they are not the same for ordinary people. Let’s translate the situation to an everyday situation. Someone installed software you don’t want so you go to the computer store because you don’t know how to uninstall the software. The next day you go back to the store believing that the software is uninstalled because that is what you asked for. To your surprise the personal tells you that the software isn’t uninstalled but they made sure you cannot use it anymore. I can’t speak for the WMF-developers but I wouldn’t accept such a situation. So no, let’s not try to fool us by trying to convince us that uninstalling and a kill switch are the same thing. Natuur12 (talk) 14:50, 26 March 2018 (UTC)
  • Natuur12's comparison appears to be accurate. Flow is still around and visible in various places, where it consumes valuable screen estate and otherwise consumes our limited user resources. For instance I see the namespace in Special:AllPages and a list of titles which, if clicked, present the user with some confusing warnings. Is work still ongoing? Because this seems quite far from the proposed "functional equivalent of uninstalling", which would mean making sure the user can never bump into any trace of Flow from the present user interface and can never tell it was ever installed other than by clicking on actual proofs that it was (such as old URLs, logs). --Nemo 17:52, 26 March 2018 (UTC)

Discussion (Flow)[edit]

  • 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".[4] 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.[5] 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?[6] 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.[7] 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)
@Alsee: Leave it. They have as much as admitted, that Flow is so badly programmed, that it has to be deleted from all projects, where it's not in use, ro prevent it from wreaking havoc there like it did here. Because of this bad programming it can for now only be deactivated to keep the other software from being compromised. Danny apologised for a) being slow and b) not having a better solution, it won't come back here without a proper community consensus,, not even for testing. Yes, a proper uninstall would be the best and most acceptable solution, but as long as the devs are now admitting their bad programming and stop promoting this unretractable software anywhere else, it could be fine. If there is any new project compromised with Flow after now for testing purposes, the AGF-attitude will quickly evaporate, Flow is now officially not suitable for any new project, as it's not possible to get rid of it in a acceptable way after a decision against it.
@Danny: Will you make sure, that Flow will not get installed on any new project until it's really possible to revoke the installation in an acceptable manner (and no, this software switch is just a weak emergency solution, not something acceptable for the future). Grüße vom Sänger ♫ (talk) 05:43, 23 March 2018 (UTC)
DannyH (WMF) as I said, this discussion is hollow if you insist it will not have any effect. When I said dialog, I didn't mean irrelevant chit-chat.
Saying the task was "under discussion", then giving no response at all, created the impression that it was under discussion for a month. But let's say I and others are at fault for filling that vacuum with fears that this was a familiar pattern.
Whatever the reason for the delay, it could have been followed by dialog of the issues and options. But it wasn't. It was followed by an announcement that code had already been built. This created an impression that a "final" decision had been made internally. But let's say that impression was also wrong.
At that point, you declared the radical position the WMF was unwilling to even discuss even leaving Flow installed without read-only, much less any of the issues and options on uninstall itself. And you still won't offer any rationale for that radical stance.
The rationale for not uninstalling Flow appears to be full of holes, but how can we discuss that when you declare (with no basis whatsoever) that there can't even be dialog on even leaving Flow installed without read-only?
Please tell me, at what point was the WMF willing to engage in constructive dialog with the community to sort out what we (WMF&community) want to do? Alsee (talk) 06:45, 23 March 2018 (UTC)

I've just looked around the old discussions I was involved in about Flow, mostly on Lilas talk page in the good, structured layout, not Flow, and came about your name quite some time. I think this here sums up quite good what's to be said about Flow, and Flow hasn't changed so much since then, it's still just useful as a trollspace and for chitchat. What I came about as well was some stuff with the enWP, where you seem to have collaborated with Eric to get more Flow pages against the explicit wishes of the community working over there. That was after Erik declared his open all-out war against the communities with MV/SuperProtect, so everybody @WMF should have been very aware that further acting against the community will not be a good idea and not met with much enthusiasm, but there didn't seem to be any change in attitude at all. There was some delight once Lila declared that failed project as such, but it soon emerged, that it was still developed further, some newspeak renaming of Flow to StructuredDiscussions was done, and it was promoted again quite soon after everybody hoped for a learning curve within the WMF, but there was none. Grüße vom Sänger ♫ (talk) 22:14, 23 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)
I honestly find pinging a steward in case of an emergency quite easy; most likely easier than b'crats ;) --Zhuyifei1999 (talk) 19:49, 26 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>
{{documentation}}
</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)

Add alamy.com to spam blacklist[edit]

Add alamy.com to spam blacklist so nobody can speedy delete images with a link to Alamy. Okay that may be too much. Please see new suggestion below. - Alexis Jazz 02:39, 1 April 2018 (UTC)

Symbol oppose vote.svg Oppose Any issues with these sites does not discount the fact that there are thousands upon thousands of actually copyrighted images on them. Something that would require a link to. The spam blacklist is an extremely blunt tool for something that requires a more surgical strike. --Majora (talk) 03:47, 1 April 2018 (UTC)
Fair point, but I don't think there is any way to blacklist a domain from being used for speedy deletions? - Alexis Jazz 08:29, 1 April 2018 (UTC)
Symbol oppose vote.svg Oppose as per above. Also it doesn't solve anything and goes against the purpose of the spam blacklist. Bidgee (talk) 05:29, 1 April 2018 (UTC)
  • With all due respect, the proposal is extremely poorly considered. An abuse filter against deletion requests linked to alamy.com may be discussed, but setting a spam filter would, as was noticed above, go against the purpose of that tool. It would interfere with future reports about attribution problems on Alamy which may escalate well beyond attempts to sell public-domain pictures, a marginally legal busyness yet. Incnis Mrsi (talk) 11:01, 1 April 2018 (UTC)
@Incnis Mrsi: my idea was a bit more to do this as a stop-gap solution until we can find a better way to handle this, but I now agree it's too much. I will make a new suggestion below Jeff G. - Alexis Jazz 12:16, 1 April 2018 (UTC)
Alexis Jazz, please remove the profanity, thanks. Artix Kreiger (talk) 11:45, 1 April 2018 (UTC)
If it bothers you, you are free to create your own essay, copy mine and remove everything you don't like. There is also Commons:Deleting images based on stock photo sites as an alternative. - Alexis Jazz 12:16, 1 April 2018 (UTC)

New suggestion to achieve the same goal: whenever somebody starts a speedy delete with Alamy link, have a bot converting that instantly into a normal DR and add a comment about Alamy. When a normal DR is started with an Alamy link, let the bot automatically add a comment about Alamy. - Alexis Jazz 12:16, 1 April 2018 (UTC)

The main shortcoming of the bot proposal is that known wiki bots are not real-time. Should Commons develop a new software solution for a problem of very localized significance? Incnis Mrsi (talk) 12:33, 1 April 2018 (UTC)
A manual template text can do the same thing, plus it's easy to search for all open DRs with mentions of the site. However Alamy is not the only mindless aggregator guilty of making money from constructive deliberate copyfraud.
A WMF funded project to engineer a group lawsuit to sue for damages, for a failure to give legal attribution, would be a more politically effective step. -- (talk) 08:56, 5 April 2018 (UTC)
@: What kind of template could ever stop anyone from adding {{copyvio|https://www.alamy.com/stock-photo-alice-in-wonderland1-jose-de-creeft-166890602.html}} to File:Alice in Wonderland1-Jose de Creeft.jpg? Or do we have to add some template to millions of images that Alamy took from Commons? - Alexis Jazz 17:34, 5 April 2018 (UTC)
@Alexis Jazz: we can modify {{copyvio}} using Module:String#find. It can refuse to work when the argument matches a blacklisted pattern. Incnis Mrsi (talk) 17:42, 5 April 2018 (UTC)
@Incnis Mrsi: And I assume the same could be done with other speedy templates (speedy, no permission, etc)? That sounds okay. And the regular deletion template would automatically have to insert a warning that Alamy can't be trusted blindly. I assume that could be done the same way? I suppose I should create a new proposal for that, or if you can perhaps you could make a proposal as you can maybe word it better. But if you don't want to or don't have the time I will also be happy to. - Alexis Jazz 17:50, 5 April 2018 (UTC)
In it, and do not expect that adding this functionality needs much deliberation. Watch {{copyvio}} for an upcoming edit request, and see {{sane mind}} for a filter prototype. Incnis Mrsi (talk) 19:16, 5 April 2018 (UTC)

This all seems like a solution to a problem we don't really have. I live among the copyvios and deletion nominations, and I see far more nominations referencing Alchetron, Mashpedia, Popflock, Readtiger, Revolvy, Wikivisually, Wikivividly and Wikiwand (and every other stupidly named Wikipedia clone in the universe) where the nominator hasn't realised that they are Wikipedia clones. (Clones that often hotlink the very file on Commons that's nominated for deletion.) Is there any evidence that speedy deletions referencing files from these two dodgy accounts on Alamy is something that happens a lot? Often enough to justify obstructing tagging of actual, unambiguous copyright violations from the same site (of which there are plenty)? LX (talk, contribs) 17:29, 6 April 2018 (UTC)

Excellent idea, @Incnis Mrsi: would it be possible to add those wikiclones to the blacklist as well?
@LX: If there is a list of redlinks somewhere (a long list) I could search them. But I could only find something if the deleting admin left a note with Alamy link. At this moment I simply don't even have any usable list of redlinks. - Alexis Jazz 20:03, 6 April 2018 (UTC)
Yes, please, do add this filter. A dozen sites that are known copyright thieves are manageable. Thank you Alexis and Incnis! --GRuban (talk) 20:16, 6 April 2018 (UTC)

If I knew this was happening before today I would have said something. I've responded on template talk:copyvio but I have a lot of issues with this. Primarily the fact that this can all be done with an abuse filter. On the other front, who is going to monitor this new category for the inevitable "lost" images that just sit there because people will tag them and then move on? A change to one of the core templates on the entire projects would need community consensus to implement. --Majora (talk) 20:54, 6 April 2018 (UTC)

Commons:Abuse filter says suggestions can be made on the talk page, but the talk page is just a long list of reports and most don't seem to know what they are talking about. I personally wouldn't suggest a new category, but would force speedy (copyvio/no permission/etc) deletions to instead be made as (or get converted to) a regular DR as these cases are never obvious and require some investigation. - Alexis Jazz 22:45, 6 April 2018 (UTC)
Any admin that knows what they are doing can create a new filter. That talk page seems to be for reporting false positives (or at least attempting to report but in reality is just a black hole for things that will never be looked at). Forcing DRs also shouldn't apply to everyone. Admins and license reviewers (people whose sole purpose is examining licenses) should be exempt. Deletion requests is already a wasteland with requests going back months. Force adding a whole bunch more when a good chunk of them are probably actually copyvios seems like a massive waste of time for everyone involved. Which is why we also need statistics. How often is this actually happening? An abuse filter can tell us that via the logging feature. Charging head long into this without examination is the wrong way of going about it in my opinion. --Majora (talk) 22:58, 6 April 2018 (UTC)
@Majora: But that is part of the problem. I'd love to tell you how often this happens. And if everyone reporting an image would have done so using a DR instead of a speedy deletion, I could. But the result of speedy deletions is that too often there is no way to tell what happened. If Alamy/Granger/Wikiclone links would automatically be surrounded by a warning when used to request deletion (speedy or otherwise) and that link plus filename is automatically copied to some place that is searchable it would make quite a difference for me. I'm not so sure you should exclude admins from this, if every admin perfectly understood all this and was aware of all copyfraud sites perhaps.. but that's not the case.
The simple fact that I can't tell you how often this happens should be a writing on the wall by itself.
And as for the DRs piling up - we all know why that's happening. But there is very little force that tries to fix it. Sadly it's basically just me and my time is limited. - Alexis Jazz 00:13, 7 April 2018 (UTC)
And the abuse filter would tell you how often. With a permanent log. Abuse filters can also display warnings. Just like you mentioned. Again. Altering the copyvio template is not the way to go about doing this. --Majora (talk) 00:18, 7 April 2018 (UTC)
There is also the fact that most copyvio tagging is not done manually but is done with MediaWiki:Gadget-QuickDelete.js. If not the abuse filter route, that should be altered. Not the actual copyvio template. In fact, it would probably be possible to make it so any copyvio tagging done with that gadget defaults to DR. I still believe that we should do an abuse filter though. Again, the rush to alter the copyvio template does not seem very well thought out. There are numerous alternatives to doing that that would be much more effective. --Majora (talk) 00:25, 7 April 2018 (UTC)
Before this discussion I didn't even know about abuse filters. I'm not saying we must alter the copyvio template. I don't really care if this gets realized through an abuse filter, gadget, a template or some other way. So I think we are agreeing with each other. Face-smile.svg - Alexis Jazz 00:28, 7 April 2018 (UTC)
@Majora: both template(s) and gadget(s) should support the blacklist, of course. I can implement it, but not in nearest days because am busy with other tasks. Incnis Mrsi (talk) 09:27, 7 April 2018 (UTC)
you are seeking a technical solution to a human problem (misuse of speedy) how about some training and warning of wrongful deletions? Slowking4 § Sander.v.Ginkel's revenge 03:16, 14 April 2018 (UTC)
Afaik there is no central place to educate admins and you would also have to somehow introduce that training to every new admin that ever gets appointed. Also all admins interpret the policies in different ways. And Alamy is not alone: every admin would somehow have to memorize all the bad stocksites and wikiclones. @Majora: are you working on the abuse filter, or are other steps needed before that can happen? - Alexis Jazz 13:25, 14 April 2018 (UTC)
It is being worked on, yes. --Majora (talk) 20:21, 14 April 2018 (UTC)

Please can FormWizard be installed on Wikimedia Commons[edit]

Hi

I hope this is the correct place to ask, I would very much like to use FormWizard to create proformas for photo essays for the Wiki Loves photo competitions. Photo essays are becoming more popular (e.g Wiki Loves Africa) however they are currently very complex to construct for new editors or take a great deal of time by organisers to make. I think FormWizard would be a very nice way of making this easier to accomplish. It would allow us to create a new page for each photo essay and provide a proforma for the formatting of the page, allowing users to much more easily create the pages themselves.

Thanks

John Cummings (talk) 08:08, 13 April 2018 (UTC)

  • Looks like a good idea, let's do this. Might turn out to be useful for other things as well (Photo Challenge, maybe?) --El Grafo (talk) 09:07, 13 April 2018 (UTC) PS: I guess someone calling this "very complex" is a strong sign for the times when Wikitext was considered a super-simple alternative to html & CSS finally being over. I guess I'm getting old.
  • I agree. Its been implemented on en without any issues. Seems like a natural fit for it to come here as well. ~ PaulT+/C 03:54, 16 April 2018 (UTC)