Jump to content

Wikipedia:Village pump (proposals)/Archive 160

Add links
From Wikipedia, the free encyclopedia
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). 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: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 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, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

RfC: Ending the system of portals take 2

There is a clear consensus against the proposal to end the system of portals.

Cunard (talk) 01:18, 22 September 2019 (UTC)

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

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

Rationale discussion

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

Regarding "with just a few votes" - When I look at any xFD if the nom makes a good case and all the !votes are to delete (even if there are only one or two of them) then I don't usually bother to !vote. Many other editors may do similar. DexDor (talk) 05:25, 19 June 2019 (UTC)
The vast majority of editors do not go to, or even know about, xFD, so removing things via that route probably doesn't give an accurate picture of true feelings of the community. Randy Kryn (talk) 13:19, 19 June 2019 (UTC)
The vast majority of editors do not go to, or even know about, any type of Wikipedia discussion. ―Mandruss ☎ 14:41, 19 June 2019 (UTC)
Those at the isolated deletion board don't care about the last Rfc and they have littld interest in updating any or even giving the community a chance to fix them. If there is any desire to retain portals we will need content editors to step up and update the portals. As of now portals are being deleted bases on views or the fact a topic like the military of the United States is considered not a broad topic. If no one is will to help there is no point in having them...as they will all be gone soon anyways. I voted last time to end portals...but now find myself trying to explain that back door deletion is not what the community intent was in the last Rfc. I still think they should be deleted overall...but am not a fan of the non policy bases they are being bandwagon deleted.--Moxy 🍁 19:09, 19 June 2019 (UTC)\
Well, I have occasionally looked at some portals since the last RfC and they looked fine. It's rather a mystery why some people would want to trash every portal that might interest others and the last RfC suggests rational people do not. It's fine to trim, but 900 is just not that many pages and neither is 4000. Alanscottwalker (talk) 19:51, 19 June 2019 (UTC)
  • I think this proposal is too rash and misses a lot of points that would help build consensus. Given the lack of consensus in the previous RfC, the next step is not to propose all or even most portals be deleted. The recent mass portal deletions were in response to what was as much a conduct dispute as a content dispute. The XfD discussions were largely because a proposal for a new speedy deletion criterion applying to all portals created by a single user failed to gain consensus. Pointing to those to say that there is consensus to delete all portals is not a good example. The AN discussion has over 10 proposals on how to handle portals, some of which, like proposals 7 and 13, seem like they might actually find consensus.
If anything, the problems pointed out regarding the upgrades to portal maintenance can at best show that we should not create any more portals as they are likely to wind up unmaintained and just as complex as before. I think a proposal to mark WP:PORTAL historical but maintain what we have for the time being is far more likely to gain consensus than deleting portals en masse. Lots of people believe there are portals which still have value and are actively maintained and so blanket deletion is not going to find consensus because of that.
I fear that this discussion is only going to harm consensus building by making people more entrenched in their positions. It's unlikely to pass and those who support portals will be more likely to view further good faith attempts at consensus building as attempts to delete all portals. I suggest this be withdrawn or closed in favor of a more nuanced proposal. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 21:25, 26 June 2019 (UTC)
  • Procedural close this bad faith, disruptive RFC. This proposal is just a blatant act of bad faith by Moxy, who doesn't understand what was actually decided at the 2018 WP:ENDPORTALS RFC. That was a proposal to delete all portals, now, and it was rejected. That's all; it was not a decision to keep any individual portal, just a decision not to delete them all immediately.
However, Moxy has spent the last few weeks opposing deletion of long-abandoned portals, repeatedly making the false claim that ENDPORTALS decided to keep them all.
This pseudo-RFC is just a re-run of the false binary thinking, intended to demolish a straw man. It posits them single option of deleting them all, in the hope that when that's rejected Moxy can then use the outcome to oppose deletion even of abandoned crap.
The current situation is that good portals are being kept, but the abandoned junk is being deleted. Moxy's aim is simply to stop that cleanup, and there is no need for the community to waste its time indulging this game-playing. --BrownHairedGirl (talk) • (contribs) 20:38, 1 July 2019 (UTC)
Just have to read There exists a strong consensus against deleting or even deprecating portals at this time . Not sure that it could be more clear...so here we are again trying to get you to move in the right direction to no avail. Have you seen what is being said here??? You 2 have been asked many many times to give the community time to fix the portals you guys dont like......simply not possible to fix hundreds of portals at a time. --Moxy 🍁 20:46, 1 July 2019 (UTC)
Moxy, it was a decision to not delete all portals now.
It was not a decision to never delete any portal ever.
It's a great pity that Moxy's deep deficiency in logic and of reading comprehension does not debar him wasting the community's time with this WP:POINTy RFC. --BrownHairedGirl (talk) • (contribs) 21:00, 1 July 2019 (UTC)
Your simply not doing right by our editors and this should be clear by all the feed back your getting . Cant believe you dont understand why editors are upset with you 2 ...your deleting portals based on view and what you guys think is not a big topics....zero effort at fixing portals that are clearly valid like Wikipedia:Miscellany for deletion/Portal:Military of the United States that has 1,197 featured and 3,088 good articles to use. Now you 2 are deleting portals based on no attribution...thats every portal we have a ... So were does your deletion end and the fixup work begin?? 3000+ portals deleted is definitely not what the RfC is looking for.--Moxy 🍁 21:12, 1 July 2019 (UTC)
Your Moxy, the feedback I am getting is very clear that most editors have no objection to the deletion of portals which fail the portal guidelines, while keeping those which do meet the guidelines. It's a great pity that you continue to refuse to actually read the guidelines. If you did read and comprehend them, you might understand why Wikipedia:Miscellany for deletion/Portal:Military of the United States was closed as delete.
However, there has always been a small trickle of editors like yourself who object to the deletion of even portals which have been abandoned for a decade ... and every now and then one of them tries to make a drama.
Fixup begins whenever you or anyone else wants to start fixing them. --BrownHairedGirl (talk) • (contribs) 00:00, 2 July 2019 (UTC)
...Erm, I have no leg in this discussion overall, but "deep deficiency in logic and of reading comprehension" (EDIT 16:58, 6 July 2019 (UTC): and other comments regarding them elsewhere in this discussion) reads as a clear, unambiguous personal attack to me, or at the very least, highly uncivil (I was considering saying as such on your talk page, but something in me said to bring it up here instead, even though part of me is worried that could escalate things), and I'm quite frankly appalled that it's coming from not just any random user but rather a sysop, of all people. It's gotta be possible (and, indeed, appears quite possible, from some of the other things you said) to argue against Moxy's position (or what you believe their reasoning for opening this RFC was) without stooping to the level of suggesting they can't comprehend the processes or previous outcomes related to this discussion. - Purplewowies (talk) 16:53, 6 July 2019 (UTC)

Voting discussion

  • Oppose: I think we should keep portals, because they're useful for organization, navigation, and bridging between reading and project space. Benjamin (talk) 06:36, 19 June 2019 (UTC)
  • WP:ENDPORTALS: Electric Boogaloo? Moxy, I would suggest pausing this a bit to work on the wording of the RfC, at least. The last RfC got muddled up with Wikipedia:Community_portal and Portal:Current_events (with the intention being that the current events portal would be moved to Wikipedia space), and with some opposition to full deletion (with preferrence a slower process than Nuking the whole space). So I would suggest some rephrasing of the RfC question or changes to the format to allow a consensus for a less dramatic step. Galobtter (pingó mió) 12:32, 19 June 2019 (UTC)
    Done I guess we should make it as clear as possible.--Moxy 🍁 19:30, 19 June 2019 (UTC)
  • Oppose, this was fully discussed in the last well-attended and novel-length RfC. Some editors have worked diligently on the collection since then. Randy Kryn (talk) 13:13, 19 June 2019 (UTC)
  • Not now per Galobtter. I think you're right that recent developments might have changed consensus. I agree with the spirit of the proposal, but per the last RFC, Community portal and Current Events are going to be stumbling blocks to consensus unless there's an explicit plan to deal with them from the beginning. I think you should withdraw this and consider a better compromise than deleting portals which I don't think will find consensus. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 14:41, 19 June 2019 (UTC)
    Note: Wikipedia:Community portal probably isn't relevant - it isn't in portal namespace, isn't a WP:Portal and was only mentioned once in the previous RFC. DexDor (talk) 18:15, 19 June 2019 (UTC)
    Have amended wording for those not familiar with topic portals.--Moxy 🍁 19:30, 19 June 2019 (UTC)
  • Oppose The major portals still appear on the main page and that's not a problem. People bickering about lesser portals is typical disruption per WP:LIGHTBULB. Tsk. Andrew D. (talk) 22:36, 19 June 2019 (UTC)
  • Oppose I have been appalled by the tone of the discussions at MFD but I simply haven't have the inclination to take part. All the same, I think portals should continue. Thincat (talk) 08:03, 20 June 2019 (UTC)
  • Strong Oppose - We already had a lengthy discussion on the matter that has its own subpage saying there is a "strong consensus" to retain the portals, no need to beat a WP:DEADHORSE. - Knowledgekid87 (talk) 16:02, 20 June 2019 (UTC)
  • Oppose That there was consensus to delete some portals does not imply consensus to delete all portals. Articles are deleted every day at AfD but this does not imply a consensus to delete the article space. Hawkeye7 (discuss) 19:46, 20 June 2019 (UTC)
    Going by the reasons for deletion that I see most days I think that there are some editors here who would like to make this place neat and tidy by deleting the whole of article space, so they would be able to argue about things without having that messy encyclopedia to worry about. Phil Bridger (talk) 20:38, 20 June 2019 (UTC)
    This just goes against WP:IMPERFECT (which is a policy), no amount of deletion cleanup will ever be enough to please everyone. Things that hinder editing I can understand, but to go after things just to go after them is wrong in my opinion. - Knowledgekid87 (talk) 15:16, 21 June 2019 (UTC)
  • Oppose I'm against deleting high level portals such a those on the main page and Portal:Contents, plus any others which don't duplicate article content such as Portal:Current events and Portal:Featured content. I would be happy to consider proposals to drastically reduce the number of portals but not get rid of them entirely. Hut 8.5 12:53, 22 June 2019 (UTC)
    My guess is this is the plan...deleted all but main portals..--Moxy 🍁 12:00, 24 June 2019 (UTC)
  • Strong support. I feel that portals are long obsolete and that their removal is inevitable and would benefit Wikipedia. Also, in response to those who note that we have had a discussion on it before, I remind you that that was over a year ago and that consensus can change. Having said all that, I get the feeling that consensus does not currently support the eradication of the namespace, so I will support the form of consensus that is closest to it (such as removing all but the main-page portals, etc.). EDIT: After thinking it over for a little bit I realize that I've been a bit overly harsh on portals. I still see no use for them personally, and would not oppose deleting all but the main-page and non-article-duplicating portals, but those who really want to maintain the portalspace should be able to do so provided that they don't spam with cruft and, most importantly, help the encyclopedia. – John M Wolfson (talk • contribs) 18:02, 26 June 2019 (UTC)
  • Strong oppose. Look, there are a lot of useless portals. If that makes the whole system useless to you, fine, ignore them. If you think it could be useful but it isn't because of the cruft, then decide whether it's worth your time to help clean it up. If it is, then do it. If it isn't, see sentence 2.
    The "resources" argument is fundamentally misbegotten. There is no common pool of resources that we draw on. There are volunteer contributors, who allocate their resources as suits them. --Trovatore (talk) 19:51, 26 June 2019 (UTC)
Would be nice but efforts to improve are just reverted....got just a few editors voting rrsulting in deletion of thousnads of portals.--Moxy 🍁 21:41, 26 June 2019 (UTC)
Moxy, if you genuinely believe that efforts to improve are just reverted, then please post evidence of this. I have seen no evidence of this raised at MFD or at WT:WPPORT ... so unless you can show actual evidence I will mark it down as simply more of Moxy's lies.
As to just a few editors voting rrsulting in deletion of thousnads of portals, that's a blatant lie (as in something which you stated it when you knew to be untrue). As Moxy well knows, the majority of the deleted portals were removed in two mass deletions of automated portals: one, and two). Those were widely-advertised discussions, and they were some of the most heavily-attended MFDs ever. Claiming that this is just a few editors voting is a simply a lie designed to deceive other editors. --BrownHairedGirl (talk) • (contribs) 21:10, 1 July 2019 (UTC)
More lies what are you talking about? Cant BS the facts girl...its clear portal after portal that was not automated is being deleted by just a few votes (as mentioned here by others). As for your revert I am simply not sure what to say]...editors cant do much when an admin is reverting fix attempts now can we. You sure your on the right side here...are you doing right by our editors?--Moxy 🍁 21:47, 1 July 2019 (UTC)
Moxy, either you are either a congenital liar or you have a very poor grasp of facts.
You claimed just a few editors voting rrsulting in deletion of thousnads of portals.
The facts are that:
  1. ~2500 automated portals were deleted by overwhelming consensus at the two mass MFDS.
  2. Another ~1900 automated portals were deleted per that consensus
  3. ~570 portals have subsequently been deleted at MFD, in discussions with varying numbers of participants.
So your claim that a few editors have deleted thousands of portals is a complete lie. That description could be applied to at most a few hundred portals.
As you know, those portals have been deleted because they don't meet the portal guidelines ... so your whole claim of this being the work of a few editors is either more lies, or a paranoid delusion.
Now, that diff.[1]
  1. It is not a revert. It was a removal of a category on Portal:Washington, D.C..
  2. I removed Category:Portals by city because the portal was already in the subcat Category:United States portals by city, so per WP:SUBCAT it shouldn't also be in Category:Portals by city. This is very very basic categorisation policy, so it is bizarre that you try to make an issue of this at in an RFC.
So that's another of Moxy's fairy tales disposed of. So where exactly is this evidence of portal improvement being blocked? --BrownHairedGirl (talk) • (contribs) 23:51, 1 July 2019 (UTC)
  • @Davey2010, I agree with all that. I voted delete in the 2018 RFC (as the lesser evil of a binary choice), but I accept the outcome and see no benefit in a re-run.
However, this proposal isn't actually born out of a desire to end portals. The proposer Moxy actually wants to keep all portals, and this RFC is a thoroughly bad faith straw man proposal after Moxy's objectives failed through other channels.
In the last 4 months, many portals have been deleted at MFD because they were abandoned, stillborn, or had too narrow a scope. These last few months have seen a cull of several hundred of the worst portals, because they failed the criteria set out in WP:POG. Moxy has objected to many of these deletions, almost always without success.
So Moxy and others have tried to change the guidelines to remove the quality criteria. See e.g. WT:Portal/Guidelines#How_often_to_update? and WT:Portal/Guidelines#Pageviews where such proposals have been roundly rejected. In his characteristically abysmal writing style, Moxy has been quite explicit about his goal: "We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion. criteria."
Having failed to remove the quality threshold from the guidelines, this RFC is a straw man: Moxy hopes that its rejection will allow him to claim that there is a consensus not to delete any portals.
This disingenuous tactic is foolish, because most editors can well understand that a decision not delete the entire namespace is not a decision to keep every piece of ten-year-old abandoned junk in portalspace. There are some really good portals which serve readers well, and most editors want to see the junk culled while keeping the good stuff ... but Moxy is going to play his transparent game of trying to pose it as a binary choice between keep keep all or delete all.
I'm inclined to think that there should be some certification process for RFCs, requiring a number of co-signatories before the Village Pump can be abused in this way. It is a waste of the community's time for a linguistically-challenged "editor" to be free to unilaterally start to waste the community's time with this sort of straw man game. --BrownHairedGirl (talk) • (contribs) 00:15, 3 July 2019 (UTC)
Hi User:BrownHairedGirl, I agree if they're not being used then yeah I see no valid reason for keeping them,
I have to say looking at their contribs I'm rather disappointed at the continuous !votes on various portal MFDs- The time trying (and failing) to keep these crap could seriously be better spent on writing or improving articles for our readers,
If they've genuinely created this to make some sort of point then I hate to say it but they've all but failed on that too. –Davey2010Talk 00:57, 3 July 2019 (UTC)
@Davey2010, given the exceptionally poor writing skills which Moxy has displayed in all the discussions I have seen, it is probably a blessing that Moxy puts their efforts into defending the indefensible chunks of portalspace rather than polluting articlespace with gobbledygook such as We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion. criteria. --BrownHairedGirl (talk) • (contribs) 01:04, 3 July 2019 (UTC)
  • Oppose. The last widely advertised RfC, only last year, closed with a consensus to keep the portal space. I'm involved in portal editing & I have literally tripped over this by accident, so it does not seem widely enough advertised. Espresso Addict (talk) 07:15, 7 July 2019 (UTC)
  • Oppose. I think portals can fill a niche that lists and navboxes cannot fill. An interactive guided exploration into the subject scope. And that does not mean a bunch of navboxes collected together in colored boxes, but rather a focus on modern multimedia technology and a more visual narration style than what would otherwise be acceptable in the article-sphere. Maybe a lot of portals did not do a good job at that in the past and some attempts to make the portals easier to maintain actually made them less attractive and useful, but I do not see the need to throw the baby out with the bathwater. If Wikipedia wants to stay in touch with the next generations, then it should also try and utilize other navigational methods than just a bunch of boring lists of links that you can hover over with your mouse (still a great improvement to boring lists of links that you cannot hover over with your mouse by the way). I also agree with User:Espresso Addict that the decision to delete all portals should be on a similar scale than the last RfC. Hecato (talk) 10:46, 11 July 2019 (UTC)
  • Oppose. This same stupid proposal has already been made many times before in the past, all of which close with consensus to keep them. People clearly find them useful as per the consensus of last time, so why this is being brought up again I will never understand. Namcokid47 (talk) 23:27, 11 July 2019 (UTC)
  • Weak oppose. Portals are probably the most prominent way that the main space is linked to WikiProjects. This is, in my opinion, something good to promote people getting involved. I have no strong opinion on portals, but if we removed them, we should consider advertising wikiprojects at the bottom of articles with the same style that we advertise portals today. --MarioGom (talk) 15:34, 21 July 2019 (UTC)

RCP False Positives

When I go to recent changes patrol, and selecting the “Very likely have problems” parameter to look for vandalism, I would sometimes end up with “false positives” (e.g. a good-faith editor deleting a lot of content due to it being original research). I accidentally reverted something like my example before. Even though I check edits to make sure they are not vandalism, I propose adding a computer program to double check edits that are tagged as “Very likely have problems” to reduce false positives, reducing “accidental reverting”. LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 06:42, 23 July 2019 (UTC)

@LPS and MLP Fan: - how would you use a computer program to "double check" them? You'd need to create an equivalent (but non-identical) variant of ClueNG, which seems like a staggeringly complicated job for a relatively rare problem. Probably about 8% of those tagged as such are false positives, and hopefully it's pretty rare for humans to judge them incorrectly. Nosebagbear (talk) 09:32, 23 July 2019 (UTC)
There is already computer checking going on with recent changes, that is mostly where the "likelihood" values are coming from, see mw:ORES. It is a work in progress to get the predictions as good as possible. — xaosflux Talk 13:28, 23 July 2019 (UTC)
@Nosebagbear: I won’t exactly create a bot, but the program to detect false positives would be a computer program imbedded in the RCP system. LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 14:32, 23 July 2019 (UTC)
"RCP" is a very broad topic as well, do you mean to change the filtering directly at Special:RecentChanges, or somewhere else? — xaosflux Talk 14:45, 23 July 2019 (UTC)
I mean to change the parameter on RCP, Very likely have problems. It looks like this (click link): [2] LPS and MLP Fan (LittlestPetShop) (MyLittlePony) 17:47, 23 July 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal for a new file naming criteria: harmonize extension name

NO CONSENSUS
There is no consensus to add "Harmonize file extension format names to ease their usage" as a new criteron to Wikipedia:File names § What files should be renamed? (WP:FMV/W). Supporters of the new criteron believe that consistent capitalization across file names would be beneficial. Opposers note that the criterion would not affect files hosted on Wikimedia Commons, which comprise most of the files used on Wikipedia. — Newslinger talk 22:48, 11 September 2019 (UTC)

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

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

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

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

  • Harmonize file extension format names to ease their usage

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

Survey (file format names)

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

Discussion (file format names)

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

Disambiguation namespace

Since disambiguation pages are not considered encyclopedic, why are they in the main space? Has it been previously discussed to have a Disambiguation namespace so that the article count (currently standing at 5,887,631) would be more representative of actual encyclopedic articles? Banana Republic (talk) 02:14, 15 July 2019 (UTC)

  • @Banana Republic: This topic has appeared in the context of other conversations a few times, but there is only one conversation I can find (quickly) which is dedicated to it—Wikipedia:Village_pump_(technical)/Archive_33#Disambiguation:_namespace. This conversation is negative on the idea and presents some arguments. Personally, I think that disambiguation could, in the long term, be folded into Wikidata functionality, with the concomittent elimination of DAB pages and replacing with a search facet which draws on dab-data, but that's not something close to being discussed at present as far as I know. --User:Ceyockey (talk to me) 02:30, 15 July 2019 (UTC)
That was a rather short discussion, and it appears that it contained a basic fallacy. One user wrote "Disambiguation pages are still articles". Perhaps they were considered articles in 2008 when the discussion took place, but they are not considered articles today by Wikipedia:Disambiguation which states that "Disambiguation pages are not articles and so should not be tagged as orphans". It therefore seems that if they are not considered articles, they should not be in the article namespace. Banana Republic (talk) 02:43, 15 July 2019 (UTC)
There are lots of things in the mainspace that are not articles. Like redirects, (some) lists, etc. Killiondude (talk) 02:48, 15 July 2019 (UTC)
Per this link, redirects are not counted in the article count.
Per Wikipedia:Manual of Style/Lists, lists are considered as list articles.
This means that if disambiguation pages were to be put into their own namespace, the article count would reflect the number of articles plus 1 (the main page, which is not considered an article). Banana Republic (talk) 02:59, 15 July 2019 (UTC)
I was making the point that some lists are akin to disambiguation pages in that they are nothing but links. Killiondude (talk) 03:02, 15 July 2019 (UTC)
Lists are different from disambiguation pages, and serve a different purpose. Banana Republic (talk) 03:04, 15 July 2019 (UTC)

