Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 18:58, 13 August 2017

Table of contents
First discussion
End of page
New post

Shortcuts

New ideas and proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
Consider developing your proposal at Village pump (idea lab).
Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
Proposed policy changes belong at Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Automatic column mode for references element

Tracked in Phabricator
Task T173176

The discussion has run for a month and there is broad consensus to support the proposed changes.

There may be a small(??) percentage of articles that will be adversely affected due to various issues arising out of the change but the overall boons of the change heavily outweigh the marginal banes.And, nearly all the oppose reasons/rationales have been pretty well-defended by the supporters of the proposal.

N.B.:-(For all those who prefer single column referencing):--Even after the change, multi-column referencing can be turned off.Winged Blades^Godric 08:16, 12 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.

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:

Currently <references /> never has columns
When we switch the default, <references /> will have columns if there are more than 10 references (30em wide, same size as most Reflist usages).
This switch of the default will not influence {{Reflist}}, which can be used for changing column width and a few more advanced features.
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]
- The columns of the responsive column mode of the references tag, are the same as the most common setting for {{Reflist}}: 30em. The amount of columns depends on the width of your screen. —TheDJ (talk • contribs) 12:01, 17 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]
  - Still not clear on there being a need for this. Users of reflist have pretty much moved away from using the column to the width parameters anyway. Doesn't this have the same effect as your #2 above? What, if any, are the differences? GenQuest ^{"Talk to Me"} 13:36, 17 July 2017 (UTC)[reply]
    - This form of arguing can also be inverted. Why would you want to keep a difference between two existing methods for the same purposes, now that we have the ability to not have this difference ? Is there a need for columns to begin with ? Well probably not, yet people still like using them. Is there a need to change the default ? Well no one will die if we don't, but if it's already the most common form, then why not align the default with that form and make the exception the more laborious process ? —TheDJ (talk • contribs) 13:52, 17 July 2017 (UTC)[reply]
      - Still doesn't answer the question. Why do we not just deprecate <references> and use the more powerful {{reflist}} ? GenQuest ^{"Talk to Me"} 16:05, 23 July 2017 (UTC)[reply]
        Because {{reflist}} is, at heart, a wrapper for <references />. You can't deprecate the tag as it must be available for reflist to work. DES ^(talk)_{DESiegel Contribs} 19:29, 23 July 2017 (UTC)[reply]
        Thanks. GenQuest ^{"Talk to Me"} 18:38, 28 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]

What is your evidence for this assertion? See my brief inadequate survey (#twelve of 20). -- PBS (talk) 16:57, 12 August 2017 (UTC)[reply]

Support. There's no harm in doing so since automatically adding columns would actually reduce the amount of space that one has to scroll down. epicgenius (talk) 21:25, 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]

Support I ,like DESiege personally prefer single column, but I see from [[https://en.wikipedia.org/wiki/Template:Reflist[[ that there is an easy way to turn this off. DGG ( talk ) 15:10, 18 July 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]
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]
- Why do you think this isn't an RFC? Anomie ⚔ 12:57, 10 August 2017 (UTC)[reply]

This is not an RfC because it has not RfC banner at the top! -- PBS (talk) 16:57, 12 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]

Support. This should be the default behaviour; it can be over-ridden if needed so I see no issue with the rare articles that don't want this. Mike Christie (talk - contribs - library) 22:53, 10 August 2017 (UTC)[reply]
Support Seems like a sensible change that would improve article readability. AlasdairEdits (talk) 14:24, 11 August 2017 (UTC)[reply]
Support, currently we let article editors to decide on the number of columns, which means that articles have whatever looks best on particular peoples' screens. We can serve our readers better by adapting to everybody's screens. Max Semenik (talk) 20:22, 11 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.

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]
- I created some long text at User:Whatamidoing (WMF)/sandbox#Columns in those two sizes, and I'm not convinced that the wide columns is actually easier to read (on my screen, etc.). What do you think? Whatamidoing (WMF) (talk) 23:11, 12 August 2017 (UTC)[reply]

Allow users in the Account Creator user group to add users to the Confirmed user group

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia proposals

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Some time in the next month or so, the Wikimedia Foundation will be implementing WP:ACTRIAL at the request of the English Wikipedia community. (See the RfC.) During this trial, new (non-autoconfirmed) users will not be able to create new pages in the main (article) namespace. There is concern this could interfere with legitimate new article creation during edit-a-thons and similar events. In order to address this issue, I would like to propose that we modify the Account Creator user group (which is commonly assigned temporarily to people running edit-a-thons) so that users in this group can add other users to the Confirmed user group, thereby allowing vetted users to create new articles at these events. (Note that these articles will still be added to the reviewing queue at Special:NewPagesFeed.) The purpose of this change is basically to provide a work-around during ACTRIAL, so that disruption to these events can be minimized during the trial. As such, it can either be a temporary or permanent change, depending on what the community prefers. Kaldari (talk) 21:23, 4 August 2017 (UTC)[reply]

Support as a temporary change during WP:ACTRIAL. Most users who are added to the Account Creator user group are experienced event coordinators who are at least providing some basic guidance on how to create proper articles. Although I'm sure there will still be a fair percentage of low quality new articles from edit-a-thons, this will hopefully keep us from throwing the baby out with the bathwater. We should remember that ACTRIAL is about reducing the volume of spam and COI articles, not 100% eliminating all bad new articles. Overall, I think the contributions from edit-a-thons are a net positive for Wikipedia and we shouldn't cut those contributions off. Kaldari (talk) 21:23, 4 August 2017 (UTC)[reply]

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. Kudpung กุดผึ้ง (talk) 00:20, 5 August 2017 (UTC)[reply]

See the TV article on SABCnews. Kudpung กุดผึ้ง (talk) 03:05, 5 August 2017 (UTC)[reply]

Ha! Kaldari, you should know by now that "experienced" has a multitude of meanings. You are aware of the issues relating to the recent Dalit campaign, which involved edit-a-thons and was a disaster. This summary only brushes the surface and is replete with poor decision-making from admins and past/present WMF staff. I can assure you that I am not alone in my estimation that it was a complete mess. I wouldn't trust people like that to make exceptions to whatever the standard operating procedure/policy/guidelines might be. There is no deadline for creating articles but we have a limited number of regulars who actually know what they're talking about, and they're stretched as it is. - Sitush (talk) 00:37, 5 August 2017 (UTC)[reply]

Oppose/Needs improvement first as-is, way to many people are getting added to account-creator already that aren't even confirmed themselves! (See this list). I would normally support this, but not unless we put some actual requirements on being an account creator first. — xaosflux ^Talk 01:04, 5 August 2017 (UTC)[reply]

Xaosflux There are 338 names on that list, probably a lot more than are needed, a very large number of which whose edit count is only double figures. Recently buttons were added to the User Rights Manager to be able to accord rights for a limited period after which they would expire. This was particularly useful for Account Creator. However this feature seems to come and go for various user groups and is again not available for Account Creator. Curiouser and curiouser. Kudpung กุดผึ้ง (talk) 03:37, 5 August 2017 (UTC)[reply]

@Kudpung: the expiration should be always available to assign, if you see a case where it's not I'd be happy to check and get a bug open if it is not. Many, many of these were added for "events" and a specific administrator did the majority - I'm following up with them. — xaosflux ^Talk 12:34, 5 August 2017 (UTC)[reply]

It's a browser problem, Xaosflux. The buttons are not rendering in Firefox on Mac. Kudpung กุดผึ้ง (talk) 16:37, 6 August 2017 (UTC)[reply]

Re: needs improvement: To be clear, what I think needs fixing first is qualifications/expiration needs for the account creators themselves. — xaosflux ^Talk 20:04, 7 August 2017 (UTC)[reply]

