Wikipedia

Wikipedia:Village pump (proposals)/Archive 142

< Wikipedia:Village pump (proposals)
Latest comment: 6 years ago by Godric on Leave in topic RfC: Proposal - Removal of signature fields
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

Create a new Event Coordinators user group

Latest comment: 7 years ago48 comments26 people in discussion
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.
There is consensus to oppose this proposal. Many participants have come to a common conclusion that editors in editathons ≠ high quality contributors ≠ article creations that don't need a review.Counter-arguments related to CAPTCHA et al don't seem satisfactory.Winged Blades of GodricOn leave 14:15, 18 September 2017 (UTC)

This is a follow-up to the previous RfC about extending the Account Creator user group. Per the comments in that RfC, there seems to be general agreement that there should be some technical means for people who have experience running edit-a-thons and similar events (and have a proven track record of successfully onboarding new editors) to be able to work around the limitations of WP:ACTRIAL during its duration—specifically, the limitation that non-autoconfirmed users can't create new articles. The main objection raised in the previous RfC was that the Account Creator user group wasn't a good user group to use for this purpose since it is given out freely to editors who haven't been adequately vetted for the ability to onboard new editors and thus shouldn't be trusted to grant autoconfirmed status to other users. For this RfC I am proposing the following:

  • A new user group is created called Event coordinators with the following rights: noratelimit (can create more than six accounts in a 24-hour period with Special:CreateAccount), ability to add group Confirmed users (See WP:CONFIRM).
  • This new user group will have the following requirements to be granted:
    • User must be auto-confirmed themselves
    • User must have a proven record of running successful Wikipedia editing events
    • User must have good understanding of key Wikipedia policies and guidelines related to article creation

Kaldari (talk) 21:56, 18 August 2017 (UTC)

  • Support at Wikipedia:Account creator there is text about giving account creation rights to people coordinating events. Account creator userights include the right to make more than 6 accounts from one IP and also some odd rights related to account creation which can cause extra damage. For the sake of event coordinators organizing Wikipedia editing events, we need a userright to bypass the 6-account limit and which admins can grant freely to users who cannot be fully trusted with the extra privileges which come with account creator. This issue has been discussed for several years on the talk page of the account creator rights. In 2018 probably 100 accounts would need this event coordinator right and the use is likely to increase over time. Many people are uncomfortable with the account creator right being granted so freely to so many new users. Blue Rasberry (talk) 22:07, 18 August 2017 (UTC)
    Not seeing how this is much differnt - yes this one doesn't have list override, but it still has wide open throttle override. — xaosflux Talk 22:10, 18 August 2017 (UTC)
Striken then - I am expecting a solution which addresses the technical issue raised years ago, and which has been the focus of discussion since then. I just want new users to be able to create accounts to contribute someplace, and I would prefer to maintain status quo in other regards. Blue Rasberry (talk) 22:52, 18 August 2017 (UTC)
  • Comment @Kaldari: have you seen the discussions at Wikipedia talk:Account creator - talking about event needs? — xaosflux Talk 22:08, 18 August 2017 (UTC)
  • Oppose - Per SilkTork's oppose at the previous RfC, The most appropriate, manageable, and helpful route to creating new articles during an edit-a-thon is via the draft process. - FlightTime (open channel) 22:18, 18 August 2017 (UTC
    • The feedback that I've seen from actual event coordinators doesn't seem to support that conclusion. For example: "I don't know any edit-a-thon organizers using AW+Draft space at events, and personally I've never found AW to be super useful."[1] Kaldari (talk) 22:26, 18 August 2017 (UTC)
  • Oppose I oppose granting account creators or event organizers the ability to make new users autoconfirmed. I've seen no evidence that these new users are better than other new users at creating new pages. New users should work in Draft. The event organizers can use their own accounts and judgement to move anything new into mainspace. That way if there are inappropraite moves we can discuss it with an established user. Or let AfC do it's job. New users should not be starting by creating new pages anyway - they shoudl learn on improving and expanding established articles. Legacypac (talk) 22:23, 18 August 2017 (UTC)
  • Oppose This is an even worse idea. Even an experienced event-coordinator can't oversee all the new editors that show up, not that they would even want to. If anything, admins should be more careful who they give account creator to; we need not create a new user group to fix past errors in judgement. There's no reason to ameliorate the effects of ACTRIAL. All new editors should be going through AfC, no exceptions. Chris Troutman (talk) 22:30, 18 August 2017 (UTC)
  • Support for a different reason Per Gnangarra's comments in the last RfC, The ability of an event coordinator to confirm other users would remove the very annoying and disruptive CAPTCHAs that come up constantly for non-autoconfirmed users. This by itself would immeasurably improve the experience for new editors at editing events. — InsertCleverPhraseHere (or here) 23:00, 18 August 2017 (UTC)
  • Comment @Kaldari: Respectfully, I'm not sure I agree with your reading of consensus on the previous RfC, which you withdrew without an uninvolved closure, as is permitted. I see two main objections to the prior proposal, with the second one being that all new users should go through the draft / AfC process, as argued by SilkTork, Ivanvector, Kudpung, et al. What I do not see is a general agreement that there exists a need to "work around the limitations of WP:ACTRIAL". I wonder if the Foundation seriously considered Cabayi's proposal centred on "event" templates, or Jytdog's idea to recruit reviewers for real-time feedback through the AfC process. I have no strong opinion on the present RfC, but don't read it as significantly different to the prior one. Snuge purveyor (talk) 23:25, 18 August 2017 (UTC)
  • Support as per my comments in the previous RfC, somewhere along the way we forget where we started and the mistakes we made. AfC is the problem, being bitten by that process is the biggest issue in editor retention and positive experiences by new users from workshops. Putting a time limit on being able to create accounts for event organisors would remove the issue of the tool being given to readily and not monitored. As we grow we have a habit of developing fiefdoms and power structures when maybe we should be reminding ourselves "Anyone can edit" and "Assume good faith" before a new process is created and ask are we hindering that. @Kaldari: is trying to address that and refine the previous rfc based on comments there, the opposes so far have raised nothing new they continue to be new user shouldnt be able to create articles not much AGF there. Projects like WikiWomen, Women in Science, Education and many other Wikibombs are specifically aimed at the creation of new content in areas where we lack coverage while at the same bringing in new editors. Either we start to address the concept that we truly want to share the sum of all knowledge and we want to address systemic bias and the cultural bias of editors or we choose to say stuff it this is a male dominated community and only the knowledge of interest to males matters. Gnangarra 23:45, 18 August 2017 (UTC)
  • There is nothing in the present system that hinders addressing any perceived systemic bias. Unless you have evidence that AfC enforces such bias? Allowing a bunch of avowedly single-purpose accounts to by-pass standard procedure on any grounds is surely not A Good Thing. - Sitush (talk) 20:43, 19 August 2017 (UTC)
the current system does hinder many people contributing, not every one learns the same way at the moment we have developed a processes that attracts only one style of learning, the workshops help to attract the majority of learning patterns dont fit into the jump in feet first basket. If we want to diversify the contributor base we need to ensure that there are are differing paths to come into the community and contribute productively. I heard all kinds of arguments put forward, but AFC has back logs and takes weeks to get past, we have backlogs of poor articles but the bar is set so high its actually contributing to those back logs, this proposal isnt about allowing anyone to bypass standard procedures.... Remember those standard procedures didnt exist when were at our peak in growth both in content and contributors the came in to address one issue and created others the end result was a drop in contributors, a drop in content expansion unlike sourcing/citation drive there hasnt been the impact we still get the problems. We keep standard procedures because we enjoy the power it gives us, but we lament the falling growth, and lack of diversity those standard procedures prevent while rejecting the idea that maybe we can do things differently or enable others to do things differently. Gnangarra 02:44, 21 August 2017 (UTC)
None of that addresses your claim re: systemic bias. And, FWIW, we introduced a tremendous amount of crap in the early growth years, eg: the copy/pastes from EB1911 and ODNB, from British Raj sources etc. We're still trying to clean that up. - Sitush (talk) 09:46, 21 August 2017 (UTC)
Systemic bias is definitely a problem around both NPP and AFC. Here's why, as the subject has been researched. New pages and draft require reviewers to evaluate their suitability for Wikipedia guidelines, and many truly good and truly bad articles are easily processed. But the ones that get looked at but not reviewed, or not approved or rejected are typically (and here's the research on it) "time consuming judgment calls". And a key type of TCJC is articles that are "well-written but have questionable notability" (scroll up in the link to see that last term).
Well, that's exactly the kind of articles that edit-a-thons tend to produce. The explicit goal of many Edit-a-thons is to create Wikipedia pages on topics that are insufficiently covered on Wikipedia. Edit-a-thons are, by design, Countering Systemic Bias. These Edit-a-thons teach principles of notability to editors so that they don't created deletable pages, but they don't teach AfC and NPP reviewers how to effectively evaluate that notability for a subject that is chosen precisely because it's underrepresented in the popular imagination. Result: these articles are consigned to purgatory and edit-a-thon attendees learn that Wikipedia is a place where their hard work goes to die.
And we also have research showing us [the net effect of shunting users through AfC]: fewer lasting articles created by new users.--Carwil (talk) 18:14, 8 September 2017 (UTC)
I'm sorry but I have little faith in anything said by people who are closely connected to the WMF. I've previously provided examples showing just how screwed up and incompetent such people can be when it comes to edit-a-thons etc; some are also arguably conflicted from a financial point of view. With a very few exceptions, people who are or have been involved with the WMF should be asked to stay well away from the editing side of this project. - Sitush (talk) 20:29, 9 September 2017 (UTC)
  • Neutral I supported the previous RfC as a measure of goodwill towards event coordinators who said they wanted this during conversations around ACTRIAL. I still don't see it as that big of a deal, but I also think the last RFC revealed that the community didn't want event participants to actually be exempted, and some appeared to be under the false impression that ACTRIAL was a permenant thing that had already been implemented, and were opposed to any exemption from it. Given both set of concerns raised by editathon coordinators and those who opposed the ability to confirm in general last time, I am neutral on this request, but thougut it appropriate to make it clear here since I have been heavily involved with the ACTRIAL conversation. TonyBallioni (talk) 23:56, 18 August 2017 (UTC)
  • Comment: While this is slightly different, I'm not changing my stance from the previous RfC: One of the major objectives of ACTRIAL is to reduce the workload for reviewers and other maintenance workers. Last week an editathon in South Africa organised by the SA chapter and the Swedish embassy was publicised during a TV interview and received a high participation. Unfortunately, the facilitator was ill prepared for the unexpected high participation and a number of articles were produced in good faith but were totally unsuitable for an encyclopedia. It's a shame to have to delete these otherwise good faith efforts. Rather than making any changes to the User Group permissions, perhaps it would be more appropriate for editathon facilitators to teach their students how to edit by getting them to create their articles in their sandbox or or in the Draft namespace instead. Facilitators could them move suitable articles to mainspace for them.
I think that good preparation for an editathon should enlist an admin who will be present or online during the event. The recent editathon in South Africa went wrong. This does not instill confidence that event organisers are automatically any more qualified than anyone else. That said, I would like to invite the comments of RexxS, a highly experience editathon facilitator and qualified teacher and instructor who generally ensures that his editathon students make their creations in their sandboxes. Kudpung กุดผึ้ง (talk) 01:30, 19 August 2017 (UTC)
Perhaps there is a broader question of how much help we give to event organisers in general. I've faced a lot of unexpected problems at events over the years, and eventually you learn how to anticipate the commoner ones (e.g. have a spare laptop and AV cables available), but getting examples of good practice beforehand can help. To be honest, I dislike losing time in creating accounts on the day, so I strongly encourage participants to register an account at least four days before the event. That's the single easiest means of completely avoiding the non-confirmed problems. Sometimes you can't, so I try to catch participants before the event starts (maybe over coffee) and get them registered then without using up scheduled time and keeping a group waiting. Otherwise you need an assistant who knows how to use Special:CreateAccount, who can make accounts while you get the rest of the group started. As for AfC - I simply prefer not to use Draft space, sorry. Despite all your good efforts, the quality of reviewing remains variable, and I much prefer working entirely in user sandboxes, at least until the participants can comfortably add referenced content. Even then, many will not be capable of getting to grips with WP:N, so ought not to be creating new articles until they are somewhat more experienced. In the rare cases where a new editor does have a notable subject with good sources, then I have no problem with doing any moves for them, if needed. I should say that the participant:instructor ratio really ought not to exceed around 12:1 (and half of that is better). It's always a good idea to have a capable assistant who is learning how to be an instructor anyway, as you can never be sure when you're going to be needed to solve an urgent problem, so the assistant can step-in to avoid "downtime". Anyway, my point is that I don't particularly need the ability to confirm new editors. It will be perfectly possible to run an event without it, even when ACTRIAL is running. It just means that some organisers may find that modifying how they work will yield better results. I'm always happy to talk through organising with folks who are uncertain. Please feel free to contact me on my talk page or by wiki-mail, if I can help. --RexxS (talk) 13:32, 19 August 2017 (UTC)
Though I don't do it exactly like RexxS does, my experience with running editathons as the Wikipedian in Residence of a museum is the same as his and, I too avoid the draftspace and encourage people to work in their sandboxes. While I'm not opposed, per se, to this proposal, neither do I have a need for it. Regards, TransporterMan (TALK) 20:24, 19 August 2017 (UTC)
  • Kaladri, one specific point: just dealing with ratelimit does not solve the problem. Many school and some library and university websites have their ip blocked because of persistent abuse--the even coordinator also needs ip block exempt. This would be necessary also. More generally, we also need to provide for unofficial editathons. Anyone can run an editathon, and some satisfactory ones have been done without contacting us at all. (A good number of unsatisfactory ones have been done that way also). Obviously we cannot extend special privileges to those who don't know enough to ask for them, but we shouldn't pose too great difficulties either. Incidentally, I think must people who use the internet are accustomed to CPATCHAs in all sorts of situations--that doesn't bother me.
My experience in NYC is a special situation, unlike many places, we have sufficient experienced event leaders and administrators to deal with this problem for all events that ask us for assistance--even when there are multiple events on the same day. We need to keep the others in mind also. DGG ( talk ) 04:22, 19 August 2017 (UTC)
CAPTCHAs for every single edit are not disruptive? — InsertCleverPhraseHere (or here) 05:33, 19 August 2017 (UTC)
@Insertcleverphrasehere: see Special:Captcha. CAPTCHA's are not required for every single edit at all. Even non-logged in users can make most edits without captchas. — xaosflux Talk 12:44, 19 August 2017 (UTC)
On the contrary, Special:Captcha is clear that "Unfortunately, this may inconvenience users with limited vision or using text-based or speech-based browsers. At the moment we do not have an audio alternative available." This is an accessibility barrier and needs to be resolved. In addition, making edits that add content require sources, most of which will be web-based and hence contain an external link that requires a CAPTCHA. I've had editathons where some well-prepared new editors actually were getting a CAPTCHA on every edit. --RexxS (talk) 13:32, 19 August 2017 (UTC)
I had the same issue at a recent editathon, editors adding external links getting CAPTCHAs on nearly every edit. It actually ends up discouraging new users from adding sources, which is pretty much the last thing we want to do to new editors at an editathon. — InsertCleverPhraseHere (or here) 14:48, 19 August 2017 (UTC)
It is significantly better if the CAPTCHA problem happens at an editathon (where a human can apologise) versus when a newbie is editing at home alone. We certainly should not discourage anyone from adding sources (but apparently we do). —Kusma (t·c) 12:23, 24 August 2017 (UTC)
@Xxanthippe: There are lots of good reasons to oppose but the userright should reduce special interest problems, not increase them. The WMF and other wiki sponsors already funds and encourages hundreds of annual editing events by special interest groups. Right now there is no system for tracking the connection between the sponsor and the wiki editing group, no way of tracking members of a collective editing team, and no way for the wiki community to capture the attention of every individual in a group to direct them to training or alert them to a group problem.
If you wish to counter wiki capture by groups, the place to address this is probably at the level of WMF policy, because so long as they are encouraging and funding this behavior, the problem cannot be addressed by avoiding action at the community level. Blue Rasberry (talk) 13:25, 25 August 2017 (UTC)
  • Support the technical details can be discussed later, but I think this right will help clarify and centralise the discussion and management of event coordinators, by viewing them as a separate group. Overall in the right direction. --Tom (LT) (talk) 08:26, 19 August 2017 (UTC)
  • Oppose I still don't see the need for editathons to bypass ACTRIAL... just going to an editathon doesn't mean you're going to write quality articles that don't need review.. -- There'sNoTime (to explain) 13:39, 19 August 2017 (UTC)
    • There's a misunderstanding here. Anyone can write an article in their userspace and then move it into mainspace without review. During ACTRIAL, it will simply mean that they have to wait four days before they can do that. It should be the case that the delay won't matter to an enthusiastic new editor who may work on an article for longer than that anyway; whereas the typical spammer will find it a barrier. The whole point is to decrease the number of unsuitable articles dropped directly into mainspace, not simply divert them into an ever-increasing queue at AfC. Being at an editathon certainly ought to mean that your work is reviewed there and then, by an experienced editor in person, before being moved into mainspace. --RexxS (talk) 14:33, 19 August 2017 (UTC)
  • Commentary There is still a need for people to "make accounts" at editathons - and auto confirmation is primarily intended to stop vandals; ACTTRIAL actually raises the overall bar for "what autoconfirmed means" here - to me it means "brand new editors" should use drafts - not skip it because they are at a specific location. I don't think having inexperienced edits (such as the ones getting account creator access today) is the way to manage an event at all though. — xaosflux Talk 14:31, 19 August 2017 (UTC)
  • Oppose This is little more than an attempt at an end-run round the previous withdrawn proposal. It has similar problems, as I and others have documented elsewhere. In particular, I documented some specific instances of long-standing event co-ordinators and past/present WMF staff who made the most ridiculous errors. While errors can slip through anyway, I don't trust any carte blanche being given that might imply some sort of "supervote" regarding the quality of submissions etc. - Sitush (talk) 20:31, 19 August 2017 (UTC)
some AGF its not an end run around the previous withdrawn proposal, its the person taking on board the concerns and rethinking the proposal which is what we expect to happen as issues are identified, then addressed by to proponents until we find a solution to an obvious problem. Gnangarra 02:54, 21 August 2017 (UTC)
It is not an "obvious problem" and, as someone else said above and I said on Kaldari's talk page prior to them mooting this proposal, Kaldari seems to have misread the consensus of the first proposal anyway. - Sitush (talk) 09:43, 21 August 2017 (UTC)
  • oppose i oppose this for the same reason i opposed the preceeding one. There is a misconception that new editors putting articles through AfC is any kind of bad thing. It isn't a bad thing. It should be the normal thing and i believe that one day it will the normal thing. Companies have orientation for new people; nobody starts driving without taking drivers ed first. It is not even a little kooky that brand new editors don't create new articles right away. This is just more backwards-thinking workarounds. If there is a desire to get immediate gratification for new editors, the coordinator can recruit an AfC reviewer to review on the fly. Jytdog (talk) 02:02, 21 August 2017 (UTC)
