Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by A Den Jentyl Ettien Avel Dysklyver (talk | contribs) at 09:16, 10 September 2017 (c/e). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Automatic column mode for references element

It seems the proposed changes have already come into effect (making the discussion moot) but regardless there is general support for it. Further issues and concerns should be taken up in a new discussion. Primefac (talk) 16:34, 29 August 2017 (UTC)[reply]

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.

Tracked in Phabricator
Task T173176

Recently it became possible for <references /> to automatically use responsive columns when there are more than 10 references in the generated list. Currently this behaviour is an opt-in mode (<references responsive="1"/>). The opt-in was intentional as throughout Wikimedia, we had many templates that already relied on pre-existing behaviour. Recently I prepared {{Reflist}}, to be able to deal with both situations. As such it would now be possible, to switch the default of <references />, without influencing {{Reflist}}. I think a default column mode is easier for most situations that do not require {{Reflist}} and I want to propose to switch the default of <references /> to automatic responsive columns. So to summarise:

  1. Currently <references /> never has columns
  2. When we switch the default, <references /> will have columns if there are more than 10 references (30em wide, same size as most Reflist usages).
  3. This switch of the default will not influence {{Reflist}}, which can be used for changing column width and a few more advanced features.
  4. It will be possible to disable these columns by using <references responsive="0" />.

If there is agreement, then we can file a phabricator bug report to make the change. —TheDJ (talk • contribs) 09:15, 13 July 2017 (UTC)[reply]

  • Yes please! --Izno (talk) 12:21, 13 July 2017 (UTC)[reply]
  • It would be great! --Jennica✿ / talk 14:52, 13 July 2017 (UTC)[reply]
  • The change reduces the size of the text. This change was not mentioned in the description of this change. I prefer that the type size match the body of the article. Jc3s5h (talk) 15:39, 13 July 2017 (UTC)[reply]
    • @Jc3s5h: I'm not sure how you reached that conclusion, but I cannot confirm it. All references lists have a font-size of 90%. It has been like that since 2011 as far as I can tell. Can you please give examples, and information regarding the skin you use perhaps ?—TheDJ (talk • contribs) 15:55, 13 July 2017 (UTC)[reply]
      • When I tried to reproduce the problem, I realized the article I used as an example has several reference-related subheadings and I had been mixed up about which section I changed (in preview mode only, of course). Jc3s5h (talk) 16:12, 13 July 2017 (UTC)[reply]
  • I agree with this change. The columns seem to be just slightly too wide at the moment, but maybe this is deliberate. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     05:58, 14 July 2017 (UTC)[reply]
  • I support this change. There will no doubt be some minor unintended consequences and some necessary cleanup to a few articles, but that is the price of progress. – Jonesey95 (talk) 16:19, 14 July 2017 (UTC)[reply]
  • Mild oppose. Personally, I prefer the single column style, and think that the change to 2 column that is often made is rarely an improvement. Making it the default will mean this is done with little thought far too widely. If this is to be done, the threshold of 10 is much too low, 30 is about right, at the lowest. DES (talk)DESiegel Contribs 14:44, 15 July 2017 (UTC)[reply]
  • This sounds like a nice improvement. I support making it the default. Kaldari (talk) 18:40, 15 July 2017 (UTC)[reply]
  • I kind of oppose this. As {{reflist}} already does this, changing <references /> too would make creating a single column ref list needlessly complicated. Daß Wölf 21:53, 15 July 2017 (UTC)[reply]
  • Oppose. Multiple columns are fine for simple citations, but make it difficult to read long explanatory footnotes. In considering whether to use columns, and of what width, our first consideration should be what makes things easiest for the reader. That has to be done on a case-by-case basis rather than according to an arbitrary standard based on the number of citations. Ammodramus (talk) 16:55, 16 July 2017 (UTC)[reply]
    • @Ammodramus: You consider the case of NOT having columns for lists larger than 10 items to be more common than having columns ? I think we should cater to the largest group of users and to 'safe' defaults. I think that if we can have 90% of the cases right and only need to modify 10%, then that is better than the reverse for the casual editor right ? —TheDJ (talk • contribs) 10:17, 17 July 2017 (UTC)[reply]
  • Would support if the proposal is limited to two columns only. Even long citations / quotes are reasonably easy to read if in a two-column format. Is that what's intended by the proposal. K.e.coffman (talk) 21:20, 16 July 2017 (UTC)[reply]
  • Oppose Support because we already have this with {{Reflist|}}. Why re-invent the wheel? What are the benefits of having two paths to get to the same place? Also, with today's screen proportions trending towards wider screens, three ref columns are being used more and more; so if this change were to take place, that capability should be available as well. I'd still oppose this, however, for the same reason as above. It's not a needed universal change, and we already have the way to do it. GenQuest "Talk to Me" 11:16, 17 July 2017 (UTC)[reply]
    • I see several errors in reasoning here. (1) The wheel is already reinvented, it just needs turning on. Our {{reflist}}'s multi-column support was liked so much it got added to the extension itself. (2) This change would use three columns on wide enough screens, it's more or less equivalent to {{reflist|30em}}, not {{reflist|2}}. (3) Two ways to do it already exist. The only thing this change changes is to make the default when "responsive" isn't specified in <references /> be <references responsive=1 /> rather than <references responsive=0 />. Anomie⚔ 12:14, 17 July 2017 (UTC)[reply]
  • Support People generally like multiple columns, which is why {{reflist}} is so widely used. We may as well make it the default for a bare <references /> too, where it will use what is currently recommended as the multi-column setting in Template:Reflist/doc#Columns. Anomie⚔ 12:14, 17 July 2017 (UTC)[reply]
  • If we were to remove all paragraph dividers and section headers the one would scroll less but that does not mean that the article would be more readable. -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