Support as useful: as a Lead Trainer for WMUK, I've been running editathons and other training events for the last five or six years and have trained hundreds, perhaps thousands of new editors. As I stated at Wikipedia talk:Autoconfirmed article creation trial #Supporting edit-a-thons and similar events, it would be helpful – but by not means essential – to be able to grant autoconfirmed status to event participants on occasion. Most participants work in their sandboxes, and it is not so often that they want to create a new article, so ACTRIAL won't impact much on most of them. In those cases where an non-autoconfirmed editor has the ability to create a new article on the day, there are work-arounds available. Nevertheless granting autoconfirmed status to someone who is clearly capable of producing a new article that early in their editing career doesn't seem like much of a risk, so I can't see any problem with account-creators being able to do that. Either you trust account-creators to do these sorts of jobs, or you don't; if you don't, then I can understand you opposing the proposal here. --RexxS (talk) 12:12, 5 August 2017 (UTC)[reply]
I don't - but I think I could - if we vetted the account creators more (e.g. they had to be extended confirmed to use this). Guidance would be to add confirmed with say a short expiration date, if the people are editing they will end up getting autoconfirmed in a few days anyway. — xaosflux ^Talk 12:34, 5 August 2017 (UTC)[reply]
So the instructions at the editathon might be: "You've made 10 edits, so now all you have to do is sit around here for a few days and you'll able to move your new article into mainspace." It kinda misses the immediacy I usually hope for. :D --RexxS (talk) 15:10, 5 August 2017 (UTC)[reply]
No, assuming this gets supports, I'm saying that attendees would get +confirmed for say a month - if they never come back it just expires, else by the time it expires they would already be autoconfirmed. — xaosflux ^Talk 16:15, 5 August 2017 (UTC)[reply]
That sounds very reasonable. In practical terms then, what would be the difference between having the right expire after a month and not having the right expire after a month (assuming all participants at an editathon/training event will make at least 10 edits on the day)? --RexxS (talk) 16:24, 5 August 2017 (UTC)[reply]
Support per RexxS; and speaking as an equally-active trainer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 5 August 2017 (UTC)[reply]
Support as a temporary change during ACTRIAL: Some newbies go through the ACC process, but during edit-a-thons etc; will be a major disruption to events. KGirl ^{(Wanna chat?)} 18:49, 5 August 2017 (UTC)[reply]
Support per RexxS, but with the understanding that there will be clear guidelines for granting that would include among other things time limited granting, both of the confirmed status and of account creator status. Note, I don't think ACTRIAL will be a major disruption for editathons per feedback we've received at those discussions. This is, however, a nice plus to make it easier. TonyBallioni (talk) 18:55, 5 August 2017 (UTC)[reply]
Support on a temp basis Maybe we can see how this works in the future as well. ^{My name is}not^dave (talk/contribs) 08:19, 6 August 2017 (UTC)[reply]
~~Support~~ on a temp basis during the trial, for in person event coordinator use only, due to the time and logistical limitations of such events. Any other use of the ability (in the ACC process, etc) should be treated as misuse and grounds for removal of the bit. – Train2104 (t • c) 12:27, 6 August 2017 (UTC)[reply]

Oppose Per the comments below and some review of the list of users with this flag, I have some serious concerns about a relatively large number of users with little to no experience/knowledge of WP policies having this ability. If/when the eligibility requirements for accountcreator are stricter, we can revisit this. See also this apparent free-for all request page. – Train2104 (t • c) 16:48, 8 August 2017 (UTC)[reply]

Support during ACTRIAL per above for now. There is no need for having this on a permanent basis. I don't think it should be limited to event coordinators though. Regards So Why 16:44, 6 August 2017 (UTC)[reply]
Support - both as a temporary change during ACTRIAL and as a permanent change. It would be good to have this on a permanent basis because of the fact that it would help those at Edit-a-thons upload images for the articles they are creating. RileyBugz^会話_投稿記録 16:52, 6 August 2017 (UTC)[reply]
Support during ACTRIAL. Edit-a-thons often involve creating articles. —MRD2014 ^{Talk • Edits} 00:25, 7 August 2017 (UTC)[reply]
Support at least for now until we work out something better. This won't deal with all difficulties in training, but it will help. About 9/10 of the trainees usually do not come back after a month, so there ought to be some expiration date, or they might come back years later and still have the confirmed right (unless this proves to be too difficult to program, it which case we just think of it as a minor problem. However, it is essential that for relatively inexperienced group leaders granted account creator for a particular editahon, that both account creator and this userright expire . DGG ( talk ) 05:26, 7 August 2017 (UTC)[reply]
Support for the duration of ACTRIAL, and or if that experiment becomes permanent. Sadads (talk) 17:57, 7 August 2017 (UTC)[reply]
Support on an ongoing basis. Enabling edit-a-thons and other events with training and editing on the same way is good for the encyclopedia.--Carwil (talk) 20:34, 7 August 2017 (UTC)[reply]
Support Give the userright and let participants make wiki articles. I sympathize with Xaosflux's reasons for opposing but the reality is that at the current pace of conversation, the account creator userright will not be developed sufficiently within the next 3 years. Despite the potential for abuse, there is no public history of problems documented with this userright or with in-person Wikipedia editing events. I do not think that this userright is the origin of the tension, but rather, the tension is between the WMF and Wikimedia communities who are organizing large numbers of in-person wiki events while some of the Wikipedia community are unwilling and uninterested to acknowledge the existence of the events. If the events will happen, then the user right should be granted. If anyone opposes the events, then please take the argument to the WMF which sponsors them and has capacity to host discussions on how they should be managed. Blocking events with private discussions with the lower level, more vulnerable, and well meaning volunteer organizers who do not want to be swept into wiki politics is not the way to develop the Wikimedia community's event policy. Blue Rasberry (talk) 21:15, 7 August 2017 (UTC)[reply]
Support confirmed is not a very dangerous user right to have and the threshold for getting it normally is very low. I would support making this permanent. Hut 8.5 21:20, 7 August 2017 (UTC)[reply]
Support I think account creators are trustworthy enough to know who should and shouldn't be able to create pages during ACTRIAL, and this seems to be beneficial for letting them create pages without making a given # of minimum edits. Everymorning (talk) 22:12, 7 August 2017 (UTC)[reply]
Support This seems like an eminently reasonable proposal, and in cases of abuse it seems easy enough to reverse. Ancient Studies major (talk) 22:40, 7 August 2017 (UTC)[reply]
Oppose Let these new editors write drafts. I've been to a fair number of edit-a-thons and I don't think most account creators are doing enough to control what the attendees write. Show me that account creators are always being held responsible before I place any trust in their discretion. Chris Troutman (talk) 22:45, 7 August 2017 (UTC)[reply]
Support - Sure. Account creators are trusted individuals, and this addition makes sense for their work. -- Ajraddatz (talk) 23:07, 7 August 2017 (UTC)[reply]
Support per RexxS. Thanks. Mike Peel (talk) 23:20, 7 August 2017 (UTC)[reply]
Oppose until we prune the list of account creators. As of now, I count some 320 account creators, 221 of which have made fewer than 1000 edits (including 50 that have made <10 edits, and another 96 that have between 10 and 99 edits). T. Canens (talk) 23:30, 7 August 2017 (UTC)[reply]
Oppose per T. Canens. There are very few editors I'd trust with this tool. Callmemirela 🍁 ^talk 23:55, 7 August 2017 (UTC)[reply]
Support per Blue Rasberry. Double sharp (talk) 23:59, 7 August 2017 (UTC)[reply]
Oppose first per Chris Troutman (I wish all editathon organizers were RexxS but that is not what the incoming pages stream suggests) and then additionally for sake of ACTRIAL's data. I'd rather see what ACTRIAL does when "fully" implemented rather than muddy the data by allowing account creators with potentially widely varying standards to override the limit on new users sending pages straight to mainspace. Innisfree987 (talk) 00:30, 8 August 2017 (UTC)[reply]
Oppose. Let's be clear on a few things. There is nothing bad about editors creating drafts as part of edit-a-thons and submitting those drafts through AfC. In fact, that's the whole point of ACTRIAL; new editors submitting to AfC instead of mainspace. Second, keep in mind this opens the door of removals of account creator for cause. If this passes and I see an account creator grant the right to an editor who goes on to create inappropriate articles, that account creator will lose their user right. That's going to affect edit-a-thons more severely than submitting drafts to AfC. ~ Rob₁₃^Talk 01:12, 8 August 2017 (UTC)[reply]
- BU Rob13, from some of the comments here re: account creators, creating clear guidelines for revoking the tool seems like a positive to me, not a reason to oppose. Re: ACTRIAL, we received some pretty vocal feedback from users who cared about editathons and similar programs. We do have some very bad editathon creations, but we also have some very good ones that I think are probably a large part of the 20% of articles by non-AC users that don't get deleted. Your comment did remind me though that I think that if this is implemented, there should be an explicit guideline preventing its use as a part of the education program/WikiEd/school courses: those are the organized events that in my opinion have the most inappropriate creations directly in article space. TonyBallioni (talk) 03:04, 8 August 2017 (UTC)[reply]
  - @TonyBallioni: Here's the scenario I'm worrying about. Account creator grants the confirmed flag during an editathon, and the editor they grant it to creates an article that is immediately speedy deleted as a copyright violation. At this point, the account creator has bypassed ACTRIAL for an editor who doesn't know what they're doing, and the only recourse to prevent this from recurring is to yank the account creator right. Now the account creator is 30 minutes into their edit-a-thon without the ability to help editors create accounts and everyone's worse off. That's surely a concern. ~ Rob₁₃^Talk 12:30, 8 August 2017 (UTC)[reply]
    - Rob, thanks for the response. I still see having a fleshed out policy as to when to remove the account creator bit is needed, and think that this conversation has shown that. Your example is a good one, but by giving people clear guidelines, I think it would be rare. As an aside that is probably better for one of our talk pages, the issue of copyvios in new content is really something that we need to work on educating people at NPP/AfC about. So much gets through that isn't caught by EranBot. TonyBallioni (talk) 15:07, 8 August 2017 (UTC)[reply]
