Jump to content

Wikipedia:Village pump (proposals)/Archive 137

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

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

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Make PC2 no longer available to admins

By a large margin, the participants to this discussion have shown there is no longer a need for this technical control and removal of the configuration is supported. — xaosflux Talk 04:10, 27 January 2017 (UTC)
No objection. See Nyttend's reply on my talk page. - Dank (push to talk) 05:09, 27 January 2017 (UTC)

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

Tracked in Phabricator
Task T156448

Since there has been no consensus for the amended PC2, no consensus exists for the original PC2, and it is unlikely to achieve consensus, we should remove the option for (original) PC2 from the protection form and policy. Cenarium (talk) 16:11, 13 January 2017 (UTC)

I agree.--Ymblanter (talk) 19:18, 13 January 2017 (UTC)
  • We need more comments for this to go to phabricator, I'll list this to CENT. Cenarium (talk) 12:03, 19 January 2017 (UTC)
  • I agree in principle. However, since PC2 has been used, both on test pages and actual articles, I would not want to mess up the logs. If PC2 is removed will the logs be affected? BethNaught (talk) 12:58, 19 January 2017 (UTC)
    No, it won't be. Cenarium (talk) 21:15, 19 January 2017 (UTC)
  • Support - this almost never used PC2 is no more than a legal fiction, taking up space in policy & guidance pages and a potential source of confusion. References to PC2 in project space should be erased and references to "Pending changes level 1" renamed as just "Pending changes": Noyster (talk), 13:21, 19 January 2017 (UTC)
  • Support until such time that there is consensus to use it. עוד מישהו Od Mishehu 13:35, 19 January 2017 (UTC)
  • Support - this is a tool which admins cannot use in any situation, per repeated broad consensus, and any admin who does is bound to meet with severe dramah. There's no reason why it should even be a technical option at this point. Ivanvector (Talk/Edits) 13:58, 19 January 2017 (UTC)
  • Support There's no point in having this cluttering up the options when protecting if we aren't supposed to be using it anyway. There are plenty of other options for protection, this one is simply unecessary and unused. Beeblebrox (talk) 19:12, 19 January 2017 (UTC)
  • Support If it can't be used, it shouldn't be able to be used. --AntiCompositeNumber (Leave a message) 23:38, 19 January 2017 (UTC)
  • Support removal from the admin toolbox; I don't keep any tools in my toolbox at home that I know I will never use. However, should consensus on using PC2 ever be achieved, it should be able to be restored to the toolbox. — Jkudlick ⚓ t ⚓ c ⚓ s 23:49, 19 January 2017 (UTC)
  • Support. PC2 used to be used ad-hoc for cases typically involving arbitration enforcement of some sort, and required a consensus to be obtained at the talk page/ANI/wherever for each individual use. I'm glad we now have ECP. -- King of ♥ ♦ ♣ ♠ 00:21, 20 January 2017 (UTC)
  • Support as long as there is no negative impact on historical logs. –Grondemar 06:28, 20 January 2017 (UTC)
  • Somewhere between weak support to meh - Not using it is almost the same as not having it, and it seems an unnecessary gray space between PC1 and ECP, even if I can make myself imagine some IAR instances involving BLP where PC2 would be a preferable middle ground (though some combination of ECP and PC1 would do a better job of that IMO). It's not readily available to individuals who would delete the main page, though, so I don't see the work of removing it as absolutely necessary (unless the people involved really want to spend time on that). Ian.thomson (talk) 07:08, 20 January 2017 (UTC)
  • Comment - is there an example of a problem this removal would solve? Not opposed to the proposal by any means, but I can't immediately see why it matters either way. -- Euryalus (talk) 07:17, 20 January 2017 (UTC)
Accidental clicking comes to mind. Otherwise, that exact question is why my support is weak and I otherwise !voted "meh". Ian.thomson (talk) 07:19, 20 January 2017 (UTC)
I don't know that it has happened recently, but it has been applied against policy and consensus a number of times by admins who wer somehow unaware they should be using it. While we should expect admins to know such things, I can't see the harm in just getting rid of the option to use it at all. Beeblebrox (talk) 07:36, 20 January 2017 (UTC)
Fair enough. Support per Ian.thomson, as a housekeeping measure. -- Euryalus (talk) 08:13, 20 January 2017 (UTC)
  •  Question: Since a consensus here is fairly obvious, do we know how to turn it off? Can we do it locally or do we have to get devs or other foundation people to do it? Beeblebrox (talk) 21:57, 25 January 2017 (UTC)
    • In a little over 12 hours, it will be one week since this question was listed at T:CENT. At that point, I'll have one question for Nyttend and another one for everyone. Depending on the answers, I may snow-close this, and then I think it makes sense to present this to the WMF and see what happens. It's entirely possible that everyone will be happy with the result. No drama is better than drama. If something goes wrong, we can deal with it at the time. - Dank (push to talk) 22:26, 25 January 2017 (UTC)
    • This is trivial to remove, see User_talk:Cenarium#PC2_and_WP:DEFER. Cenarium (talk) 02:28, 27 January 2017 (UTC)
  • Question. Does anyone here know of any admin, or any group of non-admins, expressing a preference for ever using PC2 within, say, the last year, apart from the related discussion at WP:Pending changes/Request for Comment 2016? I'll ask Nyttend a similar question on his talk page. Normally, of course, the voting here would suggest a snow-close without further discussion, but it's impossible to know ahead of time what the WMF's response will be, so it's a good idea to be clear with them about the state of discussions on the topic. My general sense has been that PC2 discussion has died down in the wake of the two new alternatives, the edit filter and extended-confirmed protection, but I admit I haven't been keeping up. (To save people the trouble of clicking, WP:Pending changes/Request for Comment March 2016 was open for over a month and attracted almost no support.) - Dank (push to talk) 19:32, 26 January 2017 (UTC)
Seems like forever ago that you and me sat down and tried to crack this nut at Wikimania. I have to say that even then I wasn't sure what benefit there was to PC2 over other forms of protection. Seeing as PC as a whole was developed specifically for this project, I would hope the WMF devs and engineers would be fine with a piece of it just going away as it's one less thing they have to maintain. In fact, that's exactly how you should approach them, "hey guys, good news, we can get rid of something nobody's using end never worry about it again!" Beeblebrox (talk) 20:25, 26 January 2017 (UTC)
I don't get what this is all about - nobody is going to be bothered at the WMF by the removal, which is completely trivial. But it isn't going to be one less thing to maintain, it works the same way as PC1 and other wikis use multiple PC levels. We just need to link this discussion and that's it (which doesn't mean it's going to get removed quickly). Cenarium (talk) 02:28, 27 January 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Propose marking Wikipedia:Article Rescue Squadron as historical

Let me preface this by saying that this is not intended as a judgement or indictment of this project, rather a simple reflection of the fact that it is inactive. After a number of the more high-profile members of the project wound up blocked for various things several years ago, it seems to have petered out. Only four actual users posted to the talk page in all of 2016. Nobody has actually responded directly to another users' post in 14 months. Last edit of any kind to the talk page was over four months ago. There were only five edits by users to the project's main page in 2016, the last even marginally substantive edit was five months ago. The rescue list, the heart of this project, still gets an occasional post. For the last year there has been no actual discussion there, users post things and later on a bot archives them. Several formerly active areas of the project have already been marked as historical.

All of that being the case, it seems clear that this project is basically not doing anything and should be marked as historical. However, I suspect if I or anyone else did so without discussing it first they would be reverted and needless drama would follow, so it would be better to establish a consensus to do so first. Beeblebrox (talk) 07:18, 18 January 2017 (UTC)

  • Oppose The proposal is obviously mistaken because it states quite clearly that there has been activity in 2016 and there were clearly fresh listings in December 2016. Myself, I engage in rescue activity on a daily basis – patrolling and removing proposed deletions; participating at AFD; filling in red links and improving articles at related activities like Women in Red and editathons like the one scheduled for next Monday. And I'm still ready to answer a call for assistance when it comes; notice how quickly I responded to this proposal. The project is listed as a resource in works about Wikipedia such as Wikipedia – The Missing Manual and has been written about by illustrious members such as Nicholson Baker. If it's quieter now then that reflects the fact that AfD in general is much quieter than it used to be in previous years. Andrew D. (talk) 08:09, 18 January 2017 (UTC)
  • The rescue list, the heart of this project, still gets an occasional post. This says it all: the project is still serving its purpose. The list averaged 3/4 posts per month last year, notifying us of articles where the skills of users good at finding sources would be helpful; there's no need for discussion taking place in the list itself, when usually there's a proper discussion at the other side of the link. Diego (talk) 15:19, 18 January 2017 (UTC)
i'm not proposing "eliminating" it, but for the record this was posted less than one minute after this discussion was opened. Beeblebrox (talk) —Preceding undated comment added 19:04, 18 January 2017 (UTC)
Shutting it down is eliminating it. And I think a notice on the rescue list page itself would get more notice. I'll put one there. That's all people check regularly. Dream Focus 19:37, 18 January 2017 (UTC)
  • Strong support We need to get better at closing down old projects that have long since stopped serving their cause. A major issue when I started on Wikipedia was how I found it difficult to find out where I could best partner up and discuss things with other editors. The reason for this was the bazillion different projects I could join, of which only a mere handful were actually active.
I get the pride and why people defend it, but an occasional message every few months that doesn't get a response only acts to disperse what could be centralized discussion, leading to threads with no answers.
Other online communities are maybe less impacted by this, or are better at closing down their dead spaces. We need to do it too. Carl Fredrik 💌 📧 19:34, 18 January 2017 (UTC)
Edit: added strong – there is really no discussion to be seen on that page. Its talk page consists of a few notices without responses. That is precisely what a dead project looks like. Carl Fredrik 💌 📧 19:35, 18 January 2017 (UTC)
Wikipedia:Article_Rescue_Squadron_-_Rescue_list does get activity, and does get results for articles listed there by people wanting help. Dream Focus 19:41, 18 January 2017 (UTC)
  • Oppose - I've been an active user there in the past, and still monitor it for entries, and still occasionally participate when entries are added. Not sure why folks think it's "historical", though I guess you'd have to look at the Wikipedia:Article_Rescue_Squadron_-_Rescue_list page. -- GreenC 19:52, 18 January 2017 (UTC)
  • Oppose - Active, not historical. Hmlarson (talk) 20:13, 18 January 2017 (UTC)
  • All I can say is that to an outside observer it doesn't look like there is any actual collaboration happening via this project anymore. That is the purpose of wiki projects after all, but I'm willing to concede the possibility that they are doing so in ways that don't leave obvious footprints even though I've never seen anything like that before. Beeblebrox (talk) —Preceding undated comment added 23:26, 18 January 2017 (UTC)
    Someone asks for help finding sources for something that seems notable or working on the article to make it more encyclopedic, they post there, and various people show up to help if they can, more often than not. You posted there once asking for help with an article. Wikipedia:Article_Rescue_Squadron_-_Rescue_list/Archive_12#Course_.28meal.29 Ashley Qualls shows collaborations still happen. One editor asks for help and finds some books mentioning the person, mentioning them in the AFD. I read through references and searched for more reliable sources, and did some work on the article. Another editor shows up and added additional references to the article. Dream Focus 03:31, 19 January 2017 (UTC)
  • ARS is a WikiProject. They are rarely marked "historical". The usual thing to do is to mark it as "semi-active" or "inactive" with {{WikiProject status}}. WhatamIdoing (talk) 07:29, 19 January 2017 (UTC)
  • Oppose While I don't spend a lot of time watching the project, but I think the majority of my wikipedia time and edits are necessarily involved in article rescue. In other words, there are too damned many wiki editors out there who wish to delete valid content, who wish to censor knowledge from the rest of the world. If these feckless people would learn how to do a WP:BEFORE, meaning do a google search before acting; if they would learn to respect the hard work of other editors, particularly newbies and IPs; in some cases, if they would just learn how to read; article rescue would not be needed. However, that is not the case. We have, as a class, far too many illiterate, obstinate idiots, many with senior wikipedia credentials, who get their jollies out of removing content. If they would use their wiki skills to help editors with inferior, they would be doing some good for the community. Instead, the inflate their egos by throwing their weight around. One person's opinion vs serving the greater good. It is a never ending, thankless job to try to defend the material that is here. An effort to silence this group, to declare it dead, to try to make it go away, is reprehensible. Trackinfo (talk) 01:45, 24 January 2017 (UTC)
  • Two points:
    1. The project clearly is active. Editors post on the Rescue list, editors follow those links and pile on at the discussion. And turnout works, both in this discussion and in the names that recur across the listed discussion, which means that...
    2. The project, intentionally or not, is being used to ideologically canvass editors with a certain (lenient) stance towards the general notability guideline to the listed discussions. Look even quickly at each of the recent discussions posted and find the same few names popping up to reinforce a previous point, often without putting forth new sourcing, and rarely (never?) disagreeing.
ARS isn't my area, and I'm not into finding new ways to discourage productive editing. I am in favor of getting better bibliographers into AfD, and of bringing wider (not just more) participation to low-traffic discussions. I believe most editors can get behind all that. I don't think there is cause to mark this effort as "historical" based on its activity, but I do think the page has issues with ideological canvassing against the spirit of AfD. When I need help with specific sourcing, I ask for help from specific librarians/editors who I know are good in those fields, but I avoid linking such discussions and certainly don't do it en masse. When a discussion lacks participation, we relist it neutrally so as not to attract partisans. A quick review of ARS discussions shows that there is more at play than simply providing sources—it's used to stack discussions. If the same action happened on any other forum, even if it were just to recruit librarians to participate, we would call it inappropriate canvassing, so I don't see how that isn't the case here. I would recommend that the project refine itself to avoid that criticism. My specific advice would be to retire the "Rescue list" and instead decentralize by offering specific topic-based resources (both experienced editors and neutral bibliographic resources), not discussion turnout. I am no longer watching this page--ping if you'd like a response czar 07:47, 31 January 2017 (UTC)

New template needed

I am reposting a proposal which I made a month ago and which was archived. It is for a new template to flag instances of what I would like to call "translationese", or basically language that is not good English. There has been some discussion of this on the Talk page of Wikipedia's internal page having to do with Cleanup templates. Here is an example provided by another editor, which he found on another discussion thread about Cleanup templates (of all places!):

Articles occasionally contain content which is otherwise valid, but appears unrelated to the nominal topic of the article. However, such stray may be subject of interpretation and must not lead to common understanding.

The second sentence above is the kind of thing that needs a new Cleanup template to flag it. Currently available templates include the following: {{Cleanup translation}} or {{Rough translation}}. However, these templates flag the entire article, and they apply specifically to known cases where the entire article was translated from another language. The cases I am thinking of involve edits or discussion threads which are written in bad English, in a "translationese" style which requires clarification. There should be an inline template or maybe a section template that flags such instances without deleting them.

Thanks to Users Thnidu and Justlettersandnumbers for their previous helpful comments on this.

- Wwallacee (talk) 08:59, 1 February 2017 (UTC)

Wwallacee, I agree that there's plenty of "translationese" about. I've just found out, but didn't know before, that {{rough translation}} has a |section parameter. Otherwise, I think that {{copyedit}} or {{copy edit section}}, with a suitable rationale, would cover many cases. I'm not actually opposed to creating a new template, but don't see any particular need for it. But if you do, why don't you just go ahead and create it, and see if anyone uses it? Justlettersandnumbers (talk) 11:51, 1 February 2017 (UTC)
Broadly agree with all of the above. If you feel the need for such a template, go for it, I don't see any need for a proposal and pre-discussion. Beeblebrox (talk) 18:39, 1 February 2017 (UTC)
@Justlettersandnumbers and Beeblebrox: Not surprisingly, I agree with Wwallacee. In addition, though, note that {{copyedit}} and {{copy edit section}} tag a whole page or section (as does {{ Rough translation}}), and both would additionally require the mention of translationese and adequate identification of the part of the text that needs work. I'd much rather have a template that, somewhat like {{sic}}, (a) can enclose the whole piece of text that needs work and (b) displays a tag [translationese] at the end of it, thus taking care of those two pieces of necessary work.--Thnidu (talk) 01:03, 2 February 2017 (UTC)

Category redirects from "organisation" to "organization" and vice versa

At Wikipedia:Bots/Requests_for_approval#BHGbot_3, I requested permission to run a bot to create a set of a few thousand category redirects from "Foo organisations" to "Foo organizations" and vice versa.

If anyone has any views on whether this is a good or a bad idea, please add your comments at Wikipedia:Bots/Requests_for_approval#BHGbot_3. --BrownHairedGirl (talk) • (contribs) 13:50, 2 February 2017 (UTC)

New Page Reviewing - Election for coordinators

New Page Reviewing - Election for 2 coordinators. Nomination period is now open and will run for two weeks followed by a two-week voting period.

  • Nomination period: Sunday 5 February to 23:59 UTC Sunday 19 February
  • Voting period: Monday 20 February to 23:59 UTC Monday 06 March

See: NPR Coordinators for full details. Kudpung กุดผึ้ง (talk) 17:03, 5 February 2017 (UTC)

Abolishing the edit-ban of archived talk pages

WP:SNOW CLOSE
Opposition to this proposal is unanimous. Discussion of modifying archive template language can take place on the talk page of the relevant template. Beeblebrox (talk) 20:00, 6 February 2017 (UTC)

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

Currently the {{Talk archive navigation}} and {{Talk archive}} templates say: 

    Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I propose abolishing this edit-ban as it significantly hinders discussion and progress on Wikipedia.

(Close to) nobody is going to actually go to an archive and revive an old discussion to post a single comment (especially for some rather small but nonetheless useful comment) - please don't deceive yourself.

Actually that's more than to expect from most editors - let alone readers - already. If anything allow editing of the page and automatically move the revived discussion to the talk page via a bot / automated process (that would actually be a second, separate proposal here; the template-text should however be changed first and asap).

It's Wikipedia - these are not actual physical "archives" - these are dynamic websites and we should be making use of this advantage (which is that no matter how old a discussion is it can be easily returned to).

If you think that this would be useful to prevent vandals from editing old talk pages: they can do so even with the template set but while the bad guys still can do their mischief and won't be stopped by this those who intend to reply to an old discussion are significantly discouraged/obstructed even though there are many instances where it would be very useful to instead of even encourage the revival of old discussions and their ideas.

You could also suggest some text that it can be replaced with (roughly).

I'd suggest something along the lines of: 

   This is an archived talk page. You may still reply to users here. Please use the {{ping}} template to notify them.

--Fixuture (talk) 18:10, 4 February 2017 (UTC)