According to Template:Disambiguation, there are approximately 190,000 disambiguation pages on Wikipedia (that incorporate the template). This is approximately 3% of the 5.89 million pages that are counted as articles. I think it would be good idea to have those 190,000 articles removed from the article count, and have a more meaningful article count. Banana Republic (talk) 03:16, 15 July 2019 (UTC)

Where would the links point, then? What would be at those titles? If an editor makes a link to Seal or Pop or Frank Smith, or a reader searches for that term, would the link point to a redirect to this new space? There isn't an article that could remotely be considered the primary topic for any of those terms. bd2412 T 03:54, 15 July 2019 (UTC)
Per WP:INTDABLINK, "Links to disambiguation pages from mainspace are typically errors". Therefore, with perhaps a few exceptions that I cannot think of, there should not be any links to disambiguation pages from within the mainspace articles. Banana Republic (talk) 04:07, 15 July 2019 (UTC)
I am fairly certain that pages which include <code>__DISAMBIG__</code> are not included in article totals. --Izno (talk) 04:26, 15 July 2019 (UTC)
Nope, I'm wrong. Interesting. Maybe that should be a request in for the devs. --Izno (talk) 04:27, 15 July 2019 (UTC)
I would think that developers would want to see a consensus before considering implementing such a change. Banana Republic (talk) 05:38, 15 July 2019 (UTC)

As pages change whether they are disambiguation pages or not (when we decide what is or what is not the primary topic), the sharp distinction of an extra namespace does not look like a good idea to me. Having Mercury redirect to Disambiguation:Mercury also does not look like an improvement. The main advantage of the proposed change seems to be that it might make it easier for our article count to be more accurate, but that is hopeless anyway, with sub-articles and with lists split into several articles because they are too long otherwise. Whether we overestimate the "correct number" by 3%, 5% or 10% (or underestimate it because of merges that really are covering separate topics) isn't relevant unless we pretend the "article count" actually means anything at all other than "Wikipedia is really big, and still growing". And we shouldn't pretend it means any more than that. —Kusma (t·c) 09:01, 15 July 2019 (UTC)

Such a move would be a case of the article count tail wagging the encyclopedia dog. We are here primarily to build an encyclopedia, not to worry about things like article count, so any decision should be made on the basis of what makes for a better encyclopedia. People are free to count articles in any way they want without the encyclopedia being disrupted for the sake of counting them. Phil Bridger (talk) 09:21, 15 July 2019 (UTC)
Article count is only one issue. The bigger issue is to drive home the point made in WP:Disambiguation that Disambiguation pages are not articles. Nothing makes the point more clear than to put them in their own namespace. Banana Republic (talk) 12:43, 15 July 2019 (UTC)
So you propose spending hundreds of hours of editor and developer time on driving hime a point made by a throwaway remark about whether certain pages should be tagged as orphans, without presenting any evidence that confusion over this point has caused the slightest of problems? I won't be commenting any further here, because I have better things to do with my time than discussing pointless proposals. Phil Bridger (talk) 14:03, 15 July 2019 (UTC)
Yes, the transition would indeed require some effort, but I think it is an effort worth exerting. I think it is worthwhile to keep things clean and keep non-articles out of the article namespace. Banana Republic (talk) 14:29, 15 July 2019 (UTC)
Disambiguation are IMHO a reading aid to help readers find the article they really want to read. A service to readers. To hide them, is not helpful at all. The Banner talk 13:09, 15 July 2019 (UTC)
The proposal would not make disambiguation pages hidden. It would only make hat notes that currently point to disambiguation pages such as George Washington (disambiguation) point to Disambigution:George Washington instead. Banana Republic (talk)
And it would make lots of pages become redirects to the disambiguation namespace. Someone who wants a working copy of the encyclopaedia would need to copy not just the article, but also the disambiguation namespace. Your fallacy is to assume that only "articles" can be in the article namespace. Many lists and outlines are not proper "articles" either, nor is the Main Page. (Moving the Main page to a different namespace, say, portal or Wikipedia, is a proposal I would support, though). —Kusma (t·c) 13:29, 15 July 2019 (UTC)
Your fallacy is to assume that only "articles" can be in the article namespace. Huh???? That's a fallacy?
Many lists and outlines are not proper "articles" either. I don't know what you mean by "outlines" (perhaps you meant "stubs"?), but as already pointed up earlier, per Wikipedia:Manual of Style/Lists, lists are considered as list articles. Banana Republic (talk) 13:48, 15 July 2019 (UTC)
Outlines, like Outline of biology. Or one of the 500+ articles that transclude Template:Outline footer. Often also called a "rough sketch". The Banner talk 15:10, 15 July 2019 (UTC)
Per the nutshell in Wikipedia:Outlines, An outline is a list article, and hence would not be impacted by this proposal. Banana Republic (talk) 16:10, 15 July 2019 (UTC)
The nutshell states An outline is a list article, arranged hierarchically, that helps a reader learn about a subject quickly, by showing what topics it includes, and how the topics relate to each other. So even when you want to push this down to just a list, it is still a special type of list. The Banner talk 17:09, 15 July 2019 (UTC)
I'm still unclear about what benefit this will provide. From the readership POV, it seems like the best case scenario is for it to be exactly as good as it is now. From an editor POV, it seems like this only complicates things. Off the top of my head, it seems like we'd need a redirect page in place of the DAB page, so that errant links to seal, for example can properly get forwarded to Disambigution:seal. I generally dislike the phrase, "a solution in search of a problem" because it's often used dismissively, but this proposal sure seems like it qualifies. Could you specify what will be fixed? Matt Deres (talk) 16:03, 15 July 2019 (UTC)
I think it's a cleaner way to do things. If disambiguation pages are not considered articles, they should not be in the article namespace, and should be included in their own namespace (since they would not fit in any other existing namespace). Implementing this proposal would leave the main page as the only non-article in the article namespace (since redirects do not count anyway). Banana Republic (talk) 16:13, 15 July 2019 (UTC)
I get that aspect of it, but to what end? What problem are people having that this will address? Matt Deres (talk) 17:53, 15 July 2019 (UTC)
In reply to the post of 02:14, 15 July 2019 (UTC): yes - the notice at Wikipedia talk:Namespace#Disambiguation namespace and this refers to Wikipedia talk:Disambiguation/Archive 33#Dab page location which in turn refers to Wikipedia:Village pump (policy)/Archive 50#ALL disambiguation pages to end "(disambiguation)", Wikipedia talk:Disambiguation/Archive 31#Hatnote redirects to disambiguation pages. and Wikipedia:Village pump (policy)/Archive 84#Uniform Disambiguation page naming. Some of these discussions link to other previous discussions. --Redrose64 🌹 (talk) 19:49, 15 July 2019 (UTC)
  • Just throwing the option here, as I do see several problems with that as well: Our search functionality gives a pretty good 'disambiguation' for 'Mercury'. We could basically delete all disambiguation pages ánd redirects that point to disambiguation pages, upon which a search for 'mercury' will automagically bring you to a list of possible articles. Only problem is that http://en.wikipedia.org/wiki/Mercury does not bring you directly to a search result but to a 'create this page' result (but also that could be changed. (Now arguably a search result may be less informative than a properly sectioned disambig page). --Dirk Beetstra T C 12:00, 16 July 2019 (UTC)
    • This only works for individual words. For multi-word phrases, including human names, the search function is borderline unusable for disambiguation purposes. If you are searching for a "John Smith" it will give you every article containing the words "John" and "Smith", and will often bury clearly relevant results behind several pages of jumbled irrelevant results. Also, as you might note, for pages that have a primary topic, like Andrew Jackson or Los Angeles, searching for the title will take you to that primary topic, meaning that a disambiguation page is required (Andrew Jackson (disambiguation), Los Angeles (disambiguation)) to easily see other results. There are tens of thousands of disambiguation pages like that, with primary topics placing the page at disambiguated titles. bd2412 T 23:50, 16 July 2019 (UTC)
      • @BD2412: I already expected that there was something obviously stupid about my idea :-). --Dirk Beetstra T C 13:42, 17 July 2019 (UTC)
        • The deficiencies of the search function are actually not obvious at all, until someone does a lot of work using that search to set up disambiguation pages. There are some instances, where there is a single-word title with a small number of meanings which are all title matches, where this would work. On the other hand, if you look at a page like Seal, and then do a search for the word "seal", look how far down the search results you have to go to find the single most common meaning of seal, Pinniped. bd2412 T 15:55, 17 July 2019 (UTC)
  • Oppose per the Banner. Disambiguation pages are in the mainspace because they are part of the encyclopaedia, like articles and redirects they are used by our readers. Other namespaces are for things that ultimately help build the Encycopaedia but are not part of it. If for statistical purposes we want to breakdown how many pages in mainspace are articles, how many are redirects and how many are disambiguations then I suspect that can be done by programmers. ϢereSpielChequers 09:04, 20 July 2019 (UTC)
As I have written elsewhere, it's not just about article count. It's also about keeping what is considered non-encyclopedic articles out of the article namespace. Banana Republic (talk) 00:01, 22 July 2019 (UTC)
This would involve moving literally hundreds of thousands of pages, and making thousands of other adjustments and fixes to existing templates policy pages, and reports. bd2412 T 00:22, 22 July 2019 (UTC)
That's correct, but it would be a one time thing, and in my opinion, worth the effort. I assume the bulk of the work could be automated. Banana Republic (talk) 01:13, 22 July 2019 (UTC)
  • This is a solution in search of a problem. There is a moderate amount of movement between regular articles and disambiguations as new articles are created about people and things with the same name, and placing disambiguation in a separate namespace just complicates the process and obscures the history for no obviously useful purpose. The whole "they aren't articles" argument is an exercise in hair-splitting. Redirects aren't articles either, yet they reside in article space, and they are subject to a certain amount of movement between regular article status and redirects too. Somehow the encyclopedia manages to get along just fine that way. And on the Wikidata idea ... no. The whole WP/WD interface is a black box to most editors. Acroterion (talk) 03:54, 22 July 2019 (UTC)
  • What counts as a disambiguation page vs article vs navigation aid is difficult to discern in some instances. It can be something of a grey zone, a matter of perspective. eg. Kart Racing Championships, Bhagwat, Custos, Remotely operated vehicle, Toronto radial lines, Mythology of the Caucasus, Mercedes-Benz SLC-Class, ARD Digital -- GreenC 04:42, 22 July 2019 (UTC)
  • In my opinion, this is a good case for rejecting based on WP:IAR alone. So disambiguation pages do not belong in article space? What harm does it cause? As Acroterion notes above, this is an exercise in hair-splitting that provides little or no benefit to the encyclopedia. -- llywrch (talk) 19:47, 25 July 2019 (UTC)

Accessibility (understandability) as a requirement for GA and FA class articles

The requirements for WP:B class articles require that the article "presents its content in an appropriately understandable way" and that "it is written with as broad an audience in mind as possible." This would logically mean that classes higher than B (WP:GA? and WP:FA?) would also have this requirement, but it doesn't. This could technically allow for articles to assume lots of prior knowledge before reading, without efforts to explain certain concepts where possible. As it stands now, the closest thing to an accessibility requirement is that the prose should be "clear and concise" for GA and "engaging and of a professional standard" for FA. Scientific papers usually pass these requirements, but they are written for experts in the field, not for laypeople; this type of writing shouldn't be what Wikipedia is aiming for.

My proposal is straightforward: mention accessibility as a requirement under the "well written" section of WP:GA? and WP:FA?. This could amount to simply adding a single word and it would make it crystal-clear for nominators and reviewers alike what is expected of the article.--Megaman en m (talk) 09:04, 4 July 2019 (UTC)

  • Could you clarify what changes would be made to ensure "accessibility" is met? The word covers a potentially huge area, and I'd like to know what would be required. Adding a request for "accessibility" isn't as crystal clear as you may think! - SchroCat (talk) 09:20, 4 July 2019 (UTC)
  • That sounds like something that's easier to say but harder to define: how would you define a more accessible FA in one word? ——SerialNumber54129 09:22, 4 July 2019 (UTC)
  • WP:Accessibility is part of our manual of style, and so could be linked along with the MOS pages currently cited by the GA and FA criteria, but I'm not sure that this is the same as what the original poster means by "accessibility". Phil Bridger (talk) 09:33, 4 July 2019 (UTC)
I was indeed not referring to that kind of accessibility, I'm referring to making articles as easy to read as possible while still including complex topics.
As to the wording, I now see that it would have to be defined more clearly than I stated it originally. The sixth requirement WP:B? does a good job of explaining it, maybe we could use that as a base. For WP:GA? we could add accessibility as a third requirement under the 'well written' section, something like "c. The article must not require excessive prior knowledge and explains technical terms where possible.". For WP:FA? we could add: "b. Accessible: The article can be understood by a broad audience and explains technical terms in the article itself."
I'm not sure if the wording should differ between FA and GA, but I tried writing it such a way that the FA requirement for accessibility is "stricter" than the one for GA, although I recognize I might not have done a great job at that. The specific wording is tentative and open for input.--Megaman en m (talk) 09:48, 4 July 2019 (UTC)
Rather than try to add further rules onto an already rule-laden process without an indication of the problems, could you find some examples of FAs and GAs you see as problematic? Thanks - SchroCat (talk) 10:02, 4 July 2019 (UTC)
My proposal isn't intended to expose problematic GA or FA articles, rather it is aiming to rectify internal inconsistency between requirements and offer clarity to reviewers and nominators. I could find various instances of terms in GA or FA articles not being adequately described to a lay audience, such as "accusative morphosyntactic alignment" in Danish, but that would be missing the greater point. Technically, another way to increase consistency would be to just remove the accessibility requirement of WP:B?, but that would not be the right way to go in my opinion.--Megaman en m (talk) 10:41, 4 July 2019 (UTC)
One example I can think of is Crater (constellation), specifically the Features section. In my comments on the FA nom I, mentioned that section and invoked WP:AUDIENCE, which says, among other things, Make your article accessible and understandable for as many readers as possible., which I think is exactly what Megaman en m is talking about. I'm not trying to shame this specific article or say it shouldn't have been promoted to FA, but I do think that providing context to the (non-expert) reader is still an area where this article could improve, and I like the idea of it being an explicit part of the FA/GA criteria (even if it's only briefly mentioned). Colin M (talk) 16:47, 5 July 2019 (UTC)
I think your first step - if you want to pursue this further - is finding another term. For Wikipedia, accessibility is defined as linked above. You want something different, so for clarity that then needs another name. --Gerda Arendt (talk) 12:03, 4 July 2019 (UTC)
Accessibility would be the usual term for what I'm talking about, but if a paraphrase is needed, maybe just say that the article has to be "understandable"? That's the term used in the essay on the perfect article describing the same concept.--Megaman en m (talk) 12:44, 4 July 2019 (UTC)
If it's "understandability", then FAs should already be compliant - having at least five reviewers per article (normally from non-specialists, unconnected wth the subject matter) means that should be the case already. - SchroCat (talk) 12:51, 4 July 2019 (UTC)
Understandable is what is used by the relevant guideline, Wikipedia:Make technical articles understandable, and yeah, people are going to be confused if you use the word "accessibility" so I would recommend "understandability". Galobtter (pingó mió) 13:11, 4 July 2019 (UTC)
That's an interesting way of looking at it, I haven't considered that. But this still leaves GA "vulnerable" to the understandability issue, as the single reviewer is usually familiar with the general subject and might not consider the viewpoint of a layperson. For example, the reviewer of a video game article nominated for GA might not stop to think that a layperson might not know what experience points actually do.--Megaman en m (talk) 13:00, 4 July 2019 (UTC)
I don't believe that "The article can be understood by a broad audience" is always possible, so your proposal would exclude (from FA at least) some topics from being covered at all. For instance, an article I've worked on that is currently rated as B-class, Dehn invariant, has a lead that I hope can be read by mathematically-inclined high school students, but some later content (particularly "Realizability") that might well be difficult for undergraduate mathematics majors. That is not because of any intention to make the article difficult, but rather because after making it as easy to access as I could it was still difficult; it is a technical subject and some technicality is unavoidable. Should such articles be automatically barred from being at a higher class? Should there be no incentive to work towards making such articles better, because it cannot be rewarded with a higher class? —David Eppstein (talk) 18:47, 4 July 2019 (UTC)
I agree with David Eppstein that there are many articles that we should include and allow to be at GA or FA class, in all academic topic areas, that are difficult for many people to understand. We should be stretching people. But, having said that, and as a postgraduate student of mathematics, I find many of our mathematical articles unnecessarily obfuscatory, which reflects most mathematicians' inability to write in a clear, understandable, way. I find most mathematics pretty easy to understand, but also find most of our mathematical articles pretty difficult to understand. Phil Bridger (talk) 19:14, 4 July 2019 (UTC)
It is of course the case that any article should be able to attain FA status, in principle. Some topics reasonably require some preexisting knowledge for the more basic concepts; if we had to explain every single piece of jargon in an advanced article about genetics, the article would become unmanageably long-winded. My proposal is that a serious attempt is made to avoid these technicalities or explain them when possible (e.g. when it can be adequately explained in a sentence or two). If the concept needs to be mentioned, is complex, and can't be explained shortly, then a simple wikilink is all we can do.
For example, a language article should not explain what a noun or tense is. But, when it comes to terms like "accusative morphosyntactic alignment" mentioned above, even someone with a introductory knowledge in linguistics might be left scratching their head. I recognize that it might be difficult sometimes to determine what a "basic" concept is versus a more advanced one, but that alone shouldn't be a reason to can the proposed understandability requirement. As a side-note, more complex concepts should preferably be mentioned near the end of the article; the introduction should ease people into the topic at hand, not scare them away.--Megaman en m (talk) 19:18, 4 July 2019 (UTC)
Yes, "can be understood by a broad audience" might be too strong a requirement. But WP:B? uses the wording The article presents its content in an appropriately understandable way. It expands on that by saying It is written with as broad an audience in mind as possible. Although Wikipedia is more than just a general encyclopedia, the article should not assume unnecessary technical background and technical terms should be explained or avoided where possible.. I think wording along these lines would address your concern, and not automatically exclude any articles about technical subjects out of the gate. For a highly technical subject "as broad an audience as possible" might actually be pretty narrow, and should be considered in light of the set of readers who are likely to actually reach the page. Someone with only a very basic math education is unlikely to reach Dehn invariant, so their ability to comprehend the article's content shouldn't be a strong consideration. Colin M (talk) 17:17, 5 July 2019 (UTC)
I might call it "readability". But I think at least most regular FAC nominators at least hope that reviewers will help out on this. I know as a lawyer I have a tendency to use jargon in my field. That has sometimes led to reviewers going "huh?" I'd like to say "we're already doing this" but I'm waiting really for actual examples in recent FAs.--Wehwalt (talk) 23:47, 4 July 2019 (UTC)
Readability is the closest thing I could think of, where there is a score generated on a readability scale. Alanscottwalker (talk) 00:00, 5 July 2019 (UTC)
Readability is a related – and useful – concept, but it's not what I'm talking about exactly. Readability would readily fall under the current "well-written" requirements.
Responding to Wehwalt: Someone pointed out that the fact that FA requires multiple reviewers who are usually not knowledgeable; this sort of fixes the understandability problem nicely. However the problem still remains for GA articles, due to the fact that it only require single reviewer who usually is knowledgeable about the subject. I would also like the requirements for all the classes to be internally consistent. By that I mean that a lower class shouldn't have a requirement lacking in higher classes (I'm talking about the 6th requirement in WP:B?.
Long story short: I now think that the understandability requirement is not practically necessary for FA class. However, for reasons of consistency and the reviewing process, GA would still benefit from this requirement for the reasons mentioned above.--Megaman en m (talk) 07:47, 5 July 2019 (UTC)
The B-class criteria "presents its content in an appropriately understandable way" and that "it is written with as broad an audience in mind as possible." are reasonably practicable and reasonably clear in intent. How they would be interpreted in any specific case will depend on the topic. Is there any reason to assume that B-class criteria no longer apply when an article is proposed for GA and FA? Feedback on what is appropriate and possible should come from someone who has the background necessary for the target audience. This is usually a person who is not already an expert, but in many cases must have some existing understanding of the broader level of the topic. When there is uncertainty or disagreement among reviewers, it could be useful to first come to some agreement on who is the target. The proposer should have a reasonably good idea of this, and should be able to explain why. · · · Peter Southwood (talk): 08:23, 5 July 2019 (UTC)
Because B-class doesn't require peer review, there is a good chance some B-class articles don't fully comply with the B-class requirements. GA is where, for the first time, the adherence to the requirements get scrutinized by an impartial reviewer. Therefore, it should at least contain all the requirements from lower classes, including understandability. The average (knowledgeable) GA reviewer will focus on more on the listed requirements, especially prose, grammar and sourcing. Understandability might fall through the cracks and be "re-discovered" during a potential FA nomination.--Megaman en m (talk) 08:39, 5 July 2019 (UTC)
  • Whole-heartedly support this. This is already a factor I consider when doing GA reviews (and I imagine many others do too, even if subconsciously). You could argue that this already exists in the penumbra of WP:GACR between "prose is clear and concise" and "stays focused on the topic without going into unnecessary detail", but I think it would be beneficial to mention it explicitly. Agree that it need not be a whole new criterion, and could be as simple as adding a few words. cf. WP:AUDIENCE, which expands on why and how to make an article "accessible and understandable for as many readers as possible". Colin M (talk) 16:57, 5 July 2019 (UTC)
So do most people agree that the sixth requirement of B class should be incorporated one way or another into the FA and/or GA requirements? It doesn't have to have its own section.--Megaman en m (talk) 06:34, 6 July 2019 (UTC)
  • I certainly agree that an article that could practically be written in such a way that a broad audience could understand it, but is not, should not be FA and perhaps not GA. My concern is, who exactly is judging the extent to which it can be written non-technically?
    Aside: This is a perennial problem with the {{technical}} template. Very frequently it is added to articles with no indication of how understandability could be improved, or even where the article fails to be as understandable as possible. The simplest explanation seems to be that the tagging editors don't understand the material themselves, and for that reason suppose that there is something wrong with the exposition, which may or may not be true but which they are not equipped to judge.
    So either you give non-technical reviewers veto power over promotion of technical articles, or you ask them to simply trust the judgment of experts that the material is presented as clearly as possible. I can't say that either of those options is especially attractive. --Trovatore (talk) 08:06, 6 July 2019 (UTC)
  • I'm leaning oppose on this proposal given WP:CREEP and the vague possibility that a sufficiently niche topic that couldn't be written from a general point of view would thus be excluded from FA status. Furthermore, I'd argue that the following sections from the FACR could be interpreted to already imply an accessibility requirement:
its prose is engaging... (from 1a)
it neglects no major facts or details and places the subject in context (from 1b)
(Emphasis mine on both)
If the prose is engaging, it engages a general audience, which would imply that a general audience could understand it. If the subject is placed in context, then a person sufficiently aware of the context from the article could then understand the details.
Having said all of that, I would not vociferously oppose the proposal if the consensus evolved to overwhelmingly favor it. – John M Wolfson (talk • contribs) 05:31, 7 July 2019 (UTC)
@Trovatore: If asked, the nominator should be able to state who the audience of the article should be. This way, the reviewer can gauge how they should enforce the understandability requirement. For example, (most?) biographies should be written for: everyone. If the reviewer finds unexplained jargon, they should ask for it to be explained. Articles on the grammar of a language should be written for: people with basic background in linguistics/grammar. Writing such an article for people without the necessary background would be nigh-impossible; most of the article would end up explaining basic linguistics rather than talking about that language's grammar. It would be up to the nominator to argue that it is not feasible to write the article for "everyone". There is of course still a risk of not agreeing on what "basic background in linguistics" actually is. This problem is not unique to understandability however. The prose being "clear and concise" and what constitutes 3b. "unnecessary detail" can run into similar problems. In short: I believe that any potential downsides are outweighed by the upsides of having both the reviewer and nominator keep the broadest audience possible in mind.--Megaman en m (talk) 07:46, 7 July 2019 (UTC)
@Megaman en m: Well, I guess that answers part of my concern, but the deeper issue here is, how is a reviewer, not having the background needed to understand the topic of the article, expected to judge whether it is written appropriately for the intended audience? Can we specify that such a reviewer is expected to ask for expert help on such matters? --Trovatore (talk) 22:21, 10 July 2019 (UTC)
@John M Wolfson: My answer above to Trovatore might ease your fears of having niche articles inadvertently excluded from FA/GA. On the current FA requirements: I don't agree they enforce understandability as mentioned in 6. WP:B?. I find technical papers on linguistics engaging, but I wouldn't have a non-expert read them. They also place the subject in the right context, although they usually do so by introducing even more jargon. An understandability requirement is not currently covered by other FA/GA requirement and would help people in the reviewing process focus on the important task of keeping the intended audience in mind.--Megaman en m (talk) 07:46, 7 July 2019 (UTC)
@Megaman en m:, that does somewhat assuage my fears of writeability for niche topics. As for placement in the right context with linguistics (basic grammar, etc.), I guess that's what internal links are for. – John M Wolfson (talk • contribs) 07:52, 7 July 2019 (UTC)
@John M Wolfson: Internal links are useful, but they should primarily be for people wanting to read more about that topic rather than "required reading material". They should only be relied upon as a last resort.--Megaman en m (talk) 08:08, 7 July 2019 (UTC)
It all depends. There are what I call "101 articles" (from the classic designation for basic university courses in the US) that should not assume much knowledge. Then there are "202" articles that have "prerequisites" when it comes to knowledge and may have to rely on links for basic concepts, and possibly higher numbers as we get more specialized. Some articles are hybrid, an article on a ship may be "101" when it comes to its history but "202" or more when it comes to the ship's specifications and equipment. While we don't have as much information on reader reaction as I would like (I supported the old feedback tool), FA nominators and reviewers have seen a lot of talk page comments, reactions on TFA day and other people's reviews, and do a good job in gearing things properly. I'm just not certain what we are supposed to do differently.--Wehwalt (talk) 11:01, 7 July 2019 (UTC)

I think most editors instinctively understand that a GA should of course also satisfy the general B-class criteria. Although there are some complications around this idea: B-class assessment is usually made by WikiProjects, which adapt the B-class criteria to their special needs. And somewhat annoyingly, the numbering of the 6 GA criteria is so different from that of the 6 B-class criteria that it is seriously confusing. B1 is strengthened to GA2, B2 is covered by GA2-GA4, B3-B4 are covered by GA1, B5 is essentially GA6 + asking for infoboxes, and B6 is not explicitly covered by GA1.

The last point, which Megaman en m has discovered, is because GA1b doesn't require full MOS-compliance but only certain sections, not including MOS:JARGON. I think this is not because MOS:JARGON shouldn't be applied but because in contrast to what is listed in GA1b it's just a tiny section. Maybe it could be added to the list anyway?

Another thing one might add to the GA criteria, and which might actually be enough on its own: Normally a GA should should satisfy the B-class criteria of the appropriate WikiProject(s). But this should be clearly marked as something GA reviewers don't have to check. It would be significant extra effort and could have unwanted effects where WikiProjects have strange ideas about B-class criteria (e.g.: may only use WP:MEDRS sources regardless of what is supposed to be supported) or about what is in their scope. Hans Adler 11:53, 7 July 2019 (UTC)

To move this discussion forward, I started a voting process.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)