Oppose mainly for the reasons highlighted in my initial comment above, which Chris Troutman reflects in a more succinct manner.; also per BU Rob13 and Innisfree987. I think T.Canens; figures may be slightly skewed because there are some obvious low-count entries in the results list where it would seem experienced contributors have created "roaming"/"public place" accounts for use at edit-a-thons. Nonetheless, there are enough scary examples in there to make me wonder who has been granting these user rights. - Sitush (talk) 02:57, 8 August 2017 (UTC)[reply]
support seems like a good idea. this way, during editathons and such, they can edit semi-protected articles, and create new pages during the ACTRIAL. really, confirmed is not that much of an additional privilege. if there are problems, it can always be rescinded. -- Aunva6^{talk - contribs} 03:22, 8 August 2017 (UTC)[reply]
Oppose This sounds like a horrible idea in my opinion. Whispering 03:31, 8 August 2017 (UTC)[reply]
Oppose As a recent participant in a Wikipedia Meetup, almost all users were creating articles as drafts or in the sandbox anyway. There is no reason why edit-a-thon contributors cant just submit their drafts for review to AfC as intended, and no reason why these drafts cannot simply be added to a list and edit-a-thon helpers (like myself) can't review their AfC creations themselves, or else move the drafts to mainspace for them (after reviewing them). In the worst case, a draft has to go through a bit of a wait at AfC... what is the problem here? This is the whole point of ACTRIAL, and shouldn't be sidestepped during edit-a-thons or meetups. — Insert CleverPhrase Here 04:05, 8 August 2017 (UTC)[reply]
Oppose per Xaosflux Keira 1996 04:10, 8 August 2017 (UTC)[reply]
Oppose per Xaosflux, Kudpung, and Sitush. Vanamonde (talk) 04:40, 8 August 2017 (UTC)[reply]
Oppose: I fundamentally oppose to all measures increasing any rights of those organizing mass events. This is just WM-agenda, increasing their maneuverable volume, but decreasing WP-quality by under cover agenda pushing. See all further arguments above. Purgy (talk) 06:32, 8 August 2017 (UTC)[reply]
Oppose I see no real reason why new editors should be given the ability to easily make pages, they should go through the proper autoconfirm process. or they should create an account before the event like a sensible person would, to learn about Wikipedia, rather than jumping into the deep end of Wikipedia's most difficult task. making bulk new pages does not really help Wikipedia much anymore, since it just 'bungs up' the new page patrol system. A Guy into Books (talk) 07:23, 8 August 2017 (UTC)[reply]
Oppose. The most appropriate, manageable, and helpful route to creating new articles during an edit-a-thon is via the draft process. The participants are then being taught the method which they will need to know when the edit-a-thon is over, and there is an encouragement and incentive for participants to get the article right in order for it to go live. It also encourages the attitude that while anyone can edit Wikipedia, what we're after these days is quality contributions. I would rather an edit-a-thon resulted in just one good quality contributor remaining active than have 100 well meaning but less than competent contributors remaining active adding inappropriate unsourced material which then has to be dealt with. SilkTork ^{✔Tea time} 08:03, 8 August 2017 (UTC)[reply]
Support This should be granted on a long-term basis as it's a hassle if this keeps lapsing. For example, I currently have the account creator right. On Aug 17, I'll be attending an event at the Royal Society of Chemistry. So far as I know, the main organisers are not admins and neither am I. Because it will be on a weekday, participation by volunteers may be limited and so this seems a good example of an event that might be disrupted by over-zealous throttles on account and article creation. The institution and organisers are of impeccable quality and so it's us that will look bad if we can't handle the smooth onboarding of novices at such an event. As another example, I was recently discussing setting up an event at the Wiener Library. At the last event there, the main organiser was actually blocked by an admin, which caused considerable bad feeling. Such hostility is contrary to policy and is foolish. I was myself checking out Everipedia this morning. I don't know much about it yet but get the impression that it has some momentum because it is more open and welcoming. Wikipedia is not the only game in town. As a further example, I just got an edit conflict posting this. This place really tries one's patience... Andrew D. (talk) 08:06, 8 August 2017 (UTC)[reply]

"Impeccable quality" as scientists, sure. But in terms of Wikipedia knowledge? - Sitush (talk) 08:17, 8 August 2017 (UTC)[reply]

The main organisers I'm thinking of are Dr Jess Wade and Dr Alice White. They are bright, energetic and personable. And they are fun to work with – that's why I'm going to take a day's leave to support this event. They exemplify "good faith" and so we should strive to facilitate their work rather than putting obstacles in their way. Andrew D. (talk) 09:44, 8 August 2017 (UTC)[reply]

Encouraging users to use the appropriate process should not be viewed as an obstacle. No one here is suggesting putting obstacles in anyone's way; rather, that the due process we have been developing to protect Wikipedia and to enable and encourage positive participation should not be specially put aside. All new articles are over-viewed by the community, be they articles created in someone's home, place of work, university library or an edit-a-thon. The users at the edit-a-thon are no different to any other user - their work will be seen by our new page patrollers and dealt with. If inappropriate articles are rejected by the patrollers this will have a dispiriting effect on the edit-a-thon editors. I'd rather they were shown the right way of editing Wikipedia, so they don't have the experience of their work being speedy deleted, but have it go through AFC where if it gets rejected reasons are given, and the work is still available for the user to work on. Not an obstacle, but an assistance. SilkTork ^{✔Tea time} 11:43, 8 August 2017 (UTC)[reply]
That sounds like you are suggesting that some people are more equal than others, more deserving of special treatment that is not available to other new contributors. As I said way, way above, it is evident that course organisers etc cannot or do not always vet what goes on and so such special treatment both undermines the trial and doesn't fix the longer-term problem. I realise different edit-a-thons attract different people but the ones I've come across have had pretty universally poor outcomes that have entailed a massive amount of clean up for BLP violations, copyright issues, sourcing and, well, pretty much everything. Being keen is good; being au fait with how Wikipedia works takes time. Edit-a-thons tend to rush through a lot in a short span. Tbh, I'd be quite happy if they didn't exist. - Sitush (talk) 12:03, 8 August 2017 (UTC)[reply]

All users are not equal – that's the point of this discussion as we're talking about permissions and privileges. Confirmed status seems designed mainly as a pure obstacle. The main issue is the four-day wait and that has no functional purpose as nothing much happens during that time; it's just a cooling-off period to discourage people. One consequence of not having confirmed status is that you have to supply CAPTCHAs when adding references. Adding citations is painfully difficult for experienced users; that's why so little of it gets done. When you have to do CAPTCHAs too then it becomes really annoying because they are not easy; I have trouble with them myself. Again, this is another obstacle especially designed to make it difficult for new users rather than encouraging them. Experienced users and admins tend not to appreciate how obnoxious Wikipedia is for a new user because, thanks to their privileged status, they don't have to deal with these obstacles. But all our current experienced users will not exist in due course because we don't live forever. Who will edit Wikipedia in the future if we make it increasingly difficult to get in? Andrew D. (talk) 17:50, 8 August 2017 (UTC)[reply]

All new user are equal. They have no privileged rights unless someone grants them. I don't trust the edit-a-thon environment (plenty of empirical evidence) nor, indeed, quite a few of the account creators to grant rights appropriately and I don't see why a new user should so arbitrarily be able to leapfrog a system that by far the majority of new users have to go through. I'm well aware of the issues of not being autoconfirmed because I've edited occasionally when logged out (one or two edits, in subject areas I never visited before or since). Not having the arbitrary account creatoin process does not make it more difficult to "get in" than it already is. - Sitush (talk) 18:49, 8 August 2017 (UTC)[reply]

Empirical evidence? I have attended over 10 events so far this year. They were all of high quality and were typically in partnership with world-class academic and GLAM institutions. They were typically focussed on a new event or on filling in red links, such as missing women. Article creation is a fundamental aspect of such events and it's something that our partners like and can get funding for, because it's productive – an outcome that they can measure and boast about. If you invite people to a one-day event with such a focus it is then ridiculous to tell them that they have to wait four days. That's what ACTRIAL would mean; it would make us look like jobsworths rather than the encyclopedia that anyone can edit. Andrew D. (talk) 06:48, 10 August 2017 (UTC)[reply]

I've given you some empirical evidence, Andrew and I've already explained that being an expert in an academic field has no bearing on abilities as a newcomer to Wikipedia. This isn't really about biting the edit-a-thon newcomers, who would be treated just like any other newcomer, but rather the people who grant the rights. Too many, including admins and WMF staffers, demonstrated cluelessness in this area and are so set on their pet "social justice" projects, grant income etc that they can't see the wood for the trees. Sue Gardner's much maligned Indian Education Program was another example. That said, even a select group of newcomers - whom you for some reason think automatically know what they're doing here - would be less likely to be bitten if they went through the usual processes of AfC etc. - Sitush (talk) 07:20, 10 August 2017 (UTC) (Sorry, my "biting" bit makes little sense because you edited your comment while I was writing mine. - Sitush (talk) 08:18, 10 August 2017 (UTC))[reply]

