Jump to content

Wikipedia:Village pump (idea lab)/Archive 33

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61

Doomsday button

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Just get this idea from a dream, what if users could download contributions they have? It would be like the option to download all contributions they make so that they won't feel useless editing wikipedia if wikipedia suddenly gets censored/wikimedia dissolved in the distant future. FYI The name doomsday button also come from the same dream. Regards, Jeromi Mikhael (marhata) 13:31, 3 October 2020 (UTC)

@Jeromi Mikhael: only "your contributions" wouldn't help you read the encyclopedia very easily, but you can actually download the ENTIRE encyclopedia - see Wikipedia:Database download for information. — xaosflux Talk 16:16, 3 October 2020 (UTC)
Like, as our private collection of what have we created? Something like that... I want to keep stuff I've created here offline. Its 11 pm right here and I'm gonna sleep. Would later come back for more explanations.Regards, Jeromi Mikhael (marhata) 16:24, 3 October 2020 (UTC)
@Jeromi Mikhael: for example, you "created" this edit: Special:Diff/981906530 - adding a few sentences, but what you really created was a derivative version of the page at Wikipedia:Village pump (idea lab) as seen here: Special:PermaLink/981906530. You also "created" a new page that eventually became an article, List of members of the People's Representative Council, 1950-1956) - however when you created it it looked like this: Special:PermaLink/814707326 then you and many others further edited it, the page was moved, it was further developed, etc. If this "doomsday button" got created can you be much more specific about what you would want the output to include? — xaosflux Talk 19:35, 8 October 2020 (UTC)
Thank you guys for your advices. Moving and archiving this discussion into my idea box.Regards, Jeromi Mikhael (marhata) 13:00, 20 October 2020 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Redirect button shortcut

I think we should add a button where you can add a #REDIRECT [[]] in the shortcut bar. If you don't know what I mean, here's the "shortcut bar"
File:Screenshot 2020-10-08 at 12.29.36 PM.png
As you can see, the only things in the shortcut bar is <ref></ref> and ~~~~. I personally think we should add #REDIRECT [[]] incase people are gonna make redirect pages --♦/\/\/\TheGeometryDashFan/\/\/\♦ (talk) 17:35, 8 October 2020 (UTC)

If you change click where it says insert and choose Wiki markup instead, there is a #REDIRECT [[]] already. El Millo (talk) 17:54, 8 October 2020 (UTC)
BTW, the name of that bar is mw:CharInsert. WhatamIdoing (talk) 23:17, 10 October 2020 (UTC)
There's also a button in the 2010 toolbar (above the editing area). Expand Advanced, and in the second-row buttons it’s at the right-hand end, between Gallery and Table. (In Visual Editor it’s not on the Insert menu but via Page Settings on the three-lines/burger menu. But that’s greyed out in New Wikitext mode.) Pelagic ( messages ) – (05:00 Wed 21, AEST) 19:00, 20 October 2020 (UTC)

Uploading a file as "own work" is too easy.

I took this photo myself and you can't prove otherwise.

I've noticed more than few occasions where a file is uploaded as if it were an "own work" so it instantly gets copied over to commons when it fact it clearly isn't an own-work. It's either something that could be considered fair-use (logo, poster) that should be uploaded with the correct licence or shouldn't be uploaded at all.

While it causes an issue on Commons, I think the source is nearly entirely people using Upload Wizard on Wikpiedia, so it's on Wikipedia to mitigate it. It occurs to me that claiming a work as your own is a very simple process of ticking the first option on each stage of the form. Uploading a file as "own work" is too easy, people do it without thinking or reading the text next to the boxes they tick.

This problem could be tackled by making that particular work flow less likely to someone not reading the text. Here's some ideas towards that, in increasing order of severity:

  1. The options for "This is a free work." and "This file is entirely my own work." should be at the bottom, rather than the top of their respective list of options.
  2. An extra tick-box to confirm that you understand what you're saying about it being own work.
  3. The field for "How" as in How did you create this work? should be compulsory with a minimum length of 10 characters ("In MS paint" would be sufficient).
  4. The form should require users to type in the exact phrase "This file is entirely my own work, cross my heart." rather than only ticking boxes.
  5. Extreme option: Files marked as own-work should go into something like pending changes review before they are moved over to commons, just to get a second person to check it's plausibly the uploaders own work.

In conclusion, I think it'd be possible to find a change that prevents copyrighted images getting uploaded, but without making it much harder at all for actual own works to be uploaded. Personally I think that 1, and 3 would do the trick pretty nicely. Any thoughts?/Other ideas? (I will claim them as my own, of course). --Paul ❬talk❭ 12:24, 14 October 2020 (UTC)

  • My favorite example of this was somebody who submitted an annotated satellite photo as "own work". Oh, you launched your own satellite to take pictures? Really? The end result was the satellite photo was from some US Government source so it was PD, and they were free to add whatever annotations they wanted, but still needed proper attribution, not just "own work".
But, that's not what I came here to talk about. I know it's not what you asked, but we really need to simplify the page "Upload file" links to. It's got seven choices on it:
  • Click here to start the upload Wizard
  • Commons Wizard
  • Plain form for Commons
  • Old form
  • Files for upload process
  • Plain form for local uploads
  • Old guided form
That's way too many options. I don't even know what most of them mean. It's no wonder people get confused. -- RoySmith (talk) 15:22, 14 October 2020 (UTC)
RoySmith, you're right that it's the whole process, from clicking "upload file" that needs to be looked at - a good UX should funnel users towards selecting the right option, which clearly doesn't happen. And to achieve that, maybe WP could do with retiring some of the options entirely. Paul ❬talk❭ 16:02, 14 October 2020 (UTC)
  • @Paul Carpenter: I'm glad to see this being discussed, and I very much agree it's an issue. The file upload process badly needs a full redesign to modernize it and address a bunch of issues, including the duplication as RoySmith points out above. The one I've been trying to address is that, when you do start uploading a file that's your own work, you have to wait until step 3 to find out that you're actually supposed to do it at Commons, where you then have to start over; it's currently at Wikipedia:User_scripts/Requests#Reordering_file_upload_wizard_steps.
Regarding preventing people from claiming works that are not their own, we'd want to figure out why people are doing it, but I suspect the reasoning is not confusion but more laziness, e.g "I don't want to have to fill out all this complicated licensing stuff, so I'll just mark it as my own work that'll get this form to go away and I'm sure no one will care." To combat that, my thought would be to mimic the style of electronic signature forms, i.e. have them check a box with "I affirm that this is indeed my own work blah blah blah" and then make them write out their name and the date. Those inputs could (and probably should) then be completely discarded, but just having to enter them would hopefully make people think twice. {{u|Sdkb}} talk 03:10, 17 October 2020 (UTC)
Sdbkb, yeah I'd put it down to Laziness. But Laziness or Confusion, they're picking the path of least resistance by selecting first-option→first-option→->first-option. Which is fully understandable: who hasn't clicked Agree without reading the terms and conditions for a free account on something or other? I know some sites try to combat that a little by making you at least scroll to the bottom before the Agree button is clickable but it's still easy to do without reading (or rather, without taking anything in). I think that allowing a free-form answer to "how did you create this" with a minimum length would 1. stop people from auto-piloting through the form, because the form doesn't tell you how to fill it in 2. make it easier to spot when something isn't an own-work (e.g. "I made this by downloading it off google). --Paul ❬talk❭ 10:44, 17 October 2020 (UTC)
Uhhhh...no? The burden of proof for the uploaders of own work is heavy enough for people like me who frequently uploads files to commons. And any admins with common sense could know. So, no. The admins could ask the user first before deleting files. There are enough amount of deletionists in commons to delete files based on no EXIF. And for those who want to request undeletions, the admins are....quite harsh. Defending the image to be kept is better than requesting the image to be undeleted. So...no. Please, for the love of god, don't give anymore bureaucracy for the uploaders here. Admins in Commons and enwiki have brains, and they would utilize those brains at a maximum capacity.Regards, Jeromi Mikhael (marhata) 00:42, 21 October 2020 (UTC)

Urgency Scale

On Wikiproject info boxes, there's a scale for its current rating, (Stub-FA), and an importance rating, but my proposal is these templates should have an urgency rating.

A project should be rated on how much it needs improvement. I'm gonna use video games as an example, its my culture. An article like The Last of Us or Undertale would be low urgency. They are fleshed out, neutral, good citation, a lot of info, etc. There isn't really much improvement needed unless new info comes out. Only re-wording or minor fixes. An article like Rusty's Real Deal Baseball, however, is really lacking. It's an article notable enough, but is only stub class: not much info or citation, improper writing, etc. This article would be an example of mid-high urgency. It's low importance, but needs a lot of improvement, and could be something for a Wikiproject to work on.

This article is rated () on the projects quality scale. This article is rated () importance. This article is rated () on the projects urgency scale?

Any thoughts? Le Panini (Talk tome?) 12:10, 19 October 2020 (UTC)

Couldn't urgency be determined by the difference between the two existing fields? The most urgent would be nearly always be the ones that are low quality but high importance, no? - Paul ❬talk❭ 04:34, 20 October 2020 (UTC)
Agreed. {{u|Sdkb}} talk 06:08, 22 October 2020 (UTC)
  • Both quality and importance ratings are kind of vague. GA and FA at least have specific criteria and get reviewed, but the rest are mostly hit-or-miss. I don't see how adding another vague rating axis adds any real value. And, Paul is right, it's pretty much just the difference of the other two. -- RoySmith (talk) 15:18, 20 October 2020 (UTC)
  • There used to be a category "Articles needing attention from experts in Subject X" - for example, the article on Locus of control was placed in the category "Articles needing attention from psychology experts". This might serve the same function as an "Urgency" rating, and if it is at the end of a main article, might be seen by more readers than an urgency rating on the talk page. However, I do think the idea of having an "Urgency" rating is a nice suggestion. Vorbee (talk) 16:55, 20 October 2020 (UTC)

Notability should come first

I've noticed that sometimes when an article gets tagged for deletion for a lack of notability, the creator says that they're still working on it and will add more later etc etc. I think the problem with that is really that ascertaining notability is really the first thing that they should have worried about. I wonder if page creation guidance should mention that so that new editors don't feel that they've wasted time and effort writing a detailed history of the subject with infoboxes, images, following the MOS and whatnot only to have it tagged for deletion.

An editor that's been through the deletion processes already knows that the process for writing a new article is 1. justify why there should be an article 2. everything else. But I can see why a new editor might not anticipate that. Would it be helpful to have a guideline/essay/whatevs that makes this clear?

--Paul ❬talk❭ 12:51, 21 October 2020 (UTC)

One of the first steps at WP:YFA is to determine if the subject is notable. Where else would you suggest to see this documented? RudolfRed (talk) 17:07, 21 October 2020 (UTC)
(edit conflict) I think that is a great idea. The problem is, how do we get the person who is writing their first article to read it? The usual progress is that they post an article about their favorite garage band, it gets listed at AfD within minutes, and only then do they find out about notability. How to reach them before this happens? An edit notice that shows up when they try to publish the article? How about a collapsed "Thinking about creating an article?" section is our standard welcoming templates? --Guy Macon (talk) 17:10, 21 October 2020 (UTC)
Some ideas: 1. Don't allow non-EC editors to create articles; 2. Modify V to require WP:THREE WP:GNG-satisfying sources for every article; 3. When a user creates a mainspace article for the first time, it should take them to a separate confirmation page (not an edit notice, but a whole page, because mobile users don't see edit notices) with the notability advisory; or, 4. Do #3 with an edit notice but make edit notices visible to mobile users. Lev!vich 17:28, 21 October 2020 (UTC)
What if instead of edit notices, we started putting it into the text box, rather than it being blank - it could start with:
{{short description|DESCRIBE YOUR SUBJECT IN LESS THAN 5 WORDS}}

{{unsourced}} <!-- remove this when you've added at least one source -->
{{notability}} <!-- remove this once you've established notability, read the guidelines for more info -->

'''ArticleName''' is a thing. It is known for...
--Paul ❬talk❭ 18:36, 21 October 2020 (UTC)
I like it! Change "read the guidelines for more info" to "read the guidelines at X for more info". --Guy Macon (talk) 18:55, 21 October 2020 (UTC)
+1 Lev!vich 19:59, 21 October 2020 (UTC)
+2. I suspect that we would also need a tracking category for all short descriptions equal to "DESCRIBE YOUR SUBJECT IN LESS THAN 5 WORDS" . Currently, the New Article Wizard displays Template:AfC draft editintro and preloads the empty edit box with Template:AfC preload. — GhostInTheMachine talk to me 20:19, 21 October 2020 (UTC)
I don't think this will work. I'm pretty sure, in fact, that it won't work. If you think it will, then I'd invite you to look through the articles in Category:Articles lacking sources and untag the ones that contain sources. This search string alone could easily earn anyone another 1,000 edits. Between Banner blindness (which is a real-world thing, not just a Wikipedia thing), worrying about messing things up, the problem that Wikipedia:Nobody reads the directions, and feeling shy of judging your own work, a substantial group of new people won't remove the tags when they ought to. (Also, what if the person wants to create a redirect or a dab page?)
@Paul Carpenter, I had a look at your contributions. You'd been editing for 11 years before you started putting more than one source in the first revision of your new articles. Your undeleted early ones (all on obviously notable subjects) contained zero sources. I don't think that we should necessarily erect barriers against new folks who know as little now as we did back then. This request doesn't seem to me like a request to write about notable subjects. It seems like a request to Wikipedia:Beef up that first revision. WhatamIdoing (talk) 19:47, 22 October 2020 (UTC)
WhatamIdoing, to be clear, it really wasn't sources that I was trying to talk about here. Just CCS. I think this thread has gotten a ways from me a bit. If the consensus is that sourcing should come first then my original premise was wrong and I don't really have much to say on that. --Paul ❬talk❭ 06:13, 23 October 2020 (UTC)
@Paul Carpenter, that makes sense. I've wondered occasionally whether it would be easier to handle articles (especially for any subject covered by BLP or Wikipedia:Notability (organizations and companies)) for inexperienced editors with an UploadWizard-style system. You ask: "Is this about a living person? Okay, what's the person's name? Write one sentence trying to convince other people that Wikipedia should have an article about this person. Name at least three sources, and tick the box that says "Hundreds of words written about this person", "Quoted in the source", "About one paragraph", "Not mentioned by name", "Written by the person (or their employer)" for each source – Thanks, someone will review all of this and get back to you soon with a link where you can start the article, if it qualifies." WhatamIdoing (talk) 15:51, 23 October 2020 (UTC)
I think we've asked for something like that at CommTech at least once now. --Izno (talk) 16:35, 23 October 2020 (UTC)
It would make a reasonable interface for Wikipedia:Requested articles, even if it's not a substitute for creating articles. WhatamIdoing (talk) 20:37, 23 October 2020 (UTC)

new items for contemporary history

hi! I created some new items to help with documenting contemporary history. open to any feedback. thanks!

here they are:

--Sm8900 (talk) 13:40, 22 October 2020 (UTC)

Sm8900, I'm not sure the idea lab is an appropriate place to announce creation of new pages. I'll comment with some thoughts on the talk page, though. {{u|Sdkb}} talk 19:58, 22 October 2020 (UTC)
sdkb, thanks!!! that's a good point. my reason for posting here is simply this; because these are just not new pages; but rather, these are a new type of page and navbox entirely. so your input is welcome. thanks!! --Sm8900 (talk) 22:47, 22 October 2020 (UTC)

Political Userboxes

On 17 September, 2020, an WP:MfD was opened[1] in which user boxes expressing support for the traditional definition of marriage were nominated for deletion on the grounds that they violate the guideline restrictions in WP:UBCR. Boxes advocating support for same sex marriage were pointedly not included in the nomination. The MfD has since devolved into a WP:NOTFORUM train wreck with open declarations that opposition to SSM is an inadmissible opinion and a specie of bigotry. It has been likened by some as the moral equivalent of support for slavery. When challenged, some editors have openly declared their belief that Wikipedia should take sides in divisive cultural/political debates...

  • I honestly can't see how this could possibly be anything but inflamatory, divisive political/religious advocacy, and is pretty explicitly homophobic. That it hasn't been deleted yet says a lot about Wikipedia, none of it good. Adam Cuerden (talk)Has about 7.5% of all FPs 00:12, 17 September 2020 (UTC)
  • Delete all - imagine if it was anti-interracial marriage. Some things, just no. Lev!vich 01:06, 17 September 2020 (UTC)
  • Delete all Divisive, hateful bilge that has no business here. OrgoneBox (talk) 00:24, 18 September 2020 (UTC)
  • As it turns out, some people are concerned that Wikipedia offer a welcoming and inclusive environment. But not to bigots. Zoozaz1, slavery was normal throughout most of human history. It is anathema now because people fought, and often died, to make it so. Gay people are not the only ones whose marriage depends on a Supreme Court decision passed in their own lifetime. Sure, we live in a time when Federal judicial nominees are unwilling to stand up for Brown vs. Board of Education, but in the immortal words of Dr. King, the arc of the moral universe is long, but it bends towards justice. Guy (help! - typo?) 21:45, 21 September 2020 (UTC)
(Re first two sentences.) I can't tell whether this is being ironic. I assume you don't actually agree with trying to drive off editors who oppose same-sex marriage, right? --Yair rand (talk) 21:50, 21 September 2020 (UTC)
If they define themselves by bigotry, sufficiently strongly to add a userbox, then absolutely. They go to Conservapedia. What would you do if anyone added a userbox saying that they believe marriage means two people of the same colour? This is exactly the same. And yes, I do mean exactly the same. Guy (help! - typo?) 21:57, 21 September 2020 (UTC)
@JzG: Independent of the userbox or similar, please. Should we welcome editors with that opinion or not? --Yair rand (talk) 22:01, 21 September 2020 (UTC)
Yes, as long as they don't define themselves as such. If they define themselves by bigotry, sufficiently strongly to add a userbox, then absolutely. They can go to Conservapedia where they belong. What would you do if anyone added a userbox saying that they believe marriage means two people of the same colour? This is exactly the same. And yes, I do mean exactly the same. My recommendation for anyone who opposes same-sex marriage is not to get married to someoen of the same sex. There are no valid arguments to oppose it for anyone else. Guy (help! - typo?) 22:07, 21 September 2020 (UTC)
  • Delete all It's a matter of debate or difference of opinion only as long as we continue to give it legitimacy as such. And it's well past time. World is too big to be fixed easily but, fortunately in this case, Wikipedia is not. Usedtobecool ☎️ 05:39, 22 September 2020 (UTC)
So, to be clear, you are advocating that Wikipedia abandon its longstanding policy of neutrality and take sides in a highly contentious cultural issue? -Ad Orientem (talk) 05:49, 22 September 2020 (UTC)
Blind and absolute neutrality is for the article space. Yes, I am suggesting that we can as a community take a stand outside of the article space and should when it is not that complicated a choice. Best, Usedtobecool ☎️ 07:17, 22 September 2020 (UTC)

The above represents small sampling of the commentary at the MfD.

Some of the comments posted are clearly inconsistent with the project's longstanding neutrality on divisive social/political issues. Suggesting that fellow Wikipedians who are opposed to SSM hold views equivalent to supporting slavery is shockingly offensive and a gross violation of WP:NPA and WP:CIVIL. They represent an ugly tendency to condemn the views of others as outside the bounds of acceptable thought, never minding those views are held by the vast majority of people globally and the followers of most of the world's major religious faiths.

My personal belief is that the boxes in question DO violate both the letter and spirit of UBCR and should go. But we must not allow the project to be identified with one side or another in political controversies. Are there positions that by near universal agreement are beyond the pale and should be excluded? Yes. Slavery has been mentioned and that is under universal condemnation. Open expression of support for social political ideologies closely associated with mass repression, crimes against humanity and genocide, i.e. Fascism, Nazism, and Communism should be proscribed.

But IMO we should simply enforce UBCR stringently and without prejudice. Any political statements in userboxes, excepting the most bland, i.e. "This user is progressive/conservative in their outlook," should not be allowed. I welcome the input of my fellow editors on this topic. However, I remind everyone to be civil and assume good faith. Some of the comments in the MfD are so intemperate and outside the bounds of civil discourse that if I were not WP:INVOLVED I would have handed down formal warnings. -Ad Orientem (talk) 18:43, 22 September 2020 (UTC)


It doesn't stop being canvassing if you disagree really strongly. You're not even trying to frame an ongoing discussion in a neutral way; just going to VP to bang alarm drums, misrepresenting the discussion and cherry-picking quotes. You've already made your case at the MfD (and can continue to do so) and already posted to AN. Others have argued that this should be listed at CENT to get broader input. I don't know that that would be necessary, but seems like an acceptable way to go if people feel like the consequences are disproportionate to the representation. This, on the other hand, is egregious. If you think specific claims are personal attacks/behavioral problems, take it to ANI. — Rhododendrites talk \\ 18:57, 22 September 2020 (UTC)
I think you need to reread WP:CANVASSING as there is not even the slightest chance of my posting a discussion here falling under that definition. Many of the issues raised at the MfD are outside the competence of that forum. This needs a community wide discussion regarding the way we handle userbox advocacy for political causes. I have not pretended to be neutral on this subject. I have stated a position and am highly offended by much of the discussion at the MfD. There is nothing improper about that. -Ad Orientem (talk) 19:04, 22 September 2020 (UTC)
All you've done here is post a list of objections to things people have said and reiterate/elaborate upon your own position at the MfD. Like I said, if you think it's "outside the competence of that forum," you would advertise it, not present a list of specific arguments and grievances about it. If your goal weren't to canvass but to start a new discussion, you wouldn't have included all of your problems with specific things people have said in this case. You've barely even asked a meta question here, nevermind focus on it. — Rhododendrites talk \\ 19:11, 22 September 2020 (UTC)
(edit conflict) Again, you obviously have not read CANVASSING. I have asked for input on the question of how to approach the question of political userboxes. In making that request, I have expressed my own view. If you think I am canvassing... WP:ANI is that way. -Ad Orientem (talk) 19:18, 22 September 2020 (UTC)
I'm surprised you're offended by the suggestion that opposition to SSM is bigotry, but not offended by the suggestion that gay people cannot marry one another. In my view, opposition to SSM is exactly like opposition to interracial marriage. Both, in my view, fall under the category of Open expression of support for social political ideologies closely associated with mass repression ... in this case, the mass repression of gay people and other non-gender-conforming people. So even if we were to make the changes you suggest -- ban political userboxes except those closely associated with mass repression, I would still support deletion of these userboxes on the same exact grounds: opposition to SSM is bigotry, closely associated with mass repression, a violation of human rights, etc. etc. Now, some may disagree with me, but my point is: the change you're advocating is no change at all. You are making a purely semantic argument. There is no way around the community deciding whether a userbox opposing SSM is in the category of allowable userboxes, or outside the category of allowable userboxes, and when people argue that it should be the latter, they're going to base that argument on the belief that opposing SSM is, in fact, an inadmissible opinion. The whole question is whether it's an "admissible" (or "ok") opinion or not; so you shouldn't be offended by people taking either side on that question, or if you are offended, realize that everyone else is offended, too, and thus your singular offense isn't a problem that needs solving. In other words, that you're offended by an MFD discussion doesn't mean there's a problem with the MFD discussion. Lev!vich 19:13, 22 September 2020 (UTC)
Calling other editors bigots because you disagree with them, is not Ok. And FTR, yet again, I affirm my belief that the nominated UBs should go. But the policy needs to be applied evenly. -Ad Orientem (talk) 19:20, 22 September 2020 (UTC)
Oh come on, don't do that. Saying something is bigotry is not the same thing as calling people bigots. The nomination statement (which is not included in the quotes above) is well grounded in existing policy. The same policy applies just as evenly to all userboxes. I would oppose a policy change that would require someone nominating a UBX at MfD to also have to nominate any UBX expressing the opposite viewpoint, which seems to be what you're suggesting should happen here. Lev!vich 19:28, 22 September 2020 (UTC)
Please, stating that somebody's beliefs are bigoted and then asserting that you are not applying the epithet to them personally, is absurd. I don't actually disagree with the narrow question of whether or not the boxes nominated should go. I have stated, ad nauseum, that they should. What I am asking for is community input on whether or not this approach should applied evenly. That is, as you implicitly have noted, outside the competence of the MfD. -Ad Orientem (talk) 19:34, 22 September 2020 (UTC)
It's not absurd at all. There's a huge difference between a "bad person" and a "bad behavior" or a "bad opinion". Just because a person holds a "bad" opinion or engages in a bad behavior doesn't make them a "bad person". And saying that a behavior or opinion is "bad" is not the same thing as saying that the people engaging in the behavior or holding the opinion are "bad". Substitute "bad" for "good" or "bigoted" or "homophobic" or any other adjective and it still holds true. And I agree with applying the policy evenly: we should not allow anti-heterosexual-marriage userboxes, either. Lev!vich 19:46, 22 September 2020 (UTC)
In your culture. AIUI some cultures believe that a person's actions are inseparable from their moral character, and therefore engaging in bad behavior is the same thing as being a bad person. WhatamIdoing (talk) 23:16, 30 September 2020 (UTC)
I guess it depends on which "bad behavior" it is. El Millo (talk) 23:42, 30 September 2020 (UTC)
FWIW, the term for such reasoning is fundamental attribution error. As a general statement, I would also argue that the ability to distinguish between a person's beliefs and the person who believes them, both in the self and in others, is one of the important components of rational discourse. Sunrise (talk) 04:51, 3 October 2020 (UTC)
I agree. And FTR I just deleted all of my userboxes, though I've never gotten any complaints. -Ad Orientem (talk) 19:36, 22 September 2020 (UTC)
Are you limiting the discussion to userboxes? (I'm asking because there are plenty of other ways to express one's political allegiance, by posting words, a picture etc. on one's user page). ---Sluzzelin talk 19:40, 22 September 2020 (UTC)
I am not. Nor could I if I wanted. This after all, The Village Pump. But I would gently suggest that we not stray too far afield lest the conversation become unwieldy. -Ad Orientem (talk) 19:42, 22 September 2020 (UTC)
Ad Orientem, I left the metrics but removed the rest because I think you're right here. Guy (help! - typo?) 16:33, 23 September 2020 (UTC)
  • This and exactly this. SSM is a wonderfully divisive issue in politics today. So are quite a few other issues (and topics). Allowing support of one side only FOR ANY REASON is just going to push people away that are wonderful editors. So just don't allow userboxes on political issues because they WILL end up angering a non-trivial number of editors when their preference isn't allowed. Ravensfire (talk) 20:04, 22 September 2020 (UTC)
  • And, while we're at it, why not get rid of all of such social media paraphernalia from this site and concentrate on building an encyclopedia rather than "expressing ourselves". There are plenty of other web sites for that. Phil Bridger (talk) 20:14, 22 September 2020 (UTC)
  • Political userboxes are inherently divisive and have exactly nothing to do with building an encyclopedia, and should be banned. At the same time, we should avoid the temptation to expand scope and solve a range of related problems in one discussion – "hey X also has nothing to do with building an encyclopedia" – as that inevitably results in "no consensus". Such groups of problems can and should be addressed one piece at a time, and whataboutism is usually counterproductive in these situations. ―Mandruss ☎ 21:04, 22 September 2020 (UTC)
    • I am okay with very surface-level political userboxes (such as "This user is a conservative") as they are far less divisive than those displaying a specific politcial/social viewpoint. However I can see how some userboxes such as the ones being displayed can be problematic. Now editors with controversial beliefs are obviously welcome here provided they abide by our policies, however openly displaying such beliefs easily cause animosity and needless controversy. funplussmart (talk) 00:28, 23 September 2020 (UTC)
  • I share a general skepticism of the value of political userboxes to the project, but I think we need to discuss what exactly we mean by 'political'. The ideal that everyone is free to participate openly and equally, free from derogatory comments about their sexual orientation or gender identity is 1) political, 2) actively divisive in many places in the world, and 3) not an issue on which Wikipedia as an organization is neutral. Specifically, I think we need to be careful to avoid banning expressions of identity or general support for an inclusive project and society, like these:
This user is in a same-sex marriage, domestic partnership or civil union.
This user supports the LGBT community.
--Trystan (talk) 00:57, 23 September 2020 (UTC)
Neither of those boxes appear problematic as they are neutrally worded. Userboxes that support or oppose a specific cause or issue is where things get messy. Supporting the LGBT community is a broad umbrella... supporting same-sex marriage is a specific cause related to the subject. Supporting Evangelicalism is again under a broad umbrella....opposing abortion is another specific cause. Just to give two examples. - Knowledgekid87 (talk) 01:18, 23 September 2020 (UTC)
Trystan, The first would help to avoid trivia errors (e.g. getting gender pronouns right if the user mentions their spouse). The second is generally welcoming to marginalised editors, and neutral towards everyone else. Supporting the LGBT community does not mean, as some seem to believe, trying to persuade everyone to be gay. It means accepting people as they are and as they identify. That is not a threat to anyone, unless they have specifically decided that their identity depends in some part on rejecting the right of others to be different. That is a worldview we call bigotry - and as we see in the news, it also very often means denial, at some level. Regardless, support for people who have an immutable characteristic is good, acceptance is the bare minimum for Wikipedia, and opposing people based on immutable characteristics, demanding that they suppress them or whatever, is unacceptable here. Guy (help! - typo?) 12:36, 30 September 2020 (UTC)
  • I'd be in favor of banning political speech on user pages but what do we do about, say, Black Lives Matter and Blue Lives Matter? I'm not crazy about telling people they can't have Black Lives Matter userboxes. Same with "Free Hong Kong", but then do we also allow "Hong Kong is part of China" userboxes? These always have been and always will be tough questions. Lev!vich 01:33, 23 September 2020 (UTC)
  • This is too broad of a proposal on a slightly problematic premise. The issue in this MfD was infoboxes which may make people feel unwelcome. Generalising this to all forms of political ideology isn't helpful. Per Lev, what about those two examples? There's niche cases of "political ideology" too. This leads down a slippery slope of 'regulating' speech broadly, telling people what views they can and can't hold. How do you deal with non-userbox political statements? Can't limit it to userboxes, that'd be pointless. This is a bit of an exaggeration of the problem imo; if userboxes are a problem, MfD exists. If a user's page is a problem, ANI exists. Is there proof of issues that these two venues can't deal with individual or batch cases? If so, a narrowest proposal (ie, ideologies which promote non-exclusivity / foster a poor collaborative environment) should be made. Trying to deal with all political statements is one heck of a slippery slope. ProcrastinatingReader (talk) 01:44, 23 September 2020 (UTC)
  • Whilst I do think the Userbox guideline has been long ignored, the fact an administrator will go so far to assure Jose who are against LGBT Wikipedians can make that clear on their underpass is kind of shocking. If you were LGBT, got a message from an administrator, and saw one of those services on their page when you clicked over to see who they were, would you feel like you'd be treated fairly? What about a black person who saw an anti-BLM userbox?
Some things shouldn't be in your userpage because they're going to ruin your credibility with minority groups in half a second flat. Adam Cuerden (talk)Has about 7.5% of all FPs 02:38, 23 September 2020 (UTC)
And what of it? You are proceeding from the assumption that the LGBT and BLM issues are settled and that those subjects are not open to criticism. This is exactly why we need to bring an end to political advocacy on the part of users on their pages. Selective censorship of political views should not be acceptable in a civilized and liberal (in the classical sense of the term) society. And it most definitely should not be allowed on Wikipedia. Name calling and demonizing those with differing views should be beyond the pale. Some of the comments at the MfD left me both offended and extremely angry. -Ad Orientem (talk) 02:53, 23 September 2020 (UTC)
both offended and extremely angry Like what? People saying we shouldn't allow others to be openly homophobic in their user pages? Discrimination isn't protected by freedom of speech. El Millo (talk) 03:03, 23 September 2020 (UTC)
WTF? Like comparing people who are not comfortable with SSM to supporters of slavery. That btw is probably close to 2/3 of the world's population. Who gets to define homophobia? Who gets to decide what speech is permissible and not? I feel like I have wandered into a chapter of 1984. Do you have any idea how this comes across as? Millions of my co-religionists were enslaved and murdered for harboring insufficiently progressive beliefs. Some of the things I am seeing written in the MfD and here, terrify me. -Ad Orientem (talk) 03:15, 23 September 2020 (UTC)
Who gets to decide what speech is permissible and not? We do. The community decides what's permissible within the confines of Wikipedia. Do you not consider it discrimination to be against same-sex marriage? Isn't it discriminatory to be against allowing a certain group of people to get married because of their sexuality? comparing people who are not comfortable with SSM to supporters of slavery this is an extreme example, these are different degrees of discrimination directed towards different groups of people. El Millo (talk) 03:47, 23 September 2020 (UTC)
No. I do not. I believe it is discrimination to vilify and silence people because of honestly held beliefs, often of a religious nature. I think it is a specie of cultural imperialism, not much different from the "white man's burden" of European colonialists who saw it as their duty to enlighten the backward savages of the rest of the world. Whether they want to be enlightened or not. I think Rudyard Kipling and Cecil Rhodes would view many of those commenting on the MfD as kindred spirits of a sort. I think the idea of people from the United States and Western Europe passing judgement on the rest of the world and telling them that they aren't really civilized until they are just like us, is just more of the same. How much has really changed... 1890 or 2020? One fifth of the the world's people are still telling the rest how they should live and that their culture is evil.
But since the question of my own personal beliefs have come up, here they are. I am against SSM. I am against heterosexual marriage. I am against marriage in any manner being subject to the laws of the state. The private lives of adults are nobody elses business but their own and those they choose to share their life with. The state should have no say whatsoever. What two or more people do in private is their own affair provided we are talking about consenting adults. The word "marriage" should be stricken from every lawbook and statute. Those who for practical reasons wish to regularize their domestic relationships for benefits or survivor's rights etc. should be able to do so by filling out a form at the local court house and having all concerned sign it in front of a notary public. If someone wants to be "married" then just say you are married to whoever. Assuming the other party has no objections, who cares? If you want some sort of old fashioned ceremony, then just invite your friends over and exchange vows. No need for the state. If you want to be married in a place of worship, that is a private matter between you and your place of worship. If they agree, great. If they don't then you will need to work that out or go elsewhere. Freedom cuts both ways. My church does not marry same sex couples. If you don't like that, I suggest not joining. And now I am off to bed. -Ad Orientem (talk) 04:18, 23 September 2020 (UTC)
Some people oppose same-sex marriage. Some people consider such opposition to be homophobic and discriminatory. Some people consider that belief to be akin to 1984-style totalitarianism and racist cultural imperialism. And so on. This isn't a rabbit hole that has any bottom. When it comes to political debates on Wikipedia, the only winning move is not to play.--Trystan (talk) 12:31, 26 September 2020 (UTC)
Trystan, the reason is, of course, that opposing marriage equality is homophobic and discriminatory, and that is true whatever rationale you might have for it. Yes, there is a bottom: don't tell other Wikipedians that you repudiate their hard-won rights. This week, two Associate Justices of the Supreme Court expressed a desire to remove marriage equality in the US. Another Dominionist who opposes marriage equality is being fast-tracked through the Senate right now. John Roberts dissented from Obergefell. And anyone who's been here ten years or more will probably know at least one beloved Wikipedian whose life would be devastated if they get their way. Guy (help! - typo?) 22:16, 12 October 2020 (UTC)
That statement about "that opposing marriage equality" is not a true fact as you claim but a divisive an inflammatory statement, that makes an unwelcome editing environment for people of widely differing opinion. Hover I think that we should be allowed to have opinions along that line or exactly opposed to it. Some people here may be offended or upset that someone disagrees with them. But just holding or expressing an opinion does not discriminate against anyone. Preventing someone from having or expressing an opinion is what is discriminatory. "hard-won rights" is nothing to do with Wikipedia but is definitely in the political opinion area. What a US court decides really is nothing much to do with userboxes. But we should be able to have boxes that support or oppose particular judges or their decisions, and not be counted as inappropriate for Wikipedia. Graeme Bartlett (talk) 01:29, 15 October 2020 (UTC)
Ad Orientem, marriage is many things. Above all it is a socially recognised commitment that allows families to effectively pool their economic resources for the common good (e.g. giving tax breaks to defray the costs of a partner who stays home to raise children, simplifying inheritance and providing some mechanism for equity on separation). Principled objections to marriage do exist, I doubt anyone would object to a userbox that says "this user opposes marriage". But opposing it only for a minority? Would you support a userbox that says "this user supports overturning Loving v. Virginia"? Guy (help! - typo?) 22:02, 12 October 2020 (UTC)
Guy, no point in pinging Ad Orientem--they've left the building and have turned off notifications. Don't expect an answer from them to your questions. Drmies (talk) 01:41, 13 October 2020 (UTC)
  • While I disagree with Ad on this issue, I really don't think adminship has anything to do with anything here, and in my view that's a bit of a low blow, and counterproductive. Everyone is allowed to have and to express an opinion, especially on controversial subjects, even if they're a sysop. I don't think Ad violated any policies or did anything wrong by raising these issues for broader discussion, and we don't want to have a chilling effect where we discourage admin from expressing their views as editors for fear that someone will say no admin should be expressing those views. In my view it doesn't matter if someone is an admin and it shouldn't be used in an argument unless you're talking about use of admin tools or serious violations of policy, neither of which is implicated here. Lev!vich 03:33, 23 September 2020 (UTC)
    • @Levivich: My point is not to vilify any specific admin. If I wanted to do that, I'd have brought up where I first saw the userbox in question. My point is that it's particularly chilling to minorities participating on Wikipedia if we normalise these sort of userboxes. When I saw this on an admin's page, I was kind of horrified, but I realised the problem wasn't the admin as such - even if it was a poor decision to broadcast them - these beliefs can easily represent nothing more than ignorance. But they're absolutely going to have a chilling effect on LGBT editors. And that's the problem. I don't want anyone banned from the project for having ignorant beliefs that could easily get better in time. It probably says more about their culture than themselves if opposition to same-sex marriage is as far as it goes. But I absolutely think that we need to mitigate the chilling efects of such ignorance. Because having the views probably doesn't harm the project. Broadcasting them does. Adam Cuerden (talk)Has about 7.5% of all FPs 06:10, 23 September 2020 (UTC)

Just a point, trying to be succinct, and then I'll give it a rest with these threads: assumption that the LGBT and BLM issues are settled - none of these social or political issues, let alone racism/homophobia, are settled in the real world. That's true. What is settled is that per our existing policies, user pages are not platforms to express support for discrimination. We are entirely capable of determining, on a case by case basis, whether a userbox falls afoul of WP:UBCR. Where it gets political is when people present say that we cannot evaluate that case because it is a "side". The "sides" are about politics, and are independent of our determination of whether or not something is discriminatory.

An alternative example: "All Trump supporters are [insert insult of choice here]". Very much not ok per our guidelines. What takes it away from the guidelines and into the messy realm of politics is if someone said "well if you're going to delete that, you also have to delete "I support Donald Trump" userboxes because if you delete just one side, then we're in 1984, wrongthink, taking sides, etc. But no, because while you can frame it as "the other side," it's not actually a relevant "other side" for the purposes of our guidelines. There the relevant "other side" would be something like "All Biden supporters are [insert insult of choice here]", which we could also easily assess on a case-by-case basis. In the same-sex marriage case it would be a statement expressing that the only valid form of marriage excludes marriage between one man and one woman. As it happens, that position doesn't exist. In other words, "sides" in politics do not and should not equate to "sides" when applying our guidelines. Just apply the guidelines. — Rhododendrites talk \\ 04:10, 23 September 2020 (UTC)

  • I am an involved party in the MfD discussion. My view is, let's not reduce this discussion into a debate of same-sex marriage itself, but rather focus on whether the userboxes shall be allowed per WP:UBCR (and other relevant policies and guidelines). My view is they do not violate the spirit of the userbox policy. I use the userbox: "This user believes marriage is between one man and one woman" as an example to illustrate my view:
    • Userboxes must not include incivility or personal attacks. The statement in question, This user believes marriage is between one man and one woman displays one's personal belief towards the institution of marriage (grounded on either traditional or religious values), and absolutely nothing more than that. Full stop. Allegations of discrimination are your subjective interpretation of the objective belief of users displaying this userbox. It is perfectly reasonable, and indeed likely, that a person who opposes same-sex marriage, or believe marriage is between a man and a woman, would respect LGBTQ individuals. It follows that there is no "incivility" or "personal attacks" is on display here.
    • "Userboxes must not be inflammatory or divisive." Not everyone would like what I am about to say, but unfortunately, opposition to same-sex marriage is the prevailing view as of 2020, and especially so when you take into account worldwide views on the subject. It is also a view that is NOT contrary to the Universal Declaration of Human Rights (Article 16) or the International Covenant on Civil and Political Rights (Article 23), both of which only prescribed the right to marry for men and women without any limitation due to race, nationality or religion. It follows, from the sheer wording of those well recognized instruments on human rights, that opposition to same-sex marriage simply isn't comparable to opposition to interracial marriage, for example. It also follows that I cannot see how holding a view that is within the reasonable bounds of discourse AND is the prevailing view worldwide would somehow become "inflammatory or divisive".
    • Wikipedia is not an appropriate place for propaganda, advocacy, or recruitment of any kind, commercial, political, religious, or otherwise, opinion pieces on current affairs or politics, self-promotion, or advertising." The statement This user believes marriage is between one man and one woman is not promoting or advocating for any ideology. It is a mere statement of personal belief as to family values, and is NOT intended to promote opposition to same-sex marriage. If there were a userbox stating along the lines of "this user opposes same sex marriage and thinks you should to" then this is advocacy. But what we have here is not.

--Dps04 (talk) 07:31, 23 September 2020 (UTC)

      • I don't think I've ever seen anyone who sincerely believes in the "marriage is one man and one woman" line and isn't, in some way, homophobic, for what it's worth. Sceptre (talk) 07:46, 23 September 2020 (UTC)
  • We should go back to first principles. What are user pages for? They are not for advocacy, they are there to tell other Wikipedians about yourself, in support of collaborative editing. Ultimately there is a difference between saying "I support X" and saying "Y should not be allowed to exist".
    • Saying you support a particular political party or are a member of a particular religion, is acceptable in my view. It contributes to understanding and prevents obvious mistakes (a Republican in the US is different from a republican in Australia, for example, and an English Liberal is different from an American liberal).
    • Saying you support gay rights is acceptable in that it indicates a possible area of editing interest ("I think you might be interested in X article I just created"), but saying "marriage should be between one man and one woman" is divisive and demeaning to gay Wikipedians.
    • Saying "Black lives matter" is OK, IMO, because of course they do. Saying you are a police officer would also be fine, but saying "blue lives matter" is fraught with difficulty because the implicit context for this is "...and Black lives don't". In the same way, an "ACAB" userbox would be unacceptable.
I guess, then, for me, the litmus test is: does a particular userbox tend to include or exclude. A userbox proclaiming membership of the Catholic Church would be welcoming to other Catholics and, I would argue, neutral to everyone else. A userbox proclaiming membership of the Klan would be intimidating to Black Wikipedians and welcoming only to those who agenda is defined by division and exclusion. I think that should be the test. Does a userbox or other user page content serve to foster collaboration, and where it implies membership of an "in" group, would the associated "out" group feel intimidated, devalued or threatened by it. Guy (help! - typo?) 08:05, 23 September 2020 (UTC)
I echo this view. Inclusive userboxes are fine; exclusive ones are not. Guy's examples do a good job of illustrating why. The anti-same-sex marriage userboxes communicate to LGBT Wikipedians that they don't deserve the same rights as heterosexual Wikipedians. This creates a hostile, unwelcoming environment for that group of editors, which certainly runs counter to the spirit of collaboration and harms the project. Messages like that are both inflammatory and divisive, meaning they also violate WP:UBCR. Armadillopteryx 08:49, 23 September 2020 (UTC)
@JzG: How would we apply the test you're describing to userboxes claiming membership in or support for: KKK, Westboro Baptist Church, Christian Science, Jehova's Witness, Mormon, Catholic, Christian, Wahabism, Salafism, Sufism, Muslim? Lev!vich 15:55, 23 September 2020 (UTC)
Levivich, you make a fair point there. Membership is a neutral statement, though membership of the KKK or Westboro Baptist is unlikely to lead to a long and happy Wiki-life unless you never edit on any articles related to race or sexuality. Claiming support for an organisation (implicitly as a non-member) is an advocacy position and I guess it would depend on the exact text. "This user thinks the Klan will Make America Great Again" is different from "This user supports the Klan's right to peaceably assemble"; "This user admires Pope Francis" is different from "This user thinks the Catholic Church should be immune from investigation of sex abuse". In the end anything beyond a neutral statement of membership is going to be viewed in context, and should be weighed against the basic test: does this help us collaborate to build the encyclopaedia? Guy (help! - typo?) 16:25, 23 September 2020 (UTC)
I agree. The issue is not ones political ideology. It is whether their contributions are conducive to building an encyclopaedia. Userboxes are no more special than statements on user pages in this sense. User pages aren't a hosting service. If content on them is unproductive for the purpose of Wikipedia, in this case by making editors feel unwelcome, then it should be removed. I wouldn't say this is "limiting expression" or a problematic attitude to have. Wikipedia has a foundation of openness, especially to openness of information; unnecessary discriminative remarks do not help in achieving that purpose. ProcrastinatingReader (talk) 16:32, 23 September 2020 (UTC)
ProcrastinatingReader, indeed - and even if it were limiting expression, so what? We do that all the time. Wikipedia is not an experiment in free speech. Guy (help! - typo?) 16:35, 23 September 2020 (UTC)
  • Update on status

Scope, RfC topics, next steps, etc.

The initial MfD that started this is now closed as delete. The next step seems to be that some people have identified other userboxes to nominate for deletion. That's fine, but since there's been a lot of talk about a hypothetical RfC and talk of what to do about the same statements made outside of a userbox, it seems like a useful time to start a sub-section.