Can the lack of opposition be taken that most people are okay with this proposal?--Megaman en m (talk) 19:19, 14 July 2019 (UTC)

No. (See also WP:POLSILENCE.)
As for me, I'm not necessarily opposed, but I don't feel my concerns have been adequately addressed. --Trovatore (talk) 19:41, 14 July 2019 (UTC)
I don't think you've made your case about FA, and from the comments, I didn't see much of an attempt to have a change to WP:WIAFA. I don't have an opinion on GA.- (Wehwalt) -19:44, 14 July 2019 (UTC)
@Trovatore: This proposal will make sure that the understandability is relative to the inherent difficulty of the material, as it will comply with WP:AUDIENCE. As for your other concern, first the nominator should make the case that the article can't reasonably be written for a broader audience. In this case, where the reviewer doesn't have the necessary knowledge, it should be expected of them to either ask for expert help, or do some basic research on their own. I have changed the proposal to reflect this.--Megaman en m (talk) 13:47, 16 July 2019 (UTC)
@Wehwalt: The case for FA rests on being consistent with lower classes. It is indeed weaker than the case for GA due to FA having multiple reviewers, which is why the proposal has come to focus on GA.--Megaman en m (talk) 13:47, 16 July 2019 (UTC)
How do I proceed now? Is this enough to move on to how the wording for understandability in GA should be implemented?--Megaman en m (talk) 07:08, 20 July 2019 (UTC)
@Megaman en m: Yes, I think that would be a good idea. I don't know if you were thinking of making it a continuation of this discussion under a new subsection, or starting a new discussion, but if it's the latter, I think Wikipedia talk:Good article criteria might actually be a better venue. It has less traffic overall obviously, but the people who do watch that page will be much more likely to have informed opinions about and a high level of interest in the GACR. And of course you could post a notice linking to it here and at WT:GAN. Just a thought. Colin M (talk) 16:57, 22 July 2019 (UTC)
Started a topic to discuss implementation for GA.--Megaman en m (talk) 09:13, 24 July 2019 (UTC)

The problem

Proposal: Incorporate the 6th requirement of B-class to GA and possibly FA (the exact wording is a topic for later). In other words: Make GA and/or FA articles formally comply with WP:AUDIENCE. Reviewers are expected to ask for expert help or do research if the topic is unfamiliar to them.

Why?: "Understandability" is very important, yet it is not specifically required for FA or GA status. This new requirement will help people in the reviewing process keep the average reader. This will also improve consistency between the classes.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)

Vote

  • Support (as proposer) With GA usually being the first time that an article undergoes peer review, the reviewer should pay just as much focus on understandability as grammar and sourcing. The FA review technically fixes this problem by having multiple reviewers act as they lay audience reading it for the first time, therefore "correcting" it for understandability. The single reviewer for GA is usually knowledgeable about the subject, which could cause them to overestimate the background knowledge of the average reader. I still believe that understandability deserves a mention in FA, even if just for the sake of internal consistency between classes.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)
  • Support for the reasons I wrote above. I think the most unobtrusive way to do this would be to add a few words to WP:GACR 1a with a link to WP:AUDIENCE. A whole new subcriterion of 1 (i.e. 1c) would also be fine, though that would require some template changes. Colin M (talk) 22:09, 8 July 2019 (UTC)
  • Pending. I could support this if it were clarified that understandability is relative to the inherent difficulty of the material, and that reviewers without the background needed to understand the material should ask for expert help in evaluating this criterion. ---Trovatore (talk) 20:00, 14 July 2019 (UTC) Support as amended. --Trovatore (talk) 16:47, 16 July 2019 (UTC)
  • So the above started about accessibility which makes some sense to me as a possible GA criteria. However this specific language is about how things are written which I had always assumed was covered in GACR 1A. So I'm in the abstract in favor of some language around accessibility but think this specific language is already covered. Best, Barkeep49 (talk) 16:06, 16 July 2019 (UTC)
  • To be clear, this proposal was never about "accessibility" in the sense of WP:ACCESSIBILITY. That word choice was a bit of a red herring (which is why the discussion has shifted more to using "understandability" instead). My reading of WP:GACR#1a (as currently written) is that it's about form more than content. i.e. spelling and grammar are correct, sentence structure is easy to parse, wording is unambiguous, etc. Whereas I see "understandability" applying more at the level of content. i.e. provide context as appropriate, state the obvious, don't use unnecessary jargon (and when it is necessary, explain its meaning). Colin M (talk) 16:20, 16 July 2019 (UTC)
  • With the proviso that sometimes the explanation of the jargon will necessarily use other jargon, and we can't always trace it all the way back to the beginnings of the subject without making the article useless to those it's potentially useful for. --Trovatore (talk) 16:49, 16 July 2019 (UTC)
  • Support Bit late to the show, but I think this is a very important criterion in general for articles and I welcome any extra focus on it, especially in GAs and FAs. Femke Nijsse (talk) 15:32, 31 July 2019 (UTC)

WikiLove for owing apologies

This would enhance civility and prevent users shying away. Although it is manually possible to make your own custom award, a template would encourage more and promote a crucial attribute currently lacking in this community. THE NEW ImmortalWizard(chat) 19:13, 22 July 2019 (UTC)

I wouldn't consider a templated apology to be a real apology. Much better to simply apologise in your own words, relevant to what is being apologised for. Anyone who is qualified to edit an English-language encyclopedia should be capable of writing a couple of sentences in English without a template. Phil Bridger (talk) 19:22, 22 July 2019 (UTC)
I'm inclined to agree. If you've made a sufficient error to warrant apologising, I wouldn't be impressed if I just received a template one. Nosebagbear (talk) 20:58, 22 July 2019 (UTC)
@Nosebagbear and Phil Bridger: I don't think ImmortalWizard is referring to templates here. This seems more akin to Barnstars which require a personalized message. @ImmortalWizard: you could theoretically already enact your proposal by giving a user a kitten, goat, or the custom option. I know plenty of users send kittens already as a way of saying sorry. However, we could add something like "Apology cake" to the food and drink section. It'd involve getting a good picture of a cake that says sorry, but that'd probably be more doable. It'd also overtake Baklava as listed first among the foods... though I have mixed feelings about that. –MJL ‐Talk‐☖ 18:05, 31 July 2019 (UTC)
Apologies IMHO don't need pretty flowers and fancy colours etc - A simple black and white apology should be enough. –Davey2010Talk 18:30, 31 July 2019 (UTC)

What should we do to 2607:fb90::/32

Moved to WP:AN § What should we do to 2607:fb90::/32 (moved from VPPR)
 – Enterprisey (talk!) 08:54, 3 August 2019 (UTC)

Whoa, this range is affecting billions of T-Mobile users. The block is too long, what should we do? Should we shorten it or extend it? 2600:1702:38D0:E70:B4CD:9550:507:3ED1 (talk) 18:12, 2 August 2019 (UTC)

Proposal - Unified index, glossary, and category using article short descriptions

Background...
Working with the newly constituted WP:WikiProject Climate change I ran into a long term maintainence headache at

A very superficial looking around suggests other subject areas have similar un-synched overlap.

This suggests the following problems...
A. There is too much overlap but not enough synchronicity between