Oppose As per SilkTork, while we want to encourage the view that anyone can edit Wikipedia, we also want to encourage the view that creating quality material requires learning about policies and processes, particularly the need for reliable sourcing. Peter coxhead (talk) 08:47, 8 August 2017 (UTC)[reply]
Oppose, per Xasoflux. Joefromrandb (talk) 08:51, 8 August 2017 (UTC)[reply]
Support while I haven't been involved in many editathons since I left WMUK, I have been involved in quite a few in the past. This userright would be useful in running such events, and it is a reasonable mitigation of ACTRIAL. I have seen attendees at such events not get the importance of having some reliable sources before they hit save, but most attendees create articles that meet our notability threshold, and I've never encountered a commercial spammer or a vandal at an editathon. More to the point, such articles created at editathons are almost always more encyclopaedic than the aspiring not yet professional model, musician or sportsperson who NPP is deluged with. Ϣere SpielChequers 10:01, 8 August 2017 (UTC)[reply]

Oppose, I agree with Xasoflux and Kudpung, and, this imho is where draft process is for.ronaz^Talk! 10:18, 8 August 2017 (UTC)[reply]
Oppose Until there some kind of vetting policy for Account Creator, I can't see giving that user group that kind of power. Sario528 (talk) 11:59, 8 August 2017 (UTC)[reply]

Oppose Edit-a-thons & other wiki-events will be far more productive if they aim to develop new wikipedians who understand why wikipedia is the way it is and happen to have a specialist knowledge rather than incubating COI editors who will abandon the wiki as soon as the event is over and they encounter the real requirements of the wiki. The problem as outlined is more about how the event is conducted rather than about how ACTRIAL and Wikipedia operate.

Encouraging new editors by promoting their articles from userspace/draft rather than setting them up for a bruising review experience the next day will be more likely to encourage them to stay - and that is the purpose of these events, isn't it?

The objectives of the proposal would be better met by:

A template on the draft/article stating that it was produced as part of event, identifying the event's coordinator, categorising the article/draft into a maintenance category for the event, and requesting that during the event (start date & time, end date & time) it would be appreciated if all review action were focussed on helping the author grow as a wikipedian rather than cleanup.
An editnotice onthe draft/article to the same effect, with an expiry set for the event's end.
Getting Twinkle & Huggle to observe the event's template & refuse to add deletion tags during the event. Cabayi (talk) 11:57, 8 August 2017 (UTC)[reply]

Oppose - for the reasons stated by Chris Troutman, and BU Rob13. The draft process has a greater control aspect as to the quality of the work proposed. Kierzek (talk) 13:34, 8 August 2017 (UTC)[reply]
Oppose, users participating in edit-a-thons should experience the same Wikipedia processes as everyone else. (If my brother goes to an edit-a-thon and then tells me how he created an article, and I then I make an account but can't create an article, I will give up on Wikipedia right away). Also, edit-a-thons and other newbie-sirected activities should probably try to focus on editing existing articles. —Kusma (t·c) 13:38, 8 August 2017 (UTC)[reply]
Oppose per those in favor of using the draft space. Bending the rules for new users may have the opposite effect of what the edit-a-thons are trying to accomplish. May as well use the processes your typical new user has to use and adequately prepare them for what Wikipedia is really like. ZettaComposer (talk) 14:05, 8 August 2017 (UTC)[reply]
Oppose Primarily the reason being not all account creators are properly vetted. I do not feel autoconfirmed is a high bar and recommend reaching this bar stay in situ. While necessarily removing a hindrance, this also can be wrongfully abused, accidentally or not. --QEDK (愛) 15:24, 8 August 2017 (UTC)[reply]
Support as temporary change during WP:ACTRIAL. Unless a large portion of the members of the account creator group suddenly decides to join the dark side en masse, I can't see how this can blow up in any meaningful way during a short trial period. I would however suggest combining this with somewhat greater circumspection in handing out the right (500/30 seems like a reasonable bar). --Elmidae (talk · contribs) 15:32, 8 August 2017 (UTC)[reply]
- @Elmidae: That isn't possible, because we have people who aren't familiar with Wikipedia running edit-a-thons from an administrative perspective all the time. Do we bar such edit-a-thons from occurring? Moreover, the concern isn't "those evil account creators". I don't doubt our account creators act in good-faith. The concern is that they hand out the "confirmed" right to everyone participating in the edit-a-thon, and the edit-a-thon participants create articles not suited for mainspace. That happens all the time in connection with edit-a-thons. ~ Rob₁₃^Talk 15:54, 8 August 2017 (UTC)[reply]
  - @BU Rob13: My thinking is that any edit-a-thon participants of events held during the envisioned ACTRIAL period are unlikely to make much of a blip on the radar, compared to the usual flood of unsuitable creations. a) There wouldn't be all that many of them (don't have any stats - a couple of thousand people? I may be way off); b) as someone noted above, they are well-intentioned and at least somewhat supervised. So, I doubt much potential damage in total, compared to business as usual. Thus an evaluation of the effectiveness of ACTRIAL should still be very possible - and isn't that the main goal?

Regarding experience thresholds of edit-a-thon organizers - I was under the impression these would be somewhat seasoned users. If that's not generally the case, a high threshold for account creation rights wouldn't be sensible, of course. --Elmidae (talk · contribs) 19:04, 8 August 2017 (UTC)[reply]