Hey, DGG. I see some typos and errors above in your post. Kind regards, --George Ho (talk) 11:31, 19 July 2017 (UTC)[reply]
(fixed, though that won;t fix the ping)--S Philbrick(Talk) 19:44, 27 July 2017 (UTC)[reply]
  • Support --S Philbrick(Talk) 19:44, 27 July 2017 (UTC)[reply]
  • Support -- less work for editors and bots.--Nizil (talk) 07:41, 31 July 2017 (UTC)[reply]
    @User:Nizil Shah How is it less work? -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
    Editors do not have to check and arrange refs in columns when number of refs increases. So one less thing to care about.--Nizil (talk) 06:40, 15 August 2017 (UTC)[reply]
  • Support, especially given that it's only a change to the default. Peter coxhead (talk) 08:14, 31 July 2017 (UTC)[reply]
  • Strong Oppose, at least unless the following issues can be proven not to apply: You're talking about reformatting hundreds of thousands of pages automatically, sight unseen. (I'd say millions, but alas, I think our average article's sourcing may be too scanty) What happens when the multi-column references interact with infoboxes, graphics, tables, elements that editors have customized by hand with HTML and CSS markup? If they break the format, do editors of that page have any way to know that the references behavior was changed? Even if an editor goes back to the history version, will he see the references appear the way they used to or will he see a broken page was always there? (I think the latter). I'm sorry, but as a general rule, please do NOT mess with default behavior. There's not even any obvious reason I can see why two columns are "better" for "more than 10" references but "worse" for less! Personally I've used the simple references / on even stubs with just a few references because it seems easier to read and keep track of a plain list, so I admit some bias against the idea to begin with, but I think the backward/history compatibility and formatting are serious issues. Wnt (talk) 11:39, 4 August 2017 (UTC)[reply]
    • Wnt, can you give a couple of examples of pages that might be affected? The pages you're talking about would have to meet all three of these conditions:
      1. they use <references /> (not {{reflist}} or similar templates),
      2. they have more than ten refs in the group, and
      3. they have hand-customized HTML and CSS markup that affects the list.
    • I don't ever remember seeing an article that meets all three conditions, and I think that a few examples would help people figure out what you're talking about. This search should give you the list of all articles that meet the first condition (plus maybe an extra 25% that don't), which might help you start your search. If my very quick spot-check is reasonably representative, then something on the order of 100,000 articles meet the first two conditions, but I can't find any that meet all three. I look forward to seeing your examples. Whatamidoing (WMF) (talk) 17:44, 6 August 2017 (UTC)[reply]
      • @Whatamidoing (WMF): Your search isn't working for me - it pulls out things with reflist and references responsive, etc. Also, checking ten more or less totally random articles using that search, as I did, is not checking a hundred thousand. So I did not find the exact thing you mention. But I *did* already find Paladin (Dungeons & Dragons) in that ten, which has a list of twelve footnotes that I think would be less readable when you decide, sight unseen, to put them into columns. If you want, you're welcome to go put a reflist|2 or references responsive into that section and see how the local editors respond. But if it seems pointless or counterproductive to make that change to one article, how can it be OK to do it to all of them? Wnt (talk) 18:02, 6 August 2017 (UTC)[reply]
        1. The search pulls out pages using the reflist template, because the proposed change here is "to switch the default of <references />, without influencing {{Reflist}}" (emphasis added), so those pages are irrelevant.
        2. Your written objection above is about "elements that editors have customized by hand with HTML and CSS markup". If nobody can find any examples of such elements actually existing in articles that will actually be affected by this, then perhaps you'd like to withdraw your objection?
        3. User research demonstrates that splitting long (but not short) lists of refs into responsive columns (NB that'd be {{reflist|30em}}, not {{reflist|exactly two fixed columns no matter what, because that's what looks pretty on my screen}}) makes it easier/faster to find what you're looking for in the refs. So, yes, I do think changing that article to use columns for the refs would be a pointful and productive change. Is it (IMO) hugely important for 12 brief refs to use columns on wider screens? Probably not. The longer the list (and the wider the screen), the greater the benefits. Readers will get some benefits at this length, and they will get more benefits with longer lists. Whatamidoing (WMF) (talk) 17:52, 7 August 2017 (UTC)[reply]
    • We have had this discussion. In my opinion it's worth it to break a few rare exceptions if we improve behavior for the far larger majority. For almost any change it is possible to find a small downside and if we give that undue weight, then we will never move forward on anything. Besides if editors have expectations about article content never changing in either format or contents, then they are misguide, per WP:OWN. Styling should never be relied upon when writing. We are not typesetting a book or a newspaper, we are using HTML, to deliver to each and every person a page that is optimized for his or her usage of the content. And before we get wound up about backwards compatibility, let us not forget that we regularly delete entire templates, even though they have been used in articles. Everything is relative. —TheDJ (talk • contribs) 15:38, 9 August 2017 (UTC)[reply]
  • Support – The majority of articles use, with good reason, {{Reflist}}, {{Reflist|30em}}, and some other variations that display responsive columns. Making <references /> behave the same way will improve consistency across Wikipedia. A 1-column display for >10 references can still be done. No downside. -- Michael Bednarek (talk) 13:20, 8 August 2017 (UTC)[reply]
    @User:Michael Bednarek what is you evidence for this even if the template {{Reflist}} is used it is usually used without any column formatting and until User:TheDJ changed it recently it too displayed one column by default. -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
  • Support - this is something novice editors can almost never understand, and I don't believe new article creators should have to worry about it. There are few articles for which a multi-column reference list would be inappropriate, and it shouldn't be necessary to manually recode the reflist to be multi-column once it swells up - it should certainly be an automatic thing. Blythwood (talk) 22:17, 9 August 2017 (UTC)[reply]
  • Support - thanks for taking this hard work on. I'm glad to see this proposal come to fruition - as editors we really shouldn't have to manually set how many columns a reference list has. Legoktm (talk) 03:39, 10 August 2017 (UTC)[reply]
  • Support. As I understand it, the facilities to produce other column widths and numbers will remain for those rare occasions where they may be useful, so I see no real down side, only imaginary/hypothetical ones. • • • Peter (Southwood) (talk): 10:08, 10 August 2017 (UTC)[reply]
  • Support. Where {{reflist}} section 2.1, bullet 3 applies it can be overridden (see for example Edith Cavell). The only problem is if someone lets loose a bot or goes off on a spree removing all reflist parameters without reading and thinking. Martin of Sheffield (talk) 11:13, 10 August 2017 (UTC)[reply]
  • Comment I think that this needs to be decided by an RfC, and as this affects the citation style I think it appropriate to hold it on the talk page of the guideline that covers this issue, so see Wikipedia talk:Citing sources#RfC: Number of columns when displaying ref..tags -- PBS (talk) 11:31, 10 August 2017 (UTC)[reply]
  • Support, so long as the behaviour can be turned off by code. While this would work with the vast majority of pages, some will be better off with refs in a flat list rather than columns. Ivanvector (Talk/Edits) 19:26, 10 August 2017 (UTC)[reply]
  • Comment I first saw this earlier today, and was at first in the negative camp wrt a new default for {{reflist}}, but have softened somewhat because I see its value in the majority of cases. I recognize that the ship has probably sailed, but I'm with PBS (talk · contribs) in regretting its effect on readability for articles that have at least one reference generated by templates referring to EB1911, EB9, DNB, CathEnc etc (of which there are probably tens of thousands) due to their inevitable length. Great Officer of State is the current canonical exhibit A, but even one such reference tightly wrapped into multiple lines in a column is plain ugly. Fortunately, it's the nature of such articles dependent on old PD sources that this citation is often the only one, and having more than ten is a small minority. I don't know of a good solution for these cases; manually forcing some to one column on the basis of visual style is way down the totem poles of priority for me. I am aware that using {{sfn}} with a single "source" notation is an alternative, but have other issues with that approach.