B. The three bullets above require three different manual edits (There is a fourth edit which isn't presently involved in the problem but is a part of the solutiuon, and that is adding a short description to each article.)

C. Glossaries I have looked at all fail WP:Verification because they only have a few citations if any

Proposed unified solution
1. Provide a window of time for editors to verify entries on an index are properly categorized, and after the time period auto-replace all manual indexes with bot-generated indices based on categorization (assuming an index isn't just redundant in the first place)

2. Same as 1 but for glossaries. In addition to verifying categorization, verify each article's short description is suitable as a brief glossary explanation

3. When the bot auto-generates the glossary, it looks up and copies the articles short description from Template:short description

Advantages....

  • Instead of four steps to make a glossary + index + category + short description there are just two, tagging the articles for categories and adding the short description
  • There will be automatically be a 1:1:1 relationship between index, glossary, and category entries
  • Glossaries still won't have references, but odds are that glossaries are built with little peer review, whereas articles have a lot more watchers. Presumably the short descriptions will be more accurate due to the increased peer review from other eds.
  • Article short descriptions and glossary text will automatically remain in sync.
  • Urges editors to verify that all articles in a given subject area have good short descriptions (a goal included in the template's documentation)
  • After implementation, simply adding short descriptions and category tags takes care of all of this, while the bots maintain synchronicity between all four tools (indexes, glossaries, cats, and short descriptions). Super simple.

Comments, questions, discussion? NewsAndEventsGuy (talk) 02:48, 1 August 2019 (UTC)

Discussion

  • Support as proposerNewsAndEventsGuy (talk) 02:48, 1 August 2019 (UTC)
  • I don't think this will work for many areas. We have relatively few glossary and index articles in fact - still fewer areas with both -and where we do the articles will often be spread over several categories, and many if not most of the index articles shouldn't be in the glossary. So "There will be automatically be a 1:1:1 relationship between index, glossary, and category entries" doesn't necessarily strike me as a good thing. Both index and glossary articles are typically rather neglected in areas I work in, and not much viewed. It may be different elsewhere (actually looking at some, I see decent views for some glossaries). Johnbod (talk) 03:17, 1 August 2019 (UTC)
Thanks for commenting, those are easily overcome, I think.
For your first point, without examples, we're guessing. The climate change subject can be parsed and diced into different subcats, but there is still the mother category "climate change". I have a hard time believing a subject that is sufficiently one thing to have either an index or a glossary lacks a similar mother-of-all super category that catches everything. It must exist, so future bot generated index or glossaries could be based on that super category. Can you find an unfixable example that disproves this assumption?
Re your second point (maybe an index entry should not be a glossary entry) that's a good point. For subjects with both an index and a glossary right now we have editors thinking and pushing the right buttons so the index and glossary has intentional mismatch. The next editor might not maintain that mismatch because there is no record of the thinking by the first editor. Voila! Just add a parameter for the super-category template to suppress inclusion when the bot runs the glossary or the index. Then editors can still think and push the right buttons to get that outcome, and we can still enjoy the advantages I described, and future editors will see a record of the first editor's work to suppress glossary inclusion.
NewsAndEventsGuy (talk) 03:30, 1 August 2019 (UTC)
  • I haven't had time to consider this proposal fully, and probably won't for a few days, but in general I agree that the overlap between Index, Categories, and Glossaries (I would even throw in Outlines and Portals to the set) is something that needs more consideration. These pages duplicate the features and purposes of many others, and this is not ideal because it means things very quickly get out of sync and are hard to maintain as a set. At first glance, I like 1 and am unsure of 2 and 3 (mostly because I'm not sure short descriptions are reliable for that), but I'll think about it more. Wug·a·po·des​ 03:47, 1 August 2019 (UTC)
Yes, not only are short descriptions mostly currently written by dedicated non-specialists driving-by, they are almost always too short, vague and non-descriptive to be usable in a glossary. Restricting the idea to auto-compiling indexes from categories ought to be simpler & might be a good idea in some cases, though I suspect it might make many too long to be very useful. Johnbod (talk) 11:02, 1 August 2019 (UTC)
PROPOSER says.... Current practice is not an obstacle to reforming current practice, so that's something of a circular argument. Both short descriptions and glossaries are insufficiently vetted - not enough eyeballs, not enough source-checking. Sure, this proposal would change the word choice for some short descriptions, maybe. It would also increase care and attention put on both glossaries and short descriptions, which would be a good thing for both. NewsAndEventsGuy (talk) 11:47, 1 August 2019 (UTC)
Yes, so basically you are proposing a huge amount of work, needing to be done by relatively specialized editors, on articles that fairly few look at. Looking at some more index articles, I think quite a high proportion should be moved to draft space or user space until they can be brought to a useful level of completion (by automation or otherwise). Look at the completely useless Index of Renaissance articles, last edited in Feb 17, & about 1% complete. But I'll shut up now & see what others think. Johnbod (talk) 21:19, 1 August 2019 (UTC)
Not only are our index articles useless as they stand (Index of Renaissance articles is particularly bad, with only 35 articles – WP:PETSCAN finds 461 articles in Category:Renaissance or one of its immediate subcats, or almost 10,000 articles if it goes down to three categories deep), but I can't even work out what the point of them is, and neither WP:INDEXES nor WP:WPINDEXES is enlightening. Categories and outlines at least have a hierarchy, so it helps with navigation; I can't think of any reason I would ever be looking for an article in a particular topic alphabetically. Caeciliusinhorto (talk) 22:01, 2 August 2019 (UTC)
  • Some thoughts:
    1. On the one hand, both editors & users need something like an index or portal to find related topics that our current best tools -- namely hyperlinks, navboxes, & the category system fail at. There have been many times that even after a diligent search I've failed to discover existing articles related to the one I'm working on.
    2. On the other hand, indices/portals/outlines/lists fail because they are hand-made, not automated. It's a lot of tedious & error-prone work compiling one of those pages. Then they must be maintained & kept up to date; people have been known to stop contributing to Wikipedia, often with no notice.
    3. But until we have some kind of automated tool to create a guide to subjects -- say a means to apply the information at Wikidata, while retaining some kind of oversight, or an easy ability to modify the facts there -- we're stuck with what we have. (Yeah, we could insist that WMF fund such an application, but I've been waiting for them to provide a comprehensive guide to Wikipedia templates, & it's been at least 10 years since I first suggested that.) -- llywrch (talk) 19:47, 2 August 2019 (UTC)
  • Should not use short descriptions this way. Short descriptions are to be kept short, less than 40 characters, as they are targeted for mobile devices, etc. That requirement limits their use in any other area, as in this proposal; to be that short, they can (and often do) violate normal encyclopedic uses, such as skimping on proper grammar, overgeneralizing, etc. Worse, having multiple conflicting missions for short descriptions encourages changing them so as to be less useful for their intended primary purpose. Now, if we want to start a new "short description-ish" system for more general purposes as in this proposal, that would be okay; we could even allow one system default to using the description provided by the other if that's all that's available. (Maybe the current short description should be renamed mobile description to emphasize its more narrow specific purpose?) (And yes, I know many current short descriptions are not short; it's a very new system with teething problems, but we should assume these will be worked out. See Wikipedia_talk:Short_description#Should_a_short_description_define_or_distinguish?) --A D Monroe III(talk) 16:27, 3 August 2019 (UTC)
  • If only we had a linked-, open- data repository, and a tool to build Wikipedia pages from it. Oh, wait, we do: Wikipedia:Listeria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 3 August 2019 (UTC)

Multiple issues

I periodically see {{Multiple issues}} transcluded on an article with only one top-of-article issues template, e.g. see this revision of the Hot or Not article. Would it be worthwhile to have a bot go around and remove this template in such situations, both a one-time run now and periodic runs in the future? The point of a cleanup template is to draw attention to the problem in question, but {{Multiple issues}} doesn't do that — of course that's all right if there are lots of issues, but with only one issue the template doesn't particularly help, and also it looks rather silly to the reader to say "This has multiple issues" and then give just one. "What else is wrong with the article?" one might think. From a technical perspective, this should be really easy: get a list of all pages transcluding this template, check each one, remove template if it's encasing one or zero cleanup templates, and don't touch template if it's encasing two or more templates. Nyttend (talk) 22:44, 22 July 2019 (UTC)

Maybe {{Multiple issues}} could be made a bit cleverer to detect if there are fewer than two issues, and if there are none display nothing and if there is one then display it as if it wasn't wrapped in {{Multiple issues}}? I'm sure that this wouldn't be too difficult for one of our many Lua experts to implement. Phil Bridger (talk) 17:54, 23 July 2019 (UTC)
I suspect the most frequent cause of this is that a page with a originally appropriate multiple issues template, has had some of the issues removed. I've done this hundreds of times, but I've only thought once or twice to remove the multiple template also. Now that I see it's posing a problem, I'll do this, but it would be more practical do do this by a program. DGG ( talk ) 17:02, 26 July 2019 (UTC)
A smart {{Multiple issues}} that behaves as if it's not there when there's only one issue would be the best I feel. If not, a WP:BOTREQ could be done. Headbomb {t · c · p · b} 21:09, 26 July 2019 (UTC)
I created a prototype Lua module here: Module:Sandbox/MarioGom/Multiple issues. This will take two parameters. If the first parameter contains a single or no template, it will return the first parameter. Otherwise, it will return the second, which would be the wrapped version. I'll try to get this prototype to a full template version. Should I create it on Template:Multiple issues/sandbox or somewhere else? Best, --MarioGom (talk) 23:42, 26 July 2019 (UTC)
Phil Bridger, DGG, and Headbomb, what do you think of the module that MarioGom has created? Sorry for the days of delay; I just thought of this after removing another non-multiple occurrence of the template. Nyttend (talk) 12:02, 3 August 2019 (UTC)
Unfortunately, the approach MarioGom has taken here doesn't actually work, because Lua modules get their input post-template-expansion and thus don't see any curly braces to check. * Pppery * it has begun... 14:19, 3 August 2019 (UTC)
:-( In that case, is it time for a bot request? Nyttend (talk) 19:06, 3 August 2019 (UTC)

Disclose the editors who are enrolled over Wikipedia Library

No.∯WBGconverse 15:14, 9 August 2019 (UTC)

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

A few months back, I sought for a L'Harmattan article over en-wiki RX. Now, L'Harmattan is a TWL partner whose subscriptions gets processed from fr.wiki. I (till date) have not come across any need to access any of their resources and thus, did not intend to consume one account for accessing a single resource (it seemed unethical to me) and per a conversation with Nikkimaria, sought for folks over fr.wiki, who have access to it. But, I failed to reach a single user, who had a subscription to Harmattan. One had his user-box, despite expiration of the subscription whilst one did not choose to reply. Another, (who was pinged by the one with expired-access), did not choose to reply either. Per subscription-counts, it was clear that ample people had access to it, but I had no scope of knowing whom to contact other than those, who self-disclosed. RX did not help me either and at last, Sam asked me to proceed towards consuming one account for the sole purpose of accessing about two pages, which is a highly inefficient and non-optimal way of doing things.

I (thus) propose that there be

a public list of all editors who are granted access to any resource from TWL

so that they can help out fellow editors within rational limits. All applicants (including myself) are feeding on a scarce community-resource and I am unable to see any reasons for not being radically transparent, in this regard.

FWIW, I'm not seeking for any retroactive change which might infringe on already signed legal agreements and all that. I'm arguing for the implementation of this proposal for all new requests and renewals.

Thoughts and opinions on the proposal (esp. about reasons (if any) to maintain the current privacy) are welcome:-) ∯WBGconverse 15:58, 31 July 2019 (UTC)

Transcluded to Wikipedia talk:The Wikipedia Library. * Pppery * it has begun... 16:13, 31 July 2019 (UTC)
  • I like this idea. I think it helps with the transparency of TWL and allows more member-to-member resource sharing that doesn't have to bottleneck through the very busy TWL folks. Jessamyn (talk) 16:37, 31 July 2019 (UTC)
    • I'm not 100% sure about this. Shouldn't it be an opt-in list like WP:RX? On the RX, me and others have listed what resources they have access to, whether or not affliated by the wikipedia library. The only reason why I'm hesitant because what if some editors do not want to be on this list? What if they prefer not to be bombarded with emails asking for help for a resource they have access to? If it's opt-in, sure. Then it'd be a list of who has access to what and who don't mind helping others out :) --MrLinkinPark333 (talk) 18:04, 31 July 2019 (UTC)
      When you are accessing a community-resource, you shall be prepared for receiving such requests of assistance. Whether to process them is obviously at your discretion but as far as I have seen, most of the people are nice and collaborative enough to help out others:-) I also disagree about your assessment of probable bombardment, in light of the volumes of request at RX (which I've been patrolling for long). ∯WBGconverse 18:26, 31 July 2019 (UTC)
      Well, this is before this idea comes up. I'm just listing a possibility of what could happen. Whether it does or not, we'll see. --MrLinkinPark333 (talk) 19:14, 31 July 2019 (UTC)
  • Hmm, the issue with that is that it's a retroactive change in the written out expectations. So I'm happy to be on such a list (I hadn't realised there was also the shared resources list, so I've added myself there). Whether it's fair to require that for all, despite being community licenses...I'm not sure. I'd certainly be in favour for such for any future granted accesses. I have a 2nd concern - people are going to always go for those on the top or bottom of any such list, which means certain editors are going to face way more requests. Is there a way to randomly shuffle them around periodically? Nosebagbear (talk) 18:33, 31 July 2019 (UTC)
    Regarding Nosebagbear's second concern, randomizing the list might help; Mr. Stradivarius' Module:Random as employed on this page for example could be used for this. Jo-Jo Eumerus (talk, contributions) 18:44, 31 July 2019 (UTC)
    Nosebagbear, I'm not seeking a retroactive change. I'm arguing for the implementation of this for all new requests and renewals. Probably worth clarifying in the main post? ∯WBGconverse 18:56, 31 July 2019 (UTC)
    @Winged Blades of Godric and Jo-Jo Eumerus: - ah, that looks fine then, and a great potential solution Jo-Jo. I'd certainly support such a change unless someone comes up with another major issue. Probably worth clarifying in the proposal, though i imagine most current holders would be happy enough to sign-up as well. Nosebagbear (talk) 19:07, 31 July 2019 (UTC)
    :-) Agree that current access-holders can jump onto the list per their individual discretion. ∯WBGconverse 19:10, 31 July 2019 (UTC)
  • One additional question, perhaps it sounds a little silly: When one enrolls in TWL, is it OK under their contractual agreements to access sources on someone else's behalf? Jo-Jo Eumerus (talk, contributions) 18:38, 31 July 2019 (UTC)
    Jo-Jo Eumerus, the relevant portion of the ToS (of WMF-Library-platform) states:-

    Please note that in order to access an individual publisher’s resources, you agree to that publisher’s terms of use and privacy policy. Additionally, your access to publisher resources through the Wikipedia Library is accompanied by the following terms.

    Your access allows you to search, view, retrieve and display partner content (that is, content that requires an account to access) from publishers; to electronically save partner content; and to print out single copies of partner content.

    You must agree not to share your usernames and passwords for access to publisher resources with others.

    Your access to publisher resources does not allow you to mass scrape or mass download restricted content from publishers; to systematically make printed or electronic copies of multiple extracts of restricted content available for any purpose; to data mine metadata without permission, in order to use metadata for auto-created stub articles, for example; or to use the access you receive through the Wikipedia Library for profit by selling access to your account or resources to which you have through it.

    I have checked the ToU of ample publishers (who are in the platform) and none disallows accessing sources on someone's behalf. They mostly regurgitate the above stuff in slightly different forms. ∯WBGconverse 19:01, 31 July 2019 (UTC)
  • Support. I actually never really looked into WP:TWL before WBG posted on my talk page to inquire about my thoughts. I just applied to get access to JSTORE now. This seems a bit different in nature than WP:RX because it's a paid service to Wikipedians. I don't think it's unreasonable to ask them to potentially share the economic benefits with users. If it is deemed neccesary, the list can be opt-in, but do remember that these individuals (like potentially me in the future) aren't paying for these benefits rather than the library is on their behalf to create a better encyclopedia. We're a collaborative project, and I think it all the better for TWL to simply reflect that in some way. –MJL ‐Talk‐☖ 20:43, 31 July 2019 (UTC)
  • I thought this was already publicly made known - https://wikipedialibrary.wmflabs.org/activity/ - the applicants and the successful ones appear to be marked on the TWL page - so it should only be a matter of putting that data together but keeping track of expiry and maintaining the list is probably not a fun job. Maybe a software feature request for the Library Card Platform website would work. Shyamal (talk) 07:21, 1 August 2019 (UTC)
    Shyamal, that is an opt-in list and only tracks the last 50 events over the platform, pending which they are (probably) removed.
    Account coordinators regularly email the users whose accounts are nearing expiry to inquire about whether they still need the resource, in which case they are renewed or else, the account locked and allotted to someone else. So, they are already tracking expiry and relevant stuff. ∯WBGconverse 07:30, 1 August 2019 (UTC)
  • The plans for a Wikipedia_Library_Bundle would seem to address the inefficiency of consuming an account for a brief specific need, though I don't know which or how many providers are ready to sign up for that? AllyD (talk) 08:34, 1 August 2019 (UTC)
    AllyD, those are plans (that have been already in the pipeline for over 2 years) and per safe estimates, will take another few years to be implemented. Whilst that would eventually address some of the root problems, do you have any objection to the current proposal? ∯WBGconverse 09:03, 1 August 2019 (UTC)
  • Something I saw earlier this week indicates to me that some degree of broad rather than user account-specific access rights may be introduced soon, but I know no more than that. To the extent that access remains account-specific, the pre-Library Platform request method did involve public on-wiki record (e.g. [3]]) which, though not capturing the final steps of publisher registration and activation, was implicitly available to help another user seeking someone who could obtain a particular resource. I wouldn't think it too onerous a build to extend the Library Platform with a query on publisher to select contact details of one random user (to spread the load); though, trends in privacy legislation may mean this would have to be opt-in, despite it being a community resource which previously had on-wiki request lists. AllyD (talk) 08:51, 2 August 2019 (UTC)
    AllyD, I saw the phab-ticket but given how TWL has technically matured over the years, am not optimistic at all. ∯WBGconverse 16:01, 2 August 2019 (UTC)
  • Hi all, I work on The Wikipedia Library program at the WMF. I just wanted to clarify the situation from our end, explain why this isn’t a feature we implemented, and provide an update on our plans.
As a first point, displaying a list of users approved for access via the platform is technically feasible to implement on the Library Card platform, in any number of different ways: randomly ordered, opt-in, opt-out, you name it. There are a few reasons we haven’t shared such a list for each publisher in the past, however. The first is that for many publishers we simply don’t have an accurate list of users who actually have access - while we know who we’ve approved for access, account setup has historically been a multi-step process in which users might not finish setting up their accounts. We also haven’t been able to record a clear picture of how long any individual’s account lasts, some require renewing yearly, others are indefinite, others end on a set date, depending on the publisher - it’s not as straightforward as it might seem. This unclear picture of who has access meant that showing a list of users with access was difficult, so it wasn’t work we pursued.
We also prioritised privacy concerns on this tool, in the Terms of Use (approved by WMF Legal) and the NDAs signed by coordinators, and in allowing users to apply via email where necessary to preserve their privacy. Additionally, facilitating the sharing of individual resources is something I wouldn’t feel entirely comfortable with given how concerned many publishers are with sharing this access freely in the first place - importantly, we don't pay for publisher content, it's all provided by donation. The reason we have account caps for most publishers is that they’re understandably hesitant to give access to their resources out for free. Additionally, the specific terms of use for some publishers do place restrictions on sharing of content. Finally, due to their local context, some users may not be comfortable receiving requests for full-text content - see the final bullet under ‘Copyright tips’ at WP:RX.
I appreciate, though, that a limited number of accounts per-publisher introduces issues when we’ve either filled the list or you only want one or two resources. I’m happy to say that the more comprehensive solution to this problem (as alluded to above by WBG and AllyD) is finally right around the corner! While the development on authentication-based access and the Library Bundle was unfortunately delayed for quite some time due to legal discussions, we’re now moving ahead with technical implementation and are currently scheduled to be up and running before the end of the year. Under this system more than half of our content will be immediately accessible to everyone who meets TWL’s activity criteria (500 edits, 6+ months editing, 10+ edits in the past month) without manual approval or a fixed cap on the number of accounts. This, along with a more streamlined proxy-based process for many other publishers, should mean that access is more plentiful and you should rarely feel worried about only needing a small number of resources.
In the meantime, as Xaosflux points out above, we do have userboxes/categories for most publishers which users can place on their user page to add them to the relevant tracking category and opt into marking themselves as being available for queries. There’s also WP:RX if you’re requesting individual resources. I hope that helps, please feel free to ping me if you have any questions. Samwalton9 (WMF) (talk) 18:19, 2 August 2019 (UTC)
Samwalton9 (WMF),
The first issue of multi-layered-approval is problematic, indeed. May-be necessitate that once an editor gets his/her access, he/she needs to confirm that over through email? Unless he/she confirms, we send periodic (monthly/bimonthly?) reminders to the users? Obviously, an user can play around that because we have to take his/her words at face value but that would be peak-ABF-esque.
Now, an account lasts for a specific time, which's unique to a part. resource across all applicants. The coordinators often knows this span, too and send mails, a month or two before our access is to end, inquiring about whether we still need access or our account can be locked and re-allotted to someone else. Do you enter into agreements w/o specifying all these details? How does the process of enrolling a partner plays our internally?
Additionally, the specific terms of use for some publishers do place restrictions on sharing of content. - Evidence, please.
Some users may not be comfortable receiving requests for full-text content - see the final bullet under ‘Copyright tips’ at WP:RX - One can take himself out of the list and, as I said, nobody can compel anyone to provide resources.
We also prioritised privacy concerns is not a reasoning tool - I'm asking for the reasons behind the prioritization, over here. ∯WBGconverse 19:37, 2 August 2019 (UTC)
  • Oppose The Wikipedia Library (TWL) doesn't know whether an editor has access to a resource through TWL. TWL knows when they offer an editor access, but, depending on the partner, may not know if the editor followed through and activated an account with the partner. TWL doesn't know if the editor has retained any special url required to access the partner, or remembers or can recover their password. TWL doesn't know if the access has been terminated. In several cases TWL has contacted me to advise me that my access will lapse if I don't respond, when in fact the partner expired my access years earlier.
TWL access is widely available for the asking. Most subscription expire after a year (Miramar after just a few days), after which I beleive the subcriptions return to the pool. The 15% or so of partners who are routinely waitlisted (AAAS, Cambridge, Science Direct, Sage, ...) are mostly readily available through reasearch university libraries, and thus through Resource Request (RX). If an editor is so public-spirited that they hesitate to consume a plentiful resource by signing up for a subscription, then they should sign up for the account anyway, self-disclose that they have it, and offer at RX to use it on behalf of anyone else who needs it, rather than imposing that condition on all subscribers. If it ain't broke, don't fix it.
I volunteer at RX, where I can choose what requests to read and respond to. I would not sign up for TWL resources if WP:CREEP caused TWL to place me on a public list of people to contact about that resource. I have no interest in searching databases for someone who doesn't qualify for access through TWL, or is too lazy to apply for access through TWL, or is on a fishing expedition for something that I don't believe would improve the encyclopedia. Using a community resource to improve Wikipedia should continue being sufficient reason to grant access to that resource, without the editor having to be on the receiving end of unwanted requests for help. Transparency should be balanced against an editor's right to privacy. --Worldbruce (talk) 19:06, 2 August 2019 (UTC)
  • Oppose - Basically Worldbruce and Samwalton9 have covered everything I would have said. There might be room to improve the layout (simplification, clarification, etc.) of the TWL application pages especially to increase crosslinks between WP:TWL and WP:RX to advertise WP:RX for those in a situation like Winged Blades of Godric (WBG) where research assistance is required but ethical concerns prevent the researcher from signing up with TWL, but in my experience the coordinators are very good at directing requests for scarce sources to RX where assistance is generally available. The privacy issues raised above are likely to be common with some library-oriented folks (e.g. at TWL) for historical reasons. -Thibbs (talk) 14:25, 3 August 2019 (UTC) (Disclosure: I am a former TWL coordinator. -Thibbs (talk) 14:25, 3 August 2019 (UTC))
    Thibbs, I fucking know where the RX is. Have provided ample content to users, from there and received some. In the described case, nobody at RX managed to access the resource. I contacted Nikkimaria (the coordinator for the resource) who merely pointed me to fr.wiki user-cat and said that she can't help more. Also, the linked case is too hyperbolic to be relevant. ∯WBGconverse 16:46, 3 August 2019 (UTC)
    OK, calm down. I understood your proposal of a public list to be a general proposal intended to help all editors here at Wikipedia including those who don't know where RX is. I understand that you have specific needs for specific sources in the case you described, but as your proposal was phrased as a general request I didn't think you were asking specifically for yourself. In your specific case I would recommend the following: (1) sign up for an account despite the ethical concerns, (2) carry out whatever research you need, and then (3) restore the ethical neutral point by alerting the coordinator that you wish to relinquish control over your account. Is it inefficient, sub-optimal, and generally clunky? Sure. But at least it protects the privacy of the other users who might wish to avoid unpleasant demands from others. -Thibbs (talk) 17:34, 3 August 2019 (UTC)
    My core point is that if you are concerned over privacy to such an extent (the proposal allows for optional opt-outs but with a public entry), you have no business to claiming community resources.
    As far as I have seen, once people access RX, they know about TWL and vice-versa.
    I have since got that resource (via guest inst. access and using stuff, completely outside of wikimedia) but that's not much relevant and it intends to serve as an example case. ∯WBGconverse 18:03, 3 August 2019 (UTC)
    Worst case scenario: the accounts expire within a certain time period and the account gets cycled back into the community. I understand your perspective, but I don't think it's accurate to characterize the resources as a non-community resource. -Thibbs (talk) 19:52, 3 August 2019 (UTC)
  • Oppose: I'm afraid I have to oppose this resolution. As someone who uses TWL as a resource, I'm not comfortable being put on a presumably-public list for dissemination, simply because I use TWL. Moreover, it's a rather simple process to apply; it just takes some patience for one's submission to be processed. Thibbs, Worldbruce, and Samwalton9 more or less encapsulate my other thoughts on this matter. —Javert2113 (Siarad.|¤) 15:04, 3 August 2019 (UTC)
    Not much sure as to why you have the access, either. ∯WBGconverse 16:46, 3 August 2019 (UTC)
  • Oppose - I don't think WBG's initial concern is unreasonable, but find the arguments by Samwalton, etc. persuasive. I also don't actually see that there's a problem that needs fixing at this point. There is no case here where someone wants access to something and can't have it. WBG can have access to the resource in question (at least as far as I understand), but would prefer not to take an account for such a limited purpose. I'd be more sympathetic if we had a situation where someone wanted access, all the accounts were taken, and the people who have opted into using the user category were unresponsive. Especially if someone is themselves active at RX, I see no problem with them requesting whatever accounts they want. I wouldn't be opposed to making the user category opt-out rather than opt-in, though, since I suspect the majority of people who have access wouldn't mind being listed. — Rhododendrites talk \\ 18:15, 3 August 2019 (UTC)
  • Oppose. Agreed that it doesn't make much sense to require you to consume an account only to access two pages, but unless TWL indicates having the bandwidth to implement the extra reporting steps, I view this as scope creep or, most charitably, a nice-to-have. Last I recall, TWL was in need of more volunteers, not more to put on their plates. Additionally, it's really exciting to hear about recent progress towards proxy-based access (haste the day!) which would obviate the need for manual transparency. If the dev time is zero sum, that definitely seems like the area with greatest impact. czar 19:16, 3 August 2019 (UTC)
  • I don't have an opinion either way: but if you are going to do this, just make sure you have an 'accurate' list of currently enrolled people, for example I no longer have any access from TWL provided resources. — regards, Revi 07:19, 4 August 2019 (UTC)
  • The TWL could theoretically grant shorter-term access like a month-long access if scarcity of the resource really became the problem. Most editors applied for the access because they want to write an article which may have relevant material in respective database/library, that does not mean they're suddenly ready to became a librarian. The proxy model used by most libraries could also work, just that I don't think the partners would agree to that. SFPL worked out a license model with NYTimes that grant three day access to their patrons and can reapply after, which could also be of reference to what TWL might work in the future. viz ✦ 01:55, 6 August 2019 (UTC)
  • As a WPL account coordinator, I've had two or three users apply for accounts but express discontent over having to release any of their personal details to WPL volunteers. While a list like this wouldn't necessarily expose such details, a list like this would likely discourage such users from signing up. This may or may not be a reason to oppose this proposal, but I wanted to add my evidence that privacy concerns are important to people with WPL access. I personally do not wish to make a !vote. Smmurphy(Talk) 14:10, 8 August 2019 (UTC)
  • I don't think anyone should be required to disclosed anything, but it would be good to have voluntary disclosure of those things. Headbomb {t · c · p · b} 14:16, 8 August 2019 (UTC)
  • Oppose - I agree with User:Headbomb and others above. Users with access should be encouraged to disclose, but it should not be enforced. --Hecato (talk) 14:45, 8 August 2019 (UTC)
  • I'd be opposed to requiring disclosure. For some users in repressive countries, strictly regulated social groups, etc, just accessing certain information sources may be illegal, dangerous, or embarrassing. On the other hand, providing an easy way for users to find people with access to these databases seems like a good thing and promotes the goals of wikipedia, so I'm all for it, on a voluntary basis. I'd even make it easy to opt-in, like a "please list me in the directory" checkbox when you sign up (but which defaults to not). I've got JSTOR, Newspapers.com, and Rock's Backpages access. The later, of course, being a highly subversive organization. -- RoySmith (talk) 14:47, 8 August 2019 (UTC)
  • Oppose per several of the previous oppose votes. While the TWL partner accounts are a community resource, my volunteer time is not: whether I choose to make myself available to handle such requests must be, like all other contributions on these projects, entirely up to me. And, frankly, the sheer entitled attitude exhibited in some previous posts make me question whether I would want to subject myself to that hassle.
    That being said, until the mentioned Library Card Platform changes address the root problem, I think we both could and should do much to encourage more editors to volunteer to make themselves available for such requests and to make it easier to contact them with a request. My gripe above aside, I have always been happy to help anyone who asks—using both the TWL partner services I have access to, my personal library, and any physical library or other resource I can access—but I haven't been conscientious about adding the relevant user boxes or watchlisting WP:RX.
    I think we should use either mass-message or targeted email based on TWL account info to send out instructions for and encouragement to add userboxes for all resources an editor can access. The idea mentioned above about using Module:Random and a template to easily get a list of, say, five random editors with access to a given resource willing to handle requests. Maybe we could even get a bot to maintain a frequently updated list of "currently active editors with access to resource X" (ping Xaosflux) so one wouldn't have to waste time placing requests with editors who aren't currently editing, or who are on Wikibreak but haven't removed the userboxes. The Library Card Platform user interface and coordinator acceptance emails could surface instructions for adding the relevant userboxes on acceptance to a given resource, and explain why it is important to do so (the nominator's quandry isn't unique, but it's not something most people will automatically think of unless prompted).
    I also think more explicit guidance on what are permissible uses of partner resources would make more people comfortable volunteering to handle such requests. On the one hand we could clear away the nonsensical concern that partners might be pissed if you access their service on someone else's behalf (they won't be, and wouldn't have a leg to stand on if they did: this is knowledge not anything copyrightable we're talking about). But on the flip side I imagine a lot of them (but not necessarily all!) would react badly if you send someone a PDF copy of an entire journal article (just because academics at a university do that all the time does not mean we can or should get away with it). And if you can't just send someone the whole article, that means most requests will be some level of research, which is complicated and time-consuming (relative to just grabbing a PDF) and may not be in a field or area that you are familiar with. Clear and explicit guidelines on this will help steer the expectations of both requester and those trying to help, and will make borderline requests less uncomfortable for those receiving them.
    And just to note… I've never had any problem getting help accessing a resource in a TWL partner service. In my experience almost all editors on the project are happy to help in any way they can, and will bend over backwards to do so if it all possible. And that includes outright "Can you research this for me?" type requests! Wikipedia editors on the whole are straight awsome people. --Xover (talk) 09:57, 9 August 2019 (UTC)