The granting guidelines for ACC seem to be rather permissive at present, perhaps better to instruct coordinators on the process to request confirmed and try to have an administrator or two to keep an eye on the permission page during the event if the participants are expected to require 'confirmed'. –xeno^talk 17:12, 8 August 2017 (UTC)[reply]
Oppose- it is what, four days and 10 edits? If someone is going to come onto WP, I think 4 days is a logical minimum to understand the ropes of article quality. Further, the 10 edits shouldn't even be an issue, as if the user is creating the article in the sandbox or similar space, they should make at least 10 edits in creating the article there. I don't think edit a thons deserve special treatment (though I'm not wholly familiar with what they are). And being a part of an edit a thon doesn't make someone more trustworthy. Summary - 4 days and 10 edits do not create undue hardship for anyone, and giving power to lift it arbitrarily because someone is part of some organization does not seem rational. Even if we trust the admin more than anything, how can they have any idea if the individual is trustworthy? Leave it be ‡ Єl Cid, Єl Caɱ̩peador ^ᐐT₳LKᐬ 19:23, 8 August 2017 (UTC)[reply]
Support as a temporary change per those above. JTP ^{(talk • contribs)} 21:16, 8 August 2017 (UTC)[reply]
Support If one of the goals of editathons is to bring in new editors and get them to write articles, making them potentially wait weeks to get their articles reviewed (and possibly shot down by a reviewer with really high standards anyway) is going to be really unsatisfying. The discussions on ACTRIAL happened before article-creation editathons were as frequent as they are now (in particular, WikiProject Women in Red didn't exist back then), and we need a measure like this to account for that change. TheCatalyst31 ^{Reaction•Creation} 23:50, 8 August 2017 (UTC)[reply]

I literally just participated in a women in red editathon meetup and I have to say that there is no need for this. Everyone was working in the draft space anyway, it it was much better to review the articles myself before submitting them to namespace than to let the new users do it themselves (a result of some users working in the mainspace resulted in some articles getting prodded, and another article getting onto mainspace with copyright violations. These problems would have been avoided if these users needed help promoting their articles as the issues would have been flagged when doing so. — Insert CleverPhrase Here 00:02, 9 August 2017 (UTC)[reply]

Support during ACTRIAL. --joe decker ^talk 01:29, 9 August 2017 (UTC)[reply]
Comment I'd be far, far, more amenable to arguments that "let 'em use drafts" if we had a Draft review process that wasn't badly backlogged. --joe decker ^talk 03:35, 11 August 2017 (UTC)[reply]
Neutral. Assigning any user right should be left in the hands of administrators. But, then again, aren't account creators supposed to have their identities confirmed by the foundation? With that being said, I'm torn on where I stand, given that the requirement to have account creators' identities confirmed by the foundation adds accountability. Steel1943 (talk) —Preceding undated comment added 01:40, 9 August 2017 (UTC)[reply]
Account creators who work in the request an account process are identified, but the user right is more commonly handed out to event organizers, who need not be identified. Many of these organizers are new users who have not even reached extendedconfirmed yet. – Train2104 (t • c) 03:51, 9 August 2017 (UTC)[reply]
I now oppose this proposal now that I know there is a group besides Administrators that can have the account creation permission other than Account Creators. Steel1943 (talk) 18:49, 9 August 2017 (UTC)[reply]
Question - Would implementing this proposal allow account creators to add existing accounts to the confirmed user group, or only allow for assigning this right during the creation of an account? I am inclined to support the latter but quite reserved on the former. Thank you.--John Cline (talk) 02:25, 9 August 2017 (UTC)[reply]

As far as I can tell, it would be the former, just like an admin can assign permissions to any user. – Train2104 (t • c) 03:58, 9 August 2017 (UTC)[reply]

Comment - It seems to me that supporting this as a temporary measure to mitigate the effects of ACTRIAL is tantamount with supporting a measure to reduce the value of the statistical data being assessed, and the trail itself. Am I wrong?--John Cline (talk) 05:48, 9 August 2017 (UTC)[reply]
Comment I've been assuming that that the effects of this on the trial results would be insignificant, that new articles from these events do not make up anything like a signficant fraction of incoming articles from new editors. Am I mistaken? --joe decker ^talk 15:00, 9 August 2017 (UTC)[reply]

Same here. Any numbers available on that? --Elmidae (talk · contribs) 16:54, 9 August 2017 (UTC)[reply]

Oppose. With Wikipedia's increasing maturity, the bar for article creation needs to be higher to maintain quality. Editathons seem too often to be a source of low quality article by newbies whose convenors are unwilling to criticize. Xxanthippe (talk) 06:06, 9 August 2017 (UTC).[reply]
Oppose Creating them in Draft adds extra work at the beginning for experienced users to review them but I feel that it will also allow to better guide new users and improve the quality of articles in main space. --Crystallizedcarbon (talk) 15:37, 9 August 2017 (UTC)[reply]
Oppose per Kudpung, xaosflux, Sitush, and many others above who have observed quite serious problems with the provision of the account creator userright and suitability for mainspace of articles created at these events. Draft space is the way to go for these events. Ivanvector (^Talk/_Edits) 16:45, 9 August 2017 (UTC)[reply]
Oppose. New editors should be encouraged to create drafts, and that's what editing event organizers should have them do anyway. I had people do that at an editing event I worked on and there were no issues with it at all, and a much reduced risk of having to field the question "Why does someone say my article should be deleted?". (Never happened.) Creating an article that's immediately mainspace ready is not something we should encourage new users to try, it's just likely to cause frustration on all sides. Seraphimblade ^{Talk to me} 17:10, 9 August 2017 (UTC)[reply]
Oppose Per BU Rob13. This just doesn't make sense. Let me get this straight, the community decided to increase the prerequisite for article creation from "nothing" to "4 days and 10 edits" (addendum, per Kaldari: for a trial run). But the WMF blocked this, and more than 6 years later they're just getting around to testing it? But they want to add the caveat where Account Creators, of all people, can exempt anyone as they see fit? What's even the point then, honestly? It seems like WMF is just trying to add a major loophole to something that they apparently disagree with enough to block a community decision for 6 years. As one of the admins involved at Requests for Permissions, I'll share something that not everyone may realize: Account Creator has fairly high requirements usually, including identification to the foundation, but it's also granted to basically anyone who says they need it for an event. These users may well just barely be autoconfirmed themselves. They're not some well-vetted, highly trusted class. They're literally random people, many of them inexperienced, who claimed they were running an event, and were permanently granted this flag (the ability to grant it temporarily finally exists, but it was only recently implemented). The task of revoking the flag from these users was reinforced by a community consensus, but it has yet be undertaken by admins, due it being a large, tedious and relatively unimportant task in an area where not many admins are involved. Anyway, if you're going to give Account Creators the ability to confirm accounts, you may as well give it to everyone. I just can't see the logic of delegating an administrative responsibility to a ragtag group of users who were rubber stamped. Swarm ♠ 18:09, 9 August 2017 (UTC)[reply]
- @Swarm: I don't think the WMF is seeking this change; it's community members who for some reason think edit-a-thon participants going through AfC would be harmful (how? no clue). The WMF, if anything, would likely oppose this change because it would pollute the statistical results of the trial. ~ Rob₁₃^Talk 18:17, 9 August 2017 (UTC)[reply]
  - Rob, my impression is that the WMF has as one of its goals increasing new editors. I don't think @Kaldari and DannyH (WMF): and the Community Tech team have strong opinions either way on this. I believe Sadads who works in another WMF department was one of the first to bring this up as an issue. JMatazzoni (WMF) also probably has thoughts on this as his team more directly deals with editor retention, but I don't know what his thoughts are on it in terms of affecting the trial. The short: my impression is that different parts of the WMF are viewing ACTRIAL in different ways. There is definitely some support for something like this there, but there are likely others who oppose it for the reasons you pointed out. TonyBallioni (talk) 18:24, 9 August 2017 (UTC)[reply]
  - I see what you're saying about WMF not wanting to dilute the data, and that's certainly what you would think they would want. However, after the six-year delay in implementing this, a WMF employee's request for a major exemption for all outreach initiatives certainly does not give the appearance that they are actually supportive of this idea. I'm not saying Kaldari is disingenuously pursuing some sort of hidden agenda, and I think Tony's comment makes sense. I'm just pointing out that the ACTRIAL is such a modest change, and combined with the ridiculousness of this proposal (see my comments on ACCers above), which would gut it, the whole thing seems disingenuous. Swarm ♠ 18:57, 9 August 2017 (UTC)[reply]
    - @Swarm: With all due respect, much of what you said above is wrong. First, the community didn't decide to increase the prerequisite for article creation, they decided to request a trial of such a limitation. The WMF is now running that trial. The WMF doesn't want to add a caveat; the community expressed support for a very similar idea at Wikipedia talk:Autoconfirmed article creation trial#Supporting edit-a-thons and similar events. No one at the WMF has any strong opinions on this proposal (that I know of). If you don't want to AGF, that's fine, but I promise there's no conspiracy here. Kaldari (talk) 19:15, 9 August 2017 (UTC)[reply]
      - Again, I was not assuming bad faith, nor alleging some sort of conspiracy, and I expressly clarified that in my previous comment. Thank you, but I don't actually need assurances from WMF staff that there are no nefarious motives at play. I'm sure we can both agree that such a notion is a bit ridiculous. And I'll point out that that aspect of my comment was not even my reason for objecting. It was just an observation on how ridiculous this proposal looks, in the context of my perspective on Account Creators and my perceived significant ramifications for the ACTRIAL. Swarm ♠ 20:03, 9 August 2017 (UTC)[reply]

The Community Tech team is helping to support ACTRIAL as a research experiment, because it'll give us better information about how all these processes work. It's possible that restricting page creation to autoconfirmed users will drive new people away to an unacceptable extent, and we'll lose good editors and good content. But creating a new page and having it deleted within a couple hours is a terrible experience for new users, so it's possible that if we redirect them to the Article Wizard and Drafts, then they'll be more likely to stick around and learn how to edit. Opinions on both sides are pretty entrenched, and running this trial will help us all have informed discussions about it. So that's why Community Tech is working on this -- you can see the hypotheses and measures that we're working on at Research:ACTRIAL on Meta.

Running this trial has an impact on other people's work, so we want to minimize that if we can. People at the WMF who work with program leaders, like Sadads, want to make sure that people can run events successfully during the trial. We haven't actually looked at the experiment-pollution angle; we should see if we could get an estimate of the number of main namespace articles created in editathons, to see if it would make a difference to the statistical significance.

But this is a community decision; that's why Kaldari proposed this here. Running ACTRIAL isn't dependent on this decision; we've committed to running the experiment. -- DannyH (WMF) (talk) 19:18, 9 August 2017 (UTC)[reply]

Those are the events that bring in a bunch of (often conflicted) new contributors who are enabled by people who often don't have much experience themselves (honourable exceptions) or who share similar conflicts and want to steamroller over policy etc in order to get their way (per the link to my talk page right near the top). "More editors" seems to be the overarching mantra and it should not be. - Sitush (talk) 19:29, 9 August 2017 (UTC)[reply]

DannyH (WMF), how much research has been done into what type of editing productive long term users do when they first become active on Wikipedia, compared with the type of editing done by short term or single purpose editors whose work is largely unhelpful? Anecdotally, my impression is that the sort of editors on this page commentating on this (representative of the productive heart and core of Wikipedia), would not have started on Wikipedia by attempting to create a new article. While those editors who have started off by creating a new article, have tended to be those who have a vested interest in the subject they are introducing onto Wikipedia (and no real interest in editing on any other subject), and either disappear soon after they have created the article, or simply hang around to feed that article and none other. My anecdotal experience might well be shared by others on this page. We have spent a disproportionate amount of our time over the years, attempting to clean up messes created by users who are not interested in Wikipedia itself, but only in their particular subject appearing on Wikipedia. If WMF wishes to encourage new users, perhaps conduct research into what attracts productive users compared to what attracts disruptive or unhelpful users, and then work on attracting productive users while discouraging unproductive users. It seems to me, again purely anecdotally, that directing new users to go through an approved article creation procedure is likely to attract, develop and retain the sort of editor we want, while discouraging the sort of editor we don't want. SilkTork ^{✔Tea time} 08:53, 11 August 2017 (UTC)[reply]

I'm not sure that I can agree with the implicit idea that only long-term users are desirable. However, you may be interested in a quick check that I did: The first (undeleted) edit for three of the current 22 bureaucrats was creating an article in the mainspace. Adding internal or external links (including adding a line to WP:Build the web to the linked article) was the most common first edit, and a couple fixed typos or similar small errors. Only two made major changes to an article. Two created their user pages, one moved a page (back then, you didn't have to be autoconfirmed to do that), one warned a spammer, one voted in a discussion, one expressed an opinion about a merge proposal on a talk page, and the other inserted an image to an article. So if you assume that bureaucrats are "productive, long-term users", then the answer seems to be: they did almost everything for their first edit.

There has been some research into the effect of sandboxes and draft space. Someone involved in that project will have more information, but the TLDR seems to be "Draftspace is where articles (and their creators) go do die". WhatamIdoing (talk) 22:11, 11 August 2017 (UTC)[reply]

Oppose, Whether via Edit-a-thons or not, articles created by non-autoconfirmed editors should go through AfC, or draft-to-AfC. Softlavender (talk) 22:29, 9 August 2017 (UTC)[reply]
Support Trim the list by all means, but this will help the trial not be skewed.L3X1 (distænt write) )evidence( 22:58, 9 August 2017 (UTC)[reply]
Oppose - in my opinion, Edit-a-thons ought to focus on editing instead of article creation, especially if the editors are so inexperienced that they are not even autoconfirmed. And I think the ability to add a user right necessitates the ability to remove that user right, which this proposal does not address.--John Cline (talk) 23:40, 9 August 2017 (UTC)[reply]
Support for a number of reasons - if the purpose of opposing is to force new people into AFC/Draft process thats is nothing but a power trip to many of the reviewers with expectations of content being GA/FP ready. I always encourage new editors to ignore that process, just we did when we started editing its a learning curve becuase its almost certain negative experience. The big issues at editathons isnt so much the creation of new articles but rather that every edit the user gets a captcha thats really unproductive especially as new editors in a workshop are being supervised anyway. There is already a limit on the number of accounts an IP can create so generally need an account creator or an admin, having run workshops for most of the last 10 years as an admin I actually prefer to edit user rights as auto confirmed so that I can capture the new editors usernames and monitor post event whether they return, what issues they run into, review their edits, and generally keep in contact. Gnan garra 00:24, 10 August 2017 (UTC)[reply]

The captcha argument is the most convincing argument I've seen here (as it really is very disruptive to new users at meetups). AfC also does sometimes require far too much of new articles. However, the arguments that this change would undermine ACTRIAL, as well as the fact that there are so many users that currently have account creator rights that clearly shouldn't have the ability to do what is proposed here are stopping me from changing my !vote. — InsertCleverPhraseHere ^{(or here)} 18:40, 10 August 2017 (UTC)[reply]

Oppose On the theory that the current system works reasonably well. If an editor feels that the confirmed right is needed, it can be requested through an admin at WP:PERM. Dolotta (talk) 00:33, 10 August 2017 (UTC)[reply]
Oppose during ACTRIAL, Support a trial run afterwards if we decide to go forward with ACTRIAL changes. One experiment at a time, please. Daß Wölf 01:29, 10 August 2017 (UTC)[reply]
Oppose as proposed. Kudpung has presented a number of reasons. In brief, too much chance of trouble that will be hard and/or long to undo. Let them create in draftspace. — No stance on experimenting in a more controlled and limited way. --Thnidu (talk) 04:56, 10 August 2017 (UTC)[reply]
Oppose Per Timotheus Canens and Xaosflux. Way too many users with the ACC flag, in my opinion, that list needs to be pruned by about 300 users and a vetting process for the flag needs to be hammered out. - FlightTime (open channel) 07:10, 10 August 2017 (UTC)[reply]
Oppose I'm generally uncomfortable with tool unbundling, but this is just a bad idea. As many people above me have stated, giving relatively new editors (and yes, we do hand out Account Creator to almost new accounts who are perhaps running an editathon) the ability to not only bypass ACTRIAL themselves, but to allow the rest of their group to do it too. I also fail to see how articles created at these events are automatically legitimate new article[s] - does being at an editathon just magically make you an experienced editor? There's the implied understanding that perhaps these participants have been given training, but that's entirely down to the organisers. -- There'sNoTime ^{(to explain)} 07:35, 10 August 2017 (UTC)[reply]
Oppose per Xaosflux, Kudpung, Sitush, SilkTork and others. Callanecc (talk • contribs • logs) 08:46, 10 August 2017 (UTC)[reply]
Oppose per Swarm and several others. I can add that I took a quick look at the 50 or so first names on the list of users with the "account creator" right, and found a whole bunch of users who aren't even autoconfirmed themselves (several of them have only two or three edits of their own...), but would still be given the right to autoconfirm other users if this proposal passes... - Tom | Thomas.W ^talk 17:22, 10 August 2017 (UTC)[reply]
- Worth mentioning that they could autoconfirm themselves and any socks they wanted to create (should they not actually be running an editathon shock horror) -- There'sNoTime ^{(to explain)} 17:37, 10 August 2017 (UTC)[reply]
Oppose As per SilkTork and many others. We must continue to encourage the fact that anyone can edit Wikipedia, but we must be cognizant that not everyone can simply jump in without learning policies and processes. High quality standards have taken years of collaborative effort to create and changing this will undermine a lot of that effort. Spacini (talk) 18:13, 10 August 2017 (UTC)[reply]
Oppose per Kudpung amongst others. (((The Quixotic Potato))) (talk) 19:29, 10 August 2017 (UTC)[reply]
Oppose I'm not so enthusiastic about the qualities of newly created articles by non-confirmed users. — JudeccaXIII (talk) 19:50, 10 August 2017 (UTC)[reply]
Oppose per @Train2104: way up above. If anything, this flag needs to be tightened, not loosened in any way. GenQuest ^{"Talk to Me"} 21:41, 10 August 2017 (UTC)[reply]
Oppose - My reasoning is the same as many of the other editors on this page. All Wikipedians should go through the same processes when joining the website, regardless of the circumstance. The drafting process, in addition to vetting some of the more incomprehensible work that's produced, can serve as an important teaching moment for newer users. Those who are committed to collaborating on Wikipedia will hopefully have the patience to learn from that experience. The only real problem I see here is that new editors unable to directly publish their work might feel discouraged (like they aren't truly editing the encyclopedia "anyone can edit") from the onset and never bother sticking around. But if an editor is committed and goes through with the processes they will almost certainly come out of it more competent than their peers. So I say its worth it if we break a few eggs if that keeps the one-time contributors with their "drive-by" articles under proper supervision. Lastly, I think that this proposal would undermine ACTRIAL and its effects, which would by extension undermine the research that's to be conducted. -Indy beetle (talk) 06:54, 11 August 2017 (UTC)[reply]
Oppose. My early thought on this were to support, but I declined to comment for a few days until some of the arguments for and against had been brought up. Now that I read them I'm swayed the other way. Optimist on the run (talk) 09:54, 11 August 2017 (UTC)[reply]
Oppose - As per Swarm, I do not think it is a good idea. Adityavagarwal (talk) 12:52, 11 August 2017 (UTC)[reply]
Oppose - As per SilkTork, in addition I feel that this proposal would undermine the research that is being conducted with regards to ACTRIAL --Imminent77 (talk) 13:45, 11 August 2017 (UTC)[reply]
Oppose - Per many others, allowing many new editors to obtain confirmed status is a dangerous prospect. Edithons are a good thing, but they also overload editors like myself that cruise the new page feed. Diverting traffic through our existing system of drafts is the best way to do things. SamHolt6 (talk) 16:54, 11 August 2017 (UTC)[reply]
Oppose - encouraging new editors to jump into creation causes more problems than it solves. I am a case in point. Let them cut their teeth on the million plus articles that have problems, so they don't create more. Rhadow (talk) 19:44, 11 August 2017 (UTC)[reply]
Oppose per many editors here (too many to name) - If newbies want to create articles we have drafts which is more than sufficient - I see no valid reason as to why we should allow account creators to go on a mass-adding spree especially when most (judging by the link by Xaosflux) shouldn't even be account creators anyway!. –Davey2010^Talk 21:43, 11 August 2017 (UTC)[reply]
Oppose: it would be a big security risk, especially as many of the account creators are inactive. Esquivalience (talk) 22:34, 12 August 2017 (UTC)[reply]
Support as a temporary change during ACTRIAL: This will be a major help during edit-a-thons, which are already guided environments. Sayan rc (talk) 13:57, 13 August 2017 (UTC)[reply]

@Sayan rc: The right to auto-confirm other users, and even themselves and whatever socks they might create, isn't a temporary right connected to a certain event, so it wouldn't be limited to just whatever edit-a-thon they were to take part in but would be a "full-time" right that they can use as they want, whenever they want to, and would also be given to several hundred existing user accounts that haven't been screened at all... - Tom | Thomas.W ^talk 14:16, 13 August 2017 (UTC)[reply]

oppose new editors should put articles through AfC - there is no shame in that, and there appears to be an underlying assumption that there is. Doing that does not harm editathons in any way, and actually helps teach new users to respect that they are new and learning and that it takes time to understand the policies and guidelines that allow WP articles to realize the mission of providing high quality articles summarizing accepted knowledge to the public. There is a learning curve. Not impossible to travel up, but there.

On a further note, once permissions are given it is often very hard to take them back, and i do not think it is wise to add this particular permission to this particular class of users.

A better way to manage the trial, if an editathon organizer really wants to give participants the immediate gratification of seeing their work published, would be to recruit independent article reviewers to participate in real time,

which also would be helpful in teaching new users how to interact with independent community members.  Jytdog (talk) 18:54, 13 August 2017 (UTC)[reply]

Television channels

I thought there should be new rules regarding articles about television (and, to some extent, radio) channels.

If a regional version of a multinational TV channel business has a fully independent schedule, an article about that particular version can be created, regardless of where the channel is actually transmitted from. (Thus, for example, the articles like Cartoon Network (Brazil) and Discovery Kids (Brazil) can be created apart from Cartoon Network (Latin America) and Discovery Kids (Latin America), respectively.)
- Of course, channels with simple regional advertisement opt-out or minor variation(s) in schedule (like UK's Sky Sports channels in the Republic of Ireland) should not be counted as such.
If, for example, 'Channel H' is simply a rebrand of 'Channel Q', and thus making the former a continuation of the latter, the two should be regarded as a same channel, even if the channel was also reformatted in the process (for example, a documentary channel turned into a sports channel).
- In that sense, Discovery Kids USA-The Hub-Hub Network-Discovery Family should be treated as same channel rebranded over the years, and so does Locomotion (TV channel)-Animax (Latin America)-Sony Spin-Lifetime (Latin American TV channel).
- (Edited. JSH-alive/^{talk/cont/mail} 15:35, 7 August 2017 (UTC)) Some exception(s) can be made if the two channels should be considered as different channels for legal or technical reason: for example, Discovery Kids (Canada) was replaced on most Canadian TV providers by Nickelodeon (Canada) with a separate CRTC licence. Thus, DK Canada and Nick Canada can be regarded as two separate channels.[reply]
And finally, article's title (with parenthesis) for disambiguation...
- If a channel's name has any word that indicates a broadcast channel (like 'channel', 'television', 'TV', 'network', etc.), a word that strongly implies a media brand, or a name of broadcaster, article's title can simply have a name of country or region in parenthesis.
  - Cartoon Network (Latin America), TVN (South Korea), Disney Channel (Southeast Asia), Channel 5 (United Kingdom), etc.
  - Discovery Turbo (UK & Ireland), Cartoonito (Italy), Disney XD (Netherlands), etc.
  - BBC Entertainment (Southeast Asia), CBS Reality (UK & Ireland), CBC TV (Barbados), etc.
- If a channel's name consists of normal word(s), there should be 'TV channel' in parenthesis as well.
  - Fox (Finnish TV channel), Boing (Spanish TV channel), Pop (Italian TV channel), Boomerang (Latin American TV channel), etc.

JSH-alive/^{talk/cont/mail} 15:29, 6 August 2017 (UTC)[reply]

This sounds like something to discuss at Wikipedia:WikiProject Television. Praemonitus (talk) 19:47, 9 August 2017 (UTC)[reply]

WikiProject Hasbro

I think there should be a WikiProject that oversees the Wikipedia articles about Hasbro's toy, games and multimedia businesses, named Wikipedia:WikiProject Hasbro (just like Wikipedia:WikiProject Lego). A child project of Wikipedia:WikiProject Toys, it would have two WikiProjects - Transformers and G. I. Joe (the latter is believed to be semi-active) - as child projects, and absorb Wikiproject My Little Pony (which is believed to be inactive). It should also oversee other subjects (like Mr. Potato Head, Nerf, Jem, Moon Dreamers, Glo Friends, Hanazuki, FurReal Friends, etc.) previously not overseen by the three individual projects. I'm not sure if I could intensively participate in that project for the long time, but I feel there's a need. JSH-alive/^{talk/cont/mail} 15:31, 6 August 2017 (UTC)[reply]

You can read WP:PRJCRE and then start it yourself. Ruslik_Zero 20:16, 6 August 2017 (UTC)[reply]

JSH-alive, a WP:WikiProject is a group of people. If you don't have a group of people that want to work together, then there is no point in creating yet another set of inactive pages for a WikiProject that doesn't really exist. In general, niche areas without a serious (think "Star Wars"-level) fan base are doomed to failure. People who are interested in Hasbro toys should start off by trying to WP:REVIVE Wikipedia:WikiProject Toys, and only split into a narrower group if it gets too busy (which, in my not-inconsiderable experience, requires more than one hundred participants). WhatamIdoing (talk) 17:59, 7 August 2017 (UTC)[reply]

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 So Why 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 So Why 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. — Insert CleverPhrase Here 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. ~ Rob₁₃^Talk 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 So Why 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. ~ Rob₁₃^Talk 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 So Why 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 So Why 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 So Why 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. — Insert CleverPhrase Here 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 So Why 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. — Insert CleverPhrase Here 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 So Why 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. — Insert CleverPhrase Here 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 So Why 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. — Insert CleverPhrase Here 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. — Insert CleverPhrase Here 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. — Insert CleverPhrase Here 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 So Why 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. — Insert CleverPhrase Here 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. — Insert CleverPhrase Here 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, SmokeyJoe is already working on this. He might be able to provide some context. TonyBallioni (talk) 15:44, 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. — Insert CleverPhrase Here 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. — Insert CleverPhrase Here 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]
- Well, "less frequently" is a loose term. I don't think 200 such moves in a week alone (cf. https://quarry.wmflabs.org/query/20795) can be considered infrequent. I don't have time now to check all those moves but I am fairly certain not all of them were correct (and those are just moves without a redirect, i.e. those not leaving a trace for a second pair of eyes to check). Regards So Why 07:23, 9 August 2017 (UTC)[reply]
  - I have made a somewhat easier to read list of the moves mentioned above here.Mduvekot (talk) 14:10, 11 August 2017 (UTC)[reply]
- That's a common misconception. In the run-up to the Olympics/Paralympics, the Olympic Project creates many articles on Olympians. In some cases, they are not presumed notable, because they are not considered Olympians until the games begin. But we want to have the articles on them on day one, when the readers will start looking for information on them, so they are kept in the User space until either the articles reach the point where WP:GNG is demonstrated, or the games begin. The Draft space cannot be used for this purpose. The Draft space is reserved for the use of AFC Project. Hawkeye7 (talk) 22:10, 9 August 2017 (UTC)[reply]
  - Hawkeye7, there is nothing on WP:Drafts that says anything about it being exclusive to AfC. The language of that page suggests the opposite: Editors may also optionally submit drafts for review via the articles for creation process. (emphasis mine). TonyBallioni (talk) 22:20, 9 August 2017 (UTC)[reply]
    But that's the way it is. Anything placed in the Draft space will be tagged with a {{AFC submission}} template. See User talk:Ricky81682/Archive 10#"Unsubmitting" drafts and User talk:Hawkeye7/Archive 2015#Draftspace for the discussion. And also the comments by Softlavender and John Cline. We don't want our efforts to create new Olympic articles to go through the AFC process. Hawkeye7 (talk) 00:19, 10 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]

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...ronaz^Talk! 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. Keira 1996 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]
- What purpose does a redirect serve that {{There is a draft for this article}} does not? Does it just need to be displayed more prominently, or maybe for Draft: to be searchable by default along with mainspace? —Cryptic 17:33, 12 August 2017 (UTC)[reply]
  - Well, my experience has been that editors object to having a working redirect going from mainspace to draftspace. Nor do I think that draftspace should be searchable from Google.
    Here is a new proposal: Adding Category:Wikipedia draftspace to a redirect, soft or hard, in mainspace moves the edit history to draftspace, and no further edits are allowed until the draft article is moved back to mainspace. A common redirect is {{soft redirect|Wikipedia draftspace}}. Then we'd need to write the article at Wikipedia draftspace to attract new editors and explain how to locate articles in draftspace. Unscintillating (talk) 19:43, 12 August 2017 (UTC)[reply]