Case in point, Graeme Bartlett's approach was to circumvent deletion of the template by simply repeating the template's code on his userpage (or an approximation thereof -- I can't be sure). I.e. same as if the template were not deleted.

Personally, I did not see any great need to have an RfC about using Wikipedia user pages to express such views outside of userboxes, but this seems rather against the spirit of the deletion, no? — Rhododendrites talk \\ 02:54, 25 September 2020 (UTC)

We need an RfC about it as this goes against a neutral point of view by getting rid of userboxes supporting or opposing one side of a political issue. I want to repeat that this has nothing to do with what you believe in. It is not our job to state what is right and what is wrong per WP:RGW. Editors should not be pushing their point of view on Wikipedia to invite/welcome like minded people no matter what the cause may be. - Knowledgekid87 (talk) 03:00, 25 September 2020 (UTC)
What RfC question would you propose? — Rhododendrites talk \\ 03:01, 25 September 2020 (UTC)
I am too tired to think up a proposal right now... (going to bed) I welcome anyone to come up with one in the meantime. - Knowledgekid87 (talk) 03:07, 25 September 2020 (UTC)
I've tried to think of one over the last couple days and haven't found an answer, either. We would need to agree on some definitions in order to set boundaries for a question. For example, if you were to say "should we prohibit all political speech on userpages" I don't think it would pass. If you say "should we prohibit using one's user page to make statements supporting discrimination against marginalized groups?" it probably would. But we just saw at that MfD that there was disagreement over which of those categories those userboxes fell into. Getting into "as long as some nontrivial number of people agree with it" seems like it wouldn't go well either.
As Graeme has demonstrated, it would likewise be insufficient to limit these discussions to userboxes, and there's no point continuing to nominate them if anyone can just reproduce them locally. Clearly a userbox isn't actually needed to make the exact same statement -- they just make it easier. We do already have WP:POLEMIC which should, but clearly does not in practice, cover some of this.... it's a tough one. — Rhododendrites talk \\ 03:17, 25 September 2020 (UTC)
Since this deletion is controversial, and is making Wikipedia push a particular partisan point of view, I am sure this debate will continue. Graeme Bartlett (talk) 03:22, 25 September 2020 (UTC)
  • For the record, while I do not dispute with the outcome of this MfD close, given the sheer number of !votes in favour of deletion, I profoundly disagree with the closer's rationale. They essentially summarized the "keep" argument as the argument that pro-same-sex-marriage userboxes would also need deleting for the same reasons. Seriously? I contributed Three large paragraphs of argument substantiating the reason to keep, NONE of which even mentioned pro same-sex marriage userboxes. Instead I explained my view in accordance with the userbox policy, why I believe it is not discriminatory nor divisive/ inflammatory and thus should not be deleted per WP:UBCR. It is of course open for the closer to refute my arguments (or better yet, state how my arguments has been refuted by other participants in the discussion), but NOT to pretend my argument never existed. Having said this though, no I am not purusing a WP:DRV, because I do not think it will be in the interests of the community to re-litigate the issue, and quite possibly convert the DRV into another WP:Trainwreck. However worrying the rationale of the closer is, I accept the verdict of the community is to completely shut down these userboxes. --Dps04 (talk) 04:43, 25 September 2020 (UTC)
  • I have to say that I do find political userboxes useful, in the same way I find blank edit summaries useful: they're a flag. Often, I'll encounter an editor on a talk page for a charged political topic making a, shall we say, highly strained argument for a particular outcome. I'll initially WP:AGF that they perhaps just have an unusual interpretation of policy, but if I check their user page and it's filled with political boxes, that's useful, since it pushes their behavior into WP:SPADE territory, or at the least indicates that they're too blinded by their ideology to look at the issue objectively. I can then choose to disengage with them or otherwise proceed accordingly. Let's allow POV pushers to out themselves. {{u|Sdkb}} talk 20:12, 25 September 2020 (UTC)
  • Just a note that the OP, Ad Orientem, has announced his retirement as a result of the MfD discussion. I dont think this is the right approach to take, but it clearly illustrates that, if the userboxes were "divisive and inflammatory", what's clearly much more "divisive and inflammatory" than that is shutting down opposition towards one side of a controversial socio-cultural debate. --Dps04 (talk) 04:51, 26 September 2020 (UTC)
Frankly, I, and I think a number of other people, would have stopped editing if Wikipedia decided that discrimination was alright and discriminatory views were something to be protected. So please stop the "Oh, clearly ONLY THE DECISION TAKEN would have had negative consequences!" stuff. This wasn't just Wikipedia actively allowing, but Wikipedia actively promoting on Wikipedia-space discriminatory userboxes - because there were whole galleries to grab. There might well be some still. Adam Cuerden (talk)Has about 7.5% of all FPs 18:46, 26 September 2020 (UTC)
You are missing the point of what a neutral point of view means in this case. Discrimination to you means something entirely different to those living in other parts of the world. It is not our job per WP:PROMOTION to set moral standards on what is right versus what is wrong. In any case... the discussion is moot anyone can re-create user-boxes [2]. - Knowledgekid87 (talk) 02:45, 27 September 2020 (UTC)
I think that the Wikipedia community can indeed set moral standards within itself. We do not allow for discrimination in Wikipedia, and there was disagreement over these userboxes constituting discrimination. The wide majority of !votes considered it so, arriving at a consensus that it was indeed discrimination, and concluding in the deletion of the userboxes. El Millo (talk) 03:35, 27 September 2020 (UTC)
Adam Cuerden, I don't mean to suggest that closing the MfD discussion as "delete" is the only outcome which would have negative consequences. What I was saying is, once this discussion is open, the Pandora's box is open and heated debate will definitely ensue, given the controversial nature of the subject-matter. So, if the userboxes are "inflammatory and divisive", having a heated discussion like what we had, and then having such a discussion closed either way (be it "delete", "keep" or "no consensus") would clearly be much more "inflammatory and divisive" to the community, as both sides have strong arguments and more importantly, strongly held opinions. I am not blaming you for having opened that discussion though, since any user in good standing can open a discussion for deletion of userboxes they perceive to be violating WP:UBCR. What I do observe is this: just because having a discussion is permitted within the bounds of the policy, it does not follow that having such a discussion would be in the interests of the community. I echo the words of Jimbo in his talk page: I think that it's bad to allow userboxes on one side of a live political issue, while not allowing them on the other side. -- Dps04 (talk) 04:26, 28 September 2020 (UTC)
  • Can't we just get rid of all political userboxes? This is a giant timesink that contributes nothing to the project. How is it helpful to find out someone you enjoy collaborating with has political views you find abhorrent? Actually, let's just get rid of any userbox that isn't project-related. I don't need to know you went to UMich, either. :) —valereee (talk) 17:49, 28 September 2020 (UTC)
    Possibly, but thus far nobody has offered a workable definition of "political" apart from pointing to what one or a small number of people have already categorized (leaving aside that many of those nominated for deletion weren't even included in those categories/lists). It also doesn't address creating a userbox on one's own page (i.e. not a template), putting the same kind of expression outside of a template on one's user page, or surrounding that expression with a CSS box without using a template. In other words, I'm increasingly of the mind that debates over userboxes are pointless because they're specific to particular kinds of templates when the objection is to what's written inside those templates. — Rhododendrites talk \\ 17:56, 28 September 2020 (UTC)
    Maybe something like "Any userboxes which convey support or opposition to what a reasonable person would consider a contentious political issue are banned. Userboxes which contain statements of identity, such as being LGBT or stating nationality or ethnicity are not banned." The issue I see here is debate over if religion counts. I would argue that it probably should count as a statement of identity, considering how religious discrimination and freedom of religion are strongly protected in most places, but am unsure. Or we could just do away with userboxes entirely, honestly. I used to have embarrassing amounts of political userboxes on my userpage, but I grew out of it. However, just doing away with userboxes does sound somewhat extreme. ThePlatypusofDoom (talk) 18:50, 28 September 2020 (UTC)
    I would support Platypus' proposal. (t · c) buidhe 21:14, 28 September 2020 (UTC)
    This seems like a good proposal, or at least a good start. Similar to the question on religious identity userboxes, would political party identity userboxes be allowed? (e.g. "This user is a Republican") —pythoncoder (talk | contribs) 13:10, 29 September 2020 (UTC)
  • I think we should tend toward deletion of "I believe in X" user boxes. "I am a Y" and "I edit in Z topics" userboxes seem fine from a general perspective. --Izno (talk) 19:22, 28 September 2020 (UTC)
  • Here's an easy test. If there's a userbox, then ask yourself if having a userbox saying the polar opposite would make anyone feel upset/offended/unwelcome/etc. If the answer is yes (and on a hot-button political topic like same-sex marriage, anything beyond a simple statement of a user's status or editing habits, the answer will be yes), then both boxes are verboten. Are you worried that this will limit your ability to tell the world about all the progressive causes you support? Tough. Even so, there's probably room to disagree about how the test applies, but it's a pretty good start. Note that this does still leave room for some political userboxes. It's hard to see how two users, one who supports going back on the gold standard, and one who opposes, would really have any sort of problem with each other – plenty of spirited debate about the topic perhaps, but nothing personal about any of it. –Deacon Vorbis (carbon • videos) 22:22, 28 September 2020 (UTC)
    This seems to be pretty close to Platypus' above, which I promise I came up with independently. Maybe this is a good sign. –Deacon Vorbis (carbon • videos) 22:24, 28 September 2020 (UTC)
    That seems like a terrible false equivalency argument. The most banal userboxes out there "I love Scotland", "This user believes in making Wikipedia a friendly place for new editors", and "This user is against literal Nazis" all fail that. This kind of ivory tower worship of a theoretical perfect, no-consequences free speech utopia really has no place in a pragmatic environment. Some things just aren't equal to their opposite. Hell, several WikiProjects would be banned from having userboxes under this rule - WP:WikiProject Women in Red certainly dare not say they want to improve the presence of women on Wikipedia if they're going to be judged by the opposite, wanting to suppress women on Wikipedia.
    How about solutions that aren't stupid? Adam Cuerden (talk)Has about 7.5% of all FPs 01:45, 29 September 2020 (UTC)
    Wow...spitballing an idea (this is the idea lab after all), and I have it called stupid for my trouble. Stay classy, San Diego! –Deacon Vorbis (carbon • videos) 01:54, 29 September 2020 (UTC)
    Sorry. It's just one of those things that.... well, it sounds good, until practicalities get thought about. It's the Userbox equivalent of that old meme: 'When one person says, "Let's throw 10 puppies in a blender", and the other says "No, that's awful. What are you thinking? Don't do that", the solution isn't to compromise and blend five puppies.' Adam Cuerden (talk)Has about 7.5% of all FPs 02:57, 29 September 2020 (UTC)
    Adam Cuerden, how about striking through your "How about solutions that aren't stupid?" statement? It might be construed as a personal attack... Regards, Jeromi Mikhael (marhata) 02:46, 5 October 2020 (UTC)

Or we could just say two things:

  1. userboxes are containers for expressions, not expressions themselves; if the problem isn't the formatting of how it's displayed, there's no point continuing this discussion in the context of "userboxes" as opposed to specific statements on userpages.
  2. this isn't actually about politics. it's about our fourth pillar. it was always about the fourth pillar. the only reason it has become about politics is because arguing along the lines of the fourth pillar makes the "keep" position more or less untenable. so if you want to keep it and the original framing doesn't work, reframe as being not about the fourth pillar but about picking sides in off-wiki politics. at the end of the day, while it's impossible to remain apolitical, we put our rules and our community above those external debates when it comes to, say, userpages. does a statement negatively affect our attempt to foster a welcoming environment for all groups? if so, external politics is secondary. if "both sides" of an issue aren't actually equal when it comes to the fourth pillar, they have no business being compared here. the only hitch is being welcoming to groups defined by their discrimination or other negative actions towards others (in which case, you're welcome to edit here, but you still have to refrain from expressing those views because this isn't a first amendment exercise, it's a collaborative encyclopedia-writing exercise).
TL;DR - this is about statements on userpages and the fourth pillar, not userboxes and off-wiki political "sides" — Rhododendrites talk \\ 02:20, 29 September 2020 (UTC)
  • Our userboxes typically are the only outlets for self-expression allowed in Wikipedia. Article-spaces should not reflect our views at all, and talk pages mostly reflect policy-related debates and content disputes. When I express my beliefs or interests in an userbox, it is not a declaration that I am trying to push my POV in any article I happen to edit. Similarly, I expect most Wikipedians practice self-restraint when it comes to voicing their preferences. But I do not believe that Wikipedia is becoming a more "welcoming environment" by deciding which political, religious, etc. views are acceptable to others and which should remain hidden under threat of punishment. It is no longer a matter of "external politics" when Wikipedia adopts a clear stance on the matter, and threatens anyone who voices dissent. Wikipedia itself starts playing politics and taking sides. Dimadick (talk) 18:05, 29 September 2020 (UTC)
  • Outlaw all political and social policy advocacy userboxes, and all but the most anodyne religious userboxes; deprecate non-templated position statements on user pages. It's nice to express ourselves on our userpages, and I've butted heads defending redlinked categories as harmless collegiality. But taking a political or social policy position on one's userpage, yes, even a "Je suis Charlie" banner, is divisive to the community. So are religious statements, except for the format "This editor is an X or is interested in Xness". It is my understanding—but I wasn't there, so I may have this partly wrong—that Jimbo deleted all userboxes (or all except the Babel boxes?) for that reason and the community recreated the majority in user space on the understanding we needed to keep them from being nailing of colors to the mast, or they might be deleted again. Usage has crept, and here we are. I rarely agree with Jimbo on anything, but I believe we've proved him right. One editor's proud declaration of their religion or honest statement of their beliefs can be intimidating or even hurtful to another. Once we start deleting them on grounds of inadmissability, we start making judgements about what beliefs or opinions are admissable, and that's not the issue. Or it should not be, because we are not social media, or even a debating society. Our strength is the breadth of our backgrounds, knowledge, and skill sets; I don't want to know what opinions another editor holds, I shouldn't be able to tell from their editing, and I don't want any editor to feel unwelcome here either because of what they see on another editor's user page or because of what they thought they could put on their user page and are told they can't. Once I know someone is hostile to some aspect of who I am, the damage is done. We already deprecate divisive and polemical statements on userpages; we should enforce that by getting rid of all userboxes that violate that principle, fairly, explicitly, and across the board, and by making clear with enforcement action that non-templated statements are inappropriate, too. I have argued along these lines before and been told it will never happen, but I cannot see why it doesn't already follow under policy. If the thought is that we want to be able to identify pedophiles or Nazis, surely non-templated statements give them away adequately? I don't even see why we need an RfC; I consider this is already policy. If there must be an RfC, clearly I'm not the one to write it. But we have the entirety of the rest of the internet to talk about what we believe in and what we despise. Yes, I have a blog. But this is a unique place on the internet and this community exists to work on a neutrally written encyclopedia. Yngvadottir (talk) 00:01, 1 October 2020 (UTC)
    • @Yngvadottir: To clarify, what would you consider to be among "the most anodyne religious userboxes"? Would that include simple self-identification of the "This user is a [adherent of religion X]"-type? I could see such userboxes as being useful for avoiding offence in certain kinds of interactions, as well as occasionally providing Wikipedia-relevant information (eg that someone will be offline on certain days, etc). --Yair rand (talk) 09:19, 25 October 2020 (UTC)
      • I tried to make that clear in my post: the format "This editor is an X or is interested in Xness". Drawing conclusions from "This editor is of X religion" to what days they might be offline is, to me, too much poking into people's personal lives, and only a step away from assuming they cannot be neutral on matters that (some other editor decides) pertain to that religious identity. Again, I thought this was in fact policy; it's the basis on which I chose the userboxes on my own user page in 2009. (I see now I had to use "and/or"; I'd rather have had "or". Non-templated statements are going to be divisive, too; they will always leave some editors wondering about the neutrality of someone who felt the need to state such personal information up-front, and we've seen occasionally from mentions at venues such as AN/I how off-putting either personal statements or belief-related userboxes can be to fellow editors: I'll use the atheism ones as an example. Yes, it's great that we can make our own userpages and not have them dictated to us as on many social media venues. And yes, userpages serve to show our diversity, which is why when I learned about the "userbox wars" I was glad the community defied Jimbo in keeping them (at least that's the version of the history I heard). But anything resembling staking one's colors to the mast, or which could be interpreted that way, is divisive and I do believe it's still technically forbidden. And hurts the community far more than many of us realize. Yngvadottir (talk) 19:52, 25 October 2020 (UTC)
  • Unfortunately, trying to ban "political" or "divisive" userboxes is much too open to interpretation, and disputes about interpretation would themselves likely bring people into unproductive arguments. We need something more general and unambiguous. I suggest that the problematic userboxes are those which are used to advocate for or against, or express support for or opposition to:
    • Any piece of legislation, government policy, system of government, political candidate or party, or government agency/organization;
    • Any military or paramilitary group, or participant in any armed conflict;
    • Any state or government;
    • Any political-ideological movement or social movement;
    • Any religion, religious stance, moral stance, or demographic group.
  • Does that cover most of it? Definitely needs some fine-tuning, at least. --Yair rand (talk) 08:31, 1 October 2020 (UTC) (Edit: Added "moral stance" and "government policy". --Yair rand (talk) 08:53, 19 October 2020 (UTC))
      • That's excssively prohibitive. You couldn't even say "I'm a Christian" or "I'm an SNP supporter", or even "I'm a proud Scot". We should be limiting as little as possible, not banning even the most uncontroversial things in a misguided effort at fairness. Adam Cuerden (talk)Has about 7.6% of all FPs 19:36, 2 October 2020 (UTC)
        • I don't think editors should be allowed to say on their user pages, for example, "This user accepts Jesus Christ as their savior" or "This user does not believe in the magic person in the sky", any more than "This person defines marriage as between one man and one woman" or "This person endorses the inviolability of Eretz Yisroel" or "This user is a Communist" or "This user is a monarchist". (I was avoiding giving examples because we have allowed policy to creep such that editors can reasonably expect to be allowed all of those, and only one of them has now been outlawed by consensus.) That means we should not permit "This user is a Christian" or "This user is a Social Democrat" either. Fair's fair, and as I say I believe that was the original position hammered out at the end of the user box wars, with only Babel boxes, positions on editing such as "This user thinks all editors should be registered" and "This user is a deletionist", and anodyne and somewhat edit-related things like "This user is from Zambia" and "This user is a Moslem or is interested in Islam" allowed. Fair's fair, and all my first examples are divisive and are hurtful to some editors. (We have the whole rest of the internet to identify what side we're on. And, I'll add, to tell everybody who we are; there should be no pressure to do so here, it reduces safety.) Yngvadottir (talk) 00:05, 5 October 2020 (UTC)
        @Adam Cuerden: Re religions: Maybe we could make a distinction between "This user is a Buddhist/Wahhabist/fundamentalist Christian/etc" and "This user thinks than [religion] is great/awful/(has some positive/negative quality)"? (It's extremely important that we don't end up with a situation where we place a religion "on trial", so to speak.)
        On nationalities, I'm unsure of whether we'd want to generally allow people to express pride in their country. If there was a country that went extremely evil (and, of course, the community was unable to determine this at the time, as things often tend to be), would we be harming the project environment by allowing such expressions? Compare, eg an anachronistic c. 1940 "This user is a proud German" userbox. Not the same as supporting Nazis, not even equivalent, but could it be problematic? What do you think? --Yair rand (talk) 20:45, 12 October 2020 (UTC)
      • Yeah, I think it's not that hard. If something clearly advocates for discrimination, exclusion or violence, then it's not allowed. If something is a bit more ambiguous, we start a discussion, as we did with the "marriage is between one man and one woman" userboxes and as it is currently being done with the anti-Zionist userboxes and the like. Most editors clearly thought the former was discriminatory, while most editors thus far are considering the latter not discriminatory and it seems less controversial overall, judging by the amount of participation. El Millo (talk) 19:53, 2 October 2020 (UTC)
        @Facu-el Millo: Do you think that the community can accurately assess whether supporting/opposing any particular legislation, government policy, or candidate is discriminatory? Could any other cultural group in history do this? Consider, for a moment, the differing results that would come from having some random cultures (present or past) either have broad rules or do things case-by-case. I suspect that if, eg, a bunch of Indonesians, Russians, Nigerians, or even 1990s Americans were to try to identify discrimination in legislation on a case-by-case basis, the result would be not match up with what people here want. Given that it appears that essentially every culture in history seems to have both giant blind spots about which things are discriminatory and unawareness of said blind spots, maybe one shouldn't assume one's own group to be the single culture/time period combination that is somehow immune here?
        And what if we aren't just worried about discrimination? What if, per Rhododendrites, we try to have userboxes abide by the fourth pillar and look at this from the angle of being civil, welcoming and respectful?
        In that case, among the things we'd want to avoid is implied hostility, intended or not. Unfortunately, politics is rife with it. Many (most?) expressions of political ideology have some significant group of people who genuinely feel that the position is based around hating them, or otherwise feel alienated by it. (Eg, the idea that anti-abortion people hate women, the local separatist group hates the people outside the associated region/culture/ethnic group, the irredentist hates the people on the other side of the border, people taking whatever side on an issue of religion-and-state either hate people from the relevant religious group(s) or everyone outside of it... There are plenty of others, and people tend to be really bad at determining which specific things will be taken in that manner, particularly those applying to either positions they like or groups they dislike.)
        Community neutrality is important. Probably the most important factor here, in my opinion. But even if you were to ignore it entirely, consistent application of the idea to prioritize being welcoming over ensuring visibility of bias would lead to the same outcome. If you want a welcoming environment, and if you want people to get along with each other, having people introduce themselves with their political opinions is a terrible idea. --Yair rand (talk) 08:27, 7 October 2020 (UTC)
        • I think that the Wikipedia community can decide for itself what it will and won't accept. The line is fuzzy, so deciding on a case-by-case basis when it's unclear is the best thing I can think of. Removing anything political seems excessive, and then we get in the territory of what's political and what's not and we're in the same situation as before, but even more subjective and complex. I think that what we're currently doing will work just fine. In my opinion, being civil, welcoming and respectful is for users to be able to generally express their ideologies and opinions, but drawing the line when it advocates for, say, denying someone civil rights because of their identity, as a recent example. And I think the way to distinguish what is simply an ideology or opinion from what is an attack on someone else is by discussing and reaching a consensus (or lack thereof) for each case, which can of course establish a precedent for other discussions that come afterwards. El Millo (talk) 14:27, 7 October 2020 (UTC)
    Yair rand, there's the germ, of a good idea there. If a 501(c)3 could not do it, a userbox probably shouldn't either. Guy (help! - typo?) 22:51, 2 October 2020 (UTC)
  • Delete all political userboxes. These are outside the purpose of Wikipedia, and encourage people to use it as advocacy for a cause. If all you are interested in is advocating for a certain viewpoint, you shouldn't be on Wikipedia. This can be done by updating the relevant policy, and notifying new users that they should not create political userboxes, with a warning. I think statements of religious belief are okay because that's often part of a person's identity, although I would be open to removing them as well. —Naddruf (talk ~ contribs) 04:09, 3 October 2020 (UTC)
    I agree that the best way to solve this issue once and for all is to Delete all political userboxes. It is difficult to draw an unambiguous, yet widely accepted, non-arbitrary line between what constitutes discrimination and what is not, or what is within the acceptable bounds of political discourse and what is not, as people have wide-ranging opinions on that based on their own values, cultures and experience. However, I am anticipating a fair share of opposition if this gets proposed. This will not be the first time the encyclopedia will have proposed to make such a ban, and the last time it was so proposed didn't end so well. -- Dps04 (talk) 04:56, 3 October 2020 (UTC)
    Just going to one more time point out that the issue is particular kinds of statements, not how they're formatted on a userpage. As such, any RfC that targets only userboxes doesn't actually do anything when someone displays the exact same thing using a different template or no template. I feel like I've said that a few times now, so I'll keep quiet for now, unless someone makes the mistake of forming an RfC that's only about userboxes. — Rhododendrites talk \\ 05:22, 3 October 2020 (UTC)
    It rather feels like this is all going to develop into an over-broad proposal, and get rejected. If you want this to pass, you need to come up with some very tight requirments. Adam Cuerden (talk)Has about 7.6% of all FPs 16:56, 3 October 2020 (UTC)
    Well, a simple statement on a userpage is obviously just that user, but a userbox has an air of at least semi-officiality that could be seen as Wikipedia supporting their position. --Khajidha (talk) 19:55, 3 October 2020 (UTC)
  • Delete all userboxes - Anything that they convey that might be relevant to your work on Wikipedia can be stated in prose and anything that isn't relevant to your work on Wikipedia doesn't belong here.--Khajidha (talk) 12:28, 3 October 2020 (UTC)
This is explicitly not a vote. This is where to come up with the proposal being moved forwards. Adam Cuerden (talk)Has about 7.6% of all FPs 20:14, 3 October 2020 (UTC)
And this is my proposal. It is absolutely impartial and simple to determine if it applies. --Khajidha (talk) 21:17, 4 October 2020 (UTC)
  • I think we shouldn't have any big shit about politics until the US election (including big shit about whether or not any given shit is politics). People (specifically Americans) tend to become quite mentally confused and agitated around this time every four years, and I'd go so far as to say that this election contains at least as much bozosity as the previous four combined. It's like lycanthropy, except for being angry about politics. One editor (with more than fifty thousand edits) seems to have already left over this discussion. Obviously, it's unreasonable to expect a whole drama to be postponed for upwards of a month, but in all seriousness, I think everyone ought to at least take into account the sheer amount of Mad Online Syndrome that's currently perfused into all corners of the Internet before evaluating the posts here too harshly. jp×g 12:01, 4 October 2020 (UTC)
  • Delete all political userboxes. I bet a majority of them fall into WP:UP#POLEMIC and WP:UBCR in some way shape or form. The one at a time deletions also threaten Wikipedia's stance on a WP:NPOV (WP:5P2) "Editors' personal experiences, interpretations, or opinions do not belong on Wikipedia." - Knowledgekid87 (talk) 18:58, 4 October 2020 (UTC)
    • The NPOV policy in a nutshell states: Articles must not take sides, but should explain the sides, fairly and without editorial bias. This applies to both what you say and how you say it. NPOV applies to articles, not to the community as a whole or to userspace. These one at a time deletions are helpful to see what the members of the Wikipedia community consider to be too much or too far. Since not everyone agrees on what constitutes discrimination or advocates for violence and what doesn't, those who are interested participate in a discussion, and then a consensus emerges. There was a consensus in favor of deleting the "one man and one woman" userboxes, and a consensus seems to be forming in favor of keeping the anti-Zionist and similar userboxes. El Millo (talk) 19:15, 4 October 2020 (UTC)
Move this to meta's RfC Honestly, if we want to make Wikipedia inclusive, why not apply it evenly? Why only in English Wikipedia? We should've gone with Meta instead to discuss this. Userboxes aren't only being used in english wikipedia, a lot of other wikipedias probably have one or similar. A policy about inclusion and exclusion should be applied Wikimedia-wide rather than Wikipedia only. It'll be weird to see users getting confused about "Hey, why I can't express that in [insert language] Wikipedia? I could have that in [insert language] Wikipedia!" Regards, Jeromi Mikhael (marhata) 00:03, 5 October 2020 (UTC)
  • Delete most political userboxes. The heatedness of the MfD that led to this, and others like it, is worrying. Personally, I don't particularly care if another user has an extreme opinion; in fact, it'll probably help me understand why they may have made certain edits. But I recognize that others would be discouraged or angry from seeing another editor who opposes SSM, for example, and that matters.

I see userboxes as at the intersection of self-expression and helping us build an encyclopedia. When I see "This user plays the oboe", that means might ask them for advice about oboe-related articles. "This user is female and prefers she/her" helps us address people properly in discussions. "This user supports/opposes the right of gay people to marry" doesn't really help us in such a way, and apparently serves to divide us, which is truly sad.

Now, there's no need to ban non-political userboxes that don't help us encyclopedia-wise, because they are pretty harmless. Also, I'd be okay if political userboxes which have near-unanimous support, or are benign, were kept. Like "This user despises Holocaust denial" or "This user opposes miscegenation laws." But if a userbox does not have near-unanimous support—yes, including "This user supports the right of gay people to marry"—I think it should not be kept. This could be determined case-by-case, but honestly we have better things to do with our time.

Examples of things I think are okay:

  • "This user is interested in Black Lives Matter." Tells us about what articles they are interested in editing.
  • "This user is interested in Nagorno-Karabakh."
  • "This user is married."
  • "This user is a vegetarian." Non-political.
  • "This user supports the right to free speech." Nearly unanimous.
  • "This user has a conservative outlook." Pretty benign.

Examples of things I don't think should be allowed:

  • "This user supports/opposes gay marriage."
  • "This user is in a heterosexual/same-sex marriage." Makes a point about a controversial issue.
  • "This user supports/opposes gun control in the US."
  • "This user hates the European Union, and recommends you burn your Euros."
  • "This user voted for Joe Biden/Donald Trump."
  • "This user supports/opposes restitution for descendants of slaves."

tl;dr: In summary, I think an expression of interest in controversial topics, where opinions on the issue do not have nearly-unanimous agreement, is fine, but an expression of opinion is not. I know it would ruffle some feathers that "This user supports Black Lives Matter" would be disallowed, but I think we need to remember what we're here for... making a neutral, reliable encyclopedia for the world, not furthering or expounding our opinions of the world to our peers. Sincerely, Ovinus (talk) 08:28, 6 October 2020 (UTC)

TALKFORK from VPPOL

A sizeable talkfork occurred at WP:VPPOL#Disallow political opinion and userboxes on userpages. Leaving a note here for if/when this earlier discussion continues. --Izno (talk) 14:20, 7 October 2020 (UTC)

A tool to help find a good/featured article companion for non-featured articles

I suspect that most of us experienced users know that one of the best ways to improve an article is to locate a featured article for a similar topic to use as a template/inspiration. But new editors are likely to find it very difficult to locate the featured article directory, if they even know about the concept of FAs/GAs at all. If it would be possible to program, I think it would be extremely useful to have a tool that could show up somewhere on talk pages that'd use a search algorithm to identify the FA most similar to the article (or, if no featured article is similar, the most similar GA). It could then prompt editors with something like Looking for ideas to improve this page? Check out Foobar, a high-quality page on a similar topic. Do you all agree that this would be useful? And if so, how hard would it be to create? {{u|Sdkb}} talk 20:21, 25 September 2020 (UTC)

I like this. How about adding two check-boxes to the Wikipedia search engine, one of which added "incategory:Featured_articles" and the other which added "incategory:Good_articles" to the end of the search request?
For that matter, change the way Category: pages work so there is a "search only this category" search bar, with an optional "search sub-categories up to x layers deep" where X limited to something reasonable maximum, say 2 or 3. davidwr/(talk)/(contribs) 21:05, 25 September 2020 (UTC)
I'm not sure it would be useful frankly. Often the most "similar", if all text is searched for word matches, will be a different type of article - an actor rather than a film say. Is this really a big problem? There aren't so many FAs in particular that they aren't easy to find for a particular sort of topic. Johnbod (talk) 03:30, 28 September 2020 (UTC)
A "find similar articles" tool would be useful: something that would, say, find articles with the same or similar infobox template, categories, and WikiProject banners, with filters for quality or size. Basically an automated/prefilled WP:PET or quarry: Lev!vich 05:03, 29 September 2020 (UTC)
Yes, I agree! Sorry to jump on this idea wagon, but it is also better to have a similar thing such as this when we want to create an article. For example, we could have an article creation tool where we could put the relevant tags and then wikipedia would recommend high quality article in which we could copy and paste the format of the high quality articles to our article. If we want to create an article about a city, then it would show us a list of FA and GA articles about city. Regards, Jeromi Mikhael (marhata) 23:42, 4 October 2020 (UTC)
@Jeromi Mikhael: I definitely agree that it'd be helpful to offer more templates for the creation of certain kinds of articles, and FAs are good for certain kinds of things like categories. There is a bit of a problem in that many FAs were created way back when the threshold was lower, and thus contain outdated code, and they tend to be very long. What I tend to look for for copying and pasting when creating a new article is not an FA in the area, but a small new article in the area created by an experienced contributor. {{u|Sdkb}} talk 19:37, 6 October 2020 (UTC)
Sdkb, I like the general idea, as I often talk to new editors, and encourage them to look at an FA or GA relevant to their area of interest. I've typically done the search myself, and think it would be nice if it could be automated. I'm not sold on the concept of using the text of the article to identify the appropriate FA or GA. My first thought is that identification of categories might be the best way of doing the search. S Philbrick(Talk) 00:00, 20 October 2020 (UTC)
This is a very good idea- in addition to your rationale, it is also a chance to make new users aware of FAs and GAs. Bzweebl (talk • contribs) 05:57, 26 October 2020 (UTC)

Demonstration Website Timelinesinhistory.com for Inclusion of Timelines in Wikipedia

Timelinesinhistory.com is a HTML/JavaScript/AJAX (with a swappable AWS Redshift, Azure, MySQL, or SQL Server backend) enabled website that presents any historically oriented textual information contemporaneously on an attractive horizontally (or vertically) scrollable timeline. The technology we have developed takes any Wikipedia article, parses the dates from text, and refactors it to be placed on a timeline (with little to no human intervention).

All the technology utilized is non-proprietary.

Any timeline can be displayed in any browser by placing a small amount of code on any Wikipedia article. We recently published this website as a demonstration of its feasibility. Any user can create as many timelines with as many Wikipedia articles that they wish. We believe that any Wikipedia article can include a timeline in a [show] tag at the bottom of any Wikipedia article. The user(s) can then add any other Wikipedia article in the displayed timeline for contemporaneous historical analysis. We believe this to be a very desirable tool for educators in the fields of History and Social Studies.

In 2017 we used our text/date parsing technology demonstrated at timelinesinhistory.com to parse 38 million dates from 26 million paragraphs from the English Wikipedia. A summary of our efforts can be found at:

https://en.wikipedia.org/wiki/Wikipedia:Dates_in_Wikipedia

You may download all dates in the English Wikipedia as of February 2017 here:

https://drive.google.com/u/0/uc?export=download&confirm=4aw5&id=0BwW3GI4uVWLjeVA5R2cwQmNzUFk

Timelinesinhistory.com is easy to use and helpful to the users understanding of history. You may add any Wikipedia article to any timeline by selecting “Add an article” to any timeline. We seek to add one timeline to one [show] tag in one Wikipedia article.

In Summary:

We believe Wikipedia is one of the great treasures of our information age. We seek to make it even more informative concerning historical analysis. We think that Timelinesinhistory.com is a good demonstration website of how Wikipedia can more effectively communicate historical information.

Sincerely

Jeff Roehl

Lead developer

timelinesinhistory.com

5345 Heatherdowns Blvd, Toledo, OH 43614

wikitimelines@outlook.com

(812) 458-4065

Jroehl (talk) 19:56, 22 October 2020 (UTC)

Wikipedia editorial compass

How much of a fight would this cause ?Regards, Jeromi Mikhael (marhata) 02:37, 23 October 2020 (UTC)

Jeromi Mikhael, your idea has two axes. I think you might want a third: m:immediatism vs. m:eventualism. Also, deletionism vs inclusionism is complicated by m:mergism, which is neither, and there are two sub-styles of inclusionism, which you might think of "as many articles as possible" vs "as much content as possible". I'm not sure how to explain that clearly, but think about one editor saying "This small business is borderline notable, so Wikipedia should include a separate article about it" vs another saying "This small business is borderline notable, so Wikipedia should include at least a paragraph about it somewhere, maybe on a List of small businesses in Hometown". WhatamIdoing (talk) 15:45, 23 October 2020 (UTC)
Didn't we stop (at least most of us - there are some well-known throwbacks around) defining ourselves by such labels over a decade ago? Nobody should pretend that anything as grand as a "philosophy" has any place in a mundane process like editing Wikipedia. Phil Bridger (talk) 16:50, 23 October 2020 (UTC)
Well, we still do use one label for ourselves, this one . davidwr/(talk)/(contribs) 16:54, 23 October 2020 (UTC)
Not all do so, see Category:Wikipedians who are not a Wikipedian! (A protest category against the majority of Wikipedians who cannot accept minority point of views) And there are yet more kinds: Category:Wikipedians with unconventional user categories Graeme Bartlett (talk) 21:38, 24 October 2020 (UTC)
Touché. davidwr/(talk)/(contribs) 22:50, 24 October 2020 (UTC)
I mean, I'm lazy so I call myself an inclusionist, but we a) sit in very broad churches b) simultaneously sit across different groups (my analogy fell apart rapidly there); c) as said above, we don't even get everyone into those broad camps Nosebagbear (talk) 22:19, 26 October 2020 (UTC)

The policy regarding edit/revert cycles

Hello, I would like some guidance from some of the seasoned editors here around 2 questions. Q1: If person A makes an edit on a page, and person B doesn't agree with the edit, is the proper course of action for person B to start a talk and invite person A for a discussion to clarify, or can person B revert the edit unilaterally? Q2: If both parties are not agreeing on an edit/revert, what is the policy (or advise) in order to prevent unproductive cycles of edit/revert? Thank you!--Sataralynd (talk) 16:09, 26 October 2020 (UTC)

@Sataralynd: Either way works. B may start a discussion on the talk page or B may revert the edit without discussing first. If A wants to put the edit back, A should start a discussion on the article's talk page. See WP:BRD. Don't enagage in an edit war, the general rule is WP:3RR. If there is problems reaching consensus, follow the guidance at WP:DR to resolve the dispute. RudolfRed (talk) 16:31, 26 October 2020 (UTC)
@RudolfRed: thank you. Follow up question please. What if A starts a discussion but there is a lack of engagement from B, who goes on and makes changes on open and contentious topics without having consensus, and carefully sidesteps the 3RR? In other words, in these cases, is there a way to engage other editors and try to resolve the conflict, or say increase the restriction on the article to avoid PVO-pushing editors from engaging in such behaviours?--Sataralynd (talk) 02:29, 30 October 2020 (UTC)

Idea - merging WP:F9 and WP:G12

Both are for copyvios. My impression is that one is generalized to any page, including files, that violate copyright, and another is just for files. I think F9 should be merged with G12 as one is more generalized than the other. It is also less tracking we need to do. We can redirect F9 to G12 and use template logic to display the appropriate text and notice on files. Aasim (talk) 21:10, 28 October 2020 (UTC)

Also, feel free to move this to Idea Lab if this proposal is not quite ready. Aasim (talk) 21:11, 28 October 2020 (UTC)
Awesome Aasim, I moved this. I have some concerns but let me do a little homework to articulate them properly. S Philbrick(Talk) 21:34, 28 October 2020 (UTC)
Awesome Aasim, I do appreciate that both F9 and G12 represent potential violations of our copyright policy. For this reason I presume you think that we would be better served by combining them rather than treating them separately.
I have some concerns, and think these concerns should be discussed before simply voting yes or no.
Simply stated, F9 refers to purported copyright violations associated with files, while G12 refers to purported copyright violations of text. while both are purported violations of a single policy Wikipedia:Copyrights, I think there are some differences and we ought to discuss whether these differences are significant enough to retain the different groupings.
My editing history includes working on both groups, but my experience is that I approach the two issues differently. My guess is that my general approach is similar to that of others who work in this area. When I see a G12 nomination, there are a few steps I typically work through to determine whether it is a false positive or a violation, and if a violation, there are additional steps to determine how to cure (deleting the article is one option but there are other options). In contrast, if I'm looking at a file with the potential copyright issue, the investigative steps are different.
For better or for worse, when I decide to spend some time contributing to Wikipedia, find it helpful to spend a chunk of time on similar issues. If I'm working on reviewing G 12s, I get into my text copyright routine. If a list of potential items included both textbased articles and files, I'd either have to switch gears every time a transition between text and files, or find some way to separate them out. They are currently separated out so it's easy enough to work on textbased, or image-based depending on what I feel like working on at the moment.
Note that Category:Candidates for speedy deletion Not only lists G 12 and F9 in separate subsections, but displays the image for F9. If the two are merged, we might lose this valuable feature or have to figure out how to re-create it.
This is hardly a make or break issue, but I see it as a small negative while combining them would require some work for what benefit? S Philbrick(Talk) 21:57, 28 October 2020 (UTC)
Another thing we can do is have {{db-g12}} automatically transclude the {{db-f9}} template if used in file space. That way, we can have the g12 template work in filespace. Or we can treat files as a special case of G12. Aasim (talk) 22:11, 28 October 2020 (UTC)
This comes up every few years at WT:CSD, most recently here in November 2019. —Cryptic 21:40, 28 October 2020 (UTC)
When the work flows to deal with the problematic content is different, then it is reasonable to track the categories separately. isaacl (talk) 22:36, 28 October 2020 (UTC)

Micro Wikiprojects

So my idea is to have a new type of Wikiproject named a micro-wikiproject. These would be very small Wikiprojects which are dedicated to covering topics large enough to be significant, but not large enough to be their own Wikiproject, Task Force or Subtask Force. These micro-groups would edit as little as 5 pages, but as many as 30 or so and would comprise of not too many people (maybe around 3?). It would most likely outline topics linked by Nav-Boxes (as opposed to portals) The purpose of these micro-wikiprojects would be to provide, up to date, current, thourough information on small groups of articles so that editors can focus on making the individual articles the best they can be.
An example of where a Micro-Wikiproject would work well is with the video game franchise Minecraft. It has around 20-30 articles on the subject ranging from games to iconography. It is too small to have a Wikiproject, but undeniably relevant enough to require up to date information.
What do you think? Would this work well? Squid45 (talk) 19:30, 30 September 2020 (UTC)

What wouldn't work well is limiting the number of participants. Anyone is, and should be, entitled to join any Wikiproject that they are interested in. Phil Bridger (talk) 19:39, 30 September 2020 (UTC)
That's a fair point. 3 was an estimate of how many were necessesary, considering the number of articles, but the more people join, the better. Maybe even if the project grows big enough, it can be deemed a full Wikiproject status. Squid45 (talk) 19:47, 30 September 2020 (UTC)
A WikiProject is a group of people. A WikiProject is not a case of Build it and they will come. If you don't already have the people, you don't have a WikiProject.
When such a small number of people are working together, they should just work together, using article talk pages and their own userspace. Setting up the infrastructure for a WikiProject (e.g., pages, categories, tagging, coordinating...) can run on the order of a hundred hours' work, even when the scope is small. If you've got three good editors, they should not waste that much time on paperwork. They should just edit the articles. WhatamIdoing (talk) 02:45, 1 October 2020 (UTC)
The usual approach is to create a task force underneath an appropriate WikiProject. isaacl (talk) 23:42, 30 September 2020 (UTC)
In particular the video games wikiproject already has task forces for Blizzard, Nintendo, Rockstar Games. So it seems like the precedent here would just be to set up an additional task force for Mojang Studios. That way you get to use the infrastructure of the existing Wikiproject while still attracting the editors wanting to work on the Minecraft franchise specifically. --Paul Carpenter (talk) 05:59, 1 October 2020 (UTC)
In this particular case, video game project already trimmed and deprecated a lot of inactive task forces like this. Company task forces don't last and editors eventually just move on. In fact, both Blizzard and Rockstar task forces you linked are inactive and were upmerged by consensus. In fact, the most recent precedent has been the opposite of creating the task forces -- to centralize discussion to the main project talk page. —  HELLKNOWZ   ▎TALK 18:36, 1 October 2020 (UTC)
Comes down to what WhatamIdoing said: find the interested persons first, and they can choose to hold their discussions wherever they find convenient. The easiest is to just adopt the talk page of an existing, relevant WikiProject. This has the added bonus of advertising the group's activity to a potentially larger audience. If that becomes unwieldy, then you can create a subpage (that is, a taskforce subpage) and hold discussion there. isaacl (talk) 22:33, 1 October 2020 (UTC)
Topic coordination is always a possibility. –MJL ‐Talk‐☖ 00:28, 3 November 2020 (UTC)

Namespace idea

Is it possible we can make a new space called Disambugition page? I don't like seeing those pages with "(disambugition)" in their titles, and they also aren't "articles". We can removed the prefix (remove Disambugition page: from the title) too to look like the Article namespace, so we can still search it convieniently. I think it would be nice to sort things out (rejections here we go) a gd fan (talk) 14:25, 26 October 2020 (UTC)

Disambiguation. ―Mandruss ☎ 14:27, 26 October 2020 (UTC)
What do you mean? a gd fan (talk) 14:48, 26 October 2020 (UTC)
Spelling. Disambiguation, not disambugition. ―Mandruss ☎ 14:51, 26 October 2020 (UTC)
Oh, sorry, I spell that word wrong a LOT --a gd fan (talk) 15:01, 26 October 2020 (UTC)
If I had my way, every disambiguation page would have (disambiguation) in the article title. When I'm searching for content as a reader, sometimes I want to find the disambiguation page for a term/name and it's frustrating when I can't tell if I'm going to what I want or to an article. Schazjmd (talk) 16:28, 26 October 2020 (UTC)
I believe it is current policy/guideline to have such a page as a redirect where that is not in the title. Perhaps a bot can be stood up to run regularly to make such redirects. --Izno (talk) 17:09, 26 October 2020 (UTC)
This is an interesting thought. I definitely think that "disambiguation page" should be a sharply defined concept that's appropriately categorized/marked/etc. If moving them to their own namespace would help with that, I'm for it. {{u|Sdkb}} talk 19:48, 26 October 2020 (UTC)
  • It would be nice if dab pages said something other than "Article" next to "Talk". Is the proposal here to move just mainspace dab pages to the new namespace (which would add complexity) or move all dab pages to the new namespace (I can't see how that would work)? There have been several previous discussions about this (example) DexDor (talk) 20:29, 26 October 2020 (UTC)
  • To readers, disambiguation pages already look distinctive enough (the visual pattern of:
    Bongo bon gobon go:
    followed by a long bulleted list is recognisable even to people who can't read. For editors, article disambiguation pages are already clearly set-off by their membership in the all-encompassing Category:All article disambiguation pages. – Uanfala (talk) 00:52, 1 November 2020 (UTC)

Sandbox organiser

Sandbox Organiser

A place to help you organise your work

Hi all

I've made something for people like me who have a million half finished sandboxes to help be a bit more organised and play around with the idea of having a wiki page that works a bit like the apps menu on your computer. I'm guessing some of you have quite a few articles in draft space as well :)

https://en.wikipedia.org/wiki/User:John_Cummings/sandbox

If you'd like your own there's some instructions down the bottom on how to copy it (just find and replace my name in the wikicode with yours) but also feel free to poke around on my one to see how it works.

All feedback very welcome, ideas for making things clearer, new sections, etc, the instructions (at the bottom) need some work so feel free to ask questions there or here or wherever. I'm not sure where to put it yet as a tool people can use, any ideas?

Thanks

John Cummings (talk) 17:54, 30 October 2020 (UTC)

What should we do about experienced editors who habitually don't use edit summaries?

I occasionally come across experienced editors who make generally positive contributions, but just do not use edit summaries. They generally have plenty of warnings on their talk page (I recently revamped {{Summary2}} to make it useful for using for experienced editors, since {{Summary}} is not), but since our rules don't formally require summaries, they are able to just ignore the warnings and carry on, wasting other editors' time. Is it time to change the rules somehow? If not, are there other approaches we could take to address this problem? {{u|Sdkb}} talk 19:45, 7 September 2020 (UTC)

I feel your pain. I think ANI is about the only way to go, where nothing will likely happen, especially if it's an experienced, productive editor. While we're at it, I'd also lump in the habit of just blindly copy/pasting the entire text of an edit into the summary box along with that. That's not only almost as useless, but also tends to make page histories a lot less navigable. But people will often just oppose anything that adds or strengthens anything resembling a rule, even if it would be useful, citing WP:CREEP, so I'm not expecting much, myself. –Deacon Vorbis (carbon • videos) 19:57, 7 September 2020 (UTC)
The prevailing community approach to such things (with which I disagree) appears to be:
  • Write guidelines describing best practices.
  • Ensure that editors are aware of the guidelines.
  • Carry on.
Generally speaking and with exceptions, individual freedom trumps the greater good at en-wiki. Custom signatures are another example, where the community consistently refuses to impose even minimal bright-line restrictions. ―Mandruss ☎ 20:04, 7 September 2020 (UTC)
The community might not but the foundation has. See Wikipedia:Village pump (WMF)#New requirements for user signatures. CambridgeBayWeather, Uqaqtuq (talk), Huliva 23:41, 7 September 2020 (UTC)
I see nothing there addressing the problem of distracting signatures that get in the way of discussion, a problem that could be greatly reduced by one or two bright-line restrictions. And even what's there applies only to new signatures, meaning the improvements will be realized only by gradual attrition that will take decades. I probably won't live that long, and I'm not that patient anyway. ―Mandruss ☎ 00:03, 8 September 2020 (UTC)
Whatamidoing is contacting everyone whose signature does not comply to resolve them. The current forecast is "probably months"—see Wikipedia:Village pump (proposals)/Archive 170 § Add basic HTML syntax-checking on user signature field changes for a few more details. There are about 900 more editors affected, and about 700 of them are easily fixed. isaacl (talk) 00:18, 8 September 2020 (UTC)
AFAIK, that only applies to malformed signatures that break new tools, and some rare pathological transclusion vulnerability (the latter which I don’t fully understand). It doesn’t address acceptable style, bright colours, etc. — Pelagic ( messages ) – (08:55 Sun 18, AEST) 22:55, 17 October 2020 (UTC)
I can't remember when we last had a change to the rules about signatures, other than the WMF reform to them which has proved remarkably uncontentious for a WMF change. Though we did have this 2009 Request for signatureship. Perhaps now would be a good time to propose a change at Wikipedia_talk:Signatures. Can you be specific though as to what is allowed now but which you feel should no longer be allowed? ϢereSpielChequers 16:48, 18 September 2020 (UTC)
@Mandruss: I've enforced our custom-signature bright-line restrictions with block warnings before, specifically the prohibitions on signatures that disrupt the flow of text, that call templates, or that include images. — xaosflux Talk 00:14, 8 September 2020 (UTC)
  • 15 years ago, when I ran for admin, whether you used edit summaries or not was something that people worried about. I guess people are still worrying about it. What's next? Worrying about signatures? Oh, wait, yeah, I guess it is. The big issues of the day: edit summaries, signatures, and oxford commas. — Preceding unsigned comment added by RoySmith (talk • contribs) 00:32, 8 September 2020 (UTC)
  • How about asking nicely with a human message rather than a templated warning? Phil Bridger (talk) 15:55, 9 September 2020 (UTC)
    And when that's still ignored, then what? –Deacon Vorbis (carbon • videos) 17:48, 9 September 2020 (UTC)
    Then it depends on circumstances. If the editor is a net positive to the task of building this encyclopedia then we just put up with them not obeying some officious "rule". We are not here to provide nice neat edit summaries or to make our signatures look good, but to build an encyclopedia. Phil Bridger (talk) 17:57, 9 September 2020 (UTC)
    Edit summaries are useful tools when building an encyclopedia, and having them can hours and hours of work from the many editors that might have to review each edit to tell what it is. --Ahecht (TALK
    PAGE    ) 19:33, 9 September 2020 (UTC)
    Yes, they can be, but in other circumstances they can be useless, as RoySmith explains below. That is why I used the phrases "it depends on circumstances" and "net positive". Phil Bridger (talk) 19:47, 9 September 2020 (UTC)
  • I really don't see a blank edit summary as a reasonable freedom. The user preference Preferences ↠ Editing ↠ Prompt me when entering a blank edit summary should be set as the default. Better still, remove the A blank edit summary is OK the second time around option. And do not mention Oxford commas. — GhostInTheMachine talk to me 19:02, 9 September 2020 (UTC)
    GhostInTheMachine, The problem with requiring the user to enter something is that it just encourages garbage. Often, there's nothing to say besides "fix", "more", "reply", or something equally useless. When there's something useful to say, I say it. It's like the web forms that require me to enter a phone number.
    If you insist on refusing to allow me to place my order without giving you a phone number, OK, fine, my phone number is 999-999-9999. -- RoySmith (talk) 19:24, 9 September 2020 (UTC)
    How did you know what phone number I entered today on a web form? Phil Bridger (talk) 19:27, 9 September 2020 (UTC)
    With COVID restrictions where I live, we can dine out but have to register our details for contact tracing. However, some restaurants are asking for more info than what the department of health would need. So they get some interesting data from me.
    Back to the topic, Roy makes a reasonable point that often there's nothing to say. But I think "grammar" or "copyedit" is still more useful than no summary. "Fix" gets my spider senses tingling, as pov-pushers, nationalists, and righters of great wrongs might fix-up an article real good and use that as their summary. Genuinely mixed fixes are hard to describe (e.g. spelling + grammar + structure + added some wikilinks, but not a full copy-edit in the way some would use the term).
    — Pelagic ( messages ) – (10:13 Sun 18, AEST) 00:13, 18 October 2020 (UTC)
    Pelagic, I usually start new articles as userspace drafts. While I'm doing the initial writing, most of my edit comments are simply, "more". I make lots of small edits, and the value of writing something like, "added another two sentences describing how a widget is made" doesn't justify the effort. On the other hand, if I'm editing an established article to make a correction, I'll spend the effort to write a useful and descriptive edit summary. -- RoySmith (talk) 00:54, 18 October 2020 (UTC)
    Great point, Roy. Describing every step in detail when building up content would be unnecessary and probably tedious. Pelagic ( messages ) – (21:50 Thu 29, AEST) 11:50, 29 October 2020 (UTC)
    I know. I still think that the first You have entered a blank edit summary, please think about that warning should be the default. — GhostInTheMachine talk to me 19:45, 9 September 2020 (UTC)
    Maybe for logged in editors who have completed their first 100 edits. Otherwise the main thing you achieve is discouraging vandals from self identifying by leaving a blank edit summary. ϢereSpielChequers 16:25, 18 September 2020 (UTC)
  • If a Wikipedian does not type in an edit summary, the contribution will be marked in the article's history by the sub-heading of the article. This could be seen as an edit summary (for example, I am not going to type in an edit here but I will still have this edit marked up as "What should we do about experienced editors who habitually don't use edit summaries?") so I do not see a problem. Vorbee (talk) 06:20, 18 September 2020 (UTC)
Sdkb, I'm curious: what part of our rules don't formally require summaries left you confused? Guy (help! - typo?) 21:55, 12 October 2020 (UTC)
JzG, where did I say I was confused? {{u|Sdkb}} talk 22:01, 12 October 2020 (UTC)

Would a greater problem be whether or not a Wikipedian marks an edit a minor edit or not? There might be debate about what counts as a minor edit, but sometimes edits are obviously minor (e.g. inserting a missing letter into a typo) and if such an edit is not noted as minor, this will not show up in the article's history. Vorbee (talk) 06:27, 18 September 2020 (UTC)

  • When I'm training, or talking to someone who doesn't see the point of edit summaries, I usually explain that an edit summary is code for "I'm probably not a vandal". Of course there are some vandals and spammers who have cottoned on and use edit summaries, and some regulars who don't. But as long as keeping edit summaries as optional helps some spammers and vandals self identify as such, then I think that it is useful to keep it optional. However there are some people who don't opt in to an edit summary point until they run an RFA. or ask an experienced RFA nominator like myself for a nomination. So keeping edit summaries optional is an imperfect but useful tool for spotting bad edits. ϢereSpielChequers 16:18, 18 September 2020 (UTC)
    Since this discussion is veering in the direction of discussing mandatory edit summaries, I'll note that it's listed at Wikipedia:Perennial proposals#Automatically prompt for missing edit summary. It's certainly a valid discussion to have, but I'm more interested here in sticking to the more narrow question I initially posed about experienced non-vandal editors. {{u|Sdkb}} talk 04:40, 20 September 2020 (UTC)
Vorbee, edits incorrectly marked as minor are certainly a problem. I rewrote {{uw-minor}} a few months ago, and I use it whenever I come across an edit improperly marked as minor. It's usually from a beginner; I think it's (thankfully) not that common to intentionally mark a controversial edit as minor to try to avoid scrutiny. If you want, a parameter or separate template could be made to allow for a more strongly-worded alternative to uw-minor, which would be appropriate for instances in which someone is trying to evade scrutiny. {{u|Sdkb}} talk 04:44, 20 September 2020 (UTC)
@Sdkb: Unfortunately, abusing the "minor" flag is not that uncommon. I don’t do specifically anti-vandal or patrolling work and I still encounter it. Also see edit summaries like "typo" or "fix spelling" for a change that could range from section blanking down to replacing Ukraine—>Russia (-1 byte). Can’t stop people from being dishonest. Though I suppose the latter change could be a minor typo fix in someone's mind.
I think repeated dishonest summaries would/should be sanctionable, maybe comes under "disrupting the encyclopedia". People who do that generally display other behaviours which end up getting them kicked for POV-pushing, not-here, edit-warring, or UPE anyway.
But the good editors who just don’t or won’t see any value in good edit summaries, how to convince them otherwise? And should we? (Disclaimer: I’m from the other end of the spectrum and for a gnomish change will sometimes spend as much time on the summary as the edit itself! So I do believe in the value of summaries.) Pelagic ( messages ) – (09:32 Sun 18, AEST) 23:32, 17 October 2020 (UTC)
  • I presume this idea is for mainspaces, not talk pages or user pages? ProcrastinatingReader (talk) 05:20, 20 September 2020 (UTC)
  • I would like to hear from people who habitually don’t leave summaries as to their reasons. However, there's also a class of experienced productive editors who don’t engage in discussions. I wonder how much overlap there is between the two groups? When you template their talk pages, do they respond? Pelagic ( messages ) – (09:46 Sun 18, AEST) 23:46, 17 October 2020 (UTC)
  • I probably don't leave a summary much more often than I do. Why? 1) For many edits the edit summary would take longer to compose than the actual edit, 2) many edit summaries aren't very useful in the first place ("spelling"), 3) more complex edits would require too much description in the summary, and 4) even if you leave a summary, how do I know you aren't lying? --Khajidha (talk) 18:38, 27 October 2020 (UTC)
  • I usually leave an edit summary but it is often a pointless chore. For example, in this case I will probably just add the word "comment" to the default summary, which is already quite long ("/* What should we do about experienced editors who habitually don't use edit summaries? */"). And for some update screens, the edit summary box may be hidden or otherwise difficult to find and use.
Whatever the cause of such difficulty, the best remedy would be for there to be a mechanical default or substitute which is used when a manual summary is not provided. The current screen I am using provides several "Common (minor) edit summaries" such as "Fixing style/layout errors". Perhaps something like ORES can figure out which of these is appropriate and use that. Andrew🐉(talk) 12:51, 29 October 2020 (UTC)
Building on what Andrew says, we should distinguish between omitting edit summaries in articles and omitting edit summaries in discussions. Most edit summaries in discussions are some variant on "Reply" or "Comment", which are pretty pointless.
That said, informative automatic edit summaries have been proposed over the years, and I believe that the new m:Community Wishlist is open if anyone wants to propose them. Link to phab:T3307, phab:T14411, and phab:T54859 in your proposal. WhatamIdoing (talk) 16:07, 6 November 2020 (UTC)

So, like most people I read Wikipedia to get information on topics I want to learn about. When my sister told me about a relatively new political meme, of course I looked it up on Wikipedia because I hadn't heard about it before. I skimmed the article until I got to the end where I see the two navboxes. I see {{Neuropsychology tests}} is included, so I click to expand it only to find it relatively useless to me. Montreal Cognitive Assessment looks just like any other link there.
That had me thinking about how we do navboxes. If an editor wanted to integrate Person, woman, man, camera, TV with {{Neuropsychology tests}}, they'd have three options:
(1) Add a link to the meme right after MoCA Montreal Cognitive Assessment (Person, woman, man, camera, TV).
(2) Add a link to a new |group13= for "See also" section which includes Person, woman, man, camera, TV with possibly some other links under |list13=.
(3) Reorder |list0= with a child navbox that creates a Montreal Cognitive Assessment subgroup separated from the rest like so: Special:Permalink/985580715.
Now, none of these methods are currently ideal. However, what if {{Neuropsychology tests|state=expanded}} while onPerson, woman, man, camera, TV looked like this?
Essentially, I'm suggesting we bold the link to Article A while on Article B to make Article A easier to find through the navbox. Does that sound like a good idea? –MJL ‐Talk‐☖ 19:20, 26 October 2020 (UTC)

  • Well, {{Neuropsychology tests}} probably shouldn't be used on Person, woman, man, camera, TV in the first place because of WP:BIDIRECTIONAL. But if it does get used, then yes, your proposal will make it more helpful. On a more general note, I've sometimes been thinking that the way we organise navboxes isn't always optimal. For example, it doesn't work well if the logical organisation of the topics doesn't fit neatly into the mould of nested lists. What if the topics are stored under the hood of the navbox as a sort of network graph, and any individual use of the navbox generates the display of (a subset of) those topics centred on the current article, with the most similar other topics displayed more prominently? – Uanfala (talk) 01:03, 1 November 2020 (UTC)
    I have suggested something in that direction (though not so fancy I think) in the context of the perennial show navboxes on mobile request. The RelatedArticles extension automatically does this to some extent. (It's just displayed only on mobile and in Timeless.) --Izno (talk) 02:28, 1 November 2020 (UTC)
    @Uanfala: I fully agree on all counts. As for your idea, could you please elaborate with an example? –MJL ‐Talk‐☖ 00:43, 3 November 2020 (UTC)
    For example, if the navbox is to navigate between countries, then its underlying graph would have individual countries as its nodes, with edges connecting countries that are neighbours. There'll be edges connecting France to Germany, Italy, Spain, etc., and edges from, say, Italy and Germany to Austria, but no direct edge from France to Austria. Each invocation of the template will generate a display based on the page it's used on, some setting in the template itself, and whether it is displaying on mobile or desktop. So, for example, if it's at France, the template will list France's immediate neighbours for mobile, while on desktop it could list neighbours + neighbours of neighbours.
    The edges could have any meaning you assign to them. The variable display could also work with the current way of organising navboxes. For example, {{William Shakespeare}} could be configured to show only the subgroup, so in the Macbeth article the template would only display the list of tragedies, with the sister subgroups for comedies, histories, etc. collapsed into "see also" entries. – Uanfala (talk) 03:08, 3 November 2020 (UTC)
    I'm doubtful about almost everything we do with navboxes. I specifically wonder whether BIDIRECTIONAL should be scrapped. I think it leads to bloated boxes, because the only way to get a navbox for a broader concept into the relevant articles is to put it all in the same navbox. If you think about a subject like Cancer (and if you believe that navboxes are useful for readers, which has never been proven), then we probably want navboxes in all cancer articles that take people to basic topics: Causes of cancer, Cancer screening, Cancer staging, Treatment of cancer, Cancer survivor, Cancer survival rates, etc. But under BIDIRECTIONAL, the only way to do that is to cram all of those general links into every single specific navbox. BIDI says you can't have a {{general cancer information}} navbox that appears in a couple hundred articles. WhatamIdoing (talk) 17:10, 6 November 2020 (UTC)
    You might be interested in a recently listed CENT item about sidebars then, which have generally enjoyed 'doesn't need to meet bidirectional'. --Izno (talk) 20:30, 6 November 2020 (UTC)

Time Conversion

It's really confusing to me that the time is UTC. My time zone is EST, and it's really weird seeing the Main page update around 6:00 PM for me. Is there a bot that converts the time, for example, wherever it says 2:13 PM UTC it would change it to 9:13 AM EST for better user understanding? Should there be one? Or is this too confusing and UTC is really the best option? Le Panini (Talk tome?) 14:14, 5 November 2020 (UTC)

Set your time zone in Special:Preferences#mw-prefsection-rendering — GhostInTheMachine talk to me 14:35, 5 November 2020 (UTC)
This is what I've been looking for all my six months. Le Panini Talk 17:03, 5 November 2020 (UTC)

Content Assessment Tool

Since WikiProjects use Wikipedia's Content Assessment ratings and ask their members to help rate articles, it might be a good idea to build a content assessment tool so anyone can quickly rate articles. The tool could be built in a similar style to the VisualEditor (with the OOUI framework), and would gather articles to rate from any of the categories set up by WikiProjects, for example the Unassessed Transport Articles Category set up by WikiProject Transport. The tool should probably be in a centralised location, something like en.wikipedia.org/Wikipedia:Content Assessment Tool

Two toolbars could be implemented at the top of the tool:

  • The first toolbar would contain navigation buttons (i.e. go back to last rated article or skip to next article in category, which would trigger dialog boxes). The user would select the WikiProject they wish to rate articles for using a drop-down box here, and then the tool would gather articles from predefined categories set up by their respective WikiProjects (see the example above). The guidelines for rating articles would be linked in an "edit notices" section similar to what is present in VisualEditor, and obviously there would be a notice asking the user to read the article carefully before deciding on a rating. There would be a blue "Publish changes..." button similar to what is present in VisualEditor for the user to publish their rating, and upon clicking on that the edit summary would be automatically filled in to read 'Added rating for Wikiproject Name'.
  • The second toolbar would be where the user could click on the rating they reckon fits the article best.

The space below the two toolbars would be for displaying the article/s to be rated.

Does anyone think this is a good idea? And what about articles within the scope of multiple WikiProjects, or users rating for multiple WikiProjects?

Please let me know of your opinions and whether I should consider proposing this formally.

Thanks!

Jh15s (talk) 02:03, 6 November 2020 (UTC)

So, basically WP:RATER. --Izno (talk) 08:24, 6 November 2020 (UTC)
@Izno: I didn't know of that script! Yes, basically like that but without having to install anything or fiddle with anything, or worry about skin support . Also, I think the script only works when you are editing an article you have selected yourself, whilst my idea would automatically queue up articles to be rated from categories of unrated articles set up by their respective projects. We could consider proposing an implementation of this queuing feature in the existing script but I'm not too sure that's technically possible, since Rater plugs into the Visual Editor. Having two tools for ratings might not work well, though, since, by the looks of it, Rater is an official tool (correct me if I'm wrong). Jh15s (talk) 09:54, 6 November 2020 (UTC)
No, it is a volunteer tool. I don't really see the need for the additional system you've proposed in this case, between Rater and middle-clicking the articles listed in unassessed categories... I open a few more tabs but does exactly what you want. --Izno (talk) 12:57, 6 November 2020 (UTC)
@Izno: Alright then, looks like my suggestion isn't needed then. Thanks for your help!

We could use Google Maps and google sign in (OAUTH) Wikipedia.

Dear Team,

Greetings,

We could use Google Maps and google sign in (OAUTH) Wikipedia.

Thanks and Regards, Shiv — Preceding unsigned comment added by Suryawanshi.Shivkumar (talk • contribs) 16:28, 8 November 2020 (UTC)

We don't want to do either of those due to privacy concerns. See phab:T61631 for example. Majavah (talk!) 16:35, 8 November 2020 (UTC)

If a topic reaches consensus on an article's talk page, could it be reference by other articles?

Question that I hope some of the experienced editors could offer guidance on

If a topic has been discussed at length on Article A's talk page and reached consensus, could we reference the same talk from Article A in relation to the same topic in Article B? or should we open a new talk in Article B's talk page, and go through the same process?
Thanks--Sataralynd (talk) 03:51, 9 November 2020 (UTC)

It could certainly be a good basis for an article change (rather than simply stating one's own position in edit-summary) and also referenced in a talkpage discussion if someone objects. DMacks (talk) 03:53, 9 November 2020 (UTC)
Thanks @DMacks: just to make sure I understand, you are suggesting it is ok to make the change in Article B and reference the talk from Article A in the edit summary, and if someone objects then they open a new talk in Article B's page. Right? --Sataralynd (talk) 14:33, 9 November 2020 (UTC)
Exactly. Unless it is already controversial in B (for example, that article's edit-history or existing discussion at Talk:B). DMacks (talk) 14:39, 9 November 2020 (UTC)
Thank you that is clear now--Sataralynd (talk) 04:46, 10 November 2020 (UTC)
This is already fairly common - one example would be that whole-field changes on Covid get discussed on the central article and then cascaded downwards Nosebagbear (talk) 09:38, 10 November 2020 (UTC)
Sataralynd, some related pages are WP:CONLEVEL, WP:Precedents, and WP:OSE. Ironically, they're not fully consistent with themselves—some editors give more weight to precedent than others. {{u|Sdkb}} talk 22:57, 10 November 2020 (UTC)

For readers, reporting/fixing vandalism is far too tedious

I'm sure this has been brought up before, but we should really implement some sort of vandalism or otherwise disruptive editing reporting mechanism for your average reader. As experienced editors, it's easy to say what we have right now works "well enough", but it relies too heavily on active recent changes patrollers, edit filters and other mechanisms that simply have too many failings still, especially in terms of false or long-term vandalism (i.e. on pages that may receive very little traffic). We often neglect the fact that the most common user of Wikipedia is not familiar with our oftentimes complex policies and reporting methods (many of which requiring knowledge of WikiText), and is probably familiar with the reporting mechanisms of other platforms such as Facebook, Twitter, YouTube, and so on. Wikipedia still doesn't have these features, and yes, while it can be fixed by the users themselves this is often too complex for them, or too time consuming, especially considering people read Wikipedia in situations or contexts where editing the page may be daunting or just not appropriate. If we could add a simple way for people to report vandalism, BLP/POV issues, incorrect information or advertisement/promotion, we can continue to improve and advance the reliability of the English Wikipedia massively.

We don't have to implement this into MediaWiki (the software that powers Wikipedia and many other sites) itself, but can add it as a link in the header or sidebar to a "reporting wizard", or a report gadget that is enabled by default and would essentially work the same as the reporting mechanisms that many of our readers may be familiar with on other sites.

Does anyone have any suggestions for the mechanisms of this tool, or objections for a proposal of this nature? Many thanks, Ed talk! 19:22, 24 October 2020 (UTC)

The last time we had a feedback tool, we trashed it because we were getting 80% useless comments (that also didn't integrate into our talk pages [you can decide whether that's a good or bad thing]). You should consider how to deal with that problem. --Izno (talk) 21:50, 24 October 2020 (UTC)
The feedback idea was flawed from the start -- too much effort needed to evaluate the comments. A straight up vote system, on the other hand, wouldn't require all that work and could be quite useful. Imaging if you (this should be visible to extended conformed editors only so we don't turn into Reddit) could look at a list and see that certain pages had 1000 votes for them being inaccurate? Or especially useful? Or spam? To make it even better, have a separate list that only lists votes from voters who voted fewer than 10 times in the last 30 days. --Guy Macon (talk) 00:21, 25 October 2020 (UTC)
"Straight-up vote" is a pretty good description of the early versions of the Article Feedback Tool. Have you forgotten about all the stars at the bottom of the articles? It worked okay in some areas, but in pop culture, the "votes" tended to reflect whether people liked the film/actor/etc. regardless of article quality. The reason the last version was text-heavy was because we asked them to take away the "vote" component. I found the comments useful (people reading about rare diseases want to know about the prognosis), but I understand that the value varied significantly by subject matter. WhatamIdoing (talk) 18:52, 26 October 2020 (UTC)
Ed6767, this is an issue I've definitely thought about. It was compounded until recently by the fact that pages like WP:Vandalism are not at all beginner-friendly. I wrote Help:Simple guide to vandalism cleanup, a very short page that explains how to revert, to address that issue. It does include a semi-automated way to report vandalism to the help desk, but it's provided only at the bottom for editors who are really too shy to fix it themselves. {{u|Sdkb}} talk 01:10, 25 October 2020 (UTC)
Editing SkyThe sky is blue greeeen.
I don't think the real issue is that we don't have a way of reporting vandalism, it's that reverting vandalism is much too complicated for the average reader. We really should have a quick way of fixing vandalism, integrated into the regular edit screen. There should be little boxes on the side of the edit screen pointing out recent edits, with quick revert buttons. (Uh-oh, random UX wishing started...) Also, little boxes full of text from a "meta-article" of some kind which is full of explanations of why things in the article are the way they are, along with pointers to discussions. And also pointers to broader recent history, which could tie in to some kind of section-local WhoColor/HistoryView hybrid, and ongoing fork-drafts and real-time ongoing collaboration units, and a flying unicorn that fixes bad edits and a... --Yair rand (talk) 07:22, 27 October 2020 (UTC)
It's not that simple, unfortunately. A lot of times, there are edits made after the original vandal, and reverting it requires digging through hundreds of edits over many years, doing research to figure out what the actual information is and whether it's changed since the edit was made ("who is the current principal" type stuff), etc. Gnomingstuff (talk) 22:25, 4 November 2020 (UTC)
Maybe MediaWiki could add a feature similar to Gits "blame" feature, where whoever edited a section can be seen and reverted interactively? Ed talk! 16:19, 13 November 2020 (UTC)
We have two different systems for that currently, see WP:WikiBlame. --Izno (talk) 16:37, 13 November 2020 (UTC)

Graeme Bartlett's post in the section above reminds me of another problem I have seen at the Teahouse: Paid editors with filled out {{Paid}} tags on their user pages but enclosed in nowiki. I have never used the Visual Editor; is it that the Visual Editor makes difficult (or impossible?) to insert templates? Is it helping them fill out the template and then inactivating it? That shouldn't be! —teb728 t c 01:08, 12 November 2020 (UTC)

@Teb728: I did some experimentation, and I can coax VisualEditor into the nowiki state with a vaguely plausible workflow:
  • Copy-pasting one of the examples from Template:Paid will render the template properly
  • If you manually type everything, once you finish "{{", a template dialog pops up, which leads to the template rendering properly
  • If you copy-paste it in pieces (e.g. copy-paste {{paid|employer=, then type the employer name, then |client=W. Coyote, then the client, then }}, the entire thing ends up being surrounded in nowiki tags.
Unfortunately, this behavior from VisualEditor is probably correct, as aggressively converting double-braces into templates would probably lead to weird and wrong outcomes in some cases. I did, however, go through manually and remove nowiki tags for about 50 users who had done this. You might be able to create a bot to take care of the most obvious cases, but it would be tricky to get exactly right, especially if it was premised on ignoring the one facility to tag wikitext as "don't mess with this". Vahurzpu (talk) 04:27, 12 November 2020 (UTC)
@Teb728: Taking back my earlier statement, as I've found another, very obvious, way to reproduce the weird behavior: copy-pasting the exact syntax on Wikipedia:Article wizard/HowToDisclose with VisualEditor doesn't work, presumably because of some of the markup. I've made an edit request to fix this. Vahurzpu (talk) 18:08, 12 November 2020 (UTC)

President-elect, but not president-elect (yet)

Every 4 or 8 years, the argument across quite a few American political articles (bio & non-bio) shows up, about whether or not a US president & vice president have been elected on election day, or when the Electoral College has voted or when a joint session of the US Congress has certified such votes. Again in 2020/21 it's been occurring again at Donald Trump, Mike Pence, Joe Biden, Kamala Harris, 117th United States Congress, etc etc. Is it possible for us to finally come to an agreement on which to go with? GoodDay (talk) 15:33, 12 November 2020 (UTC)

It actually wasn't an issue in 2016 or 2012 or 2008, as far as I can tell. We use the terminology that everyone uses, which is that when the results of the election are determined to a sufficient point (i.e. when the election is "called" by reliable sources and/or when the opponent concedes, whichever comes first), they start calling the next President the "President-Elect". The Electoral College "vote" itself in December has not been anything except an anachronistic formalism, and there has not been any functional issues with that vote in over a century. It's a pro-forma thing, and the occasional "faithless elector" (who end up being trivial) notwithstanding, there really is not a single reliable source that treats the Electoral College vote as anything other than that; a pro-forma legal formalism with no inherent effect on the outcome of the election. The only reason it is a deal this year is that the side that lost the election is trying to finagle it into somehow using the Electoral College vote as a means to win by the backdoor, but there's no reason to suspect this stands any chance to happen this year anymore so than in previous years. Biden is the president-elect, and we use that language because that's the language all the reliable sources are using. --Jayron32 16:27, 12 November 2020 (UTC)
Referring to Biden as president-elect is completely in line with how the term has been used for decades. That one petulant little bully and his sycophants cannot accept reality has no bearing on proper English usage. --Khajidha (talk) 19:28, 12 November 2020 (UTC)
Is it possible for us to finally come to an agreement – No. Of course not. Out of the question. What are you, GoodDay, one of those incurable optimists? 😜 WhatamIdoing (talk) 04:03, 14 November 2020 (UTC)

Raising donation for Wikipedia: email postage as protective charge for spam protection

Hi,

handling spam emails in the inbox of public addresses costs enterprises a lot of time and money. So enterprises could insist on accepting only "qualified emails" on public email addresses. An email should be considered qualified, if it comes from a known sender (and has additional features, e.g. includes a sender specific secret in the header or body) or it is a "stamped" email. The postage for a stamped email would be very low, e.g. 1 cent.

Approach 1)

To stamp the email, some key data (email address of sender and receiver, body hash) which uniquely identify the email has to be sent to a server which creates a signature (signs the key data with a private key) which must be included in the mail to qualify it. The receiver verifies the mail by extracting and removing the signature from the body and applying the public key of the stamping server against the key data to verify that the mail is correctly stamped.

The part of Wikipedia is to provide the stamping service, to allow users to create an account with his sender email address as user name and password or other authentication methods (oauth). Users can fill the deposit of their account by giving a donation to Wikipedia. The challenge is to make the procedure to stamp the email easy on user side, e.g. via a) integration through plug-ins into the main email client programs (like Outlook), or b) negatiation with the providers of web based email services (like gmail, gmx, web.de) to offer users to click on "stamp".