Some have suggested that we use {{reflist|1}} as an override. But I thought the unnamed parameter was deprecated, so that confuses me.
I'm also in agreement with whoever said that the XML element looks like the old Wikipedia, as opposed to the more concise reflist, especially with LDRs. But, if it's going to be used, I hope we don't literally mean people should write <references responsive /> (an attribute without a value) because it's invalid XML. David Brooks (talk) 21:12, 10 August 2017 (UTC)[reply]
ETA: I realize I'm not being constructive above. Does the implementation have the ability to increase the column width if it detects that there are footnotes with more than a certain number of characters? Great Officer of State looks much better at 48em, and slightly better at 40em, than the default (I realize that would often just end up in a single column). Also, now that I understand the syntax I see that my comment about LDRs above is backwards, so I withdraw it.
To Mike Christie's comment below - may be true for new articles, so long as the editor is up to date on the responsive feature, but for existing articles requires first finding candidates, which would take some deep analysis. Not so simple. David Brooks (talk) 01:45, 11 August 2017 (UTC)[reply]
  • Commment @user:Winged Blades of Godric I have re-open this as I created an RfC two days ago about this issue and my questions there were not addressed. There is no reason for closing this so quickly particularly as it was not well advertised. It is a very big change that affects a lot of pages so I think that there needs to much more widely advertised, than it has been so far. -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