CWW - What's the point?

I intended to clean up an article marked {Copypaste} from 2016. It was fresh in Oct 2016, a complete article, but with tags that indicated they had been retrieved several years before. It was a mashup of other articles from WP or mirrors.

WP:CWW says a new article like this one needs to have attribution unless WP:NOATT applies or WP:PATT is satisfied. I got into a discussion with another editor who deleted a speedy-delete tag and said the process was fine.

The logical result, over time, is that we end up with a multiplicity of articles describing the same content in different mixtures. There is no harm in that, but if an error is injected into one copy, it can be copied from parent to child indefinitely. Because these pages all come with references, they look legit. Only a review of every line and reference would fix each one. Fixing one leaves the others broken.

WP editors, according to their own desires like to format, correct grammar mistakes, discover new facts and cite them, rearrange old unwieldy articles, or create new ones. That is satisfying work. You can see your results. Asking someone to verify every reference in an article is not very popular, as you can tell from the backlogs. There a million articles (yes 1,000,000) with bad references. Every time one of those articles is copied, the number ratchets up.

In the database world, there is a concept called normality. One such standard is third form normal. In it a fact (datum) occurs only once. It is either correct or false. Fix it once and it is fixed everywhere. We allow wikilinks to whole articles. Why not have another form of wikilink that allows one to build an article from portions of other articles? Instead of copying a paragraph, leaving two separate paragraphs that have to be maintained, there is only one underlying paragraph that is correct in both articles? It would solve so many problems where we now use {main}. The subsidiary article explodes and gets out of sync with the main article.