Approach 2)

The user adds the email address of the stamping server as cc to the email to send. When the stamping server receives the mail, it asks the user to confirm the stamp request (providing the email data). The server identifies the user by the sender email address. That's why the user can register additional sender email addresses in his account. The stamp confirmation request can be sent per email back to the sender address or the user logs on into his wikipost account and approves the stamp request there.

Of course then the signature can not be included in the email sent to the real recipient. In this case the recipient has to make a call to the stamping server to verify that the mail is stamped, using the cc address in the mail to identify the stamping authority to ask (in case there might be other stamping services arising). This way Wikipedia will get more donations.

Regards Mick — Preceding unsigned comment added by MickHaskell (talk • contribs) 09:45, 13 November 2020 (UTC)

It seems like somebody proposes this idea at the Village pump every few years. Is it always you, or is it a different person each time?
None of them explain why this has anything to do with Wikipedia, which does not control e-mail, nor who's supposed to get the money (100–200 billion probably legitimate e-mail messages worldwide per day turns at your "low" price of just one cent each turns into a surprising chunk of change – maybe that's all for you?), or how to deal with competing services.
If you can find multiple long Wikipedia:Reliable sources about this (e.g., in computing magazines), then Wikipedia could have an article about it. WhatamIdoing (talk) 04:11, 14 November 2020 (UTC)