and we are suppose to be a community that anyone can edit and one that has no editorial oversight, yet AfC is both a preventing anyone from contributing new content and imposing editorial oversight on the contributions of others. Now telling event organisors that they need to seek out an approved AfC reviewer we might as well also change the name back to Nupedia or what was that other mob Citizendium or some such nonsense. Gnangarra 02:59, 21 August 2017 (UTC)
Wikipedia is a community that is dedicated to building an encyclopedia for the benefit humankind, and has made much progress in that aspiration. All other considerations are subordinate to that. WP:Wikipedia is not therapy. Xxanthippe (talk) 03:12, 21 August 2017 (UTC).
  • Oppose, the Wikipedia experience for newbies at edit-a-thons should not be substantially different from that of other newbies. If ACTRIAL ends up breaking edit-a-thons, so be it (maybe we'll find out that ACTRIAL is a bad idea). —Kusma (t·c) 12:20, 24 August 2017 (UTC)
  • Support in part: I think the user group/right should exist, but cannot agree with the "proven record of running successful Wikipedia editing events" criterion, since that's elitist and a barrier to getting things done. It verges on self-defeating, since it's people trying to organize such events who need the ability to do this. The cart is before the horse. You don't offer a useful tool only to those who've already proven they don't really need it to get the job done. There are other ways to weed out suspicious noobs from gaining potentially mischief-enabling power they shouldn't have.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  05:40, 25 August 2017 (UTC)
  • Oppose, sounds like a terrible idea. There's no reason to imagine that just because a user shows up at an event their contributions are automatically better than any other user, and a policy to help them avoid scrutiny is wrong for so many reasons. Andrew Lenahan - Starblind 16:50, 1 September 2017 (UTC)
    Actually after several years of editathons we can now say that editathon attendees are different from other newbies. A significant minority of newbies are vandals. I'm not aware of any editathon attendees who have had to be blocked as vandals - experience means we have good reason to believe that editathon attendees are much less likely to be vandals than other new editors. ϢereSpielChequers 20:56, 9 September 2017 (UTC)
  • Oppose per Starblind. – Train2104 (t • c) 18:28, 6 September 2017 (UTC)
  • Support this is good for productivity of new users who receive training at edit-a-thons. (See my comments above.) See if it works on its own. If it doesn't, make the right revokable when a given distributor of user rights creates a cadre of problematic users.--Carwil (talk) 18:14, 8 September 2017 (UTC)
  • Oppose - This proposed user right is unnecessary. Per above votes, we already have "Draft" namespace if newly registered editors want to create new articles. Also, if they want to become Confirmed users, they should go to WP:Requests for permissions/Confirmed, wait for four days, and/or make ten edits to become autoconfirmed users.

    As for edit-a-thons, which are for usually creating new articles (but also improving existing articles if new editors are willing to do so), rather than rely too much on tools, event coordinators/organizers should communicate with ACTRIAL coordinators or WMF if they are concerned about ACTRIAL. Also, they can go to the Wikipedia talk:Articles for creation if they find the AfC process problematic.

    I was going to raise the COI issue regarding this proposed user group, but then I saw one proposed rule saying that applicants should understand existing enWP rules, including the COI guideline, especially if they run edit-a-thons. Still, I don't think another user group is needed unless the community finds the rules to become Autoconfirmed too rigid. --George Ho (talk) 19:50, 9 September 2017 (UTC)

  • Comment — We need new AfC reviewers to deal with the influx of drafts that will come with ACTRIAL. the current situation (without the influx) is already a minor crisis: 1703 backlogged articles as of today.--Carwil (talk) 14:55, 13 September 2017 (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.

RfC about refactoring

Latest comment: 7 years ago1 comment1 person in discussion
  FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Talk page guidelines#RfC: Should the guideline discourage interleaving? #2. The proposal could have significant impact on what is permissible under WP:TPO and WP:REFACTOR.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  10:14, 19 September 2017 (UTC)

Tool to PROD, AfD, or Speedy Delete a class of articles

Latest comment: 7 years ago12 comments9 people in discussion

I came across a large (not sure how large) group of articles with the following characteristics:

  • Biographies of persons who died more than 200 years ago
  • Persons whose biographical references are likely not in English (the ones I found were Japanese)
  • Articles with no references for eight or ten years or more
  • Many were based on Japanese Wikipedia
  • These articles had propagated through the WP mirrors, making searches for original references a real slog

My belief is that a fan of samurai history figured out a way to quickly generate these articles into the English WP without any references. Because the references are likely to be in Japanese, an English language editor is unlikely to ever discover them. Having these article on the backlog will only slow down the task of cleaning it up.

As a general matter, articles for which the best references are not in English, and for which there are not English references and have not been for years, should be left to the editors of the natural language of the article. We should simply delete our musty articles. If they are later offered to English with references, we can take them. In the mean time, the current batch should go.

Technically, writing such a script should not be so difficult. Look for articles including {{unreferenced and {{Japanese name and whatever date parameter you want and you've got your selection tool. The tool can be generalized with the language of the name to help clear the backlog. Waddaya think? Rhadow (talk) 11:14, 20 September 2017 (UTC)

Have you tried searching the contribution history of the creator, including the page creations? Legacypac (talk) 11:23, 20 September 2017 (UTC)
On quick inspection, all the ones Rhadow presently has PROD-tagged are different creators. However, the edit history of Akechi Mitsutada shows an edit summary of "rm reference to Samurai Wiki" - possibly some or many of these were originally referenced from Samurai Wiki, which is less than optimal. ♠PMC♠ (talk) 12:37, 20 September 2017 (UTC)
Ohh hell on closer inspection these are super hinky. Lots were created by Darin Fidika operating under a number of socks, including Cosmos Raver and Exiled Ambition, and others listed at his sock category. The master, Darin, was blocked in 2008 for serious issues including copy-pasting straight from Samurai Wiki. This ANI refers. There is also the page history at User:Nihonjoe/Samurai which describes the effort to clean all this trash up. Even if they're not copyvios now they're not great :| ♠PMC♠ (talk) 12:54, 20 September 2017 (UTC)
Courtesy ping to Nihonjoe since a page in his userspace has been brought up. TonyBallioni (talk) 14:37, 20 September 2017 (UTC)
Anything created by this editor (under any username) is suspect. Feel free to browse through all the contributions by any of them and nominate anything that appears dubious. Given his history, it's entirely likely he's still operating under some undiscovered username, too. He seemed very miffed at being blocked over and over. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 15:40, 20 September 2017 (UTC)
I don't think such a script should be created since it will most likely lead to mass-nominations with serious WP:BEFORE violations. If there really is a group of such articles that need equal handling, such exceptional cases can be discussed at a noticeboard and if consensus is to delete them all, an admin can do so. Or you can create a multi-AFD for a set of them (say 20), tag them with AWB or similar and see if there is actual consensus to handle them all at once; somehow, I doubt it.
But the core assumption that we should delete articles because sources in English do not exist is contrary to WP:NOTENG and WP:NEXIST. If sources exist in any language, then the article should be kept, because readers should not be deprived of information just because some people here cannot read Japanese. Regards SoWhy 15:10, 20 September 2017 (UTC)
Hello SoWhy -- I understand your line of argument. The result of it, though, is a free pass for any article about Flat earth or Pink elephants written prior to 2007, because someone believes there are existing references in Old church slavonic. Pink elephant articles will stay in the list of 280,000 unreferenced articles. It shifts the burden of proof from the reckless copy-n-paster to the hapless volunteer. As long as we celebrate the number of articles created by an editor, rather than the quality, the backlog of unreferenced articles and pointless lists will continue to grow. Rhadow (talk) 16:05, 20 September 2017 (UTC)
I think you misunderstood. Deletion of articles because they are completely unverifiable is perfectly acceptable, see WP:DEL7. What you were proposing though is deletion of articles that are verifiable but just are not yet referenced. That is what I object to, because there is no deadline. Regards SoWhy 16:17, 20 September 2017 (UTC)

Modification of WP:PROF

Latest comment: 7 years ago6 comments3 people in discussion

An editor has started a discussion on the notability guideline for academics. Interested editors may wish to participate in the discussion. Thanks. Ivanvector (Talk/Edits) 14:31, 30 August 2017 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The proposal is to change the guideline to say that Wikipedia should not necessarily have articles about BLPs that meet the NPROF criteria (e.g., "Made a significant impact on higher education"), but about whom editors have been unable to find any WP:Independent sources (e.g., sources that are not affiliated with that BLP and that support the claim about the BLP's research having any effect on higher education).
NPROF is one of the few (perhaps the only) WP:SNGs that does not make the existence of independent sources a universal requirement. WhatamIdoing (talk) 22:34, 30 August 2017 (UTC)
The claim is false. WP:Prof requires many (often 1000) citations to the work of the subject to pass WP:Prof#C1. Debate is at [2]. Xxanthippe (talk) 00:02, 31 August 2017 (UTC).
Yup. Exactly one (1) of the nine (9) criteria requires WP:Independent sources (NB that happening to cite your paper might not technically count as an independent reliable source about you).
That means that eight (8) of the nine (9) criteria – a smidge under 89% of the criteria – do not require independent sources. When 89% of the criteria do not require independent sources, I believe that it is entirely fair to say that the existence of independent sources is not "a universal requirement" under this guideline. I have not yet encountered any definition of universal that amounts to "in just one (1) of the nine (9) options", and until I do, I stand by my statement that NPROF "does not make the existence of independent sources a universal requirement".
I also note, for those less familiar with this guideline, that several of them are entirely subjective. NPROF permits BLPs on anyone who has made "a significant impact in the area of higher education", and it does not require even a single independent reliable source to attest to this claim. According to NPROF, an editor's personal opinion or the prof's university bio is sufficient to establish that the BLP had a "significant impact". WhatamIdoing (talk) 15:23, 12 September 2017 (UTC)
Why are you putting these comments here? The discussion is at the link I placed above. Most of the editors there are not aware of this thread, it's just a notification. Ivanvector (Talk/Edits) 18:02, 18 September 2017 (UTC)
  1. Because a little extra information about the subject of the discussion is more likely to attract interested editors than "Please see Mystery Meat on this other page".
  2. Because an editor replied here, to say that s/he thought I was wrong, and I cannot agree with him/her that "one criterion" is the same as "all nine criteria".
Also, please don't WP:COLLAPSE comments in an effort to stop discussions; it interferes with reading and searching (⌘F) for content on the page. WhatamIdoing (talk) 17:42, 22 September 2017 (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.

Deprecate old parameters

Latest comment: 7 years ago6 comments4 people in discussion

per WP:IMGSIZE, the |image_size= should be deprecated fully from all infoboxes and replaced with |image_upright=. -- Pankaj Jain Capankajsmilyo (talk · contribs · count) 02:55, 20 September 2017 (UTC)

  • Oppose - IMGSIZE does not prohibit the use of pixel specification, it discourages it "except with very good reason". Unless someone can show that there is never a very good reason to use pixel specification in an infobox, we will continue to need support for the |image_size= parameter. ―Mandruss ☎ 09:05, 20 September 2017 (UTC)
  • Support in the absence of any evidence that this is neccessary or desirable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 21 September 2017 (UTC)
  • Support. I was going to say pretty much what Andy said. I've been on this site for about 12 years, and have never even once seen a good case for specifying something like this in fixed pixel sizes. Doing it with images at all makes this site look terrible at notably lower or notably higher resolutions than the average office PC's monitor.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:15, 23 September 2017 (UTC)
  • Support - Fine. If two editors with far more experience than I have are willing to assume that this thread will receive enough attention to decide we will never have a legitimate need for this parameter, I can live with that. I'm all about simplification. But "per WP:IMGSIZE", alone, was an inadequate argument. ―Mandruss ☎ 03:46, 24 September 2017 (UTC)

Upgrade WP:DRAFTIFY to policy or guideline and disallow moves to Draft- or userspace without discussion or consent

Latest comment: 7 years ago100 comments49 people in discussion
There is clearly an overwhelming consensus against this proposal. Biblio (talk) 20:38, 24 September 2017 (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.

Since it's been pointed out to me that currently a number of editors believe in draftifying articles without prior discussion or request/consent (see previous discussions here and here for example), I hereby suggest that the WP:DRAFTIFY portion of WP:Drafts is given the status of policy (or at least guideline) and that it's clarified that moves that are not the result of i) a deletion discussion, ii) an undeletion request, or iii) userfication [upon request] are not allowed, except by an admin as an alternative to speedy deletion (provided the article could have been deleted otherwise).

The reasoning is this: Such moves circumvent the deletion policy by removing articles from mainspace without either discussion at WP:AFD or applicability of WP:CSD. Just as admins are not allowed to outright delete such articles if they don't fall under WP:CSD, so other users shouldn't be allowed to "pseudo"-delete them by removing them from mainspace without prior discussion. While such drafts might still be available (until deleted under a new G13 as proposed after six months), they are removed from the public eye, the result is thus the same as with outright deletion. Also, such moves usually violate WP:IMPERFECT and WP:PRESERVE, since either the topic is notable enough for inclusion - then it should stay in mainspace - or it is not - then it should be deleted.

While I understand that some editors feel that they are actually helping the project by draftifying content that would otherwise be deleted, allowing such moves without prior discussion is too risky, especially if G13 is expanded to allow deletion of all pages in Draft: space just based on age. Regards SoWhy 13:02, 8 August 2017 (UTC)

IMO, any speedy deletable content may be draftified; if it's subsequently deleted under G13, it can be REFUNDed by request of a user who intends to work on it. עוד מישהו Od Mishehu 13:09, 8 August 2017 (UTC)
This proposal is about content that is not speedy deletable. I won't argue that we shouldn't draftify instead of deletion. I've clarified it above. Regards SoWhy 13:13, 8 August 2017 (UTC)
Actually, it isn't. This proposal specifically disallows draftification as an option to non-admins even when speedy deletion criteria apply. — InsertCleverPhraseHere 14:57, 8 August 2017 (UTC)
If an article is about a clearly notable topic, but is so appallingly written that it shouldn't be visible to readers of the encyclopedia in its current form, then moving to draft space is a sensible move until it can be fixed. Peter coxhead (talk) 13:17, 8 August 2017 (UTC)
@SoWhy: I'd recommend waiting on the close for the current discussion to expand G13 before we discuss this. My opinion would change based on whether we'd be retaining these drafts indefinitely or not. ~ Rob13Talk 13:17, 8 August 2017 (UTC)
Unfortunately, the current proposal does not make an exception for such drafts, which is the reason I brought this here in the first place. Regards SoWhy 13:38, 8 August 2017 (UTC)
@SoWhy: I'm not sure exactly what you mean. My point is that if G13 is not expanded and draftifying stuff means indefinitely retaining something unsuited for mainspace, I'd oppose this. If it is expanded, I would need to think on it more, but I'm leaning support. ~ Rob13Talk 15:51, 8 August 2017 (UTC)
  • Oppose PRESERVE says nothing about this (or deletion, by the way), and anyway we have WP:DON'T PRESERVE right below it that points out when removal may be appropriate. While I appreciate SoWhy's concerns, I think they are very far removed from the practical use of this tool and also would serve to create a distinction between admins and non-admins on the use of the move tool. The content that I move to draft is either 100% in violation of WP:V, is speedy deletable, or is an abandoned article that is so poorly formatted with few sources to the point where it would be likely PRODed or CSD tagged and deleted regardless of the actual content in it. Moving content like this to draft to give the user time to improve it rather than taking to to AfD, or PRODing It, or CSD tagging it is the definition of not biting newcomers and BOLDly improving the encyclopedia rather than letting it sit and rot in main space or be deleted. TonyBallioni (talk) 13:21, 8 August 2017 (UTC)
Both WP:DEL and WP:DPR are quite clear on how articles can be deleted: CSD, PROD or AFD. Moving to draft-space? Not on that list. In fact, WP:DPR explicitly mentions it as a potential outcome of a deletion discussion. Saying you move content that is a violation of WP:V or because it's poorly formatted is basically my point: Both are either fixable - then per WP:IMPERFECT they should stay - or they are not - then what's the point of moving it to Draft-space? After all, doesn't policy say Even poor articles, if they can be improved, are welcome.? Regards SoWhy 13:38, 8 August 2017 (UTC)
SoWhy, except draftification is the exact opposite of deletion, which is why it has no business being in the deletion policy. As for WP:V: if there is a two sentence stub about a village with nice palm trees in Foo that searching provides no sourcing and is completely inappropriate for mainspace there are three options: blank and redirect, PROD, or send to draft. Draft:Cantabaco is an example of the type of article that would easily be deleted via PROD for failure of WP:V, but is notable as a named placed and the author should be given more time to update it. Sending it to draft is much better than either redirecting or PRODing.
We also get articles such as Draft:Nerds On Ice that would be G2 eligible. Also ones like Draft:Loctote that were apparently AfC submissions that were accidentally created in mainspace. I can go through countless other examples, but draftification is actually a major tool in upholding WP:PRESERVE, a policy I know you care deeply about. TonyBallioni (talk) 14:00, 8 August 2017 (UTC)
It removes articles from sight, so how is it different from the reader's point of view? As for your examples: If it's a village, WP:GEOLAND says it's notable, so remove the incoherent stuff and leave it in mainspace. The second is an AFD submission in mainspace, not an example of draftifying. The third example is not really something to be proud of. Draftifying within seconds of creation? Most likely the user was working on it but when they were done, the page was gone and they left the project for good. Regards SoWhy 14:21, 8 August 2017 (UTC)
Except that notability isn't the issue. Of course it was notable, the question is whether or not we should delete a notable article that fails our most central content policy (per WP:DEL7) or whether we should give the author time to develop it. I vote for giving the author more time to develop it. Re: Draft:Nerds On Ice, the creator was clearly trying to create a draft article and moving it to the right namespace for them to have that opportunity is already anticipated by WP:PM/C#3. Its the exact same as the AfC submission above, and if it weren't draftified it would have been deleted within minutes via G2 by someone who is much less conservative than I am on G2. I was acting quickly to prevent deletion because the front of the feed is where overtagging for CSD is most common. I'm also pinging Boleyn, who is one of our best and most dedicated reviewers, as a courtesy since you used an article she touched as an example below. TonyBallioni (talk) 14:29, 8 August 2017 (UTC)
But that's the point, isn't it? If the subject is a geographic location, source will exist. So why move to Draft when you could easily spend five seconds on GBooks and add a source? Doesn't that violate WP:FIXTHEPROBLEM? After all, this is a project that strives on collaboration, so why should any one editor be responsible to "develop it"? ICPH bemoans below that "tag bombing" is not the correct solution but how is moving stuff out of sight any different? Both imply that it's somebody else's problem when in fact it's ours. And leaving it in mainspace at least allows others to fix it. Regards SoWhy 15:52, 8 August 2017 (UTC)
SoWhy, the issue is as ICPH points out below that no one fixes it, and per WP:CANTFIX when this is the case it might justify removal from article space. Most of these types of articles require knowledge beyond a simple Google Book search to fix the problem: I know absolutely nothing about the Philippines, and that Google Book search told me nothing that was of use in verifying the content in the article or in creating what you would expect for a geographic article. I assume the article creator will know enough about the article to find sources and improve it and then move it to mainspace. Draft space is a much better place to do this. This is similar to when I remove CSD tags I leave a note for the nominator rather than sending it to AfD myself if I think it should be deleted: I assume the first person who spots the issue is going to be better at explaining their reasoning than I am, and giving them the space to do it is important. I think this principle applies even more for content that someone who isn't a generalist wouldn't be able to verify. TonyBallioni (talk) 16:13, 8 August 2017 (UTC)
(edit conflict) SoWhy. Editor discretion is what is needed to decide the appropriate action in each specific case, not a top-down ban of draftification. If it looks like the editor might keep working on it, I'd draftify an article rather than leave it to get PRODed or worse by another less-kind patroller. A big deletion notice tends to discourage editing... why bother if it is going to be deleted anyway? but draftification with a message indicating how the problems can be solved can encourage further editing. Generally the only editors that see stuff in the New pages feed are patrollers anyway, as these articles are not indexed, so either you are suggesting A) we should tag bomb articles and then mark them as reviewed and hope for the best in 'the wild', or B) that NPP has an obligation to improve every half-baked article with a potentially notable subject that comes into the feed to an acceptable standard, regardless of how bad it is.
All of this supposes whether we are sure that the subject even is or is not notable. In many cases the subject is a two line article with a couple crappy blog sources about some Pakistani actress that may or may not be notable, and all the potential sources are not in english. Or else it is a single sentence article on a long dead scottish playright with one dubious cite to an offline source that may or may not be reliable, or can't be confirmed to exist, and where most other likely sources are offline as well. These sorts of grey area examples are where draftification is often a very good fit, and NPP often is not black and white the way you want it to be. — InsertCleverPhraseHere 16:22, 8 August 2017 (UTC)
I think there is some misunderstanding here. I don't oppose draftifying per se, in fact, I believe it to be a good alternative to deletion where possible. What I do object to is unilateral draftifying, one editor deciding an article is not worthy of inclusion or not fit for inclusion even when it would not be deleted at AFD and speedy deletion is not applicable. The current practice relies on a single editor (sometimes with an user right he got from a single admin (w/o discussion usually)) making the "right" call, often the same people who are unable to apply speedy deletion tags correctly. I know NPP is not black and white, I was a NPPer once as well (nine years ago...damn, now I feel old). But I also know that clear rules are extremely important in this area because these are the editors most newbies encounter first and thus whose actions will have a lasting impact. That's why CSD is so strict and that's why draftifying needs to have strict rules too. And just like CSD it's dangerous if there is not a second pair of eyes forced to check each action. I can think of a lot of alternatives, from allowing AFD nominations with the intent to draftify to a PROD-like system (draftify after seven days if no one objects) but in all cases it needs to be clear that draftifying is only an option if the article were otherwise deleted without a doubt. It can't be (as it has become for some) a way to push sub-standard articles out of mainspace. I welcome any wording suggestions. Regards SoWhy 17:37, 8 August 2017 (UTC)
  • Oppose Draftification is useful. It is often more appropriate, and less BITEy to retain a badly written article for further work as a draft than any other option available to NPP (tag bombing or various deletion options). This proposal seems to specifically only allow admins to draftify articles (even when speedy deletion criteria apply). This would mean that non-admin NPPatrollers would need a whole new system in place to tag articles for draftification instead of CSD if this was their preferred choice. Without some other whole level of tagging that would need to be implemented with the Page Curation tool (good luck getting the WMF to work on this in a timely manner) this proposal would essentially hogtie non-admin NPP into proposing deletion or tag bombing and would remove the option for Draftification from non-admin NPP altogether. — InsertCleverPhraseHere 13:35, 8 August 2017 (UTC)
Speedy deletion uses a four-eyes-principle for a reason: One user tags, an admin (usually) reviews and decides. Unilateral draftification is like speedy deletion without the second pair of eyes. Considering how many things are tagged for speedy deletion incorrectly, one can easily guess how many articles are moved to draft-space that shouldn't be without anyone ever noticing. Why should NPPers who are not allowed to delete pages, be allowed to "pseudo"-delete them in such a manner? Why bother about WP:CSD at all if you can just move everything out of sight? Regards SoWhy 13:43, 8 August 2017 (UTC)
No one is suggesting 'moving everything out of sight', most problem articles are still clearly best served by other options, but it is the best option for some new articles. The only users that can move articles without a CSD on the redirect (i.e. without oversight) are admins and page movers. Policy reflects current practice, not the other way around. What I see is this: Wikipedia:New_pages_patrol#Drafts, as the current accepted practice of draftification as it relates to NPP. If you want to see a change to the current implimentation, I would suggest starting over at NPP rather than trying to pull the rug out from underneath patrollers that are simply trying to find the best solution for each individual problem (and draftification often is the best solution). I don't object to a proposed draftification tag, or something similar being added to the Page Curation Tool, but I wouldn't hold my breath: a proposal to add draftification to the PC tool has been on the list for over 10 months already. — InsertCleverPhraseHere 14:05, 8 August 2017 (UTC)
The problem is not what someone is suggesting or not, it's what is possible at the moment. What policy is stopping someone with "an agenda" from moving thousands of articles to draft? Articles such as Siamese buffalo don't belong in Draft: space, yet there they were. Saying something is current practice does not make it right. In fact, that it is current practice is the reason I proposed this change in the first place. Regards SoWhy 14:14, 8 August 2017 (UTC)
No doubt people make mistakes (though I'd point out that the article you linked above was named Krabue buffalo at the time, so this particular mistake was understandable given there was also no refs for verification at the time). Admins also make mistakes and delete articles that clearly shouldn't be deleted as well (i.e. Speed Langworthy as a recent example that I dealt with the aftermath of), but you don't see me advocating completely taking away admins' power to delete articles do you? I don't object to a clarification as to when draftification is appropriate and when it is not; this would be useful to NPP. I object to your proposal for several reasons that I have stated above. It is unnecessarily restrictive to non-admins and destroys the usefulness of draftification entirely by essentially making it not allowed except as admin discretion during CSD, and removes a useful tool from NPP when we need all the help we can get at the moment. — InsertCleverPhraseHere 14:34, 8 August 2017 (UTC)
Lets also not forget that we have WP:ACTRIAL coming up soon as well, which will essentially mean that all new articles not from autoconfirmed editiors will be essentially forced to use the draft space anyway. It seems to me that you are trying to force the rigid rules of deletion policy on a system that needs flexibility now more than ever. — InsertCleverPhraseHere 14:38, 8 August 2017 (UTC)
@Insertcleverphrasehere: To my knowledge there has never been a consensus amongst NPPers about draftification. Wikipedia:New_pages_patrol#Drafts was inserted recently and isn't the result of any prior discussion as far as I'm aware. Draftifying has crept in because individual users have decided it's a good idea (which is fine), but when it has actually come up in a discussion there have been objections to it. In my opinion SoWhy is absolutely right to seek a wider consensus on this issue. Even if there were a prior consensus amongst NPPers (and again, I don't see one), WP:LOCALCONSENSUS applies. – Joe (talk) 15:05, 8 August 2017 (UTC)
I never claimed any consensus. However, this is how draftifaction is currently implemented by patrollers, both in the tutorial for NPP (for the last 10 months) and in practice as I experience it 'at the coal face' so-to-speak. No offence meant here, but if you had actually done a bit more coal digging yourself you might understand the usefulness of draftification. I respect SoWhy, and I don't dissagree with his seeking wider consensus about the future of draftification (I agree that we need clarification on the dos and don'ts). However, I think that the current proposal is misguided and both of you seem to not quite get why so many experienced patrollers find draftification to be a useful tool in many cases. — InsertCleverPhraseHere 15:29, 8 August 2017 (UTC)
I've never claimed to be a very active patroller, but I wasn't aware that was a requirement for having an opinion on policy. I have been doing AfC reviewing and WikiProject new article monitoring for over five years, if that counts. Not all patrollers agree with draftifying, as you well know, which is why it's disingenuous to declare it the status quo and argue that "policy reflects current practice". That we don't get why draftification is useful is exactly the point: none of the oppose !voters have been able to explain why it's useful beyond that fact that they WP:DONTLIKE the established processes for deletion and cleanup (i.e. "tag bombing"). – Joe (talk) 18:25, 8 August 2017 (UTC)
I presented an argument below. RileyBugz会話投稿記録 18:56, 8 August 2017 (UTC)
I moved Siamese buffalo to draft for very good reason. My edit summary was 'unref sub-stub with no clear indication of notability. Please move back to mainspace when it's ready.' However, that was only part of it, I had spent several hours over weeks on that editor's unreferenced and unclear articles, and was finding no evidence that some were subspecies at all, rather than just, for instance, buffalo in Thailand. The editor had repeatedly refused to communicate and been warned about his behaviour by more than one editor on several occasions. I was hoping that moving to draft would stop us propagating something unverified, as well as encouraging the editor to stop the constant stream of unclear, unreferenced one-line articles. Boleyn (talk) 06:29, 9 August 2017 (UTC)
  • Strong support. I've noticed the draftification trend creeping in for some time now (e.g. perennial requests to make it a built-in feature of the Page Curation tool), so thank you for finally opening it up to a wider community discussion. I understand why superficially draftifying seems an attractive option when faced with tough calls at WP:NPP, but for me it is a very bad solution for two reasons. The first is that it is a form of "soft" deletion. Brand new editors are not going to understand that they have the right to move it back to mainspace if they disagree, and if they aren't autoconfirmed they won't have the technical ability to. In all likelihood most draftified articles are going to hang around in draftspace for six months (possibly bouncing back and forth to AfC a few times first) until they're G13'd six months later. The end result is that an article is deleted based on a single editor's opinion. This flies in the face of Wikipedia:Deletion policy, which requires a broad consensus at AfD, or at least, in in a small number of well-defined circumstances previously established by broad consensus (i.e. CSD and PROD), the agreement of the nominator and an administrator. Proponents contend that the deletion processes are more bitey than draftifying, but what would you prefer: a prompt and clear message that unfortunately your contribution is not suitable for Wikipedia; or being kept in limbo for six months whilst you struggle to jump through the hoops given to you in vaguely worded templated messages, until you give up and it's summarily deleted anyway?
My second objection is that any purpose draftifying might serve is pre-empted by WP:IMPERFECT. Although many NPPers and AfC reviewers seem to think otherwise, there is no minimum quality standard required for articles to exist. If the subject is not suitable for inclusion, you should nominate it for deletion via AfD, PROD, or CSD. If the subject is suitable for inclusion, you should do as much cleanup as you fancy, and tag the rest for someone else to do at a later date. Poor articles on suitable subjects are much more likely to be improved in mainspace than hidden away as drafts. – Joe (talk) 14:46, 8 August 2017 (UTC)
  • Oppose - This makes it so that users don't have to go through a stressful deletion process. It makes it so that, if I find an unsourced science article with lots of jargon while looking at new pages, I can give the creator the opportunity to improve it. More accurately, I can make it more likely that the creator will improve it so that when they move it to the mainspace, they don't have to worry about it being moved back to draftspace. This does violate WP:PRESERVE, but, as stated in the banner at the top of the page, "It describes a widely accepted standard that all editors should normally follow. Changes made to it should reflect consensus." (emphasis mine) This shows that the nature of policy is to describe standard, accepted practice. Thus, we should follow standard practice when we know it, and policy when we don't. This, of course, is overruled by ignore all rules. Anyways, standard practice is to draftify these things instead of having a tag sitting on top of an article forever, with the problem never being fixed. RileyBugz会話投稿記録 14:52, 8 August 2017 (UTC)
Also, we don't need more bureaucracy to slow us down. RileyBugz会話投稿記録 14:53, 8 August 2017 (UTC)
@RileyBugz: Your examples, like so many of the explanations I've seen people give for draftifying, don't appear to me to match policy at all. Why would deleting an "unsourced science article with lots of jargon" even be on the table? As long as it's viable subject, you can tag it with {{unreferenced}} and {{jargon}} at all. Why do you think it has to be in draftspace to be improved? Can't it be improved in mainspace? What if the creator can't or doesn't know how to move it to draftspace, and just gives up instead? – Joe (talk) 14:57, 8 August 2017 (UTC)
I do it because nobody would fix it otherwise. And besides, I move it to draftspace, and then leave a note describing to the creator 1. that I did it 2. where they can find it 3. how they can move it out when they are done. To answer not matching policy, isn't this for discussing policy? RileyBugz会話投稿記録 14:59, 8 August 2017 (UTC)
How is you moving it to draftspace "fixing it"? How is it different from "tag bombing"? In both cases the problem persists, however, in case of draftifying it's now out of sight of "common" editors who might stumble upon it otherwise and fix it. Regards SoWhy 15:57, 8 August 2017 (UTC)
First off, I never said that it was fixing it. What moving the page to draft does is keep a potentially bad page off the mainspace while allowing the creator to easily improve it. Overall, it is a win-win, even if the page wouldn't be deleted by an AfD. Also, I want to present another argument. This rests on the fact that 1. tag bombing is bad, as it is BITE-y and doesn't fix much 2. Not doing anything to an article is slightly bad, as it significantly decreases the chance that somebody will fix the problem, although it does not help BITE the creators or anything. 3. Draftifying is slightly positive in terms of the fact that it helps encourage creators to actually fix their page but slightly negative in that it is a bit BITE-y. This makes Draftifying a neutral process. 4. AfDing an article is the best, as it encourages people to fix it, although in some cases (such as for an unreferenced article with lots of scientific jargon), the fact that people would not have an incentive to clean it up (as they would vote keep no matter what, as you don't have to save it from deletion) makes the BITE factor of AfD outweigh the cleanup part. If we follow this model, we can see that, in some cases, Draftifying is the best idea. RileyBugz会話投稿記録 16:50, 8 August 2017 (UTC)
Tag bombing is NOT the universal solution that you seem to think it is Joe. We currently have 206,011 articles tagged with 'unreferenced' and 320,706 articles tagged with 'needs additional references' on EN wiki. — InsertCleverPhraseHere 15:10, 8 August 2017 (UTC)
@Insertcleverphrasehere: And? – Joe (talk) 18:25, 8 August 2017 (UTC)
I thought my point was clear, but here you go: my point is that tags do next to nothing in many cases. A quick look at Category:Articles_lacking_sources will reveal that there are many articles without sources there that have remained unsourced since 2006. — InsertCleverPhraseHere 20:43, 8 August 2017 (UTC)
"I do it because nobody would fix it otherwise." RileyBugz, I heard recently (but don't have a link) that there's been the effect of putting a page in draftspace. One conclusion: articles in the mainspace are far more likely to be improved than articles in draftspace or userspace. If your main goal is more like "hide imperfect articles from readers", then moving them to draftspace is fairly effective. If your main goal is to get articles improved, then moving them to draftspace is counter-productive. They will get fewer edits and less improvement. Moving the articles to draftspace with a message seems plausible (you're basically trying to bribe the initial editor to make extra efforts, in return for a promised 'reward' of some AFC regular eventually moving the article back in the mainspace), but it doesn't actually work. WhatamIdoing (talk) 02:33, 9 August 2017 (UTC)
  • Oppose: draftifying a new user's article is sometimes better than a long deletion discussion because it is less bite-y and less bureaucratic. For the most part, I trust the discretion of new page reviewers and draftifying is a legitimate alternative to tagging which requires no discussion. I've not witnessed any draftification wars so I think this solution is probably unnecessary. DrStrauss talk 15:04, 8 August 2017 (UTC)
  • Suggest drafting a guideline. I'm seeing good arguments from both sides. At the moment the discussion seems to be leaning "opposed" to flat prohibition on draftification. However I think there is implicit support for a guideline to clarify what is or isn't appropriate. I'm personally leaning to the position that draftification could be a good option, at least in some circumstances. Given the uncertainty here, it would probably be best to draft different levels of allowance/prohibition. Then an RFC can more clearly sort out what we want. Alsee (talk) 15:39, 8 August 2017 (UTC)
Alsee, agreed. I think this is a good solution, and long overdue. One suggestion that I have is that we should have a specific CSD template made up that is to be used on the redirect by patrollers who have draftified articles without admin or pagemover rights. This will tip off admins to review the decision to draftify and check whether the choice was correct when compared to whatever we decide are the acceptable limits of draftification. I think that page movers can be trusted to generally work without a second set of eyes and follow whatever guidelines we decide upon, given the requirements of that user-right, though I suppose this point is debatable. — InsertCleverPhraseHere 15:53, 8 August 2017 (UTC)
  • Oppose. If speedily deletion remains possible, then the lesser recourse of speedy draftification must remain possible. bd2412 T 19:04, 8 August 2017 (UTC)
  • Support It is our policy that "Even poor articles, if they can be improved, are welcome." Pushing an article into draft space is not welcoming. If it is done without leaving a redirect, as I've seen happening then it is effectively deletion by stealth – exploiting a loophole to subvert all our deletion policies. This loophole should be closed. If it isn't then you're going to see move warring and article recreations causing chaos and confusion. Andrew D. (talk) 19:14, 8 August 2017 (UTC)
I'm not sure how others do it, but if a user decides to simply move the article back to mainspace, or to recreate it, I simply give up on draftification and persue other means of patrolling the new page via CSD/PROD/AfD/tagging/etc in order to avoid any kind of move warring. I agree that clarification for patrollers is needed here and I'd like to see some version of this (don't force draft if new users don't want to work in draft) recommended as part of the proposed guidelines in a future RfC per Alsee. — InsertCleverPhraseHere 20:37, 8 August 2017 (UTC)
  • Strong Oppose setting up yet another restriction applicable only to non-Admins that Admins like SoWhy can sanction lowly regular users on is not welcome. There are already so many conflicting rules it is hard to keep track. This restriction will just remove another tool from the toolbox of NPPers that are struggling to keep up with the firehose of garbage pages being created. Many new mainspace pages should have been started in Draft and putting them where they belong is a kind and appropriate gesture. Legacypac (talk) 21:32, 8 August 2017 (UTC)
  • Oppose moving something to draft space counts as a WP:BOLD step that can be reversed. Limiting it to admins will have an artificial divide between activities admins and non-admins can do. Sure, moving to draft space has its disadvantages, but leaving a piece of junk in article space does too. Instead of blocking out this option, explain what patrollers should do, ie notify the writer(s) about the move and how to fix the page up so that it can be returned. Those that think this is a problem can look at the move log to see when draftification happens. Graeme Bartlett (talk) 22:13, 8 August 2017 (UTC)
  • Support I can see no reasons for draftifying. If an article falls under CSD then it should be deleted. If there is a dispute about that, it should be sent to discussion (AfD). If the article is a crappy stub, well, that makes it par for the course. Hawkeye7 (talk) 22:18, 8 August 2017 (UTC)
  • Very strong Oppose - this is a classic example of a solution looking for a problem. There would need to be proof and evidence of misuse of the 'Draftify' solution. Precisely the reason the Draft mainspace was created was for good faith creations that are however absolutely not ready for publication in mainspace. and to undo now would be a significant step backwards. The 'move to draft' is actually used much less frequently than the non NPP voters would claim, and AFAIK, no creators have complained. Of those new articles that I have moved to Draft, the creators have actually thanked me for it. To be absolutely honest, I see this RfC, while in good faith, not only as totally superfluous, but a drain on our time having to respond to it. Kudpung กุดผึ้ง (talk) 02:48, 9 August 2017 (UTC)
    • Well, "less frequently" is a loose term. I don't think 200 such moves in a week alone (cf. https://quarry.wmflabs.org/query/20795) can be considered infrequent. I don't have time now to check all those moves but I am fairly certain not all of them were correct (and those are just moves without a redirect, i.e. those not leaving a trace for a second pair of eyes to check). Regards SoWhy 07:23, 9 August 2017 (UTC)
    • That's a common misconception. In the run-up to the Olympics/Paralympics, the Olympic Project creates many articles on Olympians. In some cases, they are not presumed notable, because they are not considered Olympians until the games begin. But we want to have the articles on them on day one, when the readers will start looking for information on them, so they are kept in the User space until either the articles reach the point where WP:GNG is demonstrated, or the games begin. The Draft space cannot be used for this purpose. The Draft space is reserved for the use of AFC Project. Hawkeye7 (talk) 22:10, 9 August 2017 (UTC)
That's not been my experience, and I think the discussion about G13 at WT:CSD makes it clear this is far from universal. @Legacypac and Premeditated Chaos: both of you have much more experience than I do in this area. Is what Hawkeye saying the current standard practice? TonyBallioni (talk) 00:36, 10 August 2017 (UTC)
Not remotely, which is the entire reason we've been having the discussion at WT:CSD about expanding G13 to cover all drafts in draftspace. Drafts don't get tagged for AfC until someone (usually their creator) submits them to AfC for review. Anything submitted to AfC and subsequently abandoned is eligible for G13. At present, anything not submitted to AfC will not have an AfC tag and will therefore never be eligible for G13. There's no mandate that items in draftspace must have an AfC tag and I honestly have no idea where Hawkeye7 got that impression. (Check out the stale drafts report for confirmation that there is plenty in draftspace without an AfC tag) ♠PMC♠ (talk) 00:55, 10 August 2017 (UTC)
As noted in the links, that is exactly what happened. Articles in the draftspace were tagged for AFC without my submitting them. That then made them G13-eligible. You cannot honestly assert that you have no idea where I got that impression when I have presented the evidence. Furthermore, I note the discussion at WT:CSD#Expand G13 to cover ALL old drafts under which AFC asserts the right to delete articles under G13 regardless of whether they are AFC tagged. The reading of Editors may also optionally submit drafts for review via the articles for creation process by AFC is that any editor may submit any article in the draftspace to AFC, not just the article creators. Hawkeye7 (talk) 21:23, 10 August 2017 (UTC)
You are correct in saying that any article in draftspace may be tagged by anyone for submission. I clearly acknowledged that in my original comment (until someone (usually their creator) submits them to AfC). However, it is not the case that, as you said, anything placed in the Draft space will be tagged with a AFC submission template. Just because it can happen does not mean that it will happen to all drafts. Your experience is far from the norm; if you look at the stale drafts report you will see that the vast majority of those do not have AfC tags and never will. ♠PMC♠ (talk) 05:33, 11 August 2017 (UTC)
How about a way of preventing it from ever happening? Hawkeye7 (talk) 03:37, 12 August 2017 (UTC)
Not the scope of this RfC, so not worth arguing about further here. If you'd like to change the way Draftpace/AfC works, you should make your own RfC asking to prohibit other editors from putting AfC tags on other peoples' drafts. You will almost certainly encounter strong resistance; the possibility of editors finding and improving other peoples' drafts is supposedly one of the main benefits of draftspace so I doubt the community would agree to a measure that would prevent that. ♠PMC♠ (talk) 07:27, 12 August 2017 (UTC)
Which brings us back to the draftspace being AFC's playground, and unusable for any other purpose. Hawkeye7 (talk) 13:00, 14 August 2017 (UTC)
  • strong support - draftifying should be viewed as a type of deletion, ands only be used when outright deletion would be appropriate. עוד מישהו Od Mishehu 03:08, 9 August 2017 (UTC)
  • Oppose Draft-space is a useful 'stick' to motivate contributors, especially UPEs and those with COIs who only care about getting an article into the encyclopedia to improve their articles and avoid perpetual tags. It is also useful as an alternative to deletion, where an otherwise useful new contributor might find that their article is at AfD or speedy deletion because they don't know about the various hurdles and notability criteria that they have to demonstrate. In draftspace, especially if they submit to AfC, they can get feedback regarding this. I agree that this RfC is not in bad faith, and I do think there should be more monitoring to make sure it isn't being used as a 'quick deletion' option, but that fundamentally the option to draftify should remain. jcc (tea and biscuits) 09:10, 9 August 2017 (UTC)
  • Oppose - draftification should be kept as a viable interim step to other deletions. I would support a pohibition on subsequent attempts to draftify if the measure was contested, similar to PRODs, but nothing more stringent.--John Cline (talk) 10:07, 9 August 2017 (UTC)
  • Guideline Per Alsee. A soft delete without due process invalidates Prod, xfD etc. Yet I do see Kudpung's point. In case this is a solution looking for a problem, writing up a guideline will prevent loss of time in the future. Started it, might as well finish it right now...ronazTalk! 11:06, 9 August 2017 (UTC)
  • Oppose you show a picture of a cute buffalo, but what I think about is this. I have nothing against buffalos. So far, I have draftified exactly one article - a rejected AfC draft moved to main by one of nearly 100 blocked socks of a paid editor. It had 68 references, and had been rejected as "improperly sourced". I moved it back to draft space where it belongs. See also Jasmine Directory for a nice example how draftifying a promotional article prompted an editor to come forward, fix it and resubmit through the proper channels. Please consider these anecdotes when writing a guideline regarding draftification. Rentier (talk) 15:34, 9 August 2017 (UTC)
  • Oppose. Moving an article to draft is a substantially "softer" way of doing things than tagging for various forms of deletion on a new editor. It keeps stuff that isn't ready for mainspace out of it, but still keeps what they've done intact to get fixed. There still might be clearly unsalvageable stuff that needs deletion outright, but other stuff can go to draftspace and either become a viable article there or eventually fall into G13. Seraphimblade Talk to me 17:06, 9 August 2017 (UTC)
    • Seraphimblade, who gets to decide what's truly "ready for mainspace"? Should every autoconfirmed editor be allowed to boldly move pages to draftspace, without any kind of notification, discussion, or determination of consensus? What if other people disagree? Should they just boldly move the same article back to the mainspace? And what's the standard for "not ready for mainspace"? Anything that's WP:IMPERFECT? WhatamIdoing (talk) 22:18, 11 August 2017 (UTC)
  • Oppose. Draftifying allows new article creators to learn through feedback and communication, instead of feeling unwelcome – never to return or try again. GenQuest "Talk to Me" 17:16, 9 August 2017 (UTC)
  • Strong support. "since either the topic is notable enough for inclusion - then it should stay in mainspace - or it is not - then it should be deleted." is the key here, really. WP:FIXTHEPROBLEM - shoving a poor article behind a curtain means less chance of editors actually seeing and correcting the article. If a topic is notable enough for inclusion, then it can stay and be fixed, if not deleted. The only argument for draftifying is that an editor (usually they who created the article) is going to expand it - but surely then it can stay in mainspace? I see no real place for draftifying articles on Wikipedia - after all, we are the encyclopaedia that anyone can edit, not the encyclopaedia that require some arbitrary standard of quality otherwise your edits will be hidden from view and forgotten about. There is no difference between draftification and deletion, except that the content is still accessible - if you know where to look. Keira1996 00:09, 10 August 2017 (UTC)
  • Oppose a blanket ban, support the creation of some kind of guideline. ♠PMC♠ (talk) 01:02, 10 August 2017 (UTC)
  • Oppose. If a new editor believes that they can WP:BOLDly move a draft into the article namespace, I do not see why experienced editors cannot, in return, WP:BOLDly disagree with that move, return the page to the "Draft:" namespace, and get the indexed redirect in the article namespace removed via WP:R2. Also, I agree with GenQuest's approach about how to communicate with the draft creator and/or publisher after moving the article back into the "Draft:" namespace; we are not in the business of chasing new editors away, but we have to ensure that the content being published is either up to our standards (usually eligible for WP:CSD) or on the way to becoming an article worthy of being in the article namespace (and thus moved back in the "Draft:" namespace pending further improvements). Steel1943 (talk) 06:22, 10 August 2017 (UTC)
  • Qualified Oppose Move to draft should be retained as an option when the creator has been told what improvements are necessary and there is reason to think they will make these improvements. However, we are no longer in the days when most creators could be assumed to be both competent and willing to follow guidance, engage in discussion and bring their articles up to scratch; it should be discouraged to fill draftspace with pages that have no hope of improvement. Such pages need to be improved by others, tagged, or deleted: Noyster (talk), 07:46, 10 August 2017 (UTC)
  • Strong oppose: Draftifying articles that is still under development or other issues is useful for newbies rather than being bitten by editors. KGirl (Wanna chat?) 20:13, 10 August 2017 (UTC)
  • Strong oppose per Seraphimblade. (((The Quixotic Potato))) (talk) 23:19, 10 August 2017 (UTC)
  • Oppose unless there is data showing that limiting draft moves is beneficial. Esquivalience (talk) 00:49, 11 August 2017 (UTC)
  • Strong oppose per TonyBallioni and Kudpung. Draftifying or userfying is in no way a form of deletion, since the article still exists, and can be restored to articlespace whenever it is appropriate. Inappropriate draftifications or userfications can be dealt with the old-fashioned way, through consensus discussion between editohrs. Beyond My Ken (talk) 13:34, 12 August 2017 (UTC)
  • Oppose  A bold move to draftspace or a "Speedy incubate" is fine, and strongly supported by our fundamental principles.  The remedy to a bold move is a revert.  Imposing a new bureaucracy violates policy. 

    I've written before about this, and Andrew D. points to a key flaw in the current design, which is the semi-auto deletion of the remaining redirect, which causes a loss of information.  Editors can't revert the bold move if they don't know that it is there. 

    If an article is present in drafspace, we need technical support to lockout the creation of an article in mainspace.  This lockout mechanism must not prevent a mainspace redirect.  We also need the ability to edit articles (i.e., add to the edit history) under a redirect.  This is not a proposal here, just elements of what have been many proposals over the years.  Unscintillating (talk) 14:13, 12 August 2017 (UTC)

  • Strong support. We are supposed to be the encyclopedia that anyone can edit. Articles in draftspace are effectively invisible to most editors (=readers), because you will only find them if you know exactly what you are looking for. It becomes a form of deletion by the back door and (with the exception of the cases covered by speedy deletion) deletion should require discussion. I also see draftification being used contrary to WP:BITE. Matt's talk 22:56, 13 August 2017 (UTC)
  • Strongest possible oppose – articles that do not meet notability guidelines such as WP:NFF or WP:TVSHOW, etc., but which are likely to once the guidelines are met to, should be moved to Draft space in the meantime, post haste. It doesn't take an Admin to figure this out – any NPP'er or experienced editor, can figure it out on their own. Making it an "Admin only" thing is another attempt to give Admins "super powers" over other editors. Now, if someone wants to come up with a better policy for when clarifying exactly when this can/should be done, then fine. But banning the practice outright is beyond harmful, and is likely to be roundly ignored even it's formalized. --IJBall (contribs • talk) 03:49, 14 August 2017 (UTC)
  • Oppose - I had never even heard of "draftification" before but I find the oppose arguments above, particularly that of Kudpung and InsertClever...., to be compelling. Carrite (talk) 11:34, 14 August 2017 (UTC)
  • Strong oppose per Kudpung, Seraphimblade, TonyBallioni etc – in many cases, this is the least bitey method of dealing with new articles that have, in their current state, little or no chance of survival in mainspace. It gives inexperienced new editors breathing-space in which to learn what is expected of an article and how to fulfil those expectations, and is – I believe – far more likely to contribute to editor retention than is summary speedy deletion. Our guidelines should be rewritten to clarify that this an acceptable option and an integral part of what the draft space was created for. Disclosure: my name is among the most frequent on the list of such moves provided by Mduvekot above. Justlettersandnumbers (talk) 14:23, 14 August 2017 (UTC)
  • Strong oppose - No, moving articles to draft is not deletion. There is very little upside to this proposal, and significant downside as it would tend to make maintenance much more onerous while bringing down the average article quality in main space. Articles are moved to draft space because they are poorly written, poorly sourced, poorly translated, lack sufficient context, written like essays, or are of unknown notability. It's a simple matter for the creators of any such articles to improve them so that they approximate the quality of other articles, before they are republished in main space.- MrX 15:08, 17 August 2017 (UTC)
  • Strong oppose - qualified reviewers granted such rights, especially for use in NPP and/or AfC are, well...qualified to do so and for good reason. If they abuse the right, there are remedies. I see no reason to keep articles in main space that simply are not ready for main space or that fail one way or another. The quality of our articles is essential to the integrity of the project which is why we have the process in the first place. Atsme📞📧 12:10, 20 August 2017 (UTC)
  • Suppress draft space. This just goes to show how overly complicated our editing process is if things get just bolted on in a Byzantine manner until even veterans don't understand how we are supposed to work. Any article content should be either presentable (in mainspace, even if stubbed), improvable (in the userspace of somebody who intends to improve it), or deleted. Quartium non datur.  Sandstein  07:35, 23 August 2017 (UTC)
    I already provided a counter-example above, where this is not the case. In the run-up to the Olympics/Paralympics, the Olympic Project creates many articles on Olympians. In some cases, they are not presumed notable, because they are not considered Olympians until the games begin. But we want to have the articles on them on day one, when the readers will start looking for information on them, so they are kept in the User space until either the articles reach the point where WP:GNG is demonstrated. The draft space would be better suited to this purpose, if we could use it, rather than having the articles scattered across the User space. Hawkeye7 (talk) 14:31, 23 August 2017 (UTC)
    And I've given two more examples above – films and TV shows that are in the planning phase but which do not yet meet WP:NFF or WP:TVSHOW (e.g. because they haven't yet gone into principal filming/production). All of these are clear examples of articles that would do well cooling their heels for weeks or months in Draftspace until they meet the relevant WikiProject notability guidelines. And it boggles my mind that people think Userspace is better for this than Draftspace... --IJBall (contribs • talk) 03:57, 24 August 2017 (UTC)
  • Oppose, and suggest drafting a guideline instead, per Alsee, et al. We do not promote essay material to guideline status (maybe in Ye Olde Tymes, but not any more), much less tiny bits of them. Doing it with one fragment would encourage a thousand WP:OWNish camps to try to elevate their own WP:PROJPAGE and other essay nit-picks into policies. Guideline wording should be drafted and discussed, for inclusion in a pre-existing guideline page (or policy page, if people think it rises to that level). The "blanket" approach being taken (by most people on both sides) is unhelpful. I agree that guidance on when draftification may or may not be appropriate is needed.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:25, 23 August 2017 (UTC)
  • Oppose. This is NOT a good idea. This just adds more unneeded bureaucracy to the unneeded bureaucracy that is AFC. KMF (talk) 18:20, 27 August 2017 (UTC)
  • Comment Something that might be of interest to those following this discussion. I have had a chat with Evad37, and at my request he modified the User:Evad37/MoveToDraft tool to add a 'Draftify log' functionality similar to the CSD log functionality of Twinkle. I thought it would be useful to have a way to keep track of draftifications afterward. All you need to do to activate logging for the tool is to create a page at User:Username/Draftify log (with your own username in place of 'Username'). — InsertCleverPhraseHere (or here) 06:29, 28 August 2017 (UTC)
  • Oppose. In my experience there is far more of a problem with articles being CSD'd or AfD'd too soon and while the shiny new editor who created it is still working on it, than there is with such articles (which should have been created in draftspace or userspace in the first place) being unilaterally draftified by a more experienced editor. Leaving such articles in mainspace where they will be vulnerable to the many overzealous deletionists runs a significant risk of the first interaction a new editor has with a more experienced editor being the flagging of their article for deletion, which many new editors find so off-putting that they leave Wikipedia forever. Sure, some of them are people we don't really want editing here anyway, but that's not always obvious from a look at the earliest version of an article. WP:BITE, WP:BITE, WP:BITE. —GrammarFascist contribstalk 17:48, 30 August 2017 (UTC)
  • Oppose. I've come across a lot of new articles during the new page review process and I always check for myself if the topic has any chance to pass the notability guidelines. And, surprisingly, about 40-50% of them does, and the articles are well written. The problem is with the new, inexperienced editors who don't (always) know all the policies or where to search for independent reliable sources. Because of this issue, most often noteworthy articles end up being prod-ed. Instead, moving such an article in the user's draftspace (on topics that I'm familiar with I reference the article and review it) gives the opportunity to the editor who created it to learn Wikipedia policies, encourages him (psychologically) to continue and improve his work, get help, and, the most important aspect, the article is not lost. Robert G. (talk) 07:11, 2 September 2017 (UTC)
  • Oppose Per the many opposes above and the farcical convoluted reasonings supporting this proposition. I know from my personal review very few of those supporting actually have walked a mile in NPP or AFCs shoes (and surprisingly show up frequently to argue tortured inclusionist positions). Unless SoWhy is volunteering to be on call 24/7/365 to support these draftifications, the position is untainable. If there is a rogue user incrrectly moving things to draft space we deal with that user via topic Ban (and other forms of ban/block), when we have ~5 users all doing it, then we could consider if this really needs to happen. Until then this is just a policy land grab that takes a useful tool out of the toolbox of all non-admins to preserve content that would be headed to the Shred bin when there could be improvement. Hasteur (talk) 01:56, 11 September 2017 (UTC)
  • Comment A 'new article review flowchart' is being developed by myself and with the input of others over at the NPP discussion board that hopes to clarify and codify the step by step process of reviewing a new page. Development of that flowchart/reviewing instructional tool is ongoing, so any input by others is appreciated. While clarification of a guideline about when draftification should/shouldn't be used is still a priority, this flowchart does identify at least one potential outcome of the review process where draftification is the most desirable action and could be used as a starting point for a new guideline on when draftification is/isn't appropriate. — InsertCleverPhraseHere (or here) 04:11, 11 September 2017 (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.

Wikipedian in Residence at the University of Pittsburgh

Latest comment: 7 years ago2 comments2 people in discussion

Your support is solicited for the Project Grant that can be seen here. Part of the grant-making process requires notification of those who would like to support this project. I am the potential grantee and believe that this position will make a significant contribution to many projects. Some of these are Wikipedia:WikiProject Indigenous peoples of North America, Wikipedia:WikiProject Ethnic groups, Wikipedia:WikiProject Women in Red, Wikipedia:WikiProject Pennsylvania, Wikipedia:WikiProject United States History, Wikipedia:WikiProject Military history/American Revolutionary War task force, Wikipedia:WikiProject Pittsburgh, and Wikipedia:WikiProject African diaspora. Some of these WikiProjects are currently semi-active and would benefit from more contributions from those in the Western Pennsylvania region and the University of Pittsburgh. The University of Pittsburgh has significant archival and historical content related to gaps to these WikProjects. Thank you for your consideration.

Best Regards, Barbara (WVS) ✐ ✉ 23:33, 25 September 2017 (UTC)
WP:CANVASSING KMF (talk) 00:07, 26 September 2017 (UTC)

Bot for automatically listing AfD noms

Latest comment: 7 years ago3 comments3 people in discussion

Apologies if this has been considered before... I can't find it after a quick trawl through the archives.

I notice that with the WP:Requested moves process, once a requested move has been proposed, a bot automatically lists the request at the WP:RM page. Is there any technical or logical reason why the same shouldn't be done with the subpages made for AfD nominations? This would save the step of creating and adding an {{afd3}} template manually to the day's AfD listings, saving time, effort, and one stage in the afd'ing process. Grutness...wha? 02:20, 25 September 2017 (UTC)

New magic word for short descriptions

Latest comment: 7 years ago1 comment1 person in discussion

This discussion was spread across multiple pages, including some village pumps, but organically ended up at a dedicated page. However, we are now at (or beyond?) the stage where this again needs wide publicity and participation. Please see the long discussion at Wikipedia talk:Wikidata/2017 State of affairs#Strategies for improving the descriptions and especially the "Proposal from WMF" subsection (currently the bottom one), where a new magic word is proposed and specific implementations of it discussed.

This is a discussion which will potentially impact all articles and affect the first thing all users get to see in mobile view and on apps (and elsewhere), so getting enough input on this is important. I have posted it at WP:CENT and will also post notices at WP:AN and the bot owners noticeboard. Feel free to drop notes at other places.

Please keep the actual discussion in one place (if this should be here, then close the other discussion and send people here, but please don't discuss in two or more places at once). Fram (talk) 07:02, 29 September 2017 (UTC)

Re-hiding the siteSub "from Wikipedia blah blah"

Latest comment: 7 years ago15 comments8 people in discussion

In the same fashion as when suffixes of browser titles were shortened from "- Wikipedia, the free encyclopedia" to "- Wikipedia",

I suggest removing the text "From Wikipedia, the free encyclopedia" that is displayed below the <h1> page titles. It's pretty obvious we are on Wikipedia, it just adds clutter. Note it is hidden by default in MediaWiki.

Refs:

Od1n (talk) 22:04, 22 September 2017 (UTC)

Od1n, if Monobook, Vector, and Modern all hide it, it sounds obvious to remove it and reduce page size. However since it's hidden, could you post a screenshot of Cologneblue displaying it? I'd like to know what we're considering removing, before supporting removal. :D Alsee (talk) 22:38, 22 September 2017 (UTC)
Just use query string useskin=cologneblue. Also I just noticed cologneblue doesn't remove it from the homepage, contrarily to the other skins. This reveals that skin isn't much supported by en.wikipedia in practice. Od1n (talk) 04:29, 23 September 2017 (UTC)

I remember at one time that the sub-heading at the top of Wikipedia articles read "Wikipedia - the free encyclopeadia that anyone can edit". As Wikipedia has a high Google search, would it be a good idea to go back to putting this at the top of articles, to alert new users to Wikipedia to the fact that this is a wiki Website? Vorbee (talk) 15:56, 23 September 2017 (UTC)

Notice this un-hiding was introduced in 2004. The context was different at that time. It would be like « Facebook, the social network you can register for free! ». Od1n (talk) 20:08, 23 September 2017 (UTC)
@Vorbee : I disagree about your proposal of expanding the text even further. People just don't read this kind of stuff. Od1n (talk) 20:13, 23 September 2017 (UTC)
A little technical clarification. It's actually called the tagline and the text is set by MediaWiki:Tagline. I have posted a notification of this discussion at MediaWiki talk:Tagline#Proposal to hide tagline. siteSub is just an id assigned to the tagline in some skins so it's easy to manipulate with CSS rules. https://en.wikipedia.org/w/load.php?modules=mediawiki.skinning.interface hides it by default with #siteSub{display:none}. For some reason Cologne Blue doesn't assign the id siteSub to the tagline. That's why it's displayed by default in Cologne Blue. MediaWiki:Vector.css, MediaWiki:Monobook.css and MediaWiki:Modern.css override the default hiding in those skins by saying #siteSub {display: block;}. PrimeHunter (talk) 22:34, 23 September 2017 (UTC)
The MediaWiki default for MediaWiki:Tagline is From {{SITENAME}} where {{SITENAME}} is "Wikipedia" here. Wikipedia has many live mirrors. Some are listed at meta:Live mirrors (a lot of those are no longer active). It varies which parts they display and whether they satisfy the attribution requirement in our license. There may be live mirrors where the tagline is the only indication that the page is taken from Wikipedia, but often they just display everything including the copyrighted logo. PrimeHunter (talk) 22:49, 23 September 2017 (UTC)
Some parts of this message's history are very funny. Od1n (talk) 22:50, 23 September 2017 (UTC)
  • Support hiding it in the Cologne Blue skin, since it is in the others and we got rid of it by consensus; the fact this didn't happen in one rather disused skin is just an oversight.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  23:10, 23 September 2017 (UTC)
The original post may be a little ambiguous but the tagline is currently shown in all desktop skins at the English Wikipedia and as far as I know there has never been a consensus to hide it. The tagline is the text "From Wikipedia, the free encyclopedia" below the big "Example" heading at Example. The statements "it is hidden by default in MediaWiki" and "Cologneblue skin shows it by default" both refer to a default MediaWiki installation with no local css like MediaWiki:Vector.css. You personally hide it in User:SMcCandlish/common.css with this line:
#sitesub, .editpage-head-copywarn, .edithelp, .posteditwindowhelplinks { display: none; }
You can log out to see the tagline seen by others. As I mentioned earlier, Cologne Blue doesn't assign the id siteSub to the tagline. That's why your common.css doesn't hide it in Cologne Blue. PrimeHunter (talk) 23:45, 23 September 2017 (UTC)
To clarify:
  • MediaWiki software hides the tagline by default on skins Vector, Monobook, Modern. Then, Wikipedia website un-hides them. I'm suggesting to undo this un-hiding.
Unrelated stories:
  • On Cologneblue skin, MediaWiki software doesn't hide the tagline. Probably an overlook. Thus, Wikipedia doesn't un-hide the tagline on this skin.
  • On the Wikipedia homepage the <h1> and tagline are hidden, except on Cologneblue skin. Probably an overlook.
Od1n (talk) 00:10, 24 September 2017 (UTC)
User:Isarra, are you maintaining this skin, or do you know who is? Whatamidoing (WMF) (talk) 23:33, 28 September 2017 (UTC)
Cologne Blue is maintained by whoever feels like maintaining it at any given moment. If it's behaving in an inconsistent manner to the other skins, patches are always welcome. You may need to make sure to add one or more of the general skin maintainers (me, jack phoenix, matmarex, some others) to be sure it actually gets reviewed, though. -— Isarra ༆ 09:50, 29 September 2017 (UTC)

It should be noted that the same area is used by several gadgets, incl the popular assessment gadget. When making it invisible, you will have to correct those gadgets as well. —TheDJ (talk • contribs) 11:26, 29 September 2017 (UTC)

Latest comment: 7 years ago40 comments12 people in discussion
specific proposal withdrawn; keeping discussion open to see if something that can be worked out that might gain consensus Jytdog (talk) 21:01, 19 September 2017 (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.

This applies to WP:NMEDIA and related guidelines WP:NFILM, WP:NBOOK, WP:PERIODICAL, WP:NJOURNALS, WP:BCAST, and WP:RPRGM.

Propose to add the following to each of the above, in order to accord with the pseudoscience policy WP:PSCI and the according guideline for notability, WP:NFRINGE, by adding the following:

A media property (a periodical, a book, a film, etc) that advocates a pseudoscience or other fringe perspective is not notable if there are not independent reliable sources with significant discussion of the pseudoscience or fringe nature of the content from a mainstream perspective, as described as WP:NFRINGE. Wikipedia articles cannot become coatracks for pseudoscience and fringe notions, under the argument that an article is about a book, movie, etc, and not also about the pseudoscience or fringe ideas that the media property propagates.

-- Jytdog (talk) 21:21, 18 September 2017 (UTC)

!Votes

  • Oppose – the proposal mixes two things: notability can be about more than the (pseudo)scientific content of a media franchise; that such articles don't become a coatrack for various side-topics is about the content of the article, not about its notability. With the above guidance many of Arthur Conan Doyle's writings are in danger of being deleted: they may contain fringey (pseudo)science (while, yeah, fiction, or something Conan Doyle believed in but which was disproved by later science) which may possibly not be discussed separately in literary analyses of these works; another example: "The Unparalleled Adventure of One Hans Pfaall" could no longer have a separate article, while built on pseudoscientific insights (e.g. that there's enough oxygen outside the atmosphere to be pumped in a vessel of waxed cloth for human survival), etc, etc. --Francis Schonken (talk) 21:40, 18 September 2017 (UTC)
We hate coatracks but the above proposal reads too much like burn every house that may likely ever contain a coatrack. --Francis Schonken (talk) 21:44, 18 September 2017 (UTC)
  • Oppose -- I don't care for the phrase significant discussion of the pseudoscience or fringe nature of the content from a mainstream perspective. This language seems to imply that if the mainstream analysis doesn't identify and criticize each and every detail for its inadequacies, then that aspect is off limits for Wikipedia. JerryRussell (talk) 23:41, 18 September 2017 (UTC)
  • Oppose I can see this being gamed already, as while things with pseudosciences can be generally objective, other fringe ideas - or at least what constitutes fringes ideas - can be highly subjective and could be used to shut down topics in political or ideological areas. Fortunately, we do have the requirement at WP:N that works need to be independent of the topic they cover, so a book published by a known proponent of a fringe concept covering that fringe concept is definitely not "independent" for notability determination. It can still be used if the topic is otherwise notable to document what those proponents state about the fringe idea (and we would be remiss in not including that if the fringe idea is notable otherwise per NPOV). --MASEM (t) 23:49, 18 September 2017 (UTC)
  • Oppose If this requires a formal !vote, here's mine. Mostly per myself (below) and Francis Schonken. Headbomb {t · c · p · b} 00:33, 19 September 2017 (UTC)
  • support As proposer. We are currently defenseless against pure COATRACK articles, where "reception" is entirely driven by low-quality but still impossible-to-exclude advocacy websites. Not a single opposer has addressed this. It is not game-able, as every article about a work advocating a controversial subject should have discussion in the Reception section representing the mainstream - or at least multiple - views on the subject matter. If there are none and all the refs are from one perspective, the work is not really notable. We should not have articles that are purely in any bubble. Jytdog (talk) 00:41, 19 September 2017 (UTC)
  • Oppose as written. Uses the difficult to define term "mainstream" as a basis for the entire policy change, which seems like a recipe for ambiguity and constant arguments. Pure fringe sources don't classify as reliable sources anyway, and hence do not contribute to notability. While notability for some articles might be based on sources that are not wholly 'mainstream', WP:NPOV pretty much prevents those articles from becoming advocacy themselves. I don't see how this would improve the encyclopedia, and can see some ways that it could be used to do a lot of damage instead. Plenty of things are notable but only of interest to certain fringe groups, but as long as our coverage is kept neutral, this is not a problem. The examples submitted below by the proposer are not convincing as problems in need of deletion, but rather seem clearly notable and present fairly neutral points of view on the subjects. — InsertCleverPhraseHere (or here) 01:25, 19 September 2017 (UTC)
  • Support in spirit. This is the right general idea, though I can't argue much with the wording concerns raised above. I would treat this RfC has a drafting process not a "do we ever want anything like this?" vote. The central premise of the proposal is already inherent in our policies. It's simply a matter of spelling it out in a way that people don't quibble with it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  11:21, 19 September 2017 (UTC)
  • Oppose I'm not seeing a COATRACK problem. This proposal would require Orwellian denouncements of content in our articles based upon certain Wikipedians' orthodoxies. While critical commentary is needed in articles like Is Genesis History?, we cannot simply delete a well-written neutral article lest the reader come to believe a POV about which some disagree. This proposal evinces an effort to control the narrative which is out of step with our nonpartisan efforts to write an encyclopedia. Chris Troutman (talk) 15:20, 19 September 2017 (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.

Discussion

For examples of where this was an issue, see:

I don't see any need for a specific quack-related guideline/amendment anywhere. In the first case, it both clearly passes WP:GNG and WP:NJOURNALS#C1. In the second case, it's a clear pass of WP:GNG as well (and closed as keep, not keep/no consensus). There's no need to have specific criterion for determining the notability of quack topics, whether the topic concerns quacks themselves, the specific quack theories, quack publications, etc. Journals/Movies aren't considered notable if they lack "independent reliable sources". That covers both quack and non-quack journals/movies. Headbomb {t · c · p · b} 21:29, 18 September 2017 (UTC)

The second is a clear pass only in violation of PSCI. The purpose of this RfC is to change the guideline so that it is clear that WP articles cannot be COATRACKS.
The general N guideline addresses articles about pseudoscience directly at Wikipedia:Notability#Fringe_topics but nothing addresses media that is propaganda for FRINGE/PSCI, and that is a big hole. And if you read the whole close of the creationist fakeumentary, it ends with This leaves us, given the headcount, with a rough consensus for keeping the article (or at the worst, with no consensus for deleting.). Jytdog (talk) 21:36, 18 September 2017 (UTC)
I don't see the coatrack. Reading Is Genesis History?, I find it a dispassionate treatment of the movie as a subject, and stays completely neutral on the subject of the movie. I'm surprised very little non-Christian sources analyze the movie, much in the same way you can find in Expelled: No Intelligence Allowed, but it could simply be no one bothered to look. Or maybe they don't exist because no one outside the Christian world cared. I don't see what either of these articles warrant additions to our notability policies. These articles are notable, both are clear passes of WP:GNG, and no amount of "but it's quackery" will make them non-notable.
As for "but nothing addresses media that is propaganda for FRINGE/PSCI, and that is a big hole" we have something that does cover that: WP:IS/WP:RS. Headbomb {t · c · p · b} 21:43, 18 September 2017 (UTC)Italic text
I will not be replying to you further. Jytdog (talk) 21:48, 18 September 2017 (UTC)
Typical Jytdog reply. Can't land arguments, ignore the person calling you on it. Headbomb {t · c · p · b} 22:23, 18 September 2017 (UTC)
Nope; you don't listen and misrepresent other people and I am not going to derail this dealing with malarky. You will surely write something snarkish in reply, and I will not reply to that. Sorry if you are all sweaty and Ready to Fight but I am not interested. Jytdog (talk) 22:26, 18 September 2017 (UTC)
The second has been stated as a clear pass of GNG, but I would challenge you to actually look for sources. Included in the list of sources keep !voters repeated are WorldNetDaily, Biologos Founadtion, Box Office Mojo, and other advocacy sites (which, regardless of their bias, do not contribute much to notability when posting about their focus subjects on their own websites). In fact, there was an extended discussion defending WorldNetDaily in that AfD. There are a couple other decent names mixed in, but upon further inspection they're simply press releases, screening announcements, brief mentions, and offer no in-depth coverage of the film (let alone sufficient coverage of PSCI/FRINGE, which were relevant issues, but the debate wound up resting on the question of whether PSCI was relevant, with most people uncritical of the claim that it passes NFILM/GNG. — Rhododendrites talk \\ 00:00, 19 September 2017 (UTC)
  • User:Francis Schonken no, it does not mix two things. N is the guideline that implements the WP:NOT policy - it answers the question: Does this topic belong in Wikipedia or not? The basic answer if GNG, as we all know. The idea is that if there are insufficient sources with which we can create an article that is WP:NPOV, the topic is not suitable for Wikipedia. WP:PSCI is part of NPOV. All this does is apply WP:NFRINGE to media properties that are propaganda for pseudoscience or FRINGE topics. The hole that was exploited to create the creationist COATRACK article is clear as day and easy to close. If you really do oppose this, how do you propose we prevent COATRACK articles from existing? (real question) Jytdog (talk) 21:48, 18 September 2017 (UTC)
    • Nah, the proposal is badly written. There can be a significant amount of independent reliable sources that don't delve into the is-it-true-or-not aspects of a literary work (or film, or whatever) that advocates a pseudoscience. On the merits of these reliable sources which discuss the work (without much discussing its pseudoscientific content) it can pass GNG without passing this proposed guidance. So no, wouldn't work. Tries to solve an issue of keeping out coatrack content by forbidding the article.
    Re. "how do you propose we prevent COATRACK articles from existing?" – by keeping out the coatrack elements. Suppose a gifted author writes a beautiful love story, but interwoven with pseudoscience advocacy. Press praises the book for its literary qualities, but largely ignores the pseudoscientific content. If then, the Wikipedians who write the article on that book keep to what reliable secondary sources have written about the book, they avoid the coatrack and keep the article. --Francis Schonken (talk) 22:33, 18 September 2017 (UTC)
User:Francis Schonken Thanks for replying but I don't see how it is possible to keep out RS that promote the pseudoscience. have a look at Is_Genesis_History?#Release_and_reception. What do we do about that? (and really I looked and looked and there is only one source (which is sub-WP:PARITY) that addresses the pseudoscience of this propaganda piece.) I feel you are being too ... glib here. (if you are watching and I shouldn't ping you pls let me know)
If you have ideas about how to improve the proposal, very open to that. Jytdog (talk) 22:38, 18 September 2017 (UTC)
Re. "RS that promote the pseudoscience" – maybe listen to yourself: "RS that promote the pseudoscience" are either not truly RS (then take to WP:RSN to check) or not truly promoting pseudoscience (take to WP:FTN to check). If neither of that helps, take to WP:NPOVN to determine how to incorporate content, in a balanced manner, from a RS that leaves a door open to something that would generally be considered pseudoscience.
Re my ideas "about how to improve the proposal": WP:SNOW (in fact: WP:TNT), this is not going anywhere while it mixes two things: notability (about the existence of articles) and COATRACK (about the content of an article, once its topic is deemed notable enough for existence). --Francis Schonken (talk) 22:56, 18 September 2017 (UTC)
I appreciate your time but we are far from SNOW, and you are not dealing with the difficulties of an article like the Genesis one or similar PSCI advocacy media. We will see what others say. Thanks again for your time. Jytdog (talk) 23:16, 18 September 2017 (UTC)
I think Is_Genesis_History is a perfectly fine Wikipedia article about a notable film. It can't be construed as promotion of pseudoscience as long as there's a link right at the top to the article about Young Earth Creationism. The more unfriendly this place is to diverse content, the more editors will get fed up and leave. Then there will be nothing left but MainstreamPropagandaPedia. JerryRussell (talk) 23:55, 18 September 2017 (UTC)

A more promising try (in the sense of likely to draw support) may be to add a qualifier rather than change the meaning of notability in this sense. By qualifier I mean something like an addendum to the notability criteria e.g. "Note that it is possible for a film to be notable, but to fall short of compliance with other content policies like WP:NOT, WP:FRINGE, or WP:NPOV. In such cases, it is usually preferable to redirect or delete the article rather than retain an article that cannot be developed beyond a stub." — Rhododendrites talk \\ 00:11, 19 September 2017 (UTC)

Stubs are better than redlinks. Headbomb {t · c · p · b} 00:36, 19 September 2017 (UTC)
It is not game-able, as every article about a work advocating a controversial subject should have discussion in the Reception section representing the mainstream - or at least multiple - views on the subject matter. this is problematic statement. Because we are such a wide variety of topics, this idea - while well-intended to prevent promotional regurgitation of fringe theories - would also potentially be applied to topics that do not regularly receive "mainstream" coverage but still are considered appropriate topics for WP here. I agree we have to be aware if all the sources for a topic in a fringe area are strictly all fringe-y, and they are all overly promotional (rather than being a more critical review), that's definitely a good sign that the item is not notable. But even within these fringe fields, there are "reliable sources" that are editorially control, and are reviewing these works from a critical eye rather than a proselytizing view, then that makes the works notable by our metrics. It doesn't matter it is fringe theory, as long as we write in a neutral tone and assign fringe claims to the appropriate attribution. --MASEM (t) 02:33, 19 September 2017 (UTC)
I wonder whether films such as Reefer Madness would be classified as something that "advocates a pseudoscience or other fringe perspective". Presumably Dressed to Kill (book) would be in that category, too. WhatamIdoing (talk) 17:55, 20 September 2017 (UTC)
  • I've withdrawn the RfC but am keeping discussion open to see if agreement on some refinement can be reached. Nobody has put out specific language and I look forward to seeing something like that. Jytdog (talk) 21:04, 19 September 2017 (UTC)
    The movie-article[3] you cited appears to have turned out acceptably. However I have an idea. I haven't thought it through deeply yet. If an article on a topic such as a movie significantly discusses a subtopic such as creationism, and our article on that subtopic explicitly identifies it as fringe/pseudoscience, maybe we should explicitly endorse adding NPOV context for that subtopic. That would apply even if we have no sources about the movie addressing the fringe nature of the subtopic. We would basically just insert text briefly explaining subtopic is pseudoscience and wikilink to good articles addressing the issue. Alsee (talk) 23:24, 22 September 2017 (UTC)
User:Alsee thanks for that thoughts. There is a very fine line between complying with PSCI by doing what you say, and editors committing WP:SYN by doing the debunking themselves instead of citing sources that do the debunking. The WP:FRINGE guideline talks about this some. I try like crazy to avoid the SYN thing. Jytdog (talk) 00:01, 23 September 2017 (UTC)

Define "COATRACK article"?

Taking a step back from the original discussion, maybe the issue should be analysed a bit more thoroughly before solutions are proposed (to avoid "solution in search of a problem" issues).

Maybe a good vantage point would be to give a good definition of "COATRACK article". The obvious meaning would appear to be "an article that is entirely (from start to finish) a WP:COATRACK". Well, if that is the case I suppose the problem could (and should) be addressed by a WP:RM – reasoning: if the entire content of the article doesn't fit under its stated article title, then move to an article title that does cover the content of the article.

But that does not seem to be (not by far) the issue which the proposal above aims to address. So, would it be possible to give a workable definition of "COATRACK article", or, at least, what it stands for in the discussion here? --Francis Schonken (talk) 07:28, 20 September 2017 (UTC)

I just looked at the WP:COATRACK essay again. Its actual title is Wikipedia:Coatrack articles, and sort of defines the "coatrack article" concept in terms of article content, with a variety of advice on how to handle coatrack issues (move the coatracked content elsewhere, remove bias, etc., see Wikipedia:Coatrack articles#What to do about coatracks). Multiple ideas afaics on how to "prevent COATRACK articles from existing", i.e., by transforming them into non-coatrack articles. Again, probably not what we're looking for here (unless, for instance, upgrading the essay to guideline status is what is being sought here – is it?). Maybe the "What to do about coatracks" section can be finetuned, with specific advice on how the type of coatracks that are experienced problematic in the current discussion should be handled. Still, an accurate definition of the kind of coatrack articles we're trying to prevent now (as opposed to the types of coatrack articles already covered by the guidance in the essay) would seem a first step. --Francis Schonken (talk) 08:53, 20 September 2017 (UTC)

User:Francis Schonken thanks for giving some thought to this. In the Is Genesis History article, the "hook" was the movieness (made by X, cast of Y, premiere on Z, box office of A) but the "coat" was the POV celebration of the creationist pseudoscience. I had to reach deep down in the gutter of blogginess to make the reception remotely compliant with PSCI - there are actually no mainstream sources that discuss this movie for what it is - pure pseudoscience. And if I hadn't been able to find that shitty blog that described the movie for what it is, it would still be a celebration of pseudoscience, right here in WP because of a lack of mainstream sources. We delete articles generally where there are insufficient sources to create an NPOV article. The AfD should have been a resounding "delete", but people concentrated on the hook (it's a movie) and ignored the coat. What can happen with this piece of progaganda can happen with any kind of propaganda - Nazi shit, racist shit, MRA shit, whatever shit. Hence the suggested change to the guidelines. There really is a problem with N guidelines that people can cite to allow POV Jytdog (talk) 23:58, 22 September 2017 (UTC)
I can relate to the "lack of mainstream sources" issue, but not in a sense of always being confined to "PSCI" issues. Let me give you an example: In its glory-days we had this separate section on a publication not mentioned in "mainstream sources", which I recently cut down and reformed to the shorter last paragraph of this section. When doing that I wasn't thinking so much about any guidance, just trying to put things in the perspective apparent from available sources (sort of a WP:BALASPS reasoning in the background of my mind I suppose); framing it as a "pseudoscience" topic, would maybe be a bit of a stretch (it could maybe be described as some sort of religiously inspired pseudo-history, and pseudo-history could then possibly be framed as pseudo-science, but framing it thus would probably be too much of a convoluted analysis as compared to any manageable solution that might result from such analysis).
Some topics which have a separate Wikipedia article, such as the article in question, Pontius Pilate's wife, as well as for instance Adagio in G minor, centre almost exclusively around the "reception history" aspect – so, as such, I can't see reception history as a coatrack: some "trivia" growth may need to pruned every once and a while (sometimes drastically, e.g. here), but that's hardly the kind of coatrack we're talking about here I suppose. I mean, "trivia" could mostly be framed as some sort of coatracking, but again pruning of trivia is easier to do without taking the longer and more convoluted road of framing it as coatracking before just weeding it out. In sum: reception history can be a fickle thing for some topics, but hardly ever, imho, does it need to be framed as coatracking, and even less should reception history be deemed innately 'suspect' (from a PSCI angle or whatever).
The specific problem for the Is Genesis History? article rather seems, imho, its "recent history" aspect. To a certain degree that was a problem playing in the BWV 565#Reception section, so I can relate to that somewhat (although I mostly stay out of recent history articles because of that kind of difficulties, respecting editors who take such challenges all the more). In a first step I'd say that for such topics the "reception history" aspect rather needs to be framed as falling under the WP:BALASPS policy, without worrying too much about the PSCI aspect. (NPOV trumps PSCI in the domain of reception history if you want it in a short formula). Sure, creationists had their field day with the Is Genesis History? film. Maybe a Wikipedia editor should be able to say to themself: let them have their field day, I don't care, I don't "write" history, I record it. Is Is Genesis History? a pseudo-documentary? Probably, but until a reliable source says so, we can't put it in Wikipedia. Wait a few years until someone writes a history book about the surge of creationism in the early 21st century, and uses the film as an example. Until if and when that happens, make do with the reception history sources as available, pretty much what has been done up till now in the article. I'd maybe have the "mix of history and philosophy" comment (which I found truly insightful) somewhat higher in the article, maybe even in the lead, but if that commentary can only be found in a blog, it would probably need to stay where it is now (or even be removed when it can be replaced by the commentary from a more reliable source).
Anyhow, as far as the rewriting of guidance goes, I don't see a need for it (yet) – we'd also need more than one or two examples that indicate a "trend": tailoring guidance to problems that occur only in one or two articles hardly ever finds consensus. Don't let that stop you from formulating analyses or proposals that might make it clearer why and how such updating of policies and guidelines would be indicated. --Francis Schonken (talk) 09:08, 23 September 2017 (UTC)
OK thanks for your thoughts. I am stewing on them and appreciate the time you took to write them. Jytdog (talk) 07:04, 29 September 2017 (UTC)
Jytdog, you appear to be saying that "Is Genesis History" shouldn't have an article unless somewhere in it we say creationism is pseudo-science (using those very words). The thing that persuaded me to vote 'keep' there was at least one review written by scientists who were christians. They chose one example used in the film (formation of Grand Canyon) and pointed out how implausible and inconsistent all the claims made in the film about the GC were, they then went on to argue that creationism is NOT the orthodox historical christian belief and is not, and never has been, necessary to being a christian. They argued that the film presents a false dichotomy between science and religion (as IMO do many notable atheists). This may not use the specific words 'pseudo-science', but they are clearly of the opinion that the film's science as well as its theology are plain wrong. To me personally, this review was a great deal stronger because it DID come from a christian source.
Your general point however "what can happen with this piece of progaganda can happen with any kind" is true. I first became involved with WP because of a film which adopted a very particular, very contentious, viewpoint on the Yugoslav wars. The film was so fringe that it had never been reviewed anywhere, and certainly not outside its ethnic/political base. It took 20 months on and off, several ANI's and a few SPI's before the article ceased to be a mirror of the filmmaker's website, by which time it had 'done its job', ie given a veneer of respectability to a dangerous piece of propaganda. As so often on WP, failure to implement existing policy, rather than lack of policy is the problem. Pincrete (talk) 14:01, 1 October 2017 (UTC)

Frame as issues regarding reception content of recent history topics?

If we can leave the "COATRACK articles" approach aside, which imho seems somewhat at a dead end anyhow (see my last comment in the previous section), we could maybe define the problematic area as "recent history" topics often lacking reliable (secondary) sources to cover reception-related content. Then we could tie this with an elaborate field, covering many articles, which has come under heightened scrutiny of Wikipedia editors recently, e.g. Wikipedia talk:What Wikipedia is not#Proposal for new section under "Not a Newspaper: Not real-time news reaction, commentary, and analysis. Not that anything practical has come out of these deliberations yet, but at least we're no longer talking about "one or two articles". But also no longer in a "seek ways to nuke the entire article" dynamic (which I consider another route at a dead end here). --Francis Schonken (talk) 13:24, 23 September 2017 (UTC)

Loves Monuments

Latest comment: 7 years ago4 comments4 people in discussion

We are supposed to be ad-free, even though St. James himself proposed adverts, overruled thanks to the Spanish Fork.

But now we get incessant advertising for internal odds & ends of our own(e.g. monuments) - not unlike the BBC, which carries endless adverts, though only for its own stuff.

Could someone stop this nuisance, or at least have a poll to see if it is wanted— Preceding unsigned comment added by JohnWheater (talk • contribs) 12:40, 29 September 2017 (UTC)

You can switch it off by clicking on the cross--Ymblanter (talk) 20:01, 29 September 2017 (UTC)
It comes back every now and then. --Treetear (talk) 15:36, 1 October 2017 (UTC)
I don't think that I've seen these yet. —PaleoNeonate – 23:00, 1 October 2017 (UTC)

InternetArchiveBot notices about nothing but archive-url additions

Latest comment: 7 years ago1 comment1 person in discussion
  FYI
 – Pointer to relevant discussion elsewhere.

Please see: WP:Bots/Noticeboard#InternetArchiveBot notices about nothing but archive-url additions

Summary: Proposal to have InternetArchiveBot stop posting one specific kind of notice on article talk pages – namely that it's just added an archive-url to a citation template. The reasoning is that it's a triple-notice (watchlist hit, notice post, and watchlist hit of the notice post) of trivia that doesn't need any human intervention, and clutters talk pages. An opposing view is that all bot notices are useful.

Will not affect InternetArchiveBot notices that may need editor examination, such as problem reports or notices of attempts to repair broken URLs.
 — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  22:48, 4 October 2017 (UTC)

New Twinkle Log

Latest comment: 7 years ago2 comments2 people in discussion

I have no idea if this should be posted on Phabricator or not, feel free to file it in the appropriate venue.

I have Twinkle set to make CSD and PROD logs automatically, this is great and I link them on my talk page to keep track of things I have nominated for deletion. However, I have to manually update my XfD log every time I use Twinkle to create an AfD, this is time consuming and could easily be automated.

Please add an option for a AfD log in Twinkle preferences.

Obviously this would only work for AfD's started with twinkle - the vast majority, and would be an optional log, switched on/off in the same way as the CSD ad PROD logs. Dysklyver 15:44, 5 October 2017 (UTC)

  • If someone wants to volunteer their time to do it, sure, but per my typical "don't waste volunteer developer time when we have something else that is functionally the same" comment on a lot of our tech requests, I don't see how it would be any different than the AfD Stats tool, which is actually better because it shows the outcome. TonyBallioni (talk) 16:03, 5 October 2017 (UTC)

Features for readers

Latest comment: 7 years ago2 comments2 people in discussion

From a readers perspective it would be awesome if there would be a feature where I can put different articles on a "to-read" list, and also have a "read" list of all the articles I already read on wikipedia. Right now as far as I can see, registering on wikipedia is only useful for editors. LuxMaryn (talk) 12:06, 6 October 2017 (UTC)

@LuxMaryn: This will soon be available in the mobile app. Please take a look at mediawikiwiki:Wikimedia Apps/Synced Reading Lists. --Izno (talk) 12:56, 6 October 2017 (UTC)

Proposal to go back to calling "Main" "Article" on edit count on Wikipededia

Latest comment: 7 years ago2 comments2 people in discussion

If one goes to "Contributions" one can then do an Edit Count. If one goes down far enough on this page displaying one's edit count, one will see a pie chart listing percentages of the different contributions one has made. I am sure that there used to be a section of this pie chart called "Article", but I now think it is called "Main". My proposal is that we go back to calling this section of the pie chart "Article" - calling it "Main" may confuse some Wikipedians into thinking it is to do with Wikipedia: Main Page. Vorbee (talk) 16:38, 8 October 2017 (UTC)

Hi @Vorbee:, that chart is from an external link to the xtools utility. You can use this link to request changes to xtools. — xaosflux Talk 02:03, 9 October 2017 (UTC)

I propose that WMF begin work on my rewards incentive system

Latest comment: 7 years ago5 comments5 people in discussion
Absolutely no chance that this or anything like this will be adopted here, as has already been stated by Iridescent, so continuing this thread is pointless. BencherliteTalk 23:48, 10 October 2017 (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.

This is not paid editing, on the contrary. I am opposed to paid editing because it is wrecking parts of our encyclopedia. My proposal and its design is explained here. - Shiftchange (talk) 18:50, 10 October 2017 (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.
Latest comment: 7 years ago2 comments2 people in discussion

More than once I've enquired (not here) about whether it would be feasible to create an automated list of redlinks, which would appear much the same as Special:AllPages, except all the entries would be red.

One could peruse the list, and finding that there are, say 20 redlinks for Pope Donald III throughout WP, and having established that they are not vandalism or typos, one could set about either creating an article for said Pope Donald III (assuming notability can be established), or delinking the redlinks - in either case eliminating 20 redlinks. This would serve a very useful purpose.

The first time I raised this idea, some years ago, it was knocked on the head immediately as being beyond the capacity of the system at that time. Have things marched on, technologically speaking? Is this now a goer? It seems a glaring omission from the wiki-way of doing things. -- Jack of Oz [pleasantries] 19:33, 12 October 2017 (UTC)

Jack of Oz you could try Special:WantedPages, however that list is not restricted to mainspace, and redlinks-in-templates get counted for every instance of the template. The (current) top result is Talk:Jay Obernolte/GA1‏‎ (48,618 links). A Wikiproject Games template spamed that link on every game's talk page. You'll probably find WP:Most-wanted_articles more useful. It hasn't been updated in 17 months, but it has close to a thousand links. Only about 16 of those links have turned blue. Special bonus for Sumo fans! 1953 in sumo through 1984 in sumo are all in demand! :D Alsee (talk) 07:02, 13 October 2017 (UTC)

Adding license information to image

Latest comment: 7 years ago4 comments4 people in discussion

I would like to propose a license captions on the image across Wikipedia. It may be same as found on Wikimedia blogs. As Wikipedia follows Attribution-ShareAlike 3.0 Unported {{Cc-by-sa-3.0}} License the term of ATTRIBUTION too will satisfy by this step. As the pixels of image in info box is around 220px only the license on commons or fair use shall be displayed. Further comments on improvement shall be accepted --✝iѵɛɳ२२४०†ลℓк †๏ мэ 05:15, 11 October 2017 (UTC)

Oppose: A well intentioned proposal, but I see little likelihood that we are going to clutter every image with a text overlay. Alsee (talk) 07:14, 13 October 2017 (UTC)
Oppose: The information is generally one click away. —PaleoNeonate – 09:30, 13 October 2017 (UTC)
Oppose per both of the above. License information of no use or interest to 99.9% of readers. ―Mandruss ☎ 09:57, 13 October 2017 (UTC)

The legacy of User:Allen3

Latest comment: 7 years ago12 comments9 people in discussion

User:Allen3 has died. He was for many years a vibrant and active editor and admin. He was kind. He was helpful. The last edit he ever made was to give helpful advice in a discussion.

When a productive Wikipedian leaves us, we remember them, and we preserve their legacy. We strive to finish their work. Allen3 was a busy content creator. He left over forty drafts in various stages of production. As we would hope for any of our drafts, let's finish his. Let's get them into mainspace, maybe even into DYK, which Allen3 loved, and into the best quality we can muster.

They are:

Thanks. bd2412 T 22:36, 5 October 2017 (UTC)

Very sorry to hear about this. I am generally interested in history articles of any sort, so perhaps I could work on a few of the drafts. Biblio (talk) 16:16, 8 October 2017 (UTC)
Great! There are 42 of these, so if we could get a dozen editors to each adopt a handful, they would be covered. Fortunately, Allen3 got most of these off to a good start with a rough outline of the notability of the individual, and sourcing to support it. bd2412 T 16:52, 8 October 2017 (UTC)
I'll take Stoddard. What's the procedure to "claim" these? Just move the page? MB 01:38, 9 October 2017 (UTC)
@MB: that is fine, certainly use move and not copy to maintain attribution. Moving User:Allen3/Stoddard to Draft:Isaac Taft Stoddard for example is perfectly fine. — xaosflux Talk 01:59, 9 October 2017 (UTC)
I deleted User:Allen3/Camp Grant that was just an infobox for an article we already have (Camp Grant massacre). User:Allen3/gosper was a substantial expansion of the pre-existing John J. Gosper, so I hist-merged it to there. It needs cleanup of some sentence fragments if someone wants to do some simple editorial work; I'm out of time at the moment. DMacks (talk) 05:37, 9 October 2017 (UTC)
I will take the E. B. Gage draft into my userspace and work on it for the next few months. RIP, Allen3. A Traintalk 12:38, 9 October 2017 (UTC)
I will pledge to work on Clark Churchill. I've got a deadline looming this week, will get it up there next week. Carrite (talk) 17:14, 12 October 2017 (UTC)
I'll do User:Allen3/l zeckendorf. Eddie891 Talk Work 01:26, 13 October 2017 (UTC)
User:Allen3/Mac exists. RIP Allen. Eddie891 Talk Work 23:57, 13 October 2017 (UTC)
Dibs on User:Allen3/diamond please. ♠PMC♠ (talk) 01:59, 13 October 2017 (UTC)

RfC: Article Wizard Redesign

Latest comment: 7 years ago38 comments31 people in discussion
Closing per WP:SNOW - unanimous support, and the minor formatting notes don't necessarily need an RFC to implement. Primefac (talk) 14:01, 14 October 2017 (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.

In light of the positive feedback from the new user landing page, I expressed a need to redesign the article wizard primarily in an attempt to combat the common issues seen at AfC, with the secondary purpose of it "flowing" better in conjunction with the new user landing page.

I would like to propose that we adapt this redesign as the new article wizard. Drewmutt (^ᴥ^) talk 01:58, 4 October 2017 (UTC)

Survey

Threaded discussion

Finer issues are:

  • Standardization of colour of buttons (blue=we want you to do this;white=we do not care;red=look before you leap)
  • Introduction to the word notability somewhere in the wizard
  • Wording of the buttons(should they all be next or should they say some thing about what is to follow)
  • A emergency help button somewhere in the wizard linking to either WP:TH or live help chat.

These issues need to be resolved .On the whole it is certainly better than the old wizard.-(User:Forceradical on a mobile)-150.107.215.6 (talk) 11:27, 5 October 2017 (UTC)

The Create Draft page states that "When you create your draft, it won't be publicly viewable." However, drafts are in fact publicly viewable, just not searchable. Perhaps we could reword this sentence so new editors are not misled? Otherwise, this is awesome. Thanks! Tony Tan · talk 17:49, 6 October 2017 (UTC)

I don't feel like the proposed wizard addresses notability sufficiently. While it is mentioned that articles need good sourcing, I don't think it gets the point across that article topics need to be notable to be accepted (it doesn't even mention notability, I believe). Thoughts? Darylgolden(talk) Ping when replying 00:54, 7 October 2017 (UTC)
I think what Drewmutt was trying to do was simplify it and get away from the wall of text approach of the current wizard and WP:YFA. Those approaches haven't been working in actually improving draft and article quality IMO. I think we could have a For more informations see Wikipedia notability type thing, but we need to remember that most people who create new articles as new users aren't going to be the type of people who regularly visit project space and are aware of the minutia of WP policy. Some people read the manual, others just want a summary. I think the redesign does a good job of getting the basics (you need high quality sourcing) without turning people off with in-depth policy discussions. TonyBallioni (talk) 01:46, 7 October 2017 (UTC)
Not to mention, if they can't find good sources about something (as the proposed wizard asks them to do), it's likely that it isn't notable anyway. — Gestrid (talk) 18:17, 7 October 2017 (UTC)
But practically speaking 95% of people submitting drafts are going to be told that "this subject does not meet the notability criteria for blah blah blah..." The current wizard is far too complex and confusing, but there needs to be a step (probably the first step) that says something like,
Wikipedia is an encyclopaedia built on verifiable information from existing reliable sources. Not every topic is suitable for inclusion.
Has the topic you want to write about already been written about by multiple, reliable sources that are independent of the subject?
Otherwise we're simply not being up-front about the number one criterion the draft will be reviewed on. – Joe (talk) 12:23, 12 October 2017 (UTC)
  • Yes, I agree the colour of the buttons needs to be standardised, for example at this page the blue could be taken as an encouragement for users that saying that they're unconnected is the "right option" and "I'm being paid to edit" is the "wrong" option. Additionally, at the welcome page blue is used as the "escape" option, whereas later on it's used as the "proceed" option. jcc (tea and biscuits) 21:56, 7 October 2017 (UTC)
Added link at CD to generate more community involvement since this is a major change affecting a lot of people

Feel free to revert if inappropriateForceradical (talk) 11:15, 11 October 2017 (UTC)

There's a lot to like about this draft:

  • Cleaner
  • I like the encouragement to try out their own sandbox
  • I like the handling of COI and paid disclosures

There's always a tension between clean design and walls of text. Many such things start out clean, then many editors want "just one little thing" and it becomes a wall of text. Rinse and repeat.

That said, my primary concern is the list of things that are not acceptable references, with "not" being emphasized. Some of those things "do not count" when assessing notability, but are not forbidden as references. I ought to suggest alternative wording, but I haven't come up with anything acceptably succinct. One possible option (which might also address some concerns of others), would be to say something like "Your article will be rejected, unless you provide references to independent, reliable sources which demonstrate Notability." Then modify the list description to clarify that those things do not demonstrate notability.

I also concur with the comment that the phrase "When you create your draft, it won't be publicly viewable." needs tweaking.--S Philbrick(Talk) 15:47, 11 October 2017 (UTC)

While "Reviews can take a long time, and are reviewed in somewhat of a random fashion, so please be patient and know that your draft will be reviewed eventually." Is true, there must be a way of saying this that sounds less off-putting and dispiriting. Something like: "When you create your draft, it won't be publicly viewable. However, when you finish, you'll be able to submit it to be reviewed. Article drafts from new editors are reviewed by experienced editors to check they are compatible with our policies. Because everyone is a volunteer this may take some time, so please be patient, rest assured your article will be reviewed in time" or something AlasdairEdits (talk) 16:39, 11 October 2017 (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.

Lint errors discussion place

Latest comment: 7 years ago13 comments6 people in discussion

There should be an official place for discussions regarding Lint errors. There are numerous issues I would like to discuss, and, not to start those discussions here, but just to give a sense of some of the scope, here are some:

  • Is there a way to run an individual page through all lint tests, or just one lint test? If not, how soon can this tool be constructed?
  • Each page's "Page Information" link provides a page that tells how many errors of each type of lint error the page has. This should be enhanced to provide some further information such as what is displayed on each of the Lint errors page, e.g. edit link, some error text, and "Through a template?"
  • Some of these Lint errors would be relatively easy to fix with bots, especially Multi colon escape. Are there plans to create such bots?
  • Why, when a new type of Lint Error is added, do the numbers continue to grow for an extended period? Is it that it takes a long time for the linter to process every Wikipedia page, or that the definition of the error expands, or other factors?
  • For each type of Lint error, should Wikipedia editors attempt to correct these errors at all, or just wait for a bot to fix at least some of them?
  • Are there pages that should not be fixed, for example, sandboxes, user talk pages, Wikipedia talk archives? If there were an official reference on this, then editors would not worry about others objecting, and they would also be able to say to anyone who objects
  • Which pages should the user be reasonably certain of fixing correctly on the first try? For example, if it is OK to edit User pages, it might be good etiquette to get each fix right the first time (if necessary, by experimenting in the editor's own sandbox).
  • Are there plans to improve the ordering of errors? If page information reports that there are "Misnested tag with different rendering in HTML5 and HTML4", it can be a major search effort to find the indication on Special:LintErrors/html5-misnesting, in order to fix the errors.
  • The Wikipedia edit page, upon "Show preview" and "Save changes", should warn Wikipedia editors of any newly-added lint errors. Arguably, new High Priority errors should prevent a page from being saved.
  • Can we make the help link more prominent on each Lint error page?
  • Can we enhance the help pages to discuss other errors, such as unclosed tags or unclosed tables, that are known to frequently trigger the topical lint error?
  • Can we improve the diagnostic to better localize the error?

Again, I don't want to have these discussions here. I just want a unified place to have these and other discussions. —Anomalocaris (talk) 07:23, 4 October 2017 (UTC)

Sounds useful, feel free to start up Wikipedia:Lint errors and an associated talk page or the like. We can link to it from MediaWiki:Linterrors-summary that displays at Special:LintErrors. — xaosflux Talk 12:12, 4 October 2017 (UTC)
Alternatively, we can have the discussion first (probably better at WP:VPPOL or WP:VPT) and then start a page with a working set of rules. --Izno (talk) 12:24, 4 October 2017 (UTC)
Put it at VPT not not VPPOL if you have the discussion. I'm sure there are many of us who have no earthly idea what a lint error is. I'm currently imagining Wikipedia being full of exploding cloths dryers ;-) TonyBallioni (talk) 14:29, 4 October 2017 (UTC)
That's... not far off in actuality. --Izno (talk) 14:38, 4 October 2017 (UTC)
If there are questions related to bad / incomplete documentation, would you be able to add it to mw:Help_talk:Extension:Linter? For feature requests for the linter, either a phabricator ticket or a request at mw:Extension_talk:Linter would be useful. For now, I'll pick up things from the list above and add it to the appropriate places and/or make fixes and update here when I am done. PS: Thanks for the exploding clothes dryers humour. :-) SSastry (WMF) (talk) 15:06, 4 October 2017 (UTC)
User:Anomalocaris didn't want the discussion here, so will wait on responding to some of these things, but mw:Help:Extension:Linter#Tools might be useful. SSastry (WMF) (talk) 16:12, 4 October 2017 (UTC)
We just deployed a couple of fixes that reduce the false positives categorized in the html5-misnesting linter category. Most of those errors will now go back to being missing-end-tag errors or misnested-tag errors. SSastry (WMF) (talk) 21:17, 4 October 2017 (UTC)

Just a note, but my bot (NihlusBOT) was handling some misnested errors. I received some assertive feedback from some users about it clogging up their watchlists. This should be considered when tackling these in the future. I am open to working on these as I have been manually tracking some of them. Nihlus 15:22, 4 October 2017 (UTC)

I have a bot, Fluxbot that works on one of these as well (well technically it works on Category:Pages using invalid self-closed HTML tags, but that is basically an overlay of Special:LintErrors/self-closed-tag. The backlog is done, but there are new entries occasionally. — xaosflux Talk 15:32, 4 October 2017 (UTC)

Xaosflux above suggested that I start up Wikipedia:Lint errors and an associated talk page or the like. Are there objections or reservations on this? —Anomalocaris (talk) 04:27, 10 October 2017 (UTC)

dewiki has this de:Hilfe:Wikisyntax/Validierung page with help and discussion in case it is useful here. SSastry (WMF) (talk) 22:47, 10 October 2017 (UTC)
itwiki has it:Wikipedia:Bar/Discussioni/Passaggio_da_Tidy_a_RemexHTML:_c'è_del_lavoro_da_fare for discussion and co-ordination. SSastry (WMF) (talk) 22:26, 14 October 2017 (UTC)

Policy or accepted standard behavior regarding Reverts.

Latest comment: 7 years ago5 comments5 people in discussion

I have just read some of the content on 'Dispute Resolution'. I read about the three revert rule in context of 'edit-warring', and that you should attempt to resolve your disputes when your changes are reverted.

While I agree on the aim to achieve a peaceful consensus, I do think that the currently accepted standards of behavior regarding 'Reverts', favor the editors 'watching' the article and do not put two editors(one that has made the change and the one that has reverted those) at equal footing.

While an editor makes any change and in doing that deletes or modifies existing content instead of just adding some, he/she is not specifically targeting a particular editor. But in case of 'Reverts', exactly that is happening ie one undoes changes done by a particular editor. 

While doing a 'Revert' it is 'assumed' that the 'changes' are disruptive and unconstructive, without even trying to make a contact or asking the editor for the reasons for the change. It is entirely plausible that the changes are in fact constructive and that the article was in a vandalised state beforehand.

So, I do think that 'Reverts' are more offensive and aggressive as compared to some ad-hoc changes made to an article, and hence have a much greater potential of igniting a chain reaction of aggressive and warring behavior.

If talking/conversation is the behavior being promoted or encouraged by Wikipedia, then it should be promoted/encouraged right from the start. So, before making a 'Revert', one should try to talk to the editor and try to achieve consensus.  One cannot expect the editor making the first change, to do this, as it would be very difficult to go and find out in the 'History' exactly who are the editors, the content of which he/she is trying to modify/delete, and to find out about all the editors 'watching' an article and then try to talk to each of them and achieve consensus.

I think that 'Reverts' should be entirely discouraged, and should only be allowed in exceptional cases where the vandalistic or disruptive nature of the 'change' is very obvious. If Revert is done, then one should always specify an 'as objective as possible' reason for the 'Revert'.

One more reason for above policy change is the difference between the knowledge of editors 'watching' an article and the editors making first change.  You see, editors who 'watch' an article, in most probability, are somewhat familiar with Wikipedia and probably would know about such thing as 'Dispute Resolution'.  Given that they know about the expected procedures/actions to be taken in the case of 'Disputes', they are less likely to take 'Disputes' as threatening or feel helpless/powerless when it happens. On the contrary, the editor who is making the first change, could be someone entirely new to Wikipedia and knows nothing about 'Dispute Resolution'. When someone 'reverts' his/her changes, he/she is more likely to engage in aggressive behavior and feel threatened or enraged at the perceived injustice of 'Revert' done to his/her changes.

Editors who 'watch' an article should not be automatically assumed better/more neutral than others, and should not be given undue benefit of doubt. 

When I do make a change to an article and someone 'reverts' it, and then when I read the message in my notifications, this is what I(and probably many others) think:-

  • Why my change has been reverted? Why is it 'assumed' to be disruptive? Who decides whether it is 'disruptive' or 'constructive', given that supposedly everyone can edit Wikipedia?
  • Who the hell he/she(the editor who has made the revert) thinks he/she is? Is he/she some kind of authority? What does he/she thinks of him/herself that he/she can decide about whether a 'change' is disruptive or constructive?
  • Why am I the one, who is expected to go through all this shit(talk pages and stuff) and try to gain approval? Why doesn't he/she has done or tried that already? Am I inferior to him/her? No I am not, and I will fight for this!

You can see where it's going. Add to this, the message: "Continual disruptive editing may result in loss of editing privileges", only seems more threatening and a sign of partiality/discrimination in built in the 'System'. Because you see, as per my thought process, why is it that my editing is assumed to be disruptive and that the 'Reverts' made by the other editor are assumed to be 'constructive'? — Preceding unsigned comment added by Manubhatt3 (talk • contribs)

I think your suggestion is completely non-viable and based on a misunderstanding. Reverting is an integral part of the editing process, not a form of "targeting", unless it is in the form of dealing with a problem editor or wikistalking. A revert simply means you are going to have to obtain a consensus for the change. If both editors break 3RR they are both likely to be blocked, unless the revert is exempt from sanctions (i.e. reverting clear vandalism, reverting a blocked editor etc). If both editors become embroiled in a cycle of reverting each other without a technical 3RR violation they may also be blocked, depending on the level of engagement on the talk page and the level of support from impartial editors. A decent admin should only base their decision to block on the level of disruption and the efforts undertaken to resolve the dispute; for example, if the editor attempting to implement a change provides a very detailed rationale on the talk page and an article "watcher" constantly reverts without leaving so much as an edit summary, I would expect only the non-communicating editor to be blocked even if the number of reverts for both parties are similar. Ultimately though we all face this: the burden of obtaining consensus is on those seeking to effect change. It's not a perfect system, and it is sometimes abused, but it is an essential part of quality control. Betty Logan (talk) 17:57, 14 October 2017 (UTC)
Another important reason is that a high proportion of reverts are to deal with vandalism or other totally non-constructive editing. It would be ridiculous to have to obtain consensus before undoing such edits. Peter coxhead (talk) 17:59, 14 October 2017 (UTC)
What they said. Correct me if I'm wrong, Betty Logan, but I think you're referring to the first revert, a la WP:BRD. We can and do debate what constitutes the first revert, but we shouldn't be discussing turning BRD on its head. ―Mandruss ☎ 18:07, 14 October 2017 (UTC)
Betty Logan I can understand your argument, but you must understand that I am talking from the point of view of people/editors who are not much familiar with such concepts and processes. AFTER reading your comment, I can NOW understand that a 'Revert' is a signal to obtain consensus, but that is probably not the message sent across to someone who is relatively somewhat new to this and making changes. If you read my full post, that is what I am trying to say there. Peter coxhead I am not against 'Reverts' done to obvious cases of vandalism and disruptive editing(read my full post), but what I am saying is that the editor making the change should be given benefit of doubt.— Preceding unsigned comment added by Manubhatt3 (talk • contribs) 02:57, 15 October 2017 (UTC)
That is why we also have an Undo button with the ability to add your own customized edit summary explaining your action so as to not WP:BITE newcomers. Certain scripts such as WP:TWINKLE also have an option to do a "Good faith revert" to soften the blow even more. Of course, not everyone takes advantage of these features. -- Ϫ 05:04, 15 October 2017 (UTC)

Making differences clearer

Latest comment: 7 years ago6 comments5 people in discussion

Is there any way that the "Differences between revisions" page can make the revision more obvious? Sometimes I look but I can't see anything. See, for example, this delta – I don't see anything highlighted. Praemonitus (talk) 16:57, 10 October 2017 (UTC)

There is User:Cacycle/wikEdDiff, which can be enabled at Special:Preferences#mw-prefsection-gadgets: wikEdDiff: improved diff view between article versions (not needed if wikEd is used). Nihlus 17:03, 10 October 2017 (UTC)
Thanks. I tried that but it doesn't actually show any differences. Perhaps nothing actually changed? Ah well. Praemonitus (talk) 18:59, 10 October 2017 (UTC)
There's an extra full stop: Graves, Genevieve J. M was changed to Graves, Genevieve J. M. -- John of Reading (talk) 19:02, 10 October 2017 (UTC)

Some time ago, the whole diff'd paragraph had a color background. I think that the diff'd character background should have a color background, not just the characters themselves. --NaBUru38 (talk) 19:34, 16 October 2017 (UTC)

Sometimes the revisions are only minor revisions and this would be evident if the revision is marked with an m. Vorbee (talk) 19:48, 16 October 2017 (UTC)

Proposal: Time-release watchlist items

Latest comment: 7 years ago13 comments7 people in discussion

Occasionally, Wikipedians tend to put things on our watchlist that we only intend to watch for a limited amount of time, such as a particular move request, deletion discussion, user talk pages of editors to whom we have made a specific inquiry, articles undergoing a particular editing process, etc. Presuming this is technically feasible, I would like to be able to watchlist items like these with an expiration date, so that after, say, six months, they automatically disappears from my watchlist. In terms of design, I am thinking that the default would remain "no expiration", which would require no additional action, but that an editor could choose expiration option from a dropdown menu. I would further propose the option of changing preferences to reverse this situation, allowing a particular editor to choose a preset expiration time for all watchlisted items, except those for which "no expiration" is specifically selected. Thoughts? bd2412 T 03:13, 13 October 2017 (UTC)

bd2412 the request for this feature dates back to at least 2006, and has been submitted for the 2014 WikimediaGermany wishlist and the 2015 WMF Community Tech wishlist. The primary Phabricator item is T100508. Some progress has been made in May of this year upgrading backend systems to support this,[4] however it seems to be lingering again as an "open task" with no indication of when anyone is going to work on it.
The WMF has just been too busy with more important tasks: Renewing Flow development, providing a "wikitext edit mode" inside VisualEditor so that they can deprecate the current wikitext editor, and damn near crashing Wikipedia itself with new Wikidata rollouts. (I tried to resist the temptation to be snarky, but I failed badly.) Alsee (talk) 06:23, 13 October 2017 (UTC)
(I tend to be careful of where I'm spending our painfully crowdsourced money, but in case anybody else missed that "The current wikitext editor is not going anywhere, at least for the next few years." - per documentation, now you know! I am unaware of current plans to remove it, but hey, please do keep me posted if you hear otherwise. Elitre (WMF) (talk) 14:25, 13 October 2017 (UTC))
If wikitext is not going anywhere, then someone should have time to implement the feature proposed above. bd2412 T 20:25, 13 October 2017 (UTC)
Or maybe this ten-year-old watchlist bug which has been partially responsible for multiple ArbCom cases. Snuge purveyor (talk) 22:57, 13 October 2017 (UTC)
Elitre (WMF) per your link, the WMF wants to terminate support for the current editor due to the cost of "multiple parallel work streams". Given that the WMF already ignores or neglects community requests for "high impact"(random example) work on core wikitext infrastructure because you're too busy chasing visual-butterflies, and given the intention to terminate support for the current editor, I expect the current editor would be even more neglected. I expect your work on other things will cause incidental breakage or crippling of the current editor extremely quickly. However that is almost irrelevant. There is a far far bigger problem here:
The WMF is repeating a bad old problem. The WMF effectively built the NewEditor in secret. The WMF built the NewEditor with zero community input. Once the prototype was available, the WMF was immediately notified that there were going to be serious community objections. For the last year the WMF has been unwilling or unable to constructively address the issue. There is currently a consensus that the NewEditor is unacceptable.[5] Unacceptable as the default for existing editors. Unacceptable as the default for new editors. Either:
  1. You need to change the community's mind and build a new consensus that we want the NewEditor promoted to default; or
  2. You need to throw the NewEditor in the garbage; or
  3. You keep supporting our primary editor as the primary editor, AND you support the secondary VisualEditor, AND you add maintenance load supporting a pointless tertiary NewEditor; or
  4. You go to war with the community trying to force out a NewEditor as the default against consensus.
I would like to note that MediaViewer was a rather petty squabble over an essentially cosmetic feature. It blew up because the WMF was unable to constructively engage the community, it blew up because the WMF had zero respect for the consensus process, and it blew up because the WMF committed one of our most serious crimes. The WMF abandoned discussion and Eloquence abused technical protection trying to win a petty dispute by force. If the WMF were to engage in warfare over our core editing platform, things could escalate far worse. The default editor is not a petty issue. Sabotaging wikitext-editing by trying to force out an inferior&sabotaged default-wikitext-editor is a threat to Wikipedia itself. The fact that it's an obsessive-compulsive effort to force everyone into VE just adds insult to injury.
I have been seriously worried about this situation for a year now, and the WMF just keeps ignoring the situation. Jdforrester just goes non-responsive, and Whatamidoing is unwilling or unable to give a constructive response. So since you're here, please don't waste time discussing how the current editor will stay as opt-in "for years". That is irrelevant. The dispute is whether the default is going to be changed at all. Please tell me the WMF has some plan for addressing the WMF-community conflict on this issue. Please tell me the WMF isn't going to blindly ignore the issue until "deployment day". Please tell me the WMF isn't going to try to force out the NewEditor as default against consensus. Please tell me we're not all just waiting to discover how big and destructive the fireworks are. We should have sorted this out before writing code for a NewEditor. At worst we should have sorted this out immediately after the prototype was built. Alsee (talk) 13:26, 14 October 2017 (UTC)
Per that link, the Foundation does indeed want to remove support for some "multiple parallel workstreams". But you will not find any plans, on any page, for removing the 2010 wikitext editor (nor the 2003 editor, for that matter), as you have been told repeatedly (on at least three separate occasions by me personally).
For those who haven't been told many times already, you can find out just how many editing environments the WMF is currently supporting by looking at the long table at mw:Editor. The only "removals" associated with VisualEditor involve converting the codebases for CX and some of the mobile editors, while leaving the end-user experience the same. Completely unrelated to mw:Extension:VisualEditor, the WMF will stop supporting the 2006 Javascript wikitext editor (probably before the end of this calendar year), but it looks like a volunteer at the French Wikipedia will convert it to a user script, in which case I'm not sure that it's accurate to say that anyone is actually "removing" it, even though the Foundation will stop fixing it when/if it breaks. Whatamidoing (WMF) (talk) 21:05, 16 October 2017 (UTC)
Whatamidoing (WMF) I am not interested in a Crystalball debate on how long or how well the WMF will support a deprecated editor at the level of functioning expected of a first-rank-editor. It's irrelevant. I will ask, for far more than the third time, for you or anyone from the WMF to address the the #1 #2 #3 #4 issue I posted above regarding default editor, in light of the overwhelming consensus against deploying Visual Editor's new "wikitext mode". Alsee (talk) 12:56, 18 October 2017 (UTC)
Your entire premise is wrong. The editing environment you prefer is not deprecated. I would appreciate it if you would quit claiming or even implying that it is.
Your numbered list offers false choices. When and whether it will be offered by default to which users at which wikis has not been decided. The only things that I can say with certainty are:
  • The Foundation will not be scrapping VisualEditor's wikitext mode.
  • It won't be offered outside the Beta Feature at this wiki until sometime after (possibly long after) the current performance audit is completed. Whatamidoing (WMF) (talk) 16:33, 18 October 2017 (UTC)
  • Sounds interesting. There must be an essay somewhere (?) about the inefficiency of editing based on watchlists. It often seems to lead to accusations of hounding and "following". I'm sure it contributes significantly to edit warring. I often wish I could see my Watchlist in reverse time order (is that a editting setting already?) I'm often reminded of an under-10's football match where they all follow the ball round in a tight clump. Martinevans123 (talk) 20:36, 13 October 2017 (UTC)
  • There's already a solution to meet this need! Well, a work-around actually. I totally agree that Watchlists are pretty useless as editing tools except to receive email alerts of new changes to pages. Cleaning them out down to just key articles of interest can be a pain. So I installed Page Collector script, and now have two additional, and much more useful watchlists, though you can have more. One is my 'To Do' list to flag up pages I encounter that I'm far too busy to edit right now, but which I definitely want to go back to later and make changes myself. The other is a chronological 'To Monitor' list of pages that I only want to keep an eye on for a short while, often as a result of encountering a page under WP:NPP and seeing how others have handled it where I'm not too sure myself (- a great way to learn). It can also be great for monitoring user contributions to check for persistent vandal activity or to watch someone's talk page for an ongoing topic. You can manually insert a marker date, but there's always the page history to show when items were added. So it's relatively easy to remove 'watched' pages. Adding a page is done from a Tab next to the search bar at the top of the page. If anyone thinks this would meet their needs, here's the link to install it. Nick Moyes (talk) 01:31, 15 October 2017 (UTC)
  • BD2412, I'm told that this project is about a million dollars' worth of engineering work. But I still want it.  ;-) I encourage you to consider adding it to the next m:Community Wishlist, which I believe will start in about three weeks. Whatamidoing (WMF) (talk) 19:20, 16 October 2017 (UTC)

SUL username cross platform solution

Latest comment: 7 years ago3 comments2 people in discussion

The complicated issues arising around the current RFC non-language characters in usernames has a lot of comments around being hard to ping, hard to refer to in 'plain language' form and such like, complicated even more by the issue of arabic and asian charater sets among others. A possible solution to the problem could be to automatically assign a secondary username to ALL usernames as an alias, using a simple number string (say 8 or 10 characters) that serves as an alternative method of referring to, or communicating with, problematic usernames. Pinging the number would do exactly the same as pinging the username. I see this as a simple look-up, whereby each username is backgrounded with the number in the same way you have easy access to a user's contributions, userlog, blocklog etc when hovering over a name. A bot could easily run through assigning exisitng usernames the number and auto-create it on new ones. On the presumption there are existing usernames that consit only of numbers, prefixing it with something like "~" (tilde) would distinguish it as an alias. Eg, My username being ClubOranje would have an alias like ~27504667. I'm sure there is someone clever over at Meta that could acheive this. ClubOranjeT 20:10, 18 October 2017 (UTC)

This should probably be on Meta somewhere, but I can't find an equivalen tpage over there... ClubOranjeT 20:19, 18 October 2017 (UTC)
Such an idea would likely require some rather significant changes to the MediaWiki software to support these aliases for pings and to show them in the places you propose. BTW, your alias would probably be either 2184171 or 17366057. Anomie⚔ 21:08, 19 October 2017 (UTC)

NOTNEWS – discussion about deleting part of it as "no longer policy"

Latest comment: 7 years ago2 comments2 people in discussion
  FYI
 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:What Wikipedia is not#Paragraph 2 of NOTNEWS. The gist: it's suggested that the part in it about Wikipedia not being here for the reporting of breaking news is ignored by a sufficient number of editors that it isn't really a policy and should be deleted.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  21:19, 17 October 2017 (UTC)

The key word here is "enduring" and if an event or incident fails to prove enduring, it could always get discussed at Wikipedia: Articles for deletion. Vorbee (talk) 07:38, 20 October 2017 (UTC)

Opt-in "Edit source" for new accounts?

Latest comment: 7 years ago17 comments11 people in discussion
Closing per WP:SNOW: Given the circumstance, Wikipedia:VisualEditor, and the lack of any supporting evidence, the consensus is against this proposal. Alex ShihTalk 17:15, 20 October 2017 (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.

Visual Editor is becoming more and more popular and is very stable. Since Visual Editor is Wikipedia's future, we should educate more and more editors to directly use and editing wikicode is expected to fade out at some point. In that frame, what do you think of making "Edit source" opt-in for all accounts created from now on? -- Magioladitis (talk) 08:19, 20 October 2017 (UTC)

"Visual Editor is beoming more and more popular": evidence? "Visual Editor is Wikipedia's future" Er, no. "editing wikicode is expected to fade out at some point" again, no. In recent changes, article namespace, bots hidden, 500 recent edits took 12 minutes now (i.e. changes from 08.31 to 08.43 are shown). Only taking visual editor made changes (a subset of the previous list). 500 edits, taking only those made by visual editor, ranged from 04.32 to 08.44, or 172 minutes. Counting it differently, among the last 500 article space edits, made between 08.34 and 08.46, there were 18 visual editor edits. That's 3.6% of the edits.

If after 5 years the adoption rate of VE is so low, I doubt that it can be considered the future of Wikipedia or that it should be pushed on new editors by default (or evn at all). Fram (talk) 08:49, 20 October 2017 (UTC)

Perhaps, by pushing it, we create a huge pool of volunteer software testers which will probably help programmers improving it? Moreover, this will reduce the various blanking vandalism. -- Magioladitis (talk) 08:58, 20 October 2017 (UTC)

(ec)So you have no evidence for your original statements that it is "becoming more and more popular" or "wikicode is expected to fade out" and so on? You just want to push VE and used false pretenses to support your point. Are you deliberately trying everything you can to get banned from enwiki, or does it happen by accident? Please stop this nonsense and simply withdraw this proposal now that you can do so with some dignity left. Fram (talk) 09:05, 20 October 2017 (UTC)
You added "Moreover, this will reduce the various blanking vandalism." while I wrote my reply. So, having been caught on starting a proposal with utter bollocks arguments, you decide to add another one. Why do you think that making things up on the spot will somehow convince people of anything but your utter unreliability? Fram (talk) 09:06, 20 October 2017 (UTC)
Fram This is the impression I get from people I know. Is there any study that says the opposite? I don't understand why you are so agreesive in a question I made. WMF has invested a lot to Visual Editor and had been improved a lot these 5 years. For the vandalism: I have seen removing of brackets in wikilinks and categories. Or even broken tables. This can't happen via Visual Editor. You say that in your random test 3.6% of the edits were with VE. Maybe last year this was much lower.-- Magioladitis (talk) 09:11, 20 October 2017 (UTC)
WP:ANI#Propose indef ban for Magioladitis. You are totally out of your depth in way too many discussions, and are ruining even the most simple tasks now. I'm done discussing things with you. Fram (talk) 09:23, 20 October 2017 (UTC)
I wrote "editing wikicode is expected..." not just "wikicode is expeted..." -- Magioladitis (talk) 09:37, 20 October 2017 (UTC)
  • I might not have worded it that way, but Fram is correct that proposing something based on a false premise is a bad idea. Personally, I think it is horrible software but it is up to the public to decide, and it appears that the public is choosing to just edit the source. You want (your words, mind you) to push defective software onto the masses in the hope of attracting the attention of a pool of "testers" so our software engineers will fix the defective software. Perhaps that should have been the actual proposal. In that event, I would oppose. Dennis Brown - 2¢ 11:47, 20 October 2017 (UTC)
  • Oppose Prima facie any proposal based on demosntratedly false premises have no justification for proceeding. --Jayron32 11:49, 20 October 2017 (UTC)
  • Oppose this is a hypertext encyclopedia, not simply a encyclopedia that happens to be on the internet. Expecting people to learn half-a-dozen syntax features if they contribute regularly ([[wikilinks]], <ref>s and {{cite}}, '''bold''' and ''italic'' are probably enough) is not an unreasonable burden. Besides, there's already a dialog asking whether users want to "Switch to the visual editor" when they start editing. power~enwiki (π, ν) 15:19, 20 October 2017 (UTC)
  • Evidence needed. Jo-Jo Eumerus (talk, contributions) 15:28, 20 October 2017 (UTC)
  • Oppose pending evidence - proposal makes no sense at all as it stands. - Sitush (talk) 15:40, 20 October 2017 (UTC)
  • Oppose - Mostly per WP:CIR. —PaleoNeonate – 16:03, 20 October 2017 (UTC)
  • Oppose I use Lilypond over Finale, too. --SarekOfVulcan (talk) 16:12, 20 October 2017 (UTC)
  • Oppose; we're not going to change our most fundamental workflow based solely on the impression I get from people I know, and you've yet to provide any actual evidence for your claims (unsurprisingly, since they're patently untrue). Magioladitis, please withdraw this; given the amount of disruption you've spent the last few months causing, a proposal this idiotic is sailing very close to outright trolling. ‑ Iridescent 16:45, 20 October 2017 (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.

Bot requested to finish up the WP:JR moves

Latest comment: 7 years ago3 comments3 people in discussion

See Wikipedia:AutoWikiBrowser/Tasks#Admin_help_wanted and Wikipedia:Bots/Requests_for_approval/JJMC89_bot_14.

After a couple of years of manual effort to move and edit articles to better follow the consensus guidelines about punctuating names in bios (at WP:JR), we're down to a shortlist of exceptions and a long tail of about 1,650 obscure names (see User:Certes/JrSr/titles). So we got some help, including a bot that's ready to finish this. The Bot Approval Group asked that we advertise this here for a week before executing it. If interested, take a look at the lists at User:Certes/JrSr/titles and say if you see any issues. Dicklyon (talk) 17:01, 18 October 2017 (UTC)

  • Disclosure: I know Dicklyon's work, and usually support his efforts. So all I can say is that I my opinion were sought, I'd support this. Tony (talk) 03:07, 19 October 2017 (UTC)
  • Support I see no reason to not proceed with moving the appropriate pages (i.e. non-bio pages need not adhere to WP:JR). However, I am an involved editor and have been making changes to this effect up until this VPP.   ~ Tom.Reding (talk ⋅dgaf)  15:53, 23 October 2017 (UTC)
Latest comment: 7 years ago14 comments8 people in discussion
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.
Closing this on my own recognizance, as it seems clear that it's not going to get traction. DonIago (talk) 13:01, 24 October 2017 (UTC)

Pursuant to this discussion, I'm opening an RfC to hopefully gain consensus on the creation of a bot that will automatically date redlinks.

My idea is that, similar to how Template:Citation needed without specifying additional params will lead a bot to automatically date the template, a similar template be created to mark redlinks, which a bot (perhaps even the same bot) could then tag with the current month and year (if there's a way to forego the template and just have a bot detect and tag redlinks, even better). I feel it would be useful to be able to see, when editing an article, whether a redlink has been relatively newly-created, or has existed for some time, so that editors can make more informed decisions as to whether a redlink is really merited. Even if this was only applied to redlinks going forward (i.e. no searching through existing ones) I feel it would be an improvement over the current approach, where it can be difficult if not impossible to determine when a redlink was created.

The linked discussion includes some thoughts on indexing redlinks and more advanced functionality, but for the purposes of this RfC I would consider that out of scope. If others feel the advanced options should be pursued, I would encourage them to say so in any ensuing discussion, or initiate a subsequent RfC.

Please indicate your support or opposition for the creation of such a bot (and associated template if necessary), and feel free to bring up any questions or concerns in the discussion section. Thank you for your participation! DonIago (talk) 19:45, 13 October 2017 (UTC)

  • Support as proposer. DonIago (talk) 19:45, 13 October 2017 (UTC)
  • Oppose as I don't see the problem this is solving. There is no deadline. How long a link is red is meaningless. Many will never be articles. None will instantly become articles just because of a date. They will become an article once someone with sufficient knowledge and desire decides to remedy the redlink. Having a bot traveling around and dating doesn't change that nor improve the experience for the reader. We could probably do a better job of making a list of red links that anyone can see, as many should probably be removed or converted into links to other articles or subsections, but dating them doesn't help that. Dennis Brown - 2¢ 01:05, 17 October 2017 (UTC)
  • Oppose I concur with Dennis Brown. A redlink is not a flaw that needs fixing (like, say, the lack of a citation is). It's not a task in the WP:BACKLOG. If one wishes to know when a redlink was introduced to an article, you can do that by inspecting the diffs to work that out. This introduces lots of extra edits for no real benefit. It'd probably be interesting to be able to parse and cluster redlinks, but that's something that'd probably be better done as a tool on the WMF's Tool Labs, similar to WP:CHECKWIKI. —Tom Morris (talk) 20:42, 23 October 2017 (UTC)

To be clear, I have no opposition to the more advanced functionality brought up at the original discussion, but those weren't my ideas, and I don't want to assume the responsibility of speaking to them as the RfC creator. DonIago (talk) 19:45, 13 October 2017 (UTC)

I note there are around 2,623,323 articles (i.e. mainspace, namespace 0) with at least one redlink. I have no way to easily determine how many of these are due to links in navigation templates or the like. Anomie⚔ 19:51, 16 October 2017 (UTC)

  • If Wikipedia:Most-wanted articles is not doing what is wanted, the solution would be to fix it. That link is one of three at Wikipedia:Red link#Lists of redlinks. However, there should not be more bot edits obscuring watchlists and adding bogus entries to complicate article history. At least, not unless a very strong benefit has been demonstrated. A script analyzing page dumps could work out what pages exist and which links are red. It could (if run monthly for a year or two) build a history showing when new red links were added. Johnuniq (talk) 22:09, 16 October 2017 (UTC)
    • I'm not sure how Most-wanted articles is relevant to my coming across a redlink in a film article, or such, and not knowing how recently the redlink was created? DonIago (talk) 05:34, 17 October 2017 (UTC)
  • I don't see any value in knowing how long a red link has been there when editing an article. ie the proposer's rationale. The main one here is red links that really should be blue, but are not, usually because of misspelling or different disambiguation. (Similarly, the date on the "citation required" is of zero use so far as I know - if someone would care to enlighten me, that would be welcome.) However, there is a situations when the this might come in handy:
    • When a red link goes blue. I created an article today on the physicist John Corner. When I checked "What links here", an unexpected article came up. Julia Corner linked to it, but wanted the more famous (but apparently not on Wikipedia) 18th century engraver. I removed the red link; a disambiguation will be required and anyone writing about him will want to link to Julia, so this will be okay. The problem here is that the link goes blue without notifying anyone, so the change is easily missed. Hawkeye7 (discuss) 02:49, 17 October 2017 (UTC)
      • To me, the value, as an editor, is that if I see a redlink that's been sitting around since 2010 or so, I feel reasonably justified in removing it on the grounds that it's unlikely to be de-redlinked anytime soon. OTOH, if the redlink was added a month ago, I'd be likely to leave it alone, reasoning (perhaps fallaciously, perhaps not) that there's a chance someone may write an appropriate article. I find the dates on CN tags useful for the same reason. If a CN tag has been in place for months/years, it's time to remove the challenged material. If it's a fairly recent tag, editors deserve more time to try to locate appropriate sourcing. Maybe it works, maybe it doesn't, but I'm not aware of any studies determining whether date-stamping is useful or not, so if it's a minimal effort, why not implement it? DonIago (talk) 05:30, 17 October 2017 (UTC)
        • Why would you want to remove a redlink based in it having existed for a long time? That is no indication of whether an article is needed.· · · Peter (Southwood) (talk): 04:22, 23 October 2017 (UTC)
          • For the same reason I'd be more likely to delete uncited information that's been in an article for a long time. It is an indication that nothing's going to be done to resolve the underlying situation. Besides, a redlink in and of itself is also no indication of whether an article is needed. DonIago (talk) 20:19, 23 October 2017 (UTC)
Aa already explained, a redlink is not an "underlying situation" that needs to be resolved. This is a very bad idea. EEng 22:29, 23 October 2017 (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.

More dynamic search bar?

Latest comment: 7 years ago4 comments3 people in discussion

I was wondering if it could be possible to have a more dynamic search bar than what we have. The search bar present automatically looks for the most popular/clicked upon page based on the letters you type in first, but this isn't what I want. I want it to be based on my watchlist, as they are the articles/pages that I frequent the most. For example, if I type in the phrase 'Jack', I come up with File:JackDelanolocomotiveshop.jpg, File:JackXArik.png, Jack Dempsey, Jacksonville, Florida, Jacksonville Jaguars, Jackson, Mississippi, Jackie Robinson, Jackie Chan and Jack Kirby. None of these pages are any that I edit or look at. However, the Jack Gallagher (wrestler) page is on my watchlist and I frequently edit it. Is there a way to make it so that I could see this article at the top of my search? Pages I frequently edit and are on my watchlist, I use the search bar to quickly navigate to and I feel like they should pop up at the top of searches as something that is on my watchlist. If there is a way to do this, please let me know. Regards, — Moe Epsilon 16:22, 22 October 2017 (UTC)

That would be useful. · · · Peter (Southwood) (talk): 18:30, 22 October 2017 (UTC)
This would probably be a software change, please see how to request these at Wikipedia:Bug reports and feature requests. עוד מישהו Od Mishehu 13:23, 23 October 2017 (UTC)
@Od Mishehu: thanks, but would I not need local consensus before I requested something such as that? Regards, — Moe Epsilon 20:18, 23 October 2017 (UTC)
Any such gadget would be at the top of my wish list, at least I will not have to type half of my name before my name shows up on the search bar-
To ping me add {{ping|Force Radical}} OR [[User:Force Radical]]

06:56, 25 October 2017 (UTC)

Automatic intra-article link updating after section title changed

Latest comment: 7 years ago1 comment1 person in discussion

Hi, how about having the Save changes function scan for section title changes, and if there are any, pass the article name and the "before" and "after" title(s) to a bot which waits for, say, 48 hours which start anew if it receives another notification concerning the same section title (to detect an edit war), and if the article hasn't been reverted to the "before" title(s) by then, crawls the article and everything on the What links here list, updating all intra-article links ([[#Section title|see below]]) still pointing to the "before" title? 85.240.213.239 (talk) 11:42, 26 October 2017 (UTC)

Discussion about making the "In The News" nomination process more transparent for visitors to the main page

Latest comment: 7 years ago1 comment1 person in discussion

There's a discussion here that could use some wider input from the community at large since it involves a prominent section of the main page. Please read the proposal and comment as you feel is necessary. Thanks! --Jayron32 20:19, 26 October 2017 (UTC)

New Pages Team?

Latest comment: 7 years ago11 comments9 people in discussion

Basically, the idea is that we could have a "Team" of people who sit at the new pages feed and, after finding an article which isn't CSD-able, making rapid changes to turn it into at least a stub. (Fixing grammatical errors, adding a dozen or so sources, tagging the issues, and expanding the article) Terrariola 12:04, 20 October 2017 (UTC)

Isn't this what WP:NPP does? Darylgolden(talk) Ping when replying 12:13, 20 October 2017 (UTC)
Strictly speaking, no. It's a triage, not a field hospital. It's difficult enough to get the 430 reviwers to do the bare minimum. In fact about 90% of the reviewing is done by about 10% of the reviewers. Kudpung กุดผึ้ง (talk) 12:51, 20 October 2017 (UTC)
Well... ideally when NPP comes a cross a page with obvious and easily fixable errors, they should take a few seconds and fix them, which I normally do. You know, put on a tourniquet and tag them with a casualty card for the MASH unit. But if we can't get NPP to do at least that, I don't see a reason why we should expect to be able to assemble some other team to do it instead. GMGtalk 12:55, 20 October 2017 (UTC)
NPP is almost 100% CSD-ing, my idea is not for simple grammatical fixes, but turning "Substub" articles into proper stubs with reliably sourced text and the appropriate images, infoboxes, audio, etc.— Preceding unsigned comment added by Terrariola (talk • contribs) 13:36, 20 October 2017 (UTC)
The idea that NPP is mainly CSDing is a misconception. Since ACTRIAL, to be honest, most of the work I do there when I'm reviewing new pages is stuff like formatting references. Even before ACTRIAL it was never mostly CSD for me, but there was a lot more of it. But to your idea: that is in theory what the tags do: let people know an article is unreferrnced or whatever so they can fix it. We see how well that actually works, but I don't think creating a team to work on new pages after they are triaged would really do anything much more than we have now. TonyBallioni (talk) 13:47, 20 October 2017 (UTC)
Can it do any harm? · · · Peter (Southwood) (talk): 16:41, 20 October 2017 (UTC)
It wouldn't do any harm, but Terrariola not being a New Page Reviewer may not be aware that it's chicken/egg. We need interested reviewers and we urgently need some enhancements to the system, and without one we don't get the other. Kudpung กุดผึ้ง (talk) 16:59, 20 October 2017 (UTC)
This sounds like a good idea for a "task force" under NPP, but like Kudpung said above, NPP is already sorely understaffed and fixing that is much more impactful to readers. — xaosflux Talk 17:08, 20 October 2017 (UTC)
The suggestion has already been put forward that New Page Reviewers should have the option of leaving a copy of constructive feedback and suggestions on the article's Talk Page for all to see, and not just on the creator's own talk page. I think this might help a bit, were it ever to be implemented. Regards from the UK. Nick Moyes (talk) 01:12, 25 October 2017 (UTC)
Some of us do consider that NPP is a place for categorisation and other fixes as well as for deletion tagging. I think it a shame when I see a patroller who hasn't yet started to improve articles. But it would be a mistake to do too much of that at the very front of the NPP queue, most new articles have no sections, and many are created by newish editors who have not yet mastered the art of fixing edit conflicts. The number of new and not so new editors who have suffered from edit conflicts on the second or third edit to the article they just started is non trivial. ϢereSpielChequers 19:04, 27 October 2017 (UTC)
Latest comment: 7 years ago6 comments6 people in discussion

It is important that the references in legal citations in articles invovlving explanation of law in the United States give the correct information in the proper form, in order to be able to be looked up for those that wish to read the cases for themselves. Therefore, it is proposed that editors should be required to follow proper form when they cite U.S. case law. For example, We might often see a citation like this (IF we're lucky): Brown V. Board (1954). Where the proper citation is: Brown V. Board of Education of Topeka, 347 U.S. 483 (1954).

This gets compounded when the author is intending to cite to specific pages of a decision, where the proper form is as follows:

Party V. Party, Volume number of the reporter, Reporter name, Page No. the case starts on, page numbers cited to, court name (Supreme court of the U.S. is ALWAYS omitted), Year of case.

It is worthy of mention in support of this that things such as law reviews, etc. ARE NOT binding. Rather only direct quotes from the proper reporters are binding. [in the case of the Supreme Court, only direct quotes from the United States Reporter are actually binding law, cited as ___ U.S.___)].

This is necessary to ensure that articles are as accurate as possible, and to ensure that citations are compatible to other look -up tools such as lexus-nexus, findlaw, fastcase, etc., which expect proper citation; as well as to ensure that where case names are searched in google, that the user is able to easily identify the correct case as pertinent. This will help to streamline wikipedia review functions, as well as give the users the correct tools within which to further their own research into the subject matter of the given article. 108.201.29.108 (talk) 03:48, 26 October 2017 (UTC)

See {{Cite court}}, a template that standardizes the formatting and reminds you what fields to include. The few times I've wanted to cite a case, I spent a long time trying to figure out how to look up the reporter and details therein, and then just gave up. I'm not a lawyer, so I don't know the lingo or reference tools. If I know the involved parties, court, and date, and maybe even a caselaw.findlaw.com link, how do I find the other details? Take as a specific example footnote 1 at Davol Square. DMacks (talk) 04:44, 26 October 2017 (UTC)
I think its unreasonable to expect laymen to be able to understand that they are doing it wrong. The best that can be done is to provide better instructions for how to do it right, and fix any errors we find. Dysklyver 14:17, 26 October 2017 (UTC)
It's generally pretty easy to find the full information for a reasonably notable case by googling the case name. Also, as to the original comment, the "v." should be lowercase. bd2412 T 14:59, 26 October 2017 (UTC)
Concur with Dysklyver and with BD2412 (including on the typographical matter).  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  06:35, 27 October 2017 (UTC)
Wikipedia articles are supposed to be cited to secondary sources, rather than primary sources such as legal cases, so this should not be a major issue. If this is a problem anywhere then it can simply be fixed by someone who knows how to do it better as with everything else on Wikipedia. I don't see that there's any need to require anybody to change the way that they write citations. And should we develop similar rules for citing legal cases in the countries where 96% or so of the world's population lives? 86.17.222.157 (talk) 19:36, 27 October 2017 (UTC)

Women in Red World Contest

Latest comment: 7 years ago1 comment1 person in discussion

If anybody feels like contributing an article or two this month to help us try to move closer to 20 % women biographies this would mean a lot. I hope to use the contest to launch a long term challenge after it which will try to get us to 20% women bios within two years rather than around 8 I roughly guess. I think we need around 65,000 new articles to get us there given the current rate of male bio production (rough guesses), we're aiming for 2000 with the contest but anything can happen if people help! Even if you dislike contests or prizes, you're welcome to contribute to it as an editathon independently and simply list articles created at the bottom of the main page. If people like the idea of a long term challenge like the Wikipedia:The 10,000 Challenge to try to reach 20% quicker feel free to discuss below, hopefully quality won't be sacrificed which I know is the concern of some!♦ Dr. Blofeld 12:33, 1 November 2017 (UTC)

RfC: Proposal - Removal of signature fields

Latest comment: 6 years ago108 comments78 people in discussion
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.
  • Summary:--
    • There is a weighed consensus to  N oppose the specific version of the floated proposal, mainly due to its all-encompassing purview.
    • But, there's also a  Y general consensus that there are many signatures, across numerous articles which are not encyclopedically important.
  • Details:--
    • Many supporters have argued that signatures, as a whole, are often not useful for any encyclopedic purpose and/or they are not so important to be included in the infobox.
    • The opposers have argued that many signatures are very integrally associated with the heads of state/government and numerous famed legislators, authors, painters et al.Hence, enactment of the floated proposal would mean a blanket removal of all such signatures without a much-necessary discretion.It may be noted that even some supporter(s) have conceded to the need for exceptions.
      The second argument is obviously much valid and thus, the locus of the argument that:-- No signature is ever important to an encyclopaedia is not found to be a good/effective argument.
      Their value of importance, justifying their presence in infoboxes seems to be also skewed towards the opposers.
    • Nonetheless most of the opposer(s) have heavily conceded that many signatures (esp. at little-known BLPs) are often of little encyclopedic use and may be a violation of privacy.
      No good counter-argument could be traced in the discussion.
    • There were some proposals to support the mass-removal, followed by a per se basis of inclusion, subject to local consensus, per onus of inclusion.
      No strong support could be found for the implementation of the same.
  • Way-out:-
    • It is noted that GuyMacon has floated a proposal which has accounted a compromisatory-wording-stance, based on the general consensus in the main-discussion.The mini-proposal has managed to gain some additional support.Guy's proposal may be converted into a full-blown RFC to address the concerns of the community about the issue.

Winged Blades of GodricOn leave 06:39, 9 November 2017 (UTC)

Survey (Removal of signature fields)

  • Support as proposer. Beyond My Ken (talk) 00:02, 9 October 2017 (UTC)
  • Support Tony (talk) 03:18, 9 October 2017 (UTC)
  • support --JohnBlackburnewordsdeeds 04:02, 9 October 2017 (UTC)
  • Support Alex ShihTalk 04:03, 9 October 2017 (UTC)
  • Support per Tony, basically. No reason to have it unless there is something actually notable about it, in which case write about it in the article, not the infobox. ansh666 04:26, 9 October 2017 (UTC)
    Tony hasn't offered a rationale, though.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:57, 9 October 2017 (UTC)
  • Oppose such sweeping and unspecific guidelines. This would alter almost 90,000 pages and provide little to no guidance. Signatures such as those belonging to individuals signing historic documents (John Hancock, George Washington, and anyone else who can enact laws with their signature) and those belonging to famous artists are just some of the cases that require discretion that this proposal doesn't address. I'm not necessarily opposed to moving them out of the infobox and don't believe we should be including them for graphoanalysis, but just unilaterally removing them is problematic. Nihlus 05:09, 9 October 2017 (UTC)
  • Support Given that an infobox is supposed to be a quick summary of a person's bio, I cannot see how a signature fits that. In the body, it can be used, but not infobox. --MASEM (t) 05:21, 9 October 2017 (UTC)
  • Support --Blackmane (talk) 05:41, 9 October 2017 (UTC)
  • Support - Very sensible proposal. Even without the concerns presented below, from a content-to-space ratio perspective it does not make sense to include the signature in the infobox. That is not useful overview information, and says nothing about the subject as the other fields in the infobox do. -- Ajraddatz (talk) 06:38, 9 October 2017 (UTC)
  • Oppose something so broadly constructed. My feeling is similar to Nihlus, I think. I completely get why we have signatures for American presidents, whose signatures are the instrument by which laws come into force. There are probably other good examples that are beyond my info horizon. But do we need Pedro Pascal's signature? No. So I would enthusiastically support this if it was construed more narrowly. A Traintalk 06:45, 9 October 2017 (UTC)
  • Support. Not key information about a person. Also can aid in attempting forgeries of documents (though that's not my principal objection, the content's irrelevance is).  Sandstein  07:13, 9 October 2017 (UTC)
  • Support. Notable, authentic signatures for non-BLPs can always be added directly into the article if necessary: removed from an infobox doen't equal can't be used anywhere, anytime. Fram (talk) 08:27, 9 October 2017 (UTC)
  • Oppose as written - Support omission as default per first sentence at MOS:INFOBOX - not a "key feature of the page's subject" in most cases. Omit signature from the infobox unless there is discussion-based consensus to include it. Oppose outright ban from the infobox. My approach would mean that a signature could be removed from any infobox without local discussion, based on this consensus, pending discussion-based consensus to include it. ―Mandruss ☎ 09:13, 9 October 2017 (UTC)
  • Oppose though I'd be open to prohibiting it for living persons who are non-public figures. This is actually fairly normal to see in short biographical articles off Wikipedia as well and does add encyclopedic value in my opinion. I'm particularly thinking of heads of state, heads of government, religious leaders, noted authors, etc. where their signature is publicly known and very much associated with who they are. As always, I appreciate BMK's efforts here, but unfortunately I cannot support this specific proposal. TonyBallioni (talk) 10:01, 9 October 2017 (UTC)
  • Support There may be certain figures whose signature is relevant to their encyclopaedic value (someone mentioned presidents- good example, per thatthey sign off laws. Artists might be another, as they stick em at the bottom of their works on a regular basis). But the current position which is that since their is an IB parameter, it must be filled, even if the only way of doing so is to effectively forge the thing. Madness. This is completely unencyclopaedic behaviour. The use of signatures should be governed by our usual policies of WP:VNT and WP:RS; if the sig is covered in sources, there's something that makes it notable, so we use it. Otherwise, our default position should be no signature, and the argument should be made on a case-by-case basis for inclusion. On edit let me clarify per below. The IB parameter encourages inclusion of the sig. It aso means that the onus is on us to patrol articles to ensure that a sig is not inserted without consensus. This is not good. So what we do is, we prevent a sig being inserted by default (per this proposal), yet we allow sigs to be used in articles (as per WP:MOSIMAGE) on a case-by-case basis. So noooo.... definitely not an !oppose  :) — fortunavelut luna 12:06, 9 October 2017 (UTC)
  • Oppose. I understand the sentiment and a lot of signatures are superfluous for our needs, but this proposal is way too sweeping and would mean the deletion of many signatures that are worth keeping. If it was narrowed down to limiting signatures to a specific criteria that allows for case by case examination (ie: demonstration that the signature itself is important), I would be more open. Dennis Brown - 2¢ 12:28, 9 October 2017 (UTC)
  • Strong oppose, oh come on, these are always interesting. Signatures and autographs carry a personal historical imprint. They directly link the reader with the page's subject. Consider the signatures as human touchstones, a work of art in themselves. To see Jeanne of Arc's signature, or that of Shakespeare, brings the topic more fully alive and real to many readers. Degas, Picasso, Dali, their signatures are part of what they are and how people "know" them. To see so many editors supporting this reminds me of the adage that too many rules eventually bring down what they are meant to hold up. Hopefully the closer will see keeping the signatures as worthwhile, and take the common sense reasons why they should be kept. This is a sad one, and I feel that if "passed" it will hurt the project more than help it, and I hope the nominator and support editors will reconsider. Randy Kryn (talk) 12:29, 9 October 2017 (UTC)
  • Support these signatures are really just a bit of decoration and add nothing of encyclopaedic value in the infobox. If the signature adds real value to the article for some reason there is no problem with including it in the main body of the article like any other information or image, subject to all the usual rules for inclusion, of course. - Nick Thorne talk 13:46, 9 October 2017 (UTC)
  • Support Privacy issues with live people. No encyclopedic benefit for (almost all) dead people. On the rare occasion it does merit attention in the article it can be explored in the body. I can see an argument that painters would deserve an exemption. Only in death does duty end (talk) 14:58, 9 October 2017 (UTC)
  • Oppose I don't object to a guideline on when to include signatures but there are many examples of signatures that are of encyclopedic value: Those of presidents, artists, writers etc. The infobox should be the place to have them because that is where people will expect and find them the easiest. Disallowing signatures from living people who are non-public figures as TonyBallioni suggests above for various reasons is not a reason to remove them alltogether. Readers expect to find Barack Obama's signature with the quick facts about him, not somewhere buried in the 330kb long article and we should not make it harder for readers to access information they look for. Regards SoWhy 15:09, 9 October 2017 (UTC)
  • Oppose - At least in the Western World, signatures are a central personal identifier, and I expect in many if not most cases, of an almost default encyclopedic relevance. In cases of living people, signatures may already be routinely removed for privacy reasons as a matter of courtesy, although I would be in favor of adding that specifically to WP:BLPPRIVACY. Other than that, this is just overkill. GMGtalk 15:47, 9 October 2017 (UTC)
  • Support, they're usually copyvios anyway. Stifle (talk) 16:13, 9 October 2017 (UTC)
  • Oppose for BLPs Due to concern of privacy issues. When it comes to dead people, I'm going to proudly state that I like them. As noted by SoWhy above, some of these signatures are quite famous and quite notable. An all out removal is not going to work here. My name continues to not be dave (talk) 19:16, 9 October 2017 (UTC)
    I think you mean "Support for BLPs".  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:57, 9 October 2017 (UTC)
    I like dead people too, although I can't say I'm particularly proud of it. ―Mandruss ☎ 20:52, 9 October 2017 (UTC)
  • Oppose per WP:CREEP and WP:NOTLAW. If we have ~90000 pages like this it's clearly our policy to do so. A handful of curmudgeons have no mandate to issue an diktat forbidding them. Andrew D. (talk) 19:27, 9 October 2017 (UTC)
    We had spoiler tags in an even higher proportion of articles, and both ethnicity and religion parameters in even more bio infoboxes, yet ditched those as well.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:57, 9 October 2017 (UTC)
    Andy, do you think it's possible to state your oppose with more reasoning and less referral to those who have a different opinion as curmudgeons and their idea as a diktat? (I think you missed the point of this thread, but I may be mistaken.) ----Sluzzelin talk 21:40, 9 October 2017 (UTC)
  • Support for BLPs, since they're a privacy problem. Most do appear to be copyvios, ripped from books or from websites that ripped them from books. Except for cases like John Hancock, they verge on trivia, but are harmless for deceased subjects when properly sourced and licensed. Should probably have instructions in the template documentation to not include one that's not properly licensed and not to include one just to include one but because it's unusually relevant.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:57, 9 October 2017 (UTC)
  • Comment. Tending to oppose, as per Dennis and SOWHY; but also leaning to support for BLPs as per Stanton. For most authors they seem kind of irrelevant. Signatures of painters or other graphic artists might be more "useful", but I guess the copyright issues with those might be even more challenging? Martinevans123 (talk) 20:05, 9 October 2017 (UTC)
  • Support the may have some encyclopedic value. but they are not basic factual information--especially as the one used may or may not be a representative sample. They are absolutely a privacy problem for BLPs--where they normally should not be used anywhere in the article except for the most public of figures, such as presidents, , and I am amazed we continue to use them. As for licensing so, I do not think there is copyright in a signature. DGG ( talk ) 23:37, 9 October 2017 (UTC)
    @DGG: See commons:COM:SIG. Nikkimaria (talk) 01:12, 11 October 2017 (UTC)
  • Oppose I don't see what we lose from having it. I do agree and I may support a more specific guideline for inclusion, such has holding a political office or something. But I feel the signature gives the user a sense of the style of person, much as their photo does.Drewmutt (^ᴥ^) talk 01:38, 10 October 2017 (UTC)
  • Support - if someone forged a signiture using our digitized version, wouldn't that make us morally responsible for helping him/her do that? עוד מישהו Od Mishehu 04:03, 10 October 2017 (UTC)
  • Oppose; I agree with other users who say that for at least some persons, such as U.S. presidents and famous painters, their signatures are notable and important enough to be in the infobox. I also agree with other users who say that for persons who are not notable for signing stuff, their signatures don't belong in the infobox (or anywhere else in the article), and I would encourage editors to remove signatures from infoboxes about anyone not famous for signing stuff. —Anomalocaris (talk) 04:50, 10 October 2017 (UTC)
  • Oppose- These are sometimes appropriate, sometimes not. No need for a draconian rule like this. Carrite (talk) 05:18, 10 October 2017 (UTC)
  • Oppose making a blanket rule about this. This can be discussed on a per article basis. (I also oppose the "rule" that if we have a signature, it must be included in the infobox). —Kusma (t·c) 08:24, 10 October 2017 (UTC)
  • Support per Fortuna Imperatrix Mundi. - SchroCat (talk) 19:06, 10 October 2017 (UTC)
  • Support - in most cases signatures are not encyclopedic, but I could see exceptions for political figures or famous artists. Kaldari (talk) 19:40, 10 October 2017 (UTC)
  • Oppose it should be up to the article's main author, or group of main collaborators, to decide, via the medium of a talk page discussion if necessary. There is no reason for a blanket ban. jcc (tea and biscuits) 20:01, 10 October 2017 (UTC)
  • Oppose, although guidelines about smaller display size would be reasonable. It's too strict to consider them as lacking in encyclopedic value. --Tryptofish (talk) 21:42, 10 October 2017 (UTC)
  • Support as someone who has even added them before, I agree that this is really not one of the most basic overview facts that you want to know about a person. The argument about copyrite is silly. ―Justin (koavf)❤T☮C☺M☯ 23:08, 10 October 2017 (UTC)
  • Support per Fortuna Imperatrix Mundi and DGG, notably re BLPs. Where there is special artistic, political or social significance to the signature, it should be depicted and explained within the article text. -- Euryalus (talk) 23:21, 10 October 2017 (UTC)
  • Support A photograph or portrait of the subject is expected and is useful for identification; additional forms of ID such as signature, fingerprints, blood type, etc. seem overkill. In the case of artists: if the artist signs his/her works, the signature is seen in any jpgs included in the article; if the artist doesn't sign his/her works, the signature is of no special interest. If editors want to give encyclopedic attention to a signature, it's better presented in context as in Albrecht Dürer or William-Adolphe Bouguereau. Ewulp (talk) 00:31, 11 October 2017 (UTC)
  • Support; easy. I've never understood the point of the signature in the infobox; if the point of an encyclopaedia is to include every possible piece of trivia and by the way information about or loosely linked to a subject, then i suppose i understand: For us, however, surely we are selective in the information we present, and in how we present it, and someone's signature, while perhaps of interest, is not really of encyclopaedic value ~ it doesn't help the reader understand more about the subject. Essentially, per Sandstein. Happy days, LindsayHello 09:27, 11 October 2017 (UTC)
  • Oppose. There are many cases where a signature is relevant and should be in the infobox (e.g. a politician/statesman/monarch who signs legislation to bring it into effect, a central banker whose signature appears on national currency, an artist's signature on their work, being probably the biggest three). However, a narrower provision it is removed for BLPs where there is no prima facie reason to have it could work. ---- Patar knight - chat/contributions 16:15, 11 October 2017 (UTC)
  • Oppose only a Sith deals in absolutes. On a more serious note, there are some articles where this field adds value. Mr Ernie (talk) 18:23, 11 October 2017 (UTC)
  • Support I agree with others. If a signature is important then place it somewhere in the article where it is discussed. Otherwise it is just pointless decoration. AIRcorn (talk) 23:06, 11 October 2017 (UTC)
  • Oppose The collecting of autographs has been a field of study for centuries. This is one of those items that fits very nicely in an infobox and we should continue to do as we have. The suggestion that they hold no encyclopedic value forces me to question if the nominator ever read an encyclopedia (in print). I enjoy having them featured, where applicable. Chris Troutman (talk) 02:44, 12 October 2017 (UTC)
  • Support for BLPs only There is no issue for historical figures and in those cases they are often interesting and if not, at least harmless. BLPs are a different matter and they should only be included when their encyclopaedic value (whatever that may be) justifies it. Jschnur (talk) 03:01, 12 October 2017 (UTC)
  • Strong support per nom, this should have been done long ago. If the signature is particularly notable for the person (looking at you, John Hancock), there is nothing stopping editors from including the images in the regular article. Ed [talk] [majestic titan] 03:03, 12 October 2017 (UTC)
  • Support with an exception for rare but reasonable uses like John Hancock. There's no need for this with the exception of figures of major significance like US Presidents. Most uses strike me as crass and fanboyish. Also support Guy Macon's compromise below. Gamaliel (talk) 05:32, 12 October 2017 (UTC)
  • Support. We already have a severe case of infobox bloat and the autographs served little purpose. Kablammo (talk) 16:54, 12 October 2017 (UTC)
  • Support - As I said at ANI "What encyclopedic value do these actually serve?"..... there is no actual purpose to these and as such these should be done away with (with all sigs then deleted), Why would anyone care how a BLP signs their name ? ..... –Davey2010Talk 20:47, 12 October 2017 (UTC)
  • Oppose. Does the reader "need" to see a person's signature? No. But so what? It catches the eye; it adds visual interest. It "personalizes" the subject somehow. If there are cases where it's actually problematic to have a signature, then write a guideline to clarify those, but I see no reason to ban them from the boxes globally. --Trovatore (talk) 01:58, 13 October 2017 (UTC)
  • Oppose hard rule - Perhaps it's better to treat this on a case-by-case basis, meaning inclusion would depend on whether or not the signature adds to the article as a whole (personally, I don't really consider signatures of living people as a BLP problem as long as such signatures are known to the public anyway, like in autographs). But an outright ban seems too much. Narutolovehinata5 tccsdnew 02:03, 13 October 2017 (UTC)
  • Oppose. The signature is a means of self-identification; most people don't have logos or any other visual means of identifying themselves to others (aside from plain text versions of their names), except for their signatures. Plus, even if there's a problem with including a signature image in some articles, that doesn't mean that we should remove it from all. If you think that one article shouldn't have it, then start a discussion, but don't remove large numbers of signatures with AWB or a bot, and definitely don't remove them all by cutting the parameter out from the template. Nyttend (talk) 22:55, 13 October 2017 (UTC)
  • Oppose signatures are a notable characteristic and worth mentioning. --Tom (LT) (talk) 05:23, 14 October 2017 (UTC)
  • Oppose per User:Nihlus -- œ™ 04:42, 15 October 2017 (UTC)
  • Oppose: far too broad. In many cases the signature may have educational value for some readers. Jonathunder (talk) 04:52, 15 October 2017 (UTC)
  • Strong Oppose: The proposal seems to be in two parts - a) an assertion that no signature is ever relevant to an encyclopaedia. b) a move to strip signature images from every Infobox. I disagree with the assertion in a), but if that were ever to be the consensus of the community, so be it, and we would need to convert the essay WP:AUTOGRAPH into policy and ban use of all signatures or autographs in any article. Until such time as that happens, I firmly believe the Infobox is absolutely the right place to expect a signature to be located. It's akin to an infobox image of a person in visually summarising their identity. There's nothing to stop a signature/autograph being used elsewhere on a page, but we should not forced their removal from the most logical place to locate them by default - the Infobox. Issues relating to the uploading and appropriate use of signatures and autographs of living persons are best dealt with elsewhere and not in a discussion about Infobox data fields. Nick Moyes (talk) 09:06, 16 October 2017 (UTC)
  • Oppose: way too broad. If an article shouldn't have one, start a discussion there. Removing the parameter from the infobox makes no sense. Raystorm (¿Sí?) 16:53, 16 October 2017 (UTC)
  • Support in principle but Oppose as written; whilst there's a very good case for getting rid of these things, there are instances where they have encyclopedic value, and so a more nuanced proposal is needed. Yunshui 雲水 09:02, 17 October 2017 (UTC)
  • Oppose: This is a content matter, to be dealt with on a case-by-case basis, on article talk pages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:39, 18 October 2017 (UTC)
  • Oppose "No encyclopedic value" is just another way of saying WP:NIME: That info got there because people cared enough to put it there. Jclemens (talk) 05:24, 19 October 2017 (UTC)
  • Weak oppose. I agree with the OP that signatures are generally not relevant to the encyclopedia. However, in very limited cases, the opposite may be true. The standard should be to not include them, with the burden of proof of encyclopedic value and notability on those who wish to include them. A minimum requirement should be discussion of the signature in the article text. James (talk/contribs) 15:56, 20 October 2017 (UTC)
  • Support for BLPs, per privacy concerns. Oppose for BDPs.   ~ Tom.Reding (talk ⋅dgaf)  15:59, 23 October 2017 (UTC)
  • Oppose as written. Could get behind a looser wording that left John Hancock, etc. in. --SarekOfVulcan (talk) 20:22, 23 October 2017 (UTC)
  • Oppose The signatures give our users a deeper understanding of the topic. Many times the signature itself is not notable enough to warrant prose in the body of the article. The info box is a perfect place for it. I also reject the BLP concerns people have raised. Unless there is some sort of applicable law we should include it for living people too. Protecting privacy isn’t our business here.—Adam in MO Talk 07:35, 24 October 2017 (UTC)
  • Oppose Removing content because it's not "central" or "significant" continues, grinding WP down to mere overviews, bones with no meat. Any token that makes the subject - the individual - more real for the reader is to be granted our precious exhibition space. Doesn't a signature make a person vastly more 'actual', a physical reality, than some academic's whining about their tutor's faults? Shenme (talk) 02:25, 25 October 2017 (UTC)
  • Well, shouldn't we be talking first about getting rid of images? Who cares what some 18th century king or poet looked like? How he looked has zero bearing on his kinging or poetry. Also the frigging birth dates -- can we cut that down to just the year, please? If someone was born in 1836 that has meaning; it places him in historical context. Whether he was born on July 17th or September 12th has no meaning; it's datacruft that has no bearing on the person's life and works. Don't even get me started on where the guy is frigging buried for chrissakes (ooooh so important for understanding his career), or the ******* spouse for crying out load (exceptions, as always, for the rare cases where any of this is important or meaningful to understanding the person's career). Then after dealing with this datacruft maybe we can start talking about signatures. Herostratus (talk) 06:31, 25 October 2017 (UTC)
  • Oppose. Signatures are often iconic (Nixon's for example), and merit inclusion. A sweeping ban is not the right solution. — Insertcleverphrasehere (or here) 18:18, 25 October 2017 (UTC)
  • Strong oppose. A draconian measure with no justification. "No encyclopedic value" is an arbitrary, meaningless statement. Really, how can anyone say that signatures contain little or no encyclopedic value? Signatures are not only the most direct, personal, firsthand manifestation of an individual's identity, but they're literally the modern symbol of legitimacy and authenticity in the same way that a seals were historically (and still are) used. Personal correspondence, official correspondence, deeds, titles, declarations of independence, declarations of war, peace treaties—that is, any treaties, contracts, decrees, executive orders, banknotes, diplomas. It is signatures that give all of these things legitimacy in the eyes of society, and in the eyes of history. Far from being meaningless bits of information, the use of signatures (and before that, seals) to legitimize and authenticate documents is a cornerstone of civilization and has been since the very beginnings of human civilization. It's mind boggling to me that people don't think that there's any value in a signature, and that they're meaningless pictures provided for no other reason than that they're "neat" to look at. I find the very premise of this proposal unacademic. Swarm ♠ 20:23, 2 November 2017 (UTC)
  • Oppose. This sweeping omission would be unproductive, considering all of the notable signatures/signatures by notable people we deal with. -Indy beetle (talk) 06:10, 6 November 2017 (UTC)

Threaded discussion (Removal of signature fields)

  • Removing the field from BLP infoboxes would curb this practice. My issues:

    No verification is provided of whether these signatures are the real ones, and if so, how they were acquired; surely the file description pages should state whether they were copied from the original or a copy of it.

    Risk of invasion of privacy.

    Risk of security breach: the display presumably makes it a proposition to forge the BLP's signature in real life.

    Query over what it adds to readers' understanding of the topic. Tony (talk) 03:20, 9 October 2017 (UTC)

Tony1 has summarised the case for removing them well. I would add that if a signature is to be added it makes sense to do so in the body of the article, alongside the sourced content that justifies its inclusion. I can think of only a couple of cases (without checking the articles) when a signature was noteworthy. Richard Nixon’s, which deteriorated over the course of Watergate. Shakespeare who signed his name with a different spelling each time. But those are exceptional. The default should be not to include it.--JohnBlackburnewordsdeeds 04:02, 9 October 2017 (UTC)

  • @Nihlus: I'm not sure I understand your objection. How are those examples of signatures more worthwhile of being in an article infobox? And if the consensus was that the vast majority of signatures should be removed from infoboxes, what would be your recommendation be for defining those that you believe should be kept there? Why, specifically, should the ability to enact laws make the signature of that person more worthy of being displayed in an infobox? It's not as if the signature in one of our infoboxes is a determiner of whether those laws are legitimate or not, or that Wikipedia would be used as a source by a serious scholar investigating possibly forged signatures. I guess I just would like to hear some more on your point of view, since I don't believe the encyclopedia would be in any important way harmed by eliminating signatures in infoboxes altogether, and allowing the rare instance (John Hancock, for instance) where the signature has historic value in and of itself to be presented in an image in the body of the article. Beyond My Ken (talk) 05:27, 9 October 2017 (UTC)
    • @Beyond My Ken: My last sentence says I am not opposed to their removal in general; rather, I am opposed to their removal without guidance. You are going to see many users wonder where they are and wonder where they should go. I don't believe this proposal adequately (if at all) addresses that concern. Nihlus 05:33, 9 October 2017 (UTC)
      • My concern was (and is) eliminating signatures in infoboxes, which is why the RfC addresses only that issue, but I have absolutely no objection to people having a discussion either here in this section or in a new section about what the standards should be for use of signatures in articles. However, I do see that as a separate matter. Beyond My Ken (talk) 05:49, 9 October 2017 (UTC)
  • Since the proposal has a little traction, I've added a link to it on WP:Centralized discussions. Beyond My Ken (talk) 05:55, 9 October 2017 (UTC)
  • In principle, I support the above proposal, but would like to ask whether an exception could be made for Template:Infobox_royalty? I've always liked the fact that our articles on Ottoman sultans include their tughras in the infobox. No big deal, however. ---Sluzzelin talk 09:38, 9 October 2017 (UTC)
  • "Removing the field from BLP infoboxes" What's a "BLP" infobox? How is that different from a "dead for decades" infobox? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 18 October 2017 (UTC)

Alternative proposal:

Many of the support !votes have focused on privacy issues. and a fair number of the oppose !votes think that signatures are a good addition to articles about historical figures. How about only removing signatures from BLPs with an exception for individuals who have self-published their signatures? Nobody is going to use John Hancock's signature to commit identity theft, and if someone publishes their signature on their website or in a book they wrote, having it in an infobox doesn't increase the risk of it being used for nefarious purposes. --Guy Macon (talk) 15:24, 9 October 2017 (UTC)
Sure, but those of us with this view are already inserting it into the !voting section above.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  19:59, 9 October 2017 (UTC)
Yes, that would be appropriate, to limit the BLP question. Some living persons have used their signatures on books (Jimmy Carter, if memory serves me, and HRClinton), and wouldn't most American presidents and other world leaders' signatures be given public domain status due to their signature releases on official documents? Trump would be an example of a useful and interesting signature to keep in the infobox, and his official documented use should qualify as an aspect of public domain. Check out the {{John Hancock}} template, one of my favorites. Randy Kryn (talk) 21:50, 9 October 2017 (UTC)
Good approach. EEng 03:58, 18 October 2017 (UTC)
  • Comment When I read the article on Picasso, I fully expect to see an image of his signature within an infobox, almost as a matter of course— and if I saw none I would suspect there had been some oversight. A signature field (whether filled or not) seems appropriate for those professions in which signatures are regularly recorded as either indicators of authorship (artworks, works of notable literary fiction) or highly-visible markers of participation/ group membership/ social roles (the Declaration of Independence, presidential acts, baseball player's sigs on baseballs, kings, queens, sultans, however not the signatures of most academics/ researchers, medical doctors, singers, drummers, producers, writers of non-fiction, etc.) and should probably not be encouraged in the latter by the presence of an empty signature parameter begging to be filled. Can't we maybe do that? KDS4444 (talk) 22:26, 9 October 2017 (UTC)
    You expect it to be there because you're used to infoboxes having them; if they didn't, you wouldn't be. Your argument is essentially one for never changing anything, because "it's always been that way". Beyond My Ken (talk) 02:00, 10 October 2017 (UTC)
    KDS4444 more likely expected it to be there because Picasso's infobox should have his signature display, so the editor was surprised when it didn't. It certainly should be included, this is Picasso for Monet's sake. The argument isn't "it's always been that way" but more about the readers who, at least speaking for myself, like them and find some of them really interesting. Nothing is broken here, except for maybe the BLP issue which could be addressed as a separate topic if this discussion gets consensus to allow signatures of very notable he's-dead-Jim subjects (which seems to be the way it's heading). Randy Kryn (talk) 02:08, 10 October 2017 (UTC)
    I would disagree with the statement "nothing's broken here". What's broken is that infoboxes are intended to be a quick summary of the subject of the article, and -- in my opinion, of course, and apparently in the opinions of quite a few other editors -- the subject's signature is not basic key information in the same way that, for instance, birth and death dates and an image are. (I'd also disagree with your statement up above "These are always interesting" - no, actually, with rare exceptions, they're not really interesting at all, they're pretty darn uninteresting -- again IMO.) Beyond My Ken (talk) 05:14, 10 October 2017 (UTC)
  • Oppose It is interesting to see the differing handwriting between some historical figures and celebrities. In many ways it speaks about their character. --Penpalthe (talk) 07:49, 10 October 2017 (UTC)
    So why did you just oppose an alternative proposal that keeps the signature of historical figures and celebrities? --Guy Macon (talk) 20:04, 10 October 2017 (UTC)
  • Weak and watery support. I'm sure the reader should be encouraged to move on to more important things in an article. Martinevans123 (talk) 19:37, 10 October 2017 (UTC)
  • Support—sensible. Tony (talk) 01:39, 11 October 2017 (UTC)
  • Support: as proposer. --Guy Macon (talk) 02:49, 11 October 2017 (UTC)
  • Comment. I'd be fine with a requirement that the signature be openly published elsewhere before we can use it here. In fact, that would also be in keeping with the spirit of our WP:NFCC policies. --Tryptofish (talk) 17:24, 11 October 2017 (UTC)
  • Supportish - Not sure there is such a problem, but if we limited this solely to living persons, with an exception of when that living person has published their signature elsewhere (artists are a good example), then the restriction makes sense as it addressing potential privacy issues. Dennis Brown - 2¢ 16:13, 12 October 2017 (UTC)
  • Meh. Better than a global ban, I guess. I'm not convinced there's a real problem. If WP editors can get their hands on a signature, then the bad guys can probably do it independently, and I'm not sure it would do them that much good anyway. I would certainly support respecting takedown requests from the interested party. --Trovatore (talk) 02:03, 13 October 2017 (UTC)
  • Comment This RfC has transmogrified from a proposal on stripping a data field from a template to one on the circumstances in which a signature image is ok to be used. Seems an entirely different discussion to me. Nick Moyes (talk) 09:22, 16 October 2017 (UTC)
    • You are correct, but often this is helpful to truly get a consensus on how editors feel about signatures in article, and gauging whether or not there is really a problem, and what that problem is. The RFC won't likely pass, but the extended content still provides useful information. If the alternative had strong enough support, it would create the basis for a whole new RFC, for instance. Or if it isn't, would demonstrate why a new RFC would be pointless. Dennis Brown - 2¢ 21:21, 16 October 2017 (UTC)
  • Why is the privacy of BLPs our concern? Is there a legal issue here? In some cases we have BLP’s with notable homes and we provide GPS coordinates to their domicile, when notable. If their signature is notable why shouldn’t we do the same? —Adam in MO Talk 07:39, 24 October 2017 (UTC)
  • Oppose Throwing out the baby with the bathwater. Deb (talk) 10:57, 26 October 2017 (UTC)
  • 'Support if "published" is construed boradly and "BLP" is construed narrowly. That is, signatures on public manifestos, artworks, and campaign materials are "published." A living Picasso or Walt Disney should have their signatures included. And the BLP concerns should exclude high profile figures.--Carwil (talk) 19:23, 30 October 2017 (UTC)
  • Support. The exact wording of it could be massaged later, but the central principle is sound, and is what I advocated (in part) in the main discussion above.  — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ<  15:47, 6 November 2017 (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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_142&oldid=1144235235"