It's a big step, but it would solve many problems. I posted at the Teahouse, but was recommended here. Rhadow (talk) 13:01, 11 August 2017 (UTC)[reply]

I'll start with where I do agree with you. Normalisation is a great goal for basic data. We all should be using it to simplify references and citations. AS an example I have just been looking at one page where one book has its bibliographical information and wikilinks repeated 13 times, a full reference for each change of page number! My task this evening will be to change it to a {{sfn}} system so that there is one bibliography and a series of simple references with the page numbers.

Where I disagree however is when we have "a multiplicity of articles describing the same content in different mixtures" and you say "There is no harm in that". Intelligent use of WP:MERGE and hat notes should seriously reduce duplication. This is the 21st century and we do have hypertext! It is reasonable to précis the page "History of XYZ" into a one or two paragraph summary in a section called history within the "XYZ" article. A hat note will lead the reader to the fuller form. What is a waste of time is to copy word for word (and reference for reference) paragraph after paragraph from one page to another. Speaking personally I would not expect a summary to have detailed referencing if there is a full form elsewhere, so the issue of propagating bad references also goes away.

In summary; lets keep normalisation for data and sort out duplication using the existing structures of Wiki. I'm sure there are boundary cases but to create a structure to solve a problem that shouldn't be there in the first place is, IMHO, a waste of time. Regards, Martin of Sheffield (talk) 13:24, 11 August 2017 (UTC)[reply]