Every year Wikipedia asks for donations. My proposal is my contribution to allow Wikipedia to get donations. But anyway, then forget it.

Every year we ask for donations, and more than enough of our readers donate for that to be an excellent way of funding wikipedia. Running an authenticated Email service, with all the checks and filters needed to block accounts that are bought by spammers, would be an interesting business venture, I don't see it having a good fit with this community though. The issue being how you identify the accounts being used for spamming and where you draw the line between legitimate business and spam. You either do this with sophisticated software which makes this an expensive commercial speculation, or you use volunteers to monitor spam. So there is a risk that even if this succeeds, it generates money - which we currently have no shortage of, but takes up volunteer time, or loses us volunteers and money by tarnishing our reputation. Remember volunteer time is the thing we are short of. Better to continue the community's current focus, innovate invest and try new things to recruit more editors, while leaving the fundraising side undisturbed as long as it continues to be the goose that lays the golden eggs. ϢereSpielChequers 10:07, 18 November 2020 (UTC)
So this user is essentially suggesting the Wikipedia create it's own email client, one where someone must pay to send a message? Squeeps10 Talk to meplease ping me 02:49, 21 November 2020 (UTC)
Yes, but it is worse than that. Lots of businesses could launch such a premium service if there was demand for it. The essential ingredient that Wikipedia would bring to the table would be a highly trusted brand. It would not surprise me if people were willing to pay to have a Wikipedia email that would likely get past spam filters, at least the people whose emails get problems with spam filters would find this attractive until the inevitable happened and either the brand was trashed or the businesses found their email was being rejected for breaking the rules. Given that money is not a problem for this movement, that our reputation does matter to us, and that a scheme like this would not help and would almost certainly be counter productive for editor recruitment. This does not seem to be a sensible idea. ϢereSpielChequers 09:17, 21 November 2020 (UTC)

How can we better consolidate and discourage creation of overly-specific WikiProjects?

I just came across Wikipedia talk:WikiProject Ballet. It's what you'd expect—a bunch of notices and some beginners who found their way there, asked for help, and were ignored since the page is very evidently unmonitored (no one has replied to a thread there since 2015). Marking it as inactive would be easy enough, but (a) it's concerning that it hasn't already been marked, and (b) even then, I suspect many beginners would still miss the banner. Meanwhile, I recently witnessed the creation of a new WikiProject almost sure to go defunct once its subject drops out of the news, and while there was some disgruntlement, the project got off the ground since any editor can decide to unilaterally create a new project, whereas shutting down a project requires fighting against its self-selected participants to find consensus, an uphill climb at best. Our current approach is clearly not working well, so I'd be interested in hearing ideas about how we might want to shift it to make accelerate the cleanup. Possible reforms that come to mind:

  1. Developing tools to automatically identify and tag inactive WikiProjects, or to assist editors in mass-nominating them for discussion and possible defunctification.
  2. Better strategies for ensuring that inactive/defunct projects are tucked away in the historical bucket where they won't clutter or draw attention away from active projects.
  3. A mandatory review process for new WikiProjects to ensure they have consensus (possibly accompanied by specific guidance of some sort about how broad a topic needs to be to warrant a project), so that editors can't just create them willy-nilly.

Thoughts? {{u|Sdkb}} talk 20:21, 14 November 2020 (UTC)

Dear User: Sdkb you say that you have come across a new WikiProject likely to go defunct once its subject is out of the news - it might help if you told us what the WikiProject is. Activity levels of WikiProjects are likely to fluctuate = there are signs saying that some WikiProjects are inactive, but on occasion these WikiProjects get revived. Vorbee (talk) 21:31, 14 November 2020 (UTC)