Yes; yes you are. ——SerialNumber54129 11:01, 9 August 2019 (UTC)
Now why would you bring sexual orientation into this? Gråbergs Gråa Sång (talk) 15:09, 9 August 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Misspelled filename

It should be File:My blood is full of airplanes.jpg instead of File:My blood is full of aiplanes.jpg. Please move file to correct name with redirect and mark the redirect with {{R typo}}. — Preceding unsigned comment added by Monniasza (talk • contribs) 11:32, 11 August 2019 (UTC)

@Monniasza:  Done. Next time, please use {{rename media}} to request that a file be moved. --AntiCompositeNumber (talk) 11:40, 11 August 2019 (UTC)
My hovercraft is full of eels. --Redrose64 🌹 (talk) 16:42, 11 August 2019 (UTC)

Combine discretionary sanctions notices

Some articles end up with multiple discretionary sanctions notices on their talk pages, when multiple reasons apply. Talk:2019 Dayton shooting is one example of the messy, confusing, and poorly readable outcome. I would suggest combining them. Like having a single template with one or more reasons plugging into it, the way Template:Multiple issues works. Sakkura (talk) 19:23, 10 August 2019 (UTC)

Some of them have specific sanctions, eg Template:ArbCom Arab-Israeli enforcement. I'm not sure what's confusing about having several on a page. --Doug Weller talk 18:10, 11 August 2019 (UTC) reping @Sakkura: --Doug Weller talk 18:12, 11 August 2019 (UTC)
A container box like we have when multiple wikiprojects would not be bad, it can lead off "This article is subject to multiple discretionary sanctions:" and include each notice. --Masem (t) 18:14, 11 August 2019 (UTC)
The DS talk page banners are technically useless anyway. Per WP:Discretionary_sanctions#Awareness_and_alerts, editors may only be sanctioned under DS if they are technically "aware" DS applies, and technical awareness is defined with various criteria. Working on an article that has a talk page DS template banner is not one of them. So in reality, these things are entirely FYI but for application of current DS procedure their very existence is a nonissue, and therefore so is there polish and form and content. All that said, support modification as follows. If the presence of the moot but FYI template text ever makes any difference to anyone, then that is the sort of person who is likely to click a link to see that text. So I think I agree, it would be nice to have a simple bannershell that lists the topics, with links to pop up the specifics for each. The reality, though, is few people will read them no matter what they say and the folks who take enough care to do so are unlikely to be source of the problems. So.... sure, clean 'em up. But it probably doesn't make a ton of difference either way and as a technical matter... they don't matter. NewsAndEventsGuy (talk) 18:17, 11 August 2019 (UTC)

Add a warning for broken/orphaned reference names before saving edit

I think there should be a warning at the top of a preview of an edit if there is a broken reference name. I have been spending a lot of time going through the huge backlog of pages with broken reference names, and have found that many of them occur when someone copy/pastes text from one article to another and forgets to grab the parent reference. Also, there are some cases where someone mistakenly puts the name of a book or publication in the <ref name> parameter. I think most people don't scroll down to the bottom of the page to double-check the reference section if they preview their edit, and this could solve the problem. It would only take another minute or two for the editor to find the parent reference in this case, whereas when someone else has to hunt down the reference a year later, it can take a long time. I wasn't sure if this was something I should post about here or on Phabricator, so let me know if there's a better way to proceed. Secundus Zephyrus (talk) 19:29, 24 July 2019 (UTC)

A warning would be a very good idea. This has been a problem for years and there has been some progress. AnomieBOT's OrphanReferenceFixer manages to fix many of these errors or we would be inundated. See the log here. For a while there was another bot, ReferenceBot, which would leave messages on editors' talk pages about errors AnomieBOT couldn't fix. However it has not been running since Feb 2017. StarryGrandma (talk) 04:15, 25 July 2019 (UTC)
+1 Headbomb {t · c · p · b} 04:32, 25 July 2019 (UTC)
This would be a great improvement. Auto-detection of failure to include the pesky "/" at the end of <ref name> where needed would also help. RobDuch (talk·contribs) 07:01, 25 July 2019 (UTC)
Agreed. This is especially important when editing a section (not the whole page where all refs are visible) and forgetting to check for other sections where refs may become orphaned. ComplexRational (talk) 19:42, 29 July 2019 (UTC)
ComplexRational, I hadn't even thought of that possibility, that's a great point. --Secundus Zephyrus (talk) 20:29, 29 July 2019 (UTC)
All great ideas above. Does someone with technical background know how these warnings above the preview window are generated in Lua? --Hecato (talk) 10:23, 25 July 2019 (UTC)
Nyttend, that's a good point. I wonder if it can be worded in a less-scary way that might strike a balance between the newbies and the experienced editors? The reason I ask is because I've come across pages with broken references going back years, and I think if an experienced editor got a notification of an old error, they might be more likely to try to fix it if they have the time. --Secundus Zephyrus (talk) 18:55, 11 August 2019 (UTC)

Proposal to use a CentralNotice to publicize photo competition

There's an open proposal on Meta to run a CentralNotice banner on Wikipedia and certain other Wikimedia projects from September 1 to September 30 in order to publicize the Wiki Loves Monuments photo contest, as has been done in previous years. Please comment on the proposal at m:CentralNotice/Request/Wiki Loves Monuments 2019. --Yair rand (talk) 06:10, 14 August 2019 (UTC)

Civil parish bot

I started a discussion at Wikipedia:Bot requests#Civil parish bot to have a bot create the missing civil parishes in England (about 700) but there were a few problems, namely that my instructions weren't clear enough, that it would be violating my creation restriction (not so) and that they might not be notable (not so, civil parishes as opposed to ecclesiastical parishes are legally recognized administrative division per WP:GEOLAND).

I have created User:Crouch, Swale/Bot tasks/Civil parishes (current)/Simple which is the current model, there is also User:Crouch, Swale/Bot tasks/Civil parishes (current)/Coded and User:Crouch, Swale/Bot tasks/Civil parishes (current) which provide more instructions and some arguments for an against for bot created articles at User:Crouch, Swale/Bot tasks/Civil parishes (current)#Process.

There are 2 questions here, who has the understanding to program such a bot and are there any other things that need to be improves/changed to ensure that this works correctly or to otherwise improve the articles.

It would be good if eventually we could do the same thing for places in other countries to but we'll start with England for now. Crouch, Swale (talk) 12:02, 5 August 2019 (UTC)

