Italian, Latvian, Polish, and Spanish Wikipedia are dark to raise awareness of the EU Copyright Directive. I have seen an email sent around by a copyright maximalist lobbying group complaining about the Wikipedia community's direct action here - the attitude appears to be that back room deals in Brussels by highly paid lobbying firms is fine, but the public speaking and responding is not. I am reminded of the famous case of Chris Dodd of the MPAA complaining to Congress in the US "Don't ask me to write a check for you when you think your job is at risk and then don't pay any attention to me when my job is at stake" and also calling our action an "abuse of power". As I said then, millions of people calling their lawmakers is not an abuse of power: it's democracy.
The Polish Wikipedia in particular moved very quickly from a proposal to a blackout. I'm not suggesting that we can do the same here, but I am wondering what others think. English Wikipedia is the loudest voice for free culture in the world, and our banner certainly is helping... I just fear that it may not be enough. If we could black out for just 4 hours before the vote (which is at noon Brussels time tomorrow) then I think we'll get their attention at just the right moment.
To remind you - a "No" vote tomorrow just means that there will be a wider debate in European Parliament, involving the entire chamber, in September. Amendments can be offered and our action will make sure that free culture has a voice at the table. A "Yes" vote tomorrow means that our only choice will be to try to kill the entire thing in September... when it is only Articles 11 and 13 which are the problem. (The rest, I am told by activists, is pretty straightforward and useful modernization.) Obviously it will be harder to kill a mixed bill then, and a shame to kill it. So I am keenly hopeful that tomorrow goes well.--Jimbo Wales (talk) 17:44, 4 July 2018 (UTC)
I would firmly oppose an enwiki blackout for this. While it's an important matter, it's not exactly an existential threat that would justify such an extreme measure. A blackout would adversely impact our readers with no real upside.- MrX 🖋 18:02, 4 July 2018 (UTC)
The upside: stopping a terrible anti-consumer anti-free culture law in its tracks, showing that this is not an area that moneyed lobbyists can tread into without fear from a reaction from the public. The downside: a few hours of inconvenience. It is no contest.--Jimbo Wales (talk) 22:54, 4 July 2018 (UTC)
I'd support a localized SOPA-style blackout from now until the vote on July 5th personally (or until September if this passes with no option but to kill it in full in September). Headbomb {t · c · p · b}18:13, 4 July 2018 (UTC)
Given that our servers, if I'm not mistaken, are mainly based in the United States, and, as a result, the Wikimedia Foundation is subject to U.S. jurisdiction and law, I would wholly oppose any English Wikipedia blackout that could be seen as a political action to cajole, coax, interfere, or otherwise effect a response from lawmakers and representatives of other nations and states, which would in no way affect U.S. law. It would, as Mr X says quite plainly, detrimentally affect our user-base, as well, in the United States, Australia, and other English-speaking, non-UK nations, which would hurt us severely regarding editor retention, too. I cannot, for these reasons, support any sort of black-out of English Wikipedia. —Javert2113 (Siarad.|¤)18:21, 4 July 2018 (UTC)
This is a very narrow view which I hope we could not take. This will hurt the entire free culture movement, including Wikipedia, worldwide. If we do not take a principled stand that open culture matters, then we will be increasingly boxed in. If we were a for-profit company, or if we were narrowly a non-profit organization, then we might take such a narrow view. We are neither. We are a community with a great deal of power to help Internet users world wide, and I think with that kind of power comes responsibility.--Jimbo Wales (talk) 22:54, 4 July 2018 (UTC)
Well, Mr. Wales, I certainly recognize your position, and though I continue to disagree on the possible impact of this legislation, I think a compromise might work: geo-targeting Europe, as you replied above, would be an acceptable policy (whether or not that includes the United Kingdom, I leave up to you, the Trustees, and the Foundation). I certainly wouldn't object too strenuously to that, though I opine that open knowledge means open to all, regardless of location, political pressures, or public opinion. —Javert2113 (Siarad.|¤)01:01, 5 July 2018 (UTC)
The geotargeting is pretty much assumed. The SOPA blackout was only in the US and the banner was only in the EU. I have been working with the EFF to (depending on how the current vote goes) have them pick a blackout date and start asking websites to join. I have explained to them that while Reddit or Facebook can make such a decision in days, it will take us a lot longer, so the date should be set sooner rather than later. --Guy Macon (talk) 05:25, 5 July 2018 (UTC)
I'd also oppose any blackout, localized or not. This isn't an existential risk, and a blackout disrupts our primary goal. --Yair rand (talk) 18:26, 4 July 2018 (UTC)
So it is your position that we should not oppose anything that hurts Wikipedia, no matter how badly, unless it actually causes us to shut down the encyclopedia? --Guy Macon (talk) 05:25, 5 July 2018 (UTC)
I think that even if the Wikimedia Foundation were to be shut down by the US Government, Wikipedia would survive. If we come to a dystopian totalitarian future and had to go into hiding and work to reassemble secretly and edit articles, like the characters in Fahrenheit 451, I think we would, and my life work would be to help lead that in any way that I could, and Wikipedia would survive. My point is that I don't think much can cause Wikipedia to "cease to exist". Wikipedia is an idea. Wikipedia is a community. Wikipedia means something to people, and we will persevere even under great pressure. My point is really that I don't think "Wikipedia will cease to exist" is the right filter for deciding when to act. We should act when we see something that will significantly damage the free culture movement, that will undermine the view that people have the right to upload things to the Internet without a prior assumption of potential criminality, and when we see that we actually can make a meaningful difference. There will be many cases where we should not act, and there will be cases where reasonable people will disagree on whether we should act or how we should act. But I don't think that "We only act when Wikipedia will cease to exist if we don't" is particularly meaningful.--Jimbo Wales (talk) 09:24, 5 July 2018 (UTC)
Support. I think this very much is relevant to the English Wikipedia, and anyone around the world reading it, because the standards sets by the European Union will affect any website with clients within the EU, which is basically every website everywhere (see how the recent privacy bill created a global standard). Article 11 would allow websites to demand that we purchase a license from them when quoting their text (even small snippets), which would make life miserable for us trying to maintain neutrality and due weight in articles by writing thoughts as quotes attributed to wherever they came from. Meanwhile, Article 13 creates some unspecific obligation to filter copyrighted content (with whether our systems are sufficient being anyone's guess), then bungles an attempt to create an exemption for us, so that whole thing is asking for regulatory creep. Overall, the whole thing is quite menacing to our project and goals, and I'm more than willing to sacrifice a couple hours to help stop it. —Compassionate727(T·C)18:51, 4 July 2018 (UTC)
@Compassionate727: As with one of the comments above, something I think is missing is the enforcement part of this rulemaking, and what the projected impact of that would be, do you have a good way to explain it to the common reader what happens if: (a) These new EU rules become active and (b) Wikipedia just ignores them. — xaosfluxTalk20:36, 4 July 2018 (UTC)
I think this is the right approach to take in terms of thinking about it. What happens if this passes and we ignore them? Then the major platforms extend their monopoly power, as competition is suppressed. (Google and Facebook can afford this - their smaller competitors cannot.) That increased power means more and more leverage to squeeze out free culture entirely. A symbiotic relationship will emerge between the copyright lobby and big platform lobby, with ordinary people left out. There is only one group who has both the power, and the motive to defend free culture. That is us.--Jimbo Wales (talk) 22:59, 4 July 2018 (UTC)
Thank you Jimbo Wales this is the part of the message that I think is missing, while I think WMF can "ignore this" for direct impact, the indirect impact (e.g. on availability of sources, local governments restricting access) demonstrates how this may hurt many more people. When trying to engage our readers I don't think we are giving a very solid message - we are saying "we think this is important" but not why "this matters to you". Unfortunate for this matter our huge North American readership doesn't have representation to engage though. — xaosfluxTalk03:31, 5 July 2018 (UTC)
Oppose Enwiki Blackout both strategically and logistically it would be better to do so in advance of a September vote rather than doing so for the current one. power~enwiki (π, ν) 21:27, 4 July 2018 (UTC)
I support a blackout in advance of the September vote and will campaign for it if necessary. But I think it would be strategically sub-optimal. As explained above, the chances of victory in September are much lower, and the vote tomorrow is about allowing for debate in Parliament in September. It is therefore easier to convince parliamentarians now.--Jimbo Wales (talk) 22:56, 4 July 2018 (UTC)
Support The site was blacked out for the Americans for SOPA on the understanding that similar action would be taken for other countries. Hawkeye7(discuss)23:01, 4 July 2018 (UTC)
@Hawkeye7: one big thing to consider is audience. enwiki has a huge US readership that has representation related to SOPA, but much less for EU matters (i.e. our US/CA readers are not governed or represented by the EU), so the geonotice makes more sense. — xaosfluxTalk03:34, 5 July 2018 (UTC)
Support. stand in solidity with EU Wikipedia.Italian, Spanish, Latvian, Estonian, Polish, Catalan, Galician Wikipeida went dark and Slovenian and Hungarian sites put up banners. A few hours in convenience in EN Wikipedia is too small to compare with the threat to free culture worldwide. I remembered when SOPA incident before I join Wikipedia, seeing that was profoundly important in understanding of such threat. It is general Wikipedia do not involved in political matter, but an existential threat to Wikipedia is another matter all together. CASSIOPEIA(talk)00:33, 5 July 2018 (UTC)
Tentative Support. A blackout would definitely send a message, although I wonder if it would be better timing to save it for the September vote instead. There is also the already-running banner to consider. I don't believe a blackout for a few hours would have a significant adverse impact our users, though. The world can survive without us for a few hours. — AfroThundr (u · t · c)03:49, 5 July 2018 (UTC)
Support I do not believe this passing will result in Wikipedia ceasing to exist, but I do believe that this passing in its current form will significantly affect the functioning of Wikipedia. The lack of freedom of panorama makes Commons super complicated. Imagine if how many words we can use within a quote varied by the EU country of publication? Upload filters would suck for commons (it is not clear we are truly exempt per the entire sentence in the document in question). While the media and publishing groups are trying to frame this as a disagreement between them and Google, I do not believe that. Google in fact may benefit from the current proposal. This is more the large platforms and publishers attempting to divide the Internet between themselves while pushing out the open movement. We need to stand up for and defend our movement and an open Internet. Doc James (talk · contribs · email) 03:59, 5 July 2018 (UTC)
If a September blackout still seems necessary at the time (cynical prediction: yesofcourseitwill), we should be planning for it more than two or three days in advance; we missed our chance this time around, though it was ultimately unnecessary. I'm not comfortable putting a bolded support here, though, since I don't geolocate to Europe and so presumably will be unaffected. —Cryptic11:34, 5 July 2018 (UTC)
Actually, I think it would be prudent if we could go over the text as it was, and annotate it collectively. Noting concerns with the areas in question, indicating what usecases we consider to be critical to be possible within the framework, red lines, alternative suggestions etc. and then providing this as feedback to MEPs. Anyone else willing to work on something like that ? —TheDJ (talk • contribs) 11:46, 5 July 2018 (UTC)
The directive should be getting a substantial reworking. Hopefully what comes out of that will take our and others concerns into account. But if it remains problematic we need to be ready to act again. Doc James (talk · contribs · email) 11:49, 5 July 2018 (UTC)
Oppose any further activism, until we have a clear consensus-based guideline to handle such situations. The constant disregard for valid concerns from a significant large number of editors and the rushed PoV pushing in favor of yet more activism are deeply worrying. As noted, I am not totally against emergency actions in exceptional cases. But the current handling ignores the underlying fundamental question (should Wikipedia be politically active and if yes, when and how?) and cements a notable divide within the community instead of looking for an acceptable and clearly-worded general consensus. GermanJoe (talk) 13:20, 5 July 2018 (UTC)
Comment I have avoided these debates and decisions, including this one, since before SOPA basically because 'I don't get it' and 'it's not my field'. That, I suppose, makes me truly neutral. On the other hand, I am not institutionally opposed to us supporting the other language projects with a black-out or banner (after all, we run a banner and notices for other things and no-one expects such a thing to be wholely "neutral"). As far as it is suggested that Wikipedia is neutral about Wikipedia, that's seems a paradox, and a sophistry -- in many ways it makes no sense to anyone that an organization is neutral about itself (no matter, how much it tries) -- if the organization continues, than it must wish to continue as is, and is not neutral on itself, even if it loves and hates itself, that is not neutral. As for the current system of making the editorial decision organically within the basic Consensus model, that does seem the most "neutral" way to decide because there is no, it must happen, here, and must not happen there -- editor/editor(s) perceive a need, advertises centrally, and persuades others -- we already know the initial individual and institutional response is 'don't bother' and 'don't bother me', and that response will win-out most days and years, regardless of any politics. But if you are an editor that sees a need for more 'rules' in these decisions, go for it and get Consensus, but see above about the potential immovable object you will likely run into. -- Alanscottwalker (talk) 17:11, 5 July 2018 (UTC)
We did it!
No proposal here, but as this has been widely discussed here I thought it appropriate to note. We won as the EU Parliament voted NO.--Jimbo Wales (talk) 10:20, 5 July 2018 (UTC)
@Jimbo Wales: I thought the vote today was to have the whole EU parliament consider it in September with amendments. Is that still the case, or has the bill been fully rejected/killed in whole? Headbomb {t · c · p · b}13:43, 5 July 2018 (UTC)
This discussion has been about as thoughtful and reasoned as it gets at Wikipedia. Ideological differences are not resolved by debate but by numbers. Whatever the outcome, we should refrain from unsubstantiated statements (and section headings) implying a causal effect of presence or absence of a Wikipedia banner. Correlation is not causation. ―Mandruss☎22:55, 8 July 2018 (UTC)
ArbCom wants the community to come up with infobox inclusion criteria
Short version: In two RFARBs, the Arbitration Committee has said that it can/won't resolve the perpetual "infobox warring" problem, because this is a content and policy decision that the community has to make. We've been asked repeatedly by ArbCom to develop inclusion criteria for infoboxes so that "The use of infoboxes is neither required nor prohibited for any article" does more than resolve (or devolve) to "fight about it endlessly article by article and category by category". But this has yet to happen, and it won't be easy.
The discussion now open isn't an RfC for !voting, but a place to discuss drafting such criteria for eventual RfCing at Village Pump. — SMcCandlish☏¢ 😼 22:14, 8 July 2018 (UTC)
I just had to undo a bunch of disruptive moves from draft to mainspace by a newly autoconfirmed user (whom I've blocked). I'm sure we have some rate limits already (if somebody could point me to the details, I'd appreciate that), but whatever they are, they're not strict enough. This user was executing several page moves per minute. Surely that's not something most users need to be able to do. I'm sure a rate limit of one page move and/or creation per hour would satisfy the needs of 99.999% of our users. -- RoySmith(talk)14:22, 6 July 2018 (UTC)
@Cryptic: please note filter 68 does not apply to autoconfirmed users. @RoySmith: the autoconfirmed move limit is 8 moves per 60 seconds. Please note most moves are 2 moves (page+talk). — xaosfluxTalk14:31, 6 July 2018 (UTC)
Whew, thought I was going crazy. Second question: where are you getting the 8 per 60 seconds figure? I don't see any other filters restricting page moves in general, as opposed to ones by specific LTA. (They aren't particularly straightforward to search, though admittedly they aren't remotely in my bailiwick.) It's not in core or another extension, is it? —Cryptic18:04, 6 July 2018 (UTC)
8 per minute is too high a limit. Good point about the talk page doubling, but 8 is still pretty high. Do we have the ability to implement burst limits with the current software? I.e. 2/minute and 20/day? -- RoySmith(talk)14:53, 6 July 2018 (UTC)
Per Xoasflux, one per hour would prevent moving any page along with its talk page. Moving a template could easily require 8 moves (template, template talk, /sandbox, /sandbox talk, /testcases, /testcases talk, /doc, /doc talk), or more if there are archived talk pages. 8/minute is a sensible burst rate, but a limit of something like 24/hour may make more sense. --Ahecht (TALK PAGE) 16:18, 6 July 2018 (UTC)
Several (avoidable) issues about pagemove by new and newly-autoconfirmed editors/vandals have been resurfacing in the recent with filters proving ineffective. It is time for concrete proposal to restrict (move) ability to only Extended confirmed users. There are cogent reasons favoring this in this archived discussion which was incorrectly closed as SNOW. I am yet to see any reason not do this, except the usual and banal cliché that "this is a wiki that anyone can edit". –Ammarpad (talk) 16:21, 6 July 2018 (UTC)
Do we have a sense of how often pagemove vandalism happens compared with how often there are legitimate mass-moves done by autoconfirmed users? -- Ajraddatz (talk) 16:33, 6 July 2018 (UTC)
I don't regularly clean up pagemove vandalism, but I'd find it roughly the same amount of work to revert ten page moves as to properly histmerge even one good-faith cut-and-paste that should've been a move instead. And we'd see a lot more of the latter if we did this. —Cryptic18:04, 6 July 2018 (UTC)
re Ajr, Not sure if there's such stats, but it's pretty recurring issue lately. I saw many discussions on ANI and VP on this within past few weeks. –Ammarpad (talk) 18:08, 6 July 2018 (UTC)
New editors cut-and-paste moving instead is a good point. I think limiting page moves to EC could cause more disruption than it would eliminate. Natureium (talk) 22:18, 7 July 2018 (UTC)
This is a really good point. Its easy for an admin to clean up page move vandalism. A single messy history merge is going to be as much work as correcting a fairly large number of bad page moves. Page move vandalism is fairly rare too... Monty84500:51, 10 July 2018 (UTC)
The extended confirmed permission was created to enfore a specific arbcomm remedy on editing certain pages in inflammitory topic areas. Extending this to cover unrelated permissions to combat run-of-the-mill vandalism is a huge amount of scope creep. I know I supported this proposal the last time around, but the more I've thought about it, the more I've come to the conclusion that it would likely not have a net positive empact on the encyclopedia. --Ahecht (TALK PAGE) 18:18, 6 July 2018 (UTC)
That was before. Extended confirmed is no longer used only to enforce arbitration remedy. And this has nothing to do with scope-creep, it is simple technical restriction not screed of text advising new editors not move pages. –Ammarpad (talk) 18:31, 6 July 2018 (UTC)
Does this have anything to do with why I was hit with a rate-limit error yesterday? Damnedest thing; I'd never seen one before. — SMcCandlish☏¢ 😼 20:57, 8 July 2018 (UTC)
Autowelcome new registrants
Newcomers need a few reading links before they begin editing, and definitely before they begin creating articles or drafts. AfC provides too many reading links, and is geared towards someone already committed to writing a new topic. The welcome template reading links will catch many of them before they commit to an ill-advised topic. Too many newcomers' talk pages are created by speedy deletion notices or AfC decline notices.
It's a very old perenial proposal, but I can't find anything in any archive that provides a good reason to not do it.
The reasons sound as if they have been unreviewed for about six year.
Responses to the reasons for previous reject:
1. If bot-weloming is cold and impersonal, then being completely ignored is absolutely shilling.
2. Vandals can be exposed by a red user_talk link? True, but primitive, and the technique still works by looking at the color of the user link.
3. An estimate 1000 welcomes for every non vandal that edits? This is a WP:PERFORMANCE objection, and it reveals a lack of value for the registration process. It is not trivial to register, stuff to read, having to find a likeable never-used username, auto-welcome is far less an expenditure for the project than for the registrants.
Hostbot? Run by User:Jtmorgan, good, but, the welcome givne has zero reading links, too few. I see from a look at a few authors of new drafts that it is not catching many authors. Looking at new authors, it is common for the registrant to make their first edit, a draft page creation, a few hours after registering. I think for them, the welcome links would help and not hurt. It is also common for new registrants to wait a long time before their first edit, in which case Hostbot misses them.
I agree with User:Berean Hunter 21:08, 26 August 2012 "The real purpose of the welcome is about getting them off to a good start with some links". Welcomes are for giving the basic starting information, initiating a conversation is not a high objective.
User:Steven Walling 22:13, 26 August 2012 conclusion from a a German Wikipedia experiment, rings true, that: Shorter welcome templates are more effective.
My feeling is that template:Welcome is about right, not too many links. Line links for reading/following. Maybe a few less would be better. Template:Welcome only, with zero reading links, has too few.
The most common theme of opposition is that autowelcoming robs human welcomers of the chance to be first to give the welcome. While I agree that this is a downside, it is far short of compelling. Human welcomers, like Hostbot, wait for edits. Newcomers need access to the reading links before they start editing. Also, a great many editing editors are never welcomed. I suggest that human welcomers, and even Hosbot, could continue to thank new users for their first edits. A slight differentiation of the templates would be easy.
The proposal:
All new registrants on en.wikipedia.org are to have their user talk page created with {{subst:Welcome}}, with the modification to the signature to explain that this is an automated welcome. This should be done by WMF software working straight from the registration process, to be developed if the proposal is supported.
Accounts from other WMF projects, such as other language Wikipedias, will not be welcomed.
No. Sorry to be a wet blanket but a hand-crafted welcome is much better than a machine that welcomes silly vandalism. I put {{subst:welcome}} ~~~~ on a new user's talk page, but only when I think it would help the encyclopedia. Some people do not like receiving an automated welcome, and often they are the kind of academic person that we really need (I have seen that a couple of times, but can't provide a link). Edits made by someone with a red-linked talk page need extra scrutiny and a bot should not hide that. Welcoming vandals makes us look dumb and would encourage some personalities to think Wikipedia needed to be attacked because such a system is obviously silly. Johnuniq (talk) 03:53, 28 June 2018 (UTC)
The "hand-crafted welcome is much better" response I think is well answered by "hand-crafted welcomes are woefully failing to welcome newcomers when they need it most, which is after registration, and before their first edit.
Some people do not like receiving an automated welcome, sure, but the solution is to keep is brief, to the point. Most unlike Help:Getting_started. In this world, it is a common thing to sign up to things, and to immediately receive an emailed welcome providing the basic information. "red-linked talk page need extra scrutiny", yes, as do redlinked user pages. The counter point is that a newcomer seeing their own redlinked usertalk page is feeling a cold shoulder.
Welcoming vandals makes us look dumb? That's almost funny. Welcoming them before the vandalise looks like AGF not dumbness. I guess you really mean that welcoming obviously bad usernames looks dumb? I don't think so, everyone can understand what registration auto-welcome is. --SmokeyJoe (talk) 04:30, 28 June 2018 (UTC)
Thanks for the ping. If you check out the summary of message testing results the tl;dr is that even with automated messages delivered via tools like Huggle, a shorter message that is written in an informal, first-person language performs better. If we do want to try out an automated welcome, I'd just suggest writing it in a style that still feels like a person wrote it just for you. Additionally, some of the best help in such a message is to tell people how to contact a real fellow editor, not just give them FAQs or policy pages to read. Steven Walling • talk04:22, 28 June 2018 (UTC)
Thanks User:Steven Walling. You were writing some very interesting things on this topic six years ago. At the very least, I think it is time for a review. I think, going on feelings, that newcomers these days, setting aside the very much large number of spammers, are arriving with less patience, and your point is even more important now than then. --SmokeyJoe (talk) 04:33, 28 June 2018 (UTC)
Comment - I'm leaning to oppose because redlink talkpages are useful for detecting potential vandals and give an indication of "newbieness". My replies to redlink TP users are always different than my replies to bluelinked ones. I would propose a banner or automatic editnotice for newcomers instead. L293D (☎ • ✎)14:38, 29 June 2018 (UTC)
Oppose I don't think warning every new account is helpful. If the link they are pinged to isn't helpful, propose to change that page. I don't see how a redlinked talk page could feel like a cold shoulder. If they asked a question and no one answered, sure, but this isn't a social network, and we don't need to send everyone an impersonal automatic message. Natureium (talk) 14:46, 29 June 2018 (UTC)
Oppose - same reason as L293D, redlinked talk pages are the number one reason that I review an edit on my watchlist. It is very important to look at the first couple of edits made by a user to detect if they are vandalizing Wikipedia. It also allows me to add specific messages to their talk page (for example, if they are making good edits but using primary sources to cite the information). Daylen (talk) 06:46, 30 June 2018 (UTC)
Oppose per L293D and per the fact you'd just be welcoming vandals..... which would send out the wrong message, Also worth noting not everyone who registers immediately edits and some never do so again there would be no point welcoming them ...... –Davey2010Talk12:07, 30 June 2018 (UTC)
Support a trial. There needs to be concrete data and proper A/B testing to test an automated welcome message's effect on editor retention and rates of vandalism. Darylgolden(talk)Ping when replying05:21, 1 July 2018 (UTC)
I suggest looking at the quality of newcomers first edits, comparing new registrants pointed to 5P in a brief message, against new registrants ignored. —SmokeyJoe (talk) 23:05, 1 July 2018 (UTC)
Support trying out the use of a bot for this purpose; if the biggest concern regarding this proposal is that we'd welcome some bad-faith editors who don't "deserve" to be welcomed, and it would clearly help new users who are here to contribute constructively find their way around, that's definitely a good idea. Everymorningtalk to me00:21, 5 July 2018 (UTC)
Support something different: We should be auto-delivering some pointers to basic editing how-to, key policy summaries, etc. so people can get started. "Welcome" sentiments are something that real humans should deliver. — SMcCandlish☏¢ 😼 01:58, 5 July 2018 (UTC)
I think that’s an excellent idea, but not instead. I think new users need to see WP:5P, that shouldn’t hinder a notice on their tenth edit. —SmokeyJoe (talk) 10:25, 5 July 2018 (UTC)
There already is a notification for the tenth edit. (And the first, and hundredth, and each power of ten up to the millionth.) List of text here. Easy enough to customize that. —Cryptic10:56, 5 July 2018 (UTC)
Yes, it's odd to discuss a talk page on its associated non-talk page, but proposals tend to go here, so we thus end up with a slightly odd self-referential discussion. Wikipedia talk:Village pump isn't a good place, because it's so rarely used (just six sections in the last two years, several of which don't deal with the VPs), and I don't want to propose this at one talk page and leave out anyone who cares about the others but not the one where I propose things.
Why do the various VPs need to have separate talk pages? The Reference Desks share a single talk page (see Wikipedia talk:Reference desk/Humanities, for example), as do WP:AN and WP:ANI. WP:AN3 has a different talk page, but it has a different structure: each section's completely isolated, and it's template-populated, versus discussions at AN and ANI. How are the various VPs at all different from each other from a technical perspective? Aside from our choice to put proposals here, ideas at the idea lab, etc., is there any difference among them? It seems to me we could just merge all of them into one, and either we could retain the existing archives or we could dump everything into one big page, rearrange them chronologically, and create a single unified archive system for everything. Nyttend (talk) 02:17, 4 July 2018 (UTC)
I have a feeling this has come out on the Village Pump before, although I do not recall what the discussion said. Vorbee (talk) 06:56, 4 July 2018 (UTC)
I think that's actually a bit different; the person asked why the VPs have any talk pages at all, while I'm simply asking about merging them all into one. Nyttend (talk) 12:53, 4 July 2018 (UTC)
Do you mean that what ever section of the Village Pump one is on, clicking on the talk page will take you to the same talk page? Vorbee (talk) 14:36, 5 July 2018 (UTC)
I believe that's what they mean. I personally am not sure about it, but can see the argument either way Nosebagbear (talk)
Suggestion: Prohibiting anons from contributing to Wikipedia
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi,
Recently, I’ve heard of anons vandalizing pages, spamming on talk pages, etc. I really want to stop contributions from anons coming to us, not only to make Wikipedia free of clutter and vandalism, but also to prohibit under-13s from editing here according to COPPA. Anyway, bye! Peppa Pig the Second (talk) 13:55, 13 July 2018 (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.
Related changes with talk posts
I suggest that Special:Recentchangeslinked be expanded to also list changes to associated talk pages. Now, a link list page must have links both to the subject page and to the talk page in order for talk page posts to be listed. This could be done easier with links just to the subject page, and have the "related changes" list talk page posts as well. Iceblock (talk) 09:42, 12 July 2018 (UTC)
If I view related changes to Category:Moon, only article-space pages are shown. Changes to Talk:Moon are not shown. The same thing happens when I create a page linking to Moon. Changes to Talk:Moon are not shown in this case either (unless there also is a link to Talk:Moon). What I propose is to include associated talk page changes to these lists. Iceblock (talk) 20:02, 14 July 2018 (UTC)
Click on the "hamburger" icon to access the filters. Scroll down to "advanced filters". Click "namespaces". Select which namespaces you want.
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, all pages in the User: namespace are automatically noindexed by the software. I think if we simply tell people about this, we might stop a few spammy userpage creations.
We already have {{Base userpage editnotice}} which only shows for base userpage creations (not subpages). I think if we change it from:
If you want to draft an article, please create a userspace draft instead of creating it here.
You may also want to read Wikipedia:Your first article, which explains what is expected of articles on Wikipedia.
Articles or promotional content, including CVs or resumes, on user pages may be deleted. For more information on user pages, see Wikipedia:User pages.
to something along the lines of (alternate phrasings welcome of course):
If you want to draft an article, please create a userspace draft instead of creating it here.
You may also want to read Wikipedia:Your first article, which explains what is expected of articles on Wikipedia.
Articles or promotional content, including CVs or resumes, on user pages may be deleted. For more information on user pages, see Wikipedia:User pages.
This page will not appear in any major search engine listings.
then maybe some spammers will think "why bother?" They'd have figured it out soon enough after they created the page, but this way they don't waste our time.
I don't know what to do about subpages. We might not want to irritate frequent userspace-draft creators with a garish editnotice like this. But if there is some way to only display a notice to new users, something similar could be created. Suffusion of Yellow (talk) 22:11, 9 July 2018 (UTC)
Support: Easy anti-spam fix, and would also be nice for legit new users to understand (i.e., no need to be embarrassed about early-draft work). — SMcCandlish☏¢ 😼 00:33, 10 July 2018 (UTC)
Oppose all this will do is make it more likely for them to force indexing by a magic word if they are dedicated enough. TonyBallioni (talk) 01:17, 10 July 2018 (UTC)
(edit conflict) Savvy spammers bypass this. I'm no fan of security through obscurity, but I'm still reluctant to help unsavvy spammers along: they're not going to think "why bother?", they're going to google up the various ways to bypass this. I'd rather be deleting unindexed user pages than indexed articles and drafts, by far. —Cryptic01:18, 10 July 2018 (UTC)
Neutral: No harm in this, but not sure it will do anything either. I think the part telling them CVs/promotional content will be deleted (as rightly they're) just suffice.–Ammarpad (talk) 08:04, 10 July 2018 (UTC)
Oppose Per Cryptic, and I'd add why teach people how to be WP:NOTHERE? If there is some problem stuff cluttering up the servers is that existentially bad for us? If not, hold your nose and move along. NewsAndEventsGuy (talk) 11:00, 10 July 2018 (UTC)
Oppose. Either they have a spammy clue, or they do not have a clue. If they do not have a clue, nothing is to be gained from educating them. Spam in user pages is better than span elsewhere - and there are ways and means of getting spam elsewhere (mostly) undetected.Icewhiz (talk) 11:10, 10 July 2018 (UTC)
Oppose - I would be in favor if it wasn't easy to permit indexing (if __INDEX__ did not work for user pages, which I would personally like, but that would be the subject of another perennial discussion)... —PaleoNeonate – 12:24, 10 July 2018 (UTC)
Oppose:The last thing we need are spammers indexing their pages without even moving the shit to article space — FR+16:31, 10 July 2018 (UTC)
Oppose - If a user's intent is to spam, advertise, or promote, this proposal will basically them where they need to be adding their spam, advertising, or promotions... ~Oshwah~(talk)(contribs)07:36, 13 July 2018 (UTC)
I'm against this proposal. Edit notices are already very ineffective at conveying information to people because of banner blindness; the notices need to be made smaller, not larger, to be more useful. --Deskana (talk) 10:01, 17 July 2018 (UTC)
Oppose as this won't be helpful. As mentioned above, some may just add __INDEX__ to the draft to index it and this would also be WP:BEANS. Probably would do more harm than good. — MRD2014Talk12:22, 17 July 2018 (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.
Have two new permissions: File and Page Remover
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.
Hello. I am proposing that we should add two new user permissions: File and Page Remover. The reason why we should have these permissions is that if an discussion at WP:AFD and WP:FFD outcome is delete, someone with the permission could delete it and they wouldn't need to wait for an admin. The rules for Page Removers should be:
The user should have an account on Wikipedia for at least a year.
The user must have made at least 2,500 edits.
The user must display levels of familiarity with doing actions per consensus.
The user must not have performed any obvious vandalism for at least a year before applying.
The user also should have no WP:3RR and/or behavioral blocks for at least a year before applying.
The user must not delete files without consensus.
These permissions would absolutely improve the convenience of WP:AFD and WP:FFD discussions, it would also help to rid Wikipedia of attack pages and other vandalism. Thank you. In Memoriam A.H.H.What, you egg?. 09:31, 2 July 2018 (UTC)
Oppose The problem with that proposal is that such users would be unable to fix any mistakes they might make. We can't grant them the ability to undelete content because then they could potentially view sensitive material, and allowing them to view such material would require them to go through an RFA-like process anyway. I'm also not sure what problem this is supposed to solve. You wouldn't be granting these users the ability to do speedy deletions, deletions through AfD and FfD are not urgent, and there isn't a problematic backlog of AfDs and FfDs waiting to be deleted. --Ahecht (TALK PAGE) 17:14, 2 July 2018 (UTC)
Not an actual problem. If the page should not have been deleted, any admin could undelete it. The rate of errors, versus rate of business as usual, would be low, so it would be a net increase in productivity. — SMcCandlish☏¢ 😼 00:33, 4 July 2018 (UTC)
While I don't support this proposal, I have to point out that your comment isn't responsive to the nature of the proposal, which is to get more hands on deck for one particular bit of maintenance, not to vet them for adminship. WP:RFAs fail all the time for reasons that have nothing to do with the candidate's understanding of and trustworthiness around page deletion (most often for civility problems, or failure to fully understand some other, completely unrelated, policy or guideline). All it takes is one slip-up, e.g. pursuing the wrong person at WP:SPA, or having breached WP:3RR and accusing someone of vandalism when the community decides it was a legit content dispute, or insert a zillion other deletion-unrelated things. — SMcCandlish☏¢ 😼 00:40, 4 July 2018 (UTC)
Support unbundling the delete permission in general, but I'm not sure about this proposal. I don't think there should be two groups for deleting (especially since the software isn't set up that way currently). I don't think that being unable to revert your action is a serious argument against unbundling; event coordinators can only assign the confirmed permission and stewards can globally suppress an account name but under certain circumstances need to ask a local oversighter to undo it, to give two immediate examples of this that come to mind. I also don't think that people who can delete are instantly trusted by the community with the full toolset. I would personally trust them with everything, but I think there's a case to be made that 'block' is the big ticket item that prevents the community from handing out adminship more liberally. -- Ajraddatz (talk) 17:16, 3 July 2018 (UTC)
Somewhat OK with this. Agree not being able to undelete shouldn't be a showstopper here. Agree this should not be separate groups. Basically bring the "eliminator" group here. If so I think they should get: delete, deletedhistory, and maybe browsearchive. — xaosfluxTalk18:51, 3 July 2018 (UTC)
Yes, though I personally dislike the name eliminator and didn't use it when making Pathoschild's global group (:P). Worth noting that other wikis tend to include undelete in the package but also have a one-week discussion period, making eliminator a sort of admin-lite with all the same bureaucracy to get it as regular adminship. I wouldn't want the same process to apply here, though it might be worth having a bit more in-depth process than PERM, whatever that might look like. -- Ajraddatz (talk) 19:28, 3 July 2018 (UTC)
@Xaosflux and Ajraddatz: see my comments below. I can’t imagine granting the ability that delete without the ability to view deleted content. We know the WMF won’t consent to that without an RfA equivalent process, which is one of the many reasons unbundling delete always fails to gain consensus: it’d turn into RfA, Jr. TonyBallioni (talk) 00:14, 4 July 2018 (UTC)
Why does it need to come with the ability to view deleted content? Strange without I suppose but not technically required. -- Ajraddatz (talk) 00:58, 4 July 2018 (UTC)
"Hi there. Seven months ago you deleted this page under the obvious vandalism! clause. I don't see how that can be, I remember it being perfectly reasonable. Please justify yourself immediately or I and nineteen of my closest friends will devote an entire WP:ANI archive page to making you look irresponsible. ~~~~" —Cryptic01:36, 4 July 2018 (UTC)
Heh, fair point. A sysop could always provide the deleted content or speak to it in such a case, though that would certainly not be ideal. Then again none of this is ideal; but if we want to better utilize the hundreds of users who are involved in deletion-related processes who have no desire to go through RfA this is something we should start to think about. -- Ajraddatz (talk) 01:43, 4 July 2018 (UTC)
Regardless of the merits, I don't think "backlogs via NACs" at AfD and FfD are a pressing enough (or at all) concern to justify this proposal. Basically, I think the above is coming at this from the wrong direction and on unsure footing. ~ Amory(u • t • c)19:11, 3 July 2018 (UTC)
Agree with this - a better rationale for general unbundling of the delete permission would be to allow trusted users to become involved in the deletion process (beyond NACs) without needing to get the full sysop bit, with the need part being the distinct lack of people willing to go through RfA. This could apply to CSD tagging and deletion discussion closing. I doubt that unbundling the delete permission would ever get serious support, especially since a couple of RfAs have passed this year so people think the process is unbroken again and thus further devolution isn't needed. -- Ajraddatz (talk) 19:28, 3 July 2018 (UTC)
Oppose I agree with Fastily. If someone can be trusted with page deletion, why not trust them with all the tools? If there's really a problem with not enough admins, make adminship "no big deal" again. Natureium (talk) 19:34, 3 July 2018 (UTC)
Users carrying out administrative tasks should be held to WP:ADMINACCT whether or not they have the admin bit. You can't do that with deletions unless you have deletedhistory and deletedtext permissions, too. —Cryptic19:40, 3 July 2018 (UTC)
Comment This would be useful beyond the cases mentioned here. Last week I had a new page in my user space, but when I went to move it to the mainspace, I was unable to do so due to a redirect page being in the way For some reason I mistakenly thought that I could move a new page over a redirect. Had I known that I could not, I would never have created the new page in the first place. If I had this permission, I could have deleted the redirect page and then moved my new page. As it was, I had to file a WP:Requested Moves request. Of course, this was not obvious vandalism, but an uncontroversial technical move (G6). I would expect thoigh that it could be used on any Wikipedia:Criteria for speedy deletionHawkeye7(discuss)20:17, 3 July 2018 (UTC)
Oppose as the ability to delete needs to come with the ability to undelete abd view deleted content. The WMF will not consent to this without an RfA equivalent process for legal and political reasons. Community opinion on this simply doesn’t matter as it would be vetoed by the office. TonyBallioni (talk) 00:09, 4 July 2018 (UTC)
Support in theory but not this particular proposal. Deletion is not as dangerous as people think it is (it can always be undone), but various aspects of this are a bit daft. We don't have hard requirements of a sort this specific even for full adminship, for starters. A more specific criticism would be that being active at AfD doesn't indicate anything. There are AfD regulars who are rabid inclusionists and rabid deletionists who are both too often wrong. There are also rubber-stampers who never !vote at AfD unless they're already sure where the consensus will go, because they're trying "sculpt" their AfD stats for a run at WP:RFA some day. Doesn't indicate any understanding of deletion policy. A solid WP:CSD-tagging track record would be a better indicator. — SMcCandlish☏¢ 😼 00:30, 4 July 2018 (UTC)
Oppose: I'm not sure I can fully support this proposal as written, given the low standards required. It, indeed, might be best for us to revert to the "RfA is no big deal" if this gains traction: I am entirely uncomfortable with the idea of particular users, through user permissions (which, though no offense is intended to the administration, are granted solely by one person, and sometimes as a matter of course), being able to delete pages without the whole of the community weighing in on said person's suitability. (Moreover, if this passes, the inherent security issues glossed over in the proposal are a serious concern.) In short, the RfA process is the right place to go for this, and not a new permission. —Javert2113 (Siarad.|¤)00:49, 4 July 2018 (UTC)
Oppose. I would be very surprised if (delete), (block), or (protect) ever get unbundled from the administrator toolset. Everything else, maybe, but these three seem to be the "core" set of admin tools. I'm not too familiar with WP:FFD, but at least for the past year administrators have been pretty good about closing WP:AFDs on time. The administrative backlog isn't so egregiously long that we need to change our process from how it's been for 15 years. Mz7 (talk) 02:21, 4 July 2018 (UTC)
Oppose While I would actually rather enjoy being able to close FFD discussions properly and completely since file maintenance is my specialty I still do not believe that delete, protect, or block should ever be unbundled from the admin toolkit. Those three all play off well with each other and like others have mentioned, if you delete it you should be able to bring it back. If you want any of three abilities WP:RFA is your only option and I would prefer if it stayed that way. --Majora (talk) 01:01, 10 July 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Bot archive all article talk page sections unchanged for five years
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.
Several years ago I proposed something like this here, and was told by one of the regulars (in a frankly patronising manner) that there was no need to worry about this, as in a matter of months if not weeks the old talkpages would be swept away by the new social media-style set-up, Wikipedia:Flow. Well, here we all are, and the average less-frequented talk page still goes back to say 2006. So once again I propose we set up a bot that auto-archives all article talk page sections that have not changed for 5 years (or 7, or 3, whatever). Few of the ancient points are still at all relevant, and the pages give a very bad impression - often referring to a totally different text. I'd imagine this is fairly easy to get set up, if the support is there. Johnbod (talk) 23:40, 25 June 2018 (UTC)
social media didn't replace talk pages. Pros and cons with proposal. Archiving makes information discovery harder, finding unknown unknowns. Posts are dated so no chance of old threads being mistaken for new and they can contain FAQs and other still-relevant material. They can also contain outdated information and embarrassing comments from early career days. In balance I would weigh on keeping data as open and accessible as is practical ie. not archiving except for constraints of size or frequency. -- GreenC00:24, 26 June 2018 (UTC)
On highly-viewed or well run talk pages old threads are archived long before this, but on neglected ones they just sit there forever. There is every chance of "old threads being mistaken for new" - I not infrequently see people "replying" to random comments over 10 years old, clearly without realizing this. Many inexperienced users assume the newest posts are at the top. Actual FAQ sections should of course not be affected. Johnbod (talk) 01:56, 26 June 2018 (UTC)
I don't see how this would help anything. Edits rearranging talk pages, however minor, makes tracing history harder. Johnuniq (talk) 07:17, 26 June 2018 (UTC)
Rather, it's that on those talk pages, the benefits of archiving are considered to weigh up against the downsides; on inactive talk pages, the benefits of archiving are significantly lesser and do imho not weigh up. While yes, inexperienced users (as well as folks just not paying attention) may occasionally mistakenly respond to a really old comment, they likely were already looking to post something on the talk page. People, especially new editors, generally only visit the talkpage to either use it or see if something's been said about a particular subject. In effect, it doesn't matter particularly much whether their response is to a decade-old comment or on a freshly archived talk page: when a talk page hasn't received edits in five years, it's close to a given that unless attention is attracted to said talkpage comment by other means (e.g. helpdesk or teahouse, or by means of the editor committing problematic edits resulting in heightened scrutiny on all their edits) no one is going to respond either way. If the talk page has received more recent edits, it's just particular sections that haven't, it's likely to be on people's watchlists and much like folks are perfectly capable of handling new editors who respond on the wrong part of a user talk page, they're perfectly capable of handling new editors responding in the wrong section of an article talk page. (And if it isn't on people's watchlists, much the same goes as for the fully-dead talkpages: it wouldn't matter whether they respond in the right or wrong section when no one's around to reply anyway) AddWittyNameHere (talk) 20:34, 26 June 2018 (UTC)
I really don't see the problem with talk pages containing old posts. Ideally, we would want to have all the past discussions clearly visible on one page, and noramlly archiving enters the picture only when that page starts getting too long. I don't think we should be fragmenting the history and making it more difficult to access past discussions unless there are clear benefits and they outweigh the risks. I don't know how common it is for new users to reply to old posts mistakenly taking them to be still relevant, I can't recall seeing that happen. I do recall seeing new users make proposals that have been rejected before simply because they haven't learned about the archives, and I've seen editors mess up the templates so the link to the archives disappears witout anyone noticing for years. – Uanfala (talk)11:54, 26 June 2018 (UTC)
Really, do any of you ever look at unarchived talk pages? They are very very rarely worth reading at all beyond 3 years back, and give a pretty bad impression to the uninitiated. Typically there are complaints from c. 2006 about basic failings that were no doubt justified at the time, but are now completely irrelevant. If any good point is raised and a discussion started, that is liable to get archived anyway. A properly-written bot would get the edits right. Johnbod (talk) 14:45, 26 June 2018 (UTC)
Almost all of the article talk pages I look at are unarchived. If there are old posts on a talk page that an editor deems distracting, they can always set up the archive themselves. – Uanfala (talk)20:41, 26 June 2018 (UTC)
On less active topics, old posts are often very relevant. See Talk:Tirana for example, which has never been archived, and is currently at 32,160 bytes (not too large). See Talk:Tirana#About the name! which still ought to be of interest to current editors. Someone started that thread in 2005, and there is a new (apt) contribution from 2008. Also Talk:Tirana#Tirana or Tiranë. It's a perennial proposal to change Albanian cities to the indefinite form (ë instead of a) and that talk thread is quite germane. It was started in 2007 and there is a later contribution from 2009. Under the above mass-archiving proposal, both of these useful threads would be sent away into Archive 1. EdJohnston (talk) 15:32, 26 June 2018 (UTC)
Yes, unless saved, before or after archiving, by someone adding some comment now (like "Best not archived"). Or by making/adding to an FAQ header. Incidentally the top section here illustrates one of my points: a post from 2003 is replied to in 2005 and then in 2012, probably without the last poster realizing he is talking to departed users. Johnbod (talk) 16:59, 26 June 2018 (UTC)
Support Good idea. I see new editors getting confused by really old talk page messages. IMO archive everything older than 3 years maybe (keeping at least two of the most recent posts). Put a link to the archive at the top of the page with the ability to search said archive. Doc James (talk · contribs · email) 19:14, 26 June 2018 (UTC)
Weaker Oppose especially if you mean all kinds of talk pages (not just ns:1) without someone doing some database diving this sounds like a recipe to create possibly millions of pages. For example File talk:'The Morning of Sedgemoor' by Edgar Bundy, Tate Britain.JPG - what is the benefit to anyone of creating a sub page, copy-pasting this content, and creating an archive header? Any busy talk page can already request archiving. — xaosfluxTalk19:47, 26 June 2018 (UTC)
Actually I only meant article talk pages, & have amended at top to clarify. The talk pages of the types you mention normally so rarely have anything at all I agree it's not worth it. And when they do it is more likely to have lasting relevance. Johnbod (talk) 21:09, 26 June 2018 (UTC)
Thanks for the note, weaker oppose - but would still want to see some numbers (and we would never approve a BRFA that can't estimate the load - and if it would be 100,000+ pages it will need a LOT of consensus). — xaosfluxTalk02:21, 27 June 2018 (UTC)
I'd see this as something that only needs to run say annually or bi-annually, and is obviously not urgent, so could be broken down into manageable chunks. I'd like to see some figures too, but I'm afraid I've no idea where/how to get them. Anyone? Johnbod (talk) 13:57, 27 June 2018 (UTC)
Support Makes sense to me. Old talk page messages could be confusing (though I'm wondering if this would be restricted to a specific namespace or not), so this sounds like a good idea. SemiHypercube (talk) 20:16, 26 June 2018 (UTC)
Actually, no it doesn't; at all. In fact the default 90-day archiving is part of a rather different problem, giving us a bunch of talk pages with 60 or 70 archives that contain almost nothing. Of course the page you link to is entirely incomprehensible to those not professional or keen amateur IT people, and I suspect to quite a few who are. You don't "just add" that at all - it seems you have to go off to a choice of other incomprehensible pages (selected how?) and do something or other there. Then it will archive far more frequently than is usually desirable, annoying User:GreenC, Johnuniq, and others above, as well as me - I don't usually like to see anything more recent than about 9 months archived. These are the reasons such auto-archiving is rarely found, and sometimes removed when it has been added. If there was a simple template for a one-off archive of sections unaltered for over x years then yes, that would go about 10% of the way to solving the problem. But apparently there isn't. Johnbod (talk) 00:05, 27 June 2018 (UTC)
So then people can change the day can't they?..... it's not rocket science and we shouldn't be treating people like they're thick nor should we be spoon feeding them, "You don't "just add" that at all" - Well .... you do .... you copy and paste it = problem solved, Well if you dislike seeing anything over 9 months you're more than welcome to use WP:1CA, Again I feel this is a solution looking for a problem. –Davey2010Talk01:53, 27 June 2018 (UTC)
That only does a section at a time, and "due to Technical 13's indefinite ban, it is currently unmaintained". Not the same at all. Johnbod (talk) 02:00, 27 June 2018 (UTC)
Well doing a section at a time hardly takes up a lot of time does it ? .... But now that issue's been resolved I'm still seeing no reason for this.... –Davey2010Talk
Oppose per Ed. If there's barely anything happening on a page, it's nice to have context. Do people sometimes ignore or miss the dates, and necropost? Sure. Does it really matter at all? No. Not sure what the harm is in having someone try to comment on an old post; if folks are watching, it'll get replies, and if people aren't watching, then no harm done! Don't see any gain or benefit. ~ Amory(u • t • c)01:08, 27 June 2018 (UTC)
Based on my experience – which I readily grant is not everyone else's experience, but which is also sufficient to not be dismissed with a "Really, do any of you ever look at unarchived talk pages?", eh? – I would have qualms about an automated implementation of across-the-board archiving. Yes, I do see very infrequent instances of less-experienced editors posting replies to talk pages without realizing that they are adding to threads which have been quiet for years. More frequently, however, I see less-experienced editors creating redundant new threads on talk pages, dealing with issues that were talked to death in threads already archived. Out of sight is out of mind. If we are attempting to protect newbies (and not-so-newbies) from confusion and wasted effort caused by old talk pages remaining visible, we cannot discount the confusion and wasted effort suffered by newbies (and not-so-newbies) who don't know there's another layer of extra-buried talk pages behind the regular talk page. Speaking anecdotally, I know that less than 24 hours ago I made improvements to an article driven by fresh comments in a talk page thread last edited in 2013. Infrequently-edited talk pages are often associated with infrequently-edited articles; issues that existed five years ago can and do linger unresolved. Consequently, a blanket imposition of automated archiving is problematic. If a talk page isn't desperately cumbersome, 'cosmetic' archiving provides little benefit. Manual or semi-automated archiving (where the talk page's and article's editors determine acceptable thread counts, talk page sizes, and so forth, within reason) is much less likely to throw the baby out with the bathwater, and helps to retain a talk page's focus. TenOfAllTrades(talk) 01:37, 27 June 2018 (UTC)
Talk page threads, if closed/handled, give users a glimpse in how the article reached its current status: reading a discussion on why a certain section is written in a certain way is much easier than digging the history. If not handled, discussions may be relevant for many years to come: there is no deadline and I often find useful suggestions which are 5 or even 10 years old. Age is not a predictor of usefulness. --Nemo14:27, 27 June 2018 (UTC)
oppose The only reason, ever, to archive talk pages is because they have become unmanageably long. Simply archiving them because they are old hides useful information. Mangoe (talk) 15:24, 27 June 2018 (UTC)
Support There's a lot of lesser-watched pages on my watchlist that get comments on threads that are several years old. Timestamps do not fix basic stupidity or ignorance of WP:NOTFORUM. Ian.thomson (talk) 19:54, 27 June 2018 (UTC)
Oppose There's no problem to be solved here; none was even expressed. And in certain articles it would do harm. North8000 (talk) 20:38, 27 June 2018 (UTC)
Oh, you misssed "Few of the ancient points are still at all relevant, and the pages give a very bad impression - often referring to a totally different text", expanded on by various people above. Our talk pages are so full of crap it discourages people from looking at them or using them; we can at least get rid of the really old crap, which is either the usual nonsense, or if there is a valid point, it will almost always have been fixed many years ago. Johnbod (talk) 02:20, 29 June 2018 (UTC)
Oppose archiving talk pages for any reason other than the one expressed in the lead sentence of Help:Archiving a talk page: "It is customary to periodically archive old discussions on a talk page when that page becomes too large." Lightly used talk pages should never be archived, especially if such pages contain discussions crucial to the substance of the article's content or if there are past exchanges regarding WP:Requested moves. Roman Spinner(talk • contribs)03:25, 29 June 2018 (UTC)
Oppose: I cannot see the use of this, quite frankly. I follow several articles and talk pages that are long enough, chronologically, to be archived should this proposal pass, but they're simply not long enough in terms of length; archiving for archiving's sake is rather unnecessary, I believe. And there's really no issue here that requires a resolution; moreover, I believe this idea, if implemented, might substantially degrade the rate of usage of talk pages. I mean, to drop the high-falutin' talk for a second, let's be real: if Alex Q. Public saw an empty talk page (with archives and whatever) for article Orange, do you think they would add to it? No: it's hard being the person who speaks up, more so when an empty page exists. I rest my case. —Javert2113 (Siarad.|¤)04:12, 29 June 2018 (UTC)
Oppose: I don't think there's a pressing need to archive *every* talk page on Wikipedia. Generally, if I come across an old Talk page with lots of old comments, I'll manually archive it or set up an archive bot. It's a bit of a hobby of mine. I think that is sufficient for dealing with the rare page that has gone too large without archiving. — The Hand That Feeds You:Bite18:51, 29 June 2018 (UTC)
Oppose. Odds are that a talk page that hasn't been archived in five years is talking about issues that nobody has settled in five years. It seems excessively optimistic to imagine that there are gnomes running around fixing problems on a mainspace page without dumping some manner of poo on the talk page in sufficient quantity to have forced an archive. Wnt (talk) 21:12, 1 July 2018 (UTC)
Oppose - Most of the time it's going to be appropriate, but it's not worth those few times that a thread does pick back up after several years, or those times when an older thread provides important context on little-watched pages. — Rhododendritestalk \\ 16:49, 2 July 2018 (UTC)
Not a good idea. See the first section of Talk:Edward Smith-Stanley, 12th Earl of Derby, which began in 2012 and has just been resumed. Yes, this is an unusual situation, but "do X in all situations" is appropriate only if X will never be problematic, or if doing X is a significant improvement and it's worth a few problems. This isn't a significant benefit: if you ignore talk pages with banners only, most of our article talk pages have had only a tiny number of comments, and archiving would be confusing. One week ago, this is what Smith-Stanley's talk page looked like. Even if the issue had gotten resolved in 2012, why archive? It's just one discussion, and you'd be creating a separate archive page for it. I just now hit "Random article" until I found one with a talk page comment, Talk:Quantum mirage. Is it a good idea to have a bot create an archive for pages with this history? This one's exceptional, with no datestamp, but if that post had been properly signed, it wouldn't affect my argument. Nyttend (talk) 11:39, 3 July 2018 (UTC)
Oppose I don’t really agree that the reasons suggested for auto archiving are pressing enough for it to be done. Aiken D18:26, 4 July 2018 (UTC)
Support: Stuff that old is rarely relevant, and more often than not already resolved, weird old rants by anons, or weird old rants by editor A against editor B for some alleged slight and either of them active editors any longer. WP's talk pages are for working on content not memorializing people's ability to ignore WP:NOT#FORUM. — SMcCandlish☏¢ 😼 01:56, 5 July 2018 (UTC)
Oppose I frequently come across stubs that were tagged for notability 10 years ago and haven't had any major edits since. Often a quick peek at the talk page will reveal concerns that have not been addressed or plans to "wait and see if this topic becomes notable." Sometimes there will even be copyvio or promo content that was removed long ago and reinserted by a single-purpose account. There's no reason that this backstory should be more than a click away. –dlthewave☎12:35, 5 July 2018 (UTC)
Oppose unless the talk page is long. The talk-content may be highly relevant, if the article has also been inactive for years. Alsee (talk) 13:19, 8 July 2018 (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.
Remove .svg as a permitted file type
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.
.SVG files are unopenable on OS X devices. This makes it impossible for a user to upload a new version of an image, so they would have to upload a completely new image to replace it. Computer40«»(talk)06:36, 15 July 2018 (UTC)
SVG is the open standard for vector images and we're certainly not giving it up. I have no idea how your device can fail to support it, but certainly it would be a bug worth raising with your vendor. --Nemo08:08, 15 July 2018 (UTC)
In case this could help, SVG image previews are normally smaller PNG. If that is not the case, perhaps disabling the media viewer may help. Another relevant preference is related to math formula rendering: you could select PNG mode. I would still be surprised if no available browser for OSX can display SVG. —PaleoNeonate – 08:28, 15 July 2018 (UTC)
@Computer40: I'm very surprised that you would say this, because I'm using a Mac and SVGs open in Firefox and Safari just fine. (Safari's SVG support is terrible, but that's irrelevant.) You can also open, edit and save them in TextEdit or another text editor like BBEdit (you might have to override the application selector to use "All Applications"). I've uploaded thousands of SVGs with this Mac. As mentioned, Inkscape+XQuartz also exists. Jc86035 (talk) 10:44, 15 July 2018 (UTC)
I too am am on a Mac and have no problems editing and creating SVGs, using InkScape or editing the source in simple cases. As for opening apart from InkScape I can view them in Safari, use Quick Look to view them in the OS, and have a number of apps that can import them to other formats such as bitmap graphics. If the OP is having problems it is likely with particular files; despite SVG being a standard different apps have their own idea of the standard and sometimes output incompatible files. InkScape is good at opening such problematic files in my experience. If all else fails ask at the Graphics Lab for help with a particular image.--JohnBlackburnewordsdeeds10:55, 15 July 2018 (UTC)
For those prepared to pay, I find EazyDraw easier to use than Inkscape (which may just be familiarity). Its export to SVG has improved greatly in recent versions. Peter coxhead (talk) 11:29, 15 July 2018 (UTC)
It's absurd to suggest you can't open an SVG file on OSX. The OS may not come with the software to do that out of the box, but there's certainly plenty of apps around to edit SVG on OSX. I use OmniGraffle, which is a commercial product. MacSVG looks like a reasonable open-source tool, and others have been mentioned above (much as I despise XQuartz). — Preceding unsigned comment added by RoySmith (talk • contribs) 15:30, 15 July 2018 (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.
Greater consistency
In fairness to those who create articles, can something be done to bring together the rather loose criteria applied by those who review articles and the very rigorous criteria of those who are dedicated to trimming and deleting? Jzsj (talk) 20:22, 16 July 2018 (UTC)
I would propose that whenever a reviewer passes an article (as notable), that this must follow a check of references to assure that at least one reference is given that passes WP:SIGCOV. If they do not find such a reference and they still pass the article, then they must place a warning on its Talk page that it does not pass WP:SIGCOV and may be deleted. Jzsj (talk) 22:28, 16 July 2018 (UTC)
I suggest that you consider writing up an essay and posting it in your userspace. Some user essays are used a lot; I often get comments about my essay at WP:1AM. --Guy Macon (talk) 01:23, 17 July 2018 (UTC)
I think it's in the speedy deletion criteria, esp. A7: Wikipedia:Criteria_for_speedy_deletion#A7; no essay needed. That is, there's a specified pretty low bar needed to avoid speedy deletion. SIGCOV is still required, but this gives more time to work on that, and then off to AfD if it can't be found. Dicklyon (talk) 06:09, 17 July 2018 (UTC)
That's right. The NPP works to WP:NPPCSD: "In particular, an article should not be tagged for speedy delete under CSD A7 where you think the topic is not notable, or does not prove notability by the references included. This is a common misunderstanding. The standard under A7 is solely whether the content contains a credible assertion of importance or significance (whether it actually is notable is a subject for an AfD discussion, not for speedy deletion). Consider using a Notability tag instead of a speedy deletion tag." This links to the aforementioned essay, as does WP:CSD, which is a policy. Hawkeye7(discuss)06:12, 17 July 2018 (UTC)
This proposal is a poster child for the existence of VPI. IMO, this page is for well-formed proposals, not a place to develop a proposal.--S Philbrick(Talk)16:01, 17 July 2018 (UTC)
I am in the process of trying to make my way through all the policy and guidelines related to this and will reformulate my above proposal, possibly where proposals are developed rather than here. So let me call this one off, though I appreciate the guidance so far given. Jzsj (talk) 16:54, 17 July 2018 (UTC)
Meta: Consultation on the creation of a separate user group for editing sitewide CSS/JS
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In my opinion, the perennial suggestions section is useless. What if the community's opinion changes over time? Instead their opinions are censored to a box. The perennial section needs to go. Axumbasra (talk) 08:53, 27 June 2018 (UTC)
Nothing is censored, however, it does help cut down pointless, hopeless discussions before they happen. New person comes in, they don't know that RFA reform has been talked to death. This is where they learn it. Headbomb {t · c · p · b}11:21, 27 June 2018 (UTC)
I agree with Headbomb; the perennial box lets people know a subject has been done multiple times already. If the person reviving an old conversation has new information or some other reason to believe the situation has changed since the last edition, they should explain that reasoning in their post. — AfroThundr (u · t · c)12:10, 27 June 2018 (UTC)
I see keeping it as helpful. On top of reducing unintentional rehasing of old arguments, someone who wants to make a new case can look up why it was previously rejected and use that info to create a new proposal that addresses the previous objections.--76.65.41.59 (talk) 14:02, 30 June 2018 (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.
Schedules and salaries
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 think admins, bureaucrats, and all other approved editors should get paid for the work they do here. All approved editors other than RC patrollers, admins, and bureaucrats should be paid by the edit. Approved RC patrollers should be paid by the hour. Admins and bureaucrats should be salaried. Admins, bureaucrats, and approved RC patrollers should also have schedules. All bureaucrats should be scheduled M-F 8am-4pm except for major holidays in their country, Christmas Eve, and New Years Eve. There should be admins and RC patrollers scheduled at all times. I think this system will really work well for Wikipedia. 2602:306:3357:BA0:446A:81FF:8391:EC1D (talk) 02:45, 22 July 2018 (UTC)
Hello anonymous editor. We are all volunteers here because we want to be here. If no one wants to be here they can just move on with their lives. There are numerous restrictions on paid editing including terms of use requirements as well. Inflating your edit count just to get paid screams conflicts of interest and your edit count means nothing. Thanks for the suggestion but this isn't going to happen. --Majora (talk) 03:47, 22 July 2018 (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.
Turn off Wikidata weekly summaries
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.
User_talk:Timathom is an example of how much space these take up. The page is at 2 MB already, and growing every week.
Instead, the Wikidata weekly summaries should be posted to a single page on the English Wikipedia and anyone interested should be encouraged to put that page on their watchlist.
Alternate proposal: Send everyone who receives on of these weekly text bombs a message asking them to opt-in if they want to continue receiving them. --Guy Macon (talk) 03:54, 19 July 2018 (UTC)
I don't understand the proposal. They did opt-in. You're suggesting that they must re-confirm that they want to receive them, in case they change their minds? --Yair rand (talk) 04:16, 19 July 2018 (UTC)
My first choice is to not send them at all. Let the user "opt in" by watching a page where new Wikidata weekly summaries are posted.
My second choice is that they reconfirm. Many people abandon their Wikipedia accounts, and many others never bother reading their talk pages, yet the spam[note] keep arriving. Have you looked at User_talk:Timathom? How is this sort of thing beneficial to the encyclopedia?
Note:
Man: Well, what've you got?
Waitress: Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam; spam bacon sausage and spam; spam egg spam spam bacon and spam; spam sausage spam spam bacon spam tomato and spam; spam spam spam egg and spam; spam spam spam spam spam spam baked beans spam spam spam or Lobster Thermidor a Crevette with a mornay sauce served in a Provencale manner with shallots and aubergines garnished with truffle pate, brandy and with a fried egg on top and spam.
Wife: Have you got anything without spam?
Waitress: Well, there's spam egg sausage and spam, that's not got much spam in it.
Oppose They aren't spam. Individual users subscribe to them if they want to, and they can also unsubscribe from them if they want to, same with signpost, glam, education, etc. - and there is a long history of such newsletters being posted on user talk pages (the first one I received was August 2006, I believe). Thanks. Mike Peel (talk) 06:33, 19 July 2018 (UTC)
Comment This seems like a performance problem impacting other users, which is a proper reason to archive someones talk page FOR them. See no reason to change the delivery for everyone. I do also think that people who have not edited in 2 years qualify to be auto unsubscribed from newsletters as well. See no reason to change the newsletter delivery in general. —TheDJ (talk • contribs) 07:36, 19 July 2018 (UTC)
Oppose the options given. It's really easy to miss updates when having to rely on the watchlist to catch them, at least if one has a sizeable number of pages on the watchlist. A one-time reconfirmation thing wouldn't solve the problem (in so far as there even is a problem rather than a minor annoyance) just postpone it; doing repeated reconfirmations is going to get on people's nerves fairly quickly.
That said, while I don't consider newsletters spam by default, I do agree there is not much use to newsletters being posted to the user talkpages of long-inactive users. I could support a bot being ran every now and then to check the subscription lists and template subscriptions (which at least the Signpost offers as option, not sure if any other newsletters do too) for editors that haven't been active for over a year and remove those and post a message on the relevant user talk 1. that their subscription was cancelled due to inactivity and 2. how to re-enable their subscription if/when they return. That'd reduce the amount of automatically-delivered messages to long-term inactive editors without creating unnecessary hoops for active subscribers to jump through and while still keeping it easy for returning editors to renew their subscriptions. AddWittyNameHere07:49, 19 July 2018 (UTC)
Thanks for pinging me. I wish we could let people decide if they want to receive the newsletter on their talk page or not. I learned during the last survey about the Wikidata newsletter that people have many different reading habits, some get it via their talk page, some via a dicussion page, some others on the social networks. I want to let them the opportunity to follow the newsletter, the way they prefer.
I agree though that some inactive accounts could be removed from the list of subscribers. That would cause less spam, and also help me having a better view of how many people are actually following the newsletter. We currently have no automatic cleaning or bot, I'd be interested in digging more into that option. Do you know who takes care of it for the Signpost? Lea Lacroix (WMDE) (talk) 20:20, 19 July 2018 (UTC)
Oppose - Sorry if I sound extremely thick .... but what's difference between opting in for Wikidata messages and vanishing - and - opting in for Signpost messages and vanishing ? ..... Sure I'm not a Wikidata reader but I don't get why you'd choose this for Wikidata and not the rest ? ..... –Davey2010Talk16:38, 19 July 2018 (UTC)
Gotta start somewhere. If this were to pass (doesn't look like it will) I would have followed up with an RfC for the others. --Guy Macon (talk) 17:06, 19 July 2018 (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.