It was a mildly charged topic, so I'd prefer not to name it in order to help us stay focused here on the broader concept rather than getting sidetracked into a debate on a specific example. {{u|Sdkb}} talk 22:00, 14 November 2020 (UTC)
The answer is obvious. Create Wikiproject consolidate and discourage creation of overly-specific WikiProjects... :)   --Guy Macon (talk) 22:26, 14 November 2020 (UTC)
Good one GM :-) Please explain what harm is done by having "overly-specific WikiProjects." They come and they go. Back in the late 00s they were created at a rapid rate and now, at a guess, most of those are defunct. On the evidence presented I can't see a problem. It is worth noting that wikipedia is not a bureaucracy and this smacks of exactly the kind of red tape that addresses. The imposition of what one person thinks wikiprojects should be is to be avoided in an encyclopedia that anyone can edit. If there is a specific problem there are other places to deal with that. MarnetteD|Talk 22:51, 14 November 2020 (UTC)
Agree. Why would we discourage editors from working in groups to improved and organize a topic that wish to work on be it vast in nature or not. What we need is more people collaborating and more editors encouraging those efforts. Not interested in a topic go on to something that is of interest. Let' not drive collaboration underground but give it a platform to flourish and be visible to the community at large.--Moxy 🍁 23:09, 14 November 2020 (UTC)
The issues I see with having lots of inactive/semi-active projects are that it creates potential for WP:TALKFORKs, confuses beginners who might not know it's not the best place to post (and more experienced editors who might be clicking through talk page banners trying to find an active project), and uses up editor energy (as mentioned by WhatamIdoing below; it's not necessarily zero-sum but it is certainly finite). {{u|Sdkb}} talk 08:08, 15 November 2020 (UTC)
Just like posting to help pages that no one replies on.....all will learn in time were to find assistance. Not sure WP:TALKFORK is a good reason to restrict people from working in groups or to hide projects that have valid information.--Moxy 🍁 14:09, 15 November 2020 (UTC)
Marnette took it as a joke, but the video games topic area did just that in the late 2000s/early 2010s in WP:VG/IPC. We approached other video games topics WikiProjects, and either suggested they become task forces or if no-one responded to our suggestion, MFDd the projects. We count it a success of reducing the bureaucracy, as it made one focal point for video games editors in the case of project deletion/redirection, and also a success of reducing the bureaucracy when projects were made task forces as it reduced the number of things a group of people interested in a specific topic had to take care of on top of actually writing the articles. Even continuing after the main project, WP:VG reassessed and continues to reassess ad hoc the livelihood of its task forces, which also have summarily been redirected to the main project page. While I do not know if this would work as a general WikiProject, it is something which could be tried. --Izno (talk) 01:53, 16 November 2020 (UTC)
For anyone thinking about doing this: A WikiProject is a group of editors, not a group of pages/subject area. So if you want to merge your group of humans with their group of humans, you need to think about How to Win Friends and Influence People. Don't just show up on their group's talk page and announce that you're taking over "their" pages, or tell them that they're being merged whether they like it or not. Post a friendly note, offer them a deal they will want to accept (like "we'll do all the boring bureaucratic and technical work, and you can focus on the articles"), and wait to see what happens. At WT:COUNCIL, we normally recommend waiting at least a month before merging groups, even if you are convinced that nobody's home.
If nobody replies during that time, then it's just a matter of merging pages. If people are there and like your proposal, then you need to merge pages and, more importantly, make friends with the folks in that group, so you can all work together effectively. WhatamIdoing (talk) 02:39, 16 November 2020 (UTC)
Indeed, we had a copy-pasted message (as in the provided link) saying exactly that. :^) --Izno (talk) 03:25, 16 November 2020 (UTC)
It's tricky trying to figure out how to automatically identify what projects are active. The Wikipedia:WikiProject Directory shows activity in pages tagged as being associated with a WikiProject, which gives some indication of how busy the topic area is, but not a direct indication of the activity of the WikiProject. WhatamIdoing and I exchanged a couple posts on possible metrics at Wikipedia talk:WikiProject Council/Archive 24 § reply (scroll down to the bottom of that subsection): time-to-response on the WikiProject talk page, and average time between posts.
The key problem is in a volunteer environment, it's hard to keep people from doing what they really want to do when it has minimal effect on others (even if that minimal effect on each person might have a larger aggregate effect, as the existence of many defunct WikiProjects could be argued to have). A priori it's hard to distinguish between initiatives that catch on and persist, versus the many, many ones that start up with a big burst and fade away quickly. Everyone thinks their initiative will be different, and we don't actually want to extinguish that hope entirely, or else no new initiatives will ever happen.
As long as any initiative is active, I don't personally feel that a certain broadness of scope should be a necessary requirement for it to continue to exist, so I don't agree with a mandatory periodic review process based on that criterion. I don't think we need a new process, as anyone can go and mark WikiProjects as inactive or defunct. Just like all of these inactive initiatives, though, we need volunteers willing to sink time into it. And like so many initiatives, it's hard to get people to work on things not directly related to creating content. isaacl (talk) 23:14, 14 November 2020 (UTC)
So-called dead projects still have inherent value.... I personally have referred to them many times as outlined at Wikipedia:WikiProject#Inactive projects.--Moxy 🍁 23:20, 14 November 2020 (UTC)
I have indeed argued previously for the ongoing value of project pages even if the project itself is inactive or defunct. isaacl (talk) 23:24, 14 November 2020 (UTC)
But we don't necessarily want editors to spend time creating the project pages, when they could be working on articles instead. The value in deleting extant project pages (i.e., not renaming or merging, but actually deleting the pages so nobody can read them) is usually very small, but the value in not spending several long days creating them in the first place can be high. WhatamIdoing (talk) 01:31, 15 November 2020 (UTC)
What editors do here is entirely up to them. Editing articles, adding or deleting categories, answering questions at ref desks, reporting vandalism (to name but a few) are all things I see editors do every day. If they want to create a project page, whether it takes long or short days, more power to them. Try to remember everyone is a volunteer here - what they choose to do - as long as it does no damage is - once again - up to their whims and desires. No one as the right to tell them you MUST edit article space. MarnetteD|Talk 03:15, 15 November 2020 (UTC)
But "does no damage" is the key phrase. There's a reasonable case to be made that inactive niche projects are actively damaging. A new editor with an interest in (for instance) the history of Naples will reasonably assume that Wikipedia talk:WikiProject Kingdom of Naples is the place to ask questions. That project has has 9 watchers and since only one of the project's members has edited Wikipedia in the past five years it's likely none of those watchers are actually watching. Thus, the new editor is just going to get upset and frustrated and assume that they're being ignored and that the cliche that Wikipedia is full of self-important assholes who treat new editors with contempt is true, whereas if that page had been blanked and replaced with a big This project is inactive, please direct any discussion to Wikipedia talk:WikiProject Italy instead banner, they'd have had their query answered within minutes and been introduced to a large number of people with similar interest who could help them. Multiply that by the 400+ current inactive projects, and it starts to have a statistically significant effect on editor recruitment and retention. ‑ Iridescent 14:36, 15 November 2020 (UTC)
What on earth are you talking about. You don't seem to have even read the post that I was replying to since your self-important post is about something else entirely. As to the rest of your post a little frustration is a) not damaging and b) part and parcel of editing around here for editors old and new. BTW new editors have several other venues to find out what is going on and ask for help. Try getting a sense of perspective please. Hundreds of thousands if people dead who should be alive is "damage" what you are talking about isn't. MarnetteD|Talk 21:08, 15 November 2020 (UTC)
"A new editor with an interest in (for instance) the history of Naples will reasonably assume that Wikipedia talk:WikiProject Kingdom of Naples is the place to ask questions." A new editor is highly unlikely to have any clue that WikiProjects in general even exist. (Heck, many new editors barely even know that talk pages exist.) The average newbie with a question will go to the talk page for the article in question. --Khajidha (talk) 16:41, 24 November 2020 (UTC)
A as editor that has all the projects on my watchlist I can attest to the fact inactive projects do not reply to questions posed. But this is also true of many active projects....all depends on what people wish to reply to. Perhaps part of the solution could be to add an explanation saying questions may not be answered here and to go to the teahouse in big giant text on {{WikiProject status}} for dead projects.--Moxy 🍁 15:06, 15 November 2020 (UTC)
Yeah, the proper replacement for a specific inactive project is not always a more general, active project. What are the chances that a sufficient proportion of the 128 watchers of WikiProject Italy would be interested enough in the historic kingdom of Naples to provide answers to questions about it? In many cases like this, the best discussion page will actually be the talk page of an article – Kingdom of Naples has almost as many watchers as the entire Italian wikiproject, and presumably a much higher ratio of editors with knowledge of, and interest in, the kingdom. – Uanfala (talk) 17:48, 15 November 2020 (UTC)
I agree that editors should be encouraged to use existing, active venues instead of creating new ones as much as possible, and I support editors who are motivated to mark projects as inactive. I also agree there is an overall detrimental effect with having so many unlabelled inactive projects, making it harder to find the ones that truly can provide assistance. Note, though, this is a general issue across the Internet: there are many discussion areas that have faded out, and those seeking assistance learn how to gauge activity levels and temper their expectations accordingly. While still a factor for editor retention, I suspect it doesn't cause new editors to ascribe malevolent motives to the community. It rather creates the impression of a ghost town, which discourages people from getting involved. isaacl (talk) 20:08, 15 November 2020 (UTC)
This is very well put. It gives me the thought that perhaps talk/discussion pages ought to display the number of watchers more prominently than hiding it away in the page information section (but even so, beginners won't know how to interpret "<30" or whatever the number might be). {{u|Sdkb}} talk 02:46, 16 November 2020 (UTC)
Yes, I previously said on the WikiProject Council talk page that editors interested in a subject who want to co-ordinate and discuss points of interest should find an appropriate existing venue, particularly one where more interested participants can be found. Generally this will mean using the discussion page for an appropriate, active WikiProject. If that becomes unwieldy, then perhaps a separate venue could be considered. However that has to be weighed against the costs of starting it up and trying to preserve and increase its audience. isaacl (talk) 19:46, 15 November 2020 (UTC)
WikiProjects should be a good way to encourage editors to focus their activities on editing the articles within their area of interest. As such we should encourage the creation of projects that seem to have a collection of enthusiastic editors – regardless of how wide or narrow is their area of interest. Once created we also need to take care to label projects as inactive once the initial enthusiasm wears off. We seem to have a WikiProject for WikiProjects, so I assume that one of their main functions is that encouragement and the subsequent ongoing monitoring of project activity to allow the status of each project to be updated accordingly. — GhostInTheMachine talk to me 15:47, 15 November 2020 (UTC)
Chiming in briefly to say that Wikiproject history is almost totally inactive, except as a general community forum; while other history-related wikiprojects that have even a small amount of greater specific focus are exponentially more active. for example WP Military history, Women in Red, etc etc. so I absolutely agree that a broader, more generic scope is often not better or more attractive to editors; on the contrary, in the case of history, the majority of editor activity is at wikiprojects that have at least some degree of greater topical focus. --Sm8900 (talk) 18:19, 15 November 2020 (UTC)
The history project has the classic hierarchy structure problem. Not to many people want to join groups with bosses telling them what to do..... does not look like a cooperative but an administrative structure with a hierarchy of best editors. It is also extremely confusing telling new editors post here for this post over there for this post and there for that post. The project pages overwhelmed with rules.--Moxy 🍁 20:24, 15 November 2020 (UTC)
GhostInTheMachine, I agree with you about how to measure size. The relevant size is number of editors, not number of pages. 10 editors working on 100 pages is a much bigger WikiProject than two editors working on a million pages. WhatamIdoing (talk) 02:32, 16 November 2020 (UTC)
@Sdkb: thanks for this, but I don't think this a problem greater than the solutions that we currently use. The participants in WP:WikiProject Council (feel free to join us there!) discourage many a too narrow project, and as to the future certain fading of interest in particular projects, who cares? Yes, WP:WikiProject Joe Biden will likely not be useful in a few years, but it is useful to bring together a group of editors now, and so it is good that it exists. There is very, very little cost to a project that's no longer useful: mark it and its banner as inactive, and move on. UnitedStatesian (talk) 04:37, 18 November 2020 (UTC)
@UnitedStatesian: I do appreciate the work that goes on there, but the reason I brought up this discussion is that I think our current approach is evidently inadequate. {{u|Sdkb}} talk 05:31, 18 November 2020 (UTC)
Wikiprojects come and go in terms of activity, but keeping a dormant project takes less work than MFDing it and increases the chances of people reviving it in the future. We also need to remember the context, currently we have a broadly stable community, but if the WMF ever gives us a viable smartphone editor we are likely to go through another major growth phase with opportunities for newbies to revive Wikiprojects in the areas they care about. ϢereSpielChequers 10:28, 18 November 2020 (UTC)
Even active projects typically function very little as an engine for collaborative article improvement these days - as always Milhist may be the exception. By far the largest actual project-related activity is adding talk page banners and ratings. New projects tend to start with a big burst of that, and then just .... stop. These ratings are only of any utility if people then use them to find eg low quality/high importance articles to improve, but this seems to happen rather rarely. A Biden project is almost the only viable proposal for a new project I can think of - it should be "Biden administration" though. Johnbod (talk) 15:12, 18 November 2020 (UTC)
I'm pretty satisfied with the prospects for Wikipedia:WikiProject COVID-19. Like the Biden group, it'll probably fade away in a few years, but it's been useful. WhatamIdoing (talk) 20:56, 18 November 2020 (UTC)

Talk page notifications when topic equivalent is promoted to quality status on another project?

I think it'd be cool if a bot could be designed to add Talk page notifications when the subject's article is promoted to Quality status at another Wikipedia project. To pick an artbitrary example, a notification could have been added to en:Talk:G.U.Y. when hu:G.U.Y. was promoted to quality status.

Added benefits could be editors comparing different language versions, encouraging translation efforts, and more editors becoming familiar with Wikidata, depending on the notification's text and bot design. I could also see notifications being posted to WikiProject talk pages, etc.

Thoughts? Concerns? Other feedback? Sorry if this idea has been brought to the table before. ---Another Believer (Talk) 00:10, 20 November 2020 (UTC)

Another Believer, bot requests will get more useful feedback if you post them to WP:BOTREQ than here, so I'd suggest moving this there. {{u|Sdkb}} talk 08:09, 20 November 2020 (UTC)
Sdkb, Thanks, I've copied my request over there. ---Another Believer (Talk) 15:38, 24 November 2020 (UTC)

Volume warning flag.

I would propose adding a flag for audio files to indicate that it may be LOUD and to tell users of headphones to turn down their volume before playing the file. -- Waterthatisdry (talk) 13:23, 23 November 2020 (UTC)

Waterthatisdry, where would you want the flag to go? Our display of audio files in general needs a lot of improvement. {{u|Sdkb}} talk 17:33, 23 November 2020 (UTC)
Isn't it just common sense to turn your speakers/headphones down before playing a file and then turning them up if needed? --Khajidha (talk) 16:07, 24 November 2020 (UTC)

Honor prefers-reduced-motion setting

Tracked in Phabricator
Task T264442
Resolved

It would be nice if the donation nag screen would honor the "prefers-reduced-motion" setting by skipping the slide-in animation if enabled: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion — Preceding unsigned comment added by 84.59.252.191 (talk) 23:52, 19 November 2020 (UTC)

Thanks for the feedback. This is already on our to-do list (phab:T264442) and I'm hoping to work on it next week. Peter Coombe (Wikimedia Foundation) (talk) 18:08, 20 November 2020 (UTC)
This is done now. Peter Coombe (Wikimedia Foundation) (talk) 17:18, 25 November 2020 (UTC)

Renaming the "oversight" team

This may seem like something on a whim, but "oversight" can be misleading to new users requesting information being suppressed. "Oversight" implies that the user is "overseeing" something, see Lexico. While we did have a tool called "oversight", that was over a decade ago before we had RevisionDelete (and the suppression mode in that MW feature). So I think it would be better to rename the "oversight team" to "suppression team", add an alias for "suppression-en-wp" and make it the primary alias for the "oversight-en-wp" mailing list, change MediaWiki:Group-oversight and related pages to "suppressor" and rename the "oversight policy" to "suppression policy". Aasim (talk) 18:01, 25 November 2020 (UTC)

I understand where you are coming from, but if you thought "oversight" had linguistic baggage, "suppression" may have even more, especially if people start viewing "Wikipedia overighters/suppressors" through a political lens. That said, suppression is more accurate once you see past the linguistic baggage. davidwr/(talk)/(contribs) 18:21, 25 November 2020 (UTC)
@Davidwr would "redaction" be better? Aasim (talk) 19:59, 25 November 2020 (UTC)
@Awesome Aasim: Better yes, unfortunately the term is already in use, see Wikipedia:Revision deletion#Criteria for redaction. Maybe "level 2 redaction"? But "level 2 anything" has baggage when it comes to Wikipedia user-rights - remember "level 2 pending protection?" I'm not sure where to go from here. I do prefer "redaction" over "suppression" or "oversight" but not enough to want to "hijack" its existing use. davidwr/(talk)/(contribs) 20:06, 25 November 2020 (UTC)
  • abolisher / abolishing
  • annihilator / annihilating
  • bluepenciler / bluepenciling
  • censor / censoring
  • concealer / concealing
  • container / containing
  • controller / controlling
  • curber / curbing
  • deadener / deadening
  • effacer / effacing
  • elider / eliding
  • emender / emending
  • expunger / expunging
  • expurgator / expurgating
  • extinguisher / extinguishing
  • husher / hushing
  • inhibitor / inhibition
  • invisibilizer / invisibilizing
  • kibosher / kiboshing
  • launderer / laundering
  • limiter / limiting
  • muffler / muffling
  • muzzler / muzzling
  • nuker / nuking
  • obliterator / obliterating
  • protecter / protecting
  • quasher / quashing
  • queller / quelling
  • quencher / quenching
  • rectifier / rectifying
  • redactor / redaction
  • redliner / redlining
  • remover / removing
  • repressor / repressesing
  • restrainer / restraining
  • shielder / shielding
  • shusher / shushing
  • silencer / silencing
  • smotherer / smothering
  • snuffer / snuffing
  • spiker / spiking
  • stifler / stifling
  • subduing / subduction
  • suppressor / suppression
  • withholder / withholding

--Guy Macon (talk) 23:15, 25 November 2020 (UTC)

I like "vanishers", with its hints of secret agent/organized crime powers... Schazjmd (talk) 23:20, 25 November 2020 (UTC)
If this is a serious list, I like "concealer/concealing" and "expunger/expunging." If it's meant for humor, the funny-sounding ones like "shusher" put a smile on my face. davidwr/(talk)/(contribs) 23:33, 25 November 2020 (UTC)
It's actually both. Sometimes a silly suggestion causes someone to come up with a great solution that nobody has thought of yet. Other times it just results in a small chuckle. --Guy Macon (talk) 23:41, 25 November 2020 (UTC)
Guy Macon, "can someone ping the smotherer team? we need this smothered to prevent harassment." Hmm... Natureium (talk) 02:59, 26 November 2020 (UTC)
  • We've had this discussion before over on the Oversight talk page. As someone who is an oversighter, I'd much rather be called an oversighter than any one of the suggestions above, most of which have very negative connotations, and most of which are even less accurate than the current name of the role. The extension is called "suppression" and there was a very conscious decision at the time of creating the extension not to change the name of the role, because the logical alternate name was suppressor, which also has very negative connotations. The user right's name is rooted in history (it is the name of the extension that was in use until early 2009), and I'm not seeing a good reason for obliterating a part of our history. Seriously...shusher? restrainer? queller? This list feels more like someone spent a fun time with their thesaurus (something I've been known to do myself - this isn't a dig!) than really thinking about a different name that is more appropriate to the role. Risker (talk) 02:40, 26 November 2020 (UTC)
See brainstorming. "brainstorming is a situation where a group of people meet to generate new ideas and solutions around a specific domain of interest by removing inhibitions. People are able to think more freely and they suggest as many spontaneous new ideas as possible. All the ideas are noted down without criticism and after the brainstorming session the ideas are evaluated." It really does work but not every time. Every so often someone looks at an idea like shusher and it causes them to come up with a great idea that nobody has thought of before. If you criticize the shusher suggestion from the start (or worse, if it is never suggested because the group doesn't understand brainstorming), you never get that great idea. A classic case is the CPAP mask that goes over the nose but not the mouth. They started with a bunch of silly and obviously bad naming suggestions ("hose up the nose", "snot rocket") and, through brainstorming, came up with the perfect name: "nasal pillow".[3]. --Guy Macon (talk) 07:31, 26 November 2020 (UTC)
Re: "there was a very conscious decision at the time of creating the extension not to change the name of the role", this is the village pump idea lab, not village pump proposals. As it says at the top of this page, "The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas." and "This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them." --Guy Macon (talk) 07:31, 26 November 2020 (UTC)
Suppression always reminds me of the trial scene from Alice in Wonderland: “Here one of the guinea-pigs cheered, and was immediately suppressed by the officers of the court. (As that is rather a hard word, I will just explain to you how it was done. They had a large canvas bag, which tied up at the mouth with strings: into this they slipped the guinea-pig, head first, and then sat upon it.)” Oh, there we go: call them baggers!—Odysseus1479 04:05, 26 November 2020 (UTC)
I think the thing is oversighters are not suppressing things from the public, nor are they overseeing anything. I see how "suppression" can equate to "censorship" and that is not who we are. "Redactor" seems more neutral, as they are just redacting certain types of information that Wikipedia deems inappropriate. Maybe "redaction team"? Aasim (talk) 09:23, 26 November 2020 (UTC)
I like redaction better that suppression (too negative) or oversight (sounds too much like a congressional committee signing off on drone strikes). Then again, "annihilator" sounds like a pro wrestler, which is a plus.[Citation Needed] --Guy Macon (talk) 09:43, 26 November 2020 (UTC)
If we are really going to change this, shouldn't we also look at what admins do? Currently anyone can redact or blank things, Admins delete things, but when deletion isn't enough, we oversight things. A more logical sequence would be, anyone can blank things, admins can conceal things and oversighters can delete things. Yes changing over to such a system would be a tad annoying to some existing editors and a bit surprising to some returning oldtimers in the future. But for the 99.9% of people who deal with us, a more logical system that was closer to plain English would help demistify and dejargonise a site that often seems more complicated and unfriendly to casual users than it truly wants to be. ϢereSpielChequers 10:53, 26 November 2020 (UTC)
  • If we are going to change names (and, btw, I would be viewed as a weak oppose at this point), I'd be in favour of "expunge/expunger" - clear, and without baggage, and also understandable as a more aggressive form of deletion. Nosebagbear (talk) 14:15, 28 November 2020 (UTC)

Extension to check paper quality in Wikipedia sources - expand/integrate?

Came across an extension today called scite; to quote its website, it, "easily check[s] how an article has been cited and if it has been supported or disputed by others." On the right is a sample of it running on the Quantum computing page.

Obviously, it's not running on non-academic sources, but it seems like a valuable resource. The source code, it seems, is available online here. Is there any way we can adapt/expand this into broader usefulness for Wikipedia, and perhaps even make it an integrated option for users?

--Nerd1a4i (talk) 19:22, 1 December 2020 (UTC)

New twinkle idea

We might possibly add a feature to tag pages with stub templates, is that ok? Because manually stubbing articles is very inconvenient. --a gd fan (talk) 19:57, 1 December 2020 (UTC)

There are already a few tools for stub sorting. You can find some of them here. As for adding this feature into Twinkle, it would probably be better if you posted your proposal here instead, as that is the talk page for the Twinkle gadget, and Twinkle developers and users will most likely be looking there instead. PorkchopGMXPush to talk! is signing off w/ 4 tildes. 00:02, 2 December 2020 (UTC)

Unsubmitted drafts

A perennial question at the Teahouse is, "I have completed my draft; how do I submit it for review?" or worse, "I completed my page three months ago; why isn't it in the encyclopedia yet?" The problem is that they created a draft or user draft without a Submit button. Ideas that occur to me include adding instructions to the boilerplate text on the edit screen of draft or user pages on how to submit a draft or add a submit button and/or even adding a submit button as default content of new draft or user draft pages. —teb728 t c 07:25, 10 November 2020 (UTC)

So this may or may not be appropriate for user pages, but would definitely be a good idea for Draft pages. One issue is that the quickest way to direct submit an already created draft to AfC can't (very simply) be done through Visual Editor, which obviously is the editors most used by 1st-time draft creators. Nosebagbear (talk) 09:37, 10 November 2020 (UTC)
  • Yeah, we ought to figure out what's going on with this. There's a hole somewhere in the maze of ways that people come to create a draft page that is allowing them to do so without there being a submit button. Maybe we should have some sort of persistent notice on all draftspace pages that includes the submit button? {{u|Sdkb}} talk 23:02, 10 November 2020 (UTC)
  • Even most experienced editors would not know how to do this if they did not assist at AFC. The original boiler plate templated draft does have the afc template with button, but that is quite easy to get lost when editing. So it would best to have this "submit draft" as a standard feature, rather than as an add-on gadget only available to the approved. The standard feature should only have the option to submit as myself, rather than submit as anyone else though. And if the visual editor is used, it will carefully add nowiki tags around the submit template. Graeme Bartlett (talk) 23:18, 10 November 2020 (UTC)
  • The draft namespace editnotice can be edited to include a small submit link. – SD0001 (talk) 13:36, 11 November 2020 (UTC)
    Except that Wikipedia:Nobody reads the directions, especially in an edit notice. Maybe a bot could leave a "personal" message on the creator's user talk page after, e.g., 30 days with no edits to the draft. It would be easy to limit this to relatively inexperienced editors.
    Teb728, does the Teahouse have a FAQ? That might reduce the volume of these questions. WhatamIdoing (talk) 03:57, 14 November 2020 (UTC)
Hasteur Bot notified page creators on their talk page after a draft had gone 5 months without editing activity because at 6 months, it gets tagged as a CSD G13 stale draft. But that bot was deactivated in April and we are waiting for the new bot serving this function to be activated by the bot operator Mdaniels5757. Liz Read! Talk! 04:04, 14 November 2020 (UTC)
FAQ was discussed at Wikipedia talk:Teahouse/Archive 20#Adding a link to the FAQ page at the top of the page and the edit notice. It was decided to add a search box to the header which searched Help and Wikipedia:FAQ and subpages. —teb728 t c 08:40, 14 November 2020 (UTC)
  • Perhaps it would make more sense to have a bot drop the gray "press here to submit" box onto any draft created? (The one that goes on if you create your draft through article wizard) Nosebagbear (talk) 17:24, 15 November 2020 (UTC)
  • What I'd really like to see is a much more prominent notice informing the editors that they don't need to "submit" the draft for review at all, don't need to get involved with the AfC but have the option of publishing a draft directly to mainspace via a pagemove. Every autoconfirmed editor can do that but many of them have no idea about it and they spend weeks and months waiting for their submission to be reviewed at AfC often to get a completely random result back. There needs to be a big green button on every draft "move/publish to mainspace". Nsk92 (talk) 23:55, 18 November 2020 (UTC)
    Nsk92, I suppose we could create a template to make it easy to let people know that. WhatamIdoing (talk) 06:05, 3 December 2020 (UTC)
@WhatamIdoing: Or, better yet, modify one of the existing templates, by adding an extra button there, e.g. Template:Draft article. I made a suggestion at Template talk:Draft article#Publish/move to mainspace button a while ago, but of course there was no response; apparently nobody reads those talk pages. Nsk92 (talk) 06:42, 3 December 2020 (UTC)

Creation of a CSD criteria for articles and drafts with no encyclopedic value

Moved to Wikipedia talk:Criteria for speedy deletion § Creation of a CSD criterion for articles and drafts with no encyclopedic value
 – Moved discussion to proper venue for discussion criteria for speedy deletion. Regards SoWhy 17:24, 22 November 2020 (UTC)
Discussion closed as failed. Graeme Bartlett (talk) 09:41, 3 December 2020 (UTC)

Filenames starting with a dot

In Unix-like operating systems, any file or folder that starts with a dot character (for example, /home/user/.config), commonly called a dot file or dotfile, is to be treated as hidden – that is, the ls command does not display them unless the -a or -A flags (ls -a or ls -A) are used. (Unix-like includes macOS btw)

I tried this and while modern browsers seem to remove the dot when downloading, with a download manager I ended up with a hidden file. When the browser removes the dot, there could still be confusion as the downloaded file now differs from the file on Wikipedia in filename. Here's list of files on Wikipedia that start with a dot. Is there any particular reason filenames that start with a dot aren't forbidden? — Alexis Jazz (talk or ping me) 02:32, 2 December 2020 (UTC)

The technical constraints on naming of files are the same as the ones for other pages. A good reason is needed for forbidding titles, not for not forbidding them.
FWIW, page names beginning with patterns that Unix treats as directory navigation, such as ./ and ../ are indeed forbidden. – SD0001 (talk) 15:39, 2 December 2020 (UTC)
@SD0001: Thanks, I meant more like, is there some compelling reason why these must be allowed? — Alexis Jazz (talk or ping me) 17:11, 2 December 2020 (UTC)
We live in the real world. Maybe it would be better if programs running on Unix-like systems were a bit cleverer about such file names, but many are not, so Wikipedia should conform to such restrictions imposed by any major platforms that readers and editors use. Phil Bridger (talk) 19:14, 2 December 2020 (UTC)

The edit requests time sink

Misuse of the WP:Edit requests facility is often a significant time consumer for experienced volunteers. Donald Trump, for example, averages about two edit requests per day, and upwards of 95% are one of the following, the first being far more common:

  • A request for a change that does not meet the requirement for "uncontroversial", thus requiring discussion. This is effectively a substitute for the "New section" link at the top of the talk page, which is not how the facility was designed to be used.
  • A request to be granted the right to edit the article.

In either case, significant editor time is required to respond to the request in a meaningful way. In the first case above, the response is often: It's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. – entirely missing the point that edit request should not be used for that kind of change in the first place. The problem there is not that the request was not specific enough.

I think it's clear that some change is needed, and I offer two ideas to start:

  • Clarify the instructions that a reader gets when they click "View source" at a protected article. As well as wording changes, this could de-emphasize the big blue Submit an edit request button, which likely attracts the reader's eye like a moth to a flame, sending the message "This is what you most likely want." This button could be reduced to a simple text link, giving it the same prominence as the "Discuss this page with others" link to the talk page. Additionally, there could be a link that does the same thing as the "New section" link; i.e. opens the dialog for creating a new talk page section.
  • And/or, allow the edit request facility to be turned off at an individual article. This could be used where very little does not require discussion and where there is always someone around to handle uncontroversial changes. ―Mandruss ☎ 05:17, 2 December 2020 (UTC)
    @Mandruss: Make the first bullet point "Suggest a minor uncontroversial change." and make the blue button "Suggest a change". — Alexis Jazz (talk or ping me) 10:09, 2 December 2020 (UTC)
    this could de-emphasize the big blue Submit an edit request button, which likely attracts the reader's eye like a moth to a flame, sending the message "This is what you most likely want." Well, yeah, that's the point, because the default operating mode is "you can edit". :^)
    Response helper needs some work tbh; I might look into that as A Project. --Izno (talk) 19:28, 2 December 2020 (UTC)
    Another point is that edit requests are for uncontroversial edits or edits that already have consensus. That's in the instructions, both at WP:Edit requests and in what is presented to the user in the path to edit request. If the facility can be misused in 95% of cases at one article, there is something wrong with users' understanding, and that's the fault of the facility, not the users. Part of the problem may be that it is not clear to a non-editor that "uncontroversial" means "discussion not needed" in this context, and that could be made more clear, possibly by eliminating the ambiguous word "uncontroversial" completely. ―Mandruss ☎ 19:53, 2 December 2020 (UTC)
  • Agreed that this is a problem, and that the edit request template is the place to solve it. I think having two buttons (one for minor edits, one for non-minor) would be a good first step. It won't stop the "please let me edit the page" requests, but it'll help with the non-minor requests. {{u|Sdkb}} talk 12:29, 2 December 2020 (UTC)
  • I see a lot of edit requests that are essentially spam, vandalism or test edits. These often contain no actionable request. They might be botable with some time logging the edit requests and looking for patterns. Once patterns are determined these edit requests can be automatically removed. Obviously the bot would need to be careful but it is doable. -- GreenC 18:17, 2 December 2020 (UTC)
  • I've been wondering whether the problem isn't the "button", but our expectations for suggestions made by inexperienced people. Maybe we shouldn't expect {{edit protected}} to be used only for uncontroversial and pre-agreed content. Maybe we should adjust our expectations so that we expect requests to sit around for days (perhaps with a built-in "waiting for consensus" timer) while editors decide whether the edit should be made, instead of limiting requests to what MediaWiki:Protectedpagetext calls "simple, uncontroversial" suggestions. WhatamIdoing (talk) 05:58, 3 December 2020 (UTC)
    I think the template we're talking about is {{Protected page text}}, which the MediaWiki page just implements. Mandruss, if you or anyone else wants to mock up a sandbox, it'd be nice to have something concrete to consider. {{u|Sdkb}} talk 07:10, 3 December 2020 (UTC)
    What WhatamIdoing has described (minus the "timer") is called a discussion, and the dialog already gives the user that option (although it requires them to find the "New section" link, unnecessarily). The edit request facility is needed only for low-activity protected articles, where the only way to get somebody's attention is to put the talk page in a tracking category. Otherwise there is no reason why the normal discussion process couldn't be used for all changes, controversial or uncontroversial, and the user wouldn't be required to know the difference. If no discussion were needed, none would occur and the sole response would be  Done.
    Sdkb, I'd prefer to wait for more discussion; it's not clear that's even the right direction. ―Mandruss ☎ 07:29, 3 December 2020 (UTC)
    Even for low-activity pages, I've had edit requests declined by some helpers who take a very hardline view that it should only be invoked once it's fully ready for implementation, which makes some sense but is hard to enforce and not really de facto what happens. That's a little beside the point, though. I agree with you that discussions ought to be done as discussions, and I maintain that making the "start discussion" and "make edit request" options at {{Protected page text}} more equal in prominence would help out a lot. More discussion here sounds fine. {{u|Sdkb}} talk 20:58, 3 December 2020 (UTC)

Draftification reform

I'd like to ask for your opinion on introducing a formal series of requirements that, if an article meets them, must be moved to draftspace (but this does not imply that articles that do not meet these requirements cannot be draftified)? My only idea so far is that if the article is a biography of a living person with under ten references, then it should be draftified. I understand the four requirements listed at WP:DRAFT but those are more general; I'd like to ask if you'd support my idea of introducing more formal criteria for draftification, much like speedy deletion. JJP...MASTER![talk to] JJP... master? 02:33, 5 December 2020 (UTC)

Under 10? That's a non-starter. Pick a famous person from a generation ago who happens to be still alive. The draft-writer may be getting almost all his information from one or two full-length biographies about the subject, yet still be able to write a B-class-or-better article. davidwr/(talk)/(contribs) 03:53, 5 December 2020 (UTC)
The idea of "speedy draftication" requirements sounds reasonable, but that specific requirement sounds overly strict. Gbear605 (talk) 05:08, 5 December 2020 (UTC)
Keep in mind the village pump consensus recently established (here) that limits draftification to recently-created articles: I would expect pretty strong objection to any proposed approach that would result in draftifying articles that have been in mainspace more than a few months. UnitedStatesian (talk) 06:05, 5 December 2020 (UTC)
Under 10 references? That's just silly. Also, draftification when nobody has volunteered to work on it is evil. — Alexis Jazz (talk or ping me) 21:15, 6 December 2020 (UTC)
I don't know about 'evil' but I do agree there's a real risk with draftication, when no-one has offered to work on it, that it just drags out the deletion process needlessly. I think as a whole, it wouldn't work to have codified rules for drafticications, since the reasoning behind them is inherently a bit of a judgement call of "I can see that this could be a good article". Also yeah, 10 references, jeez. --Paul ❬talk❭ 15:27, 10 December 2020 (UTC)

Non-JavaScript UI alternative to filter date ranges of Special:Contributions

What I would like is a non-JavaScript interface (alternative) version of the date filtering feature of Special:Contributions. The change to JavaScript interface in 2017 has not impressed me more. Neither has the change to OOUI (phab:T117736). The date range filtering is somewhat annoying to execute. The filtering prevents me from surfing contribution logs outside the date range, especially when I use the same date for both "From date" and "To date" filters. I have to either click "Contributions" link to return to default or change dates. Furthermore, I am also either annoyed by or not thrilled with clicking/tapping "Search for contributions" header to expand the filtering feature.

I wrote another task asking for the return of pre-JavaScript UI, but it was declined (phab:T170502). Since Phab people won't return the pre-JavaScript interface to us, shall I go for either proposing a gadget or asking for a global or local user script to implement that same UI before the 2017 change? Alternatively, I would like another version of the UI that is not reliant on JavaScript but rather loads more quickly, especially on most browsers. Or, shall I say a UI option that does not use JavaScript. But that would want me to file a request at Phabricator. George Ho (talk) 18:49, 10 December 2020 (UTC)

Project/task force to address undetected vandalism

For the past few years I have been running searches on, for lack of a better term, words and phrases vandals tend to insert into articles. This hasn't been an especially rigorous project, it's more just "as I think of it."

The results have not been pretty. So far I've turned up literally hundreds -- I don't think it's in the thousands yet, but I think it's very possible I could reach that point -- of instances of undetected vandalism, including cases that have:

  • Gone undetected for more than a decade -- the longest I've found is 13 years
  • Been on high-profile articles, often for non-trivial amounts of time
  • Been scraped and/or cited by external sources, possibly showing up on Google since their searches also scrape Wikipedia but I haven't checked, etc.

This isn't particularly subtle vandalism, either. This is low-hanging fruit, "Mike Oxlong captained the ship USS Boner and had 420 kills" type stuff. Goodness knows how much subtle stuff remains undetected.

Needless to say, this is very bad and embarrassing. We have vandalism bots, but clearly they are not doing a good enough job if this kind of thing can routinely slip through the cracks. So, I was wondering if there was any interest in a more organized, formal project to sweep the wiki for undetected vandalism. Hoaxes and other forms of vandalism could obviously fall under this, but really, there is so much obvious, blatant stuff that just sits there and becomes entrenched by inertia. Gnomingstuff (talk) 22:24, 4 November 2020 (UTC)

@Gnomingstuff: Thanks for fighting the vandalism! Check out the project at WP:CVU. I think it is what you are looking for. If you have suggestions on how to find subtle vandalism, you can start a discussion there. RudolfRed (talk) 18:17, 5 November 2020 (UTC)
I've cross-posted this there, but it doesn't seem very active, and is more focused on monitoring/automating the monitoring of recent edits from what I can tell. Which is obviously good and necessary, just not enough, especially after 10+ years of edits built up. Gnomingstuff (talk) 21:02, 5 November 2020 (UTC)
Also, just to clarify, this isn't necessarily about subtle vandalism. By nature of how I'm looking for these edits, only blatant vandalism will be caught. (Like the "dicking mechanism" below, perfect example.) Obviously it'd be great to have a way to find the longer-lasting subtle stuff, but I don't have one right now. Gnomingstuff (talk) 21:05, 5 November 2020 (UTC)
I won't be able to help, but such a project is absolutely a good idea. I'd be really interested in a seeing a catalogue of long-lived blatant edits (the way we have one for hoaxes). My favourite one was about a power loom's picking dicking mechanism [4], which managed to spread all over the internet before getting picked up eleven years later. – Uanfala (talk) 18:58, 5 November 2020 (UTC)
I am FAR from a coding or computer expert, so there's a non-zero chance everything I'm about to say is bullshit: It seems to me that ClueBot NG is, while incredibly useful, becoming obsolete. What we seem to need is some sort of more advanced machine learning than what CNG has right now. Here's my idea: Have a specific button in the edit history to tag every edit, ever, as vandalism. Push that button, the diff is sent to a centralized hub where human editors look over it to determine if it really is vandalism. If it is, it's marked as such again, and sent to a bot, which is somehow able to know that edits like this are vandalism (I know this technology exists but I don't know how to implement it), and reverts them in the future. If an edit made by the bot is reverted, there should be a button to report it, where it's sent to a different centralized hub. If the revert was correct, a message is sent to the bot telling it to be more careful reverting edits like those. If the revert was in error, nothing is done to the bot. Again, I don't know how feasible this is, but it sounds very complicated. Pinging Crispy1989 and Cobi, creators and maintainers of ClueBot NG, who are undoubtedly more knowledgeable about this stuff than me. Squeeps10 Talk to meplease ping me 02:42, 21 November 2020 (UTC)
We seem to have no evidence of a "Coors 420" having been called that, and haven't for eleven years, seven months and eleven days. InedibleHulk (talk) 05:25, 13 December 2020 (UTC)

Possible partial solution to British English/American English debate

Hello,

I was considering this topic earlier after reading that it was proposed at some point in the past that Wikipedia should be split into "uk.wikipedia" and "us.wikipedia". I think I have a (partial) solution to the issue which won't split the community.

I'm not sure how feasible this is in the technical sense, but I was thinking a dropdown could be added to the top of all pages (somewhere around where all the current links and buttons reside) which allows a choice of British English, American English, or 'As on page' (not sure about the wording of that one, basically meaning don't change anything, just display what's on the page). When one of the first two options is selected, any relevant words on the page are automatically changed to the regional equivalent as dictated by the dropdown, including title (for example, the page title for Gasoline would instead display as 'Petrol' if British English was selected). The keyword here is 'automatically': this would be accomplished without any need to change the wikitext on a page, so that no editor effort is required to achieve it. The option selected would merely 'search and replace' any relevant words, without actually changing the underlying wikitext (for instance, if there was a word on a page changed by this option which was wikilinked, the wikilink would continue to point to the correct page while only the text itself would be changed.) Some issues that I have thought of:

1. If an editor changes the setting and forgets about it, they may be confused when they edit a page and certain words are suddenly spelled differently. It could result in them changing the spelling in the article when it should use the other spelling in the first place. A possible solution to this is that they are warned somehow when editing a page that some spellings may differ due to their language setting.

2. Where articles list names used in other countries, it might be necessary to use formatting to make the order respect the language setting. To take the example of the gasoline page again, the lead states "Gasoline, or petrol". If British English was selected, the order would have to be reversed. It would be preferable for this to be automatic, but I'm not sure how that would work.

There may be more issues. If you can think of any, please let me know. I'm hoping there wouldn't be major issues with this, as I do feel that it would be quite an effective way to reduce debates and disputes regarding spelling in articles where it isn't clear which should be used.

I hope I explained this sufficiently. Please feel free to ask questions, and let me know what you think. Thank you. DesertPipeline (talk) 08:37, 6 December 2020 (UTC)

I bet the Australians and South Africans will be super excited over this proposal. --Guy Macon (talk) 09:06, 6 December 2020 (UTC)
Presumably you mean that we should also include options for them as well? I only mention British/American English because they're the two most common. Perhaps the community could extend the available languages, adding new options to the dropdown, but not present by default. The British/American differences seem to cause the most issues on the English Wikipedia. Or am I wrong? DesertPipeline (talk) 09:20, 6 December 2020 (UTC)
I don't know how you'd tell which differences cause the most issues - but worth noting that Britain is not even in the top five most speakers of English. --Paul ❬talk❭ 15:46, 8 December 2020 (UTC)
This is not technically possible because it is impossible to replace words without regard to context. We do not employ semantic markup to distinguish proper names, quotes, words-as-words etc. and it would be improper to convert those.
What is possible is to convert between different scripts without introducing semantic differences. For instance, the Chinese-language Wikipedia works pretty much how you describe it, allowing the user to change between traditional and simplified scripts that are automatically converted. This prevented the Chinese Wikipedia from being split to two different projects. – Finnusertop (talk ⋅ contribs) 10:11, 6 December 2020 (UTC)
Then would a better idea be to use wikitext to distinguish words which have alternative spellings which should be changed? The problem then is that it requires user effort, and I don't want to require people to make sweeping changes just for this. There is however a "notatypo" template which allows to mark a word as not to be corrected which could be used for this purpose. But is there no way that it can be done automatically, or semi-automatically? DesertPipeline (talk) 10:36, 6 December 2020 (UTC)
@DesertPipeline: This could maybe be achieved with Module:LangSwitch (not sure if that'll accept en-GB), but I wouldn't recommend it, exactly because of the effort. Automatic replacement can be done technically but without context this is a terrible idea as Gasoline Alley (album) would become "Petrol Alley". And sometimes it's more than just a single word. This will become very complicated very fast. — Alexis Jazz (talk or ping me) 12:31, 6 December 2020 (UTC)
And it would all be for very little benefit. I am British and very rarely have any problems with understanding any variety of English, and when I do I treat it as a learning opportunity. Phil Bridger (talk) 13:18, 6 December 2020 (UTC)
Take "torch" as an example. An automated process would have to determine what was meant: an electric torch (that is, a flashlight), or a flaming torch. Without additional hints from the writer, it's not an easy thing to do. "Lift" is another noun with multiple interpretations: lift/elevator, lift/ride, and mechanical lift. Personally I don't think that the benefit/cost ratio is worthwhile. isaacl (talk) 22:21, 6 December 2020 (UTC)
@Isaac: Torches are used for metalworking no? — Alexis Jazz (talk or ping me) 22:42, 6 December 2020 (UTC)
Sure. It's another example of where context is needed: within an article about metalworking, although an initial use of the word torch would be expected to have an accompanying adjective (or adjective phrase), subsequent uses (within the same section at least) wouldn't need it. isaacl (talk) 22:58, 6 December 2020 (UTC)
The accompanying adjective usually helps but not always. An Acetylene torch usually means something used to weld metal but it may refer to a UK version of an obsolete handheld light source from before the invention of compact batteries. --Guy Macon (talk) 13:07, 7 December 2020 (UTC)
I was speaking from a writing style perspective, but yes, from an automated translation perspective, accompanying adjectives do not necessarily avoid the need for context. isaacl (talk) 21:34, 7 December 2020 (UTC)
See also META:Abstract Wikipedia — GhostInTheMachine talk to me 18:47, 6 December 2020 (UTC)
  • This idea has been bubbling around for more than a decade. strategy:Proposal:More_multi_dialect_wikis was on the strategy Wiki in 2010. It might address our relatively low readership in the US as opposed to the UK and Canada. Since the various versions of English tend to be geographically concentrated it should be possible to have Wikipedia default to displaying the version of English most likely to be right for that geography. As for the need to put hidden templates and the like for words like hood, bonnet and pants, we have people who like doing hundreds of thousands of such semi automated edits, and it should make it much easier to do accurate auto translates from EN Wiki. ϢereSpielChequers 16:59, 8 December 2020 (UTC)
  • Take a look at List of dialects of English - having different versions for each of these would be a bit much. Dialect-wise there is a lot more to change between dialects than just spelling of certain words to be "native" to the dialect - even major grammar differences such as the dropping of adjectives in Nigerian English. Using inline templates for each word/phrase set along the line @WereSpielChequers: mentioned above may result in a big problem for editors - if you want to change one sentence, what do you do with the variants? (e.g. create an article fork, abandon them all until a dialect translator comes along, ?) — xaosflux Talk 17:30, 8 December 2020 (UTC)
This may be a silly suggestion, but could machine learning assist with this? Presumably with enough sophistication such a system could ensure articles were correct, taking into account contextual and other factors. Maybe it's not doable now, but in future? I don't really know honestly, I'm just throwing this idea at the wall and seeing if it bursts into flames and burns my house down :( DesertPipeline (talk) 21:18, 8 December 2020 (UTC)
  • What a colossal waste of time and effort this would be. We should be encouraging readers "of" different ENGVARs to become comfortable with other ENGVARS, not be fostering balkanization. EEng 01:51, 13 December 2020 (UTC)
Fully agree, otherwise following the well-known Balkanization formula, in addition to us.wiki and uk.wiki, we will soon have ca.wiki, au.wiki, nz.wiki, and so on, ad infinitum Thhhommmasss (talk) 02:06, 13 December 2020 (UTC)
I endorse EEng's analysis. In addition, this is a very complex solution in search of a non-existent problem. There is widespread consensus among experienced editors from all English-speaking countries about how ENGVAR issues should be handled. Of course, it is not uncommon for a new editor to do something like changing the spelling to "colour" in an article about an American painter, but these minor issues are resolved through routine editing. There are no intractable ENGVAR wars. Cullen328 Let's discuss it 02:33, 13 December 2020 (UTC)
In the case of separate us.wiki and en.wiki, you could have articles which are 99,5% the same, or whatever the average, very high commonality is between them. So in some articles the only difference might indeed be “color” vs. “colour”, in some articles perhaps not even that. Thus it sounds like a tremendous waste of editor and Admin efforts to maintain 2 near duplicates. In the case of multiple, near-identical-language Balkan wikis, this has enabled POV-pushing on controversial issues. In case of US and UK such big differences don’t exist today, but had WP existed in late-18th to early-19th century, when 2 countries fought 2 wars, then US plus UK wiki versions could have been used to present 2 very different views of these wars, in my view, not a good thing Thhhommmasss (talk) 03:51, 13 December 2020 (UTC)

Way to readily see how reliable or controversial a page might be

Off-topic and OP is indeffed O3000 (talk) 02:43, 14 December 2020 (UTC)
The following discussion has been closed. Please do not modify it.

I have spent a great deal of time recently using a Talk: page to make the case for a basic one word revision and some simple changes to a controversial article. In summary, the page is almost impossible for me to change.

In general, before I place trust in an article or try to edit it I would find it useful to see the revision statistics. In particular, editorial conflicts at a glance. This would be a good way for a me, or a general user, to evaluate a page's stability, and reliability.Are.u.sure (talk) 18:13, 12 December 2020 (UTC)

The "watchlist" already has the capability to flag "probably bad edits." Would having something like that in the history be valuable? This wouldn't flag conflicts of interest per se but it does flag some spam/promotional material. davidwr/(talk)/(contribs) 🎄 18:43, 12 December 2020 (UTC)
  • The OP is currently temporarily p-blocked for repeated disruption, lack of competence with respect to Wikipedia's standards, and RGW in trying to make a change against consensus based on misunderstandings of Wikipedia guidelines. The editor can't make the change because there is no consensus, not because the article is unreliable. The solution is for the editor to study Wikipedia policies and guidelines, not look for a magic indicator indicating that an article has a problem when it is the editor who has the problem. O3000 (talk) 19:10, 12 December 2020 (UTC)

If there is 'no consensus' then indicate that instead please.Are.u.sure (talk) 20:07, 12 December 2020 (UTC) Else allow another version to be crafted and published to contrast with.Are.u.sure (talk) 20:09, 12 December 2020 (UTC)

There is no consensus for your change. There is consensus for the current text. You have been provided the links to previous discussions, and the discussion you were in also was against your change. Frankly, you really should avoid discussing this at all during your block. You may be indef blocked. O3000 (talk) 20:57, 12 December 2020 (UTC)
  • I've emailed these comments to
lawofficer.com

They've replied

'Pretty dumb. There isn’t consensus on anything these days.'

I'm sure you appreciate that when the 'consensus' was agreed they weren't party to the decision.Are.u.sure (talk) 21:02, 12 December 2020 (UTC)

There is absolutely no way that they should be a part of this. I will stop discussion now as you are in danger of a permanent block. O3000 (talk) 21:08, 12 December 2020 (UTC)
Are.u.sure, that sounds like a legal threat to me. Per WP:NOLEGALTHREATS, please explain immediately. —valereee (talk) 21:49, 12 December 2020 (UTC)
Lawofficer.com is a police advocacy group that he wishes to use as a source. Not a legal threat; but a CIR problem. O3000 (talk) 22:24, 12 December 2020 (UTC)
  • To summarise
  • My attempt to change Killing of George Floyd to Death of George Floyd was reverted immediately.
  • I was advised to agree changes on the Talk: Killing of George Floyd page
  • In the Talk: page I commented that lawofficer.com were confident that there would be acquittals because George Floyd had a lethal dose of Fentanyl in his body
  • I was told that lawofficer.com were somehow unacceptable
  • From that point I used the autopsy as my source
  • I was repeatedly browbeaten that the autopsy was, somehow a primary source
  • I used Talk: Killing of George Floyd to explain my reading of the autopsy of the Press Release Report
  • In the end that Talk: got very long and I was closed
  • I opened a new Talk:
  • I was asked to state what I wanted
  • I gave a statement and an undertaking to wait until Saturday 19th for an outcome
  • Not seeing any significant discussion in the Talk: page nor change in the article I messaged the users individually.
  • One user was abusive and I responded
  • Another user advised me to make a suggestion at the Village Pump - here I am.

Are.u.sure (talk) 22:53, 12 December 2020 (UTC)

The Village Pump is not a place to continue litigating your case. Continued efforts to do so may get you blocked. -- Valjean (talk) 22:58, 12 December 2020 (UTC)
He was told to make a suggestion he had about version control on the village pump. Instead he continued the arguments that failed on article talk page. Don't give him any other suggested places to go. He will simply continue the abuse there. --Guy Macon (talk) 01:14, 13 December 2020 (UTC)
I wrote:
  • In general, before I place trust in an article or try to edit it I would find it useful to see the revision statistics. In particular, editorial conflicts at a glance. This would be a good way for a me, or a general user, to evaluate a page's stability, and reliability.Are.u.sure (talk) 18:13, 12 December 2020 (UTC)

Are.u.sure (talk) 01:36, 13 December 2020 (UTC)

Colorize the black & white photos and replace existing photos with colorized copy of it

With the recent advancement of the automated tools that will allow editors to colorize the photos in just a minute, I am thinking of an idea where to colorize the historic photos that are not in color and replace the original black and white photo in article with the colorized copy of the photo inside the Wikipedia article, but not sure if it's a good idea to do or not.

FYI due to copyright restrictions, only colorize the photo that are published in public domain, Creative Commons CC-BY-2.0, CC‑BY‑SA‑2.0 or Flickr "No known copyright restrictions" WPSamson (talk) 01:50, 3 December 2020 (UTC)

WPSamson, My inclination would be not. The idea of images in articles is to add useful information. Colorization generally makes a photo prettier, but doesn't really add any information.
It's certainly possible that adding color makes it easier to understand the photo and/or identify details, and if that's the case, I don't see why it shouldn't be allowed. I post-process my photos using tools like crop, exposure adjustment, sharpening, white balance, perspective correction, horizon rotation correction, etc. Maybe colorizing is just another tool which, if used with care, is a useful addition to the toolset. But I wouldn't just do a blanket "Colorize all the things" to every B&W photo we've got. -- RoySmith (talk) 02:05, 3 December 2020 (UTC)
Some photos have been colorized but the process generally involves original research (bad) in that an editor gets to make up colors which the article then implies are known to be valid. Johnuniq (talk) 02:47, 3 December 2020 (UTC)
Johnuniq, Ah, I didn't realize the process involved the user making color decisions, I assumed it was some sort of A/I which figured it out. Yeah, that would be WP:OR and/or WP:SYNTH. -- RoySmith (talk) 03:12, 3 December 2020 (UTC)
  • I think this proposal would be unlikely to garner support due to the WP:OR issues. {{u|Sdkb}} talk 06:52, 3 December 2020 (UTC)
  • I remember this being discussed years ago, and the conclusion back then if I remember correctly was.. no (for similar reasons as discussed above), BUT ok when showing both versions in the article side to side. —TheDJ (talk • contribs) 09:15, 3 December 2020 (UTC)
  • Absolutely Not. However advanced the technology and however well crafted the result might be, we should not be creating fake images — GhostInTheMachine talk to me 11:16, 3 December 2020 (UTC)
  • Color restoration is a different matter. If there is a public-domain or freely-licensed accurate color reference to work from, it's plausible that a "color restoration" can be done without "original research," but this will need to be handled on a case-by-case basis, preferably outside of Wikipedia. The best case scenario would be for the person who does the color restoration to explicitly disclaim any copyright interest in the "restored work" just to avoid having the "legal what-iffers" start a never-ending copyright discussion about it. That way, if the underlying images were already freely-licensed or in the public domain, his restoration could would be eligible for upload to the Commons.
The same applies if the black and white image contains "information" about the original colors, as was the case for at least one episode of Doctor Who, which was broadcast in color, converted to black-and-white using a process that unintentionally preserved color information, "lost," "found" in the black-and-white version, then restored to the color version. Granted, this is not in the public domain, but my claim holds: A color restoration, which adds no creative content, should be treated the same as a "mechanical copy" for copyright purposes until the law or a court clearly says otherwise. davidwr/(talk)/(contribs) 16:27, 3 December 2020 (UTC)
  • c:Commons:Colorization. In scope for Commons, can be useful for popular science/history video presentations and magazines where historical accuracy is less important than providing a more attractive picture that grabs the attention of the public (which Commons caters to as it's educational), but (unless an accurate color reference was used) not for Wikipedia. — Alexis Jazz (talk or ping me) 23:37, 3 December 2020 (UTC)
Why do you assume black and white photos are less attractive?--Khajidha (talk) 14:36, 7 December 2020 (UTC)
The Arecibo message is not a photo, it can be thought of as a political map. In a map it doesn't matter which country has which color, the important part are the frontiers. In the Arecibo message the important parts are the "squares" and their color doesn't really matter. As I understand it this thread is about photography colourisation as in Film colorization not vector graphics or other images. josecurioso ❯❯❯ Tell me! 15:26, 5 December 2020 (UTC)
I'd agree with this - that image is very different from a negative which is then colourised, as that has been colourised in order to highlight the different components of a binary message. It's more of a diagram. SportingFlyer T·C 15:06, 7 December 2020 (UTC)
I just want to say I think colorization of historical images is not in line with being an encyclopedia. When people come to Wikipedia and read a quote in an article, they expect that the quote was accurately copied from the cited source. Similarly, when people see a historical image, they expect that what they are seeing hasn't been significantly altered by Wikipedia. Colorization would be the visual equivalent of intentionally misquoting a historical source in order to make their phrasing sound more modern: a well intentioned change, but not one which is appropriate for an encyclopedia. 李艾连 (talk) 04:13, 21 December 2020 (UTC)

High-importance articles are rife with possibly unofficial non-free depictions

As an example, the image on Pluto (Disney) was File:Plutodog.gif that is sourced to "The Walt Disney Company". That's it! No URL, no comic book or movie title, nothing at all! For reference (as this image will disappear in a week or so), it is the same as w:sco:File:Plutodog.gif, [5] and [6]. For the same reason we are discussing the lead image for Donald Duck. And there is more. 625 non-free images from Fandom alone. I see too many such images that are either unsourced or sourced to Fandom and the like. Perhaps an edit filter or bot or something could be considered to at least tag these if not outright block uploading them. — Alexis Jazz (talk or ping me) 10:30, 6 December 2020 (UTC)

We definitely should not be pulling images from Fandom even though we know the sourced image originally came from Disney, especially when there are clear alterations beyond resizing done (such as the transparency here) that could possibly make it a work from a non-Disney fan artist. --Masem (t) 15:20, 8 December 2020 (UTC)
@Masem: Any idea how this could be moved forward? I think an edit filter would be rather helpful here. I was hoping for input from more users. — Alexis Jazz (talk or ping me) 12:03, 22 December 2020 (UTC)
Image clutter in articles is a huge problem ... which WMF is looking to make even worse. SandyGeorgia (Talk) 12:10, 22 December 2020 (UTC)

Should the scope of G6 be limited?

According to WP:CSD, G6 is for articles that have to be deleted for "uncontroversial maintenance," but I have seen in various instances G6 being used as a sort of catch-all. I have seen it used to delete pages that would better fit deletion by G3 (such as Wikipedia:Articles for deletion/Sun (2nd nomination)), R3 (Neelix's redirects; technically deleted per X1 an extension of G6), used because a "joke is getting stale" (see Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion/Wikipedia:Articles for deletion) and used as an IAR extension. I'd like to ask for your opinions on limiting the scope of G6 in order to make it more accurate to its name: "technical deletions," by restricting it to articles that have to actually be deleted for maintenance reasons. JJP...MASTER![talk to] JJP... master? 15:33, 13 December 2020 (UTC)

Are there any pages that are being deleted that shouldn't have been? If not, I'm not sure I see the point of this proposal. While in an ideal world we'd always get the summary right on speedy deletions, because they're uneditable once made (other than blanking them as a last resort) and because speedy deletion means selecting reasons from a fiddly drop-down menu where even the most experienced admin sometimes clicks the wrong item, the occasional speedy deletion with an incorrect code in the log is just a fact of Wikipedia life; it makes no actual difference whether a piece of obvious disruption like Wikipedia:Articles for deletion/Sun (2nd nomination) shows G3, G2 or G6 in the log. ‑ Iridescent 15:51, 13 December 2020 (UTC)
by restricting it to articles that have to actually be deleted for maintenance reasons how do you propose doing this? Restricting to articles is bad, I’ve made many G6 tags for other pages, indeed most of my G6 tagging is in other namespaces. But assuming you meant page, not article, isn’t this just a technical rewording? G6 has a large scope, it is not really possible to make any tangible change in the way you suggest, at least not that I can think of. ProcrastinatingReader (talk) 16:31, 13 December 2020 (UTC)
If you are requesting that G6 be split into two new criteria, one for uncontroversial technical deletions and one for uncontroversial deletions not covered by another criteria, that might be fair to discuss. But as long as admins put the actual reason in the deletion log, I'm not seeing a problem here. On the other hand, if you are saying that some deletions now done under G6 shouldn't be done under any speedy-deletion category, this will require a longer discussion. On the third hand, if you are saying that sometimes administrators "push the G6 button" when the meant to push a different one, well, admins are only human, or at least a human is responsible for their actions if they are bots. davidwr/(talk)/(contribs) 🎄 18:58, 13 December 2020 (UTC)
Exactly. Since the two examples you give were unquestionably correct deletions (no sane person is going to claim that The Sun magically exploded into a planetary nebula 29.5 days ago. Even if it did not explode, it would not be notable per WP:NSTAR and WP:NOTSTARGUIDE. Maybe a redirect to Star or Supernova is the only solution is something we somehow need to keep), it doesn't really matter what the entry in the deletion log says provided it's not actively misleading; it's not like we have quotas of each deletion criterion to meet and mislabelling two deletions as G6 is preventing G3 from reaching its target. If you're claiming there's an issue, you really need to provide examples of pages being deleted under G6 that didn't qualify for speedy deletion. ‑ Iridescent 19:10, 13 December 2020 (UTC)
  • I comment on this perennial proposal every time it’s raised, but no, it shouldn’t be split. My personal favorite use of G6 is to delete SPIs like Wikipedia:Sockpuppet investigations/175.116.243.212 (an SPI listing a bunch of dynamic IP addresses), and anyone who is active in the more behind the scenes areas likely has encountered something similar in the area where they work where there is no reason to send something to MfD and deletion would be appropriate.
    Also, as an aside about one of the examples, deleting unfunny April Fools AfDs under G6 has become a tradition just as much as the day itself... TonyBallioni (talk) 06:38, 14 December 2020 (UTC)
  • I echo some of the "so what?" mentality noted above. There's some overlap among CSD rationales, which is a feature, not a bug, of the system. The OP has failed to show how G6 is being used to delete pages that should otherwise have never been deleted, which means there is no problem to solve as far as I can tell. If it could have been deleted under another rationale, but G6 was cited instead, who cares? --Jayron32 12:45, 22 December 2020 (UTC)

Merging WP:Move review and WP:Deletion review

Before I consider an RFC on the idea of merging WP:Move review and WP:Deletion review I'd like to get some input on the idea. In my opinion, Move review just doesn't work. Discussions there stay open for months -- see Wikipedia:Move_review#Coronavirus_disease_2019_(closed) which was opened Oct. 1 and closed Dec. 9 for one example -- meaning that the previous requested move becomes stale in the process. Participation at move review is also very limited. By my estimation, at least half of all participants in a typical move review also were involved in the previous request move and just rehash the same arguments again; for an extreme example, see Wikipedia:Move_review#Telephone_(game), which has been open more than a month and attracted a single uninvolved participant. To me, both those issues could be solved by merging move review to a page that gets more attention. WP:Deletion review seems obvious but there might be other suggestions as well. I'd like to hear what others think about the idea before going further. -- Calidum 21:24, 21 December 2020 (UTC)

  • There certainly is some overlap (a retargeted redirect may end up an either review) and lack of participation issues but move and deletion review but I'm not sure if merging would be sensible (though I wouldn't really object) since more often than not DR and MR are different issues (deletion/merging involve inclusion policies while titling/primacy is very different) that said maybe it should be a discussion review in general? What about other discussions such as RFCs? Maybe discussions involving splitting/merging pages belong at DR though there is no guidance on that. Crouch, Swale (talk) 21:39, 21 December 2020 (UTC)
  • Oppose. WP:DRV is concerned with the proper application of deletion policy, and as such plays a role as the highest court for content. WP:MRV is not close to that importance, and a merge would damage the standing and function of DRV. The low attendance at MRV could be read as a reflection of the unimportance of WP:RM, and if low attendance there is a problem, the answer is Wikipedia:Publicising discussions. If anything, WP:MRV could subsume the Close Review function of WP:AN. —SmokeyJoe (talk) 01:42, 22 December 2020 (UTC)
  • Participation is one aspect, but DRV and MR involve application of, and thus expertise in, two different sets of policies that really don't overlap much (except WP:CONSENSUS and WP:CCPOLs I suppose?). So participants in one won't necessarily be interested in or helpful in the other. That said, I could see an arrangement where there is a "close review" page (pulling that function out of AN), and DRV and MR are sub-pages of that page. But that seems like re-arranging deck chairs to me; I'm not sure if it's more than a cosmetic change. Separate and apart from that, I am totally in favor of outright banning participants in RMs/AFDs from participating in resultant MRs/DRVs, to reduce the re-hash. Levivich harass/hound 08:00, 22 December 2020 (UTC)
  • Oppose Think it's a really bad idea that we should not really develop into anything further for reasons I will elucidate shortly, but I definitely and in no way am voting Oppose because I was told we don't do that here Article titling concerns and article existence concerns are mostly orthogonal. Fail to see the need for this or the problem it hopes to solve, other than "low participation". --Jayron32 12:42, 22 December 2020 (UTC) slight edit per comment below --Jayron32 20:09, 22 December 2020 (UTC)
    • I just felt I had to compliment you for sneaking orthogonal into a message Nosebagbear (talk)
  • Firstly, guys, this is the IDEAS section, and we're specifically asked not to go in with the oppose/support thing. I do think the responsibilities are distinct enough that I would not like DRV (covering a field I am very experienced in) being cluttered with Move Review issues. I imagine the few who are very active in MR might share that issue. I am perhaps less worried by the "deck chair" bit on bringing them under a central umbrella - that isn't me saying it's a good idea, but I think it's a possibility warranting additional discussion Nosebagbear (talk) 17:10, 22 December 2020 (UTC)
    Sorry. I have amended my comment so it is no longer in contravention of the rules of this board. Mea culpa. --Jayron32 20:09, 22 December 2020 (UTC)
  • Popping move issues into DRV may garner more participation, but not necessarily more valid participation. Many DRV regulars are not familiar with RM-related policy, so it may not lead to good outcomes. DRV is pretty much only capable at handling article deletion reviews. Even when straying outside that into other namespaces DRV's weaknesses start to shine (eg DRV regulars aren't really well placed to address module deletion issues), so adding in move discussions is a bit of a stretch imo. ProcrastinatingReader (talk) 20:15, 22 December 2020 (UTC)

Idea for a new protection level

I think that Extended Confirmed protection is too over-powered. All it takes is some random saps to vandalize a Semi-protected page to get it extended confirmed, which stunts growth, and only lets very active and experienced editors to edit, which limits the number of editors. I'm thinking of a new protection level, in between of Semi-protection and Extended confirmed. Is this needed, and what should be the criteria? Arsonxists (talk) 17:46, 15 December 2020 (UTC)

In most cases like this, pending changes coupled with semi-protection is probably easier to do that creating a whole new protection level. However, the rules surrounding pending-changes protection may need to be looked at to see if they meet the needs. Pending Changes Protection is one of those things you don't really want to use "out of process" (i.e. by invoking WP:Ignore all rules) if you can help it. While this "don't invoke WP:IAR unless you absolutely have to (but DO use it when it's called for)" applies to all policies, the past history of pending changes makes it even more of a minefield in that area. davidwr/(talk)/(contribs) 🎄 19:18, 15 December 2020 (UTC)
I agree with you on the pending changes. About the new protection level, it's not about taking one single page, and creating a new protection level for it, and just FOR it, is not what I am saying. I was making this so, with an Extended Confirmed padlock on it, for a page which could use a lower level lock which doesn't exist yet, but semi-protection is too low, the new protection level could fix the problem. I think alot of pages have that problem. Arsonxists (talk) 20:48, 15 December 2020 (UTC)
Arsonxists, I don't see how adding another level between semi and ECP is going to be useful. The problem is, once you get too many fine gradations, it's dang near impossible to figure out which is the right one, so application becomes essentially random, and we're already there. Between semi, pending, ECP, and full, there's more than enough choices. -- RoySmith (talk) 14:45, 16 December 2020 (UTC)
From my understanding it sounds like y'all are suggesting something like Pending Changes Level 2 (aka orange lock) which takes the current Pending Changes (formally known as Level 1) but kicks it up a notch to become a protection level between Semi-protection and Extended-confirmed protection. Essentially PC Level 2 flagged every edit on a page as needing reviewed. Only Reviewers & Administrators could have their edits go live without review after reviewing previous edits on a page. PC Level 2 could be used in conjunction with Semi-protection & Extended-confirmed protection. So in the levels of protection (in theory) it would have been PC Level 1, Semi-protection, PC Level 2, PC Level 2 + Semi-protection, Extended-confirmed protection, PC Level 2 + ECP, Template protection, Full protection if everything was adopted. This is how it appears in chart form. Again in theory, if PC Level 2 + ECP was applied then the Reviewer would also need to be Extended-confirmed to reject a pending change (since that would technically be a revert of the page.) Since Level 2 never reached a consensus on how to use it, in any configuration, the setting was removed at the software level so it wouldn't show up as an option to administrators. While some may argue a need for another level of protection I highly doubt a consensus could be reached today about using Level 2 of Pending Changes Protection since a lot of people at the time didn't feel we needed a protection level between Semi-protection and ECP. Alucard 16❯❯❯ chat? 09:51, 17 December 2020 (UTC)
If I may flip the question around, why not just lower the threshold for Extended Confirmed user rights?. If 30/500-in-any-space were taken down to say, 24/240-in-mainspace then high quality editors would be able to prove themselves pretty quickly and edit semi-protected pages without restrictions getting any more granular. Would that let through too many people too quickly? If so then I'd object to a protection level for that reason. If not then I'd opt for lowering the EC threshold as a simpler solution. --Paul ❬talk❭ 15:07, 30 December 2020 (UTC)
  • I think this entire argument is predicated on a false assumption; the OP has claimed All it takes is some random saps to vandalize a Semi-protected page to get it extended confirmed, which stunts growth, and I can see absolutely no evidence for this. Here's every page currently under ECP; the overwhelming majority are articles on Israel/Palestine, the India-Pakistan conflict, and antisemitism & Poland (on all of which the ECP is mandated by Arbcom and consequently it would take an arb case to get them lifted). Of the handful of those which don't fall into one of the arbcom-mandated topics, I'm not seeing a single one that doesn't fall into "highly contententious topic which people shouldn't be editing until they're very familiar with Wikipedia's rules" or "under sustained attack from multiple SPAs over the long term". Can any of the people calling for a lower protection level or a reduction in the ECP requirements give any actual examples of a page under ECP where you don't consider the ECP appropriate? (In my opinion, if anything we should be raising the threshold. 500 edits is trivially easy; just ctrl-f any common typo and you can rack up that many edits in half an hour.) ‑ Iridescent 16:28, 30 December 2020 (UTC)
I wasn't being particularly serious with suggestion of changing the threshold - just saying that it'd make more sense than an additional protection level. --Paul ❬talk❭ 18:24, 30 December 2020 (UTC)

"Suggest edit" button

It'll let you highlight/select some article text, type in what's wrong, add a source (via URl or whatever), and put an edit request on the talk page (so that semis, edit filters, spam url list, etc all work). Surely not an original idea. Proposed location: on Vector, in the tab row, between "Read" and "Edit", maybe with a tiny icon to get people to click on it; on Minerva, another icon next to the watchlist star (maybe a lightbulb?). Method of deployment: very slowly, using the blunt instrument of MediaWiki:Common.js, with only a few high-pageview articles at first (get consensus from most recent/top page editors?). Thoughts welcome. Enterprisey (talk!) 06:48, 21 December 2020 (UTC)

Probably should avoid doing something like this in Javascript... --Izno (talk) 08:08, 21 December 2020 (UTC)
It's a prototype, and will probably need to change a lot. Of course, we could go with the more usual workflow of having an actual "experiment" and doing A/B testing and other science in PHP over a multi-month period; indeed, if there's a PHP developer available who would like to step up and shepherd all that through, it would be a superior solution. I don't think any are available but would be happy to be proven wrong. Enterprisey (talk!) 08:15, 21 December 2020 (UTC)
I have a feeling this would turn into a turbo-charged variation on the Article Feedback Tool fiasco, which would end up flooding talkpages with hundreds of variations on "I love/hate topic" and "you should include obvious libel". The relatively low barrier to entry of the existing MediaWiki:Protectedpagetext screen has a dual purpose; as well as the obvious one of telling the person who wants to propose an edit what they need to do to propose it, it also encourages readers in this position to create accounts and points them towards assorted help pages that will (hopefully) help them figure out whether their suggestion is actually going to be one worth making. If you look at the talkpage of high-pageview articles like Talk:COVID-19 pandemic or Talk:Taylor Swift they already get hammered with good-faith cluelessness; if we end up creating a situation where we need to semiprotect the talk pages to stop them being flooded, the whole exercise would have been counterproductive.
What I would support without reservation is a change to the tabs such that in circumstances where the "view source" tab is displayed (semi'd pages to anons, full-protect pages to logged-ins) a second link to the talk page is displayed next to "view source", and preferably labeled something unambiguous like "discuss this page". The way Vector shows the tabs by default to IPs and new accounts (with "article" and "talk" on their own next to the death star, and everything else next to the search box) is quite unintuitive. I'm fairly certain most readers who look for the edit tab and can't see it because the page is protected aren't even aware that the talk page exists let alone know how to get to it, and that those who do notice the "talk" link are under the impression that it leads to their own talkpage and consequently never bother to click on it since they know that as an unregistered user they're not going to have any messages. (Minerva is such a mess that I'm fairly certain most readers aren't aware that any of the tabs exist.) ‑ Iridescent 08:39, 21 December 2020 (UTC)
Yeah, that'll probably happen with a free-form input field. Clearly I ought to review the Article Feedback data. That's my first talk page entry! What about a more limited set of options, like radio buttons saying "this fact is wrong and should be ___" or "this is irrelevant", perhaps not even with text fields? Or we could have no "what's wrong" section at all, and just an option to contribute one or more relevant sources in URL/ISBN/DOI/whatever form (which will of course be restricted client-side to avoid the usual suspects like Facebook/YouTube). The tabs change sounds like a good idea to me as well. I suppose it's too late to rename it to "discuss this article". Enterprisey (talk!) 08:57, 21 December 2020 (UTC)
AFT was limited options prior to its free form. Really, go look at AFT. --Izno (talk) 09:03, 21 December 2020 (UTC)
I had a look; seems different enough. Enterprisey (talk!) 09:17, 21 December 2020 (UTC)
AFT had multiple iterations; as our page name indicates today, it was version 5 that was finally put to rest. We had 2 or 3 iterations of forms-based options before that. --Izno (talk) 09:24, 21 December 2020 (UTC)
I had looked at all of them; I suppose I worded my comment imprecisely. I based my judgment off mw:Article feedback#Project history, which I think shows all of the versions. Enterprisey (talk!) 09:45, 21 December 2020 (UTC)
Because the WMF intentionally broke the links to the archives to make it hard to access them it's hard to put across just how much of a mess AFT was, but the very fact that they had to do this is an indicator. Even the earlier, form-based versions saw us flooded with variations on "Key fact missing from the article: he murders children and the international Jewish conspiracy covers it up". (If you're interested, the AFT archive is hidden here; to give a sense of scale, the limited experimental rollout of AFT generated 1.5 million comments.) It painted us into a corner where we had to choose which of "hosting libel indefinitely", "team of full-time paid moderators" or "literally delete the database" was the least antithetical to our values. ‑ Iridescent 09:52, 21 December 2020 (UTC)
OK, so no free-form text fields. Enterprisey (talk!) 09:56, 21 December 2020 (UTC)
Iridescent, that's an interesting point about the arrangement of the tabs. Redesigning that at a very fundamental level seems like something that should eventually happen, although I'm sure it'd get pushback since design change always gets pushback. The potential confusion about the fact that "Talk" is page-based rather than user-based is also very interesting—that's very big if true, and I'd be curious to see if anyone has looked into that.
Regarding the point about the potential pitfall of this feature, I'm inclined to agree. It could also end up discouraging more timid new editors from being bold and create massive backlogs. {{u|Sdkb}} talk 13:58, 23 December 2020 (UTC)
In my view there's a big jump from "this needs changing" to "I'll dig in and edit this". If we add a middle ground of "I'll suggest an edit", I think it's closer to the former than the latter (in terms of effort required/"activation energy"). That is, I agree this'll encourage some people to suggest edits instead of making them, but I think it'll be more than offset by others suggesting edits who wouldn't otherwise contribute at all. Enterprisey (talk!) 10:07, 24 December 2020 (UTC)
@Enterprisey: already not loving the idea of running anything heavy via common.js - perhaps something super tiny that adds a button/tab only - and that button/tab loads a withJS on-demand that we already have support for? But for something this big, it seems like you are really only going to be hitting desktop editors when I'd think a simplified workflow might be better used for mobile editors if you want to start putting in the effort. — xaosflux Talk 16:08, 23 December 2020 (UTC)
Yup, a button that loads a script was the idea. I agree designing for mobile editors is essential. I figure the highlighting part should transfer fine to mobile, but I really think we should collect something beyond that - not just a choice among "this is inaccurate/unreferenced/irrelevant" - to make the responding editor's job easier. I think requiring a source would work for that, although I guess research is a big pain on mobile. Enterprisey (talk!) 10:01, 24 December 2020 (UTC)


Proposal to change the username policy's section on impersonation

Alright, so I found out that the user by the name Billie Eilish - Baby Shark was indefinitely blocked due to a username violation, however I do not believe that that was justified. Not that the block itself was unjustified, but that the reason was unjustified. I believe that it is clear that this user's username implies that it means "Baby Shark by Billie Eilish", as opposed to an attempt to impersonate Billie Eilish, and their user page attested to that fact, but they were still blocked due to the fact that their username merely contained the name of a famous person. I would like to ask for your thoughts on if this username block was justified, and if the policy should be changed to more explicitly prohibit blatant attempts to impersonate a person. Please note that I am not requesting an unblock for the user, but I am requesting a change in the policy, in order to make it more accurate to its intention: to prevent impersonation. JJP...MASTER![talk to] JJP... master? 02:16, 25 December 2020 (UTC)

Looks like a good block to me. We couldn't change this aspect of the username policy even if we wanted to, since it's a legal issue and as such comes from the WMF rather than the community. The purpose of that section of the username policy isn't to prevent "blatant attempts", it's to prevent potential confusion; even if the username is entirely in good faith we still block. Even if this person's name genuinely was "Billie Eilish" we would still block unless there was something to make it clear they're unrelated, and that's how it should be. ‑ Iridescent 17:39, 25 December 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_33&oldid=1110548169"