I call WP:OTHERPARENT on this: although Crouch, Swale has linked Wikipedia:Bot requests#Civil parish bot, they fail to link the other places where they've requested this, such as Wikipedia talk:WikiProject England/Archive 4#Bot created articles. --Redrose64 🌹 (talk) 20:53, 5 August 2019 (UTC)
Not quite WP:FORUMSHOPing more than "wants to do something, but doesn't know what to do, so trying everything and seeing if something sticks". Truth is, no one seems interested in this, especially because of the lack of a clear example, with clear bot logic. And until those are in, interest will remain low. Headbomb {t · c · p · b} 03:19, 6 August 2019 (UTC)
  • Comment I'm not sure that this is the most necessary bot in the world (I don't believe that the US counties were created by a bot, for example), but nor do I adamantly oppose it on principle if all of the kinks get worked out. – John M Wolfson (talk • contribs) 00:34, 7 August 2019 (UTC)
  • Weren't the US counties created in the same way as the settlements, it looks like Ram-Man didn't have a separate account for the bot until later [4][5]. Anyway indeed the bot shouldn't be approved until we're sure its OK. Crouch, Swale (talk) 17:15, 8 August 2019 (UTC)
  • Based on my instructions does anyone have the ability to construct a code for the bot? If that can be done then we'd be going in the right direction to see if there's consensus. Crouch, Swale (talk) 08:00, 10 August 2019 (UTC)
    I've notified BON. Crouch, Swale (talk) 11:07, 13 August 2019 (UTC)
    @Crouch, Swale: I might be able to code such a bot, but I need some more info. Your /simple, /coded, and (current) are confusing. Can you please create: 1 full fledged example article (what the bot should be able to produce) and 1 "shell" with the content that would be common to all of the articles? (Like every single one will have == References == and {{Reflist}} DannyS712 (talk) 11:13, 13 August 2019 (UTC)
    @DannyS712: I have created User:Crouch, Swale/CP example which is an example "full fledged article" (although the categories obviously wouldn't be disabled). In the User:Crouch, Swale/Bot tasks/Civil parishes (current)/Coded example the words that aren't in "" are the content that would be common to all articles. In other words all articles will have the text "The parish touches" but the names of the parishes will be variable. The example given (Rattlesden) is one that already exists but illustrates how it would be created if it didn't exist. Note that I have removed the notes from the coded one but they'll stil be useful to the bot operator. Crouch, Swale (talk) 11:35, 13 August 2019 (UTC)
    @Crouch, Swale: Okay. So I see it as a shell that needs the following parameters:
    1. Name (without disambiguation)
    2. Region
    3. Centre point from City Population
    4. District name
    5. County name
    6. Population
    7. Area
    8. District name (with disambiguation)
    9. Touching parishes
    10. Number of listed buildings
    and, for each article, the title at which it should be located. It seems fairly straightforward, as long as all of that information can be retrieved in a usable format. Do you have a good way to get that data? If so, I'd be willing to fulfill the bot request, provided that there is indeed consensus for it. DannyS712 (talk) 11:58, 13 August 2019 (UTC)
    @DannyS712: these are explained at User:Crouch, Swale/Bot tasks/Civil parishes (current)/Simple but I'll add a bit here.
  • Name (without disambiguation)
    If the title isn't disambiguated then this will be the same as the title (as with the Rattlesden example) if the title is disambiguated (such as Boxford, Suffolk) then that will need to be removed from the "official_name" "civil_parish" and the bold face at the beginning. In other words for the Boxford, Suffolk example all 3 would just be "Boxford" not "Boxford, Suffolk" that is to say the name used on City Population.
  • Region
    The name of the region given in City Population which is not linked in the infobox for example "East of England" or "North East".
  • Centre point from City Population
    This is the middle (centre) point of the area given for the parish at City Population, if its not possible for the bot to get that then the coordinates from the Ordnance Survey linked data can be used. This is also used to measure the distance from the county town.
  • District name
    The title of the district (which might be disambiguated) for example linked as Babergh (and Category:Babergh) if not disambiguated but Arun (and Category:Arun District) or Stafford (and Category:Borough of Stafford) if it is. Remembering also if its a unitary authority.
  • County name
    Ceremonial county thus for Olney its Buckinghamshire not Milton Keynes.
  • Population
    The 2011 figure given by City Population, which is omitted if City Population doesn't give any data (mainly for parishes of less than 100) also noting that the sentence "In 2011 the parish had a population of X" is removed.
  • Area
    When you click on an entry at City Population it gives the area (which is 13.2 for Rattlesden). This is only added to the infobox.
  • District name (with disambiguation)
    As with the district name above this means that the district article (and/or category) might be disambiguated as explained above, if the article is then it needs to be piped in text as explained.
  • Touching parishes
    The names of the other parishes the parish touches (which may be disambiguated) the bot works out the correct article by checking the coordinates of the target article or if it can't just linking to the unqualified name which I can fix.
  • Number of listed buildings
    From the listed buildings site (although the English Heritage site might be a better option but can be discussed later) namely by finding the parish from here by region then county/unitary authority then parish (and the coordinates for the buildings can be compared to those from the OS to ensure the correct parish has been found). Crouch, Swale (talk) 18:56, 13 August 2019 (UTC)
    @Crouch, Swale: I understand what they stand for. My question is if you have a spreadsheet or other place where all of the applicable data is. I'd prefer not to manually input the 2011 figures, etc. DannyS712 (talk) 03:14, 14 August 2019 (UTC)
    @DannyS712: all of the 2011 figures are at City Population by region, at South East, London, North West, East of England, West Midlands, South West, Yorkshire and the Humber, East Midlands and North East on the "Population Census 2011-03-27" row eg for Workington its 25,207. Those (such as Wythop) don't have population data but do still have the area (if you click on the area). Crouch, Swale (talk) 07:22, 14 August 2019 (UTC)
    @Crouch, Swale: for South East, I made User:DannyS712 test/parish.json, which has the data from the link you posted above. But, making that took a lot longer than I thought. If you want me to help with this, I need all of the data in one place (not population from one source, coordinates from another, etc) in a bot-readable format (ideally json). --DannyS712 (talk) 08:59, 14 August 2019 (UTC)

Debates regarding ongoing issues

Hi everyone, I just wanted to propose for a debate section in the talk pages of ongoing issues like the Hong Kong crisis article. This would enhance views from different people across the world and this would encourage boldness from people who previously feared editing hence bringing the vision of Wikipedia's 'Be bold'policy to a realization. Thank you -RazorTheDJ (talk) 19:45, 14 August 2019 (UTC)

Wikipedia is not a forum. I would think a debate section would be near the literal definition of a forum. --Izno (talk) 03:16, 15 August 2019 (UTC)
Yes, a talk page is not the space for a debate or any general discussion of the article's subject. However, if such a section is devoted to analyzing the viewpoints of sources with different biases and their worthiness of inclusion in articles, it may be a good idea (as long as it does not stray to personal opinions, in accordance with talk page guidelines). Those types of discussions are in the nature of a talk page. ComplexRational (talk) 09:24, 15 August 2019 (UTC)

Make Compulsive masturbation into article stub

Compulsive masturbation has diagnosis criteria, so it is encyclopedic. Please make article about compulsive masturbation which will replace redirect. — Preceding unsigned comment added by Monniasza (talk • contribs) 17:28, 14 August 2019 (UTC)

You can do it yourself! See Help:Your first article for advice and details. Anomie⚔ 11:14, 15 August 2019 (UTC)

Allow article cleanup tags in topic categories without a main article

Some topic categories do not have a main article. For example, the article documentaries redirects to documentary film, and so the Category:Documentaries does not have a main article. Instead, the body of the category has a stub-like article content. In particular, it had a biasing statement

which casts light on most documenteries - perhaps not what was intended. In any case, I simply added the {{where}} cleanup tag. That tag was accepted, but did not add the category into any cleanup categories. I suggest it should (for most cleanups), though I do understand this might require a different title, due to the way cleanups are counted.

An alternative, is to require every topic category to have an associated (possibly shared) article where all statements can be properly sourced.

Dpleibovitz (talk) 21:37, 20 August 2019 (UTC)

I am confused about the premise here... wouldn’t the article Documentary film be considered the main article for category:documentaries? Blueboar (talk) 22:00, 20 August 2019 (UTC)
No, that would be the main article for Category:Documentary film. However, Category:Documentaries reads like a set index article or disambiguation page - there are many kinds of documentaries, with film being just one of them. There really should be a separate (stub) article, where issues such as biasing (for all kinds of documenteries) be discussed in a balanced manner - a category is simply not the forum to do so. Nevertheless, I am loathe to simply delete the offending line as it does indicate what should go into such an article. Dpleibovitz (talk) 22:12, 20 August 2019 (UTC)

Watchlist-message on a sister project proposal

Posting, no objections - final follow up at MediaWiki_talk:Watchlist-messages. — xaosflux Talk 01:42, 21 August 2019 (UTC)

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

Initial note at MediaWiki_talk:Watchlist-messages#Sister_project_proposal

I don't know what the protocol or precedent is for whether sister project proposals should be listed in the MediaWiki:Watchlist-messages. Most sister project proposals have not gained much traction and are not especially Wikipedia-relevant. However, meta:WikiJournal has had >100 comments so far and I think is fairly relevant to Wikipedia. I think getting broad feedback is valuable so it might be worth a notice briefly. Previous locations of notifications listed at this link.

Questions:

  1. Should this sister project proposal be listed in the messages
  2. If so, is the wording appropriate?
  3. If so, what is the preferred time length?

Any opinions or ideas appreciated. T.Shafee(Evo&Evo)talk 03:34, 16 August 2019 (UTC)

@Evolution and evolvability: thanks for posting this here. Perhaps a little bit more in the message hook (what is the sister project going to do - and how is is relevant to the English Wikipedia?). Just FYI, on these if noone objects at all in about a week it will usually get posted. — xaosflux Talk 14:25, 16 August 2019 (UTC)
@Xaosflux: Thanks. a few possible alternative texts below aiming to keep to typical character lengths seen in past messages (longest recent notice):
  • Initial proposed text: A proposal for a new Sister Project is open for discussion
  • Alt proposed text1: A proposal for a new Sister Project to coordinate external peer review of content is open for discussion
  • Alt proposed text2: A proposal for a new Wikimedia Sister Project to coordinate external peer review of content via hosting open access academic journals is open for discussion Comment/support/oppose!
  • Alt proposed text3: A proposal for a new Wikimedia Sister Project to coordinate external peer review of content is open for discussion. This would help facilitate expert feedback for existing Wikipedia articles, provide a route for new wikipedia articles, and publish open access research articles.
Alt 3 is probably too long, but I included in case the wikipedia interaction info is useful. I'm happy for others to choose between which they think would be best (or combine/write and alternative). T.Shafee(Evo&Evo)talk 01:09, 17 August 2019 (UTC)
  • I would support this proposal. Also, I think this is already obvious, but just to be clear this would be only for English projects, right? I think having interlanguage notices would produce too much clutter. – John M Wolfson (talk • contribs) 04:12, 19 August 2019 (UTC)
@Evolution and evolvability: looks like we'll be posting this - I would like to tweak the verbiage a little bit. To clear things up a little - what is expected source of the "content" that will be on WikiJournal? (e.g. in Prop2 "coordinate external peer review of content" when placed here on enwiki, could be taken that Wikipedia content is going to be version-fixed, transwikied, reviewed, and republished). — xaosflux Talk 00:30, 21 August 2019 (UTC)
@Xaosflux: Good point. A main aim is getting articles from non-wikipedians that can be then copied to wikipedia (example). It also acts as a companion to WP:FA by getting outside review (via WP:JAN; example). T.Shafee(Evo&Evo)talk 01:11, 21 August 2019 (UTC)
@Evolution and evolvability: would A proposal for a new Wikimedia Sister Project, WikiJournal, to coordinate the collection and external peer review of new content is open for discussion. be accurate? — xaosflux Talk 01:23, 21 August 2019 (UTC)
@Xaosflux: Yes - that works well. Thank you for the external eye! T.Shafee(Evo&Evo)talk 01:33, 21 August 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikimania presentation videos as site notice

Would it be worth this year or subsequent years putting up a banner linking to the videos of presentations at wikimania? It might be a way of making it more broadly known the sorts of things that are going on 'behind the scenes' for readers who otherwise don't know how extensive the wikimedia community activities are. Might even inspire people to think about getting involved. T.Shafee(Evo&Evo)talk 02:29, 21 August 2019 (UTC)

I don't think listening to Wikimania speeches is a good way to get an accurate understanding of what's going on behind the scenes, and I don't think using a site notice is a good way to publicize such things either. --Yair rand (talk) 05:19, 21 August 2019 (UTC)
Evolution and evolvability, sure why not. Especially some of the Research sessions were really accessible versions of the paper, that should be very insightful to people that don't feel like reading the entire research papers. —TheDJ (talk • contribs) 07:30, 21 August 2019 (UTC)
Are they adequately subtitled? I am becoming increasingly frustrated by the increasing use of videos that are inaccessible to the deaf, whether as sources or for information. - Sitush (talk) 07:35, 21 August 2019 (UTC)
@Sitush: Sadly, I think the current subtitling is pretty basic (just youtube's machine-transcribed ones). Long-term the quality of the video and sound recordings will go a long way to making them valuable after the event, as well as making wmania:2019:Video easier to navigate (also relevant: meta:WikiProject_remote_event_participation @Daniel Mietchen, Hogü-456, Jane023, and Fuzheado:). This will be especially important if the WMF is serious about wanting to make remote participation feasible for those who can't afford to or choose not to fly to the conference. T.Shafee(Evo&Evo)talk 07:59, 21 August 2019 (UTC)
Well, thanks at least for letting me know. The YT machine translations are next to useless. - Sitush (talk) 08:02, 21 August 2019 (UTC)

Thanks for the ping. No I don't think a site notice is useful unless it is trimmed back to logged-in users, because I see the main value of Wikimania content as progress status reports and how-tos for various important internal projects that mean nothing to the wider community of readers and therefore only the keynotes would be more widely appreciated and you're better off putting just those (or associated WMF blogposts) in the site notice. I see a site notice as being for temporary consumption, whereas these important status updates are crucial markers in the "History of Wikipedia" that should be tracked. I think a separate Wikibase is necessary to track the Wikimania stuff (Commons/submissions/etherpad/Youtube) and maybe we need a "Wiki Loves Wikimania" for this. Jane (talk) 08:26, 21 August 2019 (UTC)

RfC: Add 'create an article' option in the interface

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
No consensus for the proposal (old or new). Voices were split; very slightly more supported the (new) proposal, on the grounds that we should be trying to convert readers into editors, but nearly as many opposed, on the grounds that creating an article is difficult for new editors, and will be discouraging as their first article is quite likely to be deleted, while at the same time creating more work for new article reviewers (at the three letter pages: NPP, AfD, AfC, and, of course, etc.). --GRuban (talk) 14:30, 8 October 2019 (UTC)

Should we add a "Create an article" button/link in the interface/sidebars? Headbomb {t · c · p · b} 02:04, 7 July 2019 (UTC)

The problem

One thing that always puzzled me is why we don't have a "create an article" button in the sidebars. Or similar. Imagine you want to get involved on Wikipedia, and you barely know a thing about it, but you want to create an article about say Hymenopterida, an insect superorder.

Tell me, how do you figure how to create that. There's nothing to guide you. If you search for 'create' in your interface, you have the option to create a book. There's nothing to create an article. There's no help link, no create button, no draft option, no tutorial, nothing. So, I propose we add a "Create an article" link/button to the interface, which would direct people to a landing page similar to

Non-registered Non-(auto)confirmed (Auto)confirmed Extended confirmed

Welcome to Wikipedia, the encyclopedia anyone can edit! Because you do not have an account, you cannot yet create articles directly in the encyclopedia. You must first register an account and gain experience as a Wikipedia editor.

Once you have a registered an account, the following pages will help you gain this experience

  • Help:Getting started, which has several tutorials and primers about Wikipedia conventions and policies
  • Help:How to edit, which explains how exactly to edit the encyclopedia
  • Wikipedia:Sandbox, a page where you can freely experiment without having to worry about breaking anything

After you have created an account, you will be able to create an article through the Article wizard, which will guide you through the process, and explain basic concepts like notability, verifiability, and what reliable sources are. At the end of the process, your article will be created as a draft, and experienced editors will review it. Be aware that the reviewing process currently has a ~7 weeks backlog, with 1,361 pending submissions waiting for review.

which 'tab' you would land on would depend on your user access levels, and we could customize the advice/information to target the experience level of the person landing on that page. Headbomb {t · c · p · b} 19:10, 7 July 2019 (UTC)

!Vote (old proposal, withdrawn)

This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.
  • Support as proposer. Headbomb {t · c · p · b} 02:04, 7 July 2019 (UTC)
  • Support. Sounds like a great idea that would help convert our readers into editors. The article wizard is an ideal place to direct new editors to, since it encourages them to use non-public-facing areas of Wikipedia (the sandbox, a user space sandbox, and the draft space) to create content. These areas are low-pressure "safe zones" where editors can get familiar with our editing tools (wikitext or the VisualEditor) without the pushback of being reverted after making a mistake. Hopefully, these zones help new editors learn the ropes and eventually become comfortable enough to participate in other areas of Wikipedia. — Newslinger talk 02:35, 7 July 2019 (UTC)
  • Oppose - Editors should not be creating articles before they know something how how to edit Wikipedia, what its aims and policies are, and how articles should be made. Adding a "create an article" link is only going to provoke a lot of badly written, poorly sourced, stub and sub-stub from people more interested in self-aggrandizement then in improving the encyclopedia. Let people spend some time here first during which they can learn the lay of the land and, in the course of it, learn how to create an article. Beyond My Ken (talk) 04:38, 7 July 2019 (UTC)
  • Oppose within the current framework. See my comment under discussion. Espresso Addict (talk) 05:12, 7 July 2019 (UTC)
  • Oppose At this age, Wikipedia should not be encouraging brand-new editors to create articles upfront; apart from the link being misleading because new editors and IPs cannot create articles technically. People should reasonably be conversant with wikitext and minor tasks until such time they intuitively find the way to create articles, that's the time they should do that. That process is an important learning curve and may takes days, week or months depending on the prior experience of the individual, but it does not matter. – Ammarpad (talk) 05:31, 7 July 2019 (UTC)
  • Oppose as premature. See my comment in the discussion section. Kudpung กุดผึ้ง (talk) 06:16, 7 July 2019 (UTC)
  • Oppose per above. We need to encourage the improvement of existing articles more than the creation of new crap ones. MER-C 11:07, 7 July 2019 (UTC)
  • Oppose per comments by Ammarpad above and Kudpung below. At the moment, the most direct way to create a new article comes either from first searching the wiki for existing references, or expanding upon a redlink, both good starting points for a new editor. MarginalCost (talk) 13:13, 7 July 2019 (UTC)
  • Oppose the existing procedure forces the person further along the learning curve before creating an article. Granted, possibly not far enough, but why make things worse?--Wehwalt (talk) 14:11, 7 July 2019 (UTC)
  • Oppose - AfC is drowning in unreviewed drafts. I don't believe NPP is much better off. Anyone who knows enough to be able to write a basic article, knows how to go about doing so (or ask how). Anyone who doesn't, shouldn't be having it made easier for them. Nosebagbear (talk) 15:28, 7 July 2019 (UTC)
  • Neutral - I support the sentiment/aim; there are probably people who could be great editors intimidated by the learning curve or where to look. But, and this might be because I've spent some time on Wikia lately (where there is a page in the interface for this), I fear this is likely to get people to start creating articles just because they can (i.e. not good ones) in a way that's likely to increase low-quality or speedy-able articles (and increase work for people involved in their maintenance) much more than it's likely to find good ones. - Purplewowies (talk) 16:33, 7 July 2019 (UTC)
  • Oppose – I agree with Ammarpad's and Nosebagbear's reasoning. – Levivich 16:36, 7 July 2019 (UTC)

!Vote (new proposal)

  • Support as proposer. I agree directing people to AFC directly isn't ideal, so instead I propose we direct them to a landing page explaining how to get involved in Wikipedia. Headbomb {t · c · p · b} 19:20, 7 July 2019 (UTC)
  • Oppose Neutral If anything, we should be taking steps to make it harder for brand-new editors to create articles. I spend a fair amount of my reviewing copyright reports, and the number are by brand-new editors attempting to create a brand-new article, largely by copying and pasting some reliable (or not so reliable) source.--S Philbrick(Talk) 19:18, 7 July 2019 (UTC)
@Sphilbrick: I moved your !vote to the new section, since you made it after the revised proposal. However, time-wise it's pretty close to when things were reshuffled, so I'm pinging you to make sure your !vote reflects the current proposal and not the old one. Headbomb {t · c · p · b} 19:24, 7 July 2019 (UTC)
Headbomb, Thanks for the heads up. S Philbrick(Talk) 20:59, 7 July 2019 (UTC)
@Sphilbrick: Wikipedia:Article_wizard/Referencing also now warns against copy-pasting from sources, for what it's worth. I hope this brings you in the support category. Headbomb {t · c · p · b} 21:05, 7 July 2019 (UTC)
  • Support new proposal – I think it will help those who want to create new articles more easily learn how to do it and how to do it the right way. That, in turn, would make things better at AfC and NPP. I particularly like that it can specifically cater to editors based on their experience level. – Levivich 19:45, 7 July 2019 (UTC)
  • Support. My rationale for the previous proposal also applies here, with modifications. This sounds like a great idea that would help convert our readers into editors. Headbomb's tutorial is an ideal place to send new editors to, since it directs them to essential reading that helps them understand Wikipedia's conventions and expectations. Then, it encourages them to create drafts in non-public-facing areas of Wikipedia (their user space sandbox and the draft space). These areas are low-pressure "safe zones" where new editors can get familiar with our editing tools (wikitext or the VisualEditor). Since they're drafts, and not live articles, patrollers won't revert the new editors immediately after they make a mistake, which can be burdensome for patrollers and discouraging for new editors. Any outstanding issues get addressed when the editors ask for help, or are ready to submit the drafts for review. Hopefully, these zones help new editors learn the ropes at their own pace, and eventually become comfortable enough to participate in other areas of Wikipedia (including draft reviewing and new page patrolling). — Newslinger talk 20:43, 7 July 2019 (UTC)
  • Support I think this is an excellent proposal. Giving new people proper direction on how to get started is a good thing. CThomas3 (talk) 21:40, 7 July 2019 (UTC)
  • Support new proposal. The landing page is a good idea. Also, this process seems to be a good way to get new productive editors involved in Wikipedia. If new editors can create acceptable articles then they might have a stake in participating here. This may encourage them to participate in other areas that need editors. Also, learning how to create acceptable articles is a great way to begin learning how editing works on Wikipedia. ---Steve Quinn (talk) 06:35, 8 July 2019 (UTC)
  • Support It's bizarre that the sidebar has comparatively obscure options like Create a book but doesn't have the fundamental option of creating a new article or page. I regularly create articles and do so by generating a red link and then clicking through on that – a process that is not intuitive and which would be hard to explain to a new editor. Andrew D. (talk) 08:48, 8 July 2019 (UTC)
  • Support with reservations. I like the general approach but before bringing the whole thing into general use, I think it needs to be carefully tested, perhaps in conjunction with specific virtual editathons. Reactions from new users and their reviewers should be taken into account.--Ipigott (talk) 12:43, 8 July 2019 (UTC)
  • Support new proposal. It will help new users to create drafts first, instead of live articles. I also like the customized landing depending on editor status. Megalibrarygirl (talk) 15:01, 8 July 2019 (UTC)
  • Support Trial - like the idea and even the execution is snazzily slick. I do however think Ipigott has something on it being trialled. I'm not sure if limiting it to a virtual editathon is the only way to go, but an 8 week trial would be good - see whether hits on those pages, and page/draft creation, vary significantly. Nosebagbear (talk) 17:54, 8 July 2019 (UTC)
  • Support a trial - provided some dedicated attempt is made beforehand to figure out whether WMF has something similar in the works already (as noted below). Not much point in working at cross purposes! Otherwise, this strikes me as a well-executed improvement. Some more work on the exact content will be necessary. E.g., auto-confirmed users may be more "experienced" then fresh IPs, but they still should be strongly steered towards AfC and cautioned against direct mainspace creation. Also, pointers to the Adventure sounds like a good idea. --Elmidae (talk · contribs) 19:15, 8 July 2019 (UTC)
  • Support a trial - This is a much better approach. Obviously, the various texts can probably be tweaked a little, but the concept is certainly worth a try. Beyond My Ken (talk) 01:09, 9 July 2019 (UTC)
  • Support for trial only. I don't think we can really know whether this will lead to an increase in articles we would want to keep, or if it will lead to an increase in junk and disappointed contributors. There's only one way to find out. But there would have to be a thorough review by the community after the trial, before anything should be implemented permanently. --Tryptofish (talk) 18:35, 9 July 2019 (UTC)
  • Oppose We already have too many articles, already. Fully a third of all articles ought to be deleted. I wouldn't support anything that encourages the hoi polloi to create articles. Chris Troutman (talk) 23:28, 9 July 2019 (UTC)
  • That makes sense. After all, it's not like we invite everyone to edit Wikipedia, or anything like that. As has been said numerous times in the past, everything has already been discovered anyway. Beyond My Ken (talk) 04:04, 11 July 2019 (UTC)
  • Support trial only: While my general sentiment is aligned with that of Mr. Troutman (namely, we have too many articles), I can't see the harm in running a trial of this. Any further attempts to expand such a trial to the entirety of Wikipedia would depend on the data received, community sentiment and discussion, etc., etc. —Javert2113 (Siarad.|¤) 00:03, 10 July 2019 (UTC)
  • Support a trial for the many good reasons articulated above (and below) by Elmidae, Tryptofish, Kudpung, and others. Happy days, LindsayHello 06:15, 12 July 2019 (UTC)
  • Support giving it a try at the very least. XOR'easter (talk) 17:26, 12 July 2019 (UTC)
  • Oppose I don't think that directing people to create new articles as a form of editor recruitment is a good idea. Most articles written by new editors are deleted pretty quickly as unsuitable. Sending them through AfC is better but will still result in the submission being declined, possibly repeatedly. At this point the new editor is unlikely to continue. As Wikipedia has matured its standards for articles have increased and the number of suitable topics which don't have articles has shrunk, meaning that articles from new editors are much less likely to be useful. I suspect that the main effect of this will be to push up the AfC and/or NPP backlogs rather than to recruit more editors. We would be better off directing them to improve existing articles instead. Hut 8.5 13:08, 13 July 2019 (UTC)
  • Oppose as this will result in more junk to delete and therefore an increase in admin/reviewer workload (a department which is already badly understaffed). Agreed that improvements should be made to help newbies get involved, but this is not it. -FASTILY 22:40, 14 July 2019 (UTC)
  • Support as trial per Newslinger. Directs users to the correct places and tutorials, before they make bad articles that get deleted. ~~ OxonAlex - talk 09:30, 16 July 2019 (UTC)
  • Weak oppose WP:CIR applies across everything we do here, so you should at least know some of the basics before being given a button to create anything. But maybe a trial would be useful instead. Lugnuts Fire Walk with Me 15:09, 16 July 2019 (UTC)
  • Oppose per the reason I gave in opposing the original proposal now hatted. I still believe this would end up doing more harm than good; for instance by driving off more users (whose crap in mainspace would summarily have to be deleted). If we "must" add any link to the sidebar, it should be a link to some tutorial about fixing typos or the like. – Ammarpad (talk) 00:05, 17 July 2019 (UTC)
  • Oppose the reason it's so difficult to figure out how to create an article is because its so difficult to create an article that won't be deleted. * Pppery * it has begun... 01:30, 17 July 2019 (UTC)
  • Tentative support of a trial. I like making it easier to actually make an article, but am wary if it makes more junk as such. Only one way to find out....Cas Liber (talk · contribs) 03:57, 17 July 2019 (UTC)
  • Support. Great idea, worth a try and solves a common problem with some helpful links. I like the customised landing pages. --Tom (LT) (talk) 08:34, 17 July 2019 (UTC)
  • Still oppose, per Hut 8.5. New users should not even be encouraged to create drafts, judging by the amount of rubbish that gets submitted to AFC or deleted as G11/U5. MER-C 09:04, 17 July 2019 (UTC)
  • Support a time-limited trial to allow us to evaluate whether this would create more signal or more noise. Sandstein 10:54, 17 July 2019 (UTC)
  • Oppose NPP and AFC are already overloaded and backlogged and this will just heap more cargo on a struggling ship imv Atlantic306 (talk) 22:52, 17 July 2019 (UTC)
  • Oppose. Aside from the arguments above, we already have data from Commons indicating that unregistered users were uploading way too much junk to make this a worthwhile enterprise. Our current "new article" systems are already overloaded, and this is just far too tempting to trolls to use in creating articles that are deeply, deeply problematic. I suggest that the hypothetical difficulty in creating a new article (which doesn't really exist, since any registered account can do so) is in the quality aspects, not the mechanical ones; and the few unregistered users who have the ability to create a new article that will survive already have AfC. Risker (talk) 01:58, 18 July 2019 (UTC)
  • Still oppose, As I said above, as every AfC and New Page reviewer knows - and they are the only people who have an overview of what gets created nowadays - the last thing we want to be doing is making it too easy to create more junk. There is no disputing the fact that the encyclopedia has matured since its creation. The vast majority of new articles nowadays are obscure BLP from South Asia, Bollywood, Phillipino Beauty Pageants, reality shows, one-line stubs about soccer players, newly named asteroids, nn US political candidates, and blatant corporate spam. One of the reasons why there is so little interest in doing NPP is because there is nothing interesting to see nowadays - it's all just grunt work. Kudpung กุดผึ้ง (talk) 04:23, 18 July 2019 (UTC)
  • Oppose per all of the above. All this would do would be create more work for AfC reviewers, NPPers, and CSD admins. TonyBallioni (talk) 17:45, 18 July 2019 (UTC)
  • Oppose as per everyone above - This will simply mean more crap gets created and then more crap gets deleted, AFC & NPP reviewers have enough to do let alone this, On paper it sounds great but in reality not so much. –Davey2010Talk 13:26, 19 July 2019 (UTC)
  • Oppose A better link to place would be to the 20,000 already established articles needing cleanup. Learning how to clean an article is an extension to creating one, and just as valuable.  Spintendo  04:21, 21 July 2019 (UTC)
  • Support a general 'Become an editor...' or similar link. The real problem as per Headbomb is that there is no "Become an editor..." or "Become involved..." link - I would strongly support such an inclusion. All I can see now is the obliquely titled 'Community' on the sidebar. I don't support a "Create an article" link though. A number of editors above make convincing arguments as to why this should be a general link rather than a "Create an article" link. --Tom (LT) (talk) 22:27, 22 July 2019 (UTC)
    Yeah that would work too. Headbomb {t · c · p · b} 04:05, 23 July 2019 (UTC)
    Then that problem can be easily solved without even the need for an RfC. Just rename "Community portal" to "Get involved...," "Become an editor..." or whatever. The link basically already has this information though in an inconspicuous location: the tooltip of the link says "About the project, what you can do and where to find things." Needless to repeat, the portal has ideal links for new editors. – Ammarpad (talk) 20:01, 24 July 2019 (UTC)
    @Ammarpad: wrong section? Because I don't know what "Community portal" is. It's certainly not anywhere in the interface. Headbomb {t · c · p · b} 20:13, 24 July 2019 (UTC)
    It is the third item under the "Interaction" section in the sidebar. Unless you're using something that hides it, I am not sure how you're not seeing it. Here is the source text for the sidebar: MediaWiki:Sidebar, and the source text "Community portal". – Ammarpad (talk) 20:27, 24 July 2019 (UTC)
    Also a really good idea. If we end up linking to the community portal, we should probably give it a bit of a redesign to reduce information density first. Enterprisey (talk!) 10:17, 8 August 2019 (UTC)
  • Oppose for reasons I expressed in re the original proposal. At the moment, the most direct way to create a new article comes either from first searching the wiki for existing references, or expanding upon a redlink, both good starting points for a new editor. While the new language is nice, many articles are clearly created by those who haven't read the existing edit notice at the top of the page itself when you create a new article. As others have stated, at this point in the wiki's development, there is less need to encourage the creation of new articles, and more need to encourage the development of existing pages. MarginalCost (talk) 15:14, 25 July 2019 (UTC)
  • Support a trial. The growth and survival of WP depends upon the continual recruitment of new editors, and most new editors are likely to come because they have articles they want to write. However, for at least the last 12 years, at least half the submitted articles have been unsatisfactory. We have succeeded in moving most of the potentially problematic new articles--those by new editors--to Draft space, and it is therefore just as expected that most of them will not be acceptable, at least initially. It is therefore all the more essential that we provide prospective new-article writers with a clear route to make articles. The current method, of looking for an article and not finding it as the basic route to make an article is incredibly obscure, and what nobody coming here could expect. We need a clearly indicated route from the beginning, in a reasonably prominent way. The Article Wizard is a over-elaborate over-prescriptive way, but it works, and following it will not lead people astray. We need to find a way of making it much more prominent. Those who have worked on the general problem of creating and screening articles should reconsider opposition to this: it's in the spirit of WP to try new ideas. DGG ( talk ) 23:23, 26 July 2019 (UTC)
  • I'm a solid oppose here per the conclusions of the NPP/AFC crowd. --Izno (talk) 23:00, 27 July 2019 (UTC)
  • Support I know that when I created my first article, it certainly took me a while to figure out how, and I already had 200+ edits at the time. Let's do it. WizardKing 01:23, 30 July 2019 (UTC)
  • Support at least for a trial. This is a known deficiency in the interface. I'm a bit concerned with sending people to the AFC process, which we know is ineffective. If it can't support the influx of contributions after a week or two, the trial should be switched to posting directly to main namespace, which tends to be more efficient. Nemo 06:44, 31 July 2019 (UTC)
  • What Tom said. Yes to whatever makes the learning curve here less steep, but not by encouraging them to create articles (or drafts or anything standalone). Can we have a project page that allows new users to get feedback on whether potential new articles are likely to survive? For example, we can allow them to link to several sources for editors to evaluate potential WP:N compliance before the article is written. feminist (talk) 16:20, 1 August 2019 (UTC)
  • Oppose in this form. I like the thought here but there's already a 'Help' link under Interaction that prominently includes guidance on how to create an article. If that's proving hard for new editors to find (understandable - it's pretty vague), it might be best to add a second link immediately below called "Help build Wikipedia" or similar, pointed at Wikipedia:Contributing to Wikipedia or possibly Help:Getting started, rather than making another help page that would need to be maintained separately. For the reasons others have given, we probably want to encourage newbies to contribute by editing before they start creating and I think this way would achieve that better. › Mortee talk 22:02, 1 August 2019 (UTC)
  • Oppose. New users should not be invited to start new pages. Instead, they should be invited to improve existing content. Creating new pages is the hardest, and doing it through AfC segregates the newcomers from mainspace editing other users. Newcomers competent to start a new page will discover how to soon enough, incompetent newcomers being led down the glossy AfC path to rude mistreatment is not good for anyone. --SmokeyJoe (talk) 03:13, 5 August 2019 (UTC)
  • Oppose. New users should not be jumping in and creating new pages; all that will lead to is more nn-bios and one-liners to clean up. I appreciate there are hurdles in the way of creating new articles, but they are there for good reason. Better that they improve the articles we already have. Stifle (talk) 09:54, 8 August 2019 (UTC)
  • Support per DGG. Enterprisey (talk!) 10:15, 8 August 2019 (UTC)
  • Support per DGG. Creating a new page is one the main attractions for new volunteers, and telling them "we don't want you to do that, volunteer elsewhere" is unlikely to make them continue volunteering. —Kusma (t·c) 10:22, 8 August 2019 (UTC)
  • comment (mostly oppose, but also some support...). Oppose asking for "create an article", as probably that should not be the very first thing of a new editor (hmmm... it might have been mine... :-) but it was over a decade ago in a quite different wikipedia). Note that we do not lack articles although we do not have such a link for... almost 20 years or so? So maybe it is not exactly greatly needed. If implemented it should be a trial, i.e. with a time set and should only become permanent after a new RfC. Support, if this is reworded as a call for help, i.e., how to improve current content. - Nabla (talk) 00:49, 10 August 2019 (UTC)
  • Oppose per Ammarpad, Hut 8.5 , MER-C, Risker and Kudpung, and due to my past work in clearing out the speedy deletion and expired prod backlogs. My experience in this area echoes theirs. Adding Smokey Joe's reasoning. I've not yet formulated a clear, concise way to explain it to them without putting them off, but I agree that new editors need to learn their way around the 'pedia as regular editors before diving into article creation. It's both better for them psychologically, and better for the 'pedia. - CorbieV ☊ ☼ 21:05, 12 August 2019 (UTC)
  • Oppose per CorbieVreccan.--Vulphere 15:56, 13 August 2019 (UTC)
  • Oppose per Ammarpad. Willbb234Talk (please {{ping}} me in replies) 17:30, 23 August 2019 (UTC)
  • Support a trial, per DGG. We do need regular new editors, and one of the hardest and difficult to figure out things for a newbie on Wikipedia is how to start a new article. A trial will show whether the concerns of the opposes are justified or not. Nsk92 (talk) 23:28, 23 August 2019 (UTC)
  • Oppose I'm in favour of having a visibly obvious part of the interface for a "Create a new article" entrypoint, but not one that allows inexperienced users to actually create new articles but rather tells them why they cannot create articles at this time and what skills they need to acquire and what commitment to building an encyclopedia they need to demonstrate. See my comments section below if you want to know more about this approach. This proposal is just a variation on the existing Articles for Creation system, which we have been operating for some years and we know doesn't work. Kerry (talk) 00:29, 24 August 2019 (UTC)

Discussion (Create an article)

I just clicked through Wikipedia:Article wizard and did not see anything about notability (well, there is "For further information, please visit our guide on notability" but someone wanting to write about their garage band is not going to see that). A "create article" link is setting new editors up to fail or at least to be frustrated by waiting for the overloaded draft review. The article wizard would first need toughening up. It needs a section on notability and a section with links on asking questions. Johnuniq (talk) 04:00, 7 July 2019 (UTC)

  • Please let's not channel more good-faith newbies into Articles for Creation, which is where the wizard sends people. It was never designed as a nurturing place for good-faith newbies to make their first edits. Espresso Addict (talk) 05:10, 7 July 2019 (UTC)
    AfC is a much better and user-friendly route than normal new page patrolling, as someone who patrols pages occassionally, rest assured, most of them are not treated as nice, with a "this is wrong", "this needs to be fixed", but more of a "your article is wrong in this way, and will be deleted, get it?" --qedk (t 桜 c) 05:58, 7 July 2019 (UTC)
I disagree. Sitting waiting for perhaps months until someone gives you a capsule review that takes a degree in wikispeak to unwrap, and then just says "no" in acronym speak, appears to me even worse than a swift speedy. At least the speedy route is quick, contains appeal instructions, and might just throw you in the way of a friendly admin. Espresso Addict (talk) 06:06, 7 July 2019 (UTC)
I seem to recall a long discussion involving I believe Kudpung on where to send genuine newbies in the context of mainspace creation being permanently turned off for non-autoconfirmed editors, but I don't think there is a suitable venue at present. I'd certainly support creating one but I doubt it's as easy as it sounds. Espresso Addict (talk) 05:58, 7 July 2019 (UTC)
Well, whatever is at the end of that link (WP:Create an article/WP:Article wizard/WP:Your first article/WP:Whatever we decide) could be a general landing page, with a short explanation that to create articles in the mainspace, you need to have some Wikipedia experience, or you go through the article wizard and upload them as Drafts so others can review them. Headbomb {t · c · p · b} 06:09, 7 July 2019 (UTC)
In my experience, this [6] is the kind of article that newbies submit on species (let alone the much more complex taxonomic entities), and that was far from the editor's first edits, and positively stellar compared with the worst I've tripped over. And with species, there's none of the problem with notability that plagues say (auto)biographies. Espresso Addict (talk) 06:22, 7 July 2019 (UTC)
  • As every AfC and New Page reviewer knows - and they are the only people who have an overview of what gets created nowadays - the last thing we want to be doing is making it too easy to create more junk. There is no disputing the fact that the encyclopedia has matured since its creation. The vast majority of new articles nowadays are obscure BLP from South Asia, Bollywood, Phillipino Beauty Pageants, reality shows, one-line stubs about soccer players, newly named asteroids, and blatant corporate spam. Help should be offered immediately at the registration interface, and as far as I know, the WMF is working on a new landing page right now - a long awaited project since they originally started and disbanded it under various pretexts in 2012. Let's give it time to develop, and let's not lose the breathing space we gained with the introduction of ACPERM which we fought 7 long years for. Kudpung กุดผึ้ง (talk) 06:18, 7 July 2019 (UTC)
    • Couldn't agree more. I urge anyone about to caste a !vote here to go have a good look at the new page queue before they say anything. Article creation should be one of the last tasks new editors are guided towards, not the first. Triptothecottage (talk) 13:04, 7 July 2019 (UTC)
  • Updated with just 273‎ bytes to address concerns raised in this section....Wikipedia:Article_wizard/Referencing.--Moxy 🍁 06:45, 7 July 2019 (UTC)
  • The problem is that the slogan 'the encyclopedia anyone can edit' has been allowed to be interpreted too loosely. Anyone can also ride a bike or drive a car, or sail a 470, or fly a Cessna 152, it's easy enough, but there is a learning curve (that's why kids bicycles have training wheels), and the rules of the road, the sea, and the air have to be learned. A good Article Wizard can do much to help, but the whittled-down-to-nothing thing that's replaced what we had used before ACPERM was rolled out is all but useless, and that's why AfC is so backlogged. The Article Wizard should be the training wheels.Kudpung กุดผึ้ง (talk) 07:47, 7 July 2019 (UTC)
  • Wikipedia Tutorial Button? - all the answers above are bang on. But how about instead of just avoiding making our job (AfC/NPP) harder, we push some more people towards a tutorial, whether WikiAdventure or otherwise? Nosebagbear (talk) 15:30, 7 July 2019 (UTC)

@Espresso Addict, Kudpung, Nosebagbear, Beyond My Ken, MarginalCost, MER-C, Wehwalt, Purplewowies, and Levivich: How about a landing page that looks something like User:Headbomb/Create an article? I've also added the mockup to the above so you could see what it would look like. Which 'tab' you would land on would depend on what useraccess level you have, so this could be tailored to the experience level of each person landing there. Headbomb {t · c · p · b} 19:07, 7 July 2019 (UTC)

Headbomb, that I like and support... funneling the editor through the right process depending on their experience level. Nice work! (And thanks for the ping.) – Levivich 19:27, 7 July 2019 (UTC)
@Levivich: well, the new !vote section is up. Headbomb {t · c · p · b} 19:30, 7 July 2019 (UTC)
Exactly something like that is what the WMF is currently working on. But we all know what goes on at Phab. Perhaps Insertcleverphrasehere, the defacto coord of NPR knows, or Primefac, the de facto coord of AfC. Kudpung กุดผึ้ง (talk) 00:17, 8 July 2019 (UTC)
Other than the WP:AFCIMPROVE discussion from May 2018, I have not heard anything about changing or updating any part of the AFC process. Primefac (talk) 01:08, 8 July 2019 (UTC)
Kudpung, I'm also not aware of an active project on this, though I am currently only following the stuff on Phab that is directly related to the NPP wishlist items. — Insertcleverphrasehere (or here)(click me!) 05:12, 8 July 2019 (UTC)
@Headbomb: - I'd suggest adding the Adventure for the latter 3 (I realise that like WP:CENT, it becomes less valuable the more you have). Regardless of that, looks nice (I also had no idea that you could set viewing by permission level, but obviously that makes sense because the same occurs when you hit an editing lock) Nosebagbear (talk) 11:33, 8 July 2019 (UTC)

Pinging those who opposed based on some variant of 'there's too much shit at AFC/users need more experience' so far (@Chris troutman, Hut 8.5, Fastily, Lugnuts, Ammarpad, Pppery, MER-C, Atlantic306, and Risker:)

Well, a few things:

  • The AFC instructions have (since the start of this RFC) been tweaked to put the big don'ts front and center. For example, Wikipedia:Article wizard/Referencing now much more strongly hammers the three main points: Copyright, Notability, and what is and isn't proper referencing. Compare with the old version.
  • Likewise, once at AFC, {{AFC submission/draft}} now warns against copyright violations, writing with a NPOV, and hammering that it's a bad idea to write about yourself or your business (COI stuff is the majority of the crap at AFC). Compare with the old version which only told people where to go for help.
  • {{AFC submission/helptools}} is now also much more helpful at directing people towards resources (compare with old version) leveraging the power of WikiProjects to get feedback and suggesting to look at good/featured articles to have models of quality writting.
  • Wikipedia:Article_wizard/CreateDraft now gives an estimated timeline, so people are aware of roughly longs things will take.

This is at least worth trialing, I feel.

Concerning the 'lack of experience', well, these landing pages is a way to direct these people how how to get that experience. It's telling them "Yes, you can create pages, but it's a bit daunting to do that right of the bat, so instead consider doing these things instead, for example try doing [examples of easy tasks]." We have to have a way of recruiting the curious. Yes there will be shit submitted with general incompetence. But we too were shit/generally incompetent once. We're the encyclopedia anyone can edit. We made the internet not suck. And we need to remember that we too were once eager to join. We could create articles right off the bat. We submitted shit. We sucked. But we learned. So we need to have something for those that are eager to learn how to join us. Newbies deserve to have a link for them in the interface somewhere, and it's not by being a bunch of "disgruntled elitists that we're going to grow the movement. If you don't support a 'create article', we at least need a "Start editing / Get involved" sort of landing page. Headbomb {t · c · p · b} 02:47, 18 July 2019 (UTC)

Headbomb, I hear where you're coming from. But even though I may have been a not-good editor once, it was harder then to create an article than it is today by a long shot (we had no AFC, and almost no help pages), and I'm glad it was because my first article would no doubt have been (appropriately) deleted even back in those much more liberal days. However, we've automated so many of the "entry level" roles such as fixing typos and minor copy editing and reverting vandals that it is much more difficult to start off easy than it was pre-2010 or so. I still do not think that it's a good idea to stick a "create an article" button anywhere obvious, although I'd be okay with an automated message on the talk page of a newly registered account. (It would also be an interesting thought experiment to come up with tasks suitable for newbies that don't involve article creation, and including them in the automated message.) We're actually one of the few projects that *don't* post an automated welcome/informational message to new users. The message will likely remain on their talk page through unconfirmed and autoconfirmed periods at least, so they won't be losing the links. I fully expect anyone who reaches "extended confirmed" level to be capable of figuring out themselves how to create a new article. Risker (talk) 03:09, 18 July 2019 (UTC)
@Risker: Well, that's what the tabs can be used for! If you're a complete newbie, we can tell you where to go to learn. If you're autoconfirmed, you know a bit more, so we can tell you something a bit more relevant to you!
Put yourself in the shoes of a good faith and completely new editor, you don't know anything about Wikipedia works, except you want to get involved because it sounds fun, and you know something we don't have information on. You don't even have an account. How do you get involved? You see the "edit button" at the top of a window, so you guess you'll click that because you hear people can edit it and want to see for yourself. And then you're presented with a bunch of legalese and warnings. Or you land on a semi-protected page, and you don't even have an "edit button" anywhere.
What's better? That experience? Or, seeing a "Get started" link in the sidebar, so you click that, figuring if you want to get started, that's probably the place where you'll learn the how of Wikipedia. With such a link, we can give you advice of on you can contribute, where to go to get help, and what not to do, without you being on the ass end of {{uw-nor3}} after your first edit because you didn't know how to add references properly. Headbomb {t · c · p · b} 03:29, 18 July 2019 (UTC)
I could live with the two words "Get started" or "Things you can do" or something like thatin the Interaction box on the sidebar, linking to an appropriate page. Not "Create an article", which is just asking for trouble we don't need and are already having a hard time managing. It could probably be a rename of the Community Portal and its link, since there are a lot of "getting started" ideas there already; simply add a section on "create an article" there. Just keep in mind, what we're talking about here isn't what's in the current proposal. Risker (talk) 03:42, 18 July 2019 (UTC)
  • The article creation process would scare away too many newbies too early. I'd support adding a link to something like Help:Getting started in the sidebar. --Yair rand (talk) 05:25, 18 July 2019 (UTC)
  • I agree with the general sentiment that something should be done to encourage new editors to find stuff to do, but I also agree that this explicitly needs to exclude article and draft creation. Encouraging article creation leaves us with a bunch of drive-by editors creating articles or drafts with the usual COI, spam and notability problems. There are plenty of other things to do - expand stubs, categorize articles, and so forth - and it should be easy to find those tasks in a particular topic area a new editor is interested in. Building an encyclopedia requires substantial effort and is not suitable for everyone. MER-C 10:39, 18 July 2019 (UTC)
  • "We have to have a way of recruiting the curious" No, we don't. We have new editors join everyday that figure it out. Wikipedia attracts a special sort of self-selector that gets it. Efforts like these attempt to bring on the strap-hangers that will never make significant contributions. My first Wikipedia article was Dragon Seed (novel). That same day I also created The Raising of Lazarus (Rembrandt). Neither are very pretty or developed but I didn't need help or AfC. Why would anyone else? Chris Troutman (talk) 13:17, 18 July 2019 (UTC)
  • I agree with the idea of having something in the sidebar to encourage readers to become editors, I just don't think article creation is what it should point to. If people click on that button and actually write something then the vast majority of the time they will have a very bad experience when the article gets summarily deleted/rejected, so it won't be very good at attracting new editors. It also isn't free as it takes scarce editor time to deal with these creations/submissions. Putting up warnings or instructions won't necessarily help that much. If you try to create an article now you see a message saying you should cite references to reliable published sources, not violate copyright and other good stuff, and it strongly recommends you read a long page which gives you a good overview of what we want. None of this stops people writing rubbish articles. They either don't read it or falsely don't think it applies to their article. Hut 8.5 17:52, 18 July 2019 (UTC)
  • As someone who trains new users and has reviewed at AfC, I strongly agree that new users should be prevented from creating new articles and probably for a lot longer than the current autoconfirm arrangements prevent. Firstly because they don't usually have the experience of being a contributor to understand how we do things (that is, know how to do it right) and because they have nothing to demonstrate that they are here to build an encyclopedia (an intention to do it right). I think it would not hurt to simply tell new users this when they attempt to create an article "wait, you aren't experienced enough yet to do this, go improve some other articles". Funnelling brand new contributors into AfC isn't helpful -- it pushes the problem away from regular contributors (which is good for them) but dumps it onto AfC reviewers. If you review at AfC, you very quickly start to suspect that the bulk of the drafts are probably conflict-of-interest situations or paid editing as they are most articles about living people and current organisation. Just take a look at today's haul and see what you think! Category:AfC pending submissions by age/0 days ago. Because we are supposed to assume good faith, we don't have a "reject this, it looks and smells like self-promotion" so what happens is a never-ending cycle of "rejected, failed to demonstrate notability" until the person gives up on resubmitting it. Having a 2 month backlog on review contributes to the "just give up" message. Unfortunately the good faith contributors coming through this process tend to get much the same experience and I encounter plenty of experienced editors who never create new articles having had bad experiences earlier in their contributing "career". AfC could be a supportive learning experience for people creating their first articles but only if the contributors have honed their skills on article improvement first (and as a byproduct demonstrated that they are here to build an encyclopedia not just use it as an advertising platform). The one problem with this proposal is our obsession with running edit-a-thons, which almost always have lots of new contributors creating new articles, often with the topic area being the same as the contributor group (e.g. women artists). Having supported such events, I know they work better if the organisers provide a pre-compiled list of topics (ideally with a couple of pointers to where some source material might be found) which are likely to pass notability. The events where the participants are allowed to pick their own topic tend to attract notability and CoI issues. While they don't normally write about themselves (I make that very clear), they do tend to write about overly close colleagues and friends (or so I suspect from the chatter in the room). I feel quite uncomfortable about supporting such events; yet I figure if I am not there explaining our policies, then the outcome is going to be even worse. I'm all for supporting good faith users writing their first articles, but let's defer it until they are ready. The current autoconfirm threshold is based on probability of being a vandal; it isn't a measure of being ready to create articles unsupervised. I'd set the threshold much higher, say 100 non-reverted edits which add content (so positive article size diffs) where the diffs include the addition of at least 30 non-naked-URL citations, addition of 30 wikilinks and so on. Something that demonstrates ability and intention to add useful content to Wikipedia, more than just copyediting. After that, they get to do through AfC until they have had 3 new articles accepted. I'm plucking those numbers out of the air (not saying they are the right numbers). But it's important that the aspiring user can be told why they are not judged as ready yet and how they can work towards being ready ("you don't seem to have enough experience adding citations, if you would like to learn more about adding citations, read this or watch this video"). Maybe we need to have a system of "rights" that editors can earn through some combination of education and/or demonstration of competency in prerequisite skills, be it for new article creation, or editing templates, editing categories, (as opposed to simply using them) etc. Personally I would restrict new contributors to the Visual Editor (harder for them to break syntax so keeps them more focussed on content which makes it easier to assess their good intentions) and make access to the source editor another of these "rights" that is earned. Kerry (talk) 22:44, 23 August 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Update default preferences for new users

I help train new users at editathons. The Preferences defaults are not ideal for new users. At editathons we often take a special couple of minutes to advise people to change them. So I would like to change them for everyone, which will save time for lots of people. I can make this request for a "configuration change" to English Wikipedia at Phabricator but must show that there is a consensus on the proposed changes. I ask for your feedback here on two proposed changes, which I have wanted for several years:

  • Under Editing, Editing mode: should default to "Show me both editor tabs" so the new user can quickly get to the Visual Editor. We generally advise new users to use the Visual Editor immediately. They are not likely to be programmer types nowadays.
  • Under Watchlist, these four toggles below should be turned on immediately by default, otherwise the Watchlist is not useful for finding updates to their own past work. I don't know why, but for new users they are not all on by default.
    • Add pages and files I edit to my watchlist
    • Add pages and files I move to my watchlist
    • Add pages I create and files I upload to my watchlist
    • Add new files I upload to my watchlist

What do you think? -- econterms (talk) 14:13, 16 August 2019 (UTC)

@Whatamidoing (WMF): I think you might have some previous research/discussion handy for this one. --Izno (talk) 14:27, 16 August 2019 (UTC)
@Econterms: I'm not following your request very well, I just created a brand new test account to see the options:
  1. On first edit I already got the giant pop-up asking if I wanted the Visual Editor, if selected it became my default
  2. "Add pages I create and files I upload to my watchlist" is already on by default
  3. "Add pages and files I move to my watchlist" isn't in the watchlist section of preferences
  4. "Add new files I upload to my watchlist" isn't in the watchlist section of preferences
  5. "Add pages and files I edit to my watchlist" is off by default.
    For this one, I think it should be - it discourages "ownership" and also prevents watchlists from becoming horribly large over time. — xaosflux Talk 14:33, 16 August 2019 (UTC)
    OK, a little more on this. Once a user becomes confirmed/autoconfirmed then they gain access to: "Add new files I upload to my watchlist" (which is on by default) and "Add pages and files I move to my watchlist" (which is off by default). — xaosflux Talk 14:54, 16 August 2019 (UTC)
  • Thank you, xaosflux. I just checked too and I stand corrected; as you say only two of those prefs appear and the new user can indeed get to the visual editor, but they have to get something right immediately to have both editors visible. I prefer that both editor tabs be visible to anyone by default, although I understand a user can get to the Visual Editor and have it stick as you say. So I still want to make that request. And all those things should be on the watchlist asap, I think. Only experienced users have the problem of a large watchlist, and they have enough info to fix the problem. Relatively new users get something out of the watchlist system only if their very first edits show up, and often they don't. It's morale-reducing to get involved in setting technical preferences immediately when we want the new user to get the uplifting feeling of having made a fix and having the system work right. So I still want these defaults adjusted as I mentioned. Thanks for researching it. -- econterms (talk) 15:18, 16 August 2019 (UTC)
    Adding the tab buttons is "easy" and is done at other projects, for example: w:es:Special:Random. That would just require some consensus here. — xaosflux Talk 15:34, 16 August 2019 (UTC)
I agree that both edit tabs should be open immediately ( which one I tell people to start with depends on their previous computer background). Since we usually tell people to start off by editing some existing article, the default for watchlistist pages edited should be on. For most participants, their watchlist is unfortunately never going to get large enough to be confusing. DGG ( talk ) 17:53, 16 August 2019 (UTC)
I certainly agree that "Add pages and files I edit to my watchlist" should be on by default - for most of us this is most of what the watchlist is there for, & without it it isn't much use. Unfortunately most new editors don't stick around long enough to get a "horribly large" watchlist (ok, like mine is), so I'm not impressed by that concern, still less by "it discourages "ownership"". Johnbod (talk) 02:29, 17 August 2019 (UTC)
Hello, econterms,
The English Wikipedia (and maybe about a hundred other wikis?) has the mw:VisualEditor/Single edit tab configuration style. However, unlike the others, the first option here is the 2010 wikitext editor. There are advantages and disadvantages to having one vs two edit tabs. Generally speaking, with inexperienced editors and random-person user testing, one tab that starts in the visual mode is what people seem to want. But it's not an overwhelming majorty thing, because if you've edited for years and years as an IP, and now you've decided to create an account, you don't really want to see something different from what you're used to.
Among long-time experienced editors, we got used to having two tabs back in 2013, and while it took us a week or two to stop clicking on the 'wrong' one, we're over it, and most of us easily switch back and forth. Formatting disaster? Give me the wikitext. Need to insert a column in a table? Visual mode, every time. But a new editor isn't going to know the relative strengths and weaknesses of each approach, so the advantages to them are quite small. The documented disadvantages are rather significant. Offering two similar buttons creates a lot of confusion.
I don't think that the Editing team has any plans to work on this question this year, but if people want to switch the button to start with the visual mode, then I could ask the team about it. Whatamidoing (WMF) (talk) 03:15, 17 August 2019 (UTC)
Whatamidoing (WMF): I find it less confusing to offer both tabs than to have partial disclosure of the functionality. We explain why the tabs are necessary, and show that they look different visually, and move on. It is direct and clear. Both functionalities are important. It is I think more distracting for someone to need one and not see it when their mind is on a substantive problem to be addressed. It sounds like you have expert knowledge showing something different? -- econterms (talk) 08:20, 17 August 2019 (UTC)
econterms, have you tried showing them how to switch between the two modes (from inside the editor)? Whatamidoing (WMF) (talk) 03:03, 18 August 2019 (UTC)
As someone who does edit training, please make the default "both editor tabs". And is there any good reason why IPs should't be given two tabs too? Many good faith IP newbies break syntax using the source editor, but it is far more difficult to break syntax in the Visual Editor (ok, not 100% guaranteed, but very unlikely). 05:37, 17 August 2019 (UTC) — Preceding unsigned comment added by Kerry Raymond (talk • contribs)
Kerry, if IPs disproportionately screw up wikitext, then that sounds like an argument for giving them one button, which leads to the visual editor. Whatamidoing (WMF) (talk) 03:05, 18 August 2019 (UTC)
I'd be fine with that too for IPs. A lot less cleaning up of broken syntax to do and by making it more obvious/easy how to cite, the use of citations might improve. If a newbie tries to add a citation, it is typically a naked URL so using "Cite > Automatic" in Visual Editor would be a vast improvement over the things they manage to do with the URL in source editor. Kerry (talk) 03:25, 18 August 2019 (UTC)
I don't know about broken syntax (I think I generate a fair amount myself), but most unintentional WP:EGG-like links are created using the Visual Editor. I'm not sure there's less cleanup required of inexperienced VE editors or inexperienced Wikitext editors. Surveys need to be done. — Arthur Rubin (talk) 10:43, 18 August 2019 (UTC)
Running some tests might be possible (although the Analytics team is perpetually overloaded, so I'm definitely not hopeful about it being possible soon). It might be helpful to know which things were most important. Use of ref tags? Adding a link? Not getting reverted? Something else? We could even set up a Wikipedia:Labels campaign to hand-code edits, if there were a few people willing to invest several hours in that. (The "Easter egg link" problem might be significantly improved by this time next week. You can see the general model at https://en.m.wikipedia.org/wiki/Special:Random#/editor/0 if you switch to the mobile visual editing mode.) Whatamidoing (WMF) (talk) 16:09, 19 August 2019 (UTC)
  • I agree that simplifying setup for new users is important. Every minor bit of configuration you need to do before you can start doing something useful is 1) An opportunity to get things set up wrong, and 2) A turnoff to new users. Maybe as a workaround, there could be some piece of javascript which sets everything up properly for a new user, and a big friendly button on the editathon home page that says, "Click me first!". Even cooler, I could imagine a system which clones an account. So, the editathon organizer could create a new account as a template and configure it in whatever way they feel works best for their teaching style/environment. Then, they could freeze that configuration, and have the "Click me first!" button use that to configure a new account the same way. — Preceding unsigned comment added by RoySmith (talk • contribs) 16:02, 17 August 2019 (UTC)
  • This all sounds reasonable and worthwhile (both watchlisting and both-editing styles offered) - we have some really complicated and controversial methods for aiding retention and making life better for newcomers. Why not grab at the low-hanging fruit? Nosebagbear (talk) 15:42, 19 August 2019 (UTC)
  • With the visual editor having been greatly improved since the early days, it would be reasonable to show both tabs so users have a choice about which editing method they want to use. —pythoncoder (talk | contribs) 01:17, 23 August 2019 (UTC)
  • Anything helpful to new users is always an idea worth considering. However, per Xaosflux above, I would not recommend watching edited pages by default; it has an aura of WP:OWN and could create unnecessary clutter for users who edit lots of pages before learning about preferences and other technical aspects. I do have another idea, though. If it's not already, I would recommend having refToolbar on by default, as referencing is fundamental but also sometimes a weak point for newcomers, especially since the wikitext and template syntax are probably unfamiliar. ComplexRational (talk) 15:01, 24 August 2019 (UTC)

Proposal for ambiguous JOBTITLES

Hi everyone,

I've added a proposal here that I hope can be a good compromise on how and when to capitalize job titles.

Please let me know if you think this is good style policy. Cheers! --Woko Sapien (talk) 16:24, 26 August 2019 (UTC)

Tooltips for articles: Show preview text of section if section linked.

The tooltip that shows an article preview when hovering the mouse pointer above it, shows the beginning of an article, even if a section of the article has been linked.

This does not bother me personally, I just thought I should address this point here, because someone might find it useful. --Handroid7 (talk) 16:18, 26 August 2019 (UTC)

@Handroid7: See phab:T156041. --Yair rand (talk) 21:52, 26 August 2019 (UTC)
Unfortunately non-trivial.. —TheDJ (talk • contribs) 07:50, 28 August 2019 (UTC)

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

(non-admin closure) Consensus exists to remove the "susperps" parameter from Template:Infobox civilian attack. The rationale is based off of WP:NOTNEWS, and concerns about BLP. In the aftermath of tragic incidents, news sources often rush to name suspected perpetrators, but can be wrong or sensationalist. Consensus is that WP should not unduly promote attackers, or possibly defame those wrongfully accused. Unless a perpetrator is known with a relative level of certainty, they should not be named in the infobox. In cases where a perpetrator is suspected, but not known, they should be discussed in prose only – if at all. Discussion took this a step further and asked if the "perpetrator" param should be changed to "convicted", but there was consensus not to. I leave it to a template editor to make the appropriate change. Captain Eek Edits Ho Cap'n!⚓ 04:54, 19 August 2019 (UTC)

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

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

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

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

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

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

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

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.


I am not sure if this already exists, but a bot should be able to correct this:

--Handroid7 (talk) 12:56, 20 August 2019 (UTC)

Hi @Handroid7:, I'm not sure what you are asking for? If you think a bot is creating faults, please post at WP:BOTN. If you would like a bot to do a small-to-medium sized repeated job, you can ask at WP:BOTREQ. If you want a bot to do something very big (many thousands or more edits) discussing here is a good start - but we will need a little more information to get going. A good example would be for you to manually make the type of edit you would like a bot to do, then link to your own diff here. — xaosflux Talk 13:10, 20 August 2019 (UTC)
@Xaosflux: If a URL is written [[http://example.org|like this]], a bot should correct it. --Handroid7 (talk) 23:39, 30 August 2019 (UTC)

2019 Arbitration Committee pre-election RfC

A request for comment is open to provide an opportunity to amend the structure, rules, and procedures of the 2019 English Wikipedia Arbitration Committee election and resolve any issues not covered by existing rules. Mz7 (talk) 21:35, 31 August 2019 (UTC)

Add an interactive historical timeline

Wikipedia already has background information on the dates of particular historical events, as evidenced by the "on this day" section of the main page. despite this, if you wanted to find out the history of a region, and the events that took place during a particular time frame, you have to use a page like this. I propose a page where the user can input a location (or region), category and a time frame, to get a list of all the wikipedia pages that mention said parameters. I believe that this would greatly streamline discovering and learning for those with an interests or need in historical information. — Preceding unsigned comment added by Sleepercreeper1 (talk • contribs) 23:56, 28 August 2019 (UTC)

Have you tried categories e.g. Category:1750s in Canada ? WikiData might also be worth looking at. DexDor (talk) 20:38, 29 August 2019 (UTC)
Yeah, that would be cool. There are a number of ways to use and represent the information found in Wikipedia that we haven't begun to scratch the surface. Once more of the info is transported through WikiData, it might be more readily transformed to created visuals like the one you are suggesting. Killiondude (talk) 23:14, 29 August 2019 (UTC)
I've read about an external project that has more or less done this, or is in the process of developing it; for some reason, I think I may have even met someone involved in it, possibly at Wikimania 2018. Unfortunately, I have no recollection of where to find it, or even where to look it up, but I suspect it was from a Signpost article. I remember the visual was....enormous. Risker (talk) 03:52, 30 August 2019 (UTC)
The official Wikidata SPARQL endpoint can output to a timeline view, see d:Wikidata:SPARQL query service/queries/examples#Timeline. There's also a community tool at Wikidata Timeline and a third tool another one called Histropedia. --Izno (talk) 03:36, 1 September 2019 (UTC)

RFC: New Padlock System

This is going nowhere. These locks were recently changed in a well-attended RfC. I would advise Wyatt2049 to first put forth their modifications at Idea lab to receive feedback before deciding whether to open a new RfC at all. – Ammarpad (talk) 06:34, 4 September 2019 (UTC)

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

Okay. I know that we changed the padlock system not too long ago. However, I would like to propose a slightly changed version of the padlock. Basically, the only difference is the shape of the shackle, and some of the colours. I changed the colours slightly on a few to keep them seperated and not confused. However, I changed cascade protected because it was the same colour as move, and the link symbol could have been confusing because of the thought that the link meant you cant change the link. So Here are the images. --Wyatt2049 | (Talk) or (Stalk) 18:54, 3 September 2019 (UTC)

Proposed Type Current
Gold padlock Fully-protected Gold padlock
Red padlock Permanently protected Red padlock
Pink padlock Template-protected Pink padlock
Silver padlock Semi-protected Silver padlock
Blue padlock Create protected Blue padlock
Green padlock Move protected Green padlock
Purple padlock Upload protected Purple padlock
White padlock Pending changes protected White padlock
Dark blue padlock Extended confirmed protected Dark blue padlock
Black padlock Protected by Office Black padlock
Turquoise padlock Cascade protected Turquoise padlock

So as you can see, the changes are not significant, changes. The most significant is cascade protection. Please leave a comment below whether you support or oppose. Thanks! --Wyatt2049 | (Talk) or (Stalk) 18:54, 3 September 2019 (UTC)

  • There are several aspects to the changes: change of symbols (I have no opinion here), change of colours (again no preferences, but I think the idea of making them more distinctive is definitely a good one), and change of padlock shape (with the shackle's new shape and the way it joins the body right at the edge, I feel like it's not as recognisable as a padlock; at first sight, I would have assumed it was a shopping bag). – Uanfala (talk) 21:18, 3 September 2019 (UTC)
    • I'm with Uanfala. The new ones look more like shopping bags than padlocks. Um, if it's not broke, don't fix it? -- RoySmith (talk) 21:30, 3 September 2019 (UTC)
      • I agree that they look too much like shopping bags. Also, anyone want to test the colors through a colorblind filter? --Yair rand (talk) 22:12, 3 September 2019 (UTC)
      • (Tests with [7].) It looks like this would make the colors of template protection, upload protection, create protection, and extended confirmed protection mostly indistinguishable to colorblind individuals. Also, Cascade would be quite similar to PC. In the current versions, move, cascade, PC, and template protections all look pretty much the same... --Yair rand (talk) 22:31, 3 September 2019 (UTC)
  • Oppose as pointless change. * Pppery * it has begun... 22:36, 3 September 2019 (UTC)
  • Oppose Can we fiddle with the decorations less often please. Johnuniq (talk) 22:59, 3 September 2019 (UTC)

STOP VOTING UNTIL I PUT A NEW MESSAGE. I am currently redesigning the locks to make them more padlock-ey. I will be done very soon. In the mean time, please do not post any votes. Thanks --Wyatt2049 | (Talk) or (Stalk) 23:04, 3 September 2019 (UTC)

@Uanfala: @RoySmith: @Yair rand: and everyone else...I have fixed the padlocks, and they should look better. If you want to support, remove your old message and re support below. Thanks. --Wyatt2049 | (Talk) or (Stalk) 23:38, 3 September 2019 (UTC)

@Teratix: What I have done is made the padlocks slightly taller to make them appear better. I also changed the colour of cascade so it is not to be confused with move protection, as one could think the link means they cannot move it. Please see first paragraph. --Wyatt2049 | (Talk) or (Stalk) 23:44, 3 September 2019 (UTC)
I did read the first paragraph. It didn't change my opinion. – Teratix ₵ 23:47, 3 September 2019 (UTC)
  • Question: I am holding off on voting for now, but are the new colours that are proposed suitable or otherwise capable of being distinguished by persons who are colour-blind or otherwise perceive colour differently (setting aside the cultural and personal differences we all have in terms of colour discernment)? Accessibility is, of course, one of the core principles in universal design, and I do not know if such principles were followed here. (Please don't take that as oblique criticism. I really don't know what steps you took, Wyatt2049.) For that matter, we did make the current locks colour-blind accessible, right? — Javert2113 (Siarad.|¤) 23:50, 3 September 2019 (UTC)
Addendum: oops, sorry, Yair rand, didn't see your comment there. Yeah, this is not good, but I'd still like to hear what processes and thoughts were given to this re-design... — Javert2113 (Siarad.|¤) 23:52, 3 September 2019 (UTC)
  • Oppose unless/until there is a compelling reason to change. People get used to things, it is jarring to change style frequently, these are utilitarian visual aids. -- GreenC 00:07, 4 September 2019 (UTC)
  • Oppose we just went though all of this, not seeing any reason to rehash it so soon. — xaosflux Talk 01:14, 4 September 2019 (UTC)
    As for the specific new ones, I think the arrows etc are to "thin" and harder to read when very small. — xaosflux Talk 03:33, 4 September 2019 (UTC)
  • Oppose Wyatt2049 Thanks for your efforts. I suspect you feel like you are getting dumped on. I also think your heart is in the right place but I just don't see this as a noticeable improvement. I also wonder how many readers are even aware of the nuances of these symbols. I don't have an empirical evidence one way or the other but some will only care that an article is locked not why. MarnetteD|Talk 01:20, 4 September 2019 (UTC)
  • (Summoned by bot) Oppose I don't see any reason to reopen what was a really thoughtful relatively recent process - I'm just not understanding the marginal benefits to the new scheme over the old one. Best, Barkeep49 (talk) 04:36, 4 September 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to Enhance the Request for Comment (RfC) Process

(NOTE: Feel free to edit or expand on my proposal, if you feel it's needed.)

The problem The WP:RFC process is a useful enhancement to Wikipedia, but it seems like the RfCs often stay open on the Talk pages for a very long time, despite best efforts to promote the "feedback service".

The proposal Add the ability to optionally display an RfC on the Article page, either at the top or at the bottom as the community decides. Many Wikipedia pages have tags at the top of pages, so this doesn't seem to be a significant imposition, and may encourage more feedback to a given RfC.

It could be customized with different parameters, time limits, re-listing features, and bots could also be programmed to auto-promote them to subscribed WikiProjects, much like the page move process, which is pretty slick, in my view. Doug Mehus (talk) 18:35, 28 August 2019 (UTC)

Personally I don't think it such a proposed notice should be added to all articles which are a subject of an RfC. First how many readers will know or care about editorial disputes among various Wikipedians? Two not all disputes are equal, some disputes this could be helpful to get outside opinions (either from existing editors or readers/potential editors) while others may not be as useful- although this should probably be done on a case-by-case basis rather than all articles. Adding a notice to WikiProjects however does seem useful, again depending on the scope of the dispute in the article which probably can't be done without human judgement though. Sakura CarteletTalk 23:44, 28 August 2019 (UTC)
  • While I understand where Dmehus is coming from, I think Sakura is correct. I just feel we'd have more participants who didn't know what was being discussed (so many article RfCs are on technical disputes like naming). Adding to WikiProjects seems like a good idea. Nosebagbear (talk) 10:04, 29 August 2019 (UTC)
  • For a single-scope article RfC, adding to that article's editnotice seems fine. As Dmehus mentioned, these notices aren't very useful for readers. For some wide sweeping RfC (e.g. change all dates from 1980 to 1980AD) adding to every article with a date in it would be a huge waste of effort. — xaosflux Talk 10:35, 29 August 2019 (UTC)
  • Thanks all for your replies so far, but @Xaosflux:'s support of such a tag atop (or at the bottom of) a single Article page was all I was looking for. I actually didn't know you could tag multiple article pages or a range of pages, or even whole categories, with an RfC tag, but yeah in that latter example, I can see how that would be problematic. I was mainly looking to generate some interest in a discussion and some questions I posed on a relatively obscure article page's Talk page, that of Talk:Wittington Investments, that hasn't generated any replies and, as I looked through some other RfCs, noticed they weren't generating much interest. Doug Mehus (talk) 15:00, 29 August 2019 (UTC)
  • @Xaosflux: Ah, thanks. I hadn't realized there were edit notices, perhaps because I tend not to involve myself in highly controversial topics (of which that certainly qualifies). The most controversial page I edited was the Onward Together PAC to add FEC filing information about the PAC being in breach of annual filing requirements. Can an editor add these to any page? That could potentially help with preventing WP:BRD page moves. Still, many people don't edit Wikipedia, so some sort of subtle notice like a page move notice on the Article page could be helpful, I think. Certainly more helpful than all of the other banners. But yeah, I definitely think it should be limited to single-pages, possibly with a 60-90 day limit, although it could be re-advertised if the RfC is still outstanding and the editor hasn't lost interest. Doug Mehus (talk) 15:39, 29 August 2019 (UTC)
Is there a way to add a notice that is shown in read mode only by logged-ins users? That way, the vast bulk of anonymous readers wouldn't have to see it, but logged-in folk are more likely to be contrivutors who may have a view on the matter. Kerry (talk) 16:03, 31 August 2019 (UTC)
@Kerry Raymond: it would be technically possible to put a notice up, and have it be hidden from logged out users that have working javascript. However, keep in mind that Wikipedia:IPs are human too and may also be editors. — xaosflux Talk 16:11, 31 August 2019 (UTC)
  • Support. I think a tag at the top of the articles would make sense. We already do it for run-of-the-mill move, split, and merge discussions. Other maintenance templates also encourage linking to a discussion on the talk page. Why not do it for RfCs, which are supposed to be a more heavy lifting process with the explicit purpose of arriving at a broad and strong consensus?
With regards to fears about the influx of people who don't know anything about the ongoing dispute, this is actually what's happening right now when editors mainly arrive at an RFC about an article topic they've never even heard of "summoned by a bot". On the contrary, many of those discussions about "technical disputes like naming" that Nosebagbear mentions are already mandated to be tagged at the top of the article. Even if readers decide to become editors (oh the horror!), curating and closing RFCs is always done by experienced (non-)admins who know precisely which comments to consider and which not. We don't get bad vote-only comments from people who are actually reading the articles. We get them from people canvassed from outside of the encyclopedia. – Finnusertop (talk ⋅ contribs) 16:43, 31 August 2019 (UTC)
Reply to @Finnusertop:, thanks for your support. Yeah, perhaps, as a broader proposal, we could look to imposing a 3-4 Article page header notification maximum limit, to reduce the page clutter, but arguably, per your comments, an RFC notification might actually encourage non-editors into potentially editing Wikipedia or at least contributing to the discussion. In this way, I find it more helpful than a header notification that "[t]his page has multiple issues. Click here to learn why." ;-) So, I'd welcome some additional support so we can move forward on this with a suggestion for a MediaWiki/Wikipedia feature improvement request, for which consensus is required. Doug Mehus (talk) 19:29, 31 August 2019 (UTC)
  • Oppose. This is too close to showing how the sausage is made to the general readers. Interested editors use the watchlist to keep tabs on the pages of interest to them. An RfC tag to the Talk:Page alerts these editors. Also, there is No Time Limit for events in Wikipedia, so time isn't, and shouldn't be an issue. A notice to the project talk pages would be helpful as part of the RfC process, though. Regards, GenQuest "Talk to Me" 20:53, 31 August 2019 (UTC)
  • Support largely per Finnusertop. RfC's on article talk pages almost always revolved around content questions, and for these we need a way to attract participants with a knowledge of the topic, which are normally better represented among the set of editors or readers who are looking at or editing the article, than among the broader wiki population. And given that RfC's should generally be used for important matters, these really ought to be advertised on the page concerned, just like deletions, RMs, merge/split proposals and the like. – Uanfala (talk) 14:01, 3 September 2019 (UTC)
  • Support - Many RfCs could do with more involvement, and such a measure would be a great way to bring new editors into the fold, especially with diminishing numbers in certain parts of the project. It would probably be a good idea to summarise the RfC in said template so general readers/less active editors could be attracted to the talk page if it is an issue that holds their interest:
An example of what it would look like
I agree that it would be a good idea to exclude certain categories of RfC though - my concern isn't so much with users not caring; instead, it is with uninformed users that would just vote for what they prefer, rather than what is mandated by consensus-derived regulation. - Axisixa T C 03:39, 6 September 2019 (UTC)
  • Leaning Oppose - So many RfCs involve a heap of text that includes countless wikiacronyms/jargon. If it were something fairly innocuous and straightforward, such that anyone's judgment would be helpful, then maybe, but I feel like in most cases this is begging for people to apply wikipolicy with no knowledge of wikipolicy. — Rhododendrites talk \\ 13:39, 6 September 2019 (UTC)
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_160&oldid=1073152920"