@PBS: Besides being listed at Template:Centralized discussion (as mentioned by Godric), there were notifications at Wikipedia talk:Citing sources, Help talk:Citation Style 1, Help talk:Footnotes, Template talk:Reflist, and Wikipedia:Village pump (technical). Were they not adequate enough? --George Ho (talk) 20:34, 12 August 2017 (UTC)[reply]
  • Oppose keeping default as 1 column. It was the change to the template {{reflist}} that now displays multiple columns as seen on the page Great Officer of State that alerted me to this change. While I agree that short citations are better displayed with multiple columns, the majority of pages I have looked at, if they have inline citations, they are full citations and I do not think that full citations are better wrapped into narrow columns because it makes them harder to read. -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
  • Comment @User:TheDJ, I think your comments at VP show a misunderstanding of why people use {{reflist}}. They may use it to display multiple columns, but they may also use it for its other attributes of making the text smaller, or simply use it because it is used elsewhere. It would be interesting to see a proper search done, but using insource:/\{\{[Rr]eflist/ (which times out), and the small sample returned on the first page of results: twelve of the 20 have no parameter, two use "2" as the parameter five use "em30" and one uses "em35".-- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
  • Comment @User:TheDJ On the page Wikipedia talk:Citing sources you wrote "I will just note that people on this page were informed and invited, several sections up: #Proposal to default references element to column mode. —TheDJ (talk • contribs) 13:53, 10 August 2017 (UTC)"[reply]
    (1) what makes you think that "Proposal to default references element to column mode" would be a very significant header or that "I have started a proposal to switch the default behaviour of to automatic column mode" would be understood by most people that you intended to change the behaviour of the default setting? (2) why did you make changes to the default behaviour of {{reflist}} before there was a general consensus for such a change? -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]
For your kind information, this was listed at Centralized discussion for an entire month.Your RFC was already closed.Now, move on or take this to AN.Winged Blades Godric 17:04, 12 August 2017 (UTC)[reply]
@PBS:--Winged Blades Godric 17:07, 12 August 2017 (UTC)[reply]
@User:Winged Blades of Godric This was not an RfC so there was no reason to close it after a month. Besides people are clearly still posting the section so why close it? Are you in favour of the proposition or against it? -- PBS (talk) 17:22, 12 August 2017 (UTC)[reply]
  • Comment Since this thread is still active but it seems the feature is now established, I want to reiterate a request I made above that may have been overlooked. PBS (and I) make a valid point: the impact on long references is deleterious to readability. There are probably thousands of articles with long refs in their footnotes (and I may be underestimating by a ten-factor or more). Finding and editing the subset of such articles that have 10+ footnotes in order to widen the columns may be beyond my abilities to automate. So the request is: can the "references responsive" code be enhanced to detect long lines in the footnotes, and substitute a column width of 48em? For some definition of "long", and some tweaking of "48", of course. David Brooks (talk) 17:31, 12 August 2017 (UTC)[reply]
That's because your text isn't like footnotes, with its mixture of very short and moderately short lines. Using our admittedly extreme example of Great Officer of State, compare the default setting with one I forced to 42em width (not even the 48 I mentioned) at different window sizes. I think wider is better in this case, although 30 is probably OK for the typical footnote. Now consider the pages many where the full footnote is generated by {{EB1911}} with inline parameter, like "One or more of the preceding sentences incorporates text from a publication now in the public domain: Chisholm, Hugh, ed. (1911). "Antithesis". Encyclopædia Britannica. 2 (11th ed.). Cambridge University Press. pp. 146–147." (see Antithesis, where I experimented with 40em) for the more extreme effect. Or consider editors who put a fully-populated {{Cite book}} in an inline ref. David Brooks (talk) 00:02, 14 August 2017 (UTC)[reply]
In both examples you give, I like the two-column approach better than the one-column approach. (Those widths work out to that number of columns on my screen; it may be different on yours.) Whatamidoing (WMF) (talk) 00:40, 14 August 2017 (UTC)[reply]
What we are talking about here is a style preference. As most editors who have subsituted {{reflist}} for <references/> have presumably chosen the number of columns they want, it is reasonable to assume that they chose none because they wanted one column. As that was a style preference, I do not see why that ought to be changed particularly as it runs contrary to the spirit of WP:CITEVAR. A change such as this that affects 100,000s of pages ought not to be made by about a score of editors in a discussion that is not even an RfC. -- PBS (talk) 09:41, 15 August 2017 (UTC)[reply]
PBS, while I agree with you in this particular debate, I don't see support for your assertion that "most editors who have subsituted {{reflist}} for <references/> have presumably chosen the number of columns they want". I make the substitution in any case, often through an AWB template, because I remember reading some time (years?) ago that the template is preferred to the xml - in part because it does allow for parameters, but also because raw XML in a document seems so 20th century. Yes, it's more transclusion work for the backend, but that's what servers are for. David Brooks (talk) 16:41, 15 August 2017 (UTC)[reply]
@DB surly if you replace <references/> with {{reflist}} then you choose how many columns you want. Personally I often use {{reflist|30em}} but that is because I expect there to be 2 columns on a typical computer display (more or less depending on the width of the window). If I set it to {{reflist}} then I have deliberately chosen to one column. -- PBS (talk) 17:38, 15 August 2017 (UTC)[reply]
I took a look at 10 pages currently using the <references /> tag. I found two added before {{reflist}} was created, and another just days after its initial creation (in late 2006). Two were added by editors who primarily edited at wikis that don't use that template. One was added in 2007, three by experienced editors in 2008, and the last by a logged-out editor in 2009. I found no examples of editors removing the template in favor of the native code (although I've personally done that, because the visual editor does live updates for the native code, but not the template, while you're editing).
Another way of stating this is that some of these were added before the reflist template was an available option, and all of these were added before {{reflist}} was used by the Article Creation Wizard or otherwise recommended as the "normal" way to add refs (which, if memory serves, had much more to do with the size of the font than anything else, but now the two methods use the same font, so that distinction no longer exists).
None of this suggests that a deliberate choice against having columns in the article. PBS, if you have evidence that the use of <references /> is a deliberate request for a single column, then please share it. (Remember, the change under discussion has no effect whatsoever on what happens to any article that is using {{reflist}}. It's only about what happens to pages such as Original video animation, where <references /> was added before the {{reflist}} template even existed, and has never been replaced. So if anyone changed an article from <references /> to {{reflist}}, then that article will not be affected by this. It's only if you changed it the other way around that the article could be affected – and I found no examples of people doing that.) Whatamidoing (WMF) (talk) 18:28, 15 August 2017 (UTC)[reply]
It is not an issue of <references/> because that has always been one column. However in anticipation of a change to <references /> {{reflist}} has been changed to emulate it. As the majority of the {{reflist}} I surveyed in a crude search were single column, it seems reasonable to assume that it is a reasonable proxy for the preferred number of columns among those editors who have exercised a choice. -- PBS (talk) 14:41, 18 August 2017 (UTC)[reply]
It looks like {{reflist}} has been changed to explicitly specify either responsive=1 or responsive=0 on every page, but this proposal is unrelated to that. Supporting or opposing this change will not have any effect on {{reflist}} or any page that is using that template.
Given that the Article Wizard puts plain {{reflist}} in all articles, and given that plain {{reflist}} seems to have been put by bot/AWB into more than a million articles during the last five years, I am not convinced by your assertion that the use of the plain template indicates an intentional use of one column. Perhaps a better measure would be the use of columns in GAs and FAs, since those generally include long lists of references, and are generally written by editors who know how to change the default.
But even if I were convinced by your argument that not changing the template indicates intentionality, it's pretty much irrelevant, because this change will not have any effect whatsoever on the reflist template, or on any page that is using the reflist template. This change amounts to "When the responsive status is not specified (e.g., when the responsive-status-specifying reflist template is not used), then it should produce two or maybe three columns, on long lists of references, if your screen is wide enough."
This change will likely affect ≤2% of articles. Whatamidoing (WMF) (talk) 16:36, 18 August 2017 (UTC)[reply]
  • DavidBrooks, your example, Great Officer of State, has quite short references compared to fully expanded references for books, institutional web pages, and journal articles used in many areas of Wikipedia. To have reflist detect such short references and use overly wide columns would completely undo the point of responsive references for much of the English Wikipedia. StarryGrandma (talk) 21:00, 14 August 2017 (UTC)[reply]
  • That PBS and a few others feel that more disc. is needed, I would like to request the discussants to re-post this thread at Cent and make some fresh advertisements at related notice-boards.Otherwise, from the mini-post-closure discussion that is taking place, I fear, that it may be the same set of faces arguing/discusing broadly on the same set of themes.Esp. in an area where perceptions (rel. to readability et al) matter considerably, new faces would be welcome for sure.Winged Blades Godric 10:02, 14 August 2017 (UTC)[reply]
I reinserted the entry into CENT template, Godric. I also notified others about this discussion. I wasn't sure whether to notify at WT:V or request posting an announcement at MediaWiki talk:Sitenotice, or MediaWiki talk:Watchlist-details, but I should be careful about canvassing before doing any of those options. --George Ho (talk) 10:34, 14 August 2017 (UTC); partially struck, 13:05, 15 August 2017 (UTC)[reply]
thats fine, but I will not spend more time on this than I have. —TheDJ (talk • contribs) 02:57, 15 August 2017 (UTC)[reply]
PBS, may this discussion be mentioned in MediaWiki:Watchlist-details or MediaWiki:Sitenotice? You said that the discussion needs more input, right? --George Ho (talk) 12:50, 15 August 2017 (UTC)[reply]
George Ho, a watchlist or site notice for this would be inappropriate. This a minor formatting change, not a major policy issue. TonyBallioni (talk) 13:03, 15 August 2017 (UTC)[reply]
Rescinded consideration. --George Ho (talk) 13:04, 15 August 2017 (UTC)[reply]
  • Comment@ StarryGrandma I agree with you, but the problem I have finding a really good example is that most of the pages I edit tend to use short citations and separate references section, and I think that columns are preferable for short citations. I tend to come across articles with 100 of large inline references only when I am running AWB scripts to fix something else, and as this is not an issue that has come up before I have not kept a record of such articles. Perhaps someone else has a few examples which can be used so that others view them and made an informed decision. -- PBS (talk) 09:24, 15 August 2017 (UTC)[reply]
Try Pythagoreanism and Birecik, both of which contain two of the "long" version of the EB1911 template. Now I look at those, with some other long citations, I'm even more against the idea of forcing a width without reference to the line lengths. There are many other pages with multiline references due to book citations etc. But I am sensitive to the problem that choosing a bigger width (42 or 48) would result in just one column anyway, on most displays that aren't fullscreen on a PC. David Brooks (talk) 16:41, 15 August 2017 (UTC)[reply]
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.

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
I presented an argument below. RileyBugz会話投稿記録 18:56, 8 August 2017 (UTC)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
Also, we don't need more bureaucracy to slow us down. RileyBugz会話投稿記録 14:53, 8 August 2017 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@Insertcleverphrasehere: And? – Joe (talk) 18:25, 8 August 2017 (UTC)[reply]
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)[reply]
"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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
  • Oppose. If speedily deletion remains possible, then the lesser recourse of speedy draftification must remain possible. bd2412 T 19:04, 8 August 2017 (UTC)[reply]
  • 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