Unnecessary. If you want to revive a discussion, bring it back to the main talk page. ansh666 18:33, 4 February 2017 (UTC)
I agree. If someone wants to revive a discussion, just take it out of archive and put it back on the main page. 24.29.215.27 (talk) 20:15, 4 February 2017 (UTC)
Wholeheartedly agree with the ban. I know some editors ignore it but revived discussions should be brought to the current page, possibly in summary and possibly including referencing back. Martin of Sheffield (talk) 20:44, 4 February 2017 (UTC)
@Ansh666, 24.29.215.27, and Martin of Sheffield: I expected people to say this here which is way I stressed multiple times that I'd like you to think practical about this and that in reality nobody (very few people very seldomly) does that.
Nobody. is. doing. that.
This is not the solution. Just because from your point of view as experienced editors it's easy to do a copy-paste move from the archive page to the current talk page doesn't mean that newcomers should be expected to do so. There are many reasons why this is a problematic approach:
  • It discourages editors from taking part in discussions and providing valuable input by making it a lot harder (in time and effort) to reply to a talk page entry, in addition to the extra time & effort needed the main point here is being open to newcomers and people that aren't as Wikipedia-savvy as you might be (note that people often speak about how hard Wikipedia is for newcomers - this is one such instance)
  • Also note that an effect of this is an increase of the perceived threshold for creating a reply - this means people won't reply if they aren't very sure that their reply is very useful or if they really want to know something etc. - this means much potential valuable content & discussion gets missed out. For better understanding of this: if you only have some short but potentially useful input and can very quickly and easily reply to a post (and that wouldn't be given even if the ban is abolished) you're more likely to make it than if people require you to do some pretty obnoxious wiki-code-juggling and "revive" an old thread and so that everybody gets "annoyed" by this "strange users that thinks a small correction of a year-date in thread that's irrelevant anyways" would be useful enough for this. A counter-argument of this would be that any such post such might develop into a discussion for which other users would be interested in as well. To this I'd say that this comes second after ensuring that the reply gets made in the first place. Also for this the text of the template could still encourage moving an archived thread to the current talk page (e.g. if one thinks it might be interesting some other editors as well) - which is something the person replied to can do as well btw. But after all the most perfect solution would be a bot that simply moves any discussions revived (btw one could consider this to be defined by 2 new replies instead of just one) to the current talk page. But again: I think that would go second after ensuring that these replies are made asap.
  • There's not even a tutorial on how to "revive an old one" - many might not boldly assume that this means copy-pasting content to the talk page as you might but might be unsure about how this is expected to be done: e.g. if there's some requests-like process here or if one should cut & paste it instead of copying it. Actually I'm not even sure myself besides that the latter would conflict with the first part of the template's text but e.g. 24.29.215.27 & User:Mandruss already misinterpreted(?) it to mean cut&pasting it there.
From my point of view I do not care about theory (once the time for it is over) I'm concerned with the practical state of things. This doesn't work in practice. And I want Wikipedia to succeed. Furthermore I think users here might very much be biased by their own editing-boldness & -skills as well as a tendency towards policy-conservatism. Please address these points when replying (and especially so if you'd like to suggest an alternative) and take the latter concerns into consideration.
--Fixuture (talk) 02:39, 5 February 2017 (UTC)
I did not misinterpret anything. It's possible you misinterpreted my comments, as English does not appear to be your first language. The template does not currently speak to restoring an archived thread and, as I said in my comments, perhaps it should do so. If someone lacks the skills necessary to do a copy-and-paste successfully, they may ask someone else to do that. But archive pages are not for discussion, full stop. ―Mandruss ☎ 02:55, 5 February 2017 (UTC)
@Mandruss: Okay, well then the template-text only conflicts with itself. Of course they could ask someone else to do this for them but in practice will never (very seldomly) get done. If people here against such a change then there's the full stop of course - I'm just asking you to consider these points, which you haven't. --Fixuture (talk) 03:22, 5 February 2017 (UTC)
@Fixuture: You can also just start a new one, linking to the old one in the archive, which we also do all the time. But since you made such a point about being practical and all...I'll bite: give us some concrete examples where any of this is a problem. ansh666 04:59, 5 February 2017 (UTC)
Oppose - Note that restoring a thread is a 2-edit operation: 1. Copy-and-paste it to the main page. 2. Remove it from the archive page.
Otherwise we end up with two versions of the archived thread, only one of them complete. This is the only type of edit that should be done to an archive page.
Perhaps the instructions should mention this one exception to the rule. I tend to take such instructions literally, so I never did step 2 until I was educated by an admin about that. ―Mandruss ☎ 20:52, 4 February 2017 (UTC)
Oppose, the main reason: for user_talk archives - it won't trigger "new messages", and for all archives other interested editors won't see it as they are very unlikely to be watchlisting archive pages. — xaosflux Talk 21:16, 4 February 2017 (UTC)
Oppose I have seen both article and user talk pages edited to and refactor posts in various threads. MarnetteD|Talk 21:19, 4 February 2017 (UTC)
  • @Iazyges: What would text would you suggest? I do think that maybe encouraging reviving threads if they might of interest to other editors but not discouraging edits to the archived page could be a possible solution here as well (note that by this the person replied to could also take over the revival of the thread). --Fixuture (talk) 02:39, 5 February 2017 (UTC)
  • Oppose because there's no ban here. These are templates and templates and their documentation are like essays: Anyone can create one and put whatever into it whatever they like but it's not binding on anyone unless the work is done to convert it into a policy or guideline. As far as I know — and I stand to be corrected — there's no policy, guideline, or even information page which makes it a sanctionable event to edit a talk page archive. What it is, is fruitless: No one will be watching and, moreover, any addition to an archived talk page will often be regarded as not contributing to consensus on an issue simply because no one was watching. Moving it back to the active talk page cures all that, but there's nothing really preventing you from editing the archive. — TransporterMan (TALK) 22:29, 4 February 2017 (UTC)
    Oh good, so editors can ignore any instructions they read, and (counter-intuitively) are required to go spend their time hunting down applicable p&g, often contradictory p&g. Really, really bad way to run an encyclopedia, and I oppose it. There is also no policy, guideline, or even information page supporting "ignore all instructions as nothing more than somebody's opinion", as far as I know. Some longtime editors excel at devising unworkable and grossly inefficient systems without community consensus. ―Mandruss ☎ 22:38, 4 February 2017 (UTC)
    @TransporterMan: It becomes quasi-policy once it's a standard template mass-used for a specific purpose. Practically this issue can't be resolved by creating a new template and running an own archive-bot that sets it or alike. --Fixuture (talk) 02:39, 5 February 2017 (UTC
@Mandruss: There is indeed such a policy: CONLIMITED. - TransporterMan (TALK) 07:00, 5 February 2017 (UTC)
When the instructions contradict a community consensus, that argument makes sense. But they rarely do so for very long, so it's also somewhat pointless and tends to confuse more than enlighten. CONLIMITED cannot be used to say that instructions are the mere equivalent of essays. As I said, unworkable and grossly inefficient. ―Mandruss ☎ 09:43, 5 February 2017 (UTC)
  • @Robert McClenon: I do not think that changing the template text solves it but that improves the state of things. And why would it be a dumb idea? A user not getting notified of a reply as the archived pages aren't watchlisted might indeed be a problem here, however the text could state that the username has to be linked / the {{ping}} template be used for a notification. But as said this is just a suggestion for temporary improvement until adequate software changes are made. So a (more) optimal solution to this would probably look like section-level watchlisting being implemented and also applying to talk page archives or a bot automatically moving talk page entries / creating notifications or alike. --Fixuture (talk) 03:22, 5 February 2017 (UTC)
  • Oppose People have to be able to let things go and editing an archived talk page is almost always a bad idea that should not be encouraged. Suppose someone did edit an archive and ping everyone nicely. What are the others supposed to do? Should they continue the argument in the archive? If someone is concerned about a point made in an archive, the solution would be to create a new section on article talk with a link to the archived section and a brief comment with whatever clarification is needed. However, please do that only if it is really necessary—participants should resist the urge to have the last word or to continue an unproductive discussion. There is no need to ping me. Johnuniq (talk) 03:46, 5 February 2017 (UTC)
What are the others supposed to do? Should they continue the argument in the archive?
Yes, or move it to the current talk page if anybody of them thinks it might be of interest to other editors. Note that this isn't just or mainly about arguments, unproductive discussion and last words on talk pages but about providing additional information (e.g. relevant links). For instance, the case I'm experiencing most is actually old village pump entries and alike that outline ideas that one had as well. Sometimes I find these before I made a post about them and sometimes afterwards. With the plenitude of villagepump posts I guess that is happening frequently. What would be the best way to go about such for instance? If the post has already been made it's useful to link to it from the old post and if it hasn't been it would be good to add any information that's missing to the old post. Also I'm planning to go through my old talk page posts, for which I haven't had any time for yet, soon of which most are probably already archived despite not being resolved in any way (typically due to low user engagement). Having unresolved talk page entries go to archives where users are disencouraged from replying and close to nobody will read them anymore kinda pains me (I might restore or resolve mine but those of others are basically lost). This is only my personal experience and not the reason why I made this suggestion though.
the solution would be to create a new section on article talk with a link to the archived section and a brief comment with whatever clarification is needed
The issue with that is that nobody does it and that typically users (often rightfully so) don't think that their brief clarifications/additions are worth restoring the talk page entry.
participants should resist the urge to have the last word or to continue an unproductive discussion
Well, that's a point more or less: this might cause more unconstructive, endless discussions.
As of right now it looks like the quasi-consensus won't shift towards my proposal. So if that doesn't change by the arguments I provided (in the 2 top posts; please consider them!) we still need to decide on what text to replace the template-text with as it's instructions are self-conflicting / paradoxical as noted above. I suggest that it also at least shortly describes how such a revival can be made.
Also maybe people have ideas for alternative approaches to this? Lastly I'd also like to note again that this suggestion was only about a temporary fix until a more optimal software solution can be found by which e.g. talk page entries are restored automatically or are made by the click of a button within an entirely new discussion system (see WP:Flow).
--Fixuture (talk) 04:32, 5 February 2017 (UTC)
I'm not sure what happens on village pump pages, but on other discussion pages, I've seen plenty of examples of editors retrieving discussions from the archives or starting new threads on the same topic with a pointer to the old discussion. Or when a new thread is started, someone aware of the past history will post a link to the older conversation. So while it might be nice to the ability to restore a conversation to the current talk page with a single click, I don't see it as a very pressing issue. It's much simpler to have all current conversation on the current discussion page. isaacl (talk) 04:44, 5 February 2017 (UTC)
Fixutre has a good point about linking to advice from the template; it would only require the addition of a sentence "For advice on how to link to this discussion from the current page please see WP:<something>. Does anyone know if there is a suitable <something> written yet, or where it should go – possible a new appendix to Help: Wikipedia: The Missing Manual? Martin of Sheffield (talk) 12:48, 5 February 2017 (UTC)
@Martin of Sheffield: I'd suggest something like:
Do not add new replies here. Instead move the discussion to the current talk page by cutting it from this page and pasting it there. (help)
(help) should link to a more detailed tutorial on how to go about that which may also feature some other relevant information on the revival of archived talk page entries etc.
--Fixuture (talk) 18:00, 5 February 2017 (UTC)
If an editor lacks the required basic knowledge of the wiki editor and their computer's copy-and-paste functions, they certainly are in no position to use sound judgment as to when an archived discussion should be restored, and we needn't add instructions to help them do that. "Hey I didn't get a chance to participate in this discussion", by itself, is not a good reason to restore a discussion, and your draft instructions do nothing to convey that. Restore should be done sparingly; I've done it about 8 times in 3+1⁄2 years, and most of those were unclosed RfCs that needed to be restored so they could be closed. ―Mandruss ☎ 18:41, 5 February 2017 (UTC)
I don't think that's fair. Some people will look at the current language and believe that "Do not edit the contents of this page" means that they are not allowed – by policy – to "edit the contents of this page" by cutting the discussion out of the archive and moving it to the current talk page. WhatamIdoing (talk) 18:01, 6 February 2017 (UTC)
@WhatamIdoing: I have said twice that the instructions could be updated to mention restore as the only exception to the "don't edit this page". My objection is to a "detailed tutorial" on how to do that. My rationale is that archive restores should be rare and an editor who needs such a tutorial is probably the last person we want making those decisions. It's basic edit and copy-and-paste, both of which are used all the time in the course of editing of any kind. Competence is required. ―Mandruss ☎ 18:42, 6 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC on WP:RESTRICT

Wikipedia:Editing restrictions currently lists every single restriction that either the Arbitration Committee or the broader community have ever placed on a specific user, as well as lists of voluntary restrictions and conditional unblocks. The list is extremely long and contains many restrictions on users who are inactive or have been indefinitely blocked for an extended period. The purpose of this discussion will be to determine if it is desirable to continue to have all of these restrictions listed, and if not, what changes should be made. This is not a discussion of the validity of the individual restrictions or an attempt to have them revoked en masse, it is only concerned with managing the list to make it less cumbersome, and therefore more useful. Beeblebrox (talk) 21:52, 25 January 2017 (UTC)

Possible solutions

  • Remove listings on inactive users. Simply take them off the list if they have not edited in three years. This does not void the restriction.
  • Create an archive Any listing on a user who has not been active for two or more years will be placed in the archive. The restriction remains in place, and may be returned to the main list if the user resumes activity.
  • Split Split the various lists onto their own subpages, and possibly split them further by age, create a searchable index of these pages.
  • Status Quo It's fine the way it is.
  • Get rid of voluntary listings The smallest of the lists, currently only three entries, not really enforceable, not really helpful.
  • Mass review Do the thing we're not doing here: Compile a list of all restrictions that may no longer be necessary and review them all with an eye towards revoking them.

Discussion (WP:RESTRICT)

  • Status quo - Ctrl-F is a thing. Beyond My Ken (talk) 22:39, 25 January 2017 (UTC)
  • I'm not sure that any of the suggested changes would outweigh the benefit of being able to, as BMK put it, Ctrl-F on one page to find a particular user. That said, perhaps a bot-curated archive could be a good solution; if the bot were to move people back and forth based on whether they have been active in the past X years (i.e. if someone goes away they get moved to the archive, then when they start editing again the bot notices and automatically moves them back to the main page). That way there's only a maximum of two pages to search on (and only if you're looking for someone who may or may not be active), but the main one becomes a bit more manageable. Sam Walton (talk) 23:21, 25 January 2017 (UTC)
Just so you guys know, whetever it s that cntrl-F does for you isn't going to work on most mobile devices. Beeblebrox (talk) 23:29, 25 January 2017 (UTC)
As far as I'm aware most mobile browsers have a "Find in page" option. Sam Walton (talk) 23:32, 25 January 2017 (UTC)
Mine probably does somewhere, I guess, but I'm not sure that's really something we should require peopel to know in order to navigate this page. I don't see a particular benefit to bulking up these lists with a permanent record of restrictions on people who have been banned for five years or more, or who just left after their restriction was imposed and never came back. Beeblebrox (talk) 01:09, 26 January 2017 (UTC)
  • Create an archive - move any inactive users to a spearate page; make sure that the introducsion to te page mentions this split, and should any of those users become actiove again, they can be moved back to te active page. עוד מישהו Od Mishehu 05:59, 26 January 2017 (UTC)
    • @Beyond My Ken:If you think that this solution makes finding specific user's restrictions too difficult due to the Ctrl-F option being made difficult, we could also have a separate page which transcludes both parts; you could then use Ctrl-F there with no problem. Even if the community opposes such a third page in the project-space, you could create one in your userspace. עוד מישהו Od Mishehu 05:10, 27 January 2017 (UTC)
      • Why in heck would I want to re-create what should be a community resource in my userspace? I see absolutely no reason to change the existing system - to me it seems like change for the sake of change, and has the distinct downside of potentially destroying information which could come in handy in any future cases involving the listed editors. (You have noticed that the same names tend to pop up again and again, right?) Without the information on the RESTRICT page, we are reliant on the fallible memories of editors. Beyond My Ken (talk) 05:24, 27 January 2017 (UTC)
No information is being destroyed, it will be preserved in the same format on the archive pages for as long as the restriction remains in place and will retain the same functionality as the main list. It is not change for the sake of it, which I dislike as much as the next person. Beeblebrox (talk) 05:24, 7 February 2017 (UTC)
  • Just to note that I created the "Voluntary Restrictions" section, and I was thanked by some of the participants for doing so, as it put in a permanent (I guess semi-permanent now that you all want to change it) public place what had been agreed to. Beyond My Ken (talk) 00:27, 27 January 2017 (UTC)
  • Archive with bot per Samwalton and Od Mishehu. Iazyges Consermonor Opus meum 04:14, 27 January 2017 (UTC)
  • Archive non-voluntary restrictions with a bot. Beyond My Ken makes a very good point about those voluntary restrictions being a needed resource that was requested. It is a valuable community resource that should be easily findable. Old blocks of long-inactive users aren't needed with the same ease and can be archived. While searching the whole page for a user name "as is" isn't that difficult, the difficulty comes when you vaguely remember a restriction and have to hunt it down and see if the user you thought it applied to is or isn't there. That type hunting is harder when the page contains not-current information. Eggishorn (talk) (contrib) 05:50, 27 January 2017 (UTC)
  • Archive inactive users, especially if a bot can determine how active a user has been and move them between lists as necessary. — Jkudlick ⚓ t ⚓ c ⚓ s 00:52, 28 January 2017 (UTC)
  • Comment - Noting that WP:RESTRICT is not an exhaustive list of restrictions. WP:DSLOG contains what may be a much longer list of restrictions imposed as discretionary sanctions. Should we include that page in any of the solutions? - Ryk72 'c.s.n.s.' 04:47, 28 January 2017 (UTC)
  • Archive Active users should still be listed, inactive users can be moved to archive in case they become active again. Justly applied restrictions do not expire, and it is helpful to have a centralized database of all such restrictions as none of us can keep track of every user who makes a pain of themselves. --Jayron32 05:43, 28 January 2017 (UTC)
  • Archive by bot, per Od Mishehu. Tamwin (talk) 03:11, 29 January 2017 (UTC)
  • Status Quo per BMK. The list isn't so long that the page doesn't load well. I am not otherwise against archiving except that I worry that visibility will be lost on restrictions that remain in effect. I don't want archiving to either hide an ongoing restriction or create the impression that the restriction is somehow lapsed from being out of date. Chris Troutman (talk) 17:29, 29 January 2017 (UTC)
That issue could literally be addresses in about two minutes by posting notices on both the archive and the main list stating that the archives are just older restrictions but have not been rescinded. Beeblebrox (talk) 21:16, 30 January 2017 (UTC)
  • Archive - Ctrl-F is a thing for most users, but some old mobile browsers lack that function. Moreover, the old notices serve little purpose other than historical record. This is like old discussions, which we archive in order to maintain user-friendly and tidy talk and discussion pages (e.g., SPI, ANI, user talk pages, etc.). Preserving old information is standard practice here. I see no reason not to employ it on this particular page. We would need to choose a specific time interval (e.g., one year inactivity). EvergreenFir (talk) 05:48, 2 February 2017 (UTC)
  • Currently it runs to 250kb which is a bit big, but there is huge duplication, multiple people under identical sanctions, sometimes grouped together sometimes not. It should be easy to trim it a bit by grouping more people who share the same sanctions. More seriously there are lots of hard to use time clauses, restricted for 6 months or 12 months. Replacing those with dates would be a big step forward "not allowed to do x before 13/02/2017"is much easier to understand, and easy to remove the bits that are out of date. ϢereSpielChequers 10:41, 5 February 2017 (UTC)
I believe arbcom deliberately stopped grouping sanctions some time ago in order to simplify appeals and WP:ARCA requests. Grouping them together again would actually complicate the archiving process. Beeblebrox (talk) 05:22, 7 February 2017 (UTC)

Wikidata items pointing into our draft space

I'm closing my own straw poll. I believe a unanimous eight firm comments is clear enough. Wikidata links to draft pages are not wanted. The discussion section remains open. Alsee (talk) 20:56, 29 January 2017 (UTC)

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

I am horrified that I even have to open this discussion. Apparently there are people at wikidata who are either creating wikidata items pointing to our drafts, or who are attempting to do so. There is an open Phabricator task T122806 Wikidata items for articles in the Draft namespace: It is possible to add sitelinks to draft articles on Wikidata, but they are not functioning properly. If I understand the situation correctly(???), general public readers of foreign language wikis would be given these links, encouraged to read our draft as the "English language" version of the article.

I've only been over at wikidata a few times. I will go over to wikidata and open a discussion on this, but first I'd like to have a quick rough consensus in hand.

Straw poll proposed communique to our friends at Wikidata: 

The EnWiki community requests that Wikidata establish a policy against linking to our draft space. Drafts are intended as an internal workspace. Drafts may contain inappropriate or problematical content. External consumption of drafts is undesired, and is strongly discouraged.

Alsee (talk) 23:43, 27 January 2017 (UTC)

Followup: Yes, my understanding was correct. See wikidata item Q969904. It has links to a French wiki biography, an Italian wiki biography, and to our draft of the same biography. When I view the french biography fr:Gian_Francesco_Biandrate_di_San_Giorgio_Aldobrandini, the left sidebar on the article has links to the article "In other languages". It links to the Italian version, and it links to our draft space as "the English version" of the article. Alsee (talk) 00:00, 28 January 2017 (UTC)

Straw poll

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

Discussion (Wikidata)

  • It's probable that the links to draft space are there because of moves from mainspace to draftspace, and the Wikidata notability policy specifies that Drafts are not welcome as dedicated items. I would guess they would be amenable (as a Wikidatan) to removing Draft-space pages. --Izno (talk) 01:31, 28 January 2017 (UTC)
    • Izno, The draft was not moved. It was created as an unsourced stub, then Wikidata-linked. And the Wikidata notability policy you linked appears unhelpful. If I'm reading it right, all does is affirm Q969904 is valid. It has valid sitelinks to the ItWiki and FrWiki articles. I'd like to ensure there's a policy against draft links. And after that, it may be worth investigating a technical barrier to entering such links. Alsee (talk) 10:52, 28 January 2017 (UTC)
  • Rather than have this poll, have you tried discussing this on Wikidata first? --Rschen7754 04:46, 28 January 2017 (UTC)
  • Comment : There is at least one advantage to this : if someone has already started a draft on a topic you want to write something, you'll be aware of this. TomT0m (talk) 11:43, 28 January 2017 (UTC)
    • Indeed there are several good reasons why you might want to add a sitelink to a draft article. One is that the draft will then show inter-language links to other wikis which could help when writing a new article. Another is to be able to use the data about the topic in infoboxes, etc. which would then work just as well when the article is moved into mainspace. Another is the point by TomT0m above. It is my opinion that inter-language links FROM a draft should be displayed, but links TO a draft should be disabled. This is precisely the opposite of what happens currently, which is why I opened T2000. — Martin (MSGJ · talk) 08:56, 30 January 2017 (UTC)
    • This is kind of a weird thing for us to be trying to make "rules" about. WP:CONEXCEPT indicates that we really have no right to tell Wikidata that they may not track whatever pages they want, and we certainly have no right to tell the communities at the French and Italian Wikipedias (to use the example given) that they have no right to link to our drafts along with the other interlanguage links if that's what they want to do. We really cannot expect to control in-bound links to our pages, whether on WMF-based sites or on independent blogs. WhatamIdoing (talk) 17:02, 6 February 2017 (UTC)
      • WhatamIdoing, I'll assume that you skimmed the topic without carefully reading it. Exactly no one in this discussion tried to make any "rules". Exactly no one said anything that that goes against conexcept. In fact this discussion could be linked from conexcept as an excellent illustration of exactly what conexcept does mean.
        1. A local individual has concerns about what another project is doing.
        2. A non-rulemaking, non-binding, utterly unofficial Straw Poll asks for input to sanity check whether this is a shared concern, just or a rogue individual with weird ideas.
        3. The first community respects the independence of the second community, and sends a friendly request that they stop doing X for reasons Y.
        4. The second community controls its own rules. They may or may not agree with reasons Y. They will act on the information as they see fit.
        1. They may even submit a request for the WMF to make a software change.
        2. The WMF decides whether to spend money (employee salary) making that change. We're all working together as partners, and if there's a good reason for the change then the WMF is generally happy to do so.
      In case you didn't check the discussion at Wikidata[1], the discussion has been going in the direction that they don't want these links on wikidata. Their Notability policy already says that userspace and draft space are not valid sitelinks. The software already blocks any attempt to add an invalid sitelink to userspace. Several of them have said there should also be a technical block preventing invalid sitelinks to draftspace. I think it would require a Phab request to tweak the existing invalid-link check to match the existing policy definition of invalid links. Alsee (talk) 11:10, 7 February 2017 (UTC)

WP:INCUBATOR

I invite you to comment on as well as to endorse my idea of article incubator. The idea is not new and details of the previous version can be found at WP:INCUBATOR. I would be glad if you enhance it with your experience. Feel free to improve upon the proposal that I have placed. Anasuya.D (talk) 10:05, 8 February 2017 (UTC)

  • Sorry, but this is a very bad idea. The original incubator was a disaster and very few articles were ever moved out of it into mainspace. You can see from the discussion just how strong the consesus was to shut it down. We don't need to bring back something that decisively failed. Andrew Lenahan - Starblind 02:07, 9 February 2017 (UTC)

Unbundle EducationProgram rights from sysop

Admins currently have a lengthy list of education program userrights, however those are very specialized and already possessed by course coordinators. See Special:ListGroupRights. If any sysop decides to work in this niche area, they should grant themselves course coordinator. This way, there can be an exhaustive and updated list of course coordinators, which users can rely on if they need assistance. This is a similar rationale as to the edit filter manager group. Cenarium (talk) 13:12, 8 February 2017 (UTC)

Note, admin is the only group that has ep-bulkdelorgs so that shouldn't be removed. As far as the rest, I don't think this is going to solve your issue - people don't search for users based on what permissions they have - they may search for them based on what groups they are in - in which case looking for the list of coordinators will show the very few that exist; this includes 3 admins - who if they want to be active in this realm should feel free to list this as an additional group. — xaosflux Talk 00:32, 9 February 2017 (UTC)
Since they already have ep-bulkdelcourses, I don't see an issue with granting ep-bulkdelorgs to course coodinators as well. This way they would have all necessary rights to handle education program issues. My main interest in this is to prune the ever-expanding list of admin rights, some unbundling is good, we only need some core rights bundled together (mostly block/delete/protect/rightschange). Searching for the list of course coordinators was what I meant. This way, all admins interested in working in this area will have to add themselves to this list so will be visible (as with edit filter managers). Cenarium (talk) 04:04, 9 February 2017 (UTC)

Ok, so in the updated proposal I also suggest to grant ep-bulkdelorgs, currently only owned by admins, to course coordinators as well; this allows them to delete institution pages, knowing that they can already delete course pages and both are logged and reversible. Cenarium (talk) 04:04, 9 February 2017 (UTC)

Unobserved subpages embedded in authoritative policy and guideline pages?

I just noticed that Wikipedia:Requested moves/Controversial essentially has the power of an authoritative guideline despite almost no one having it on their watchlist and so being made aware when a unilateral change is made. It's transcluded in WP:RM, which does have a lot of watchers, but are these editors made aware when the sub-page is edited? I was apparently the first person to notice in over four years that an explicit endorsement of Google was unilaterally transcluded in the page back in 2012. The claim had previously been made that it had been stable for years, but I have to imagine this was only because no one noticed it being added in the first place and everyone else just assumed it had been discussed somewhere.

I'm not really sure how these situations are dealt with, but has this come up before? Is it mentioned anywhere that such subpages should be edited with the same caution as the main pages that have a lot of watchers? If not, should it be?

Hijiri 88 (聖やや) 00:26, 8 February 2017 (UTC)

WP:Requested moves isn't actually a {{guideline}}. (It's a process page.) WhatamIdoing (talk) 21:21, 8 February 2017 (UTC)
I know that. That's why I said "essentially has the power of an authoritative guideline". It's not actually a PAG, but the instructions given there are still supposed to represent community consensus rather than the random thoughts of lone editors. please present Google Books or Google News Archive results before providing other web results. looks like an authoritative instruction, and the user who added it was out of line, but I'd be willing to guess no one ever noticed it except when copy-pasting the template in order to open a new RM, and the reason for that is that the main RM page has over 1,000 watchers, who are presumably interested in what the page actually says, but were likely not notified when the sub-page was edited. In fact the overwhelming majority of text included on that page is transcluded from elsewhere; do the people who have the main RM page watchlisted think they will get notifications when the subpages are modified? Or do they actually get such notifications? (I don't have the page on my watchlist so I actually don't know -- I "Ctrl+F"ed WP:WATCHLIST for "subpage" and [WP:SUBPAGE]] for "watchlist" and came up blank.) If they do get the notifications, I find it hard to believe that the change went uncommented on for over a year.
On the other hand, I can't imagine the page's 1,578 watchers watchlisted it because they want to receive notifications when someone edits the "Commenting in a requested move" or "Relisting" sections but not the rest of the page -- is there any other benefit to having a page watchlisted?
And even if anyone is free to edit process pages as they like because they are technically still subordinate to the PAG pages, doesn't the problem still apply to actual PAG pages that have transcluded subpages? I don't know a fast way to check the total number of such pages, and a quick search appears to indicate that this is not a major issue for any of the core policies, but still...
Hijiri 88 (聖やや) 05:22, 9 February 2017 (UTC)

Urban area vs. Metro area

Wikipedia articles for large United States cities typically display, in their introduction, information regarding the city proper population, and/or the population of the Metropolitan Statistical Area/Combined Statistical Area.

My proposal is as follows: Move the MSA/CSA Statistics from the introduction to the Demographics subheadings. Put the United States Urban Area definitions in their place.

This would make more sense in the introduction because the Urban statistics for U.S. cities are what are typically associated with each city. (Example: Cincinnati lists its City Proper, Metro, and CSA populations in the first paragraph. When people look up "Cincinnati", the Urban population gives the figure for the area immediately surronding Cincinnati, with residents likely going to Cincinnati for services, rather than the 15 surronding counties that people would rather refer to as the greater Cincinnati Area.)

The U.S. Census Bureau refers to an urban area as:

  • "a densely settled core of census tracts and/or census blocks that meet minimum population density requirements, along with adjacent territory containing non-residential urban land uses as well as territory with low population density included to link outlying densely settled territory with the densely settled core."

...while the Office of Management and Budget describes a Metropolitan area as:

  • "one or more adjacent counties or county equivalents that have at least one urban core area of at least 50,000 population, plus adjacent territory that has a high degree of social and economic integration with the core as measured by commuting ties."

I would love to hear everyone's opinions on each. --636Buster (talk) 13:22, 9 February 2017 (UTC)

Hi 636Buster. Perhaps you'd like to explain the application of the above to Beijing or Cape Town? ;-) Seriously though, you need to think this through in an international context and map the US-specific application to the general guidance. Regards, Martin of Sheffield (talk) 13:31, 9 February 2017 (UTC)

You're right, this idea more supports a U.S. theme. In articles on cities in China, the city proper population is listed because it more accurately demonstrates the population of what people would be considered in that city rather than the urban population that describes a smaller area. An example would ve Chongqing, where the urban population refers to a more isolated portion of the city/region. However, U.S. articles display city proper followed by metropolitan rather than the city proper and urban, which would more properly represent the city's size as a cluster rather than a link. --636Buster (talk) 13:47, 9 February 2017 (UTC)
I still think you need to consider internationally. Have a look at Sheffield: city population 563,749, urban population 640,720 and metropolitan area 1,569,000. These figures taken from the infobox. The first paragraph of the lead also mentions the figures. I then compared this layout to Cincinnati and again there are the three figures in both the infobox and the lead. This same model is common around the world, just the names vary, and it makes sense to me to keep the same format for all similar areas – it makes comparisons easier for one thing. Martin of Sheffield (talk) 15:10, 9 February 2017 (UTC)

Template suggestion: Refer to living person with indirect microbiographical data

(Transplanted from Wikipedia_talk:Editor_assistance/Requests at the suggestion of TransporterMan (TALK) )


Many articles that refer to people often include year of birth and death or for living persons, year of birth in parentheses. As a software and database engineer from the DRY school of thought, Updating all these references strikes me as very inefficient when someone passes away. Additionally, many notable people change the name they are known by (i.e. the artist formerly, then once again known as Prince), their primary "descriptive noun" (a notable "author" could become best known as a notable "vocalist", for instance), or even their gender, one or more times in their career. It seems to me that often repeated details like this should not be repeated throughout Wikipedia when the person is mentioned (and linked to). It seems to make more sense to have a template that fetches these details from the notable person's wikipedia article and includes them inline.

What this could look like

On the notable person's page: (this is just an idea)

'''{{define person name|Eleanor_Parke_Custis_Lewis|first=Eleanor|last= Lewis|middles=Parke|maiden=Custis|nick=Nelly|render=inline maiden,no nick}}''' ({{define person period lived|Eleanor_Parke_Custis_Lewis|born= March 31, 1779|died=July 15, 1852|render=dates}) known as '''{{reference person name|Eleanor_Parke_Custis_Lewis|render=nick}}''', was {{define person primary noun|Eleanor_Parke_Custis_Lewis|the granddaughter of [[Martha Washington]]|render}}

could render as:

Eleanor Parke Custis Lewis (March 31, 1779 – July 15, 1852), known as Nelly, was the granddaughter of Martha Washington

While another page may refer to Mrs. Lewis as:

'''Acme Bologna Corporation''' was founded by {{reference person name|Eleanor_Parke_Custis_Lewis|render=first last}}''' ({{define person period lived|Eleanor_Parke_Custis_Lewis|render=years}}), {{reference person primary noun|Eleanor_Parke_Custis_Lewis}} on January 2, 1834 when {{reference person name|Eleanor_Parke_Custis_Lewis|render=last,no link}} failed to find a satisfactory maker of [[Bologna_sausage|bologna]].

which could render as:

Acme Bologna Corporation was founded by Eleanor Lewis (1779-1852), the granddaughter of Martha Washington, on January 2, 1834 when Lewis failed to find a satisfactory maker of bologna.

(my apologies to the deceased, if she in anyway disliked bologna or corporations. Again... just an example)

  • I acknowledge that gender is so ingrained in how we speak, and is changed so infrequently (per capita) to make templates for gender pronouns cumbersome and practically useless. I was using it as an example.
  • I am also aware that special care must be taken when a person's name changes, as the name of the page needs to be updated too, along with probably adding a redirect from the old page, though I suspect this could be automated too.

This is just an idea I thought might be worth discussing. One (of many I'm sure) place I saw this may be helpful was List_of_people_who_have_won_Academy,_Emmy,_Grammy,_and_Tony_Awards.

Linux_dr 6:33, 10 Febuary 2017 (UTC)

Could this somehow work with/retrieve from Wikidata? The execution in the person's biography example seems cluttered, and at least some of this information (if not all/more) is currently stored in Wikidata anyway (example: Tchaikovsky). - Purplewowies (talk) 06:59, 10 February 2017 (UTC)
Sounds totally reasonable to me. My concern is for there to be one authoritative source for this data, that all other bio references draw from. If it's already in WikiData, then great! Any suggestions getting biographical pages to use this data? -Linux_dr 8:30, 24 Febuary 2017 (UTC)

Improved Spam blacklist: options to warn only, apply to new users only

Having seen this recent request to use the edit filter to warn users to not add urls to some sources that were determined as unreliable by consensus, I was wondering if we couldn't make a request to implement a more general system to warn users inserting some URLs: a spam greylist (that would warn, but subsequently allow the addition on confirming, as an edit filter warn). It would also log the attempts (restricted to admins, as the current spam blacklist log). It would be maintained at MediaWiki:Spam-greylist similarly to MediaWiki:Spam-blacklist (EDIT: or by adding options, as the MediaWiki:Titleblacklist does). The advantages, overall and over using an abuse filter, are as follows:

  • it's likely to have many uses in the future, it would provide more flexibility overall: it wouldn't be all or nothing as with only a spam blacklist
  • it could be done more efficiently than with an edit filter, and wouldn't use up the condition limit
  • a huge list of urls compromises readability in the edit filter editor
  • making addition/removal requests isn't as straightforward in the edit filter.

Cenarium (talk) 18:15, 9 February 2017 (UTC)

That is one of the uses of User:XLinkBot. Another implementation has been suggested in a long, long overdue rewrite of the extension, to have it operate more like a lightweight, specialised EditFilter. No-one has ever done this, does not have WMF/developer interest ... </frust>. --Dirk Beetstra T C 18:35, 9 February 2017 (UTC)
I may be interested in developing this myself or reviewing patches. Either way, we need to know if the community would like this specific proposal implemented. The way I first suggested it, or by adding an option like <warnonly> next to items in the spamblacklist, which may be better. But indeed I agree the extension needs a rewrite, such as better warning messages (having the possibility to customize the message for a particular entry). And we could also have an <autoconfirmed> option to indicate an entry should be applied to IPs/new users only. Cenarium (talk) 18:54, 10 February 2017 (UTC)
See T6459 and T157826. --Dirk Beetstra T C 05:41, 11 February 2017 (UTC)
I would prefer MediaWiki:Spam-greylist over adding options to the spam blacklist. I would like to see a list for pure spam or links using techniques we consider to be black hat for external consumption. MER-C 05:49, 11 February 2017 (UTC)
The greylist idea is a more technical form of XLinkBot. As long as it logs it is fine, people tend to ignore.
What I basically have suggested before is to take the current EditFilter, rip out the interpretation part completely, and replace it with a mechanism that does nothing else that match a regex against the added external links. That should be rather easy to implement, and much lighter than the current EditFilter (though likely heavier than the current blacklist tests). Filters already have the log only/warn/throttle/deny possibilities and possibility of custom warnings. Moreover, discussion and explanation could be on the filter page, and when an editor triggers a blocking filter they could be directed immediately to the correct discussion.
If one wants to fancy it up, it can have selections for confirmed levels (url's can only be added by confirmed, extended confirmed, admin only or nobody), built in whitelisting (second box) or even per-page possibilities. --Dirk Beetstra T C 10:24, 11 February 2017 (UTC)

Separating viewing deleted pages into it's own right

Yes, I know it's a perennial proposal with all the polls failing. I thought maybe I could explore the topic from a different angle that I've seen discussed. Essentially, I would like to view the content of deleted pages and have it "broken apart" from admins. This is my first proposal, so perhaps this will be a learning experience for me instead of a historical dead end.

My motivation is simple: I only have rollback and I help out in IRC. An often question I'm asked it "Why was my page deleted?" I can give a general answer (whatever the comment contained) but can't help with any specifics. For instance, the inability to mention a non-credible source they used. I tend to help late at night, so if there's an admin around, I get it as a pastebin URL, and to see it formatted, I paste it in my sandbox and save it. Needless to say, this very inefficient and at times detrimental to some admin's sleep health.

To address a few past concerns:

  • I have no interest in restoring the page or any section of it.
  • Truthfully, I'm even okay with just having this for pages that failed AfC.
  • Entirely agree it shouldn't be a public link, and should require a "viewdeclinedpages" right, same process as rollback.

As was mentioned on this failed proposal, legal chimed in with valid concerns and mentioned the adverse effects for OTRS. I respect that, and again, I'm a bit of a novice regarding this, but isn't that what OS/revdel is for? I don't think anyone is asking this proposed right to have any visibility into those. There's been some talk of a check-box if it's BLP or Office during deletion, I see that as a bit too complicated for what I'm proposing. Overall, I don't see any harm in allowing vetted users to see the content of a deleted page, anything that "isn't for our eyes" seems it should be OS'd anyway. I believe the current "process" is simply another thing to bother the admins from the more pressing things they focus on. I'd love your feedback and thanks in advance for your patience in this rehashed debate. Drewmutt (^ᴥ^) talk 00:53, 7 February 2017 (UTC)

OS and revdel are not for this. For one thing, the capacity of admins and oversighters is limited. Having to vet each deleted revision for the possibility that it contains content that should be restricted access is a big effort. Jo-Jo Eumerus (talk, contributions) 09:54, 7 February 2017 (UTC)
This just lands on the perennial pile. It's perennial because it's so obviously handy to have, and so obviously harmless in almost all cases. But it's an all-or-nothing deal. Deleted pages are an unsorted unmaintained trashheap. It grants access to copyright violations, which we can't do lightly for legal reasons. It also grants access to the entire range of the worst we delete for any reason, including any sensitive information that slipped by without being oversighted. The community is too careful to buy the "all" side of that all-or-nothing deal. Alsee (talk) 23:30, 8 February 2017 (UTC)
  • I could see it being viable only if admins were able to mark a deleted page after review as "safe for viewing" (by users with a specific permission). It's possible to change the visibility of deleted revisions so some of the revisions being bad isn't an issue, they can be hidden then the deleted page marked safe for view. But there are two hurdles. The first one is mentioned by Jo-Jo Eumerus, it takes admin effort to ensure the deleted page is viewable, although maybe for newly deleted pages it won't be an issue since the admin would have already reviewed the page in the process of making the delete decision (and could then immediately mark it as viewable). The second one is technical: it would need development, either asking the WMF to develop it directly but I wouldn't count on that, or convincing a volunteer developer, but said developer would want to be certain first that it would be accepted by both the community and WMF. Cenarium (talk) 04:22, 9 February 2017 (UTC)
  • I believe the Foundation has said that it will not aloow us to grant the ability to view deleted revisions to anyone who has not passed RFA or an equivalent process. If we have to do that, it's a zero-sum game -vs- just becoming an admin. Beeblebrox (talk) 04:41, 9 February 2017 (UTC)

Thank you guys so much for your feedback. Like I said, I'm still a bit new so thanks for your sage insight. In discussing this more with some of the other admins, I've come to agree with the consensus. I still feel there's a need for vetted volunteers to view deleted content without the help of an admin, so what I'm gathering is that deletion is too "wide" of a tool. Articles can be deleted for a number of reasons, and I get that some are more sensitive than others. As an admin do you think it would, as Cenarium suggested, be feasible (from a "workload" perspective) to have a "safe for viewing" box? I ask out of ignorance because I don't know if the entirety of articles are scanned before deletions (ensuring there is no sensitive data). Drewmutt (^ᴥ^) talk 05:05, 10 February 2017 (UTC)

  • This is one that is absolutely, positively, never going to happen, for lots of fairly WP:BEANS-y legal reasons. You linked to a previous discussion on the topic, take note of Wikipedia's legal counsel's words in that discussion, in part: "Allowing non-administrator users to have access to deleted pages would vastly increase the frequency and volume of legal complaints. (It could have even worse consequences than that in the long term, up to and including corrective legislation by Congress, which would be a disaster.) It is difficult to overstate how much legal and practical difficulty this would cause the Foundation. To be frank, community adoption of such a disastrous policy would create an actual emergency that would likely require Board intervention." That pretty decisively states why neither this nor any variant of it is ever going to happen, ever. Andrew Lenahan - Starblind 08:02, 10 February 2017 (UTC)
  • "Very late at night" depends on what time-zone you are on. There are admins from other time-zones, or at least I hope there are! All the best: Rich Farmbrough, 23:50, 13 February 2017 (UTC).

Diffusing year categories for births and deaths

I'm proposing that diffuse the categories in Category:Deaths by year and Category:Births by year (i.e. Category:2000 deaths, Category:2000 births) into more general locations such as continents, countries, or maybe even states. Currently, many of these categories are unwieldy, containing thousands of biographical entries. By diffusing these categories, we could have something like Category:2000 deaths in Europe and so forth, presenting readers with links that should be more closely related to the article they were reading. FallingGravity 04:17, 1 February 2017 (UTC)

That would make it a lot harder to use. Now it is very easy to know whether to add 2000 deaths, but if it is subcatted, then you would have to know if it was 2000 deaths in France, or 2000 deaths in Normandy or whatever level of subsetting it is. Graeme Bartlett (talk) 09:56, 5 February 2017 (UTC)
  • We could, at the very least, split it between male deaths and female deaths. It is usually a trivial matter to know the gender of the subject. bd2412 T 15:31, 5 February 2017 (UTC)
"2000 deaths in Normandy" (if we even wanted to get this specific) would be a subcategory of "2000 deaths in France", which would be a subcategory of "2000 deaths in Europe" and so forth. All you really need to know is the person's birth and death places. FallingGravity 18:07, 5 February 2017 (UTC)
My point is that the person doing the categorisation will not likely know that level of detail about the category structure. Perhaps hotcat could help by listing subcats in a dropdown when you pick a supercat. Graeme Bartlett (talk) 01:50, 7 February 2017 (UTC)
There are some other issues. Breakdowns by country, for instance, become more involved when considering the mutations of countries through the centuries. And would we be prefer to know that the death happened in a certain place; or that there was the death of a citizen of a certain country? Gender is more easy to use; not least wikidata has gender for 1.4M en.wiki biographies, but we only remove 16.83% of entries from a category by moving females to a new category. Meanwhile, is an alpha-ordered list of 5k biographies really that unwieldy? Is it more unwieldy than the same cat decanted into 200 sub-categories? --Tagishsimon (talk) 02:17, 7 February 2017 (UTC)
For edge cases, these categories could always be partially diffused per WP:DIFFUSE: some members are placed in subcategories, while others remain in the main category. Regarding your concerns about categorizing place vs. citizenry, my idea was to go with place, because the places of birth and death are usually readily available in the article's infobox, text, and Wikidata item. Are diffused categories worse than undiffused categories? I guess it depends on how the reader uses them. FallingGravity 05:02, 9 February 2017 (UTC)
They can be diffused by month and day, for articles where those are known.
—Wavelength (talk) 23:41, 13 February 2017 (UTC)
What about those self-identified as neither gender, like David Burgess (lawyer)? --George Ho (talk) 23:52, 13 February 2017 (UTC)
Gender is unnecessary for diffusion by month and day.
—Wavelength (talk) 23:54, 13 February 2017 (UTC)
Oh... I overlooked the "month and day" suggestion. I suppose we can do the month diffusion, but the day diffusion is unnecessary. However, what about articles starting with "Deaths in..."? George Ho (talk) 00:07, 14 February 2017 (UTC)

Responses

Autoconfirmed article creation proposal

Closed as withdrawn by proposer by their special request. Kudpung กุดผึ้ง (talk) 17:37, 19 February 2017 (UTC)

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

Proposal

Should the creation of articles directly into the mainspace be restricted to autoconfirmed users for a trial period of six months?

This would be implemented by a Phabricator software request should consensus be found.

Technicalities

I respect that many editors feel that this matter needs more discussion however I think that it is of paramount importance that this issue is addressed quickly to prevent the exponential growth of the backlog which will soon become unmanageable.

Due to the expedient nature of this request, the technicalities of the proposal e.g. templates will be the same as those used in the original ACTRIAL request.

Considerations

  1. The huge backlog at New Pages Feed which was mentioned in the latest newsletter.
  2. The corresponding increase in deletion of New Pages.
  3. The rise in "one page wonder" editors.

Effects

  1. Reduction of the backlog would facilitated for New Page Patrollers.
  2. Editor retention as page creators are likely to be put off by the deletion of their pages.
  3. A decrease in the amount of low-quality content coming in to Wikipedia.

Please contribute in the appropriate sections below. DrStrauss talk 13:41, 19 February 2017 (UTC)

Support

  1. Support While I support, per many of the reasons given in this RfC and in the prior discussion, I have my doubts as to whether anything has changed in regards to whether the Wikimedia Foundation will agree to implement it. Gluons12 ☢|☕ 14:24, 19 February 2017 (UTC).
  2. Support. Iazyges Consermonor Opus meum 14:36, 19 February 2017 (UTC)
  3. Support: This is needed to prevent vamdals and spammers from creating bad articles. KGirlTrucker81 huh? what I've been doing 16:10, 19 February 2017 (UTC)
  4. Strong Support Wikipedia absolutely needs this as soon as possible. Qaei ☎ 16:16, 19 February 2017 (UTC)
  5. Support I don't know if the WMF would agree with this, but this would be very helpful. ThePlatypusofDoom (talk) 16:59, 19 February 2017 (UTC)

Oppose

Srongly oppose this RfC which has been launched by a very new, inexperienced user despite multiple advice by several experienced editors in various places as ill though out, a lack of understanding of the complex issues at stake, no background links and unsigned, all while other discussions are taking place as to whether this RfC or other actions should fist be considered. Kudpung กุดผึ้ง (talk) 17:24, 19 February 2017 (UTC)

  • Strong Oppose As I have expressed in the past, I think this proposal is premature and should be shut down until a consensus exists to hold it. TonyBallioni (talk) 17:30, 19 February 2017 (UTC)
  • oppose. I concur with the reasons this was opposed previously. Anything like this would do serious harm to editor engagement, and cut off one valuable source of new articles. Attracting new editors is hard enough already, we do not need to make it harder by putting arbitrary barriers in their way.--JohnBlackburnewordsdeeds 10:19, 21 February 2017 (UTC)

Comment

@Joshualouie711: yes that would be the case. DrStrauss talk 17:06, 19 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New WP:guideline ?

CLOSED
As there is no clearly defined proposal, and no real support forthcoming, I am closing this. Anyone is free to express this idea in an essay without prior discussion. Beeblebrox (talk) 20:20, 23 February 2017 (UTC)

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

First of all - I have not experienced anything of this at English Wikipedia. But well on certain other Wikipedias does a phenomenon , which I would like to call WP: Run home to daddy, exist at the talk-pages. This new guideline refers mainly to talk-pages, and to contributors who are about to loose an argumentation, but then calls for (and receives) help by an administrator, even though there is absolutely nothing in our pillars and guidelines to complain about. I would like to call this new guideline, as already mentioned. And the the guideline itself should just state that lost arguments (based on sources and logical facts) are not matters to bring to an administrator, usually. It's different if things get personal, and is not what I mean. I just assume - if a such guideline is imposed here, it will also be imposed at all other Wikipedias. This problem exist at Wikipedias with relatively few contributors and with some "lording admins". Wikipedias with a poor Article Depth (see https://meta.wikimedia.org/wiki/Wikipedia_article_depth ) are usually the ones which might benefit from a new guideline such as this. Or a similar one. Boeing720 (talk) 10:37, 21 February 2017 (UTC)

Hi, Boeing720. If you like, would you move the whole thread to WP:VPIL. You can incubate your idea there and wait for responses. By the way, there are other existing guidelines seen at Wikipedia:List of guidelines and Wikipedia:List of policies. --George Ho (talk) 10:42, 21 February 2017 (UTC)
Never heard of the idea lab, thanks. This is a main reason why many 'guidelines' here are counter-intuitive and counter-productive, there are so many venues and pages and nooks and crannies where guidelines are being discussed, baked, and finagled that only bots and lawyers can keep track of them. Some editors then cite those guidelines to stop, delete, or curtail good ideas, claim consensus justification, and before you know it trying to overturn these now "existing" policies takes an overwhelming consensus just to move something back to where it makes sense. I don't mean your WP:HOMETODADDY idea, just ranting about bumping into these flimsy but sustained roadblocks from time to time. Randy Kryn 12:53, 21 February 2017 (UTC)
Note the different language Wikipedias set their own policies and guidelines, so what happens at English Wikipedia will not affect the others. The behaviour you describe is similar to forum shopping, sometimes referred to as WP:OTHERPARENT. isaacl (talk) 13:36, 21 February 2017 (UTC)
I see no reason to have this guideline because WP:ADMIN is already quite clear that administrators have no more power or say than any other editor when it comes to content disputes. An administrator using their tools to enforce their views in a content dispute is enough (or nearly enough, if a one-time thing) for desysopping for cause, in my opinion, and the editor who tried to reach out to an admin for "back-up" could be sanctioned under WP:CANVASS. Our existing policies and guidelines seem to have this situation pretty well-covered. ~ Rob13Talk 15:21, 21 February 2017 (UTC)
If there is no certainty of other Wikipedias to adapt the guideline I suggested, then you're absolutely correct, Rob. Thank you all for your comments. Boeing720 (talk) 15:45, 21 February 2017 (UTC) And thanks, George Ho for the advice about WP:VPIL. I have never seen that page before. Boeing720 (talk) 15:50, 21 February 2017 (UTC)
You're welcome. Also, you can go to either WP:help desk or WP:teahouse. George Ho (talk) 16:00, 21 February 2017 (UTC)
You could write an essay about it. WP:BRD, WP:TE, and many other popular pages are essays. Writing an essay does not require pre-approval; any editor can do it. WhatamIdoing (talk) 18:34, 21 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Create draft namespace redirects

Sorry for not having edited this page since 4 January 2016. I think we should have a bot create redirects from "Draft:A" to "A" for every article "A". A previous discussion at Wikipedia:Village pump (proposals)/Archive 135#Draft Namespace Redirects suggested that such redirects that already exist should not be deleted. What do you think for the creation of draft namespace redirects? GeoffreyT2000 (talk, contribs) 23:22, 14 February 2017 (UTC)

Why? Jbh Talk 00:01, 15 February 2017 (UTC)
I must be missing something, because on its face, it sounds like a horrendous idea. Seriously? You are proposing over five million new redirects? --S Philbrick(Talk) 00:13, 15 February 2017 (UTC)
Terrible idea. Kudpung กุดผึ้ง (talk) 00:16, 15 February 2017 (UTC)
This would be a terrible waste of server resources. Instead, we could ask for a MediaWiki change so that if you go to Draft:A and an article A exists, you're redirected to article A automagically without a redirect actually existing. Now that would be a welcome change. ~ Rob13Talk 00:23, 15 February 2017 (UTC)
A bot that compares Draft space names against mainspace names and leaves a message on the creator's talk page (or draft talk) if there is a match. -- GreenC 03:17, 15 February 2017 (UTC)
When you visit a redlink (to create a new article) you are displayed a message if a corresponding draft exists (see e.g. Seoul Saturday Soccer League). This could be made to work works the other way as well: when you go to Draft:Apple, you'd be notified that Apple already exists. (I have some reservations about this though: it just confuses newbies who have no idea how naming conventions and disambiguation works.) – Finnusertop (talk ⋅ contribs) 05:15, 15 February 2017 (UTC)
@Finnusertop: When you go to Draft:Apple, you see Note: There is a Wikipedia article named Apple. — JJMC89 (T·C) 05:00, 16 February 2017 (UTC)
You are right, just not as prominent as the other way around. – Finnusertop (talk ⋅ contribs) 07:49, 16 February 2017 (UTC)

Allow users to protect user page

Users should be allowed to protect their own user page — Preceding unsigned comment added by Lotofnot (talk • contribs) 05:00, 15 February 2017 (UTC)

Already allowed, if the conditions at WP:PROTECTION are met (ie. persistent vandalism. Pages are not protected pre-emptively). Upon request at Wikipedia:Requests for page protection. – Finnusertop (talk ⋅ contribs) 05:17, 15 February 2017 (UTC)
Since admins routinely grant this if you just ask, I don't see any need for this. Beeblebrox (talk) 05:21, 15 February 2017 (UTC)
This would be too open for abuse if it were allowed by the software. Being done almost automaticly by admins reduces the risks here. עוד מישהו Od Mishehu 11:56, 15 February 2017 (UTC)
Please also note, base user pages are already protected against editing by unregistered and very new editors - see WP:UPROT. — xaosflux Talk 04:45, 16 February 2017 (UTC)
Also a spammer could spam in his userpage easily if protected. Nah, it'll lead to the caos on the long distance. For me it's a no.Justmeonhere (talk) 20:04, 16 February 2017 (UTC)

Elections for New Page Patrol/New Page Review coordinators

Voting for coordinators has now begun HERE and will continue through/to 23:59 UTC Monday 06 March. New Page Review and its Page Curation is a core MediaWiki extension. The process of expertly vetting all new articles is a critical issue needing a couple of 'go to' people. The coordinators will do their best for for the advancement of the improvement of NPP and generally keep tracks on the development of those things. Coordinators have no additional or special user benefits, but they will try to keep discussions in the right places and advance negotiations with the WMF.
Please be sure to vote. Any registered, confirmed editor can vote. Nominations are now closed.Kudpung กุดผึ้ง (talk) 02:02, 22 February 2017 (UTC)

mandatory tagging of all refdesk pages and some refdesk questions

General refdesk disclaimer tag

Should the following tag, or something like it, be added to all reference desk pages and edit notices?

Please be aware of the following
  • The Wikipedia Reference Desk is not part of the encyclopedia. Rules that apply in articles such as always providing reliable sources do not apply to answers given here.
  • None of the users giving answers can be assumed to be actual experts on any topic, and no advice should be taken as representing a professional opinion on the subject.
  • The rule that Wikipedia is not a forum or chat room does not really apply here either. You may find that instead of one simple answer you get a wide range of answers, some of which may be speculative or contradictory.

(Please keep in mind that this is just a rough draft, and not even in template namespace, this is just to give the general idea of what such a template might be, formatting and specific language can always be adjusted later.)

Discussion of General refdesk disclaimer tag

What about a smaller edit notice instead, similar to the one on this page? Instead of a big red box, what about a simple information box with the blue "i" icon providing links to Wikipedia's disclaimers, and other information pages regarding the reference desks? Narutolovehinata5 tccsdnew 10:29, 10 February 2017 (UTC)

This is exactly whay the question has the phrase "or something like it" and there is a note under the template reminding versions that it is a rough draft. The formatting is not the point, whether we should do something like this at all is. Beeblebrox (talk) 19:24, 10 February 2017 (UTC)
  • Oppose. This is 100% the OPPOSITE of what the disclaimer should say. Providing reliable sources should be the main function of the ref desk. I'd support a disclaimer that literally said the exact opposite of this one before I supported this. Hell no. --Jayron32 16:34, 10 February 2017 (UTC)
Yeah, but this isn't dictating the rules, it is reflecting how the refdesk actually functions. Of course they should always provide sources, but in practice it isn't done a lot of the time. Beeblebrox (talk) 19:23, 10 February 2017 (UTC)
No, the ref desk DOES function that way. There's a few people who don't get it, but by and large, it works just fine. --Jayron32 01:25, 12 February 2017 (UTC)
  • Oppose first point as per Jayron. References sometimes have to be held to a lower standard in order to provide an answer to the question, but we don't want to encourage the notion that references are not needed. ←Baseball Bugs What's up, Doc? carrots→ 17:02, 10 February 2017 (UTC)
  • The key question is who is the target for this disclaimer? If it is readers, then I think there is one key point to make: responses are the viewpoints of individual editors and do not reflect expert or consensus views. Everything else readers can infer from context. (For example, you don't have to tell readers that reliable sources are or aren't being cited; they can see for themselves.) If the intent is to dissuade other editors from wasting time trying to change the existing environment at the Reference Desk, then I suggest having a FAQ list on the talk page. isaacl (talk) 20:54, 10 February 2017 (UTC)
It's the first one, the intent is not to discourage anyone but to inform them that they are in an area that does not work like the rest of Wikiepdia. Beeblebrox (talk) 20:47, 15 February 2017 (UTC)
In that case, then I believe a single sentence with the message I stated is enough. The critical difference is whereas Wikipedia articles are copy edited to, in theory, converge towards a consensus view, individual responses at the reference desk are not. isaacl (talk) 16:52, 17 February 2017 (UTC)
  • Oppose: The way it appears, the notice gives editors far too much leeway in regards to crucial Wikipedia policies, especially when it comes to reliable sources. Such a policy should never be disregarded on Wikipedia. Ever. Blurp92 (talk) 05:58, 17 February 2017 (UTC)
That's just the way the refdesk works, and the regulars there are extremely resistant to any changes, that's rather the whole point here. Beeblebrox (talk) 06:41, 17 February 2017 (UTC)
  • Oppose Overkill, to say the least. All we need is a single line:
"Answers may not agree with each other. They are provided by various editors with various resources and opinions, and are not official opinions of Wikipedia."
This would handle everything without going into the "discussion forum" siding. Collect (talk) 14:48, 21 February 2017 (UTC)

Medical/legal questions tag

Should the following tag, or something like it be added to all questions that could be construed as requesting medical or legal advice? Note that this does not disallow the question, it merely aims to clarify the relative weight that any answers should be given.

Wikipedia does not give medical or legal advice

Wikipedia is an encyclopedia anyone can edit. As a result, medical and legal information on Wikipedia is not guaranteed to be true, correct, precise, or up-to-date! Wikipedia is not a substitute for a doctor, medical professional, a lawyer or a solicitor. None of the volunteers who write articles, maintain the systems or assist users can take responsibility for medical or legal advice, and the same applies for the Wikimedia Foundation.

If you need medical assistance, please call your national emergency telephone number, or contact a medical professional (for instance, a qualified doctor/physician, nurse, pharmacist/chemist, and so on) for advice. If you need legal advice, contact a lawyer or your local Legal aid provider. Nothing on Wikipedia.org or included as part of any project of Wikimedia Foundation Inc., should be construed as an attempt to offer or render a medical or legal opinion or otherwise engage in the practice of medicine or law.

Please see Wikipedia:Medical disclaimer and/or Wikipedia:Legal disclaimer for more information.

(Please keep in mind that this is just a rough draft, and not even in template namespace, this is just to give the general idea of what such a template might be, formatting and specific language can always be adjusted later.)

Discussion of Mediacl/legal questions tag

  • support as proposer. This will have no effect whatsoever on any users ability ask such a question, or to go ahead and provide answers to such questions, the only purpose is to curtail infighting among refdesk regulars on these subjects and clarify the relative weight that should be given to any such questions. Beeblebrox (talk) 00:23, 10 February 2017 (UTC)
  • Oppose. If you love guidelines and policies so much, might I suggest going over WP:POINT? Seldom have I seen a "point" made with as big an exclamation as this! And in general, the fact that most Refdesk regulars believe that medical and legal questions are allowable is because asking the question or covering the topic is not advice. It is not a medical diagnosis or treatment to say a black widow bite is poisonous, or even to post sources claiming it's not that poisonous. Nor to say that cigarettes are bad, or even to post about alleged health benefits to be had from nicotine. And the open-ended nature of discussion on the Refdesk matches the open-ended nature of discussion on countless other pages on Wikipedia - the Village Pumps, Jimbo's page, the WikiProjects and so on. In other words, your policy objections have been heard and WP:CONSENSUS is against them. Wnt (talk) 01:30, 10 February 2017 (UTC)
You seem to be reading a lot into this that just isn't there. I am not making a policy objection, I am saying let's go ahead and accept the fact that the refdesk does not follow certain policies, allow that continue as it has for years, but just be sure to let people know the difference. You seem to take any attempt to say anything at all about the refdesk as personal affront and respond rather dramatically, I would again suggest (as I did way back during the 2013 discussion of actual reforms of the refdesk) that if you tone it down others might be more receptive to what you have to say. And I went out of my way to make it clear that these templates are rough drafts and the formatting is not the point of the discussion. They are both based off of {{No medical advice}} as a starting point, I would have no objection to something less obnoxious. Beeblebrox (talk) 02:18, 10 February 2017 (UTC)
@Beeblebrox: I accept the fact that you think the Refdesk doesn't follow certain policies/guidelines that it actually does, and in some cases you think others that don't apply to it ought to. But are you going to put a disclaimer on every Talk: page that it doesn't follow article guidelines, a disclaimer on every ITN item that it doesn't follow FAC guidelines? Policies that don't apply ... simply don't apply. Wnt (talk) 14:16, 10 February 2017 (UTC)
  • Oppose in current size. I could see a thin (1em) banner, with "See (linked) disclaimer for (subject)" on Medicine. -- Iazyges Consermonor Opus meum 04:11, 10 February 2017 (UTC)
  • Weak support: Not sure how to "categorize" my !vote, but my vote is per Iazyges. I agree with the idea, not necessarily with the presented execution. - Purplewowies (talk) 06:45, 10 February 2017 (UTC)
  • Oppose Please print as a banner and go demonstrate at an education fair instead. —TheDJ (talk • contribs) 09:39, 10 February 2017 (UTC)
  • Support in principle though it could be smaller. ←Baseball Bugs What's up, Doc? carrots→ 16:20, 10 February 2017 (UTC)
  • Support Medical/legal advice should not be given by anyone anywhere on Wikipedia, and such a prohibition needs to be made more clear. --Jayron32 16:35, 10 February 2017 (UTC)
  • Oppose this monster, although it might be tolerable to have a small "Wikipedia does not give medical or legal advice", with a dedicated page link or with links to existing legal/medical disclaimers. But jeeze, do we really need crap up pages even with just that much?
    Warning: Hair driers are an electrical appliance. Do not use if electric cord is damaged, do not use while bathing, do not insert into mouth or anus, do not use if hair is wet.
    Caution: The warning above above was written by someone with zero legal qualifications. If the list were compiled by genuine lawyers it would be 10x longer and twice as stupid. Alsee (talk) 19:17, 10 February 2017 (UTC)
Please note that the actual question is if we should use this tag or something like it and there is a note beneath it stating that it is a rough draft. The purpose of this discussion is to decide if we should use a tag, the formatting is 100% open to be changed to whatever is more agreeable, I based both of these off of {{No medical advice}} just as a starting point. Beeblebrox (talk) 19:28, 10 February 2017 (UTC)
I did note that. A small notice would be "tolerable" and "crap up the page". You can count that as somewhere in the range of "neutral" to "passive oppose"... on the condition that the monster is trimmed 80% or more in square inches. Alsee (talk) 03:14, 11 February 2017 (UTC)
  • Oppose as a question tag, support as an edit notice. Maybe something smaller and much less obtrusive, albeit still noticeable, for individual questions. Ks0stm (T•C•G•E) 19:39, 10 February 2017 (UTC)
  • Oppose per current size and content. I am concerned that both the banner and the explanation of the banner contradict themselves. The banner directly states that no medical / legal advice should be given, then goes on to stay that the advice given should be taken with a grain of salt (as the proposer states"This will have no effect whatsoever on any users ability ask such a question, or to go ahead and provide answers to such questions") In additionI do not think a large warning template designed "only to curtail infighting amongst regulars" is an effective approach. I suggest developing a policy or guideline statement with consensus.--Tom (LT) (talk) 03:34, 11 February 2017 (UTC)
  • Oppose the current form and content (If I'm allowed as an IP User), though some milder advisory would be in order.
Overall, I would prefer that we avoid just adding even more advisory notices to the heads of the RefDesk pages – it would only make it even more likely that they'll be ignored by OPs. ObPersonal: I experienced a similar effect at an Atomic Weapons Establishment some years ago, where piling on ever more overlapping safety regulations led to an increase in accidents and near misses. The more effective approach was to prune them back to the economical and clear minimum required: in our case that minimum should, I agree, contain the fact that the answers are provided by quasi-librarians, not topic experts, and are not endorsed by Wikipedia as an entity.
I think also there is an as-yet-unexamined problem with the "no medical or legal advice" policy. People are naturally curious about physiological topics, and sometimes that curiosity is prompted by an observation of a likely harmless phenomenon on or in their own body, which they have no actual concern about, and for which the advice "consult your physician" would be egregious – allowable but expensive in some countries (such as the USA), cheap/free but arousing of official ire in others (such as the UK).
However, I see many queries which are actually seeking physiological/medical (or legal) information being hatted or removed on the grounds of our not giving medical, etc., advice. Sometimes this might have been avoided if the query had been, quite legitimately, worded in a less self-referential way (younger people tend to personalise queries even when not about themselves – "You know that thing where you get a . . . ."), sometimes even seemingly legitimate queries for non-personally relevant information are hatted or removed by what seem to me to be over-zealous editors, and the standards seem not to be consistently applied even by the same individuals.
I do however agree that some sloppy and detrimental practices have been allowed to proliferate on the RefDesks, some but not all attributable to a few particular Editors, (and of some of which I myself am guilty); I would support more rigorous application of whatever (laws rules) guidelines the community can come to agreement on. {The poster formerly known as 87.81.230.195} 90.203.118.169 (talk) 22:20, 11 February 2017 (UTC)
  • Support - the tag is a bit big but I support it in principle. DrStrauss talk 08:22, 13 February 2017 (UTC)
  • Support - If Beeblebrox thinks a tag or something is necessary, then it most likely is. However, in its present suggested form it's too wordy. It's been proven time and time again that Internet users DO NOT READ THE INSTRUCTIONS. Classic examples are the edit notices here (yes, go on click it for once), where up to three people a week blatantly disregard it, and on the RfA transclusion page; with the best will in the world such instructions rarely work but we we have to do something. Anyone who has ever run an online store will also know how frustrating it is when 30 people a day call to ask a price when the prices are staring them in the face - and unlike Wikipedia, online store software is designed by marketing professionals. Beeblebrox is following our Wikipedia tradition of verbosity in respect of that tradition, where a short, sharp headline (something he knows about) would suffice, such as: STOP:(Stop hand icon) Wikikipedia is an encyclopedia. We do not give legal or medical advice. If you ask, your question will probably be ignored. Kudpung กุดผึ้ง (talk) 23:19, 14 February 2017 (UTC)
  • Oppose – way too big. A hatnote just below the heading with a link to WP's medical disclaimer page would suffice. The Transhumanist 10:25, 21 February 2017 (UTC)
  • Oppose Overkill. Also note that mobile devices will end up showing some such messages as taking up a full screen :). Collect (talk) 14:50, 21 February 2017 (UTC)
  • Oppose more disclaimers are a perennial proposal, a slippery slope, and may create the risks they try to avoid. I would support creation of standard optional "We do not give advice" templates, for the purposes of rapid answering (or non-answering to be more precise) such questions. All the best: Rich Farmbrough, 11:56, 23 February 2017 (UTC).

Let's ask Microsoft to give their encyclopedias to the public domain

@Ocaasi, Nikkimaria, and Samwalton9:

According to the Funk & Wagnalls article:

After failing to purchase rights to use of the text of the Encyclopaedia Britannica and World Book Encyclopedia for its Encarta digital encyclopedia, Microsoft reluctantly used under license the text of Funk & Wagnalls encyclopedia for the first editions of their encyclopedia. This licensed text was gradually replaced over the following years with content Microsoft created itself.[1]

As long as all the Funk & Wagnalls material was replaced, that might not be a problem.

But MS owns more than just Encarta. According to the Encarta article:

In the late 1990s, Microsoft added content from Collier's Encyclopedia and New Merit Scholar's Encyclopedia from Macmillan into Encarta after purchasing them.

(The Funk & Wagnalls copyright issue would not pertain to those.)

So, let's ask them to release Encarta, Collier's, and New Merit Scholar's.

Or, if they were to donate them all to the Wikimedia foundation, maybe they could take a deduction from their taxes.

So, what's the next step? The Transhumanist 08:25, 12 February 2017 (UTC)

Don't ask them? Do we really want editors copying material from encyclopedias, even if attributed? Usually the material is unsourced and is often out of date or presents only one pov. Doug Weller talk 17:06, 15 February 2017 (UTC)
Well but OP is not asking editors to copy material from these entities. I mean you could object to any source on the basis of "well, editors are just going to copy from newspapers and magazines and books, so let's not use those as sources". You can certainly pick individual facts etc. from an encyclopedia article to meld into your Wikipedia article along with material based on other sources.
And yeah the material is unsourced (and is it even? Britannica gives sources IIRC, are you sure these other entities don't?) but I mean a lot of things are unsourced. If I look at Playbill or whatever they don't give a source. If they say a play opened on September 13 1955 I'm not like "Well, how do they know that? What's their source? I can't use this". They have a reputation for being correct about stuff like that and fixing it if it's wrong.
I mean, maybe Encarta was not rigorously fact-checked and they just wrote down stuff they they overheard on the subway or whatever, and maybe ditto Funk & Wagnalls and Collier's and New Merit Scholar's. If that's the case, fine. Is it? Or did these entities have good fact-checking operations? Herostratus (talk) 21:20, 17 February 2017 (UTC)
Next step: Look at some sample Collier's content and see if there's anything there that we don't have. All the best: Rich Farmbrough, 12:00, 23 February 2017 (UTC).

References

  1. ^ Randall E. Stross, The Microsoft Way: The Real Story of How the Company Outsmarts its Competition (Reading: Addison-Wesley, 1996), pp. 81f, 91f

Unpatrol moved pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Tracked in Phabricator
Task T159028

I present a proposal: that any time an article is moved it should lose its patrolled status, so that it is flagged for new page patrol (again, if necessary), other than page moves by editors with the page mover or autopatrolled rights, or perhaps all extendedconfirmed users.

A prolific sockpuppeting spammer has recently been discovered abusing the new pages patrol process to create promotional articles without detection. Without going into too much detail, the spammer "hijacks" a disambiguation page which has already been patrolled, replaces its content with the promotional article, moves that article to a new title carrying the patrol flag with it, then covers their tracks by replacing the {{R from move}} redirect with a redirect to one of the entries on the former dab page. This way their new page does not show up in page curation and the broken dab links aren't blatantly obvious, so this vandalism is only discovered if another user happens to be watching the page, or comes across the hijacked dab by chance. As I understand it, edit filters are ineffective because this vandalism involves a sequence of several edits, none of which are particularly easy to detect for wrongdoing in and of themselves.

For background, please see:

This activity is particularly insidious because it's more than just spamming the project: this vandal is also destroying good content in the process, in a way that's proven difficult to detect, but fairly easy to repair. It's also a pretty easy to replicate backdoor through new pages patrol, our only filter against unwanted new content. This proposal is a weak solution, but it is the only solution I can think of which would not prevent a large class of users from editing (such as restricting page moves, or some such). If someone has a better way to detect this, I'd certainly be glad to hear it. I look forward to your thoughts. Ivanvector (Talk/Edits) 14:36, 7 February 2017 (UTC)

A good technical question; I don't really know. I have always assumed that page patrol is a boolean state, and that any non-redirect article which does not have the patrolled bit set will appear in the Page Curation feed, and that therefore includes pages which have had the bit un-set for some reason. Perhaps an editor with more technical familiarity can comment. Ivanvector (Talk/Edits) 18:23, 7 February 2017 (UTC)
In core, patrol flag is assigned to an edit (we only have NP patrol but some wikis have full RC patrol, which would be unmanageable here, what we would need is something in between). In PageTriage, patrol flag is assigned to a page. Cenarium (talk) 13:51, 8 February 2017 (UTC)
Note - please see Filter 837 for any hits - this should catch removal of the disambiguation template. עוד מישהו Od Mishehu 09:53, 8 February 2017 (UTC)
  • Technical note - This is probably feasible in PageTriage (you'll need to make a bug request for it), but in core this would require the ability to patrol moves, phab:T98617 (please link the discussion there once finished). Cenarium (talk) 13:51, 8 February 2017 (UTC)
  • Support As terrible as it is to get vandals doing that, I have to admit that the hijack/page move is quite clever. However, this is a current loophole that can be plugged. Lugnuts Precious bodily fluids 18:52, 10 February 2017 (UTC)
  • Support in some form for page moves preformed by newer users. Listing these separately from brand new pages is something to consider. — Godsy (TALKCONT) 21:02, 10 February 2017 (UTC)
  • Support As Sun Tzu has said, he who defends everywhere defends nowhere. WMF needs to start investigating who these abusive accounts are and take them to court. I don't think we'll ever win this game playing defense only. Chris Troutman (talk) 22:20, 10 February 2017 (UTC)
  • Support - I think that it would be best if the usergroup that could move pages without losing their patrolled status would be admins, page movers, and users with autopatrolled rights. RileyBugzYell at me | Edits 22:25, 10 February 2017 (UTC)
  • Support - Circumventing new pages patrol through some kind of page move has been a persistent problem with black-hat paid editors. It is time to close the loophole. I suggest having an option to view these unpatrolled revisions separately from new page creations. Vetting an entirely new article takes quite some time since all the content needs to be checked for copyvios, notability, etc. On the other hand, most page moves involve only superficial alterations to the article, and new page patrollers can check very quickly whether a move was a page hijacking or not. Therefore, it makes sense for Special:NewPages to have an option along the lines of "show page moves only." Altamel (talk) 23:44, 10 February 2017 (UTC)
  • Support Back when I first started doing RC patrol there was a very well known, very active WP:LTA vandal who moved literally thousands of pages to objectionable titles, but patrolling was a brand new thing then and not well known. This ole timer does ramble on though... Anyway, this is obviously a good idea. Beeblebrox (talk) 00:54, 11 February 2017 (UTC)
  • Support per nom and all per above: Problematic new pages moved by socks, paid editors, LTAs should still be checked for inclusion standards. KGirlTrucker81 huh? what I've been doing 03:16, 11 February 2017 (UTC)
  • Support per nom. If possible, it may decrease the load on NPP to apply this only to pages created in a certain time period (eg created in the last 6, 12 months) --Tom (LT) (talk) 03:28, 11 February 2017 (UTC)
  • Support per nom. As an aside, don't our regular antivandalism tools (e.g. Huggle) already handle page moves? MER-C 05:51, 11 February 2017 (UTC)
  • Support Obvious need for this. Having a sort option for Special:NewPages would also be a good idea, as Altamel suggested. --AntiCompositeNumber (Leave a message) 14:16, 11 February 2017 (UTC)
Note: I've notified WT:NPR and WT:NPPAFC of this proposal. – Joe (talk) 15:26, 11 February 2017 (UTC)
  • Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? – Joe (talk) 15:32, 11 February 2017 (UTC)
  • Oppose Support per further discussions below This is not really a good solution for the problem. Simply removing the patrol bit places the page in a queue with about 16,000 other pages. If this type of vandalism is a major problem then there needs to be a seperate queue which will allow for quicker inspection as well as to give the reviewer an idea that they are looking at an old moved page that may have been hijacked rather than a new creation. Finally, removing the patrolled flag, I think, reinstates the NOINDEX magic word. It may get removed by virtue of the page being over 90 days old but I do not know.

    Get the foundation to give development time the the Curration Tool, add a filter by recently moved and we're good to go. If not this will not solve the problem. I would support this if it were something other than just 'unpatroll moved pages'. Jbh Talk 15:33, 11 February 2017 (UTC) Last edited: 15:27, 15 February 2017 (UTC)

    • This won't noindex the page, which isn't possible after a page is older than 30 days anyway, see the updated documentation. I've suggested using a separate queue below. Cenarium (talk) 16:36, 11 February 2017 (UTC)
      • Thanks. That is good to know although I thought new pages were NOINDEXed for 90 days, at least that is what everyone was mentioning back when it was turned back on a few months ago. Jbh Talk 17:01, 11 February 2017 (UTC)
        • I could have sworn it was 90 days too. That's quite concerning, considering the NPP backlog is at least three months. – Joe (talk) 19:16, 11 February 2017 (UTC)
          • There was confusion as to the value of $wgRCMaxAge, it is 90 days in default MediaWiki but 30 days on WMF. This is for how long recent changes are kept in the database. The vast majority of the stuff that shouldn't be seen by search engines is removed after the 30 days though, and going beyond that point would risk antagonizing creators of good content whose articles get stuck in the backlog. Cenarium (talk) 20:51, 11 February 2017 (UTC)
            • Having done a lot of patrolling at the back of the queue (currently new articles from August), I'm not so sure that's the case. And perhaps letting NOINDEX stick around indefinitely would antagonise creators of good content enough to get them to help out at WP:NPP... but we're probably getting off topic. – Joe (talk) 08:10, 12 February 2017 (UTC)
  • Oppose Support per below numbers and conversation We have recently just got the backlog down to a somewhat stable 14,900 pages needing review from a spike to around 16,000. This would increase the already substantial workload on those of us who spend our time at NPP. The newly promotional page would also get thrown in the feed at the time of the creation of the original page if this works like converted redirects. If the page was older, that would probably be a good thing because there is a fair amount of activity at the end of the backlog with people trying to clean up, but if the promotional accounts picked a disambiguation page that had been reviewed mid-December, it would likely go unnoticed for months, all while growing the backlog. I could support something along the lines of Joe's suggestion of marking converted disambiguation pages as unpatrolled, but just marking new moves as unpatrolled will not be helpful. TonyBallioni (talk) 16:17, 11 February 2017 (UTC)
  • Comment This doesn't have to be added to the NP feed, in fact we could have a separate Special:NewMoves page. There are several other reasons for doing this, as noted in phab:T14363. This would then be more integrated in the RC workflow than the NP workflow. Cenarium (talk) 16:36, 11 February 2017 (UTC)
  • I could support having a separate "New moves" workflow that would be like RC patrolling. I would still oppose marking them as unpatrolled, however, because since the RfC last Fall, only admins and new page reviewers can mark a page as reviewed. Having a separate feed wouldn't add to the backlog at NPP, but requiring the user right to mark them as patrolled would necessarily split the labour for a task that I think most editors could handle. TonyBallioni (talk) 16:48, 11 February 2017 (UTC)
  • I would support either a seperate queue or a filterable tag. Whether the page should be un-patrolled depends on how prevalent this problems is vs the number of pages moves made. Jbh Talk 17:01, 11 February 2017 (UTC)
  • It's a convoluted way to bypass new pages patrol, and there are other ways to bypass NPP using moves. So it has to be restricted to admins / NP reviewers otherwise these sockpuppets could patrol each other. As for how many are going to be a problem among all page moves, I expect only a few, but the difference with new page patrolling is that it's easy to spot if a move is legit while it can be time consuming to patrol a new article neither obviously bad or good. Cenarium (talk) 21:29, 11 February 2017 (UTC)
  • (edit conflict) Just by a very crude looking at the move log, on 10 February we had over 1000 pages moved. Given, a signficant portion of those are talk pages, and some in other name spaces, but you are talking about hundreds of pages a day being marked as unpatrolled. Creating this as a something needing to be patrolled with a user right is just begging to create an additional backlog. I'd like to see better numbers on this if someone could produce a report of the average number of mainspace moves per day/per week, but just from my crude looking at the move log, I really do not think that adding move patrolling as a responsibility of NPP/those with the NPR user right will have much impact on people bypassing the new pages feed, because most of it would be buried in a backlog of mostly good-faith moves with a limited number of people who are able to review it. TonyBallioni (talk) 22:17, 11 February 2017 (UTC)
  • @Pppery: No, the move log doesn't allow to filter by namespace of the moved page, it includes multiple moves of a same page, and it can't hide bots or patrolled moves. @TonyBallioni: There are 15234 moves in mainspace in recent changes (last 30 days). However, 10343 of them are by extended confirmed users. So if they were automatically patrolled, this would give us about 163 unpatrolled mainspace moves per day on average. Cenarium (talk) 00:16, 12 February 2017 (UTC)
  • Support/Oppose - I support having some sort of patrolling mechanism for page moves, but I don't think dumping all moved pages into the new pages feed is going to help things. That backlog is already huge and growing. Maybe they could be added into it with a special filter option (i.e. "Show page moves") or maybe it could be a totally separate backlog as suggested by Cenarium, but I don't think just unpatrolling them is the best idea. Kaldari (talk) 03:15, 12 February 2017 (UTC)
  • support This fills a significant gap in our procedures that has been exploited by many promotional editors for years, not just the case that instigate this proposal. Despite the backlog, I think it would need to go into the regular feed, because things will be even worse if we start adding new processes--we want to do the opposite, combine and simplify as much as possible. We'll have no less difficulty keeping track of them in separate processes. I assume it will be programmed so that moves by autopatrolled editors will be marked as patrolled, just as their new articles are. DGG ( talk ) 23:03, 12 February 2017 (UTC)
  • @DGG: would you be open to the idea suggested above that move from extended confirmed users be autopatrolled? I think 163 pages a day would be easy to manage in the existing feed so long as there would be an option to sort for only moves. TonyBallioni (talk) 23:16, 12 February 2017 (UTC)
Extend-confirmed is quite new. I can't say I've looked systematically, but I've encountered extended-confirmed editors who shouldn't be having autopatrolled on the work they submit. It would lead to spammers trying to game extended-confirmed just the way they gamed autoconfirmed. It's harder, but the spammers are trying harder these days. From the numbers given above, the actual workload would be about a 10% increase. What I think we need is more awareness that people can ask an admin for the autopatrolled right, and I for one am quite liberal in granting it--sometimes even before people ask, from observing their new pages. As for filtering, we need much more sophisticated filtering of new pages in general, including for this. DGG ( talk ) 23:45, 12 February 2017 (UTC)
I forgot to include sysops/bots in the previous query, out of the total of 15554 there are 10407 moves by extended confirmed users, 2358 by sysops, 1596 by bots, 1019 by extended movers and 5875 by autopatrolled users. So move-autopatrolling extended movers/autopatrolled users makes about 157 moves to patrol each day, while move-autopatrolling all extended confirmed users make only about 40 moves to patrol each day. Cenarium (talk) 18:46, 13 February 2017 (UTC)
The 40 number seems small enough to me to dump into the NPF as is. 157 I would prefer a separate feed or at least better filtering at Page Curation. TonyBallioni (talk) 18:54, 13 February 2017 (UTC)
  • Support I don't really get the opposition based on 'but it would add to the backlog!'. Well, yes it would. That's the point. A move causes a page to need to be patrolled. However, I'm certainly not objected to a "MovePatrol" log, or a filtering option or whatever. Headbomb {talk / contribs / physics / books} 12:00, 13 February 2017 (UTC)
  • Support Personally think only pagemovers and Autopatrolled should be excluded, as they have clearly been given a right showing their page moves dont need checking. -- Iazyges Consermonor Opus meum 13:05, 13 February 2017 (UTC)
  • Support - it's a good suggestion and it might just catch the more sophisicated forms of spam, but I'm seriously worried about why, with 350 New Page reviewers created since November, the backlog has shown practically no real signs of dropping. Forgive me my lack of AGF, but were they perhaps mostly hat collectors? Some indeed had not touched the Wikipedia for several years. The only thing at this stage that will make a dent in the new pages feed is WP:ACTRIAL. Kudpung กุดผึ้ง (talk) 10:44, 14 February 2017 (UTC)
Kudpung, Your assertion that there are loads of hat-collectors seems founded on the notion that all the users granted NPR were new new page reviewers. Scanning Wikipedia:Requests for permissions/Approved from the first NPR request on 29 Oct shows,
  • October : 10 requests
  • November : 105 requests
  • December : 29 requests
  • January : 25 requests
  • February : 10 requests,
a total of 179 approved requests. From this we've lost
  • 2 blocked spammers,
  • 1 self-requested block, and
  • 2 successful RfAs,
leaving 174 new NPR "hat-holders" in addition to the 171 grandfathered-in. I'd interpret the numbers as showing that there were 115 patrollers who noticed they'd lost the ability to patrol in Oct & Nov and applied to regain what they already had. This would mean we had 286 existing patrollers, to whichanother 64 have been added.
It's also likely to mean that the patrol group has lost a number of patrollers who didn't bother to reclaim the privilege, maybe because they no longer see it as a significant part of their wiki-activities, or for fear of being called hat-collectors.
You're expecting an awful lot from an probable increase of 30-40 patrollers, maybe 10% of the group's size.
The best that could be hoped for from the new privilege is a higher level of competence in the reviewing and more reliable outcomes. Just my 2¢. Cabayi (talk) 13:35, 14 February 2017 (UTC)
Cabayi, your assertion of my assertion, is once again, just plain wrong. If you want inside knowledge, then run for RfA, get the bit, then work the page at PERM. I am not going to do you the pleasure of going through your list to demonstrate once more that a large number of requests came from editors who had been almost totally inactive for years. Your time would be better spent counting how many patrolls each newly created New Page Reviewer has done - or do some reviewing yourself. Kudpung กุดผึ้ง (talk) 00:26, 15 February 2017 (UTC)
  • Support - yes, it would grow the backlog, but page moves by non-autopatrolled users should anyway be reviewed, because there is significant potential for abuse. The NPP backlog is something that should be addressed by publicising the task and putting some effort into making the process as efficient as possible. --Slashme (talk) 10:58, 14 February 2017 (UTC)
  • Support - shut the backdoor. Cabayi (talk) 13:35, 14 February 2017 (UTC)
  • Support - good idea. Please submit include a request for a moved pages filter in the request for this software update. VQuakr (talk) 16:18, 14 February 2017 (UTC)
  • Support - I have seen not just IP editors but also some established editors moving pages for various reasons. The patrollers (and administrators) shall inspect newer names and newer pages, including recently changed names. I don't mind them reviewing my moves, and I hope others won't mind them reviewing their moves. George Ho (talk) 19:56, 14 February 2017 (UTC)
  • Support as a defense against article hijacking. Both page movers and autopatrolled editors should have their moves autopatrolled. ~ Rob13Talk 00:31, 15 February 2017 (UTC)
  • Support. This makes sense. Tony Tan · talk 16:40, 17 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: First sentence of BLP articles

The proposer has requested an early close, and no one has supported any of the suggested changes. — Gluons12 (talk) 20:25, 27 February 2017 (UTC)

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

This is an RfC concerning the first sentence of BLP articles, specifically the '(born XXXXX)' part of it. If there gets consensus to implement option B or C it will cause widespread change across Wikipedia. Currently it says 'Example place-holder (born XXXXX) is a(n)...'. What I propose here is to do either

  • Option A – Keep the current version (e.g. 'Example place-holder (born XXXXX) is a(n)...'),
  • Option B – Change to 'Example place-holder (XXXXX–present) is a(n)...', or
  • Option C – Change to 'Example place-holder (XXXXX–) is a(n)...'.

J947 18:27, 27 February 2017 (UTC)

  • I'm sitting here just as puzzled as NeilN. --Izno (talk) 18:55, 27 February 2017 (UTC)
  • Option A - Birthday is all that is needed - As NeilN says "Birthday to present" does not improve anything and I am hard pressed to find any other place in real life where that terminology is used. The removal of "Born" in B and C could lead to confusion with the "Years active" section of the infobox. MarnetteD|Talk 19:13, 27 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Page creation restrictions

Hi, I've been doing a bit of new page patrolling recently and for four days following the last newsletter the backlog was cut by 1,000 however it is now steadily growing again and within a week will have surpassed its previous size. As a large proportion of new articles either have dubious notability or require substantial cleanup, I suggest that page creation be temporarily restricted to extended confirmed users until the backlog is down to a manageable size. This would allow important, high quality articles to be created whilst the new page reviewers work on slashing the backlog without having more added. During this time, users not meeting the necessary qualifications can apply for their article to be created at AfC. Thoughts? Kind regards, DrStrauss talk 08:27, 13 February 2017 (UTC)

To clarify, only extended confirmed editors would be able to create articles in the mainspace, whilst anonymous to confirmed would need to create in the draftspace? -- Samtar talk · contribs 08:38, 13 February 2017 (UTC)
@Samtar: as I understand it, IPs can't create articles anyway but if I am mistaken then yes, you are correct. If not then restriction on IPs remains the same. DrStrauss talk 08:57, 13 February 2017 (UTC)
Well then I entirely support this - how long would you suggest this restriction be applied? -- Samtar talk · contribs 09:03, 13 February 2017 (UTC)

The WMF have said they won't allow anything like this, even on a temporary basis. – Finnusertop (talk ⋅ contribs) 09:09, 13 February 2017 (UTC)

Awh damn -- Samtar talk · contribs 09:13, 13 February 2017 (UTC)
@Samtar and Finnusertop: that's a shame but if the backlog grows beyond say 25,000 the WMF probably have to change its tune. DrStrauss talk 09:25, 13 February 2017 (UTC)
No, DrStrauss, they don't have to. And I doubt they will. From their point of view, Wikipedia's success is about web traffic, and explosive increase in the number of articles serves that purpose far better than article quality does. – Finnusertop (talk ⋅ contribs) 09:33, 13 February 2017 (UTC)
Hmph. Better crack on with reviewing then! DrStrauss talk 10:50, 13 February 2017 (UTC)
I've looked at that thread a few times over the years and it seems filled with the developer overreach that was not untypical at that time. Perhaps it's time to push the issue forward again, as attitudes may have changed, with certain people having left the organization. --NeilN talk to me 18:11, 14 February 2017 (UTC)
@NeilN: If the community still wishes to impose an autoconfirmed requirement for creating articles, this can be done with the Mediawiki:Titleblacklist and with no need for WMF involvement. This would look and function for the affected users very similarly to page protection. BethNaught (talk) 18:58, 14 February 2017 (UTC)
Thanks BethNaught. Do you know of any discussions surrounding this? --NeilN talk to me 19:01, 14 February 2017 (UTC)
There has been a small amount of discussion at Wikipedia talk:The future of NPP and AfC/To do#ACTRIAL and Wikipedia talk:The future of NPP and AfC#Some ACTRIAL code, though nothing large and public that I am aware of. Unfortunately people seem to know about the edit filters more than the blacklist, so discussion has focussed on what is a worse solution, because the edit filter only stops your page creation on the point of saving, but (for desktop users only—there is a bug in mobile) the blacklist stops you from starting to edit at all. BethNaught (talk) 19:12, 14 February 2017 (UTC)
@BethNaught, Samtar, and NeilN: considering the strong consensus and time passed since the last proposal, do you think we could try to push for WP:ACTRIAL to be implemented? Regards, DrStrauss talk 19:20, 14 February 2017 (UTC)
I think ACTRIAL supporters exaggerate the strength of the consensus, if you read the original closes. In any case, now five years have passed, I think a new RfC should be required. I hadn't joined Wikipedia when the original debate occurred and I don't necessary support it; I simply want to make sure that if the community consensus still exists then it is implemented in the best way. BethNaught (talk) 19:27, 14 February 2017 (UTC)
@BethNaught: should I start the RfC? DrStrauss talk 19:30, 14 February 2017 (UTC)
That's your prerogative, but I would advise you not to do so, soon at any rate. If you botch the RfC (insufficiently convincing opening arguments, malformed questions etc.) you would set back your cause possibly by a long amount of time. You would do better to start an initial discussion with other interested parties such as at the NPP work group, in order to determine the best course of action and polish an RfC before posting it. That said, there has been discussion of this before (linked above) at that group and it fizzled out, and I don't know if there are off-wiki discussions happening about it. BethNaught (talk) 19:34, 14 February 2017 (UTC)
I agree with Beth in that a new RFC should be held to evaluate the community's feelings on the matter, five years on. The RFC should be clearly worded, with assistance from editors experienced in the matter. --NeilN talk to me 19:36, 14 February 2017 (UTC)
@NeilN: shall I create a subpage in my userspace and notify the new page patrol noticeboard about it so they can help as a draft? DrStrauss talk 19:38, 14 February 2017 (UTC)
Did you see the last thread at Wikipedia_talk:The_future_of_NPP_and_AfC/To_do#ACTRIAL? If it was me, I would point editors to this topic (the one we're commenting in) and see what the response is like. --NeilN talk to me 19:50, 14 February 2017 (UTC)
Be sure to ask Kudpung but yes, I recommend creating a subspace draft to draft a good write-up before formally creating the RfC. After five years and significant strain, a new RfC is appropriate. Chris Troutman (talk) 19:53, 14 February 2017 (UTC)
If the Foundation is opposed to such a throttle, then even if it can be implemented without their help, they might intervene. It might be better to discuss ways to address the backlog rather than throttling its growth.--S Philbrick(Talk) 21:33, 14 February 2017 (UTC)
Has the Foundation been approached lately about this? As I alluded to earlier, we might get a different response as certain people have left. --NeilN talk to me 21:59, 14 February 2017 (UTC)
@Sphilbrick: the growth needs to be throttled to effectively approach it. New pages are coming in at a larger rate than we can review them so "throttling" it is a necessary step to effectively addressing it. Thanks. DrStrauss talk 23:10, 14 February 2017 (UTC)

(edit conflict) A new RfC may be a good idea but it will need to be well crafted and managed to keep it from running off the rails and either devolving into a chaos of competing proposals or simply crashing because it is not properly formed. As to discussions with the Foundation my thought is to establish what the community wants to do first. Before we have a consensus to work from "in principle" discussions are less than useless - likely becoming stuck on things which may not be issues and missing issues that may be red lines later. Also, if there are no software changes requested to implement ACTRIAL-2 there is really no handle for the Foundation to use to thwart community consensus without reaching further into the governing of en.wp than they may find comfortable or politic. Jbh Talk 23:15, 14 February 2017 (UTC)

As Sphilbrick notes, the Foundation might intervene if they don't want any kind of throttle. Better to feel them out first rather holding another RFC that will be ignored or thwarted. If they have no comment or say we are free to use existing software features the way we see fit that will signal to editors that their time won't be wasted again. --NeilN talk to me 23:24, 14 February 2017 (UTC)
The argument against that is that an answer to a hypothetical RfC vs. an answer to another massive 500+ person RfC after the fact could be vastly different, and depending on the reasoning for the close could also impact it to. TonyBallioni (talk) 23:28, 14 February 2017 (UTC)
Yes. Entering into discussions based on hypotheticals is almost never a good idea if you want to make a change. It makes it very easy for any obstructionist to throw up equally hypothetical problems, conditions and red lines which kill the proposal before it is actually made. When reduced to their basics a preliminary discussion can only have three outcomes;
  1. I can't say anything until you give me a concrete proposal so hold a RfC and get back to me.
  2. Sure. The community is self governing.
  3. No we won't allow it.
If the answer were #3 my, rather firm, guess is that we would still want to run the RfC much like we did with Flow and Gather (both instances of where Foundation and community disagreed and the community "won") but we would be starting from a position where someone has already staked their ego/authority/self-worth/whatever on No. That would make further discussions much more difficult and high stakes. Better to know if there is consensus for the change or not before lines get drawn. Jbh Talk 23:59, 14 February 2017 (UTC)
I'm contributing as someone who admittedly has not been part of the solution, but this fits into a theme that I hope to write up separately – a number of areas where the existing mechanisms are not adequate. However, while I obviously do not speak for the Foundation, and know that they try to stay hands-ff from internal editorial decisions, the very possibility that the community might conclude that Wikipedia is no longer the encyclopedia that anyone can edit strikes me as a big deal, not a minor editorial decision. I'm sympathetic to growing backlogs (Can I share my frustration at growing OTRS and copyright infringement backlogs?) but I think throttling is the last step not the first step, and I don't see much evidence that robust attempts to either recruit new reviewers, educate editors or improve triage processes have all been exhausted.--S Philbrick(Talk) 00:11, 15 February 2017 (UTC)
  • @TonyBallioni, NeilN, Sphilbrick, Jbhunley, and Chris troutman:, et al: I'm glad to see that people still believe that ACTRIAL is needed. I belive it's now needed more than ever. Our mistake at the time was asking the WMF to tweak the software to implement WP:ACTRIAL. None of us having knowledge of computer programming languages realised that it could easily have been done by local administrator access using edit filters and/or js. That RfC was one of the largest in Wikipedia history - if not the largest, and it closed with an overwhelming consensus. We have since delved into history and found instances where the WMF has greatly throttled the creation of new pages without even asking the local communities, so their 'argument' against ACTRIAL was pure balloney. What more do you folks want? (Perhaps you should all also read the Bugzilla fiasco, and prior to that, the entire two ACTRIAL debates before deciding anything here}. The venue for any future discussion has been created at WP:The future of NPP and AfC which I implore people to read thoroughly, including the new mini poll on ACTRIAL, and join if they want to be active on this front. Let's get a proper mini consensus on what to do before we go ahead, burn our bridges and train wreck again our possibilities like we did by asking the WMF devs to technically implement ACTRIAL. Kudpung กุดผึ้ง (talk) 00:13, 15 February 2017 (UTC)
    Agree on that initial approach - measuring community consensus for what is wanted is much more important then the how - we've come up with creative fixes before and can again. WP:CXT is a somewhat recent example of the community shutting down a tiny subset of unwanted new article creation - it didn't need WMF to change their software. — xaosflux Talk 00:20, 15 February 2017 (UTC)
    @Kudpung: Actrial did not get "overwhelming consensus" or anything close. Some our nonunanimous discussions have over 95% consensus. I might not be bothered at someone saying that 90, 85 or even 80% was overwhelming consensus. But Actrial was below 70%, that's a big majority, and the close described it as a clear consensus though narrow consensus would have been more honest; But it was anything but overwhelming consensus, and that was for autoconfirmed as the threshold. Go for something much stricter than Actrial and you may not even get the narrow consensus that Actrial got. A large RFC with 30% or more of the participants on the losing side is unhealthy for us as a community, but much much worse would be a not quite consensus where 55 or even 60% don't get their way...... ϢereSpielChequers 14:03, 26 February 2017 (UTC)
I'd like to see more clarification of the problem statement. A large backlog is not a statement of a problem, it is an observation of a symptom of a problem. Is NPP mindnumbing? If so can it be improved or do we need better ways to thinks those who do it? Is the backlog large because gifted editors are flocking to Wikipedia to write sparkling prose, or are is it large because we provide little guidance and editors are supplying crap? Do we even have a triage process? --S Philbrick(Talk) 00:34, 15 February 2017 (UTC)
Sphilbrick The best way to understand the problem is to spend an hour a day for a week doing new page patrol from the special:newpagesfeed selecting pages by new users as your chosen filter. That would immediately answer all your questions as clearly as is humanly possible. Is it large because we provide little guidance and editors are supplying crap? Yes, and due to the factthat the WMF refuses to prioritise the work they began in 2012 to address it. No one currently has a closer lobby to the Foundation on these issues than I have and I've recently had an hour long Skype conference withe the VP of the WMF (and other staff) who has now yet again shunted the solutions into a holding bay. Kudpung กุดผึ้ง (talk) 00:52, 15 February 2017 (UTC)
There's something fundamentally wrong if I am expected to spend seven hours before asking a question. Sorry, the OTRS backlog is far too large.--S Philbrick(Talk) 01:30, 15 February 2017 (UTC)
  • Extendedconfirmed seems like a big jump to me. I'm not against trying that for a limited period of time, but let's try just autoconfirmed first. I think we'll be surprised just how much crap that cuts out. I can easily write an abuse filter to warn then disallow on page creations by non-confirmed editors, with a warning message that directs them to copy/paste the text of their article into a draft and submit it through WP:AFC. It might be a trickier proposition to convince anyone to flip it on without another round of consensus-getting; the action would certainly face a lot of scrutiny. ~ Rob13Talk 00:22, 15 February 2017 (UTC)
No one, AFAICS, is seriously asking for Extendedconfirmed. Confirmed was what ACTRIAL demanded and it would put an end to 80% of the junk that arrives every day and which patrollers can't cope with for lack of a) numbers, and b) competency, c) interest. Kudpung กุดผึ้ง (talk) 00:52, 15 February 2017 (UTC)
  • I will never get why we don't require autoconfirmed before crating an article. It's such a low threshold. I tried to get this done several years ago but it didn't fly. (can't remember now where that discussion was but if I find it I'll add a link here) Beeblebrox (talk) 01:00, 15 February 2017 (UTC)
Found it Wikipedia talk:User access levels/RFC on autoconfirmed status required to create an article. That was quite a while ago, maybe time to revisit. Beeblebrox (talk) 01:05, 15 February 2017 (UTC)
I would approach it differently, although I'll start by saying our approach is all wrong. Our approach is hardly different than one designed to create failure. If a friend remarked that they wanted to take up the piano, and they were going to start with Liszt, would you encourage them to go for it? If someone said they wanted to take up running and they were going to start with a marathon, what advice would you give them? If they had never run for office and they decided to run for President...OK, bad example:) But seriously, we often say go for it. Instead of providing good advice like urging them to start with copy edits. I don't think auto-confirmed is enough, but rather than create a rule, I'd prefer to create incentives.
What if we prioritized our reviews, other than chronological order? What if editors with a few thousand edits could reviewed earlier than editors with a single edit? And we publicized this, explaining that someone with a single edit, trying to write a new article is setting themselves up for failure. Maybe they can do it, some can, but the review will take place after we get to people who are going about it the right way.
I haven't worked on NPP formally in some time but I look at hundreds of articles every week, people write emails to Wikimedia, which get handled in our OTRS system and many are brand-new editors wondering why their new article submission isn't going anywhere. It is sad to see how many people, who haven't tried a single edit in their life, think they can master our house style and Wikimarkup with no experience. We need to find a better approach, and throttling is not the answer.--S Philbrick(Talk) 02:15, 15 February 2017 (UTC)
The issue here is with spam (or self-promoters if we are dealing with BLPs), which is a significant portion of what we deal with everyday over at NPP. Spammers really don't care about building up an encyclopedia, no matter what you tell them. The Media-Wiki software releases unpatrolled pages to Google after 30 days, so by deprioritizing the accounts that spam and other problematic articles are likely to come from, you actually further incentivize the creation of the articles with new accounts. TonyBallioni (talk) 02:24, 15 February 2017 (UTC)
  • Oppose -- adjust the intensity of your review to fit the workload. I don't claim to be an expert on all this, so correct me if I'm wrong on either of these points:
1) New pages patrollers have been made artificially scarce by treating it as a user right to be requested specially, which is held currently by 346 people, plus admins.
2) New pages patrolling has been made exceptionally daunting by requiring the patrollers to go through a veritable Cape Canaveral checklist. What's more, the rare permission to do patrolling can be revoked if they don't go through all of it carefully.
Now what I see here looks a lot like we have in every industry in the real "capitalist" world, where there is always some racket of people who allow themselves and nobody else to do any given kind of work. You want, say, an interior design done, you're supposed to go to a licensed interior designer, and if you want to do it, you are supposed to pay the right people to take the right courses and get the right experience to be allowed take the right test to be allowed to work.
In the real world, the goal is for a better caste of people to keep the money away from their inferiors; on Wikipedia, new pages patrolling is a kind of stepping stone to stuff like adminning, so it's a career move of sorts. But the impact is still an artificial scarcity. Naturally, the way proposed to fix that is not to recruit far and wide for new NPPs and make the process simpler, but instead, to choke down on the opportunities to make a new article in the first place.
Now I may be exaggerating the crassness of motive here out of aggravation; maybe some people really think they are "just being careful" having this system. But it's ridiculous. These new articles are hopefully going to expand ten-fold, hundred-fold, with new regular edits after this is all over. All those other edits bringing in other stuff are going to be scrutinized only by the regular old Wikipedia way of having ordinary people look at them and see if they notice anything out of place. When I look at Special:NewPages I don't see a lot of oh-my-gods there, but basically a torrent of solid honest content not in urgent need of quibbles. Even if I restrict it to visualeditor edits, the solid wall of speedy deletes I see includes a lot of articles that are pretty well written and referenced, and it's by no means obvious to me that all those companies (there are a lot of them in this subset) need to be deleted. Even if some company slips through a glowing paragraph about their business until the next time a Wikipedian runs across it, it's not the end of the world - a little amateur POV pushing might even help vaccinate a reader against the pros. People shouldn't trust Wikipedia too much; doing so makes it untrustworthy. So I feel there's no real need for extraordinary competence and good-article like review for the first few drafts of a new article. We just need someone who has been around the block a few times, or a couple of people, to take a quick sniff and see if it stinks, same as any other Wikipedia edit. And if the process becomes that informal, it should be far less trouble to review a flood of new articles. Wnt (talk) 02:44, 15 February 2017 (UTC)
I found some statistics that have been compiled here, but I was wondering if there are any statistics that are more recent? Also, if this does get implemented, it might be a good idea to do a trial first, and then have the statistics from there get discussed to see if it should be implemented permanently (subject to community consensus, of course). RileyBugzYell at me | Edits 17:48, 19 February 2017 (UTC)
It might also be a good idea to see if there was a spike in deleted pages by new editors after the IP page creation ban thing. If there was, then that would most likely mean that there would be a spike in autoconfirmed editors creating spam pages. And since those editors would be autoconfirmed, they would also be able to edit semi-protected pages. Basically, this proposal could be the beginning of an influx of single-purpose accounts getting autoconfirmed status, allowing them to edit semi-protected pages. All in all, that is not a good thing. Anyways, somebody should look into this. RileyBugzYell at me | Edits 18:22, 19 February 2017 (UTC)

Proposal

Hey all, what do you think to this draft proposal? DrStrauss talk 11:20, 15 February 2017 (UTC)

For one it only addresses the issue from the perspective of NPP. While that is a big portion of it there is also a huge, and from the viewpoint of most editors, more important issue of editor training and retention. For instance one of the most common reasons to oppose ACTRIAL is the idea that if someone can not create an article immediately they will be discouraged and not hang around. The counter argument is that having one's first article quickly deleted is more likely to be what sends people away. The point of ACTRIAL is to get new editors to work through AFC where they can get feedback and instruction so their articles do not get speedy-tagged right off the bat. A properly set up RfC will have metrics to see which of these is more accurate.

From a harm reduction point of view it requires spammers to invest a bit more effort and should cause a reduction in 'one-edit-wonder' promotional/paid articles which make up a massive amount of the backlog. Again a well formed RfC will establish metrics to see if this is in fact true. If you read through the prior discussions on this topic you will see several things like these. Reviewing new pages is a vastly important maintinance task but it is not the only thing affected by ACTRIAL and presenting ACTRIAL solely from a NPP perspective without addressing other points of view - as well as the "Anyone can edit" values/ideology of most of our editors will fail and fail badly. Beyond that there is a particular skill in organizing the management of a large RfC and without a proper management plan even the best phrased major RfC will fail to demonstrate consensus because the discussion fragments into dozens of "Support but...", "Oppose but..."', and the niche alternate proposals that people then throw in. The bigger the proposed change the more preparation needs to go into a RfC - this is a very big change so... lots more preparation. Jbh Talk 15:01, 15 February 2017 (UTC)

I think the message is clear that this is not the time for a unilateral independent RfC for ACTRIAL. As I've said elsewhere,teamwork is the essence of making a good RfC and that's why The Blade of the Northern Lights, Scottywong, and I achieved such a massive participation and a clear consensus. What everyone is ignoring is that the limitation to confirmed users was ony half the proposed solution. The other half was what we had designed to help those users who were still in such a rush they would not / could not wait 4 days for their spam articles and garage bands to go live. A lot of work went into that proposal including meetings and conferences. Nothing of the sort has been done here. Who, for example is going to notify everyone of the 500 former participants of the new RfC? That's a task that needs sharing for starters. Let's also not forget that ACTRIAL is a TRIAL. It was not a new policy set in stone and it was written into the proposal that it would be reverted if the stats proved after six months that it was having a detrimental effect on the encyclopedia. The WMF already set its own precedent in 2006 for throttling the creation of new pages, thus proving that the project is organic and need to keep pace with its growth and evolution. They conveniently forgot that when they chucked out ACTRIAL. xaosflux hit the nail on the head when he agreed that we should first decide what to do before we rush headlomg into things. That said, I say don't bother with an RfC at at all, try the implementation, and see what happens. Kudpung กุดผึ้ง (talk) 16:36, 15 February 2017 (UTC)
@Kudpung: - fair enough, I suppose time is needed. If we bypass RfC, who will implement it via the blacklist. And what would that process entail? Thanks. DrStrauss talk 16:23, 16 February 2017 (UTC)
Again, DrStrauss, the answers to all those questions are at WP:The future of NPP and AfC - you have some reading to do. Kudpung กุดผึ้ง (talk) 18:43, 16 February 2017 (UTC)

Cut-off date for {{PD-old}} in Commons

A proposal has been made at the Commons Village Pump to simplify the rules for dealing with works by artists whose date of death is unknown by agreeing a cut-off date for {{PD-old}}, the intention being to improve the consistency of Deletion Requests when closed by different Commons admins. I'm noting the proposal here for greater visibility. Please comment and !vote there. MichaelMaggs (talk) 13:20, 27 February 2017 (UTC)

I'm proposing a bot process to change how links are made to Internet Archive. Currently many links include a machine ID in the URL like this:

http://ia700409.us.archive.org/24/items/bulletinofmuseum18harv/bulletinofmuseum18harv.pdf

The "ia700409" is a machine in the Internet Archive cluster. If that machine is retired, or the file is moved to a different machine, the link will break. Links like this are similar to DHCP addresses, they last for a little while.

The permalink is:

https://archive.org/details/bulletinofmuseum18harv

This link always works. It's the main work page and shows all files available not just the PDF. Tests have shown more than 50% of machine-ID links on Wikipedia are presently dead. The other 50% will also die, sooner or later. The proposal is to make edits like this. Sometimes the permalink doesn't include a preview like this. Relevant guideline WP:ELDEAD "Consider locating and linking to permalink versions of web content".

There is an open BRFA. -- GreenC 14:08, 28 February 2017 (UTC)

Thanks for posting GreenC - the primary reason to refer this for comment is the change in reader experience and ensure there is community support for this. — xaosflux Talk 16:29, 28 February 2017 (UTC)

Proposal to solve problem of process subpages

I was drafting this in my userspace pending advice on the feasibility of this proposal, but I figured going ahead and proposing it would be a better way to invte constructive criticism.

I have noticed something of a problem in the last few weeks. A number of process pages (WP:RM[2] and WP:GAR[3] among them) depend on transcluded subpages. The main process pages have hundreds of watchers, but the subpages have almost no one watching them. As a result, unilateral changes can go months or years without being noticed, or at least without being questioned. Given that the instructions included in these process subpages tend to be taken as authoritative, care should be taken that they are in line our core policies.

I am sure these unilateral changes were made in good faith, but since such changes should not generally be made without either prior community consensus or some way of determining that a significant portion of the community tacitly approved of the changes, I would like to propose either one of the following:

  1. Permanent full protection for all process subpages;
  2. Merging process subpages into their respective main process pages.

The former would prevent the pages from being edited by non-admins without prior discussion/consensus, while the latter would at least mean that the 1,580 editors watching RM and the 251 editors watching GAR would be notified when changes are made.

Hijiri 88 (聖やや) 22:32, 20 February 2017 (UTC)

So, am I being shunned? Is my proposal so utterly outrageous that no one will even comment? Hijiri 88 (聖やや) 03:06, 22 February 2017 (UTC)
The utterly outrageous ones get quick negative replies - see, for example, #Create draft namespace redirects which is present on the page here right now. The ones with no replies are typicly the ones which few users care about one way or the other - see Wikipedia:Avoid Parkinson's Bicycle Shed Effect. עוד מישהו Od Mishehu 13:53, 23 February 2017 (UTC)
@Beeblebrox: But proposal #2 is not a very radical proposal, at least as far as I have been able to establish. With the two specific examples I linked to, the main page is not particularly long, and neither are any of the subpages, so not merging them seems like maintaining subpages simply for the sake of maintaining subpages. If I am missing somewhere where it's outlined why these subpages need to exist, I ... well, I would apologize, but it's not really my fault if it's not inscribed in WP:SUBPAGE. #Allowed uses (4) appears to be the relevant guideline, but it can't apply to the short pages I linked above. And it is clearly a problem if editors can unilaterally change normative guidelines and no one notices for months a years -- I can't believe that other users don't recognize that. Hijiri 88 (聖やや) 13:19, 28 February 2017 (UTC)
  • I've actually stumbled across a subpage blank[4] that went unnoticed for roughly 5 months before I fixed it. I don't think protection would be a solution in this case, since IPs are still extra eyes that might spot these changes. I'm not familiar with how watchlists work, but would it be feasible to set them to include subpages when a specific page is watched? 170.178.234.233 (talk) 16:28, 27 February 2017 (UTC)
@170.178.234.233: But see, neither of my proposals would affect IP editors differently than editors with accounts. It's full protection (read: only admins can edit) or remove the subpages altogether. It seems like you agree with me that there's a problem; I too don't know much about watchlists, but clearly if there is such an option, almost no one is availing of it. Hijiri 88 (聖やや) 13:19, 28 February 2017 (UTC)
The problem exists, but I don't know to what extent. The two good uses for transclusions I've seen so far is to display redundant information in multiple locations, and to create a backroom for bots to make routine edits without potentially interfering with human edits (Such as Wikipedia:Dusty_articles/List used to be). The former use would become an issue if transclusions were eliminated since every recreation of the text would have to be made and changed carefully to ensure they stay consistent. I don't know if there's any bots that work in the policy areas, but if there are they could be forced to attain admin powers they would otherwise not use if the subpages were protected, and minor changes like spelling would require grabbing an admin to implement regardless of the change's merit. I think it's fine to eliminate any transclusions that don't meet either of these uses, but protection and removal beyond that would be overkill- checking the history when something doesn't look right seems to be working so far, and simply finding a way to make changes in policy areas a little more visible would likely solve most of the problem without adding any extra hoops for jumping through, in my opinion. It might drum up more discussion if you could find evidence of just how big this is beyond your and my examples.170.178.234.233 (talk) 14:57, 28 February 2017 (UTC)
Technically, the reason they are used in the two locations I referred to is to keep the pages themselves short and readable, but that doesn't make sense because even with the subpages incorporated they would still be pretty short. Hijiri 88 (聖やや) 22:34, 28 February 2017 (UTC)

Remove political banner

Update: The banner has been paused. --Yair rand (talk) 18:52, 2 March 2017 (UTC)

Six hours ago, a CentralNotice banner was enabled on the English Wikipedia for anonymous users in six countries (US, Canada, Australia, UK, New Zealand, Ireland), inviting readers to read the "Wikimedia Foundation 2016 Annual Report".

The page asks readers to "CONSIDER THE FACTS", showing a large picture of Syrian refugee children, together with the text "FACT: Half of refugees are school-age", which links to a page full of completely unencyclopedic text about the topic: "That means 10 million children are away from their homes, their communities, and their traditional education. Each refugee child’s experience is unique, but every single one loses time from their important learning years. Many of them face the added pressure of being surrounded by new languages and cultures." The linked page goes on to detail some of Wikimedia's vision and how Wikimedia projects aid refugee populations. Following that, we have an entire page on climate change and some of its effects, similarly written in a style that is not befitting the Wikimedia movement: "In 2015, [Wikimedian Andreas Weith] photographed starving polar bears in the Arctic. As the ice declines, so does their ability to find food. “It’s heartbreaking,” he says." After all that, we finally have some pages on interesting statistics about Wikimedia, mixed in with some general odd facts about the world, followed by a call to donate. There are also letters from the ED and founder linked.

Using Wikipedia to push political viewpoints is unacceptable.

I propose disabling the banner, by adding the following to Mediawiki:Common.css: body #centralNotice { display: none !important; } #mw-page-base{ margin-top: 0 !important; } #mw-head { top: 0 !important; } #mw-panel{ top: 160px !important; }

--Yair rand (talk) 23:04, 1 March 2017 (UTC)

Support, partly because it is an undue political message, but partly also because it is blatant advertising for donations to WMF. We're supposed to have had a successful end of 2016 fundraiser—so much so that the WMF tried to break its promise to stop its appeal at the original target, and was only held to that by community pressure. So why another donation drive? BethNaught (talk) 23:18, 1 March 2017 (UTC)
Support - Although I support refugees, Wikipedia is not for advertising. And even if it was, the fact that this banner is on Wikipedia probably discourages people from the opposing side to support what WikiMedia supports. Basically, Wikipedia is not advertising and this banner is probably doing the opposite of what it was designed to do. RileyBugzYell at me | Edits 23:23, 1 March 2017 (UTC)
    • I think it is important to note that this is just one of numerous facts presented and you can swipe left or right to see more, such as "OK is the most understood word globally" and "Wikipedia is updated 350 times a minute". This is just a presentation of facts. Sure, they selected facts that seem particularly relevant right now, but I don't see any overt bias in what they are actually saying. The facts themselves, I mean. Despite the impression Americanss may be getting right now, facts are not the same thing as political opinions, they are facts. Beeblebrox (talk) 23:31, 1 March 2017 (UTC)
    I don't see anywhere to "swipe" on my computer monitor....just saying. — xaosflux Talk 23:33, 1 March 2017 (UTC)
I see a little arrow on the left and right side of the image, a mouse click would do as well, assuming we are seeing the same thing. Beeblebrox (talk) 23:34, 1 March 2017 (UTC)
Got there eventually, first saw a full page banner, that obscured some sort of broken flash object. — xaosflux Talk 23:35, 1 March 2017 (UTC)
@Beeblebrox: The ones I mentioned are the first two, in order. I don't think that a statement of how "heartbreaking" it is is just a statement of facts. --Yair rand (talk) 23:35, 1 March 2017 (UTC)
But you're calling it a "political banner". What I see is a banner that links to a page, where I can scroll down, navigate through some images, click on one of them, read a few paragraphs, and find the "it's heartbreaking" quote. Let's be fair and use facts ourselves in making such a decision. Beeblebrox (talk) 23:38, 1 March 2017 (UTC)
Not to mention that describing children being forced to flee their home as "heartbreaking" is not a political description in and of itself because it isn't advocating a position as to how sovereign states should handle these children. TonyBallioni (talk) 23:52, 1 March 2017 (UTC)
Actually the "heartbreaking" quote is about starving polar bears. The comments about refugees are all about how Wikimedia projects can help them with educational resources, which I don't see as the least bit political. Beeblebrox (talk) 21:10, 2 March 2017 (UTC)
Strong oppose WMF as a non-profit has a right to advertise its annual report on its own webpage. Aside from that the annual report serves to let the people who we serve the readers know about all the work that the Wikimedia Foundation does. If people take the time to read the annual report, they will see that the refugee component is talking about the work that WMF has done in Germany with refugees. It is not making a political argument. What is the opposing side here? The side that refugees shouldn't have free access to freely licensed knowledge? To my knowledge, no political party or person has discussed the rights of refugees to read content that is publicly available for free. Also, sure, we had a successful 2016 campaign, but its almost the end of the first quarter of the calendar year, so its time to update the public on what you are doing, and yes, ask for more money if needed. TonyBallioni (talk) 23:41, 1 March 2017 (UTC)
@Jayron32: Yes, they are (seriously, I'm not joking). RileyBugzYell at me | Edits 00:29, 2 March 2017 (UTC)
I didn't realize running away from people trying to murder you was a political position. --Jayron32 00:37, 2 March 2017 (UTC)
Unfortunately it is, see comments from people like Donald Trump. RileyBugzYell at me | Edits 20:22, 2 March 2017 (UTC)
Trump talks about refugees who want to come to the United States, and what it means for the US if we allow it. This just gives numbers and details ways Wikimedia can help provide educational resources. Calling that political is typical of the reductionist thought of this benighted age. Beeblebrox (talk) 21:12, 2 March 2017 (UTC)

Comment Zack Mccune from WMF communications has provided some background to theme of the annual report on wikimedia-l. Seddon (WMF) (talk) 02:56, 2 March 2017 (UTC)

Comment Hello everyone. Grateful for the discussion @Yair rand: has opened on Wikimedia-l. As it continues, we have paused ALL "Thank you" site banners for Wikimedia projects that included a link to the Annual Report. Please join us in the discussion there and if you have re-writes to the banner itself please feel free to direct them to me zmccune [at] wikimedia [dot] org. ZMcCune (WMF) (talk) 17:17, 2 March 2017 (UTC)

  • Support per RileyBugz - It's OK for WMF to advertise themselves (annual report, donations), but this is not the place to push a political POV, no matter how widespread you think agreement with one side is. If there is significant discussion of the opposition in multiple reliable sources, it's not worth including. (also see [5]) — Train2104 (t • c) 18:17, 2 March 2017 (UTC)

Should bots perform secondary "cosmetic" tasks while making a primary task?

Per WP:COSMETICBOT and WP:NOTBROKEN many tasks as bypassing redirects, removing whitespace, simplifying links should not be done on their own. Should we ask bot owners to modify their bots so they perform secondary "cosmetic" tasks while making a primary task? Recently, Yobot one of the main syntax fixing bots had all it tasks revoked which results in need to find another ways to perform these tasks. Any action would require clear community consensus. This is an action to raise awareness of the problem. -- Magioladitis (talk) 07:23, 28 February 2017 (UTC)

"Cosmetic changes should be applied [by bots] only when there is a substantive change to make at the same time", a quote from WP:COSMETICBOT. They may already do so. Should we ask them to do so? I don't feel strongly one way or another on the matter. — Godsy (TALKCONT) 07:41, 28 February 2017 (UTC)
Godsy the problem is that we are running out of bots actually doing these edits. -- Magioladitis (talk) 07:45, 28 February 2017 (UTC)
I have no problem with asking bot owners to "modify their bots so they perform secondary 'cosmetic' tasks while [completing] a primary task", as long as it is not required (i.e. it is simply a request and they can decline). I think a call to arms of that nature at Wikipedia:Bot owners' noticeboard would suffice, as opposed to an RfC on the matter here. — Godsy (TALKCONT) 07:54, 28 February 2017 (UTC)
Godsy I am not sure. Because if me and other bot owners asks for this modification without community backup we may be declined. -- Magioladitis (talk) 07:58, 28 February 2017 (UTC)
  • Headdesks. You know, when I asked you to hold a discussion on AWB genfixes/checkwiki fixes (points #4/#5), I thought I had made it pretty clear the issue is not whether or not genfixes can or should be done, but that the issue lies with the classification of some of these genfixes which are done in the absence of more substantial changes, in violation of WP:COSMETICBOT. Likewise on the topic of Checkwiki Error #64.
But to answer the question directly, WP:COSMETICBOT is clear that bots can perform cosmetic fix alongside more substantial edits, that bots can be approved to do genfixes following a proper BRFA, and that some but not all of the checkwiki/genfixes are considered non-cosmetic and can be done own their own. As for asking bots to do AWB genfixes, I suppose you can ask, but no bot operator can be compelled to do them. And of course any bot op that chooses to do AWB genfixes alongside their main task is required to go through a BRFA for approval.
I don't see what needs an RFC on this. If the issue is you want more bot ops tackling genfixes/checkwiki tasks, make a WP:BOTREQ, or drop a notice at WP:BON. Headbomb {talk / contribs / physics / books} 11:40, 28 February 2017 (UTC)
  • Any botop can request to add general fixes to their bot tasks at a BRFA. They would need approval to do so, and such approval should take into account whether the operator is able to handle those secondary cosmetic changes without making cosmetic-only changes given the nature of the task they're doing. We obviously can't force a botop to include such changes, and I suspect most will not, as it complicates code (feature creep). But I have nothing at all against botops who want to include such changes within the bounds of the bot policy; I've always supported that. ~ Rob13Talk 12:18, 28 February 2017 (UTC)
    • I want to be clear that I don't support encouraging all bots to run with cosmetic changes. That ignores some of the nuance of when genfixes are/aren't a good idea for a bot. For instance, a bot that tends to produce very difficult to read diffs before applying genfixes probably shouldn't add genfixes, since that would confuse things further for editors trying to review edits. On the other hand, a bot making relatively simple fixes could add genfixes without an issue, provided they code responsibly. This has to be handled on an individual basis, not with a blanket "everyone should do this" sort of policy. ~ Rob13Talk 14:59, 28 February 2017 (UTC)

In some cases, when there is a more substantive edit to be made, bots have been approved to also make more minor, cosmetic changes. However, these cosmetic changes should not be made as standalone edits. This is a standard part of the bot policy, which has been established for years. Most bot operators have no difficulty following this policy.

Specific cases can be exceptions to the general policy, of course. One exception is Yobot, which has often violated the bot policy over a period of years by making cosmetic or unapproved standalone edits. There is an ongoing arbitration case about this, and separately all of Yobot's authorizations were revoked. So, for Yobot in particular, I believe it would be better not to make any "secondary" cosmetic edits, based on this long history. It should stick to the main task only. This does not mean that all bots should do that; we have a long experience with Yobot which shows that, for whatever reason, it has had more difficulty following the bot policy. — Carl (CBM · talk) 12:23, 28 February 2017 (UTC)

  • Now the community has to actively encourage bot ops to perform syntax fixes. Fixing brackets, handling overlinking is not "secondary cosmetic changes". Exactly because some people underestimate the value of syntax fixing the community has to act. Please note that there is need for people to feedback on that because it's the very same people who participate in most of the discussions. -- Magioladitis (talk) 12:25, 28 February 2017 (UTC)
    • We have to be careful with terminology. There are some edits that are really fixes, such as changing the broken link [[Categry:Foo]] to [[Category:Foo]]. There are also changes that do not fix any serious problem, but only change the way that wikicode is used, such as changing [[Image:foo]] to [[File:Foo]]. Because the "Image" namespace is an exact synonym for the "File" namespace, it would be a mistake to call that latter edit a "fix", as nothing was broken. Bots have a much easier time with approvals for edits of the first kind than for edits of the second kind, which I think is unsurprising to most people. It only confuses the issue to lump together all changes as "fixes". — Carl (CBM · talk) 12:28, 28 February 2017 (UTC)
  • Personally I would say that BOTs should not apply other changes, cosmetic or not, at the same time as doing a specific task. You know what the task is and can thus skip that change in the watchlist, having other changes rolled in means that they have to be individually checked to see if the extra changes were required because of vandalism in an earlier edit. Keith D (talk) 19:36, 28 February 2017 (UTC)
    • Keith D, if the policy prohibits a bot from making "cosmetic" changes (such as making the order of categories and stub tags comply with MOS:APPENDIX) unless the bot is already doing a specific task, and you ban them from making those changes while they are doing a specific task, then when exactly is it okay to make these changes? As far as I can tell, if you had your way, it would be impossible to make these changes. WhatamIdoing (talk) 21:08, 2 March 2017 (UTC)
  • Should we ask them to do these in addition to more vital tasks? Sure. Should we require it? No. Beeblebrox (talk) 21:57, 28 February 2017 (UTC)

Suggestion

Could they create a robot based on a platform like open source clamav that was updated online to clean the site of malicious references in the articles? Thanks in advance.201.17.137.222 (talk) 22:19, 2 March 2017 (UTC)

Make certain warning templates visible on mobile (requesting formal close)

Tracked in Phabricator
Task T159262
  • There is clear consensus that some warning templates should be visible on mobile.
  • The Wikimedia Foundation has expressed interest in developing this functionality.
  • Which templates should be displayed can be handled as usual, if and when the functionality is available. There is currently clear support for {{hoax}}, {{afd}}, and speedy deletion templates. Support for {{medref}} is potentially unclear and warrants a more specific discussion. Other templates with potential for support were suggested.
  • Npangarkar (WMF) or anyone else is invited to start a new discussion at any time on design, requirements, or any other details that need to be resolved. Alsee (talk) 22:27, 2 March 2017 (UTC)

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

If an article is up for AfD and flagged as a possible hoax with insufficient medical sourcing, any reader visiting that article on a computer is greeted by three large red and orange boxes at the top of the page, one with a cautionary stop sign. The reader is clearly told that what they're about to read may be a complete fabrication, contains inadequately referenced medical advice, and that an active, serious discussion has been raised about removing the article from Wikipedia. If a reader instead visits the same hoax medical article on their phone (and 45% of Wikimedia traffic is now from mobile devices), they just get two tiny grey words "Page issues" under the article title - the same ignorable alert they'd get if the article had an inconsistent footnote style or a missing taxobox - and the article is presented like any other.

I propose making {{hoax}}, {{medref}}, {{afd}} and all speedy templates visible on mobile, in whatever cut-down version is appropriate for mobile displays (perhaps just omitting the advice-to-editors "Please review the contents of the article and..." text in the templates' "fix=" fields). --McGeddon (talk) 10:03, 21 September 2016 (UTC)

iPhone 5S screen showing an ambox on an article
  • I've added a screenshot of how this would look when not doing too much. The problem for me here is that it is either all text, or no text, since the templates don't have 'short' versions or titles or anything... If someone has an idea how to fix that, that would be very interesting. —TheDJ (talk • contribs) 09:48, 23 September 2016 (UTC)
    {{ambox}} actually does have short-version functionality at Template:Ambox#issue_and_fix, although the AfD and prod templates don't use it (putting everything in "text="), and speedy deletions use mbox instead of ambox. It looks as if "issue=" is about right in terms of length ("approximately 10-20 words") and scope (we need to tell mobile readers there's an issue, but we can skip telling them how to fix it). If the deletion boxes can be wrangled, changing ambox from "template always invisible on mobile" to "template visible on mobile if hoax/medref/AfD/etc, fix always invisible on mobile" might be enough. --McGeddon (talk) 10:22, 23 September 2016 (UTC)
    Another solution would be to add a "mobile=" field to a/mbox, and change the templates so that if the mobile field is set to anything, it displays a small box on mobile, and otherwise remains invisible. This would be neater for not having to hardcode "if medref or hoax or..." in a/mbox - the "mobile=" field could either be a yes/no flag (the box displaying the text from "issue=" if yes), or could be free text if we'd rather write new, concise versions for mobile display. --McGeddon (talk) 10:40, 23 September 2016 (UTC)
  • Support; vital information that shouldn't be hidden from readers. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     11:55, 23 September 2016 (UTC)
  • Strong support As James Allison alluded to, the absence of warning templates treats mobile users as second class citizens. We should not be treating 45% of our users as unworthy of warnings. In addition to the templates mentioned above, I would add all content warning templates, but if that's unpopular I'd suggest at the very least {{copypaste}}, {{POV}}, {{original research}}, {{POV-lead}}, {{contradict}}, {{contradict-other}}, {{contradict-other-multiple}}, {{misleading}}, all neutrality cleanup templates, all BLP sourcing problem templates, and {{disputed list}}. I'd also like the "discuss" link of {{dubious}} to show up. Hairy Dude (talk) 10:58, 24 September 2016 (UTC)
  • Support. I would especially love to see Hairy Dude's suggestion put into place. White Arabian Filly Neigh 21:24, 25 September 2016 (UTC)
  • support per nominators rationale--Ozzie10aaaa (talk) 17:58, 27 September 2016 (UTC)
  • Oppose obscuring the whole screen by making AFD templates visible (especially to logged-out people/readers) because "I don't think this meets our criteria for notability" (the most common reason for AFD) is not a "warning" about the content of the page in any sense.
    Support making {{hoax}} visible. Weak support for making all speedy templates visible, because some are relevant and it's probably too much hassle to decide which ones matter and then code them all separately.
    Oppose including {{medref}}. (I know; my anti-woo friends at WPMED aren't going to be pleased about this vote. But:) That tag is not a badge of shame or a "warning" to the reader. We have WP:No disclaimers in articles, not even for articles that have outdated (>5 years old) sources or that use less than ideal sources. (Typically, an article earns this tag when the sources are peer-reviewed academic papers about original studies or webpages from reputable(!) patient groups like the American Cancer Society, rather than review articles and med school textbooks. It's not a "dangerous content here!" tag. It's really a call to action for editors, and the goal is usually just to replace okay sources with ideal ones – often with no change to the actual text of the article. If you're not familiar with this, then look at Plague (disease), where it's been spammed into a history section (an area that WP:MEDRS doesn't apply to) and Blood cell, whose main fault is merely having too few citations total. WhatamIdoing (talk) 18:10, 27 September 2016 (UTC)
  • Support special short and expandable versions of these templates for mobile. We should not hide our problems, but actively tell people about them. —Kusma (t·c) 18:33, 27 September 2016 (UTC)
  • Oppose all but {{hoax}} which I support. It is hard to clean up an article on mobile so not really needed. Doc James (talk · contribs · email) 05:38, 28 September 2016 (UTC)
  • Support, under the conditions that the warning is important and directed towards non-editors. We're plastered by warnings all the time and having too many only causes us to ignore them — so they should only be used very rarely, such as they examples made above. Technically it should not be too difficult to make them display on mobile, however an issue arises when we have the template {{multipleissues}} — which can not simply be adapted to display certain things on mobile, while not others. Any ideas? Carl Fredrik 💌 📧 15:03, 28 September 2016 (UTC)
  • Support making {{hoax}}, {{afd}} and all speedy templates visible on mobile, per User:James Allison. Even if we don't add a "mobile=" field to a/mbox. I do support adding that, and making {{medref}} visible too, once that's done.--Elvey(t•c) 19:12, 29 September 2016 (UTC)
  • Support Displaying AfD, PROD, CSD, and Hoax tags. Neutral on medref. Hoax needs to be implemented ASAP. Tazerdadog (talk) 06:58, 30 September 2016 (UTC)

This discussion got a lot of support back in September before it got archived, but I've struggled to get any traction for how we could actually implement it since, at either WikiProject Templates or Village pump (technical). Another editor has advised that I move it back out of the archives and request a "formal close", so here it is. Can somebody do the honours? --McGeddon (talk) 17:16, 24 February 2017 (UTC)

Disclaimer: I'm the designer for WMF's web team. I absolutely agree that this is needed. I have couple of ideas on design of this. I have compiled them on phabricator here > https://phabricator.wikimedia.org/T159262 I would love to work with everyone to finalize the design and other requirements. --Npangarkar (WMF) (talk) 22:16, 28 February 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New adminbot request - File revision deletion for orphaned fair-use versions

A new adminbot BRFA has been opened at Wikipedia:Bots/Requests for approval/RonBot and is open for community comments. Thank you, — xaosflux Talk 04:14, 3 March 2017 (UTC)

Talk Page Archives

Talk pages should be archived less often, especially when the talk page is short.

Leaving unresolved messages does no harm, but removing them does.

I'm surprised this hasn't been suggested before.

Benjamin (talk) 11:02, 4 March 2017 (UTC)

  • Support, however the time-spans vary per talk page afaik. I think the archival-scripts / bots should be modified to not archive unless the talk page has grown very long (the threshold length could be specified). Relevant to this is my suggestion to abolish the edit ban of archived talk pages (some more input on this there).
Also I just had another idea for which I'll probably create a new proposal if it's not picked up here:
instead of archiving talk page entries we could simply have them collapsed, like:
blabla
The following discussion has been closed. Please do not modify it.

contentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontent contentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontent contentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontentcontent contentcontentcontentcontent content

There could be exceptions for talk pages which are extraordinarily long like the village pumps and/or they could still be archived just at a much later point.
Also there could be a new collapse-template for this which allows, encourages and/or simplifies the modification/revival of a talk page post.
--Fixuture (talk) 12:15, 4 March 2017 (UTC)
Behavior of the archive bots varies by talk page and is controlled by relatively simple parameters coded near the top of the page. The values of the parameters are established by editors according to the current conditions on the page including level of activity. Like most other content, any editor can change the parameters, any other editor can challenge by reverting, and any disputes are resolved through discussion and consensus. I see no reason to change how this works. I also see little need for a community consensus on proper talk page archive management. ―Mandruss ☎ 12:37, 4 March 2017 (UTC)
Oh, okay, cool, I didn't know that. Benjamin (talk) 12:40, 4 March 2017 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_137&oldid=1091624816"