(edit conflict) It'd be difficult to maintain. For example, when preparing Papal conclave, May 1605 for GA review I copied content into the background from Papal conclave, March 1605, since that was the background and it had just made it through a GAR, so I knew the content was of GA quality. I made some tweaks to it if I recall in terms of tense, etc. Having the content for these articles be in one normalized source paragraph makes little sense because they took place in (barely) different moments in time. While one is the background for the other, having them be from the same source (let's assume it is a page with the paragraph that could be transcluded), would not be helpful but copying existing content in a new page and then tweaking it was. Similar issues took place with Foreign policy of the Donald Trump administration, which we split and trimmed from Foreign policy of Donald Trump and Economic policy of Donald Trump. Copying the content was useful, but keeping them separate was as well. TonyBallioni (talk) 13:36, 11 August 2017 (UTC)[reply]

Hello Martin of Sheffield -- "[T]o create a structure to solve a problem that shouldn't be there in the first place is, IMHO, a waste of time." It seems we are in violent agreement. On the point of copying paragraphs and references we agree completely. One should be able to capture a lede in its entirety and in fixed, verified form, and insert it elsewhere, not as a hyperlink, but as readable text, no references needed (because they have already been captured). Having two articles that include common elements, but from a different viewpoint, is a matter for discussion. I say "no harm in that." You see it as unnecessary duplication we can eliminate by WP:MERGE. In the example I described, the editor defended the article to the extent that he or she reverted the Delete tag. Losing the history of the text and its references didn't matter to the editor in the slightest. I pointed out the danger in that, and I think you agree. TonyBallioni gives support for copying and pasting in a specific instance, to disaggregate articles as was done with Trump. What is the solution? Rhadow (talk) 14:23, 11 August 2017 (UTC)[reply]

I do like being in "violent agreement", it's much better than the other! :-) I suspect that the instance you are talking about comes under the "boundary cases" heading. Yes they occur, but are rare and can be dealt with in an ad hoc manner. I just don't see the need for establishing the superstructure of a paragraph database. I may have a poke around and take a look this evening. Martin of Sheffield (talk) 15:03, 11 August 2017 (UTC)[reply]

Hello Martin of Sheffield -- Think of the problem another way: Most all of the satisfaction WP gives editors comes from fixing, adding to, or creating content. How about some kind of recognition for merging content, making WP more compact without losing any knowledge? Rhadow (talk) 15:10, 11 August 2017 (UTC)[reply]

The issue here is that you are basically talking about a paragraph database. Anyone who is not a data scientest has worked with databases will tell you how difficult they are to maintain: doing it for something as complex as paragraphs within the English Wikipedia (which is already poorly maintained on many of our older articles) would be much more difficult than just doing it on an article-by-article basis. Wikidata exists and tracks some data between the English Wikipedia and her sister projects. It might be something that you might be interested in if you didn't already know about it. TonyBallioni (talk) 15:39, 11 August 2017 (UTC)[reply]

Request for Importers access

Hello all, I have created a discussion to request importer access. Your input at Wikipedia talk:Requests for page importation#Request for Importers access - Xaosflux is welcome. Thank you for your consideration, — xaosflux ^Talk 14:42, 11 August 2017 (UTC)[reply]

Implement Highlight, Underline, Note, and "share notes" features into Wikipedia.

Implement a highlighting, underlining, and notes feature into Wikipedia.

All changes and uses of these features will be completely unique to every account unless a "share notes" button was added.

Imagine the possibilities of adding these features. Usage of Wikipedia will go up Time management will go up Literacy will go up Efficiency will go up The Learning Curve will dwindle

These 3 features and the "share notes" feature will be great tools for college students and professors, and essentially everyone because it will make learning that much quicker

My general proposal of this will be the follow; Add a Highlighting feature Add a Underlining feature Add a note/comment feature Add a "share notes (highlights, underlines, notes)" feature to other users

And if a page gets updated or a pice of information is removed on a page and you highlighted that part, it will give you a prompt saying "This edit has been changed. Will you like you review it?", something of this nature.

I do a ton of reading on Wikipedia and enjoy learning, and this is certainly a feature that is missing in my life and certainly millions of other users as well.— Preceding unsigned comment added by Aviartm (talk • contribs) 15:47, 11 August 2017 (UTC)[reply]

@@ Line 279: / Line 279: @@
 :*{{ping|Sayan rc}} The right to auto-confirm other users, and even themselves and whatever socks they might create, isn't a temporary right connected to a certain event, so it wouldn't be limited to just whatever edit-a-thon they were to take part in but would be a "full-time" right that they can use as they want, whenever they want to, and would also be given to several hundred existing user accounts that haven't been screened at all... -&nbsp;'''Tom'''&nbsp;&#124;&nbsp;[[User:Thomas.W|Thomas.W]] [[User talk:Thomas.W|'''''<sup><small> talk</small></sup>''''']] 14:16, 13 August 2017 (UTC)
 * '''oppose''' new editors should put articles through AfC - there is no shame in that, and there appears to be an underlying assumption that there is.  Doing that does not harm editathons in any way, and actually helps teach new users to respect that they are new and learning and that it takes time to understand the policies and guidelines that allow WP articles to realize the mission of providing high quality articles summarizing accepted knowledge to the public.  There ''is'' a learning curve.   Not impossible to travel up, but there.
-:On a further note, once permissions are given it is often very hard to take them back, and i do not think it is wise to add this particular permission to this particular class of users. [[User:Jytdog|Jytdog]] ([[User talk:Jytdog|talk]]) 18:54, 13 August 2017 (UTC)
+:On a further note, once permissions are given it is often very hard to take them back, and i do not think it is wise to add this particular permission to this particular class of users.
+:A better way to manage the trial, if an editathon organizer really wants to give participants the immediate gratification of seeing their work published, would be to recruit independent article reviewers to participate in real time,
+ which also would be helpful in teaching new users how to interact with independent community members.  [[User:Jytdog|Jytdog]] ([[User talk:Jytdog|talk]]) 18:54, 13 August 2017 (UTC)
 == Television channels ==