How about a way of preventing it from ever happening? Hawkeye7 (talk) 03:37, 12 August 2017 (UTC)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose a blanket ban, support the creation of some kind of guideline. ♠PMC♠ (talk) 01:02, 10 August 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Strong oppose per Seraphimblade. (((The Quixotic Potato))) (talk) 23:19, 10 August 2017 (UTC)[reply]
  • Oppose unless there is data showing that limiting draft moves is beneficial. Esquivalience (talk) 00:49, 11 August 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
  • 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 (both 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Create a new Event Coordinators user group

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)[reply]

  • 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)[reply]
    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)[reply]
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)[reply]
  • Comment @Kaldari: have you seen the discussions at Wikipedia talk:Account creator - talking about event needs? — xaosflux Talk 22:08, 18 August 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
CAPTCHAs for every single edit are not disruptive? — InsertCleverPhraseHere (or here) 05:33, 19 August 2017 (UTC)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
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)[reply]
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).[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • Oppose per Starblind. – Train2104 (t • c) 18:28, 6 September 2017 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

Automatic R2

I propose that {{R from move}}, which is automatically added to all moves, be modified to transclude {{db-r2}} when located in mainspace and the target is located outside the Main/Template/Category/WP/Portal spaces. We already allow page movers to suppress redirects when making these moves (WP:PM/C#6). I don't see the benefit of having others' moves leave redirects that then have to be cleaned up, and as far as I can tell, there are no valid reasons for keeping such redirects. See {{R from move/sandbox}} for a draft implementation. – Train2104 (t • c) 21:26, 26 August 2017 (UTC)[reply]

The template R from move would need to know where a page redirects. If it is placed above the #redirect call, that is not possible. If it is placed below, it might be possible in Lua (but not in Template script), but I'm not sure the MediaWiki API knows where a page redirects on the redirect page. --Izno (talk) 21:30, 26 August 2017 (UTC)[reply]
It's placed beneath the redirect by MediaWiki:Move-redirect-text, and Module:Redirect provides the functionality. For testing purposes I changed the conditional to check for userspace and used {{db-g7}} instead of {{db-r2}}, since the latter does not display outside mainspace. Test It works, except that speedy template looks really strange. – Train2104 (t • c) 21:48, 26 August 2017 (UTC)[reply]
Can someone familiar with the R-tag templates tell me why the CSD tag looks so strange in there? @Paine Ellsworth: perhaps? – Train2104 (t • c) 23:40, 26 August 2017 (UTC)[reply]
Thank you very much for the ping, Train2104! I think the reason some of the text is outside and above the main display has something to do with the fact that the outside text is generated by the meta template used by {{db-g7}}. That template, {{db-meta}}, uses the {{Mbox}} template, which can be interfered with by HTML Tidy when not correctly positioned on a page. In this case, the G7 template should go at the TOP, the very top of a page. Place it anywhere else on a page, as the {{R from move/sandbox}} does, and HTML Tidy may cause the template to appear in an abnormal and unexpected manner when saved.
We should also note that page movers are given the suppress-redirect tool specifically to perform round-robin page swaps. The redirect is suppressed only to make way to move another page into that title. Page movers are warned that to suppress a redirect under any other circumstances should be done only very carefully and selectively to prevent breaking links both on and off Wikipedia.  Paine Ellsworth  put'r there  00:48, 27 August 2017 (UTC)[reply]
Fixed it by putting it on top of the message. I've seen many cases of CSD buried under redirect and they looked fine, unfortunately we can't automatically place it on top of the page (unless a bot is involved). Thanks for the hint to look into positioning! – Train2104 (t • c) 01:43, 27 August 2017 (UTC)[reply]
Yes, I thought about that possibility several hours after I posted the above. The important thing with the Mbox and HTML Tidy is that the template should be at the start of its own line (not necessarily at the TOP of the page). I'm glad you tried that and that it worked. Yet I'm still a bit concerned over the "automatic" addition of any Db template. Seems to me it could quickly grow to be a migraine for admins.  Paine Ellsworth  put'r there  06:17, 28 August 2017 (UTC)[reply]
My oppose struck, thank you. Thincat (talk) 16:47, 1 September 2017 (UTC)[reply]
  • Comment WP:R2 says "If the redirect was the result of a page move, consider waiting a day or two before deleting the redirect." so this places the onus for the delay on the admin, not the tagger. Perhaps that is what is meant anyway. Can a warning to the admin be placed in some way? Thincat (talk) 16:56, 1 September 2017 (UTC)[reply]
My comment struck because {{db-r2}} already provides a warning. Thincat (talk) 17:02, 1 September 2017 (UTC)[reply]
Um... I'm pretty sure that this proposal meant to apply specifically to moves made by non page movers and admins (which together make up a very small fraction of total editors). I thought it was implied that moves made by page movers and admins would be suppressed (if checked) and moves made without suppression (i.e. by others) would be tagged for R2 if directed to draft space. Presumably that would also tag redirects created by page movers or admins that forgot to suppress, but that is still better than leaving these cross namespace redirects in place. — InsertCleverPhraseHere (or here) 11:11, 3 September 2017 (UTC)[reply]
As you noted, there are a very small number of editors to whom this might apply. And WP:R2 covers the deletion of redirects from page moves that are not needed. It also states: "If the redirect was the result of a page move, consider waiting a day or two before deleting the redirect." To me, this means for non-page movers to refrain from even applying {{db-r2}} for "a day or two", which goes counter to this proposal that would apply the SD template immediately. To address "...that would also tag redirects created by page movers or admins that forgot to suppress..." That is not really a good reason for such changes. IMHO, we should not make sweeping changes just to try to make up for editorial mistakes. A better solution would be to educate editors. We might want to consider an edifying addition to WP:MOVE where needed.  Paine Ellsworth  put'r there  22:27, 3 September 2017 (UTC)[reply]
I think you misunderstand me. this change would affect and improve the experience of all of the other editors (the large group), not admins or page movers (the small group). For page movers and admins, this change would likely have no effect at all, as those users generally suppress redirects anyway (again unless they forget, in which case this change would be a bonus improvement to them as well). The R2 statement about deleting the redirect is about when to delete the redirect after the redirect has been tagged (i.e. it does not say "consider waiting a day or two before tagging the redirect for deletion." it says "before deleting the redirect") This isn't about making up for editorial mistakes, it is about making the lives of normal editors who do not have redirect suppression privileges easier by autotagging redirects from mainspace to draftspace. dbR2 should always be applied to the redirect in these cases, so there is no reason not to make the process automatic and remove a trivial step (none that I am aware of anyway, feel free to enlighten me). — InsertCleverPhraseHere (or here) 23:07, 3 September 2017 (UTC)[reply]
First enlighten me. You said "this change would affect and improve the experience of all of the other editors (the large group)". So just how large is this "large group" of editors that move unready mainspace pages to draftspace and cannot suppress the redirect themselves and must add the db-r2 template? Is it large enough to warrant this alteration to a template that is presently used on close to a million redirects with the number growing daily by leaps and bounds? I doubt it, so no, IMAO there is no reason that the "large group" of editors can't continue to apply the SD template manually, which really isn't such a chore, you know.  Paine Ellsworth  put'r there  23:17, 3 September 2017 (UTC)[reply]
PS. I consider your interpretation of the text at db-r2 to prove that it's subject to intepretation. And if we go with your choice, then we just get back to this proposal being a potentially huge migraine for the admins who monitor the db-r2 template application log. PS added by  Paine Ellsworth  put'r there 
Those are fair arguments. It may be that the number of people performing such moves is small (I'd have have a watch of the R2 CSD category for a while to see), but it could also be that many non-pagemover reviewers simply avoid the hassle of draftification because of the need to manually add tags (probably not that likely but possible). In any case the potential number of people that this would apply to (all editors except the 1000 or so Admins and page movers), is a very large group. Per your second point, I guess the real question is if changing the global template makes any noticeable change to any of the existing non-draft pointing redirects, if not, and visible changes are only applied to redirects pointing at draft space, then I would argue that there are only positive benefits. Would this change immediately apply a CSD tag to all existing (but unidentified) cross namespace redirects (potentially inundating that category with many pages creating a temporary backlog)? Even if that is the case, this would only be temporary, and would be preferable to leaving such redirects in place.
As it is, I am surprised that we do not have a bot that automatically tags such inappropriate cross namespace redirects. Perhaps this would be an alternative proposal, a bot that tags all such redirects with a new tag 'cross namespace redirect' which would highlight such articles and put them in a new category so that a user (I'll volunteer) can manually rummage through and tag those that are appropriate for db R2. Would you support this as an alternative? — InsertCleverPhraseHere (or here) 00:30, 4 September 2017 (UTC)[reply]
I've done two mass R2 taggings with AWB and a Quarry query. Don't remember how many each were, but someone who can see my deleted contribs could check. – Train2104 (t • c) 13:43, 4 September 2017 (UTC)[reply]
To editor InsertCleverPhraseHere: I see nothing wrong with a bot that would tag the redirects with {{R to draft namespace}}, which would sort them to ‹The template Cat is being considered for merging.› Category:Redirects to the draft namespace.  Paine Ellsworth  put'r there  01:31, 6 September 2017 (UTC)[reply]

Modification of WP:PROF

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)[reply]

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)[reply]
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).[reply]

Enhance Lint pages

Tracked in Phabricator
Task T162895

Lint Errors could be enhanced with a short description of each type of error. The nine sub-pages could be enhanced with a short description of their respective type of error. For example, Lint errors: Fostered content should define "Fostered content" with a link to a page where the topic is discussed. (I found that page before but I can't find it now.) Paragraph wrapping bug workaround and Tidy whitespace bug are similarly non-obvious even to experienced editors. Also, these pages seem to list approximately, but not exactly, in order of least-recently to most-recently edited. It would be useful to know the exact rule for how the pages are ordered. One reason this would be useful is, after editing a listed article, the editor may wish to revisit the lint error list page to make sure the error is truly gone. But if editing affects the page ordering, then the user needs to know how to find where the page would be listed after editing.

For that matter, it would be useful to know the rule for how search results in general are ordered. —Anomalocaris (talk) 02:36, 1 September 2017 (UTC)[reply]

There is a help page linked in the top right of each error type as well as the general special page. I agree, it is not very discoverable. I have also observed the order as "most-recently edited at the bottom". --Izno (talk) 12:17, 1 September 2017 (UTC)[reply]
Regarding order, it's probably in order of "last parsed", which explains why edited articles are lower (as they automatically cause a new parse if the content has changed). But rendering can occur for many reasons, so that explains why the order is not exactly like that. BTW. these are not search results, they are just a list in our databases. Search results are what is returned by Special:Search (these use a completely different storage system, which is optimized for textual and partial matching). —TheDJ (talk • contribs) 09:24, 5 September 2017 (UTC)[reply]

One can already see all errors in a page without ever going to the special page, e.g. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)?action=info#Lint_errors . Note that the header only shows up on pages with errors. Userscripts can also show them without reloading the page. 17:58, 2 September 2017 (UTC)

Thanks for discussing this. I think Subbu may be able to do something about T162895. But I also have a question about what else it is that we could be doing to solicit more involvement here :) I have posted info a number of times (in random order, this obviously doesn't include other venues such as the mailing lists, for example), and we really welcome more ideas about finding other interested people who we could support in fixing pages :) Elitre (WMF) (talk) 16:16, 7 September 2017 (UTC)[reply]
While signatures can contain lint errors, there's little chance in reducing the figures significantly. T140606 would need fixing to help with it. -- WOSlinker (talk) 20:23, 7 September 2017 (UTC)[reply]
I've been focusing on mainspace content and have filed a couple tasks that would help track the mainspace problems. Signatures being broken is not a significant issue IMO. If people use <font>...</font> and find that they aren't getting the effect they want, they'll ask for help fixing it, at which point the "lint for signatures" issue mostly becomes moot. --Izno (talk) 22:17, 7 September 2017 (UTC)[reply]
These messages can all be defined locally, for example in MediaWiki:linter-category-fostered-desc - someone just needs to propose the messages. Feel free to leave edit requests on the talk page of the mediawiki: page. — xaosflux Talk 03:24, 8 September 2017 (UTC)[reply]
… but, as always, please don't do local customisations unless there's a serious need for bespoke information, as it means all future updates are lost to the English Wikipedia unless someone notices and manually copies them across. Jdforrester (WMF) (talk) 15:45, 8 September 2017 (UTC)[reply]

But I also have a question about what else it is that we could be doing to solicit more involvement here :)

It is a problem of inefficient tooling. Tasks like this are a) hard to fix b) require an understanding of many technologies (html, css, wikitext, and maybe lua), and then they need to dig and investigate where these errors are coming from. In complicated cases, the lint only gives a hint of where it may come from, this could be a very deeply nested template. Psychology 101, means people only care about things that impact them directly. The pages currently look perfectly fine, and there is seemingly no need to do anything. The situation can be improved by either using the carrot or the stick.

The carrot:

  1. Show errors in preview (https://phabricator.wikimedia.org/T163072)- This should be triaged and prioritized, and is the carrot because it will help all wikitext editors because editors often introduce such errors unknowningly and then spend minutes searching for the cause.
  2. Expand highlighted segment and run the linter on it - (https://phabricator.wikimedia.org/T151362), (https://phabricator.wikimedia.org/T152824), or (https://phabricator.wikimedia.org/T163149) . The latter would be the most useful, and can be trivially done using a userscript.

The stick:

  • Add an popup whenever people introduce basic errors to pages and try to save (this already happens with the code-editor)
  • Forcibly activate the parser-migration extension for everyone or show it whenever there are migration errors in the page.
  • Abusefilter - block new edits (e.g. new editors) from adding such simple (e.g. unclosed tags) lint errors to the template or possibly even the article namespace

The point is that the situation will continue as long as the lint error reports are stuffed in some special page somewhere that only few people even know about and fewer even care. The workboard for editors is the editing tool, putting things elsewhere is a great way to tell them not to care about it. Here's a recent example of this problem (https://en.wikipedia.org/w/index.php?title=Template%3AWFTDA_Division_3&type=revision&diff=799743535&oldid=799729962). A user edited 1 page (template) and immediately brought about 100 high priority lint errors, it could easily have been a template used in thousands or millions of pages, and if someone reverts it they'll simply come back.

The current approach is quite simply insane ... 16:18, 9 September 2017 (UTC)

Changing the color of DELETION TEMPLATES from from red to light green/light blue

@Ritchie333: has a page User:Ritchie333/How newbies see templates.

It would reduce WP:BITE, if Prod, csd templates and "notifying page creator templates" don't have red color. Red is warning/danger sign. If these Twinkle "article deletion" messages are light green, it won't scare new editors. --Marvellous Spider-Man 05:34, 2 September 2017 (UTC)[reply]

Humm well it might scare them a little less. I'm ok with a change. Legacypac (talk) 05:53, 2 September 2017 (UTC)[reply]

I admit, green and blue seem a little incongruous on a "ATTENTION THIS PAGE MAY BE DELETED" template. Deletion is deletion, irregardless of whether the template is red, blue or green. Jo-Jo Eumerus (talk, contributions) 08:46, 2 September 2017 (UTC)[reply]
They will know that their article might be deleted. Red is a color of warning, which should be used only to warn vandals, or block templates. Creating article about non-notable actors, musicians, bands, politicians is not vandalism. They should not see red colored template on their article page and talk page. Marvellous Spider-Man 09:10, 2 September 2017 (UTC)[reply]
While I appreciate the intent here, red is the appropriate color for "THIS NEEDS URGENT ATTENTION". Alsee (talk) 17:52, 2 September 2017 (UTC)[reply]
Split the difference and use yellow or orange.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:01, 5 September 2017 (UTC)[reply]
Yellow seems right--or orange -- red is overused on WP. Are there any problems about accessibility? DGG ( talk ) 20:27, 6 September 2017 (UTC)[reply]
No more so than Red.
People with deuteranomaly and protanomaly are collectively known as red-green colour blind and they generally have difficulty distinguishing between reds, greens, browns and oranges. They also commonly confuse different types of blue and purple hues. People with reduced blue sensitivity have difficulty identifying differences between blue and yellow, violet and red and blue and green. To these people the world appears as generally red, pink, black, white, grey and turquoise.
So to color blind people it will look the same. (probably) Α Guy into Bοοks™ § (Message) -  09:15, 10 September 2017 (UTC)[reply]

Sorry Button

I say we need a sorry button like the thank button but if you make a mistake you can apologize!

@Dinah Kirkland: Please read WP:Bug reports and feature requests. עוד מישהו Od Mishehu 03:33, 3 September 2017 (UTC)[reply]
A user talk page post is much more meaningful and more apt to be taken as sincere.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:59, 5 September 2017 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=799870637"