Article snapshot taken from Wikipedia with creative commons attribution-sharealike license.
Give it a read and then ask your questions in the chat.
We can research this topic together.
<noinclude>{{short description|Discussion page for new proposals}}{{pp-move-indef}}{{Village pump page header|Proposals|alpha=yes|
<noinclude>{{Villagepumppages|Proposals|The '''proposals''' section of the village pump is used to discuss new ideas and proposals that are not policy related (see ] for that).
The '''proposals''' section of the ] is used to offer specific changes for discussion. ''Before submitting'':
* Check to see whether your proposal is already described at ''']'''. You may also wish to search the ].
Recurring policy proposals are discussed at ]. If you have a proposal for something that sounds overwhelmingly obvious and are amazed that Misplaced Pages doesn't have it, please check there first before posting it, as someone else might have found it obvious, too.
* This page is for '''concrete, actionable''' proposals. Consider developing earlier-stage proposals at ].
* Proposed '''policy''' changes belong at ].
'''Before posting your proposal:'''
* Proposed '''speedy deletion criteria''' belong at ].
* If the proposal is a '''change to the software''', file a bug at instead. Your proposal is unlikely to be noticed by a developer unless it is placed there.
* Proposed '''WikiProjects''' or '''task forces''' may be submitted at ].
* If the proposal is a '''change in policy''', be sure to also post the proposal to, say, ], and ''ask people to discuss it '''there'''''.
* Proposed '''new wikis''' belong at ].
* If the proposal is for a '''new wiki-style project''' outside of Misplaced Pages, please go to ] and follow the guidelines there. '''Please do ''not'' post it here.''' These are different from ].
* Proposed '''new articles''' belong at ].
<!-- Villagepumppages intro end -->|]}}
* Discussions or proposals which warrant the '''attention or involvement of the Wikimedia Foundation''' belong at ].
* '''Software''' changes which have consensus should be filed at ].
Discussions are automatically archived after remaining inactive for nine days.<!--
{| class="messagebox" style="background: AntiqueWhite;"
]
|-
]
|This talk page is '''automatically archived''' by Werdnabot. Any sections older than '''7''' days are automatically archived to ''']'''. Sections without timestamps are not archived.
]
|-
]
|}<!-- BEGIN WERDNABOT ARCHIVAL CODE --><!-- This page is automatically archived by Werdnabot-->{{User:Werdnabot/Archiver/Linkhere}} <!--This is an empty template, but transcluding it counts as a link, meaning Werdnabot is directed to this page - DO NOT SUBST IT --><!--Werdnabot-Archive Age-7 DoUnreplied-Yes Target-Misplaced Pages:Village pump (proposals)/Archive--><!--END WERDNABOT ARCHIVAL CODE-->
</noinclude>
These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.
<br clear="all" />
{{clear}}
]
]
]
]
]
]</noinclude>
]
== Layered Pages ==
''']''': Might an option be made available for a user to create/access a scaled down, elementary lay version of an article that is highly technical? This would eliminate the jargon and other technicalities that may be present in the parent article.
:You mean like the ] attempts to do? --] <small>]</small> 11:13, 17 December 2006 (UTC)
:I agree. I would like to see a '''Non-technical summary''' info box included near the top of each article. Ideally it could be turned off in My Preferences. This would help me understand what the article was talking about and give me some mental framework to hang the rest of the article on. The Simple English Misplaced Pages does not have many articles on technical or complex subjects, which is where this is most needed. — ] <small>(]|])</small> 15:20, 18 December 2006 (UTC)
co-incidentally, i was just on my way here to suggest something similar.
basically, theres a problem with our target audience, i.e., given that our target audience is 'everyone', it's hard to get the depth and wordage of an article right, so that it's not too complicated for those who aren't allready knowledgable in the area, but still useful to those who are. eg, if i look up an article on genetics, then i dont want it too simple -- i want some complicated meat and bones, rather than an article that just puts simply what i allready know. on the other hands, i want articles that discuss maths to treat me like the mathematical retard that i am, and lay it out simple.
obviously, catering for me would piss other people off :-D. not catering for me pisses me, and similar people, off. so, you see the problem?
why not, at least for sci/tech articles, for decent articles (B-list or above, say), fork the article into simple, normal, advanced, and expert versions? example definitions could be:
'''simple''' presumes no background knowledge. aims to get the basic concept across, tho not neccesarily any details on how/why the concept is/works/etc
'''normal''' presumes basic/no background knowledge. aims to get the basic concept across, with some understanding of how/why the thing is/works/etc
'''advanced''' presumes some background knowledge. aims to get the concept fully accross, along with more detailed how and why
'''expert''' presumes deep background knowledge, and a reader that wants to fully and deeply comprehend the subject, and who is willing to wade through a complicated article to do so.
examples for, say, a tRNA article:
'''simple''': understandable without any background knowledge: for those who are simply interested in knowing what tRNA is and what it does, not neccesarily understanding exactly how it works nor wading through complicated bio-molecular/genetic jibberish
'''normal''' understandable by someone without any above-basic background knowledge in biology/genetics, but possibly a bit confusing (i.e., they could, with effort, understand what tRNA is, and, broadly speaking, how it works, from the article). probably useful to A-level students as a primer, but less useful to BSCs.
'''advanced''' let the scientific jibberish fly! useful to people with biological training. with a background in molecular biology, someone could come away from the article understanding what tRNA is and how it works, tho not neccesarily with an exam-passing understanding
'''expert''' for people who allready know the subject really well, and who want more esoteric info on tRNA, such as bond-lengths, etc. incomprehensable to normal people, but makes wp useful on the subject of tRNA to people who would have to work with tRNA in a professional setting.
i knocked up an example. note that i did it really quickly, and, as articles, they're shit. they just aim to demonstrait what i'm talking about.
the ] article, slightly stripped down, then forked into simple, normal, advanced and expert versions. ] (edit the demo articles if you want, i'm not going to mind just because they're on my user space).
what'cher recon? theres some gaps (between, say, advanced and expert, imo), and the system could be extended: maybe article/concise (brief as possible), article/verbiose (long winded, covering every aspect, with the kind of stuff which is usually clipped from articles to keep them of a sane size), article/data (lists of different tRNA molecules, average bond-lengths, links to genetic sequences, melting point, average molecular weights, etc), etc. etc. etc... --] 19:01, 19 December 2006 (UTC)
ELApro: I would assume that the old "Keep it '''simple'''" adage might apply. If there is a simplified version of the article in the ''Simplified English Misplaced Pages'' then there should be an auto-link function in the software to have the link created. This, by the way, might be similarly applied to WikiQuotes, or whatever other Wiki application exists for an article. Why not have an option to create a simplified lay person's page, if one does not exist and the current single option appears to be too complex for some lay reader. After a lay version is created, a lay version link from a normal Wiki page would be available for anyone considering the current main page too complex, and desiring a simplified introduction. Those satisfied with the original page can leave it as is, and those believing the original page is too complex, will either have an option to view a simplified presentation, or will have an option to create a simplified version. Let the users decide which original pages may or may not be suited to the typical lay person, by copying information from the lay page (if it exists) into the original page, and keeping the lay page simple. If an article is acceptably presented to all viewers, leave it as is. No changes necessary. Otherwise, an alternative option, only one, is available, linked from the original article. Any levels beyond two could be done by extracting information and customizing on one's own home computer, to suit one's individual taste.
:Simple English is different; it refers to language.
:However, I don't see much point. This all can be done, and is done, using multiple pages and navboxes. After all, diving deep requires more pages anyway. Well, it's just simpler as it is. ]<sup> ]</sup> |]| 15:17, 23 December 2006 (UTC)
ELApro: After an initial review of the ''Simple English Misplaced Pages'', I would disagree. It seems to be precisely what was requested. The only thing that remains to be done is to link all existing articles, hopefully in a manner similar to that described above by ]. This could be done either manually or automatically, but hopefully something could be done to ease or simplify the process. Thank you Jonathan for your valuable information and for seconding this proposal!
:The current way to link to simple English versions of articles is to put <nowiki>]</nowiki> at the bottom of the article, and the simple English version would be linked in the sidebar on the left with all the other language versions of that article. ] ] 18:50, 24 December 2006 (UTC)
== Redirect on Contribution pages, "redirect=no"? ==
::uhh....i think people just don't really have an opinion on it. I, for one, have almost never encountered the situation you've outlined. On the offchance i do click on a contribution that's a redirect, i just click the history or diff links instead to see what changes the person made. I suppose a better place to ask would be the technical section... --] 02:27, 22 October 2006 (UTC)
:::Yeah, this is definitely a good idea. ] is right - move this to a technical section and it'll get noticed and maybe even implemented. Good luck. ] 18:17, 26 October 2006 (UTC)
::I like the idea (found it annoying myself before), but yeah this may have been better on the technical pump. -- '']']'' 19:52, 26 October 2006 (UTC)
== Suggestion: New Yearbook about PC and Video Games ==
Hi,
I tried to find a place to submit this, but ended up here.
It's about a new post: http://en.wikipedia.org/Wikipedia:Articles_for_creation/2006-10-21#the_Book_of_Games_Volume_1_.28The_Ultimate_Guide_to_PC_.26_Video_Games.29
How long does it take before a new article is verified?
I am the publisher of the book, and would like to contribute if I could. Is it possible to get in contact with someone that will work on the article? We could send a press copy of the book to the person.
-Bendik Stang
== Expire (delete) unread articles ==
: '''' --] | ] 21:26, 5 December 2006 (UTC)
I suggest that articles which go unread for an extended period of time be automatically removed. After all, the goal of an encyclopedia is to transmit knowledge. So an article which is not being read is not a useful part of an encyclopedia.
It seems to me that the first thing to do is to obtain statistics on how often articles are being read, and get some idea of what consititutes an unread (or rarely read) atricle. Even without that, I would suggest the following standard for removing articles:
* An article which goes unread or unedited for 90 days should be automatically removed.
* Accesses by ] and the "random article" function should not be considered reads for the purpose of this standard.
* A user which selects pages at a rate of more than 100 reads per hours for 10 accesses or more should not have their accesses for that period counted as reads. The same should also apply to edits. (This is suggested as a way to thwart editors who would access pages to "refresh" their expiration timers.)
* A page which is deleted under this standard should
** be replaced by a template stating when and why the deletion occurred,
** have its article and discussion histories removed to prevent a trivial revival of the article, and
** be protected against being restarted for at least 90 days.
* Secondary issues:
** When the random article function is used, should the use of a link in the article cause it to be considered read?
** The editing of a article accessed through the random article function probably should reset the expiration timer.
I suspect that this may result in the removal of a substantial number of articles, but if no one comes to Misplaced Pages looking for information on a given topic, is it at all fair to consider that subject notable? --] | ] 05:57, 5 December 2006 (UTC)
::Here's a few questions: is the usage rate for all articles generally constant or are some articles read on a cyclical basis? Are articles related to Arbor Day and Halloween accessed more frequently as these dates approach? Could there also be articles related to these two topics, which are perhaps of a minor or marginal nature, and which might see no use at all except during some segment of the calendar year? A great many U.S. colleges and universities are operating on a reduced schedule during June, July, and August, and might not the fact that a majority of their students are away on vacation affect the usage of Wiki articles?
::Just generally I'm uneasy with the idea of deleting information (because the minute I trash something I'll have need of it) and I think this proposal has the potential to strike at the core of what Misplaced Pages is, or is not. If the Wiki is to set a standard as a knowledgebase I would think that ''completeness'' must be part of the perception, if not the reality, of what the Wiki is. And if the Wiki is not perceived as complete, in some sense, then I suspect it becomes less likely to be used as the first source referred to when a person first 'looks up' a particular subject. I also wonder just who the Misplaced Pages is intended to serve. Is it to be a useful reference for everyone, no matter how arcane or obscure ones interest may be, or is this to be an encyclopedia for the casual masses, who, for example, are intrigued by ''The DaVinci Codes'' and turn to the web just to read a little more and see what's out there?
::In other words, do we entertain the hope that Misplaced Pages might be perceived as a standard tool for serious research of some kind, at some point, if not now, or are we content for Misplaced Pages to serve as a kind of enormous fan infobase for devotees of a great diversity of topics? Both forms of Wiki would serve a valuable purpose, but they are not the same animal.
::Also, I feel it should be pointed out that anyone who wrote an article, only to find it deleted ninety-one days later, might well become disenchanted with Misplaced Pages, and thus disinclined to ever write to another article, or another, or another, because the fruits of their labor did not, in effect, ''sell'' to the reading public (or their search engines). You might also discourage other people from ever writing anything, out of the concern that their efforts would not be sufficiently popular to generate sustained interest, as the seasons turn. ] 17:29, 5 December 2006 (UTC)
::: With regards to cyclical reading: I find it hard to believe that ] would go completely unread for the rest of the year. The goal is to have a bar low enough so that an article that is of any legitimate interest will easily stay in Misplaced Pages. Perhaps the time on this should be 1 year instead of 90 days. (I actually suspect that much of Misplaced Pages is accessed daily, but a reasonably long expiration time is needed to protect marginal articles against the effects of randomness. For example, and article that gets accessed twice a week on average could easily have a month where it it not accessed at all. Hence the 90-day period.)
::: The concerns about Misplaced Pages as an enormous infobase and the concern over editors being disenchanted in their work vanishes are related. Once again I ask of what use an article is if it is never accessed or if anyone other than the creator cares that it is there. Such articles contribute to the article count, but do not contribute to the mission of the encyclopedia. It seems me that if an editor is not producing usable content that their becoming disenchanted is not a bad thing. In fact, we are constantly deleting undesirable/non-notable content. IMO, this is a wonderful test for non-notability.
::: As for "completeness": "] an indiscrimiate collector of information". It is not intended to be "complete". This leads to another consideration: If an article is not being accessed, it is not being checked for accuracy either. Remember the incident of that fake biography which created such a scandal within Misplaced Pages a year or so ago. That article went unnoticed for months. Under this scheme, it would have vanished of its own accord in a reasonable period of time.
::: Finally, do note that I have called for there to be a usage study first, so that the viability of this proposal can be determined. The "random article" function currently returns mostly stubs on parks and people that provide little usable information. It would be nice to see that buttom return more in the way of solid content more of the time. --] | ] 19:39, 5 December 2006 (UTC)
:This just increases systemic bias against important but less popular subjects. The Superman article would never be deleted by this, but articles about certain species or chemical compounds might. I just think this is a terrible idea.--] (<big>]]</big>) 21:30, 5 December 2006 (UTC)
:: Why in God's good name would you expect ] to be deleted under this proposal? It is an actively edited article and a regular target of vandals! Look at ! This article would need to have the Earth demolished by a kyptonite meteorite to go unread for any significant period of time. --] | ] 21:36, 5 December 2006 (UTC)
:::He said it WOULDN'T be deleted. Read his comment again. --] <small>]</small> 22:18, 5 December 2006 (UTC)
:Please no. The fact that no one on an electronic encyclopedia reads something for x period of time means very little. There's no cost to keeping it, and a detriment to someoen who eventually wants to use it. ] 21:39, 5 December 2006 (UTC)
:: If it's not being read, it's not being edited. If it's not being edited, the content is not being validated and/or improved. First versions on this medium are generally lousy, but if several editors are involved an article will improve quite fast. Also, given the current popularity of Misplaced Pages I would think that any useful article is highly unlikely to go unread for any significant period of time. --] | ] 21:45, 5 December 2006 (UTC)
:This proposal violates my general principle that bots must never be given more power than humans. The community would never allow such a blind massacre on AfD. An admin who repeatedly deleted articles without even glancing at their titles, content, histories, talk pages, logs, or linked pages would be reverted and desysopped. No amount of usage studies will change that.
:The software ''could'' help us out by generating lists of unread articles, which thoughtful humans would comb through in search of non-notability and vandalism. But the software cannot take any action that we wouldn't. ] 22:08, 5 December 2006 (UTC)
:: If an article is completely unread for an extended period of time, on what grounds would you consider it to be notable? --] | ] 22:22, 5 December 2006 (UTC)
:::Any of them. The existence of multiple, nontrivial, published reviews is a standard measure; there are others. Note that notability pertains to an article's subject, not the article itself. An article's readership can suffer from factors that have nothing to do with its subject, such as a poorly chosen title, insufficient incoming links, or improper categorization.
:::Moreover, notability is a criterion for deletion only because it tends to single out topics which are impossible to cover encyclopedically: they are so little-known that we cannot meet our content policies of verification and neutrality for an article. Your proposed process cannot identify these non-notable articles; it doesn't even care when the content standards have already been met! ] 01:51, 6 December 2006 (UTC)
This idea is patently absurd. There are many notable encyclopedic subjects which people only rarely would need to know about or research. For example, who's going to look up minor Senators of Alabama from the 30's? However, that is no excuse to go about deleting them when the information they contain is useful and necessary to our ''encyclopedic'' nature. ]s, in case you haven't heard, are supposed to be all-encompassing. Why should we delete pages simply because they are not of popular interest? This would additionally give us an even stronger bias towards the temporal and current vs. the timeless and historical. '''Rejected.''' --] <small>]</small> 22:18, 5 December 2006 (UTC)
Is this for real? This proposal is so absurd that it costs me a major effort to believe it was done in good faith. -- ] 22:23, 5 December 2006 (UTC)
:Hum. "I suggest that which go unread for an extended period of time be automatically . After all, the goal of is to transmit knowledge. So which is not being read is not a useful part of ." We were reshelving a bay at work today; I'm fairly sure some of those books hadn't been touched in four, five years. But they're still useful books, in potentia, they just need their reader to come along. I think the analogy is illuminating... ] | ] | 22:26, 5 December 2006 (UTC)
::Perfect parallel. I remember checking out a copy of ] from my library which hadn't been read since 1954. --] <small>]</small> 22:29, 5 December 2006 (UTC)
:I hope you tore it up, it was clearly not-notable. ] 22:32, 5 December 2006 (UTC)
:This is a phenomenally terrible idea. -- ] 01:32, 6 December 2006 (UTC)
::The proposer of the topic should consider WELL ESTABLISHED policies: 1) ]. There is no compelling reason to remove a well-referenced article merely to "make space". Misplaced Pages has infinite space. There are reasons for deleting articles, but simply to remove them because they aren't being used is silly. Consider the average University Library. They have millions of volumes, and only a few thousand are ever on loan. Some LARGE majority of the books in a University Library may go YEARS between check-outs. Yet, the university maintains space for them, not for the fact that they ''HAVE'' been used, but that they ''MIGHT'' be used. Past performance is never an indication of future performance. 2) Notability is established OUTSIDE of wikipedia, and is NEVER revoked. Once external, independant, third-party sources exist to verify notability, THEY NEVER STOP EXISTING. Thus, once notable, always notable. The fact that an article goes unread doesn't eliminate the existance of the sources used to write the article. Thus, there is no compelling reason to delete merely for lack of utility. 3) Misplaced Pages is a place to collect knowledge. To delete VERIFIABLE knowledge for any reason runs counter to Misplaced Pages's purpose. I would agree that this MAY be one of the worst proposals I have seen here. What purpose would it serve to delete a verifable and notable article? --]] 02:47, 6 December 2006 (UTC)
:Saying an article hasnt been edited/read for 90 days (excluding bots) so lets delete, I wonder how many FA would fall into that category. Even ignoring that Misplaced Pages is as much about the collection of knowledge as anything else, while we may write an article on something today because nobody reads or edits that page for 90 days doesnt invalidate the information. There enough stub, poorly formed or unsourced articles that survive AfD, how could it be contemplated to let a bot just delete an FA/GA because nobody as has read or edited it for 90 days. ] 03:15, 6 December 2006 (UTC)
What I am seeing are a lot of knee-jerk reactions, as if articles should be here because they are here. ] an indiscriminate collector of information. I really think that this is an idea that needs to be researched. How often are articles accessed? Are there articles which go largely unread? If so, what kind of content do those articles typically have? From there other questions will follow: Are these relatively unaccessed articles worth keeping? What do these articles say about the Misplaced Pages notability standads? Noone seems to have an answer to those questions. The concern about FA articles is valid, but I strongly doubt that topics which noone cares about become FA's. At the least Misplaced Pages should come to know how it is being used.
(BTW - I agree that blindly implementing this suggestion is a truly bad idea. You just plain don't do something like this unless you have a very good idea of what it is going to do.) --] | ] 03:25, 6 December 2006 (UTC)
:Any article can become an FA provided someone put the effort into researching and writing. then you proposal should be to find out how and what is being accessed, without the suggestion of deleting stuff. ] 03:30, 6 December 2006 (UTC)
:: The two kind of go hand-in-hand. I am making a certain assumption that unviewed material is almost certainly non-FA material. That assumption needs to be validated. It could be that stubs can be removed on this basis, but more fleshed out articles are better manually reviewed if not just plain kept. --] | ] 05:47, 6 December 2006 (UTC)
Good idea, wrong implementation. Instead of deleting them, have a Special:Unviewed page (or probably some better name) that would allow these articles to be identified. Then it gives people one more avenue to find articles that need to be reviewed. But certainly no automatic deletion. —] <sup>]</sup> 04:42, 6 December 2006 (UTC)
: That is an intriguing idea, and others have suggested above that a manual process would be more desirable. I can be flexible with this, as my concern is to remove the "clutter" from Misplaced Pages. Yet in the end I want something to come out of this that is a benefit to Misplaced Pages. I get a sense that there are a number of articles present that could be deleted but just are not worth the bother to find and flag. A system of this type may be able to cull things more efficiently. --] | ] 05:47, 6 December 2006 (UTC)
*Doug - we have ]. (]) 09:18, 6 December 2006 (UTC)
::The problem is here is that 'clutter' is a thinly veiled term for 'things I'm not interested in'. Why would you think that unread articles are 'clutter' that need to be removed? They are gems waiting to be discovered! ] 17:21, 6 December 2006 (UTC)
::: "Ancientpages" is not at all the same thing. I spot checked them and saw a collection of disambiguation pages and a few short (but well done) articles on small towns. I suspect that most (if not all) of these are accessed regularly.
::: I accept the insinuation about the meaning of "cluter". However, the issue is one of identifying what noone is interested in as opposed to what I am not interested in. 99% of this encyclopedia I will never use. At the same time, the relativity pages (which I edit) will never be read by 99% of the users of Misplaced Pages. I realize that this proves nothing.
::: Can anyone answer this question: I there are tracking a article usage currently? IMO, it would be interesting to track the last 10 non-bot/random reads to each article (by when and not who), as well as to maintain counters for the current and previous of each of day, week, month, year. (I don't know how much tracking data can be efficiently attached to an article. I am certain that doing so will make the database bigger, and that could be an issue. Perhaps a tracking database is what is needed.) --] | ] 17:54, 6 December 2006 (UTC)
Misplaced Pages is mirrored all over the place. This means it is impossible to know whether an article has been read or not; you can only find out if it has been read on a particular service (eg Wikimedia). A statistical survey might yeild interesting information (it would be especially interesting to know how well the read frequency correlates with the edit frequency), but I don't think editorial decisions like this should be made on such a crude basis.
] 19:24, 6 December 2006 (UTC)
: At least I am getting support for studying the usage patterns. I would not let the existance of mirrors bother you. The first question is how the mirrors are refreshed: If they only go to Misplaced Pages for content when it is requested (for example a mirror may seek the current article if it has been more than a day since it last retrieved it), then for the less-used articles the statistics will remain accurate and valuable. Even if mirror-related effects are not visible, Google tensd to send searchers straight to Misplaced Pages, so once again Misplaced Pages statistics should be usable and indicative of generally unread articles. As for whether this means is "crude": Until it has been studies, noone can say for sure how good or bad it is. We really should have the data instead of each of us "shooting fromt he hip". --] | ] 20:39, 6 December 2006 (UTC)
::a) Almost all mirrors are running from static dumps of varying age; very few are directly spidering Misplaced Pages or regularly updating. We have little to no knowledge of most of them, much less ability to get data.
::b) We just don't have article-read statistics. We can't generate them, not with the setup as is. Logging pageviews, the fundamental requirement for good statistics, has been estimated at about 7 terabytes of storage space ''per month'' across Wikimedia sites - your ninety days threshold would mean having to store and regularly study 20TB of logs. Even stripping that down to nothing more than a timestamp and a page-visited note would still be unwieldily large. The best we can do is very very limited sampling, hopelessly muddied by caching and proxies and so on, looking at about one pageview in a thousand - and whilst that is decent for letting us know what the most useful pages are, it's hopeless for anything in the long tail, the articles that a proposal like this is interested in.
::In short, the impracticality of collecting the data makes any proposal based on interpreting that data a non-starter. ] | ] | 20:57, 6 December 2006 (UTC)
::: This does not impress me in the least. The issue is how to get it done, not why it cannot be done. Logging all pageviews for 90 days worth is indeed a non-starter, but that is not how you would do the needed tracking! This kind of study relies on aggregate startistics. Suggestion: Create a daily tracking table/database. During the day, each read results in the invokation of a read against the tracking table entry for that article. If the entry exists, then increment it's counter. If it does not exist, then create it with a value of 1. At the end of the day do a file rename to switch the tracking to a new, empty database. The previous day's table is then saved under a name which includes the date. Batch processes can now be used to create aggregate tables for weeks, months, etc. Given a million articles and names which average 25 characters long, the result is a database which is 30-50 Mb big. Ninety days worth is then < 5 Gb worth. That isn't small but it fits easily on most modern hard drives and is far from the 20 Tb that you claim is needed each month. So a properly designed process is very much within the realm of technical feasability. --] | ] 21:17, 6 December 2006 (UTC)
::::Wikimedia simply does not have the resources to do a database write at a rate that is anywhere near 1 per read request. It takes a large number of caches and database mirrors just to keep up with the read requests. In addition, many of the dedicated caches are intentionally very dumb, and would not be able to update a read counter without a major architechural change. I am afraid any kind of tracking that needs to respond to every read request is a technical non-starter. (FYI, the read rate for Misplaced Pages is in the ballpark of 5000 pages per second distributed across >200 servers.) ] 21:50, 6 December 2006 (UTC)
::::: I beg to differ. Let's first take the external mirrors off of the table, so that only direct request to Misplaced Pages iteself are considered (which is still a real boatload). It seems to me that you identify boxes that can handle this task, and those that handle reads. Any box that can do both maintains a local read counter along the lines noted. Otherwise, the requests get passed onto a box that can handle the counting task. Note that each box does its own counting in this case to spread the load around. At the end of the day, they all send their data to another box which collects and combines the individual databases from the various boxes to obtain the statistical "dailies" for Misplaced Pages. I believe that this will introduce a minor (not necessarily trivial) load on the system. It will also need some thoughtful design and implementation to create. So the issues are ones of whether Misplaced Pages is interested in putting enough of its volunteer resources together to prototype this, and if it does so what level of system impact would be acceptable if this is to go into production.
::::: I strongly suspect that you all will learn a lot of interesting things about Misplaced Pages if this is implemented. Whether my initial suggestion will be implemented because of it is problematical though. --] | ] 04:55, 7 December 2006 (UTC)
:We should also remember that we are not just writing for the current crop of readers - we are writing about verifiable material for generations to come. We have litterally no idea what they will be interested in, just as past historians did not anticipate what we would be interested in. That is why verifiability, not whether it is interesting to current readers, must be the gold standard. ] 23:40, 6 December 2006 (UTC)
I just love the note at the top that says this was temporarily placed at perennial proposals. I'm a deletionist at heart but this is just a very very bad idea. And I won't even mention the useless technical complications that implementing this would entail. Quality articles are quality articles, regardless of whether or not they're read often. We already have plenty of resources allowing us to identify useless content: orphaned articles, linkless articles, short pages, neglected articles etc. Any attempt to make the deletion process automatic will undoubtedly lead to loss of valuable content. I have a hard time believeing this is a good faith proposal. ] 06:03, 7 December 2006 (UTC)
: I was shown the random article function by my daughter (it's on the left hand side of the screen in the skin I'm using), and she was joking about the kinds of articles that it shows. Try it. It is mostly stubs on trivial places and people. If find it hard to believe that most of that stuff is viewed at all regularly. Often it does little more that documents the existance of the topic. You worry about losing "valuable content", but how is content valuable if it is never used!? I think the silliness of that knee-jerk reaction to this proposal is shown in people worrying that ] and ] could vanish because of it. Most (if not all) of the articles removed under this proposal will be on topics that you cannot name!
: Once again, I call for article usage to be studied and unread articles to be identified in order to determine if this idea or some variation on the theme can work. Noone can name for me an unread, quality article because noone knows what articles are unread! ] shows the oldest (longest since last edited) articles, but most of those have good reason for being stable, and most likely are regularly read.
: It is silly that I keep hearing the theme of "this will remove valuable content". Once again: ] an indiscriminate collector of information. I for one find it hard to believe that unaccessed articles will be found to be valuable. Remember the incident on the fake biography accusing someone of being involved in the ]! That article went unnoticed for months! Why? Becuase noone read it, except accidentally! Unaccessed articles are not being checked for accuracy, nor do they have content being added to them as additional people with additional knowledge become involved with them. Those that may be worth keeping will be on highly esoteric subjects, and even then there may be an issue of whether they should be in this wiki!
: At the least, it would be nice if the data was gathered so that I could be shown that this is a silly proposal, or alternatively that I could show you that it (or a manual version of it) will work a lot better than you may think. --] | ] 15:49, 7 December 2006 (UTC)
::I do hope you are joking. ] 21:07, 7 December 2006 (UTC)
::: It's not a joke. Even if the idea is bad, I believe that the suggestion itself is good because of the questions it raises. After all, if there are unread articles, then why should that be the case? Are these quality articles that will reward the very occasional reader who should be looking for them? Or are they hidden pieces of BS that are waiting to "bite" an unwary user of the "random article" function? It seems to me that it would be very interesting to find out what is unread and determine why that is, and I do suspect that a lot of those articles would end up being removed upon further consideration. --] | ] 22:45, 8 December 2006 (UTC)
::::For the second time, no one said ] would be deleted. The person who commented about the Superman article was saying that Superman ''wouldn't'' be deleted but that far more scientifically valuable articles like those on elemental isotopes or rare species might be. --] <small>]</small> 23:46, 8 December 2006 (UTC)
While I agree that the idea of deleting (manually or automatically) long-unread articles is absurd, being able to view a list of pages that have not been viewed in a long time would be very useful, as ] suggested. ] orders pages based on creation date, so ] (wantonpages?) would sort them based on their last access date. This tool could be used to make sure esoteric pages are of acceptable quality. It would also be a way of finding hidden gems! -] 21:33, 8 December 2006 (UTC)
: Thank you for being open-minded about the possibilities here. --] | ] 22:45, 8 December 2006 (UTC)
:: Sorry if anyone already wrote it, but - if some page is listed in proposed Unviewedpages list and I someone will have to solve the quality of the page, he will have to visit the page - and if he does it, the page is immediatelly visited and removed from the list... So if the editor thinks for whatever reason it is a valueable page (or if the reader does not think about any reason, just browsing the Misplaced Pages not caring about editting or removing unread articles), it is safe for years again. So be careful about the list. ] 23:36, 8 December 2006 (UTC)
:'']'' is relevant to this discussion (I see that Shimgray mentioned this concept above). I oppose deleting unread articles in the same way I oppose burning dusty books (as was mentioned earlier). The statistics gleaned from the analysis would be interesting and valuable - they would help to focusing certain clean-up efforts and in surveillance for certain types of vandalism. --User:Ceyockey (<small>'']''</small>) 00:02, 9 December 2006 (UTC)
Dear God, the deletionists are at it again! No, this is an appalling proposal. Just because information is obscure and rarely accessed does not make it useless. I was the first person to check a 1940s book out of the university library where I work. Does that make it useless? No, of course it doesn't. For a start, I was interested enough in it to take it out! Let's just bin this proposal now and move on. -- ] 17:48, 10 December 2006 (UTC)
*My initial reaction is to be against this proposal, it just seems negligent. The only way I could see it working is if '''1)''' The no-read deadline is extended to 6 months, if not a whole year. and '''2)''' If the pages weren't actually deleted, but instead, archived somewhere with the possibility of recreation. -- '''] <sup>] • ] ]</sup>''' 18:43, 10 December 2006 (UTC)
:I agree, bin the proposal of anything relating to deletion of old articles. Very bad idea for all the reasons listed above and it merits no further discussion. However, we should thank ] for the entirely distinct discussion about having a way to see a list of articles that nobody has looked at in a long time that grew out of this failed proposal. As ] says, it would be a way of finding vandalism, encouraging clean-up, and additionally we could find useful neglected content that should be better linked and integrated into frequently viewed articles to make it more accessible. Who can create ]? -] 16:42, 11 December 2006 (UTC)
Its not always apparent to people but have you ever considered that an unread article maybe simply undiscovered instead of ignored, Its like that time when Atari made an illegal tetris cartridge for Nintendo's NES system, and most of the cartridges were kept in a warehouse. At that time you could see adds offering $300 for one cartridge! They simply didnt know it was there and therefore did not pay the warehouse any attention. Its basically like that, if you dont know it is there you wont visit, you could probably shave off a good amount of content from wikipedia, simply because people dont know its there! I personally think that there shouldnt be a deletion of unread content.
-Charlie34
:As far as I know, Misplaced Pages isn't a free web hosting. The purpose of WP is very different, and so I don't see how low access rate alone justifies deletion of content. Remember, HDD space cost is negligible compared to the work of creating content. Should libraries burn books not requested for a year? If not, why should we?
:Actually, deleting users who haven't edited for 90 days would make as much sense.
:However, I have always supported the idea of at least rough monitoring of usage, at least to precision of how many digits the number would have. This would help on AfD and before AfD to separate subjects with no interest and not worth salvaging from ones which are worth rewriting. Really help, there've been a lot of cases when an article on a seemingly obscure "crufty" subject was rewritten and turned into a good one, clearly proving notability of the subject. ]<sup> ]</sup> |]| 14:54, 23 December 2006 (UTC)
== ] ==
I cannot see this proposal anywhere; if I have missed it, please don't shout at me.
It seems quite clear to me that many serious new editors, who really want to help our project, do not come across the adopt-a-user setup, nor are they directed to it. I have adopted two users and, since doing so, I have been approached by three newbies with questions which, happily, I could answer. But they were unaware that they could have asked to be adopted. They had all received a {{tl|welcome}} template. I propose that the welcome templates be enlarged to include a link to ]. They then have the option of going there or not, but they will at least know about it.--] 19:39, 6 December 2006 (UTC)
:It sounds like a good suggestion, and I would eventually support it, but ] is very new. It might be best to allow for a breaking-in-period for the program before linking to it from welcome templates. ] <font color ="green">]</font > 19:45, 6 December 2006 (UTC)
:Sounds good to me. Not sure about the breaking-in-period. Do we really need it? —]] 19:56, 6 December 2006 (UTC)
:Without naming names, ''some'' other well-intentioned programs have later encountered difficulties and met with a certain amount of criticism. I do think that a longer period for community evaluation and response to ] would be in order before creating an "offical" link. In part because the link would strongly imply an official endorsement, in part because it just seems prudent to make sure the program works the way it was intended. ] <font color ="green">]</font > 20:49, 6 December 2006 (UTC)
:Are you talking about ]? I thought it started out well at first, but then things started to get complicated. --] (<big>]]</big>) 16:08, 7 December 2006 (UTC) <small>—''the preceding comment is a joke.''</small>
In support of Anthony.bradbury I would like the Adopt-a-user program to be linked from {{tl|welcome}}, but I do understand the concerns of Doc Tropics. I would like to ask what sort of time period / number we talking about, and where could we get such community evaluation done?
On the other hand the project has been running for a few months now - and we have currently over 65 adoptees - and so far (as far as I am aware) no complaints. Even if it was added to the welcome template, we could always removed it very quickly if there were problems encountered. Beyond a certain point I suppose it is an old circular argument - if we don't have any "official" support we can't advertise the service properly to increase our numbers, but we need to increase numbers before we are allowed "official" support. "Official" support is particularly important for this project because it would help us attract the newest of users (who are otherwise hard to reach).
On a similar and maybe less controversial note, it would be great if we could have a link inserted under Where to ask Questions at ] - please see ] to discuss. Thanks ] 15:00, 7 December 2006 (UTC)
:For the sake of clarification, I strongly support the program myself and I'd like to get involved; it seems a very worthwhile project. My only concern was about moving too quickly in adding it to the "welcome mat". I would support the link being added once we are sure that the program works as intended, and so far, it seems to. ] <font color ="green">]</font > 15:24, 7 December 2006 (UTC)
::Yes, I like this as well. For now, let's try to spread this by text-of-mouth.--] (<big>]]</big>) 16:10, 7 December 2006 (UTC)
As I mention ], I do not think that this program is so useful (while the idea is cute). The best way for a user to get involved would be contribute to articles, and the interaction which follows from there. Joining a wikiproject is also a good idea.
Besides, I believe that the {{tl|welcome}} template already has a bit too many links. If this project is found really useful, I'd suggest replacing one of the existing links than adding to it. ] (]) 16:09, 7 December 2006 (UTC)
:Could people also comment on maybe adding it to the ] as well/instead please - many thanks ] 16:29, 7 December 2006 (UTC)
:Per this thread ]. Comment here or there. --] 19:21, 7 December 2006 (UTC)
:Another suggestion: Maybe we could make another template (e.g. {{tl|welcome-a}}) with the welcome message and the link for users who want to link to ] to use until the link gets added to {{tl|welcome}}. That said, I'm in favor of adding it. If any problems come up, it can be removed later. I think this would have been helpful for me when I was new; I, like a lot of people with knowledge in kind of obscure areas, edited quietly and didn't have too many interactions for a long time. ] | <small>]</small> 21:18, 10 December 2006 (UTC)
:I strongly support this addition to the routine welcome template. Requiring a break-in period for the adoption program is superfluous. It is a very simple program and its basic concept has been proven for millennium. -- ] 08:07, 11 December 2006 (UTC)
:Until, which will be hopefully soon, Adopt-a-User is added to either or both of Help:Contents of the Welcome template, people that support its insertion can use an alternative template - ] - which has only a minor modification to include Adopt-a-User. Cheers ] 19:37, 11 December 2006 (UTC)
*Support this idea. I was unaware of it until I followed your link just now!!! - <span style="color:#ccf;background:#ccf;border-style: single">]</span> 10:41, 14 December 2006 (UTC)
:Just so people known, we have increased are number of users involved (combined adoptees and adopters) from 100 to 150 in under 10 days. As the project in continuing to gain support I would like to know at what sort of level of use people think it should get linked from Welcome and Help pages, or whether it should never be? Cheers ] 12:41, 14 December 2006 (UTC) P.S. I know that numbers are not everything, but they are one of the measures that, I should think, will be needed to be used to assess the programs importance ] 13:52, 14 December 2006 (UTC)
:'''Support''' per nominator. --] 10:39, 21 December 2006 (UTC)
== Topical ArbCom? ==
I just read the interesting essay by ], who left the project in August 2006.<br>
Given that we seem to have a lot of eager ArbCom candidates, certainly more than the ones needed for the main ArbCom, and many with stellar records (none perfect but no human is), would it make sense to have lower level 'topical ArbComs' as ] suggests?<br>
Imagine having, say, 6 such topical ArbComs, one for each of the current topics in ]. They would focus on main article space disputes, and on cases where behavior is mostly ] (or maybe we could add a dedicated ] topical ArbCom) and the issues are more related to the core WP content policies, such as ], ], ], ], etc. They would have the same power to decide on remedies as the main ArbCom. All their decisions would be appealable to the main ArbCom, who would be able to summarily dismiss the appeal (hopefully in most cases) or accept it.<br>
Of course each topical ArbCom would also be able to select its cases, suggesting continued efforts in other mediation venues where applicable.<br>
The motivation is to clear backlog and deal with disputes much earlier than we do today, per ]'s suggestions.
Any thoughts? Has this been suggested/rejected before? ] 13:05, 9 December 2006 (UTC)
:In other words, a group of subsidiary courts? Well, that does sound like the next logical step in expanding the dispute resolution process. We may not actually be large enough to require them quite yet, though.
:Would these subsidiary courts be permitted to desysop? I'm assuming any such decision would probably be appealed, but making it explicitly allowed/forbidden from the start would be helpful. --] <small>]</small> 19:29, 10 December 2006 (UTC)
::I suggest the topical ArbCom should be able to issue admin remedies (including desysopping), but desysopping would always require approval by the top ArbCom. I would propose that for such approvals a quick process would be instituted, similar to today's 'case closing' vote. If the lower ArbCom recommendation is voted down, then it will enter a discussion phase by the top ArbCom, followed by a possibly modified remedy. ] 01:10, 11 December 2006 (UTC)
:::Can't say I've given it much thought but I like the idea. We could have slightly smaller ArbCom committees which would probably also make them more efficient. Crum375 is right: a lot of very competent, respected election candidates will fail because there are so few spots on the ArbCom. Also, this could mean a somewhat smaller workload for individual ArbCom members, making it more likely that god candidates will apply. ] 02:04, 11 December 2006 (UTC)
:::I'm not sure this would work well. It is one thing to say that with an expanded ArbCom (see comments on Jimbo's page and on the ArbCom voting talk page), not all cases need to be heard by the full committee; ''de facto'', that's the practice now. But the community has been extremely hesitant about giving the Arbitration Committee, or any small number of users, authority over content issues. ] 02:15, 11 December 2006 (UTC)
::::I fully agree that content issues in general should be settled by consensus, and failing that with the help of voluntary non-binding dispute resolution mechanisms before reaching binding arbitration. The problem that ] alludes to (as I understand it) is that very often issues spend too much time in various non-binding mediation processes and by the time they escalate to ArbCom, way too much time and energy have been spent, with a lot of acrimony and frustration along the way, leading to loss of productivity and burnout. The concept here is to introduce binding resolutions at a lower level, while still encouraging the non-binding methods, in the hope of achieving better efficiency and reducing debilitating prolonged conflicts. The issue really is: assuming that as we grow we'll have more need for arbitrators, do we want a single tier or a dual tier arbitration system? Intuitively the dual tier sounds like it could do a better job, assuming the division of labor rules between the tiers are properly defined. ] 02:42, 11 December 2006 (UTC)
::::Can anyone here suggest a way to get more input on this from the community? ] 02:08, 11 December 2006 (UTC)
:I think a single pool that draws random panels for individual disputes would make the most sense for dealing with the growth of Misplaced Pages, plus some procedure to allow escalation to an ] decision for close or contentious issues. Since ArbComm doesn't rule on content, I don't think topical specialization would be that productive. ] 14:20, 11 December 2006 (UTC)
::I can see some scalability problems with the single tier ArbCom, in the long run:
::#It will be harder to keep track of situations with repeat offenders, as 'memory' will be diluted as we grow and spread out the load laterally
::#Some cases are simple and some are hard (hard typically involve admin-level conflicts and wheel-wars). The single tier will need to deal with all problems randomly, whereas the dual tier can automatically escalate the hard problems to the top tier while easily dealing with the simpler ones at the lower tier
::#Although content dispute per se should not be 'arbitrated', many conflicts arise in relation to content. Having the more specialized lower tier ArbCom would improve understanding of the underlying content issues and make the resolution quicker and more efficient
::#Having the dual tiers will allow a more natural division of labor, as opposed to near-random case selection by a large ArbCom pool
::] 14:32, 11 December 2006 (UTC)
:As long as the role of ArbCom is primarily related to user conduct rather than managing the content of the encyclopedia, a topical breakdown doesn't seem very natural. ] ] 03:37, 15 December 2006 (UTC)
::Maybe so, but ArbCom does need to expand to handle a bigger caseload, and a dual tier structure makes sense, as opposed to random subgroups in a single flat structure. Using generic topics as in the RefDesk as a dividing scheme for the lower tier would be an easy and natural division, and would allow the lower tier group quicker understanding of content related issues, hence more efficient handling. ] 00:26, 16 December 2006 (UTC)
:::The one concern I have with topical arbcom divisions would be that it increases the likelihood that an arbitrator might have a conflict of interest (either through editing the pages in question or personal viewpoint). Also that certain subcoms (philosophy, religion, politics, and BLP) would get much higher numbers of cases than others. However, I can't think of a better division system. Perhaps if arbitrators were shifted between branches in rotation? --] <small>]</small> 00:33, 16 December 2006 (UTC)
::::I tend to agree with your point about ], in principle. I can see requiring topical ArbCom candidates to disclose any special affiliation related to the topic. Your idea about rotation is good, except we would lose the advantage of greater efficiency due to topic specialization. Maybe some combination is needed? Maybe shorter term limits? (with possible resumption of role on a given topical ArbCom after say 1 yr hiatus.) ] 01:15, 16 December 2006 (UTC)
::::: Personally, I think that topical ArbComs are a very good idea, especially if they are staffed with people who are experienced in the area. I see ] as being something of a red herring here. We don't want to exclude scientists from the science ArbCom for instance. I see conflicts as being such things as ruling in a conflict where the arbitrator has already taken sides. I can't speak for other areas, but science is one where the subject matter is fractured as-is. We could easily do committees for physics, chemistry, biology, etc. Even there, there are subdisciplines where if one may have a conflict in one area, they would be available for others. It also will be very helpful to have recused arbitrators involved in cases on an advisory basis.
::::: I see this as a way of giving the interested editors more say in dealing with conflicts and perhaps easier access to arrbitration when needed. As-is, the current arbitration process is so complex and involved that I for one perfer to avoid it. --] | ] 17:52, 18 December 2006 (UTC)
:This would be very different from what ArbCom is now. It specifically doesn't deal with content issues, and specifically excludes them even if the conflict started about content.
:I find just "lower arbcom" (whatever named) more fitting the purpose. As ArbCom can work on several cases with different members, so can the lower tier. It's true that people often bring petty disagreements to ArbCom, and that should be avoided. However, that could encourage escalation instead of mediation. ]<sup> ]</sup> |]| 15:01, 23 December 2006 (UTC)
== Require anonymous users to confirm edits ==
Here is an idea for reducing vandalism: Require anonymous users to provide a valid e-mail address, which will be used to verify that the anon is serious about the edit and to permit identification of vandals. Here is the process:
* Anon does an edit.
* Once they hit "save page", they get a screen asking them to provide a valid e-mail address to which a confirmation message will be sent. It is noted that they will have only 30 minutes to respond (which I assume is more than enough time in most cases to reveive the e-mail and respond).
* If an e-mail address is provided, a confirmation e-mail is sent out, with instructions to either reply to it or click on a coded, confirming URL link to confirm the edit.
** If no e-mail is provided, the edit is discarded.
* If there is an edit conflict after the confirmation is done, another e-emil will be sent out with a link to a conflict resolution screen. If this link is used, the final edit will be saved as it is associated with an existing confirmation.
Note that at the end of this process we will have a valid e-mail for the user, and some hope of identification if the edit is vandalism. I strongly doubt that any vandal will be eager to type in "me@myschool.edu", but if they do so and it is vandalism we can then contact "myschool" and advise them of the issue. We can also block e-mail addresses that are for vandals in that case.
Note that I am not calling for e-mail addresses to be placed in the edit history or in any place which is generally accessible. The e-mail addresses should be in a seperate place acessible only to sysops if not a much more restricted set of users. However, it should be a part of our policy that Misplaced Pages can use that information at its discression to track down and/or contact vandals, and that should be noted on the e-mail address query screen and in the confirmation e-mail itself. --] | ] 17:55, 12 December 2006 (UTC)
:The whole point of a wiki is that it's quick and easy. Doesn't this proposal take away from that? ~ ''''']'''''<sup>(]|])</sup>
:All this does is serve to annoy the anons. It won't stop the vandals since they obviously either a)have too much time on their hands and can spare the 30 seconds to confirm their email, and/or b)have an agenda to push and won't mind the inconvenience. Legit users who don't want to join wikipedia but are just trying to be helpful once are less likely to make the effort. And no, it won't inspire people to create accounts. You can't annoy someone into joining - most would choose to simply not bother. ] 19:41, 12 December 2006 (UTC)
:: As I see it, someone doing a quick and legit edit will have little issue with doing the confirmation. Type in your e-mail (which many current browsers will auto-complete for you), and after the e-mail arrives hit the Reply and Send buttons on your e-mail tool, and the edit is in. I don't see that as a huge bother. This will only get annoying once you start making mutliple edits a day, and if you are committed to doing regular editing here, then you should have an account (and most likely will get one).
:: The goal is to set up a "low bar" to anonymous edits, but one that will stop casual vandals cold. I admit that it won't stop POV pushing and won't stop vandal accounts or other people who care to be creative about hiding their identity. However, a school kid blanking a page as a joke will be looking at creating a trail that potentially can be followed. That is the target here. --] | ] 18:10, 13 December 2006 (UTC)
::: Right, so it won't do much to solve the problems, but cause an inconvenience for many potential members. Thanks to the massive number of people who watch recent changes, have pages on their watchlists, and the AntiVandalBot, page blankings and other drive-by idiocy generally gets reverted in seconds. Your proposal runs counter to established policies of assume good faith and don't bite the newbies. Not to mention the core principle of being an open encyclopedia. You have to realize that even though a lot of vandals are anonymous editors, the vast majority of anonymous edits are helpful. Fact of the matter is that "casual vandals" are the least of our problems. ] 18:25, 13 December 2006 (UTC)
:::: Not true. In my experience the vast majority of anonymous edits, particularly when done without an edit summary, are deliberate vandalism. Moreover, it does not get reverted in seconds; it can remain for hours, days or even weeks. I used to care, but I'm beginning not to. After all: if Jimmy Wales doesn't care that Misplaced Pages has become an idiot's playground, why should I? Personally I don't think anonymous editing should be allowed at all, so anything that causes it to be inconvenient sounds good to me. --] 19:08, 15 December 2006 (UTC)
::::: A lot of energy goes onto doing these reverts that could be devoted to improving the encyclopedia. In fact, I am one editor who has limited time and who has found the vandal reverts make it hard to track what is really going on it the page. Items that could be of interest often get buried by a vandalism-and-revert. Also, as one comes to be watching a larger number of articles, more and more of them are found to have an edit summary of "rvv" or "rv to prev ver ...". So this noise in the watchlists interferes with the ability to track real issues regard that portion of the encyclopedia that you have chosen to contribute to.
::::: I honestly think that Misplaced Pages has shown that while wikis can be effective tools for creating a community-wide compendium of information, they also can be too wide open and free wheeling. The issue now is to figure out how to achieve the right balance of openness and restraint. Mine is just one suggestion of improvig that balance. --] | ] 04:00, 16 December 2006 (UTC)
I don't think editing by non-registered users should be allowed at all - the negatives far outweigh the positives. So giving anon IPs a hoop to jump through should be the least requirement. ] 04:18, 16 December 2006 (UTC)
:Let me also add that while people watching at recent changes do a great and thankless job it's not true that vandalism gets simply "canceled" by reverts: the damage on the edit history is permanent and something we shouldn't underestimate. We already have an overwhelming number of ''Historia se repetit'' edits just because there's no good way to document rationales for previous choices; and way too many editors who don't use edit summaries. I don't think we should add reverts to that. (Personally, I'm one who thinks Misplaced Pages should switch to an SCM system, or it will never be able to get a release out, for instance. But that's perhaps a broader topic.) —]] 21:21, 17 December 2006 (UTC)
*This should probably be on ]. (]) 13:49, 18 December 2006 (UTC)
:This sort of raising the barrier to entry to weed out the malicious generally backfires. I wish I could find the article, but there was a study done showing that, after the Boy Scouts of America started requiring that all volunteers submit to criminal background checks, the rate of molestation went up: potential child molesters were more willing to go to the effort of becoming volunteers than ordinary people were. --] 22:53, 19 December 2006 (UTC)
:'''Object''' Seriously if you want to stop anon-vandals, give them the template welcome anon-vandal. Very good template if you ask me. It was marked for deletion, but I think the decision was to keep the template.--] 10:47, 21 December 2006 (UTC)
Ha ha ha! Oh wait... you were serious? Lets face it, if anonymous people have to go through this huge waste of time perhaps to only correct a spelling mistake, why edit wikipedia at all? Even if there is completely wrong information, most anonymous users dont want to spend their precious Sunday afternoon going through that process. And I honestly dont think this will stop vandals at all because those people that vandalize in the first place have way too uch time o their hands.
-Charlie34
Really, this won't help against vandals. Only against people who have noticed "Wow! Edit button!" and decided to test it, but they aren't a problem. About the side effect, on many sites I often had a useful comment in mind, but didn't make it because of all the confirmation stuff. Not only it can backfire with spam, I just don't want to confirm all of that, after all, it's the site, not me, who needs it. ]<sup> ]</sup> |]| 15:28, 23 December 2006 (UTC)
== Logo Variations ==
I would like to propose for Misplaced Pages to use logo variations created by members of the community to mark '''national and international ], ], notable anniversaries, and observance days'''. Besides for the ], it is important to commemorate special days to show Misplaced Pages's support for bringing out more awareness of these issues and events. The logos would be chosen from contestants in a consensus of graphic artist users on a project page of its own. This project would be similar to google's |sketch contest]]. I would like us perhaps to be ready for our first wikilogo by ], ] and ]! ] 05:43, 14 December 2006 (UTC)
*'''comment''' the Misplaced Pages logo is copyrighted so you would probably have to get permission from the foundation to do this. ]<sup>] ]</sup> 06:44, 14 December 2006 (UTC)
*'''Question''' What would be the criteria for dates to be recognized in this way? -- ] 06:50, 14 December 2006 (UTC)
:This is an issue that needs to be discussed, I think each religion's two or three main holiday's should be considered as well as important awareness days such as ], ], breast cancer day and any others that we come to a consensus on. ] 07:01, 14 December 2006 (UTC)
*I think a better idea would be to make it possible to change the logo via some CSS code, so people could install it in their own monobook.css/js file if they want it. I've tried it before, but unfortunately the URL for the logo is stored in the <a> linking to the main page, rather than monobook.css itself, which means it would require some tricky JS to make it work. |This would allow users to have their own criteria for dates. --] (] logged out) 06:55, 14 December 2006 (UTC)
**That seems like an excellent idea, if it can be made to work... can it? -- ] 07:05, 14 December 2006 (UTC)
*::<code>#p-logo a { background-image: url(http://mylogo.com/logo.png) !important; }</code> ] (]) 07:07, 14 December 2006 (UTC)
*:::Exactly, I agree with 172.205.196.44 - for that matter, my .js has actually disabled showing the wikilogo, so I wouldn't see it anyways. But, not being selfish, I like the idea :) '''] <sup>] · ] ]</sup>''' 07:27, 14 December 2006 (UTC)
*I am for the idea in principle (I am envisaging something like the google logo changes). '''However''', I would not want to see anything national-specific (especially US-specific) or politically-motivated, religiously-motivated etc. What I would not want to see is for example a "4th of july" logo or a "jesus crusified today" logo, these are politically- and religiously- charged. Perhaps "Figure X born today" or "Chemical Y discovered today" etc. I think if we do this it should be a variation that represents the kind of things wikipedia does and stands for, rather than a slavish mimicry of eg the google logo. Cheers - <span style="color:#ccf;background:#ccf;border-style: single">]</span> 10:33, 14 December 2006 (UTC)
**Some great points from a great user. I think there can be "some" politicly and religiously charged versions though, like Christmas. ] 10:48, 14 December 2006 (UTC)
*'''Comment''': To keep our headings clear, it's probably good if we switch to numbers from asterisk indents. ] 10:57, 14 December 2006 (UTC)
#'''Comment''': That Google does it is kind of the "Diddy did it" thing: more or less irrelevant. I'm in favor of the proposal, although there would need to be a few clear understandings. The globe of letters is the copyright, just as the lettering of "Google" is, and so the graphic alterations would need to be backgrounds, colors, and things ''around'' the logo. Also, ''please'' make it two words, "Wiki logo," rather than one, as one sounds like "Wiki Λογος." As for the substance and the problems, please forgive the extra indents:
#::The project would be properly located at Commons, not .en. This would make the variations available to all projects, so that the .se pedia can put up a 4th of July logo, if they wish.
#::National holidays (ones where all government offices close) are non-controversial, but seccession day, failed rebellions, etc. can get tense. Nationally recognized religious holidays (Christmas, Easter, Good Friday), and especially those that are core, would be non-controversial, but regionally or sectarian or denominational ones would be tough.
#::If there were to be an include/exclude argument, the best one would be, "Is this nationally recognized in ''an Anglophone nation'' for .en, a ''Francophone nation'' for .fr, etc." A non-English speaker going to .en may be interested in the funny customs of the Anglophone world, just as native English speakers tend to be interested in the "strange" holidays celebrated by the Swedes, for example. The dominant nature of English shouldn't enter into it, really.
#::The proposal carries with it a rather non-wiki element, in that it requires an approval community. The best suggestion I could offer would be that this be done via a Project. There should be a Holiday Logo Project, and it should need to vote and gain consensus on these acceptable variations (and it should be plural).
#::Picking which, if any, to actually put on the main page requires a top level admin who enjoys wide, wide trust. The only candidate I can think of right now would be Raul, who is already the FA director, but I'm not sure he'd want to do it.
#:Anyway, that's what occurs to me. I really hope it helps. ] 10:57, 14 December 2006 (UTC)
*I love logos ^^, BUT! First off; what kind of awareness days? And some Rememberance days might be offencive to others, off the top of my head say the Armenian holocaust, the Turks deny it happened and refuse to adit comitting it, but I betcya the Armenians have a day to REMEMBER it. Also, some people don't like The dream factory (to get this joke click the wiki link fore Rememberance days you wrote on me talk page =P). Note: I am very buisy these days for the next two months I've got covers, collections, some more covers magazine and newspaper comics blah blah blah... so I probably won't do it, but here is some advice if it helps. In my opinion, why not, as not a lot of wikiusers go to the front page and read it all if there's an awareness thing on it, but I don't think we should go too much in to it, maybe just slap a small awareness ribbon on the logo and make a more noticible article on the front, or maybe even send an automated awareness message to ALL USERS. The wikilogos are very estetic so we must be carefull in editing them if we are permitted tom we don't want them to loock cheep now do we ^_^? I'd keep it modest. Also problems: Some awareness symbols, ribbons, or collors may stand for more things, so the observer may not get it. And: What if it gets out of hand? Before you know it we'll be having a santa cap on the logos hah. In conclusion: Only if these days are important and regard everyone, not just say Christians or something. Like AIDS day, Memorial day, Give out free candy day, Global warming awareness day, ect. Exactly how, I do not know but don't make it too flashy or just too much. If you're gonna go for it, think simple and clever, it always works ;) --] 11:19, 14 December 2006 (UTC)
#I '''support''' this proposal. It is a qay to remind us "Never Again" ] <small>]</small> 14:56, 14 December 2006 (UTC)
*It sounds like a fun idea on the surface, but doesn't really gain Misplaced Pages anything other than administrative trouble. It might have some value if, like the cartoonish altered Google logo, it brought people to the front page to see what cute logo-mod Wikipedians had come up with for the day, or if Misplaced Pages had an unfriendly image problem that desperately needed to be rectified. (And "image problem" brings up other difficult issues regarding tone and style of any illustration, btw.)<br>
:I absolutely do not support a religious logo-mod of any sort, and that most definitely includes Christmas ornaments, Channukkah dreidels, Valentine's hearts, Easter eggs, etc. ''ad nauseum''. <br>
:I agree with PocklingtonDan that only "a variation that represents the kind of things Misplaced Pages does and stands for" might be more reasonable than religious or political ''']'''. However, I think the "On this day..." section does that and more. <br>
:Perhaps, alternatively, we could choose one event from "On this day..." to call out with a stand-alone logoish graphic (i.e., not a Misplaced Pages logo-mod). This logo-like graphic might be used something like a dot-whack, and might be valuable for calling attention to the "On this day..." section, as well as adding some graphic variability to the front page... but I'm not sure it's really a problem in search of a solution.<br>
:] 17:32, 14 December 2006 (UTC)
Don't like the idea. With Google, they can detect what country you are in and provide you with an appropriate version of Google , where they can do cute and culturally appropriate things with the logo. I don't ever see there being a "U.S." version of Misplaced Pages, a British version, Canadian version, etc... There are very few holidays that are not specific to religions or certain countries. --] <small>(])</small> 17:42, 14 December 2006 (UTC)
::'''Comment''' whilst it is true that that Sweden's Christmas is snowier then Britain's, certain observance days are the same. Obviously D day is no good since some German's wont like it, but that desicion would be reached in the consensus. What are you saying? ] 03:09, 15 December 2006 (UTC)
:'''Strong Oppose''' - Misplaced Pages has a strict NPOV policy. Local holidays and events would not be global. As such, we can't do something like this. I understand that this is a bland, boring decision, but Misplaced Pages's ideals shouldn't be violated for periodic variations of the logo. ] 19:35, 14 December 2006 (UTC)
:'''Support''' - This sounds like a great idea. :) ] 20:22, 14 December 2006 (UTC)
:'''Strong Oppose''' - I agree with ], the whole idea violates NPOV policy. It's important to note that someone's holiday celebration is also a reminder to someone else's failure in history. Or recognizing someone religious event offends those opposed to that faith. It's sad to say this, and I wish any holiday could be recognized and respected but Misplaced Pages needs to keep the whole "political correct" neutrality. ] 22:06, 14 December 2006 (UTC)
:'''Strong Support'''- It could just be on internationally accepted holidays, i.e. Christmas, maybe Rememberance Day. Sooner or later you're going to upset someone about something - its absurd to not do something because someone somewhere may be offended by it. ] 23:12, 14 December 2006 (UTC)
::'''Comment''' - two things:
::#Christmas and Rememberance day are both biased. ] is Christian, and ] favors the victors of the World Wars. The article on Rememberance Day reflects that.
::#It ''is'' absurd, on Misplaced Pages, to do anything that may offend someone in a political, religious, or social way, ''even if'' ], because of the necessity for a neutral point of view. See ].
::I don't mean any offense whatsoever, but what you've said doesn't seem to hold up. ] 03:25, 15 December 2006 (UTC)
:::I apprecaite you don't mean any offense, but where do you get it that people will be "offended" if some laurels where to apear on the logo for christmas and link to the article. Finding out about each other's religion's cultures and values would be a great thing for many of us, instead of being "offended" so badly? Please read the thread, I dont beleive for a minute you've read anything above. The focal points have been discussed, except for this "offended" ]. ] 03:50, 15 December 2006 (UTC)
::::I've read the thread, and the main topic of discussion is whether such a project is feasible. On the "cool variation" level, I strongly support this idea. As with Google, it would attract some people to see the latest Misplaced Pages "doodle". On the other hand, I find holidays to be inherently POV, and on that level such a project is entirely unacceptable. Users can have user scripts to change the image for themselves, but the main page and layout need their blandness and NPOV - NPOV is one of the ]! ] 04:23, 15 December 2006 (UTC) (signed after, oops)
:::::can these problems be fixed technicly, an option to turn it off/show the normal logo? <span style="background-color: #000000"> <font color="white">'''⇒'''</font> <font color="white">]</font> </span> 18:39, 18 December 2006 (UTC)
*'''Strong Support'''- Even if it does include something only celebrated by only one religion, ethnic group, etc., that shouldn't matter so long as we include the "equivalent" (if possible) holiday for any other religions, ethnic groups, etc. As well, if someone feels that their religion, ethnic group, etc. does not have a holiday recognized that they think should be, they can always suggest it. ]] 23:52, 14 December 2006 (UTC)
*'''oppose''' ] list 21for balance, if we consider three Christian dates of Christmas, Easter, Good Friday that means that 63 religious day logo's. Then we add these UN listed special days(note some are weeks) from here http://www.un.org/events/observances.htm , theres another 60, thats 1 in 3 days. Then what happens when day A and day B occurs on the same day how would it be decided which would get the recognition. I think we leave day recognitions to the "On this Day" section that way every event gets equal and fair recognition. ] 06:32, 15 December 2006 (UTC)
*It's a good idea but there could be the problems with copyright and determining which events pass the notability test. We don't want to be following Google day for day though, though I do like the Google sketches. :) ] 22:33, 15 December 2006 (UTC)
*'''Strong Oppose:'''Per Gnangarra, Nihiltres, and Cyberia23. <small>]<sup>(])</sup></small> 11:39, 15 December 2006 (UTC)
*'''Oppose'''. Incidentally, to Geogre's comment that ''National holidays (ones where all government offices close) are non-controversial'' I'd counter that I can immediately think of one populous, economically powerful nation with a national holiday to celebrate the birthday of somebody who arguably should have been tried as a war criminal (see Dower, ''Embracing Defeat,'' passim). In principle I am vaguely interested in non-national, non-religious UN days; but really, there are so many of these, their names are so prolix, and some are so optimistic/silly/insulting -- "International '''Day''' for the Eradication of Poverty" (my emphasis), pfffft, somebody please alert me when the day becomes a decade -- that I lose interest fast. -- ] 12:24, 18 December 2006 (UTC)
*'''Strong Oppose''' This very obviously violates our NPOV policy and would end up being a never-ending headache for those who implemented it. We couldn't do any religious holidays because it would be a way of endorsing that religion, and trying to rectify this by doing it for holidays of all religions wouldn't work; there are hundreds of religions with hundreds of holidays and we couldn't possibly deal with all and would therefore have to pick and choose, which would mean accepting some POVs and rejecting others. The same problem would emerge in dealing with commemoration dates and the like, certainly those that are national rather than international would have to be excluded. Also, this seems to me to be, in my own opinion, a rather silly diversion from actually, you know... writing an encyclopedia. --] 22:19, 20 December 2006 (UTC)
*'''Leave that to Uncyc''' - even neutrality aside, we need a more serious attitude. Considering neutrality, it's horrible, as even Christmas isn't a holiday to everyone; and outside the West the world is so full of conflicts that most national holidays will be found hostile by some people. Let's list them all on the main page as we do already, but leave the logo serious. For coming to see what's new today, again, we've got the daily renewed main page which is ''way'' more interesting than on most if not all other websites. People coming to WP to see something new will be - and are - more attracted by the actual page, pictures and content, rather than jokes with the logo. Really, it won't add anything to WP. ]<sup> ]</sup> |]| 15:46, 21 December 2006 (UTC)
== Radical Linking Proposal, making wiki more efficient ==
Im not sure if it is possible but it would be nice if all words that have an article or page would automatically be links to those pages, but appearing like normal words unless you have the cursor upon them (or click them). So the Articles would appear as today but all archived words would be "hidden" links. This would maybe take more bandwidth but it would surely make the pedia more effective and integrated. /] 08:53, 14 December 2006 (UTC)
:too many links would mean a big trawl. imagine reading an article, you'de never finish it out of curosity of what every word means. at the moment you can link anything to anything, once. An interesting idea. ] 09:25, 14 December 2006 (UTC)
*Mouse-over is normally done with Java Script. That would be a developer issue, but I'm rather unenthusiastic about the idea. First, the manual of style (]) already discourages overlinking. Second, new readers may get lost in the link maze, but learning when to click and when to click later is part of the experience of Misplaced Pages. Anyway, I certainly understand the principle, and it's one reason the Manual of Style changed to discourage "overlinking." ] 11:19, 14 December 2006 (UTC)
*And I'm not even mentioning the problems words with more than one meaning would cause... - ]|] 13:50, 14 December 2006 (UTC)
*WEll well, eventually it will happen, and when every word, every syllable is completely mapped and understood, we will move on, to new frontiers and new levels of understanding. /] 14:51, 14 December 2006 (UTC)
:*If you want to know what it would feel like to implement this (scary), see ]. Otherwise, it's almost OK. :) ] 03:45, 15 December 2006 (UTC)
::Cool, thats the way i like it! Just, I'd like one color for all text, hyperlinked or not. /] 23:44, 15 December 2006 (UTC)
*Why? Because the text turns blue? I think its a great idea /] 22:53, 19 December 2006 (UTC)
Is it possible to leave things looking the way they are, but have ''right'' clicks bring up the option of finding links to Wikitionary and other projects? -- ] 10:05, 20 December 2006 (UTC)
*I personally oppose the idea as well. Too many links is overkill, only those terms that actually relate to the topic at hand should be linked. All people and places mentioned should probably be linked to as well, but not everything. Also, how would you deal with phrases that have articles but also where each word of that phrase has a separate articles? --] 22:23, 20 December 2006 (UTC)
== Limiting the number of edits for new users ==
Is there a way to limit the number of user edit by implemeting an edit quota, this would for example limit the usefulness of sockpuppets and revert/edit wars that go on. The edit limits can be placed on let's say:
* new users by limiting the number of edits they can perform overall - after the users have been around for some time, this edit quota can be lifted for example this is lifted after let's say a week or a month
* special edit limits on selected articles where edit/revert wars are constant
Regards,
] 20:30, 14 December 2006 (UTC)
:'''Rejected''', goes contrary to the purpose of encouraging new users to edit. We aren't ] where they arbitrarily define privilege levels. There is no purpose to doing this, and would serve only to discourage new editors from being active. Socks are cheap and easily creatable, so they wouldn't be stopped by this at all. Just make another 3 or 4 or 10 or 50 if you hit your revert limit. If a specific page requires it, we have ]. --] <small>]</small> 20:37, 14 December 2006 (UTC)
:I can tell you right now that it is not going to happen. This site will not treat all new users and/or anons as potential vandals and sockpuppets just because a small percentage are. See ] for more. If a revert war is going on you can have it semi-protected, but this is not the way to do it. ] 20:40, 14 December 2006 (UTC)
::Plus, those users who do commit wrongs can be blocked. ]] 23:43, 14 December 2006 (UTC)
:Of course we have problem new users, but we have problem old users, too (no, not administrators). New users who insert massive numbers of links, who write in their company everywhere, and then do the scribbling stuff are problems, but they're not a new problem, and the scope of the problem isn't growing faster than our vandal hunting tools, so there is no need to curtail our general philosophy. For every two vandals and spammers affected by this, a legitimate and good contributor, and the bad guys will simply use two accounts to accomplish the edits they're now doing with one, so the effect will be strictly to increase suspicion and unfriendliness to good users. ] 02:20, 15 December 2006 (UTC)
:: Thank you for your replies ! ] 12:32, 19 December 2006 (UTC)
==Article length templates==
Before I'm overcome with boldness, let's try this here first (ok, I'll be bold with colons). Bottomline''':''' {{tl|long}}, {{tl|Verylong}}, and {{tl|intro length}} should be deleted. Let me explain''':''' these temporary templates are placed in articles that someone believes are overly long and requests that someone (ie. not me) transfers to a sub-article or summarizes the content. The flaw is that this is metadata''':''' a comment and request (directed at ''editors'' who are familiar with the subject) concerning the structure of the article. This metadata belongs on the talk page''':''' their raison d'être. Theoretically (as some templates say and most people ignore) the template-slapper should also leave an explanation on the talk page. Templates in the article should be addressed to the ''readers'' (ie. warnings of NPOV, unverified, current event, etc.). So this clever observation that the article is long should go on the talk page: not somewhere in the actual article. On the talk page the templates would be redundant with a section explaining how it is too verbose''':''' so delete the templates. Right? :] 05:34, 15 December 2006 (UTC)
:Sort of :-) The sad thing is… many editors don't look at the talk page. I think we would need a software feature along the lines of: "don't even think of hitting the edit button and I'll show a gigantic warning in front of you" :-) OK, you got the idea. There are many other types of "annotations", BTW, which we would be able to use in that case. —]] 09:07, 19 December 2006 (UTC)
:Agreed. The templates are important, as some articles are ridiculously long and can easily be broken into separate articles. However, as mentioned, they do belong on the talk page since they are a notice for editors, not readers. Perhaps someone running a bot or using some other kind of script can move them over. A notice should also be added to the template pages with instructions to add only to the talk page as many other templates already have. ] 13:50, 15 December 2006 (UTC)
:Agree that this is talk page material, not article. ] 18:05, 15 December 2006 (UTC)
:Me, I'd send the templates to hell without apology, as I do not want anyone templating "long." If an article is too long, then go to the talk page and argue the position. Templates are far too slap-and-run for my taste, and I don't want anyone telling me that a full article on '']'' is "too long" because it gets to X kb or Y kb. If they pass TfD, then they're talk page matters and absolutely positively under no circumstances for the article page itself. ] 22:01, 15 December 2006 (UTC)
*Sounds reasonable; I think you should drop the templates on ] and/or get a ] to move them to the talk page. (]) 13:44, 18 December 2006 (UTC)
**Ok, I stuck my neck out at ]. ·] 04:24, 19 December 2006 (UTC)
==Wikidea==
What about a Wikidea. It could be like an open source think tank or blog that people could submit their ideas and people could work on them.
:Proposals for new projects should be made at ]. For your particular proposal, I think there might be a project at ] covering this sort of thing. ] ] 20:51, 17 December 2006 (UTC)
::There is ] already. ]] 17:12, 18 December 2006 (UTC)
== Just an idea for dealing with problematic users ==
Here's a simple way I thought of for dealing with users proving to be a problem on Misplaced Pages. This process would apply to those whose "problems" prevent them from doing constructive edits, even though they have good intentions (i.e. are not vandal accounts or blatant trolls).
* First Offense: User gets a short block (12 hours at the longest) and a warning, which attempts to educate them on how what they're doing is not good. The reason for the block is to show them what can happen. If they apologize, that can be grounds for lifting the block early; use common sense.
* Second Offense: User must go through mentoring. If they refuse mentoring, then they will be blocked indefinitely until they agree. It is then up to the mentoring user to talk to them or block them when appropriate.
** Always make an effort to educate
** Block ] it is appropriate to do so.
** If it's clear they're just gaming the system so that through mentoring they are allowed to not be blocked, the mentor can block them indefinitely at their discretion.
* If a user is really showing improvement, they will no longer need to be under mentorship, although the mentoring admin may still want to keep an informal watch on them.
* If a user fails to make improvement in a long times (around six months), they are banned for a long time (either indefinitely or something like a year).
Comments? Suggested improvements? ]] 12:16, 18 December 2006 (UTC)
:Can you give an example of the kinds of problematic users this is meant to help? --] 12:24, 18 December 2006 (UTC)
:: I don't know (and would not wish to give) specific names, but really this is for the kind of person that want to be involved in the goodness but don't exactly have the rules and common practices down yet. ]] 15:43, 18 December 2006 (UTC)
:::I meant kinds of user, not specific users. Can you give a hypothetical example of the kind of mistakes the users you're think of make? --] 16:48, 18 December 2006 (UTC)
::::Based on my history of controversy, do you think I should be mentored? --] 12:25, 19 December 2006 (UTC)
:Do you have the mentors available for those (many) users who make a second offence? (]) 13:41, 18 December 2006 (UTC)
:: It would be volunteer work, really. I would get invovled as well. Luckily, it doesn't have to be one-on-one (though I'd imagine it'd be a headache to do much more). ]] 15:43, 18 December 2006 (UTC)
:::Ban them all, God will know his own!
:::Ok, seriously, the idea of mentoring is very nice and warm and fuzzy, but I don't think it would work. How does one tell the difference between a user who is a problem on purpose and those who are a problem because they don't know any better? ] 20:23, 18 December 2006 (UTC)
::If wikipedia had that much moderator ] vandals would not have been a problem. There is no need in fanciful rules to ban an especially annoying one; the big huge problem is that you CANNOT ban a person from editing Misplaced Pages. IPs and even those hard adresses as ], not to mention the account itself, are all easily interchangeable. A funny solvation was met by some ] which issued a 'whole country ban' on ] because there were some problematic users from there. Nevertheless, people from Turkey and even the people in question could still play it via a ]. South Korea, on the other hand, gave each citizen an unique Internet ID, eradicating both the anonymity and anarchy in internet. Wait untill it is so far in ] and come again with that suggestion.] 21:28, 18 December 2006 (UTC)
:::I doubt that there'll be enough users to act as mentors. The backlogs at AIV, etc. suggest we need more manpower to deal with anonymous vandals. --] 12:25, 19 December 2006 (UTC)
Good idea, but there are such things as abuse of the mentoring system, the mentor might be 1. friends with the violator 2.enemies with the violator or 3.just plain abusing their newfound power to block a person there isnt much wikipedia can do to know about this but otherwise sounds good
-Charlie34
: Sounds like something that could be remedied with a conflict-of-interest disclosure requirement. Nothing fancy. If someone violates it, they get banned. I am merciless towards people who game the system. ]] 22:21, 22 December 2006 (UTC)
== Vandalism ==
I'll keep this short since most everything is explained elsewhere. Simply put, sometimes vandals are not fit to be reported to ], but there should be a place where they can be kept track of. You may read the problem in detail at ], and I would appreciate any and all feedback on my possible ], which is still in its early stages of being and is completely open to suggestions and constructive criticism. ]-] 23:54, 18 December 2006 (UTC)
:This isn't that hard to do on your own. Watch their talk page; then check their contribs list from time to time. If they vandalise repeatedly within a few days, warn them each time with the progressive warning tags, then report them to AIV. If they become good editors, or disappear for ever, leave them alone. I don't see where we need more than that. --]] 04:26, 19 December 2006 (UTC)
::Jayron32, by identifying chronic anonymous vandals, Dar-Ape's propose list aims to have many users doing what you suggested: watching their talk page, checking their contribs, and, if neccesary, warning them and reporting them to AIV. There are many anonymous vandals who stop after receiving a last warning, only to come back the next day (e.g. school IPs). If the IP address is static, they should be handed long blocks (of several months). --] 11:45, 19 December 2006 (UTC)
:::Exactly. Furthermore, even if IPs have a history of vandalism, they should generally not be listed at WP:AIV if they have only vandalized once within the past few hours, or have not vandalized after their last (which could also be their first) warning. Yet they could be reported on this page. Also, if someone has to sign off, contribs of the vandal he or she is watching can be combed and reverted the next day, but in the mean time, many people may have read the vandalized articles and gotten false or misleading information. This should be preventable, and will be with a "watchlist" like this. ]-] 03:56, 20 December 2006 (UTC)
== WikiBar ==
<s>
Apologies if this has already been suggested, but it occurred to me that a Wiki search/toolbar would be really handy for those who reference Misplaced Pages often.
] 02:13, 19 December 2006 (UTC)</s>
Sorry, just discovered it, please disregard/remove the above.
] 02:20, 19 December 2006 (UTC)
== Some ideas for the good articles shown in other languages ==
:''Moved from ]''
I've just created a template ], it's works similar as the ]. However it needs the ] and ] to be updated to reflect this change. Is that a good idea to introduce this template? --] ⇔ ] 05:58, 2 December 2006 (UTC)
:There's seems not much feedback about this proposal, so I copied to here also. --] ⇔ ] 16:18, 19 December 2006 (UTC)
::I'm curious. What do these two templates do? What are they for? Maybe they need some words inside <nowiki><noinclude></nowiki> tags, as the ] has, to explain what they are and when to use them. --] 04:14, 20 December 2006 (UTC)
:::I think they're to add a little plus icon to one of the "in other languages" links if the corresponding other-language article is marked as good. ]] 05:35, 20 December 2006 (UTC)
::::yup, that's what this template would do. (See also ], this template would add a plus icon at a inter-language link that its status is good.) --] ⇔ ] 17:02, 20 December 2006 (UTC)
== Hide/Show box for footnotes ==
Might a box be made as to make the footnotes on a page less, well obnoxious if there are many. I have seen boxes where there is a link in the top right corner where it says "show" while the box is closed and "hide" while the box is open. This could be done in much the same way the table of contents are done. Now I don't know how to do it, so I bring it here. (Note: This idea was originally derrived by myself at ], having nearly 50 citations. However, I have seen a page with 137 citations, and this would make any and all Misplaced Pages pages look far more pleasing to the non-editing reader.) How plausible, if plausible at all, is this plan, and does anyone know how to make such a box in a non-intrusive way? Other Feedback? Thanks in advance, ]]]]</font><Font Color= "light blue"> </Font> 01:36, 20 December 2006 (UTC)
: Read with Firefox, and use {{]|2}} or <nowiki>{{reflist|colwidth=40em}}</nowiki> or something like that in the article. (for instance, ]'s references are pretty big (both in quantity and column width), but on wider displays, it'll automatically display two columns side-by-side) --] 02:53, 20 December 2006 (UTC)
::Since I use ], am I left out in the cold? --] 05:11, 21 December 2006 (UTC)
:The purpose of footnotes is not just for the editor. If we consider how information is presented to the reader then we have various levels of granularity. In principle the opening summary contains the whole story and may be adequate for some readers, although we must accept that most summary intros in Misplaced Pages do not achieve this objective. The next level of granularity is the article itself, and the next again is the footnotes. A further level of granularity is going to the references themselves to establish what they say. I appreciate that a lot of Misplaced Pages articles leave a lot to be desired in this structural format, by using clumsy formations to attribute references and sources in text as well as footnoting, but that doesn't mean that the footnotes and references are only aimed at editors.
:The challenge is to get well written articles, appreciating that some will require extensive referencing to demonstrate adequate coverage.
:] 20:49, 21 December 2006 (UTC)
::But still, a box which could be hidden would make it look nicer, all I wanted to know is if anyone can make such a template. ]]]]</font><Font Color= "light blue"> </Font> 21:58, 21 December 2006 (UTC)
== Templates for proposing category splits ==
Just now I needed to propose the splitting of ] into ] and ], and found the required cf* and cf*2 templates didn't exist. I ended up using a modified version of {{tl|cfr}} on ] and the generic {{tl|split}} (with the rarely-used discuss parameter to point to CSD instead of category talk) on the category page itself. But I bet this isn't the only time a category's been put up for splitting. Shouldn't there be templates to do it with? ]] 04:58, 20 December 2006 (UTC)
==Rating system/decision system==
In some cases, building consensus on Misplaced Pages does not work very well. It is slow. It often results in a bad answer/solution. It is prone to manipulation. And often, a number of average editors can make life miserable for some real expert in a field like physics or neuroscience, reverting their changes, getting into petty arguments with them, etc. When you read the academic literature about Misplaced Pages, this is one of the complaints. The library scientists also complain about problems with unqualified people cranking out nonsense in a strident contemptuous fashion and drowning out the more learned and qualified editors on Misplaced Pages. In interviews, Jimmy Wales often has mentioned the desire to attract more experts to write articles. I am wondering about possibly tilting the playing field a bit in favor of people who have demonstrated some recognized level of expertise in some area.
I propose that a system somewhat like that used by Yahoo! Answers be used. In Yahoo! Answers, a person can put a question forward and get quite a few answers to that question in a short period. They can either choose one of these as the "best", or put it up to a vote to the community which will then choose a "best" answer. The community can then vote after the fact in agreement that the best choice has been made, or can vote in disagreement. Points are accumulated along the way that then identify fairly rapidly those with recognized qualifications and reliability in a given field. Many times I wish I could have a question that arises on Misplaced Pages put to a vote. On a talk page, this rarely works. Some people have jury rigged votes on special pages, and that can work sometimes. If points were accumulated in a yahoo! answers fashion, and people could find a list of things to vote on easily, then the community could be surveyed easily on many issues that become sources of contention. This could even be used for noncontent-related dispute resolution. For example, I have had editors claiming to me that having citations was unencyclopedic. Of course, I could have tried to organize some sort of RfC or something to address this, but it is too cumbersome. If I could quickly put the matter to a vote, and get 35 votes to 2 to show he is wrong, and build up points in the meantime, then slowly people who are knowledgable and reasonable fonts of knowledge in certain areas will be identified, and people who are less reliable and less knowledgable will become known as well. This would also be an incentive to people to improve, to get a better score. Better scores need not come with extra priveleges; prestige is enough to drive people on Yahoo! Answers. I recently had a situation where an editor claimed he had taken the wording for his contribution (which was very lacking in several aspects) directly from the work of a famous person in the field (but did not attribute the writing to the famous person). I then expressed incredulity at this claim, given that the contribution was of such doubtful quality. I pointed out that this editor appeared to be:
#admitting to plagiarism
#appealing to the presumed authority of this famous person to justify what they had written
I was met with a storm of indignation and accusations and attacks. The current dispute resolution system is too cumbersome to deal with this sort of thing. Therefore, there is lots of bullying instead. However, if something easy was available, the problem probably would have been resolved quickly without even resorting to dispute resolution, because even the existence of a way to easily publicly shame someone would encourage them to stay in line. Points might be accrued in different areas to produce a multidimensional score. Anyway, it is at least something to consider.--] 07:29, 20 December 2006 (UTC)
:Voting is not how Misplaced Pages works nor should it be. Democratic voting is not a good way to decide these sort of issues. What makes you think that votes would not be rigged? Wikis are run by consensus. If you post something and it remains, that means that everyone who reads it has in a sense "voted" to let it remain or abstained. So everything at wikipedia has unanimous approval. When people disagree, they have to discuss. If they can't discuss they can try mediation. If they can't mediate then there is arbitration. Discussions take time, and people who are not suited to collaborative efforts do not stay very long or eventually end up blocked. A million and a half pages have been created this way.
:There is no excuse for plagarism, and you should remove anything that is found to be plagarism. If someone claims information to be from an authority, they should cite them. If they do not, remove it for being uncited material. If you get reverted, ask for other editors to join you in reverting uncited material and plagarism. -- ] 09:54, 20 December 2006 (UTC)
::I understand what you are saying. However, I am reluctant to get into a pitched battle with someone who has been here more than 4 years. They clearly know all the rules and all the tricks for circumventing the rules. They obviously have a wide range of alliances and friends they can draw on. And it is true that 1.5 million pages in English have been created that way, and many more pages have been created in other languages. However, there are problems in a system where everyone is the some weight. Sometimes the herd instinct is wrong. And some lousy pages result. In fact, I have seen my share of examples of bad design, and clumsy wording, and meaningless phrases. And editors who are prepared to defend these to the death, using sockpuppets and friends. Unless someone is prepared to go to a lot of trouble, you cannot dislodge them and the text they are defending. I am not the only one who has noted this. Misplaced Pages has some very strong points, but it has weaknesses as well. I suppose a rating system could be "gamed" and end up favoring some group that wanted to cheat.--] 12:41, 20 December 2006 (UTC)
:::I hope you don't have your heart set on changing Misplaced Pages in as fundamentatl a manner as you propose, because it isn't going to happen. With 1.5 million articles out there, surely all the articles you might want to edit can't already be defended by editors with sockpuppets (violation of rules) and friends ready to defend them? Perhaps you could look at ] or ] if you're not sure where such undefended articles might be found. ] | ] 17:40, 20 December 2006 (UTC)
No of course not. I just thought I would make the suggestion. I do not claim this is the solution the problems of Misplaced Pages. When one is brainstorming, one just throws ideas out for comment. Most of them are nonsense, but they might stimulate other ideas and who knows, sometimes something good comes out of it. I also suspect there are many "orphaned" articles out there. --] 21:51, 20 December 2006 (UTC)
:Could be - there's a project to look at such articles just starting up: ], and a special page (]) to display the 1000 articles with the least recent edits. ] | ] 02:45, 21 December 2006 (UTC)
If I understood your proposal correctly, it aims to give expert views more weight in discussions/votes, and to introduce a simpler method of determining consensus. I remember ], and others, criticising Misplaced Pages for being anti-elitist, and this proposal would help address such criticism, and make it harder for trolls to game the system. A hypothetical situation where this would be useful would be a discussion where a troll tries to get a common misconception reported as a fact in the article, and an expert tries to stop him. --] 05:56, 21 December 2006 (UTC)
'''Object''' This makes absolutely no sense at all. How can you know for sure that that person is an expert on the subject? Say an example: a neurologist decides to become a Wikiholic, and start posting stuff on Neuroscience. There is no way to confirm. Besides new editors i.e. in this case the neurologist, don't have friends in Misplaced Pages. Therefore their votes will be lower. And then they may leave.--] 10:56, 21 December 2006 (UTC)
Whilst I'd agree that the current, consensus based, (effectively weighted democratic) system in Misplaced Pages is fundamentally flawed, I'm not convinced that this approach to dealing with that is adequate. You're essentially advocating a beauty contest based on a meta level rather than as it is now, on the content level. Until Misplaced Pages has some form of demonstrating expertise and utilising that in the validation of article content, we'll never get away from the rigging or pimping of votes whether on article page or in WP space. Notwithstanding that the tyrrany of ill-informed democracy does need dealing with.] 20:54, 21 December 2006 (UTC)
:I agree, this is a major problem. Most adult people with a degree have good professional knowledge in some field. I'm quite thick-skinned and used to debating on forums and so on, but a person not used to Internet can dislike this. And it's much more frustrating to defend what you really know about, and what is the common knowledge for anyone who ever had interest in the field.
:However, the way to deal with it, in my opinion, is changing attitude. Really, if an expert decides to help the site by adding some good information or fixing mistakes, he doesn't expect the ingratitutious attitude typical here. WP is becoming somewhat of thing in itself, people judged by number of edits, and anyone with few edits considered a newbie, at best met with condescending attitude.
:We just need to change the attitude, as professional knowledge is essential to filter information, and can't be replaced by trusted newspapers. By changing the attitude I do mean some measures, not just "we should". However, I'm not sure which measures. ]<sup> ]</sup> |]| 14:29, 23 December 2006 (UTC)
== search bar change ==
Hi I'd like to request a change on the placement of the search bar. I often forget where it is because of the awkward and almost unnoticible location. I think that if you moved the bar to a more visible area on the page, it would induce more browsing on the site. Thank you, and I think Misplaced Pages is awesome. <small>—The preceding ] comment was added by ] (]) 09:50, 20 December 2006 (UTC).</small><!-- HagermanBot Auto-Unsigned -->
:Where would a better place be? ] ] 15:50, 20 December 2006 (UTC)
::Maybe the top of the sidebar, under the Misplaced Pages logo? Or maybe up where the Foundation fundraiser thingie is?~ ''''']'''''<sup>(]|])</sup> 16:04, 20 December 2006 (UTC)
:::You could switch skins: Cologne Blue has the search box below the logo and Classic has it at the top of the page. ] ] 16:30, 20 December 2006 (UTC)
:::::Yup, customization is mentioned as a benefit of registering, at ]. ] | ] 17:31, 20 December 2006 (UTC)
::::::I'm guesing that our friend at IP 76.171.242.137 is a reader of Misplaced Pages; not so much an editor. Perhaps only a casual reader. Their contribution here is the only contribution from that IP address. Perhaps someday they will see that one typo they can't resist and fix it and become hooked; but for now they really aren't interested in editing and probably see no reason to register. Moreover, people are ''always'' talking about deleting unused accounts; it's somewhat of a perennial proposal. If 76.171.242.137 did register an account for the purpose of customizing his/her reading experience it would be yet another unused account for people to pick on and complain about. Moreover, ''76.171.242.137 has a valid point''. If 76.171.242.137 has trouble finding the search bar, then I guarantee that there are 10 other ''readers'' of Misplaced Pages; people who have wandered in here from a Google search or a link on some other webpage who perhaps have no idea what Misplaced Pages is who can't find the search bar. Paper encyclopedias are easy to find things in; everything is in alphabetical order, period. Misplaced Pages is one heck of a lot harder, ''especially'' if it's your first encounter with it and you don't see the search bar, don't understand that blue words are links, and can't figure out how the categories work. ~ ''''']'''''<sup>(]|])</sup> 17:51, 20 December 2006 (UTC)
:::::::what you're saying makes sense, and I'm in full agreement that concerns for readers, not editors, should be the top priority. However, the search bar seems like it's in an obvious posisition, and I'm not sure where to relocate it. ] 19:16, 20 December 2006 (UTC)
A more obvious place would be in the upper left corner, ''above'' the globe. I realize that the more graphically inclined may strongly object to that, but if the goal is to make the reader experience as trouble-free as possible, the page shouldn't be treated as an art project. ] | ] 02:41, 21 December 2006 (UTC)
'''Object''' I am used to it, and so will you.--] 10:58, 21 December 2006 (UTC)
Have you noticed that when you type in wikipedia.org, there is a seachbrowser just underneath the logo? You have to try to miss that
-Charlie34
== Misplaced Pages Toolbar ==
Hi,
Beyond any doubt wikipedia is a lovely thing to have in our cyber world. I am a big fan of her. Though I dont have a very specific area of experties where i can be helpful to your project but i do have one suggestion.
Like some other services like google, answers, yahoo and msn etc. I would suggest that wikipedia may like to launch a comprehensive and free toolbar for desktop use.
I hope i may not have disappointed you with my suggestion.
Thanx <small>—The preceding ] comment was added by ] (] • ]){{#if:{{{2|}}}| {{{2}}}|}}.</small><!-- Template:Unsigned -->
:See ] :) —] 20:09, 20 December 2006 (UTC)
== Spoilers on http://www.wikicities.com/c:Lost ==
I went to http://www.wikicities.com/c:Lost, thinking it was some sort of new wikipedia-related technological thing. It turned to be a page about the television show "Lost". That wasn't my only discovery. I also discovered something about the show that I would have preferred to have seen on the show itself. In short, the page lacks any warning of spoilers.
I propose to make a page created solely to alert people of possible spoilers before actually veiwing the page http://www.wikicities.com/c:Lost.
Thank You <small>—The preceding ] comment was added by ] (] • ]){{#if:{{{2|}}}| {{{2}}}|}}.</small><!-- Template:Unsigned -->
:Hello there. Unfortunately, that Wiki is not part of Misplaced Pages itself (as far as I know), thus we can't "force" them to add spoiler warnings. If you clicked an external link from a Misplaced Pages article that took you there, and if you really consider this step necessary, leave a message in the talk page of the article from where you clicked the link, and explain why you think a spoiler warning should be added. Misplaced Pages is not censored, and that apparently includes spoilers. -- ] 03:59, 21 December 2006 (UTC)
:Wikicities is a service of Wikia, a for-profit company founded by Jimbo Wales, who also founded (or co-founded, depending on whom you listen to) Misplaced Pages. There is no formal association between the two entities other than sharing a founder and using the same (free, open-source) software. ] 04:07, 21 December 2006 (UTC)
== How about compensation for contributors...? ==
Direct compensation of writers by readers might be a good way to compensate Misplaced Pages contributors but another method that comes to mind is the idea of establishing a system of voting for the best contribution of the week, month or year wherein the contributor with the work with the highest number of votes would be named contributor of the week, month or year and granted an appropriate sum. I say this because most of the articles I have read seem to be of such exceptional quality that they are equally, if not more, deserving of reward and compensation as are revisions and improvements to Misplaced Pages Foundation facilities (hardware and software). And I would not stop there. I can think of just as equally deserving contributors who work or participate in the reference desks as well. ] 09:33, 21 December 2006 (UTC)
:Can't they just use ]?--] 10:59, 21 December 2006 (UTC)
::Do we have to introduce ] to Misplaced Pages? Egads! It is is prolific enough elsewhere in life. ] 11:18, 21 December 2006 (UTC)
:::No, thanks. We just like working as ]. — ] 11:23, 21 December 2006 (UTC)
::Wikipedians are free to go at any time. Slaves are not.
::I am all for a system of non-monetary rewards.
::] 01:08, 22 December 2006 (UTC)
::::Most Wikipedians, being volunteers working on a 💕, would reject monetary rewards for their contributions. According to ], ] left when ], a similar proposal, was implemented. If implemented, this proposal would drive away even more editors.
::::As a writer, I work on articles because I enjoy doing so. Recognition of my work - such as an article I've significantly contributed to achieving GA status - motivates me. Therefore, I '''support''' the idea of "contributor of the month" awards, but '''no money''' should be involved, please.
::::--] 11:36, 21 December 2006 (UTC)
::::The issue is that we could attract people who are only looking for money. That's said as I'm sure many good editors, who would like to contribute more, have to limit themselves in order to leave room for they paid job. It's exactly the same in many open source software projects: they advance in the developers spare time only, because they are unpaid. *If* a way existed to economically support people's work *without* all the bad effects that this could have I'd like the idea. Of course recognition is another matter, as others have pointed out. For other POVs, it would perhaps help to hear opinions from someone involved in Yahoo! Answers. —]] 11:54, 21 December 2006 (UTC)
::::I see a different problem. It lies in quantity. The quantity of monetary support Misplaced Pages could offer is pretty low; make it a prize or share it, it is way below the real cost of the work done. However, with money being introduced into this, everything would be viewed from a different angle, the angle of money.
::::Or, phrasing it simply: Now I contribute for my own sake, good of WP, etc, with monetary system I would contribute for $200/year. Negative effects are dual - first, contributors will feel underpaid, second, people will think "oh, it's their job".
::::And concentrating money into a single or a few rewards created the spirit of competition rather than collaboration at least, and coups, factions, conflicts... well, all these problems are far beyond possible benefits. Extra $200/year won't make me, as well as most editors, contribute more, but will make others edit less, relying on the paid ones. We have some problems of undervalued contributors, factionalism, competitions, but they are relatively harmless; adding money would make them all surface, solidify and expand. ]<sup> ]</sup> |]| 15:01, 21 December 2006 (UTC)
*There used to be a system for this but it fell flat almost immediately. ] 16:18, 21 December 2006 (UTC)
:For "best contribution of the week", see ]. ]|] 16:40, 21 December 2006 (UTC)
Okay to summarize: From what I am hearing then it is the absence of monetary gain that is not only responsible for the quality but for the doing. Compensation is not in monetary gain but in the accomplishment. The idea of nominating and voting on the best contribution (and hence contributor) of the week, month or year is good but not the 3 to 14 day cruise through the Caribbean they would derive from the honor. No-strings-attached Direct PayPal donations by any user to any other user as thanks or to show appreciation or gratitude for a well written article or reference desk solution to a problem would be okay.
Thanks very much to everyone for expressing your head and heart felt opinion. ] 23:02, 21 December 2006 (UTC)
:Just thought I'd throw in some food/links for thought: ] and ], which was intended to be somewhat analagous to ], I believe. ]-] 23:13, 21 December 2006 (UTC)
::Having linked to the ] and read ] the thought occurred to me that if a newspaper editor for instance needed research on a particular topic this might be one way to get it without paying boo coo dollars to a hired gun for it. So there may already be means of compensation present which simply find no need to be well advertized. Call it the Misplaced Pages writer pool - sort of like the bar down the road where all the local writer types hang out? ] 00:53, 22 December 2006 (UTC)
:::The honor of contributing to this great encyclopedia is the only compenation that I need. I'm proud of it. --<font face="Kristen ITC">] ]</font><sup>]</sup> 01:48, 22 December 2006 (UTC)
:Check ]. -- ] 04:35, 22 December 2006 (UTC)
:2Adaptron: My opinion is that direct donations by someone to someone are fine. Having a WMF budget for prizes isn't, because it will make it look "''Mostly'' non-profit". Maybe something independent would work well. I mean, when people donate to Misplaced Pages, they donate for servers and their maintenance, all the things which keep the system running. Having a separate initiative with a fund for rewarding contributors would work fine. However, to add to, not to replace what we have now. ]<sup> ]</sup> |]| 06:08, 22 December 2006 (UTC)
::Whatever meets consensus is fine with me since that's how the Misplaced Pages got to where it is today and can get to where it's going in the future. Besides keeping hardware and software state-of-the-art, eliminating bottlenecks, adding servers, increasing speed, etc. is an ever increasing expense that demands every penny donors can provide. ] 08:29, 22 December 2006 (UTC)
This is similar as in free software: Wikimedia cannot itself pay contributors, but third parties are free to hire people to work on a specific article, similar to SUSE hiring programmers to work on the Linux kernel. Nobody can keep me, for example, from hiring three people to clean up vandalism and do categorization tasks. Or from promising $100 to my mate if he should get ] to FA status. Funding 'wikijobs' could be a new form of donation to the project, without direct involvement of Wikimedia. ] <small>]</small> 09:23, 22 December 2006 (UTC)
:And there's nothing to stop individuals from donating to Misplaced Pages indirectly by hiring someone to work on it for them. For example, lets say I'm a CEO and I earn 99 bazillian dollars a year, and I love the idea of improving articles on Misplaced Pages. I can't "afford" to work on articles myself because my time is so valuable to my company, but I can easily afford to hire 100 college kids during the summer to do nothing but sit around and improve articles on Misplaced Pages. They get $15 an hour, Misplaced Pages gets improved a lot more than it would if I did it myself. — ] <small>(]|])</small> 15:23, 22 December 2006 (UTC)
:'''Some stuff to think about'''
::*Where would the money come from?
::*How would we know where to send the money (users aren't required to say anything about their real identities or place of residence)
:::]] 20:43, 22 December 2006 (UTC)
There have been PR firms which were taking money to write Misplaced Pages articles for their clients, but this is frowned upon as a violation of ]. ]|] 03:30, 24 December 2006 (UTC)
== Spam blacklist type of warning feature ==
Misplaced Pages already has in place a spam blacklist which prevents page saves when certain URLs are detected on the page. I'd like to propose a similar type of system. It would not be a blanket refusal to save, but rather would pop up a warning (as we used to have with blank edit summaries before the autofill feature came along) when certain words are detected. The editor would still be able to save, but at least he would hav been alerted to this. It would be of great help to newbies especially. Words I'm targeting off the top of my head are things like "recent", "recently", "lately" etc. that should not be in a "permanent" encyclopedia article. I'm sure others could even think of different ways to take this, e.g. identifying certain adjectives as ] and ]. Thoughts? '''<font color="red">]</font><font color="green">]</font><font color="blue">]</font><font color="orange">]</font>''' 13:17, 21 December 2006 (UTC)
*Hm, interesting. A similar system could be used to block out vandalistic swearwords (except, of course, that we have articles on most of those words). But if it's just a pop-up, don't you think people will just ignore it? If it's not a pop-up but a refusal-to-save, don't you think this may annoy people and they will abandon their edit? ] 16:17, 21 December 2006 (UTC)
*I question that this would work. What about quotes? There are also some subjects that use swear words encyclopedically like ]. Also it can be quite discouraging to new users, similar to when your doing a long online registration and constant problems show up about the entered fields like "too short of a password / taken username", the point: its frustrating. ] 16:44, 21 December 2006 (UTC)
**Not a pop-up window exactly...it would just bring up the edit page again like does with blank edit summaries (just in case anyone reading this isn't aware, you can set it in your Preferences/Editing menu to "prompt me on blank edit summary"). The word list should obviously be cautiously applied, I'm thinking more in terms of encyclopedicness (encyclopedicity?) than profanity. Things like "recently" should NEVER be in a good encyclopedia article. For a profanity filter, perhaps an admin-settable flag can enable a whitelist allowing swear words on a per-article basis, without popping up the warning. '''<font color="red">]</font><font color="green">]</font><font color="blue">]</font><font color="orange">]</font>''' 07:57, 22 December 2006 (UTC)
***Again I'm questing if that would work. What if the user is not familiar with our guidelines on ] and ]. If the user is unable to save then I don't think he/she will understand why. Providing an optional (preferences) pop up in my opinion would be the best scenario. Pop up like "You used , which is considered unencyclopedic. Continue?". That ofcourse again being optional for registered users. But completely restricting saving of pages based on words is bound to create problems and wiki-break frustrations. ] 15:54, 22 December 2006 (UTC)
Kind of a related idea: What about doing something like this for users that have been blocked in the last 90 days? Any time a recent vandal tried to add any word in a large list of common vandalism words, they'd have to go through an extra step before being able to save the page. On the "warning page" there would be an admonishment not to revandalize: "Based on keywords in your edit, it appears that you are attempting to ] this page. You may still proceed with your changes by clicking the Save Page button below, but be aware that your edit will be speedily reverted if any vandalism is confirmed." Then, a special note would be automatically appended to the edit summary highlighting the edit as possible vandalism. — ] <small>(]|])</small> 15:12, 22 December 2006 (UTC)
== Downloadable open source Misplaced Pages software for your computer ==
I have an idea of developing an open source application that you can download and install on your computer, much like Encarta from Microsoft. The catch is that this downloaded encyclopedia is faster to access then on the web and also this program can have built in update capabilities so that every user can stay up to date. This will not only get some of the traffic off Misplaced Pages's servers but also publicize Misplaced Pages and make it into a household name, much like Google. Imagine that parents download and install this for their kids so they will still be able to do their homework and stay off the web that is filled with pedophiles and bad things for children. Not only will this help Misplaced Pages but also many parents who do not want to waste money on Encarta. Therefore, seize this opportunity and begin working on this project because it is the future of Misplaced Pages. 20:36, 21 December 2006 {{unsigned|Mcstcisco}}
::Not only of the future but of the past... Although not mentioned in the ] article IE has a syncronization option which most other browsers probably have which offers download scheduling capability much the same as scheduling for any other task. Click on the "Favorites" dropdown, select "Add to favirites..." and click on the "Make available offline" checkbox. ] 10:08, 22 December 2006 (UTC)
== RfC: Log the use of the ] at both the merge target and merge source ==
::This sort of idea is very important for those of us who work in less-wealthy regions and do not have constant internet access. We must rely on expensive Encarta subscriptions or other resources for general reference. It would be extremely useful to take a "snapshot" of the most popular Misplaced Pages articles and distribute it at low cost on a DVD. --From a global health student, Dec. 2006. <small>—The preceding ] comment was added by ] (] • ]) 21:45, 23 December 2006 (UTC).</small><!-- HagermanBot Auto-Unsigned -->
<!-- ] 16:01, 25 December 2024 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1735142470}}
== Allowing edit summaries on "rollbacks" ==
The rollback button is great to undo bad edits, but it can piss off people having their work undone without an explanation. Rollback should only be used on obvious vandals that deserve no explanation, of course, but sometimes convenience trumps caution. - ] 21:50, 21 December 2006 (UTC)
:What I do is I install ] and set <code>popupRevertSummaryPrompt=true;</code> so it prompts me for an edit summary every time I do a revert, and I have a choice of either entering an edit summary or leaving the default summary for vandalism reverts. ] ] 22:10, 21 December 2006 (UTC)
::For several weeks, I've been thinking up a similar proposal.
::Under my proposal, there will be a small text box next to the rollback button. The rollbacking admin may enter a code into the text box (entering a code is optional). Based on the code entered, an appropriate edit summary will be generated, and an appropriate warning issued to the offender.
::For example, when rollbacking spam, if an admin enters "spam2" as a code, the edit summary will indicate that they are rollbacking spam, and a <nowiki>{{spam2}}</nowiki> warning would be issued to the spammer.
::I discussed my proposal with ], a developer, on IRC, and he suggested that a user script would be more appropriate for this purpose.
::--] 02:51, 22 December 2006 (UTC)
Currently, there are open proposing that the use of the HistMerge tool be logged at the target article in addition to the source article. Several proposals have been made:
== "Edit Summary" capacity ==
*'''Option 1a''': When using ], a null edit should be placed in both the merge target and merge source's page's histories stating that a history merge took place.
*: (]: '''Special:MergeHistory should place a null edit in the page's history describing the merge''', authored Jul 13 2023)
*'''Option 1b''': When using ], add a log entry recorded for the articles at the both HistMerge target and source that records the existence of a history merge.
*: (]: '''Merging pages should add a log entry to the destination page''', authored Nov 8 2015)
*'''Option 2''': Do not log the use of the ] tool at the merge target, maintaining the current status quo.
Should the use of the HistMerge tool be explicitly logged? If so, should the use be logged via an entry in the page history or should it instead be held in a dedicated log? — ] <sub>]</sub> 15:51, 20 November 2024 (UTC)
===Survey: Log the use of the ]===
*'''Option 1a/b'''. I am in principle in support of adding this logging functionality, since people don't typically have access to the source article title (where the histmerge is currently logged) when viewing an article in the wild. There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. As for whether this is logged directly in the page history (as is done currently with page protection) or if this is merely in a separate log file, I don't have particularly strong feelings, but I do think that adding functionality to log histmerges at the target article would improve clarity in page histories. — ] <sub>]</sub> 15:51, 20 November 2024 (UTC)
*'''Option 1a/b'''. No strong feelings on which way is best (I'll let the experienced histmergers comment on this), but logging a history merge definitely seems like a useful feature. ] (] · ]) 16:02, 20 November 2024 (UTC)
*'''Option 1a/b'''. Choatic Enby has said exactly what I would have said (but more concisely) had they not said it first. ] (]) 16:23, 20 November 2024 (UTC)
*'''1b''' would be most important to me but but '''1a''' would be nice too. But this is really not the place for this sort of discussion, as noted below. ] (]) 16:28, 20 November 2024 (UTC)
* '''Option 2''' History merging done right should be seamless, leaving the page indistinguishable from if the copy-paste move being repaired had never happened. Adding extra annotations everywhere runs counter to that goal. Prefer 1b to 1a if we have to do one of them, as the extra null edits could easily interfere with the history merge being done in more complicated situations. ] ] 16:49, 20 November 2024 (UTC)
*:Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. ] (]) 17:29, 20 November 2024 (UTC)
*:: Why shouldn't it be indistinguishable? Why it it necessary to go out of our way to say even louder that someone did something wrong and it had to be cleaned up? ] ] 17:45, 20 November 2024 (UTC)
*:::All cleanup actions are logged to all the pages they affect. ] (]) 18:32, 20 November 2024 (UTC)
* '''2''' History merges ], so this survey name is somewhat off the mark. As someone who does this work: I do not think these should be displayed at either location. It would cause a lot of noise in history pages that people probably would not fundamentally understand (2 revisions for "please process this" and "remove tag" and a 3rd revision for the suggested log), and it would be "out of order" in that you will have merged a bunch of revisions but none of those revisions would be nearby the entry in the history page itself. I also find protections noisy in this way as well, and when moves end up causing a need for history merging, you end up with doubled move entries in the merged history, which also is confusing. Adding history merges to that case? No thanks. History merges are more like deletions and undeletions, which already do not add displayed content to the history view. ] (]) 16:54, 20 November 2024 (UTC)
*:They presently are logged, but only at the source article. Take for example . When I search for the merge target, I get . It's only when I search the that I'm able to get a result, but there isn't a way to ''know'' the merge source.
*:If I don't know when or if the histmerge took place, and I don't know what article the history was merged from, I'd have to look through the entirety of the merge log manually to figure that out—and that's suboptimal. — ] <sub>]</sub> 17:05, 20 November 2024 (UTC)
*::... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
*::But ignoring that, why is it valuable to know this information? What do you gain? And is what you gain actually valuable to your end objective? For example, let's take your {{tq|There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful.}} Is not the revisions left behind in the page history by both the person requesting and the person performing the histmerge not enough (see {{tl|histmerge}})? There are history merges done that don't have that request format such as the WikiProject history merge format, but those are almost always ancient revisions, so what are you gaining there? And where they are not ancient revisions, they are trivial kinds of the form "draft x -> page y, I hate that I even had to interact with this history merge it was so trivial (but also these are great because I don't have to spend significant time on them)". ] (]) 17:32, 20 November 2024 (UTC)
*:::{{tqb|... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)}}I don't think everyone would necessarily agree (see Toadspike's comment below). ] (] · ]) 17:42, 20 November 2024 (UTC)
*:::Page moves ''do'' leave a null edit on the page that describes where the page was moved from and was moved to. And it's easy to work backwards from there to figure out the page move history. The same cannot be said of the ] tool, which doesn't make it easy to re-construct what the heck went on unless we start diving naïvely through the logs. — ] <sub>]</sub> 17:50, 20 November 2024 (UTC)
*::It can be *possible* to find the original history merge source page without looking through the merge log, but the method for doing so is very brittle and extremeley hacky. Basically, look for redirects to the page using "What links here", and find the redirect whose first edit has an unusual byte difference. This relies on the redirect being stable and not deleted or retargetted. There is also ] that relies on byte difference bugs as described in the above-linked discussion by ]. Both of those are ... particularly awful. ] (]) 03:48, 21 November 2024 (UTC)
*:::In the given example, the history-merge occurred ]. Your "log" is the edit summaries. "Created page with '..." is the edit summary left by a normal page creation. But wait, there is page history before the edit that created the page. How did it get there? Hmm, the previous edit summary "Declining submission: v - Submission is improperly sourced (AFCH)" tips you off to look for the same title in draft: namespace. Anyone looking for help with understanding a particular merge may ask me and I'll probably be able to figure it out for you. – ] (]) 05:51, 21 November 2024 (UTC)
*:::Here's another example, of a merge within mainspace. The ] (created by the MediaWiki software) of this ] "Removed redirect to {{no redirect|Jordan B. Acker}}" points you to the page that was merged at that point. . . . – ] (]) 13:44, 21 November 2024 (UTC)
*::::There are times where those traces aren't left. ] (]) 13:51, 21 November 2024 (UTC)
*:::::Here's another scenario, this one from ]. The shows an edit adding '''+5,800''' bytes, leaving the page with 5,800 bytes. But the previous edit did not leave a blank page. Some say this is a bug, but it's also a feature. That "bug" is actually your "log" reporting that a hist-merge occurred at that edit. , the log for that page shows a temp delete & undelete setting the page up for a merge. The first item on the log:
*::::::@ 20:14, 16 January 2021 Tbhotch moved page ] to {{no redirect|Flag of the Republic of Yucatán}} (Correct name)
*:::::clues you in to where to look for the source of the merge. , that single edit which removed '''−5,633''' bytes tells you that previous history was merged off of that page. The provides the details. – ] (]) 16:03, 21 November 2024 (UTC)
*:::::(]: '''Special:MergeHistory causes incorrect byte change values in history''', authored Dec 2 2014) <!-- Template:Unsigned --><small class="autosigned">— Preceding ] comment added by ] (] • ]) 18:13, 21 November 2024 (UTC)</small>
*::::::Again, there are times where the clues are much harder to find, and even in those cases, it'd be much better to have a unified and assured way of finding the source. ] (]) 16:11, 21 November 2024 (UTC)
*:::::::Indeed. This is a prime example of an unintended ]. ] (]) 08:50, 22 November 2024 (UTC)
*::::::::Yeah. I don't think that we can permanently rely on that, given that future versions of MediaWiki are not bound in any real way to support that workaround. — ] <sub>]</sub> 04:24, 3 December 2024 (UTC)
*'''Support 1b''' (log only), oppose 1a (null edit). I defer to the experienced histmergers on this, and if they say that adding null edits everywhere would be inconvenient, I believe them. However, I haven't seen any arguments against logging the histmerge at both articles, so I'll support it as a sensible idea. (On a similar note, it bothers me that page moves are only logged at one title, not both.) ] </span>]] 17:10, 20 November 2024 (UTC)
* '''Option 2'''. The merges are ], so there’s no reason to add it to page histories. While it may be useful for habitual editors, it will just confuse readers who are looking for an old revision and occasional editors. ] & ]<sub>(])</sub> 18:33, 20 November 2024 (UTC)
*:But only the source page is logged as the "target". IIRC it currently can be a bit hard to find out when and who merged history into a page if you don't know the source page and the mergeperson didn't leave any editing indication that they merged something. ] (]) 18:40, 20 November 2024 (UTC)
*'''1B'''. The present situation of the action being only logged at one page is confusing and unhelpful. But so would be injecting null-edits all over the place. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 01:38, 21 November 2024 (UTC)
* '''Option 2'''. This exercise is dependent on finding a volunteer MediaWiki developer willing to work on this. Good luck with that. Maybe you'll find one a decade from now. – ] (]) 05:51, 21 November 2024 (UTC)
*: And, more importantly, someone in the to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. ] ] 06:03, 21 November 2024 (UTC)
*::That link requires a Gerrit login/developer account to view. It was a struggle to get in to mine (I only have one because of an old Toolforge account and I'd basically forgotten about it), but for those who don't want to go through all that, that group has only 82 members (several of whose usernames I recognise) and I imagine they have a lot on their collective plate. There's more information about these groups at ]. ] (]) 15:38, 21 November 2024 (UTC)
*::: Sorry, I totally forgot Gerrit behaved in that counterintuitive way and hid public information from logged out users for no reason. The things you miss if Gerrit interactions become something you do pretty much every day. If you want to count the members of the group you also have to follow the chain of included groups - it also includes https://ldap.toolforge.org/group/wmf, https://ldap.toolforge.org/group/ops and (another login-only link), as well as a few other permission edge cases (almost all of which are redundant because the user is already in the MediaWiki group) ] ] 18:07, 21 November 2024 (UTC)
*'''Support 1a/b''', and I would encourage the closer to disregard any opposition based solely on the chances of someone ever actually implementing it. <span style="white-space: nowrap;">—] <sup>(]·])</sup></span> 12:52, 21 November 2024 (UTC)
*:Fine. This stupid RfC isn't even asking the right questions. Why did I need to delete (an expensive operation) and then restore a page in order to Should we fix the software so that it doesn't require me to do that? Why did the page-mover resort to cut-paste because there was page history blocking their move, rather than ask a administrator for help? Why doesn't the software just let them move over that junk page history themselves, which would negate the need for a later hist-merge? (Actually in this case the offending user only has made 46 edits, so they don't have page-mover privileges. But they were able to move a page. They just couldn't move it back a day later after they changed their mind.) ] (]) 13:44, 21 November 2024 (UTC)
*::Yeah, ] would be amazing, for a start. ] (]) 15:38, 21 November 2024 (UTC)
*'''Option 1b'''{{snd}}changes to a page's history should be listed in that page's log. There's no need to make a null edit; pagemove null edits are useful because they meaningfully fit into the page's revision history, which isn't the case here. ] (]) 00:55, 22 November 2024 (UTC)
*'''Option 1b''' sounds best since that's what those in the know seem to agree on, but 1a would probably be OK. ] (]) 03:44, 23 November 2024 (UTC)
*'''Option 1b''' seems like the one with the best transparency to me. Thanks. <span style="text-shadow:3px 3px 3px lightblue">]<sup>'''537'''<sub>]</sub> (]|])</sup></span> 06:59, 25 November 2024 (UTC)
===Discussion: Log the use of the ]===
I think the area for "Edit Summary" should have a larger capacity. I think it is unrealistic to expect people to say all they want to say about why they are making the changes they are making, especially as concerns the reverts of someone else's writing. The Talk page is a good thing, but it is too far away to allow for the immediate explanation that is called for. I think the "Edit Summary" should be further divided into a "brief" section and a slightly "extended" section. The "extended" section should still be very limited. But it should allow several times the length of writing that the present "Edit Summary" allows for. I think this would allow people to appear to be acting in a more humane way towards one another. Presently, it is very common for reverts to engender bad feelings. It is almost impossible to try to smooth over the almost inevitable bad feelings that tend to result from reverts. ] 02:52, 22 December 2006 (UTC)
*I'm noticing some commentary in the above RfC (on widening importer rights) as to whether or not this might be useful going forward. I do think that having the community weigh in one way or another here would be helpful in terms of deciding whether or not this functionality is worth building. — ] <sub>]</sub> 15:51, 20 November 2024 (UTC)
*:<small>] . — ] <sub>]</sub> 16:01, 20 November 2024 (UTC)</small>
*This is a missing feature, not a config change. ] (]) 15:58, 20 November 2024 (UTC)
*:Indeed; it's about a feature proposal. — ] <sub>]</sub> 16:02, 20 November 2024 (UTC)
*As many of the above, this is a ] and not something that should be special for the English Misplaced Pages. — ] <sup>]</sup> 16:03, 20 November 2024 (UTC)
*:See ]. I'm not seeing any sort of reason this would need per-project opt-ins requiring a local discussion. — ] <sup>]</sup> 16:05, 20 November 2024 (UTC)
*:True, but I agree with Red-tailed hawk that it's good to have the English Misplaced Pages community weigh on whether we want that feature implemented here to begin with. ] (] · ]) 16:05, 20 November 2024 (UTC)
* Here is the , and the project's . – ] (]) 18:13, 21 November 2024 (UTC)
* I agree that this is an odd thing to RFC. This is about a feature in MediaWiki core, and there are a lot more users of MediaWiki core than just English Misplaced Pages. However, please do post the results of this RFC to both of the phab tickets. It will be a useful data point with regards to what editors would find useful. –] <small>(])</small> 23:16, 21 November 2024 (UTC)
== CheckUser for all new users ==
* '''Oppose''' - I see this as adding an odd level of omplexity, and being unlikely to be used much. As for the reasoning: It is the fact of the revert that hurts and upsets poeple, not what is written in the edit summary. It is on the talk pages that the differences need to be ironed out. --] | ] 05:02, 22 December 2006 (UTC)
* '''Comment''' I do not think we need this complexity. However, I would like having the limit raised to 250 or 300. I usually write long edits when reverting, and could use an extra 50 characters :-) -- ] 05:07, 22 December 2006 (UTC)
*You're asking to change an arbitrary limit into another arbitrary limit. Since this requires a database change, it is probably Not Going To Happen. ] 12:29, 22 December 2006 (UTC)
All new users (IPs and accounts) should be subject to CheckUser against known socks. This would prevent recidivist socks from returning and save the time and energy of users who have to prove a likely case at SPI. Recidivist socks often get better at covering their "tells" each time making detection increasingly difficult. Users should not have to make the huge effort of establishing an SPI when editing from an IP or creating a new account is so easy. We should not have to endure ], ] or ] if CheckUser can prevent them. ] (]) 04:06, 22 November 2024 (UTC)
*Yes, of course it is arbitrary. How could it not be arbitrary? My argument is there's a big gap from the edit summary to the talk page. The edit summary is a necessary part of making changes, but the talk page is seen as an option. I think there should be an "option" built right into the edit summary. Like, ''"click here for extended space for edit summary."'' That way, those who are so inclined, can try to smooth over hurt feelings that are so common. I think the extended area should be about 2 or 3 times the present edit summary area. ] 13:13, 22 December 2006 (UTC)
:I'm pretty sure that even if we had enough checkuser capacity to routinely run checks on every new user that doing so would be contrary to global policy. ] (]) 04:14, 22 November 2024 (UTC)
* '''Strong support''', together with making the summary '''mandatory'''. I can't say in words how much time I spent (''i.e.'' waste) looking at diffs of people who don't write edit summaries; that's just an irresponsible behavior. (Bogus edit summaries, in case someone begins adopting them as a "workaround", should be treated as vandalism.) —]] 12:52, 22 December 2006 (UTC)
:Setting aside privacy issues, the fact that the WMF wouldn't let us do it, and a few other things: Checking a single account, without any idea of who you're comparing them to, is not very effective, and the worst LTAs are the ones it would be least effective against. This has been floated several times in the much narrower context of adminship candidates, and rejected each time. It probably belongs on ] by now. <span style="font-family:courier"> -- ]</span><sup class="nowrap">[]]</sup> <small>(])</small> 04:21, 22 November 2024 (UTC)
::Why can't it be automated? What are the privacy issues and what would WMF concerns be? There has to be a better system than SPI which imposes a huge burden on the filer (and often fails to catch socks) while we just leave the door open for LTAs. ] (]) 04:39, 22 November 2024 (UTC)
:::How would it be automated? We can't just block everyone who even sometimes shares an IP with someone, which is most editors once you factor in mobile editing and institutional WiFi. Even if we had a system that told checkusers about all shared-IP situations and asked them to investigate, what are they investigating for? The vast majority of IP overlaps will be entirely innocent, often people who don't even know each other. There's no way for a checkuser to find any signal in all that noise. So the only way a system like this would work is if checkusers manually identified IP ranges that are being used by LTAs, and then placed blocks on those ranges to restrict them from account creation... Which is what already happens. <span style="font-family:courier"> -- ]</span><sup class="nowrap">[]]</sup> <small>(])</small> 04:58, 22 November 2024 (UTC)
::::I would assume that IT experts can work out a way to automate CheckUser. If someone edits on a shared IP used by a previous sock that should be flagged and human CheckUsers notified so they can look at the edits and the previous sock edits and warn or block as necessary. ] (]) 05:46, 22 November 2024 (UTC)
:::::We already have ]. For cases it doesn't catch, there's an additional manual layer of blocking, where if a sock is caught on an IP that's been used before but wasn't caught by autoblock, a checkuser will block the IP if it's technically feasible, sometimes for months or years at a time. Beyond that, I don't think you can imagine just how often "someone edits on a shared IP used by a previous sock". I'm doing that right now, probably, because I'm editing through T-Mobile. Basically anyone who's ever edited in India or Nigeria has been on an IP used by a previous sock. Basically anyone who's used a large institution's WiFi. There is not any way to weed through all that noise with automation. <span style="font-family:courier"> -- ]</span><sup class="nowrap">[]]</sup> <small>(])</small> 05:54, 22 November 2024 (UTC)
::::::Addendum: An actually potentially workable innovation would be something like a system that notifies CUs if an IP is autoblocked more than once in a certain time period. That would be a software proposal for Phabricator, though, not an enwiki policy proposal, and would still have privacy implications that would need to be squared with the WMF. <span style="font-family:courier"> -- ]</span><sup class="nowrap">[]]</sup> <small>(])</small> 05:57, 22 November 2024 (UTC)
::::::I believe Tamzin has it about right, but I want to clarify a thing. If you're hypothetically using T-Mobile (and this also applies to many other ISPs and many LTAs) then the odds are very high that you're using an IP address which has never been used before. With T-Mobile, which is not unusually large by any means, you belong to at least one /32 range which contains a number of IP addresses so big that it has 30 digits. These ranges contain a huge number of users. At the other extreme you have some countries with only a handful of IPs, which everyone uses. These IPs also typically contain a huge number of users. TLDR; is someone is using a single IP on their own then we'll probably just block it, otherwise you're talking about matching a huge number of users. -- ] <sup>]</sup> 03:20, 23 November 2024 (UTC)
:::::::As I understand it, if you're hypothetically using T-Mobile, then you're not editing, because someone range-blocked the whole network in pursuit of a vandal(s). See ]. ] (]) 03:36, 23 November 2024 (UTC)
::::::::T-Mobile USA is a perennial favourite of many of the most despicable LTAs, but that's besides the point. New users with an account can actually edit from T-Mobile. They can also edit from Jio, or Deutsche Telecom, Vodafone, or many other huge networks. -- ] <sup>]</sup> 03:50, 23 November 2024 (UTC)
:Would violate the policy ]. –] <small>(])</small> 04:43, 22 November 2024 (UTC)
::It would apply to '''every new User''' as a protective measure against sockpuppetry, like a credit check before you get a card/overdraft. ] is archaic like the whole burdensome SPI system that forces honest users to do all the hard work of proving sockpuppetry while socks and vandals just keep being welcomed in under ]. ] (]) 05:46, 22 November 2024 (UTC)
:::What you're suggesting is to just inundate checkusers with thousands of cases. The suggestion (as I understand it) removes burden from SPI filers by adding a disproportional burden on checkusers, who are already an overworked group. If you're suggesting an automated solution, then I believe IP blocks/IP range blocks and autoblock (discussed by Tamzin, above) already cover enough. It's quite hard to weigh up what you're really suggesting because it feels very vague without much detail - it sounds like you're just saying "a new SPI should be opened for every new user and IP, forever" which is not really a workable solution (for instance, ], which is about one every 18 seconds) ]] 18:12, 22 November 2024 (UTC)
::::And most of those accounts will make zero, one, or two edits, and then never be used again. Even if we liked this idea, doing it for every single account creation would be a waste of resources. ] (]) 23:43, 22 November 2024 (UTC)
:No, they should not. ] (]/]) 17:23, 22 November 2024 (UTC)
:This, very bluntly, ], and as noted by Tamzin this would result in frankly ''obscene'' amounts of collateral damage. You have absolutely no idea how frequently IP addresses get passed around (especially in the developing world or on ]), such that it could feasibly have three different, unrelated, people on it over the course of a day or so. —] ] <sup><small>] ]</small></sup> 18:59, 22 November 2024 (UTC)
:{{Question|label=Just out of curiosity}} If a certain ] is any indication, would a CU be able to stop that in its track? <span style="color:#7E790E;">2601AC47</span> (]|]) <span style="font-size:80%"><span style="color:grey;">Isn't a IP anon</span></span> 14:29, 23 November 2024 (UTC)
::CU's use their tools to identify socks when technical proof is necessary. The problem you're linking to is caused by one particular ] account who is extremely obvious and doesn't really require technical proof to identify - check users would just be able to provide evidence for something that is already easy to spot. There's an essay on the distinction over at ] ]] 14:45, 23 November 2024 (UTC)
::{{ping|2601AC47}} No, and that is because the user in question's MO is to abuse VPNs. Checkuser is worthless in this case because of that (but the IPs ''can and should'' be blocked for 1yr as ]). —] ] <sup><small>] ]</small></sup> 19:35, 26 November 2024 (UTC)
:::] is using a peer-to-peer VPN service which is similar to ]. Blocking peer-to-peer VPN service endpoint IP addresses carries a higher risk of collateral damage because those aren't assigned to the VPN provider but rather a third party ISP who is likely to dynamically reassign the blocked address to a completely innocent party. ] (]) 00:22, 27 November 2024 (UTC)
:I slightly oppose this idea. This is not ] where socks are immediately banned or shadowbanned outright. Reddit doesn't have ] as any wiki does. ] (]) 00:14, 25 November 2024 (UTC)
::How do you know this is how Reddit deals with ban and suspension evasion? They use advanced techniques such as device and IP fingerprinting to ban and suspend users in under an hour. ] (]) 23:47, 28 November 2024 (UTC)
:I can see where this is coming from, but we must realise that checkuser is not ] nor is it meant for ]. - ] (]) 04:49, 27 November 2024 (UTC)
::The question I ask myself is why must we realize that it is not meant for fishing? To catch fish, you need to fish. The no-fishing rule is not fit for purpose, nor is it a rule that other organizations that actively search for ban evasion use. Machines can do the fishing. They only need to show us the fish they caught. ] (]) 05:24, 27 November 2024 (UTC)
:::I think for the same reason we don't want governments to be reading our mail and emails. If we checkuser everybody, then nobody has any privacy. ] 20:20, 27 November 2024 (UTC)
I sympathize with Mztourist. The current system is less effective than it needs to be. Ban evading actors , they are dedicated hard-working folk in contentious topic areas. They can make up nearly 10% of new extendedconfirmed actors some years and the quicker an actor becomes EC the more likely they are to be blocked later for ban evasion. Their presence splits the community into two classes, the sanctionable and the unsanctionable with completely different payoff matrices. This has many consequences in contentious topic areas and significantly impacts the dynamics. The current rules are probably not good rules. Other systems have things like a 'commitment to authenticity' and actively search for ban evasion. It's tempting to burn it all down and start again, but with what? Having said that, the SPI folks do a great job. The average time from being granted extendedconfirmed to being blocked for ban evasion seems to be going down. ] (]) 18:28, 22 November 2024 (UTC)
*Yes, it should be mandatory. It should not be possible to proceed without inserting ''something'' in the edit summary box. I hadn't thought of that, but I wholeheartedly agree with that. I think these are the sort of things that are more likely to result in compatibility between participants. (And Misplaced Pages should more clearly post the importance of explaining ''what you have done and why you did it''.) ] 13:27, 22 December 2006 (UTC)
**I disagree. It should not be mandatory. Besides from simply editing own userspace, there are different kinds of articles. There are high-profile articles where conflicts are frequent, true. But there also is a lot - and a bigger lot - of noncontroversial articles worked upon by one or a few editors who trust each other, or at least know to use the talk page. They don't need edit summaries. Also, making them mandatory will not only take time, but deter newcomers, and most people will use primitive summaries like "edit", "sp", "style", "expand". I actually find myself at times unable to write anything more about editing an article where I'm the main contributor; not to mention wikiprojects, talk pages, et cetera. ]<sup> ]</sup> |]| 16:30, 22 December 2006 (UTC)
***Pretty much anything needs edit summaries. The "articles worked upon by one or a few editors who trust each other" issue is not even worth commenting; if you want a private wiki set up one. Summaries consisting only of the words you mention, and others, would not be accepted, similarly to ] in search engines. Users trying to "workaround" this measures would be just vandals and treated as such. Note that this is not ''being harsh'' but being ''responsible'', which is totally different. —]] 16:51, 22 December 2006 (UTC)
****I often run into the edit summary limit, but I think the current length is relatively ok. I would also ask the edit summaries be made mandatory, but for non-minor edits ... I think that the summary should be optional for minor edits. I wonder is there is a way to have a 'say more' button available that would create an link automatically to a new section on the talk page, the link appearing in the edit summary - I think that would be a helpful addition. --User:Ceyockey (<small>'']''</small>) 17:39, 22 December 2006 (UTC)
*****Lot of things could be done. One can sort of imagine ClearCase-like comments, for instance. But when it comes to modifying MediaWiki we have to cope with the most recalcitrant open source team that I've ever come upon. —]] 17:46, 22 December 2006 (UTC)
****"''Users trying to "workaround" this measures would be just vandals and treated as such.''" - Do you just realize what you are saying? And what we are here for? Misplaced Pages is not an experiment in enforcing discipline and ordnung on volunteers. It is not army. Not even volunteer corps. And not a police state. While some people try to make it more accessible to newcomers and attract them, others find nothing better than to invent regulations they want their lined up units to follow and punisments for failure to comply. Is "vandal" a new term for "regulations violator"? Do you consider the fact that this term has ], and a pretty specific one? Am I a vandal now, because I used edit summary "reply"? ]<sup> ]</sup> |]| 14:43, 23 December 2006 (UTC)
:I confess that I am doubtful about that 10% claim. ] (]) 23:43, 22 November 2024 (UTC)
::{{u|WhatamIdoing}}, me too. I'm doubtful about everything I say because I've noticed that the chance it is slightly to hugely wrong is quite high. The EC numbers are work in progress, but I got distracted. The description "nearly 10% of new extendedconfirmed actors" is a bit misleading, because 'new' doesn't really mean new actors. It means actors that acquired EC for a given year, so newly acquired privileges. They might have registered in previous years. Also, I don't have 100% confidence in the way count EC grants because there are some edge cases, and I'm ignoring sysops. But anyway, the statement was based on . And the statement about a potential relationship between speed of EC acquisition and probability of being blocked is based on . And of course, currently undetected socks are not included, and there will be many. ] (]) 03:39, 23 November 2024 (UTC)
:::I'm not interested in clicking through to a Google file. Here's my back-of-the-envelope calculation: We have something like 120K accounts that would qualify for EXTCONF. Most of these are no longer active, and many stopped editing so long ago that they don't actually have the user right.
:::Misplaced Pages is almost 24 years old. That makes convenient math: On average, since inception, 5K editors have achieved EXTCONF levels each year.
:::If the 10% estimate is true, then 500 accounts per year – about 10 per week – are being created by banned editors and going undetected long enough for the accounts to make 500 edits and to work in CTOP areas. Do we even have enough ] editors to make it plausible to expect banned editors to bring 500 accounts a year up to EXTCONF levels (plus however many accounts get started but are detected before then)? ] (]) 03:53, 23 November 2024 (UTC)
::::Suit yourself. I'm not interested in what interests other people or back of the envelope calculations. I'm interested in understanding the state of a system over time using evidence-based approaches by extracting data from the system itself. Let the data speak for itself. It has a lot to tell us. Then it is possible to test hypotheses and make evidence-based decisions. ] (]) 04:13, 23 November 2024 (UTC)
::::@], there's a sockmaster in the IPA CTOP who has made more than 100 socks. 500 new XC socks every year doesn't seem that much of a stretch in comparison. -- ] (]) 19:12, 23 November 2024 (UTC)
:::::More than 100 XC socks? Or more than 100 detected socks, including socks with zero edits?
:::::Making a lot of accounts isn't super unusual, but it's a lot of work to get 100 accounts up to 500+ edits. Making 50,000 edits is a lot, even if it's your full-time job. ] (]) 01:59, 24 November 2024 (UTC)
::::::Lots of users get it done in a couple of days, often through vandal fighting tools. It really is not that many when the edits are mostly mindless. ''']''' - 00:18, 26 November 2024 (UTC)
:::::::But that's kind of my point: "A couple of days", times 100 accounts, means 200–300 days per year. If you work five days per week and 52 weeks per year, that's 260 work days. This might be possible, but it's a full-time job.
:::::::Since the 30-day limit is something that can't be achieved through effort, I wonder if a sudden change to, say, 6 months would produce a five-month reprieve. ] (]) 02:23, 26 November 2024 (UTC)
::::::::Who says it’s only one at a time? Icewhiz for example has had 4 plus accounts active at a time. ''']''' - 02:25, 26 November 2024 (UTC)
::::::::: about ban evasion timelines for some sockmasters in PIA that show how accounts are operated in parallel. Operating multiple accounts concurrently seems to be the norm. ] (]) 04:31, 26 November 2024 (UTC)
::::::::::Imagine that it takes an average of one minute to make a (convincing) edit. That means that 500 edits = 8.33 hours, i.e., more than one full work day.
::::::::::Imagine, too, that having reached this point, you actually need to spend some time using your newly EXTCONF account. This, too, takes time.
::::::::::If you operate several accounts at once, that means:
::::::::::You spend an hour editing from Account1. You spend the next hour editing from Account2. You spend another hour editing from Account3. You spend your fourth hour editing from Account4. Then you take a break for lunch, and come back to edit from Accounts 5 through 8.
::::::::::At the end of the day, you have brought 8 accounts up to 60 edits (12% of the minimum goal). And maybe one of them got blocked, too, which is lost effort. At this rate, it would take you an entire year of full-time work to get 100 EXTCONF accounts, even though you are operating multiple accounts concurrently. Doing 50 edits per day in 10 accounts is not faster than doing 500 edits in 1 account. It's the same amount of work. ] (]) 05:13, 29 November 2024 (UTC)
:::::::::::Sure it’s an effort, though it doesn’t take a minute an edit. But I’m not sure why I need to imagine something that has happened multiple times already. Icewhiz most recently had like 4-5 EC accounts active, and there are probably several more. Yes, there is an effort there. But also yes, it keeps happening. ''']''' - 15:00, 29 November 2024 (UTC)
::::::::::::My point is that "4-5 EC accounts" is not "100". ] (]) 19:31, 30 November 2024 (UTC)
:::::::::::::It’s 4-5 at a time for a single sock master. Check the Icewhiz SPI for how many that adds up to over time. ''']''' - 20:16, 30 November 2024 (UTC)
::::::::Many of our frequent fliers are already adept at warehousing accounts for months or even years, so a bump in the time period probably won't make much off a difference. Additionally, and without going into detail publicly, there are several methods whereby semi- or even fully-automated editing can be used to get to 500 edits with a minimum of effort, or at least well within script-kid territory. Because so many of those are obvious on inspection some will assume that all of them are, but there are a number of rather subtle cases that have come up over the years and it would be foolish to assume that it isn't ongoing. ] (]) 17:31, 28 November 2024 (UTC)
Also, if we divide the space into contentious vs not-contentious, maybe a one size fits all CU policy doesn't make sense. ] (]) 18:55, 22 November 2024 (UTC)
Terrible idea. Let's AGF that most new users are here to improve Misplaced Pages instead of damage it. ] (]) 18:33, 22 November 2024 (UTC)
:Ban evading actors who employ deception via sockpuppetry in the ] topic area are here to improve Misplaced Pages, from their perspective, rather than damage it. There is no need to use faith. There are statistics. There is a probability that a 'new user' is employing ban evasion. ] (]) 18:46, 22 November 2024 (UTC)
::My initial comment wasn't a direct response to yours, but ] and IPs won't be able to edit in the WP:PIA topic area anyway since they need to be extended confirmed. ] (]) 20:08, 22 November 2024 (UTC)
:::Let's not hold up the way PIA handles new users and IPs, in which they are allowed to post to talk pages but then have their talk page post removed if it doesn't fall within very specific parameters, as some sort of model. ] (]) 02:51, 23 November 2024 (UTC)
Strongly support automatically checkusering all active users (new and existing) at regular intervals. If it were automated -- e.g., a script runs that compares IPs, user agent, other typical subscriber info -- there would be no privacy violation, because that information doesn't have to be disclosed to any human beings. Only the "hits" can be forwarded to the CU team for follow-up. I'd run that script daily. If the policy forbids it, we should change the policy to allow it. It's mind-boggling that Misplaced Pages doesn't do this already. It's a basic security precaution. (Also, email-required registration and get rid of IP editing.) ] (]) 02:39, 23 November 2024 (UTC)
*An automatic link to the Talk page, accessible from the Edit Summary area, would be an excellent idea. That creates a smooth continuum from Edit Summary area to Talk page. As I see it, there is too stark a break between the two areas. People ''either'' use the Talk page ''or'' they use the Edit Summary area, but far less frequently use ''both'' areas. ] 18:58, 22 December 2006 (UTC)
:I don't think you've been reading the comments from people who know what they are talking about. There would be hundreds, at least, of hits per day that would require human checking. The policy that prohibits this sort of massive breach of privacy is the Foundation's and so not one that en.wp could change even if it were a good idea (which it isn't). ] (]) 03:10, 23 November 2024 (UTC)
**Or perhaps a subpage of the talk page? In that case, it should also be decided if the page would be manually editable or not (the former being useful e.g. to fix typos, but dangerous). What I'd like most in this solution is that ] would fit like a glove to it :-) —]] 19:06, 22 December 2006 (UTC)
::A computer can be programmed to check for similarities or patterns in subscriber info (IP, etc), and in editing activity (time cards, etc), and content of edits and talk page posts (like the existing language similarity tool), with various degrees of certainty in the same way the Cluebot does with ORES when it's reverting vandalism. And the threshold can be set so it only forwards matches of a certain certainty to human CUs for review, so as not to overwhelm the humans. The WMF can make this happen with just $1 million of its $180 million per year (and it wouldn't be violating its own policies if it did so). Enwiki could ask for it, other projects might join too. ] (]) 05:24, 23 November 2024 (UTC)
:::"Oh now I see what you mean, Levivich, good point, I guess you know what you're talking about, after all."
:::"Thanks, Thryduulf!" ] (]) 17:42, 23 November 2024 (UTC)
::::I seem to have missed this comment, sorry. However I am ''very'' sceptical that sockpuppet detection is meaningfully automatable. From what CUs say it is as much art as science (which is why SPI cases can result in determinations like "possilikely"). This is the sort of thing that is difficult (at best) to automate. Additionally the only way to reliably develop such automation would be for humans analyse and process a massive amount of data from accounts that both are and are not sockpuppets and classify results as one or the other, and that anaylsis would be a massive privacy violation on its own. Assuming you have developed this magic computer that can assign a likelihood of any editor being a sock of someone who has edited in the last three months (data older than that is deleted) on a percentage scale, you then have to decide what level is appropriate to send to humans to check. Say for the sake of argument it is 75%, that means roughly one in four people being accused are innocent and are having their privacy impinged unnecessarily - and how many CUs are needed to deal with this caseload? Do we have enough? SPI isn't exactly backlog free and there aren't hoards of people volunteering for the role (although unbreaking RFA ''might'' help with this in the medium to long term). The more you reduce the number sent to CUs to investigate, the less benefit there is over the status quo.
::::In addition to all the above, how similar is "similar" in terms of articles edited, writing style, timecard, etc? How are you avoiding legitimate sockpuppets? ] (]) 18:44, 23 November 2024 (UTC)
:::::You know this already but for anyone reading this who doesn't: when a CU "checks" somebody, it's not like they send a signal out to that person's computer to go sniffing around. In fact, all the subscriber info (IP address, etc.) is already logged on the WMF's server logs (as with any website). A CU "check" just means a volunteer CU gets to look at a portion of those logs (to look up a particular account's subscriber info). That's the privacy concern: we have rules, rightfully so, about when volunteer CUs (not WMF staff) can read the server logs (or portions of them). Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs. Privacy is only an issue when those logs are revealed to volunteer CUs.
:::::So... feeding the logs into software in order to train the software doesn't violate anyone's policy. It's just letting a computer read its own files. Human verification of the training outcomes also doesn't have to violate anyone's privacy -- just don't use volunteer CUs to do it, use WMF staff. Or, anonymize the training data (changing usernames to "Example1", "Example2", etc.). Or use historical data -- which would certainly be part of the training, since the most effective way would be to put ''known'' socks into the training data to see if the computer catches them.
:::::Anyway, training the system won't violate anyone's privacy.
:::::As for the hit rate -- 75% would be way, way too low. We'd be looking for definitely over 90% or 95%, and probably more like 99.something percent. Cluebot doesn't get vandalism wrong 1 out of 4 times, neither should CluebotCU. Heck, if CluebotCU can't do better than 75%, it's not worth doing. A more interesting question is whether the 99.something% hit rate would be helpful to CUs, or whether that would only catch the socks that are so obvious you don't even need CU to recognize them. Only testing in the field would tell.
:::::But overall, AI looking for patterns, and checking subscriber info, edit patterns, and the content of edits, would be very helpful in tamping down on socking, because the computer can make far more checks than a human (a computer can look at 1,000 accounts and a 100,000 edits no problem, which no human can do), it'll be less biased than humans, and it can do it all without violating anyone's privacy -- in fact, lowering the privacy violations by lowering the false positives, sending only high-probability (90%+, not 75%+) to humans for review. And it can all be done with existing technology, and the WMF has the money to do it. ] (]) 19:38, 23 November 2024 (UTC)
::::::The more you write the clearer you make it that you don't understand checkuser or the WMF's policies regarding privacy. It's also clear that I'm not going to convince you that this is unworkable so I'll stop trying. ] (]) 20:42, 23 November 2024 (UTC)
:::::::Yeah it's weird how repeatedly insulting me hasn't convinced me yet. ] (]) 20:57, 23 November 2024 (UTC)
::::::::If you are are unable to distinguish between reasoned disagreement and insults, then it's not at all weird that reasoned disagreement fails to convince you. ] (]) 22:44, 23 November 2024 (UTC)
::::::{{ping|Levivich}} Whatever existing data set we have has too many biases to be useful for this, and this is going to be prone to false positives. AI needs ''lots'' of data to be meaningfully trained. Also, AI here would be learning a '']''; when the output is not in fact a function of the input, there's nothing for an AI model to target, and this is very much the case here. On ], where I am a CheckUser, almost all edit summaries are automated even for human edits (just like clicking the rollback button is, or undoing an edit is by default), and it is ''very'' hard to meaningfully tell whether someone is a sock or not without highly case-specific analysis. No AI model is better than the data it's trained on.
::::::Also, about the privacy policy: you are completely incorrect when you {{tq|"Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs"}}. Staff can only access that information on a ] basis, just like CheckUsers, and data privacy laws like the EU's and California's means you cannot just do whatever random thing you want with the information you collect from users about them.--] ] 21:56, 23 November 2024 (UTC)
:::::::So which part of the ] would prohibit the WMF from developing an AI that looks at server logs to find socks? Do you want me to quote to you the portions that explicitly disclose that the WMF uses personal information to develop tools and improve security? ] (]) 22:02, 23 November 2024 (UTC)
::::::::I mean yeah that would probably be more productive than snarky bickering ]] 22:05, 23 November 2024 (UTC)
::::::::{{ping|Levivich}} Did you read the part where I mentioned privacy ''laws''? Also, in this industry ''no one'' is allowed unfettered usage of private data even internally; there are ''internal'' policies that govern this that are broadly similar to the privacy policy. It's one thing to ''test'' a proposed tool on an IP address like ], but it's another to train an AI model on it. Arguably an equally big privacy concern is the usage of ''new'' data from new users after the model is trained and brought online. The foundation is already hiding IP addresses by default even for anonymous users soon, and they will not undermine that mission through a tool like this. Ultimately, the ] has to assume legal responsibility and liability for such a thing; put yourself in their position and think of whether they'd like the liability of something like this.--] ] 22:13, 23 November 2024 (UTC)
:::::::::So can you quote a part of the privacy policy, or a part of privacy laws, or anything, that would prohibit feeding server logs into a "Cluebot-CU" to find socking?
:::::::::Because I can quote the part of the ] that allows it, and it's a lot:
:::::::::{{tq2|We may use your public contributions, either aggregated with the public contributions of others or individually, '''to create new features or data-related products''' for you or to '''learn more about how the Wikimedia Sites are used''' ... <p>Because of how browsers work, we receive some information automatically when you visit the Wikimedia Sites ... This information includes the type of device you are using (possibly including unique device identification numbers, for some beta versions of our mobile applications), the type and version of your browser, your browser's language preference, the type and version of your device's operating system, in some cases the name of your internet service provider or mobile carrier, the website that referred you to the Wikimedia Sites, which pages you request and visit, and the date and time of each request you make to the Wikimedia Sites. <p>Put simply, we use this information to enhance your experience with Wikimedia Sites. For example, '''we use this information to administer the sites, provide greater security, and fight vandalism'''; optimize mobile applications, customize content and set language preferences, '''test features to see what works, and improve performance; understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites, and analyze trends'''. ... <p>We actively collect some types of information with a variety of commonly-used technologies. These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage. ... Depending on which technology we use, locally stored data may include text, Personal Information (like your IP address), and information about your use of the Wikimedia Sites (like your username or the time of your visit). ... '''We use this information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services.''' ... <p>We and our service providers use your information ... to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ... '''To fight spam, identity theft, malware and other kinds of abuse.''' ... '''To test features to see what works, understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites and analyze trends.''' ... <p>When you visit any Wikimedia Site, we automatically receive the IP address of the device (or your proxy server) you are using to access the Internet, which could be used to infer your geographical location. ... '''We use this location information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services'''. For example, we use this information '''to provide greater security''', optimize mobile applications, and '''learn how to expand and better support Wikimedia communities'''. ... <p>'''We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use''', this Privacy Policy, or any Wikimedia Foundation or user community-based policies. ... '''We may also disclose your Personal Information if we reasonably believe it necessary to detect, prevent, or otherwise assess and address potential spam, malware, fraud, abuse, unlawful activity, and security or technical concerns'''. ... '''To facilitate their work, we give some developers limited access to systems that contain your Personal Information, but only as reasonably necessary for them to develop and contribute to the Wikimedia Sites.''' ...}} Yeah that's a lot. Then there's that says {{tq2|It is important for us to be able to make sure everyone plays by the same rules, and sometimes that means we need to investigate and share specific users' information to ensure that they are. <p>For example, user information may be shared when a CheckUser is investigating abuse on a Project, such as suspected use of malicious '''"sockpuppets"''' (duplicate accounts), vandalism, harassment of other users, or disruptive behavior. If a user is found to be violating our Terms of Use or other relevant policy, the user's Personal Information may be released to a service provider, carrier, or other third-party entity, for example, to assist in the targeting of IP blocks or to launch a complaint to the relevant Internet Service Provider.}}
:::::::::So using IP addresses, etc., to develop new tools, to test features, to fight violations of the Terms of Use, and disclosing that info to Checkusers... all explicitly permitted by the Privacy Policy. ] (]) 22:22, 23 November 2024 (UTC)
::::::::::{{ping|Levivich}} {{Tq|"We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use"}} – "reasonably believed to be necessary" is not going to hold up in court when it's sweepingly applied to everyone. This doesn't even take into consideration the laws I mentioned, like ]. I'm not a lawyer, and I'm guessing neither are you. If you want to be the one assuming the legal liability for this, contact the board today and sign the contract. Even then they would probably not agree to such an arrangement. So you're ]: only the foundation could even consider assuming this risk. Also, it's clear that you do not have a single idea of how developing something like this works if you think it can be done for $1 million. Something this complex has to be done ''right'' and tech salaries and computing resources are expensive.--] ] 22:28, 23 November 2024 (UTC)
:::::::::::What I am suggesting does not involve sharing everyone's data with Checkusers. It's pretty obvious that looking at their own server logs is "necessary to enforce or investigate potential violations of our Terms of Use". Five people is how big the WMF's ] team is, @ $200k each, $1m/year covers it. Five people is enough for that team to improve ORES, so another five-person team dedicated to "ORES-CU" seems a reasonable place to start. They could double that, and still have like $180M left over. ] (]) 22:40, 23 November 2024 (UTC)
::::::::::::{{ping|Levivich}} Yeah no, lol. $200k each is not a very competitive total compensation, considering that that needs to include benefits, health insurance, etc. This doesn't include their manager or the hefty hardware required to run ML workflows. It doesn't include the legal support required given the data privacy law compliance needed. Capriciously looking at the logs does not count; accessing data of users the foundation cannot reasonably have said to be likely to cause abuse is not permissible. This all aside from the bias and other data quality issues at hand here. You can delude yourself all you want, but ]. I'm finished arguing with you anyways, because this proposal is either way dead on arrival.--] ] 23:45, 23 November 2024 (UTC)
:::::::::::::@], haggling over the math here isn't really important. You could quintuple the figures @] gave and the Foundation would still have millions upon millions of dollars left over. -- ] (]) 23:48, 23 November 2024 (UTC)
::::::::::::::{{ping|asilvering}} The point I'm making is Levivich does not understand the complexity behind this kind of thing and thus his arguments are not to be given weight by the closer. ] ] 23:56, 23 November 2024 (UTC)
:::::::::::::As a statistician/data scientist, @] is correct about the technical side of this—building an ML algorithm to detect sockpuppets would be pretty easy. Duplicate user algorithms like these are common across many websites. For a basic classification task like this (basically an ML 101 homework problem), I think $1 million is about right. As a bonus, the same tools could be used to identify and correct for possible canvasing or brigading, which behaves a lot like sockpuppetry from a statistical perspective. A similar algorithm is already used by Twitter's ] feature.
:::::::::::::IANAL, so I can't comment on the legal side of this, and I can't comment on whether that money would be better-spent elsewhere since I don't know what the WMF budget looks like. Overall though, the technical implementation wouldn't be a major hurdle. ] (]) 20:44, 24 November 2024 (UTC)
::::::::::::::Third-party services provide this kind of algorithm-based account fraud protection as an alternative to building and maintaining internally. <span style="background:#F3F3F3; color:inherit; padding:3px 9px 4px">]</span> 23:41, 24 November 2024 (UTC)
::::::::::::::Building such a model is only a small part of a real production system. If this system is to operate on all account creations, it needs to be at least as reliable as the existing systems that handle account creations. As you probably know, data scientists developing such a model need to be supported by software engineers and site reliability engineers supporting the actual system. Then you have the problem of ''new'' sockers who are not on the list of sockmasters to check against. Non-English-language speakers often would be put at a disadvantage too. It's not as trivial as you make it out to be, thus I stand by my estimate.--] ] 06:59, 25 November 2024 (UTC)
:::::::::::::::None of you have accounted for ].
:::::::::::::::I don't think we need to spend more time speculating about a system that WMF Legal is extremely unlikely to accept. Even if they did, it wouldn't exist until several years from now. Instead, let's try to think of things that we can do ourselves, or with only a very little assistance. Small, lightweight projects with full community control can help us now, and if we prove that ____ works, the WMF might be willing to adopt and expand it later. ] (]) 23:39, 25 November 2024 (UTC)
::::::::::::::::That's a mistake -- doing the same thing Misplaced Pages has been doing for 20+ years. The mistake is in leaving it to volunteers to catch sockpuppetry, rather than insisting that the WMF devote significant resources to it. And it's a mistake because the one thing we volunteers ''can't'' do, that the WMF ''can'' do, is comb through the server logs looking for patterns. ] (]) 23:44, 25 November 2024 (UTC)
:::::::::::::::::Not sure about the "building an ML algorithm to detect sockpuppets would be pretty easy" part, but I admire the optimism. It is certainly the case that it is possible, and people have done it with a surprising level of success a very long time ago in ML terms e.g. https://doi.org/10.1016/j.knosys.2018.03.002. These projects tend to rely on the category graph to distinguish sock and non-sock sets for training, the categorization of accounts as confirmed or suspected socks. However, the category graph is woefully incomplete i.e. there is information in the logs that is not reflected in the graph, so ensuring that all ban evasion accounts are properly categorized as such might help a bit. ] (]) 03:58, 26 November 2024 (UTC)
::::::::::::::::::Thankfully, we wouldn't have to build an ML algorithm, we can just use one of the existing ones. Some are even open source. Or WMF could use a third party service like the aforementioned sift.com. ] (]) 16:17, 26 November 2024 (UTC)
:::::::::::::::::::Let me guess: Essentially, you would like their machine-learning team to use Sift's {{tq|AI-Powered Fraud Protection}}, which from what I can glance, handles {{tq|safeguarding subscriptions to defending digital content and in-app purchases}} and {{tq|helps businesses reduce friction and stop sophisticated fraud attacks that gut growth}}, to provide the ability for us to {{tq|automatically checkuser all active users}}? <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 16:25, 26 November 2024 (UTC)
::::::::::::::::::::The WMF already has the ability to "automatically checkuser all users" (the verb "checkuser" just means "look at the server logs"), I'm suggesting they use it. And that they use it in a sophisticated way, employing (existing, open source or commercially available) AI/ML technologies, like the same kind we already use to automatically revert vandalism. Contrary to claims here, doing so would not be illegal or even expensive (comparatively, for the WMF). ] (]) 16:40, 26 November 2024 (UTC)
:::::::::::::::::::::So, in my attempt to get things set right and steer towards a consensus that is satisfactory, I sincerely follow-up: ] that in this vast, uncharted sea? And could this mean any more in the next 5 years? <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 16:49, 26 November 2024 (UTC)
::::::::::::::::::::::What lies beyond is ]. ] (]) 17:26, 26 November 2024 (UTC)
:::::::::::::::::::::::So, @], I think the answer to your question is "tell the WMF we really, really, really would like more attention to sockpuppetry and IP abuse from the ML team". -- ] (]) 17:31, 26 November 2024 (UTC)
::::::::::::::::::::::::Which I don't suppose someone can at the next board meeting on December 11? <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 18:00, 26 November 2024 (UTC)
:::::::::::::::::::I may also point to ], where they mention {{tq|development in other areas, such as social media features and '''machine learning expertise'''}}. <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 16:36, 26 November 2024 (UTC)
::::::::::::::::::::e.g. ] ] (]) 17:02, 26 November 2024 (UTC)
:::::::::::::::::::::And that mentions , still in beta it seems. <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 17:10, 26 November 2024 (UTC)
:::::::::::::::::::::'''3 days!''' When I first posted my comment and some editors responded that I didn't know what I was talking about, it can't be done, it'd violate the privacy policy and privacy laws, WMF Legal would never allow it... I was wondering how long it would take before somebody pointed out that this thing that can't be done has already been done and has been under development for ].
:::::::::::::::::::::''Of course'' it's already under development, it's pretty obvious that the same Misplaced Pages that developed ], one of the world's earlier and more successful examples of ML applications, would try to employ ML to fight multiple-account abuse. I mean, I'm obviously not gonna be the first person to think of this "innovation"!
:::::::::::::::::::::Anyway, it took 3 days. Thanks, Sean! ] (]) 17:31, 26 November 2024 (UTC)
:::::::::::::::::{{outdent|4}} Unlike what is being proposed, SimilarEditors only works based on publicly available data (e.g. similarities in editing patterns), and not IP data. To quote the page Sean linked, {{tq|in the model's current form, we are only considering public data, but most saliently private data such as IP addresses or user-agent information are features currently used by checkusers that could be later (carefully) incorporated into the models}}.{{pb}}So, not only the current model doesn't look at IP data, the research project also acknowledges that actually using such data should only be done in a "careful" way, because of those very same privacy policy issues quoted above.{{pb}}On the ML side, however, this does proves that it's being worked on, and I'm honestly not surprised at all that the WMF is working on machine learning-based tools to detect sockpuppets. ] (] · ]) 17:50, 26 November 2024 (UTC)
::::::::::::::::::Right. We should ask WMF to do the {{tqq|later (carefully) incorporated into the models}} part (especially since it's now later). BTW, the already pulls IP and other metadata. SimilarExtensions (a tool that uses the API) doesn't release that information to CheckUsers, by design. And that's a good thing, we can't just release all IPs to CheckUsers, it does indeed have to be done carefully. But user metadata ''can'' be used. What I'm suggesting is that the WMF ''should'' proceed to develop these types of tools (including the careful use of user metadata). ] (]) 17:57, 26 November 2024 (UTC)
:::::::::::::::::{{outdent|1}} Not really clear that they're pulling IP data from logged-in users. The relevant sections reads:{{pb}}{{tqb|<code>USER_METADATA</code> (203MB): for every user in <code>COEDIT_DATA</code>, this contains basic metadata about them (total number of edits in data, total number of pages edited, user or IP, timestamp range of edits).}}{{pb}}This reads like they're collecting the username ''or'' IP depending on whether they're a logged-in user or an IP user. ] (] · ]) 18:14, 26 November 2024 (UTC)
:::::::::::::::::In a few years people might look back on these days when we only had to deal with simple devious primates employing deception as the halcyon days. ] (]) 18:33, 26 November 2024 (UTC)
::::::::::::::::I assumed 1 million USD/year ''was'' accounting for Hofstadter's law several times over. Otherwise it feels wildly pessimistic. ] (]) 15:57, 26 November 2024 (UTC)
{{hat|IP range ] blocked by a CU}}
:::Why do you guys hate the WMF so much? If it weren’t for them, you wouldn’t have this website at all. ] (]) 23:51, 28 November 2024 (UTC)
::::We don’t. <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 01:13, 29 November 2024 (UTC)
:::::Then why do you guys always whine and complain about how incompetent they are and how much money they make and are actively against their donation drives? ] (]) 01:29, 29 November 2024 (UTC)
::::::We don't. ] (]) 02:47, 29 November 2024 (UTC)
:::::::Don’t “we don’t” me again. ] (]) 03:11, 29 November 2024 (UTC)
::::::This may be surprising, but it turns out there's more than one person on Misplaced Pages, and many of us have different opinions on things. You're probably thinking of @]'s essay.
::::::I disagree with his argument that the WMF is incompetent, but at the same time, ]. Just because the WMF spent their first $20 million ''extremely'' well (on creating Misplaced Pages) doesn't mean giving them $200 million would make them 10× as good. Nobody here thinks the WMF budget should be cut to $0; there's just some of us who think it needs a haircut.
::::::For me it comes down to, "if you don't donate to the WMF, ]"? I'd rather you give that money to ]—feeding African children is more important than reskinning Misplaced Pages—but if you won't, I'd doubt giving it to the WMF is worse than whatever else you were going to spend it on. Whether we should cut back on ads depends on whether this money is coming out of donors' charity budgets or their regular budgets. ] (]) 03:10, 29 November 2024 (UTC)
:::::::I already struggle enough with prioritizing charities and whether which ones are ethical or not and how I should be spending every single penny I get on charities dealing with PIA and trans issues because those are the most oppressed groups in the world right now. The WMF is not helping people who are actively getting killed and having their rights taken away therefore they are not important. ] (]) 03:15, 29 November 2024 (UTC)
::::::::In that case, I'd suggest checking out ], which has some very good recommendations. That said, this subthread feels wildly off-topic. ] (]) 03:33, 29 November 2024 (UTC)
:::::::::So goes this whole discussion; but to give a slightly longer answer to the IP: We’re not telling them to ], we’re trying (despite everything) to establish relations, consensus and mutual trust. And hopefully long-term progress on key areas of contention. We ''don’t'' hate them, or else they’ll dismiss us completely. <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 03:44, 29 November 2024 (UTC)
{{hab}}
:Any such system would be subject to numerous biases or be easily defeatable. Such an automated anti-abuse system would have to be exclusively a foundation initiative as only they have the resources for such a monumental undertaking. It would need its own team of developers.--] ] 18:57, 23 November 2024 (UTC)
Absolutely no chance that this would pass. ], even though there isn't a flood of opposes. There are two problems:
#The existing CheckUser team barely has the bandwidth for the existing SPI load. Doing this on every single new user would be impractical and would enable ]'s by diverting valuable CheckUser bandwidth.
#Even if we had enough CheckUser's, this would be a severe privacy violation absolutely prohibited under the Foundation privacy policy.
The ''vast majority'' of vandals and other disruptive users don't need CU involvement to deal with. There's very little to be gained from this.--] ] 18:36, 23 November 2024 (UTC)
:It is perhaps an interesting conversation to have but I have to agree that it is unworkable, and directly contrary to foundation-level policy which we cannot make a local exemption to. En.wp, I believe, already has the largest CU team of any WMF project, but we would need ''hundreds'' more people on that team to handle something like this. In the last round of appointments, the committee approved exactly '''one''' checkuser, and that one was a returning former mamber of the team. And there is the very real risk that if we appointed a whole bunch of new CUs, some of them would abuse the tool. ] ] 18:55, 23 November 2024 (UTC)
::And its worth pointing out that the Committee approving too few volunteers for Checkuser (regardless of whether you think they are or aren't) is not a significant part of this issue. There simply are not tens of people who are putting themselves forward for consideration as CUs. Since 2016 54 applications (an average of per year) have been put forward for consideration by Functionaries (the highest was 9, the lowest was 2). Note this is total applications not applicants (more than one person has applied multiple times), and is not limited to candidates who had a realistic chance of being appointed. ] (]) 20:40, 23 November 2024 (UTC)
:::The dearth of candidates has for sure been an ongoing thing, it's worth reminding admins that they don't have to wait for the committee to call for candidates, you can put your name forward at any time by emailing the committee. ] ] 23:48, 24 November 2024 (UTC)
:Generally, I tend to get the impression from those who have checkuser rights that CU should be done as a last resort, and other, less invasive methods are preferred, and it would seem that indiscriminate use of it would be a bad idea, so I would have some major misgivings about this proposal. And given the ANI case, the less user information that we retain, the better (which is also probably why temporary accounts are a necessary and prudent idea despite other potential drawbacks). ] (]) 03:56, 23 November 2024 (UTC)
:Oppose. A lot has already been written on the unsustainable workload for the CU team this would create and the amount of collateral damage; I'll add in the fact that our most notorious sockmasters in areas like PIA already use highly sophisticated methods to evade CU detection, and based on what I've seen at the relevant SPIs most of the blocks in these cases are made with more weight given to the behaviour, and even then only after lengthy deliberations on the matter. These sort of sockmasters seem to have been in the OP's mind when the request was made, and I do not see automated CU being of any more use than current techniques against such dedicated sockmasters. And, has been mentioned before, most cases of sockpuppetry (such as run-of-the-mill vandals and trolls using throwaway accounts for abuse) don't need CU anyways. '']]'' 08:17, 24 November 2024 (UTC)
::These are, unfortunately, fair points about the limits of CU and the many experienced and dedicated ban evading actors in PIA. CU information retention policy is also a complicating factor. ] (]) 08:28, 24 November 2024 (UTC)
:::As I said in my original post, recidivist socks often get better at covering their "tells" each time making behavioural detection increasingly difficult and meaning the entire burden falls on the honest user to convince an Admin to take an SPI case seriously with scarce evidence. After many years I'm tired of defending various pages from sock POV edits and if WMF won't make life easier then increasingly I just won't bother, I'm sure plenty of other users feel the same way. ] (]) 05:45, 26 November 2024 (UTC)
=== SimilarEditors ===
*Perhaps implementation of these things could proceed in stages. As a first step I would see simply increasing the capacity of the Edit Summary space. I would also like to see some wording in place encouraging editors to use the Edit Summary space. The wording should encourage people to explain what changes they have made, and why they have made them. I really think the Edit Summary area should be about 3 times it's present maximum capacity. I think the importance of this is that it would allow editors to explain to previous editors why they are massacring their work. The more important use for the Edit Summary box is an explanation of what changes were made. But it is normal human tendency to get wordy wherever they are given the opportunity. This would allow the Edit Summary area to also be used for a much trimmed down version of the Talk Page. I think, as a first step, this would be an experiment. The more ambitious changes would have to await evaluation of this step. ] 17:01, 23 December 2006 (UTC)
The development of ] -- the type of tool that could be used to do what Mztourist suggests -- has been "stalled" since 2023 and downgraded to low-priority in 2024, according to its documentation page and related phab tasks (see e.g. ], ], ]). Anybody know why? ] (]) 17:43, 26 November 2024 (UTC)
:Honestly, the main function of that sort of thing seems to be compiling data that is already available on XTools and various editor interaction analyzers, and then presenting it nicely and neatly. I think that such a page could be useful as a sanity check, and it might even be worth having that sort of thing as a standalone toolforge app, but I don't really see why the WMF would make that particular extension a high priority. — ] <sub>]</sub> 17:58, 26 November 2024 (UTC)
== Stalin Birthday ==
::Well, it doesn't have to be ''that particular extension'', but it seems to me that the entire "idea" has been stalled, unless they're working on another tool that I'm unaware of (very possible). (Or, it could be because of recent changes in domestic and int'l privacy laws that derailed their previous development advances, or it could be because of advancements in ML elsewhere making in-house development no longer practical.) <p>As to why the WMF would make this sort of problem a high priority, I'd say because the spread of misinformation on Misplaced Pages by sockpuppets is a big problem. Even without getting into the use of user metadata, just look at recent SPIs I filed, like ] and ]. That involved no private data at all, but a computer could have done automatically, in seconds, what took me hours to do manually, and those socks could have been uncovered ''before'' they made thousands and thousands of edits spreading misinformation. If the computer looked at private data as well as public data, it would be even more effective (and would save CUs time as well). Seems to me to be a worthy expenditure of 0.5% or 1% of the WMF's annual budget. ] (]) 18:09, 26 November 2024 (UTC)
:This looks really interesting. I don't really know how extensions are rolled out to individual wikis - can anyone with knowledge about that summarise if having this tool turned on (for check users/relevant admins) for en.wp is feasible? Do we need a RFC, or is this a "maybe wait several years for a phab ticket" situation? ]] 18:09, 26 November 2024 (UTC)
:I find it amusing that ~4 separate users above are arguing that automatic identification of sockpuppets is impossible, impractical, and the WMF would never do it—and meanwhile, the WMF is already doing it. ] (]) 19:29, 27 November 2024 (UTC)
::So, discussion is over? <span style="color:#7E790E;">2601AC47</span> (]<big>·</big>]<big>·</big>]) <span style="font-size:80%">Isn't a IP anon</span> 19:31, 27 November 2024 (UTC)
::I think what's happening is that people are having two simultaneous discussions – automatic identification of sockpuppets is already being done, but what people say "the WMF would never do" is using private data (e.g. IP addresses) to identify them. Which adds another level of (ethical, if not legal) complications compared to what SimilarEditors is doing (only processing data everyone can access, but in an automated way). ] (] · ]) 07:59, 28 November 2024 (UTC)
:::"automatic identification of sockpuppets is already being done" is probably an overstatement, but I agree that there may be a potential legal and ethical minefield between the Similarusers service that uses public information available to anyone from the databases after redaction of private information (i.e. course-grained sampling of revision timestamps combined with an attempt to quantify page intersection data), and a service that has access to the private information associated with a registered account name. ] (]) 11:15, 28 November 2024 (UTC)
:::The WMF said they're planning on incorporating IP addresses and device info as well! ] (]) 21:21, 29 November 2024 (UTC)
::Yes, automatic identification of (these) sockpuppets is impossible. There are many reasons for this, but the simplest one is this: These types of tools require hundreds of edits – at minimum – to return any viable data, and the sort of sockmasters who get accounts up to that volume of edits know how to evade detection by tools that analyse public information. The markers would likely indicate people from similar countries – naturally, two Cypriots would be interested in ] and over time similar hour and day overlaps will emerge, but what's to let you know whether these are actual socks when they're evading technical analysis? You're back to square one. There are other tools such as ] which I consider equally circumstantial; an analysis of myself returns a high likelihood of me being other administrators and arbitrators, while analysing an alleged sock currently at SPI returns the filer as the third most likely sockmaster. This is not commentary on the tools themselves, but rather simply the way things are. ]<sup>]</sup><sub>]</sub> 17:42, 28 November 2024 (UTC)
:::Oh, fun! Too bad it's CU-restricted, I'm quite curious to know what user I'm most stylometrically similar to. -- ] (]) 17:51, 28 November 2024 (UTC)
::::That would be {{noping|LittlePuppers}} and {{noping|LEvalyn}}. ]<sup>]</sup><sub>]</sub> 03:02, 29 November 2024 (UTC)
:::::Fascinating! One I've worked with, one I haven't, both AfC reviewers. Not bad. -- ] (]) 06:14, 29 November 2024 (UTC)
:::Idk, the half dozen ARBPIA socks I recently reported at SPI were obvious af to me, as are several others I haven't reported yet. That may be because that particular sockfarm is easy to spot by its POV pushing and a few other habits; though I bet in other topic areas it's the same. ] helps because it forces the socks to make 500 edits minimum before they can start POV pushing, but still we have to let them edit for a while post-XC just to generate enough diffs to support an SPI filing. Software that combines tools like Masz and SimilarEditor, and does other kinds of similar analysis, could significantly reduce the amount of editor time required to identify and report them. ] (]) 18:02, 28 November 2024 (UTC)
:::I think it is possible, studies have demonstrated that it is possible, but it is true that having a sufficient number of samples is critical. Samples can be aggregated in some cases. There are several other important factors too. I have tried some techniques, and sometimes they work, or let's say they can sometimes produce results consistent with SPI results, better than random, but with plenty of false positives. It is also true that there are a number of detection countermeasures (that I won't describe) that are already employed by some bad actors that make detection harder. But I think the objective should be modest, to just move a bit in the right direction by detecting more ban evading accounts than are currently detected, or at least to find ways to reduce the size of the search space by providing ban evasion candidates. Taking the human out of the detection loop might take a while. ] (]) 18:39, 28 November 2024 (UTC)
:::If you mean it's never going to be possible to catch ''some'' sockpuppets—the best-hidden, cleverest, etc. ones—you're completely correct. But I'm guessing we could cut the amount of time SPI has to spend dramatically with just some basic checks. ] (]) 02:27, 29 November 2024 (UTC)
::::I disagree. Empirically, the vast majority of time spent at SPI is not on finding possible socks, nor is it using the CheckUser tool on them, but rather it's the CU completed cases (of which there are currently 14 and I should probably stop slacking and get onto some) with non-definitive technical results waiting on an administrator to make the final determination on whether they're socks or not. Extension:SimilarUsers would concentrate various information that already exists (], RoySmith's ) in one place, but I wouldn't say the accessibility of these tools is a cause of SPI backlog. An AI analysis tool to give an accurate magic number for likelihood? I'm anything but a Luddite, but still believe that's wishful thinking. ]<sup>]</sup><sub>]</sub> 03:02, 29 November 2024 (UTC)
:::::Something seems better than nothing in this context doesn't it? EIA and the Similarusers service don't provide an estimate of the significance of page intersections. An intersection on a page with few revisions or few unique actors or few pageviews etc. is very different from a page intersection on the Donald Trump page. That kind of information is probably something that could sometimes help, even just to evaluate the importance of intersection evidence presented at SPIs. It seems to me that any kind of assistance could help. And another thing about the number of edits is that too many samples can also present challenges related to noise, with signals getting smeared out, although the type of noise in a user's data can itself be a characteristic signal in some cases it seems. And if there are too few samples, you can generate synthetic samples based on the actual samples and inject them into spaces. Search strategy matters a lot. The space of everyone vs everyone is vast, so good luck finding potential matches in that space without a lot of compute, especially for diffs. But many socks inhabit relatively small subspaces of Misplaced Pages, at least in the they edit(war)/POV-push etc. in their topic of interest. So, choosing the candidate search space and search strategy wisely can make the problem much more tractable for a given topic area/subspace. Targeted fishing by picking a potential sock and looking for potential matches (the strategy used by the Similarusers service and CU I guess) is obviously a very different challenge than large-scale industrial fishing for socks in general. ] (]) 04:08, 29 November 2024 (UTC)
:::::And to continue the whining about existing tools, EIA and the Similarusers service use a suboptimal strategy in my view. If the objective is page intersection information for a potential sock against a sockmaster, and a ban evasion source has employed n identified actors so far e.g. almost 50 accounts for Icewhiz, the source's revision data should be aggregated for the intersection. This is not difficult to do using the category graph and the logs. ] (]) 04:25, 29 November 2024 (UTC)
::::::There is so much more that could be done with the software. EIA gives you page overlaps (and isn't 100% accurate at it), but it doesn't tell you:
::::::*how many times the accounts made the same edits (tag team edit warring)
::::::*how many times they voted in the same formal discussions (RfC, AfD, RM, etc) and whether they voted the same way or different (vote stacking)
::::::*how many times they use the same language and whether they use unique phraseology
::::::*whether they edit at the same times of day
::::::*whether they edit on the same days
::::::*whether account creation dates (or start-of-regular-editing dates) line up with when other socks were blocked
::::::*whether they changed focus after reaching XC and to what extent (useful in any ARBECR area)
::::::*whether they "gamed" or "rushed" to XC (same)
::::::All of this (and more) would be useful to see in a combined way, like a dashboard. It might make sense to restrict access to such compilations of data to CUs, and the software could also throw in metadata or subscriber info in there, too (or not), and it doesn't have to reduce it all into a single score like ORES, but just having this info compiled in one place would save editors the time of having to compile it manually. If the software auto-swept logs for this info and alerted humans to any "high scores" (however defined, eg "matches across multiple criteria"), it would probably not only reduce editor time but also increase sock discovery. ] (]) 04:53, 29 November 2024 (UTC)
:::::::This is like one of my favorite strategies for meetings. Propose multiple things, many of which are technically challenging, then just walk out of the meeting.
:::::::The 'how many times the accounts made the same edits' is probably do-able because you can connect reverted revisions to the revisions that reverted them using json data in the database populated as part of the tagging system, look at the target state reverted to and whether the revision was an exact revert. ...or maybe not without computing diffs, having just looked at an article with a history of edit warring. ] (]) 07:43, 29 November 2024 (UTC)
:::::::I agree with Levivich that automated, privacy-protecting sock-detection is not a pipe dream. I proposed a system something like this in ], see also ], and more recently ]. However, it definitely requires a bit of software development and testing. It also requires the community and the foundation devs or product folks to prioritize the idea. ''']'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">]</span> 02:27, 10 December 2024 (UTC)
*'''Comment'''. For some time I have vehemnently suspected that this site is crawling with massive numbers of sockpuppets, that the community seems to be unable or unwilling to recognise probable sockpuppets for what they are, and it is not feasible to send them to SPI one at a time. I see a large number of accounts that are sleepers, or that have low edit counts, trying to do things that are controversial or otherwise suspicious. I see them showing up at discussions in large numbers and in quick succession, and offering !votes consist of interpretations of our policies and guidelines that may not reflect consensus, or other statements that may not be factually accurate.
:I think the solution is simple: when closing community discussions, admins should look at the edit count of each !voter when determining how much weight to give his !vote. The lower the edit count, the greater the level of sleeper behaviour, and the more controversial the subject of the discussion is amongst the community, the less weight should be given to !vote.
:For example, if an account with less than one thousand edits !votes in a discussion about 16th century Tibetan manuscripts, we may well be able to trust that !vote, because the community does not care about such manuscripts. But if the same account !votes on anything connected with "databases" or "lugstubs", we should probably give that !vote very little weight, because that was the subject of a massive dispute amongst the community, and any discussion on that subject is not particulary unlikely to be crawling with socks on both sides. The feeling is that, if you want to be taken seriously in such a controversial discussion, you need to make enough edits to prove that you are a real person, and not a sock. ] (]) 15:22, 12 December 2024 (UTC)
::The site presumably has a large number of unidentified sockpuppets. As for the identified ban evading accounts, accounts categorized or logged as socks, if you look at 2 million randomly selected articles for the 2023-10-07 to 2024-10-06 year, just under 2% of the revisions are by ban evading actors blocked for sockpuppetry (211,546 revisions out of 10,732,361). A problem with making weight dependent on edit count is that the edit count number does not tell you anything about the probability that an account is a sock. Some people use hundreds of disposable accounts, making just a few edits with each account. Others stick around and make thousands of edits before they are detected. Also, Misplaced Pages provides plenty of tools that people can use to rapidly increase their edit count. ] (]) 16:12, 12 December 2024 (UTC)
*I strongly oppose any idea of mass-CUing any group of users, and I'm pretty sure the WMF does too. This isn't the right way to fight sockpuppets. ] (]) 14:35, 15 December 2024 (UTC)
It is mentioned under your research that he was born on December 18th when all other research states he was born December 21st. What is the correct dob? yiannimelas(at)gmail(dot)com thanks, yianni
::Can I ask why? Is it a privacy-based concern? IPs are automatically collected and stored for 90 days, and maybe for years in the backups, regardless of CUs. That's a 90 day window that a machine could use to do something with them without anyone running a CU and without anyone having to see what the machine sees. ] (]) 15:05, 15 December 2024 (UTC)
:::Primarily privacy concerns, as well as concerns about false positives. A lot of people here probably share an IP with other editors without even knowing it. I also would like to maintain my personal privacy, and I know many other editors would too. There are other methods of fighting sockpuppets that don't have as much collateral damage, and we should pursue those instead. ] (]) 15:16, 17 December 2024 (UTC)
:::Also, it wouldn't even work on some sockpuppets, because IP info is only retained for 90 days, so a blocked editor could just wait out the 90 days and then return with a new account. ] (]) 15:19, 17 December 2024 (UTC)
:@]—one situation where I think we could pull a ''lot'' of data, and probably detect tons of sockpuppets, is !votes like RfAs and RfCs. Those have a ''lot'' of data, in addition to a very strong incentive for socking—you'd expect to see a bimodal distribution where most accounts have moderately-correlated views, but a handful have extremely strong-correlations (always !voting the same way), more than could plausibly happen by chance or by overlapping views. For accounts in the latter group, we'd have strong grounds to suspect collusion/canvassing or socking.
:RfAs are already in a very nice machine-readable format. RfCs aren't, but most could easily be made machine-readable (by adopting a few standardized templates). We could also build a tool for semi-automated recoding of old RfCs to get more data. ] (]) 18:56, 16 December 2024 (UTC)
::Would that data help with the general problem? If there are a lot of socks on an RfA, I'd expect that to be picked up by editors. Those are very well-attended. The same may apply to many RfCs. Perhaps the less well-attended ones might be affected, but the main challenge is article edits, which will not be similarly structured. ] (]) 19:13, 16 December 2024 (UTC)
:::{{tqb|Would that data help with the general problem? If there are a lot of socks on an RfA, I'd expect that to be picked up by editors.}}
:::Given we've had situations of , I'm not too sure of this myself. If someone ''did'' create a bunch of socks, as some people have alleged in this thread, it'd be weird of them not to use those socks to influence policy decisions. I'm pretty skeptical, but I do think investigating would be a good idea (if nothing else because of how important it is—even the ''possibility'' of substantial RfA/RfC manipulation is quite bad, because it undermines the whole idea of consensus). ] (]) 21:04, 16 December 2024 (UTC)
::::RFAs, RfCs, RMs, AfDs, and arbcom elections. ] (]) 23:11, 17 December 2024 (UTC)
===What do we do with this information?===
:Stalin — Date of Birth: 21 December 1879. According to http://encyclopedia.worldvillage.com/s/b/Stalin ] 10:36, 22 December 2006 (UTC)
I think we've put the cart before the horse here a bit. While we've established it's possible to detect most sockpuppets automatically—and the WMF is already working on it—it's not clear what this would actually achieve, because having multiple accounts isn't against the rules. I think we'd need to establish a set of easy-to-enforce boundaries for people using multiple accounts. My proposal is to keep it simple—two accounts controlled by the same person can't edit the same page (or participate in the same discussion) without disclosing they're the same editor.] (]) 04:41, 14 December 2024 (UTC)
::I believe ] explains it all. His official documents in the Imperial Russia were on 18 December 1878 but he himself installed 21 December 1879 as the official date. The reasons why he did it are unclear: desire to have a 50-year old celebration as a national holiday, questions of paternity, who knows? ] 10:51, 22 December 2006 (UTC)
:This is already covered by ] I think. ''']'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">]</span> 05:03, 14 December 2024 (UTC)
== Dead-Link Cleanup Day ==
::And as there are multiple legitimate ways to disclose, not all of which are machine readable, any automatically generated list is going to need human review. ] (]) 10:13, 14 December 2024 (UTC)
Is it possible to set aside a day or week where members of the community go through every article and check for deador spam links? A comment could be posted on the talk page after each page is done. Something has to be done to deal with all these dead links and i was wondering if anyone else thinks this is a good idea. ] 13:30, 22 December 2006 (UTC)
:::Yes, that's definitely the case, an automatic sock detection should probably never be an autoblock, or at least not unless there is a good reason in that specific circumstance, like a well-trained filter for a specific LTA. Having the output of automatic sock detection should still be restricted to CU/OS or another limited user group who can be trusted to treat possible user-privacy-related issues with discretion, and have gone through the appropriate legal rigmarole. There could also be some false positives or unusual situations when piloting a program like this. For example, I've seen dynamic IPs get assigned to someone else after a while, which is unlikely but not impossible depending on how an ISP implements DHCP, though I guess collisions become less common with IPV6. Or if the fingerprinting is implemented with a lot of datapoints to reduce the likelihood of false positives. ''']'''<span style="border:2px solid #073642;background:rgb(255,156,0);background:linear-gradient(90deg, rgba(255,156,0,1) 0%, rgba(147,0,255,1) 45%, rgba(4,123,134,1) 87%);">]</span> 10:31, 14 December 2024 (UTC)
:It might be possible to set up a permenant ] to work on this, similar to ]. ] 14:02, 22 December 2006 (UTC)
::::I think we are probably years away from being able to rely on autonomous agents to detect and block socks without a human in the loop. For now, people need as much help as they can get to identify ban evasion candidates. ] (]) 10:51, 14 December 2024 (UTC)
::::{{tqb|or at least not unless there is a good reason in that specific circumstance,}}
::::Yep, basically I'm saying we need to define "good reason". The obvious situation is automatically blocking socks of blocked accounts. I also think we should just automatically prevent detected socks from editing the same page (ideally make it impossible, to keep it from being done accidentally). ] (]) 17:29, 14 December 2024 (UTC)
== Requiring registration for editing ==
== Fair use of promotional photographs ==
:''{{small|{{a note}} This section was split off from ] and the "parenthetical comment" referred to below is: {{tqq|(Also, email-required registration and get rid of IP editing.)}}—03:49, 26 November 2024 (UTC)}}''
@], about your parenthetical comment on requiring registration:
{{pb}}Part of the eternally unsolvable problem is that new editors are frankly bad at it. I can give examples from my own editing: Create an article citing a personal blog post as the main source? Check. Merge two articles that were actually different subjects? Been there, done that, got the revert. Misunderstand and mangle wikitext? More times than I can count. And that's after I created my account. Like about half of experienced editors, I edited as an IP first, fixing a typo here or reverting some vandalism there.
{{pb}}But if we don't persist through these early problems, we don't get experienced editors. And if we don't get experienced editors, Misplaced Pages will die.
{{pb}}Requiring registration ("get rid of IP editing") shrinks the number of people who edit. The Portuguese Misplaced Pages banned IPs only from the mainspace three years ago. . After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. The number of contributions has dropped, too. They went from 160K to 210K edits per month down to 140K most months.
{{pb}}Some of the experienced editors have said that they like this. No IPs means less impulsive vandalism, and the talk pages are stable if you want to talk to the editor. Fewer newbies means I don't "have to" clean up after so many mistake-makers! Fewer editors, and especially fewer inexperienced editors, is more convenient – in the short term. But I wonder whether they're going to feel the same way a decade from now, when their community keeps shrinking, and they start wondering when they will lose critical mass.
{{pb}}The same thing happens in the real world, by the way. Businesses want to hire someone with experience. They don't want to train the helpless newbie. And then after years of everybody deciding that training entry-level workers is ], they all look around and say: Where are all the workers that I need? Why didn't someone else train the next generation while I was busy taking the easy path?
{{pb}}In case you're curious, there is a Misplaced Pages that puts all of the IP and newbie edits under "PC" type restrictions. Nobody can see the edits until they've been approved by an experienced editor. The rate of vandalism visible to ordinary readers is low. Experienced editors love the level of control they have. Have a look at during the last decade. Is that what you want to see here? If so, we know how to make that happen. The path to that destination even looks broad, easy, and paved with all kinds of good intentions. ] (]) 04:32, 23 November 2024 (UTC)
:Size isn't everything... what happened to their output--the quality of their encyclopedias--after they made those changes? ] (]) 05:24, 23 November 2024 (UTC)
::Well, I can tell you objectively that the number of edits declined, but "quality" is in the eye of the beholder. I understand that the latter community has the lowest use of inline citations of any mid-size or larger Misplaced Pages. What's now yesterday's TFA there wouldn't even be rated B-class here due to whole sections not having any ref tags. In terms of citation density, their FA standard is currently where ours was >15 years ago.
::But I think you have missed the point. Even if the quality has gone up according to the measure of your choice, if the number of contributors is steadily trending in the direction of zero, what will the quality be when something close to zero is reached? That community has almost halved in the last decade. How many articles are out of date, or missing, because there simply aren't enough people to write them? A decade from now, with half as many editors again, how much worse will the articles be? We're none of us idiots here. We can see the trend. We know that people die. You have doubtless seen this famous line:
::<blockquote>All men are mortal. Socrates is a man. Therefore, Socrates is mortal.</blockquote>
::I say:
::<blockquote>All Misplaced Pages editors are mortal. Dead editors do not maintain or improve Misplaced Pages articles. Therefore, maintaining and improving Misplaced Pages requires editors who are not dead.</blockquote>
::– and, ], we are going to die, my friend. ]. If we want Misplaced Pages to outlive us, we cannot be so shortsighted as to care only about the quality today, and never the quality the day after we die. ] (]) 06:13, 23 November 2024 (UTC)
:::Trends don't last forever. Enwiki's active user count decreased from its peak over a few years, then flattened out for over a decade. The quality increased over that period of time (by any measure). Just because these other projects have shed users doesn't mean they're doomed to have zero users at some point in the future. And I think there's too many variables to know how much any particular change made on a project affects its overall user count, nevermind the quality of its output. ] (]) 06:28, 23 November 2024 (UTC)
:::] If the graph to the right accurately reflects the age distribution of Misplaced Pages users, then a large chunk of the user base will die off within the next decade or two. Not to be dramatic, but I agree that requiring registration to edit, which will discourage readers from editing in the first place, will hasten the project's decline.... ] (]) 14:40, 23 November 2024 (UTC)
::::😂 Seriously? What do you suppose that chart looked like 20 years ago, and then what happened? ] (]) 14:45, 23 November 2024 (UTC)
:::::There are significantly more barriers to entry than there were 20 years ago, and over that time the age profile has increased (quite significantly iirc). Adding more barriers to entry is not the way to solve the issued caused by barriers to entry. ] (]) 15:50, 23 November 2024 (UTC)
::::::{{clear}}"" - maybe the demographics of the community will change. ] (]) 16:30, 23 November 2024 (UTC)
:::::::That talks about LLMs usage in artcles, not the users. <span style="color:#7E790E;">2601AC47</span> (]|]) <span style="font-size:80%"><span style="color:grey;">Isn't a IP anon</span></span> 16:34, 23 November 2024 (UTC)
::::::::Or you could say it's about a user called PaperQA2 that writes Misplaced Pages articles significantly more accurate than articles written by other users. ] (]) 16:55, 23 November 2024 (UTC)
:::::::::No, it is very clearly about a language model. As far as I know, PaperQA2, or WikiCrow (the generative model using PaperQA2 for question answering), has not actually been making any edits on Misplaced Pages itself. ] (] · ]) 16:58, 23 November 2024 (UTC)
::::::::::That is true. It is not making any edits on Misplaced Pages itself. There is a barrier. But my point is that in the future that barrier may not be there. There may be users like PaperQA2 writing articles better than other users and the demographics will have changed to include new kinds of users, much younger than us. ] (]) 17:33, 23 November 2024 (UTC)
:::::::::::And who will never die off! ] (]) 17:39, 23 November 2024 (UTC)
::::::::::::But which will not be ''Misplaced Pages''. ] (]) 06:03, 24 November 2024 (UTC)
:::::In re "What do you suppose that chart looked like 20 years ago": I believe that the numbers, very roughly, are that the community has gotten about 10 years older, on average, than it was 20 years ago. That is, we are bringing in some younger people, but not at a rate that would allow us to maintain the original age distribution. (Whether the original age distribution was a good thing is a separate consideration.) ] (]) 06:06, 24 November 2024 (UTC)
::::I like looking at the graph hosted on Toolforge (for anyone who might go looking for it later, there's a link to it at {{section link|Misplaced Pages:WikiProject Editor Retention|Resources}}). It shows histograms of how many editors have edited in each month, grouped by all the editors who started editing in the same month. The data is noisy, but it does seem to show an increase in editing tenure since 2020 (when the pursuit of a lot of solo hobbies picked up, of course). Prior to that, there does seem to be a bit of slow growth in tenure length since the lowest point around 2013. ] (]) 17:18, 23 November 2024 (UTC)
::::The trend is a bit clearer when looking at the . (To see the trend when looking at the , the default colour range needs to be shifted to accommodate the smaller numbers.) ] (]) 17:25, 23 November 2024 (UTC)
:::::I'd say that the story there is: Something amazing happened in 2006. Ours (since both of us registered our accounts that year) was the year from which people stuck around. I think that would be just about the time that the wall o' automated rejection really got going. There was some UPE-type commercial pressure, but it didn't feel unmanageable. It looks like an inflection point in retention. ] (]) 06:12, 24 November 2024 (UTC)
::::::I don't think something particularly amazing happened in 2006. I think the ] starting in 2004 attracted a large land rush of editors as Misplaced Pages became established as a top search result. The cohort of editors at that time had the opportunity to cover a lot of topics for the first time on Misplaced Pages, requiring a lot of co-ordination, which created bonds between editors. As topic coverage grew, there were fewer articles that could be more readily created by generalists, the land rush subsided, and there was less motivation for new editors to persist in editing. Boom-bust cycles are common for a lot of popular things, particularly in tech where newer, shinier things launch all the time. ] (]) 19:07, 24 November 2024 (UTC)
:::::::Ah yes, that glorious time when we gained an article on every Pokemon character and, it seems, every actor who was ever credited in a porn movie. Unfortunately, many of the editors I bonded with then are no longer active. Some are dead, some finished school, some presumably burned out, at least one went into the ministry. ] 23:49, 26 November 2024 (UTC)
:{{tq|Have a look at what happened to the size of their community.}}—I'm gonna be honest: eyeballing it, I don't actually see much (if any) difference with enwiki's activity. only convinces people when the dataset passes the interocular trauma test (e.g. ]).
:On the other hand, if there's a dataset of "when did $LANGUAGEwiki adopt universal pending changes protections", we could settle this argument once and for all using a real statistical model that can deliver precise effect sizes on activity. Maybe ''then'' we can all finally ]. ] (]) 18:08, 26 November 2024 (UTC)
:This is requested once or twice a year, and the answer will always be no. You would know this if you read ], as is requested at the top of this page ] (]) 08:09, 17 December 2024 (UTC)
This particular idea will not pass, but the binary developing in the discussion is depressing. A bargain where we allow IPs to edit (or unregistered users generally when IPs are masked), and therefore will sit on our hands when dealing with abuse and even harassment is a grim one. Any steps taken to curtail the second half of that bargain would make the first half stronger, and I am generally glad to see thoughts about it, even if they end up being impractical. ] (]) 02:13, 24 November 2024 (UTC)
:I don't want us to sit on our hands when we see abuse and harassment. I think our toolset is about 20 years out of date, and I believe there are things we could do that will help (e.g., ], cross-wiki checkuser tools for Stewards, detecting and responding to a little bit more information about devices/settings ). ] (]) 06:39, 24 November 2024 (UTC)
::Temporary accounts will help with the casual vandalism, but they’re not going to help with abuse and harassment. If it limits the ability to see ranges, it will make issues slightly worse. ] (]) 07:13, 24 November 2024 (UTC)
:::I'm not sure what the current story is there, but when I talked to the team last (i.e., in mid-2023), we were talking about the value of a tool that would do range-related work. For various reasons, this would probably be Toolforge instead of MediaWiki, and it would probably be restricted (e.g., to admins, or to a suitable group chosen by each community), but the goal was to make it require less manual work, particularly for cross-wiki abuse, and to be able to aggregate some information without requiring direct disclosure of some PII. ] (]) 23:56, 25 November 2024 (UTC)
Oh look, misleading statistics! "The Portuguese Misplaced Pages banned IPs only from the mainspace three years ago. . After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. " ''Of course'' you have a spike in new registrations soon after you stop allowing IP edits, and you can't sustain that spike. That is not evidence of anything. It would have been more honest and illustrative to show the graph before and after the policy change, not only afterwards, e.g. . Oh look, banning IP editing has resulted in on average some 50% ''more'' registered editors than before the ban. Number of active editors is up 50% as well. The number of new pages has stayed the same. Number of edits is down, yes, but how much of this is due to less vandalism / vandalism reverts? A lot apparently, as the count of user edits has stayed about the same. Basically, from those statistics, used properly, it is impossible to detect any issues with the Portuguese Misplaced Pages due to the banning of IP editing. ] (]) 08:55, 26 November 2024 (UTC)
Hi all,
:"how much of this is due to less vandalism / vandalism reverts?" That's a good question. Do we have some data on this? ] (]) 09:20, 26 November 2024 (UTC)
There is a vote ]. Some people believe the fair use policy currently disallows fair use of promotional photographs of living people if they occasionally make public appearances, others disagree with this. This proposal would clarify the issue.
::{{Ping|Jo-Jo Eumerus}}, the dashboard is although it looks like they stopped reporting the data in late 2021. If you take "Number of reverts" as a proxy for vandalism, you can see that the block shifted the number of reverts from a higher equilibrium to a lower one, while overall non-reverted edits does not seem to have changed significantly during that period. ] (]) 11:44, 28 November 2024 (UTC)
:::Upon thinking, it would be useful to know how many ''good'' edits are done by IP. Or as is, unreverted edits. ] (]) 14:03, 30 November 2024 (UTC)
:I agree that one should expect a spike in registration. (In fact, I have suggested a strictly temporary requirement to register – a few hours, even – to push some of our regular IPs into creating accounts.) But once you look past that initial spike, the trend is downward. ] (]) 05:32, 29 November 2024 (UTC)
::{{tqb|But once you look past that initial spike, the trend is downward.}}
::I still don't see any evidence that this downward trend is unusual. Apparently the WMF ] and didn't find evidence of a drop in activity. Net edits (non-revert edits standing for at least 48 hours) increased by 5.7%, although edits across other wikis increased slightly more. The impression I get is any effects are small either way—the gains from freeing up anti-vandalism resources basically offset the cost of some IP editors not signing up.
::TBH this lines up with what I'd expect. Very few people I talk to cite issues like "creating an account" as a major barrier to editing Misplaced Pages. The most common barrier I've heard from people who tried editing and gave it up is "Oh, I tried, but then some random admin reverted me, linked me to ], and told me to go fuck myself but with less expletives." ] (]) 07:32, 29 November 2024 (UTC)
::{{tqb|But once you look past that initial spike, the trend is downward.}} Not really obvious, and not more or even less so in Portuguese wikipedia than in e.g. Enwiki, FRwiki, NLwiki, ESwiki, Svwiki... So, once again, these statistics show ''no issue at all'' with disabling IP editing on Portuguese Misplaced Pages. ] (]) 10:38, 29 November 2024 (UTC)
Aside from the obvious loss of good 'IP' editors, I think there's a risk of unintended consequences from 'stopping vandalism' at all; 'vandalism' and 'disruptive editing' from IP editors (or others) isn't ''necessarily'' a bad thing, long term.
Even the worst disruptive editors 'stir the pot' of articles, bringing attention to articles that need it, and otherwise would have gone unnoticed. As someone who mostly just trawls through recent changes, I can remember dozens of times when where an IP, or brand new, user comes along and breaks an article entirely, but their edit leads inexorably to the article being improved. Sometimes there is a glimmer of a good point in their edit, that I was able to express better than they were, maybe in a more balanced or neutral way. Sometimes they make an entirely inappropriate edit, but it brings the article to the top of the list, and upon reading it I notice a number of other, previously missed, problems in the article. Sometimes, having reverted a disruptive change, I just go and add some sources or fix a few typos in the article before I go on my merry way.
You might think 'Ah, but 'Random article' would let you find those problems too. BUT random article' is, well, random. IP editors are more targeted, and that someone felt the need to disparage a certain person's mother in fact brings attention to an article about someone who is, unbeknownst to us editors, particularly contentious in the world of Czech Jazz Flautists so there is a lot there to fix. By stopping people making these edits, we risk a larger proportion of articles becoming an entirely stagnant. ] 15:00, 9 December 2024 (UTC)
:I feel that ] has been too clever by half here. "Ahh, but vandalism of articles stimulates improvements to those articles." If the analysis ends there, I have no objections. But if, on the other hand, you come to the conclusion that it is a good thing to vandalize articles, that it causes information to circulate, and that the encouragement of editing in general will be the result of it, you will oblige me to call out, "Halt! Your theory is confined to that which is seen; it takes no account of that which is not seen." If I were to pay a thousand people to vandalize Misplaced Pages articles full-time, bringing more attention to them, would I be a hero or villain? If vandalism is good, why do we ban vandals instead of thanking them? Because vandalism is bad—every hour spent cleaning up after a vandal is one not spent writing a new article or improving an existing one.
] 22:13, 22 December 2006 (UTC)
:On targeting: vandals are more targeted than a "random article", but are far more destructive than basic tools for prioritizing content, and less effective than even very basic prioritization tools like sorting articles by total views. ] (]) 19:11, 9 December 2024 (UTC)
::I mean, I only said Vandalism "isn't necessarily a bad thing, long term", I don't think it's completely good, but maybe I should have added 'in small doses', fixing vandalism takes one or two clicks of the mouse in most cases and it seems, based entirely on my anecdotal experience, to sometimes have surprisingly good consequences; intuitively, you wouldn't prescribe vandalism, but these things have a way of finding a natural balance, and what's intuitive isn't necessarily what's right. One wouldn't prescribe dropping asteroids on the planet you're trying to foster life upon after you finally got it going, but we can be pretty happy that it happened! - And 'vandalism' is the very worst of what unregistered (and registered!) users get up to, there are many, many more unambiguously positive contributors than unambiguously malicious. ] 20:03, 9 December 2024 (UTC)
:::{{tqb|intuitively, you wouldn't prescribe vandalism}}
:::Right, and I think this is mainly the intuition I wanted to invoke here—"more vandalism would be good" a bit too galaxy-brained of a take for me to find it compelling without some strong empirical evidence to back it up.
:::Although TBH, I don't see this as a big deal either way. We already have to review and check IP edits for vandalism; the only difference is whether that content is displayed while we wait for review (with pending changes, the edit is hidden until it's reviewed; without it, the edit is visible until someone reviews and reverts it). This is unlikely to substantially affect contributions (the only difference on the IP's end is they have to wait a bit for their edit to show up) or vandalism (since we already ''de facto'' review IP edits). ] (]) 04:29, 14 December 2024 (UTC)
== Revise ] ==
== Move and edit ==
Point 1 of Procedural removal for inactive administrators which currently reads "Has made neither edits nor administrative actions for at least a 12-month period" should be replaced with "Has made no administrative actions for at least a 12-month period". The current wording of 1. means that an Admin who takes no admin actions keeps the tools provided they make at least a few edits every year, which really isn't the point. The whole purpose of adminship is to protect and advance the project. If an admin isn't using the tools then they don't need to have them. ] (]) 07:47, 4 December 2024 (UTC)
I frequently come across small stub articles at incorrectly-najmed pages and move them to more appropriate titles. Almost inevitably, the pages also need further work such as wikifying, categorising, or re-stubbing. Currently, the "successful move" page reads:
:<small>The page '''''oldname''''' ('''links''') has been moved to '''''newname'''''. </small>
*'''Support''' as proposer. ] (]) 07:47, 4 December 2024 (UTC)
:<small>Please '''check''' whether this move has created any '''double redirects''', and fix them as necessary. </small>
*'''Oppose''' - this would create an unnecessary barrier to admins who, for real life reasons, have limited engagement for a bit. Asking the tools back at BN can feel like a faff. Plus, logged admin activity is a poor guide to actual admin activity. In some areas, maybe half of actions aren't logged? ] (]) 19:17, 4 December 2024 (UTC)
*'''Oppose'''. First, not all admin actions are logged as such. One example which immediately comes to mind is declining an unblock request. In the logs, that's just a normal edit, but it's one only admins are permitted to make. That aside, if someone has remained at least somewhat engaged with the project, they're showing they're still interested in returning to more activity one day, even if real-life commitments prevent them from it right now. We all have things come up that take away our available time for Misplaced Pages from time to time, and that's just part of life. Say, for example, someone is currently engaged in a PhD program, which is a tremendously time-consuming activity, but they still make an edit here or there when they can snatch a spare moment. Do we really want to discourage that person from coming back around once they've completed it? ] <small><sup>]</sup></small> 21:21, 4 December 2024 (UTC)
*:We could declare specific types of edits which count as admin actions despite being mere edits. It should be fairly simple to write a bot which checks if an admin has added or removed specific texts in any edit, or made any of specific modifications to pages. Checking for protected edits can be a little harder (we need to check for protection at the time of edit, not for the time of the check), but even this can be managed. Edits to pages which match specific regular expression patterns should be trivial to detect. ] ] 11:33, 9 December 2024 (UTC)
*'''Oppose''' There's no indication that this is a problem needs fixing. ]] <small><sup>Shoot Blues, Tell VileRat!</sup></small> 00:55, 5 December 2024 (UTC)
* '''Support''' Admins who don't use the tools should not have the tools. ] ] 03:55, 5 December 2024 (UTC)
*'''Oppose''' While I have never accepted "not all admin actions are logged" as a realistic reason for no logged actions in an entre year, I just don't see what problematic group of admins this is in response to. Previous tweaks to the rules were in response to admins that seemed to be gaming the system, that were basically inactive and when they did use the tools they did it badly, etc. We don't need a rule that ins't pointed a provable, ongoing problem. ] ] 19:19, 8 December 2024 (UTC)
*'''Oppose''' If an admin is still editing, it's not unreasonable to assume that they are still up to date with policies, community norms etc. I see no particular risk in allowing them to keep their tools. ] (]) 19:46, 8 December 2024 (UTC)
*'''Oppose''': It feels like some people are trying to accelerate admin attrition and I don't know why. This is a solution in search of a problem. ] (]) 07:11, 10 December 2024 (UTC)
*'''Oppose''' Sure there is a problem, but the real problem I think is that it is puzzling why they are still admins. Perhaps we could get them all to make a periodic 'declaration of intent' or some such every five years that explains why they want to remain an admin. ] (]) 19:01, 11 December 2024 (UTC)
*'''Oppose''' largely per scribolt. We want to take away mops from inactive accounts where there is a risk of them being compromised, or having got out of touch with community norms, this proposal rather targets the admins who are active members of the community. Also declining incorrect deletion tags and AIV reports doesn't require the use of the tools, doesn't get logged but is also an important thing for admins to do. '']]<span style="color:#CC5500">Chequers</span>'' 07:43, 15 December 2024 (UTC)
*'''Oppose'''. What is the motivation for this frenzy to make more hoops for admins to jump through and use not jumping through hoops as an excuse to de-admin them? What problem does it solve? It seems counterproductive and de-inspiring when the bigger issue is that we don't have enough new admins. —] (]) 07:51, 17 December 2024 (UTC)
*'''Oppose''' Some admin actions aren't logged, and I also don't see why this is necessary. Worst case scenario, we have ]. ] (]) 15:25, 17 December 2024 (UTC)
*'''Oppose''' I quite agree with David Eppstein's sentiment. What's with the rush to add more hoops? Is there some problem with the admin corps that we're not adequately dealing with? Our issue is that we have too few admins, not that we have too many. ] <sup>]</sup>] 23:20, 22 December 2024 (UTC)
===Discussion (Admin inactivity removal)===
It would be a huuge help if that could be tweaked slightly to become:
* Making administrative actions can be helpful to show that the admin is still up-to-date with community norms. We could argue that if someone is active but doesn't use the tools, it isn't a big issue whether they have them or not. Still, the tools can be requested back following an inactivity desysop, if the formerly inactive admin changes their mind and wants to make admin actions again. For now, I don't see any immediate issues with this proposal. ] (] · ]) 08:13, 4 December 2024 (UTC)
* Looking back at previous RFCs, in ] the reasoning was to reduce the attack surface for inactive account takeover, and in ] it was about admins who haven't been around enough to keep up with changing community norms. What's the justification for this besides "use it or lose it"? Further, we already have a mechanism (from the 2022 RFC) to account for admins who make a few edits every year. ]] 12:44, 4 December 2024 (UTC)
* I also note that not all admin actions are logged. Logging editing through full protection requires ]. Reviewing of deleted content isn't logged at all. Who will decide whether an admin's XFD "keep" closures are really ]s or not? Do adminbot actions count for the operator? There are probably more examples. Currently we ignore these edge cases since the edits will probably also be there, but now if we can desysop someone who made 100,000 edits in the year we may need to consider them. ]] 12:44, 4 December 2024 (UTC)
*:I had completely forgotten that many admin actions weren't logged (and thus didn't "count" for activity levels), that's actually a good point (and stops the "community norms" arguments as healthy levels of community interaction can definitely be good evidence of that). And, since admins desysopped for inactivity can request the tools back, an admin needing the bit but not making any logged actions can just ask for it back. At this point, I'm not sure if there's a reason to go through the automated process of desysopping/asking for resysop at all, rather than just politely ask the admin if they still need the tools.{{pb}}I'm still very neutral on this by virtue of it being a pretty pointless and harmless process either way (as, again, there's nothing preventing an active admin desysopped for "inactivity" from requesting the tools back), but I might lean oppose just so we don't add a pointless process for the sake of it. ] (] · ]) 15:59, 4 December 2024 (UTC)
* To me this comes down to whether the community considers it problematic for an admin to have tools they aren't using. Since it's been noted that not all admin actions are logged, and an admin who isn't using their tools also isn't causing any problems, I'm not sure I see a need to actively remove the tools from an inactive admin; in a worst-case scenario, isn't this encouraging an admin to (potentially mis-)use the tools solely in the interest of keeping their bit? There also seems to be somewhat of a bad-faith assumption to the argument that an admin who isn't using their tools may also be falling behind on community norms. I'd certainly like to hope that if I was an admin who had been inactive that I would review P&G relevant to any admin action I intended to undertake before I executed. ] (]) 15:14, 4 December 2024 (UTC)
* As I have understood it, the original rationale for desysopping after no activity for a year was the perception that an inactive account was at higher danger of being hijacked. It had nothing to do with how often the tools were being used, and presumably, if the admin was still editing, even if not using the tools, the account was less likely to be hijacked. - ] 22:26, 4 December 2024 (UTC)
*:And also, if the account of an active admin ''was'' hijacked, both the account owner and those they interact with regularly would be more likely to notice the hijacking. The sooner a hijacked account is identified as hijacked, the sooner it is blocked/locked which obviously minimises the damage that can be done. ] (]) 00:42, 5 December 2024 (UTC)
*I was not aware that not all admin actions are logged, obviously they should all be correctly logged as admin actions. If you're an Admin you should be doing Admin stuff, if not then you obviously don't need the tools. If an Admin is busy IRL then they can either give up the tools voluntarily or get desysopped for inactivity. The "Asking the tools back at BN can feel like a faff." isn't a valid argument, if an Admin has been desysopped for inactivity then getting the tools back '''should''' be "a faff". Regarding the comment that "There's no indication that this is a problem needs fixing." the problem is Admins who don't undertake admin activity, don't stay up to date with policies and norms, but don't voluntarily give up the tools. The ] change was about total edits over 5 years, not specifically admin actions and so didn't adequately address the issue. ] (]) 03:23, 5 December 2024 (UTC)
*:{{tpq|obviously they should all be correctly logged as admin actions}} - how ''would'' you log actions that are administrative actions due to context/requiring passive use of tools (viewing deleted content, etc.) rather than active use (deleting/undeleting, blocking, and so on)/declining requests where accepting them would require tool use? (e.g. closing various discussions that really shouldn't be NAC'd, reviewing deleted content, declining page restoration) Maybe there are good ways of doing that, but I haven't seen any proposed the various times this subject came up. Unless and until "soft" admin actions are actually logged somehow, "editor has admin tools and continues to engage with the project by editing" is the closest, if very imperfect, approximation to it we have, with criterion 2 sort-of functioning to catch cases of "but these specific folks edit so little over a prolonged time that it's unlikely they're up-to-date and actively engaging in soft admin actions". (I definitely do feel '''criterion 2''' could be significantly stricter, fwiw) ]] 05:30, 5 December 2024 (UTC)
*::Not being an Admin I have no idea how their actions are or aren't logged, but is it a big ask that Admins perform at least a few logged Admin actions in a year? The "imperfect, approximation" that "editor has admin tools and continues to engage with the project by editing" is completely inadequate to capture Admin inactivity. ] (]) 07:06, 6 December 2024 (UTC)
*:::Why is it "completely inadequate"? ] (]) 10:32, 6 December 2024 (UTC)
*::::I've been a "hawk" regarding admin activity standards for a very long time, but this proposal comes off as half-baked. The rules we have now are the result of careful consideration and incremental changes aimed at specific, ''provable'' issues with previous standards. While I am not a proponent of "not all actions are logged" as a blanket excuse for no logged actions in several years, it is feasible that an admin could be otherwise fully engaged with the community while not having any logged actions. We haven't been having trouble with admins who would be removed by this, so where's the problem? ] ] 19:15, 8 December 2024 (UTC)
== "Blur all images" switch ==
:<small>The page '''''oldname''''' ('''links''') has been moved to '''''newname''''' ('''edit'''). </small>
:<small>Please '''check''' whether this move has created any '''double redirects''', and fix them as necessary. </small>
Although i know that ], i propose that the Vector 2022 and Minerva Neue skins (+the Misplaced Pages mobile apps) have a "blur all images" toggle that blurs all the images on all pages (requiring clicking on them to view them), which simplifies the process of doing ] as that means:
Any chance of adding that edit link? Pretty please? ]...''<small><font color="#008822">]</font></small>'' 23:00, 22 December 2006 (UTC)
#You don't need to create an account to hide all images.
#You don't need any complex JavaScript or CSS installation procedures. Not even browser extensions.
#You can blur all images in the mobile apps, too.
#It's all done with one push of a button. No extra steps needed.
#Blurring all images > hiding all images. The content of a blurred image could be easily memorized, while a completely hidden image is difficult to compare to the others.
And it shouldn't be limited to just Misplaced Pages. This toggle should be available on all other WMF projects and MediaWiki-powered wikis, too.
] (]) 15:26, 5 December 2024 (UTC)
:Sounds good. ] will be thrilled. ] (]) 15:29, 5 December 2024 (UTC)
:Sounds like something I can try to make a demo of as a userscript! ] (] · ]) 15:38, 5 December 2024 (UTC)
::] should do the job, although I'm not sure how to deal with the Page Previews extension's images. ] (] · ]) 16:16, 5 December 2024 (UTC)
:::Wow, @], is that usable on all skins/browsers/devices? If so, we should be referring people to it from everywhere instead of the not-very-helpful ], which I didn't even bother to try to figure out. ] (]) 15:00, 17 December 2024 (UTC)
::::I haven't tested it beyond my own setup, although I can't see reasons why it wouldn't work elsewhere. However, there are two small bugs I'm not sure how to fix: when loading a new page, the images briefly show up for a fraction of a second before being blurred; and the images in Page Previews aren't blurred (the latter, mostly because I couldn't get the html code for the popups). ] (] · ]) 16:57, 17 December 2024 (UTC)
:::::Ah, yes, I see both of those. Probably best to get at least the briefly-showing bug fixed before recommending it generally. The page previews would be good to fix but may be less of an issue for recommending generally, since people using that can be assumed to know how to turn it off. ] (]) 18:28, 17 December 2024 (UTC)
::::::I don't think there's a way to get around when the Javascript file is loaded and executed. I think users will have to modify their personal CSS file to blur images on initial load, much like the solution described at {{section link|Help:Options to hide an image|Hide all images until they are clicked on}}. ] (]) 18:41, 17 December 2024 (UTC)
::::@] -- the issue with a script would be as follows:
::::# Even for logged-in users, user scripts are a moderate barrier to install (digging through settings, or worse still, having to copy-paste to the JS/CSS user pages).
::::# The majority of readers do not have an account, and the overwhelming majority of all readers make zero edits. For many people, it's too much of a hassle to sign up (or they can't remember their password, or a number of other reasons etc, etc)
::::What all readers and users have, though, is this menu: ]
::::I say instead of telling the occasional IP or user who complains to install a script (there are probably many more people who object to NOTCENSORED, but don't want to or don't know how to voice objections), we could add the option to replace all images with a placeholder (or blur) and perhaps also an option to increase thumbnail size.
::::On the image blacklist aspect, doesn't ] have a script that hides potentially offensive images? I've not a clue how it works, but perhaps it could be added to the appearance menu (I don't support this myself, for a number of reasons)
::::''']]''' 18:38, 17 December 2024 (UTC)
::::: That's ], which is already listed on ]. I wrote it a long time ago as a joke for one of these kinds of discussions: it does very well at hiding all "potentially offensive" images because it hides all images. But people who want to have to click to see any images found it useful enough to list it on ]. ]] 22:52, 17 December 2024 (UTC)
::::::Out of curiosity, how does it filter for potentially offensive images? The code at user:Anomie/hide-images.js seems rather minimal (as I write this, I realize it may work by hiding ''all'' images, so I may have answered my own question). ''']]''' 22:58, 17 December 2024 (UTC)
:::::::{{tq|because it hides all images}} ] (]) 23:11, 17 December 2024 (UTC)
:Will be a problem for non registered users, as the default would clearly to leave images in blurred for them.<span id="Masem:1733413219582:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — ] (]) 15:40, 5 December 2024 (UTC)</span>
::Better show all images by default for all users. If you clear your cookies often you can simply change the toggle every time. ] (]) 00:07, 6 December 2024 (UTC)
:::That's my point: if you are unregistered, you will see whatever the default setting is (which I assume will be unblurred, which might lead to more complaints). We had similar problems dealing with image thumbnail sizes, a setting that unregistered users can't adjust. ] (]) 01:10, 6 December 2024 (UTC)
::::I'm confused about how this would lead to more complaints. Right now, logged-out users see every image without obfuscation. After this toggle rolls out, logged-out users would still see every image without obfuscation. What fresh circumstance is leading to new complaints? <span style="position: relative; top: -0.5em;">꧁</span>]<span style="position: relative; top: -0.5em;">꧂</span> 07:20, 12 December 2024 (UTC)
:::::Well, we'd be putting in an option to censor, but not actively doing it. People will have issues with that. '''] <sup>(] • ])</sup>''' 10:37, 12 December 2024 (UTC)
::::::Isn't the page ] "an option to censor" we've put in? ] (]) 11:09, 12 December 2024 (UTC)
:I'm not opposed to this, if it can be made to work, fine. ] (]) 19:11, 5 December 2024 (UTC)
:What would be the goal of a blur all images option? It seems too tailored. But a "hide all images" could be suitable. ] (]) 06:40, 11 December 2024 (UTC)
::Simply removing them might break page layout, so images could be replaced with an equally sized placeholder. ''']]''' 13:46, 13 December 2024 (UTC)
Could there be an option to simply not load images for people with a low-bandwidth connection or who don't want them? ] (]) 16:36, 5 December 2024 (UTC)
:To add this link, an admin will need to change ] to <small>(see in edit form for code)</small>:
:'''I agree'''. This way, the options would go as
The page "<span id="specialDeleteTarget">{{MediaWiki direct link}}</span>" (]) <span id="specialDeleteLink"></span> has been moved to "]" (<span class="plainlinks"></span>).
:*Show all images
:*Blur all images
:*Hide all images
:It would honestly be better with your suggestion. ] (]) 00:02, 6 December 2024 (UTC)
::Of course, it will do nothing to appease the "These pics shouldn't be on WP at all" people. ] (]) 06:52, 6 December 2024 (UTC)
:::“Commons be thataway” is what we should tell them ] (]) 18:00, 11 December 2024 (UTC)
::I suggest that the "hide all images" display file name if possible. Between file name and caption (which admittedly are often similar, but not always), there should be sufficient clue whether an image will be useful (and some suggestion, but not reliably so, if it may offend a sensibility.) -- ] (]) 17:59, 11 December 2024 (UTC)
:For low-bandwidth ''or expensive bandwidth'' -- many folks are on mobile plans which charge for bandwidth. -- ] (]) 14:28, 11 December 2024 (UTC)
Regarding not limiting image management choices to Misplaced Pages: that's why it's better to manage this on the client side. Anyone needing to limit their bandwidth usage, or to otherwise decide individually on whether or not to load each photo, will likely want to do this generally in their web browsing. ] (]) 18:43, 6 December 2024 (UTC)
'''Please ]''' whether this move has created any ], and fix them as necessary.
:Definitely a browser issue. You can get plug-ins for Chrome right now that will do exactly this, and there's no need for Misplaced Pages/Mediawiki to implent anything. — ] (]) 18:48, 6 December 2024 (UTC)
I propose something a bit different: all images on the bad images list can only be viewed with a user account that has been verified to be over 18 with government issued ID. I say this because in my view there is absolutely no reason for a minor to view it. ] (]) 23:41, 8 December 2024 (UTC)
:Well, that means readers will be forced to not only create an account, but also disclose sensitive personal information, just to see encyclopedic images. That is pretty much the opposite of a 💕. ] (] · ]) 23:44, 8 December 2024 (UTC)
::I can support allowing users to opt to blu4 or hide some types of images, but this needs to be an opt-in only. By default, show all images. And I'm also opposed to any technical restriction which requires self-identification to overcome, except for cases where the Foundation deems it necessary to protect private information (checkuser, oversight-level hiding, or emails involving private information). Please also keep in mind that even if a user sends a copy of an ID which indicates the individual person's age, there is no way to verify that it was the user's own ID whuch had been sent. ] ] 11:25, 9 December 2024 (UTC)
:::Also, the ] is a really terrible standard. ] is completely harmless content that ''happened'' to be abused. And even some of the “NSFW” images are perfectly fine for children to view, for example ]. Are we becoming Texas or Florida now? ] (]) 18:00, 11 December 2024 (UTC)
::::You could've chosen a much better example like dirty toilet or the flag of Hezbollah... ] (]) 19:38, 11 December 2024 (UTC)
:::::Well, yes, but I rank that as “harmless”. I don’t know why anyone would consider a woman with her newborn baby so inappropriate for children it needs to be censored like hardcore porn. ] (]) 14:53, 12 December 2024 (UTC)
:::::The Hezbollah flag might be blacklisted because it's copyrighted, but placed in articles by uninformed editors (though one of JJMC89's bots automatically removes NFC files from pages). We have ] for those uses. ''']]''' 16:49, 13 December 2024 (UTC)
:I '''support''' this proposal. It’s a very clean compromise between the “think of the children” camp and the “freeze peach camp”. ] (]) 17:51, 11 December 2024 (UTC)
:Let me dox myself so I can view this image. Even Google image search doesn't require something this stringent. '''] <sup>(] • ])</sup>''' 19:49, 11 December 2024 (UTC)
:'''oppose''' should not be providing toggles to censor. ] (]) 15:15, 12 December 2024 (UTC)
:What about an option to disable images entirely? It might use significantly less data. ''']]''' 02:38, 13 December 2024 (UTC)
::This is an even better idea as an opt-in toggle than the blur one. Load no images by default, and let users click a button to load individual images. That has a use beyond sensitivity. <span style="position: relative; top: -0.5em;">꧁</span>]<span style="position: relative; top: -0.5em;">꧂</span> 02:46, 13 December 2024 (UTC)
:::Yes I like that idea even better. I think in any case we should use alt text to describe the image so people don’t have to play Russian roulette based on potentially vague or nonexistent descriptions, i.e. without alt text an ignorant reader would have no idea the album cover for ] depicts a nude child in a… ''questionable'' pose. ] (]) 11:42, 13 December 2024 (UTC)
::An option to replace images with alt text seems both much more useful and much more neutral as an option. There are technical reasons why a user might want to not load images (or only selectively load them based on the description), so that feels more like a neutral interface setting. An option to blur images by default sends a stronger message that images are dangerous.--] (]) 16:24, 13 December 2024 (UTC)
:::Also it'd negate the bandwidth savings somewhat (assuming an image is displayed as a low pixel-count version). I'm of the belief that Misplaced Pages should have more features tailored to the reader. ''']]''' 16:58, 13 December 2024 (UTC)
::::At the very least, add a filter that allows you to block all images on the bad image list, specifically that list and those images. To the people who say you shouldnt have to give up personal info, I say that we should go the way Roblox does. Seems a bit random, hear me out: To play 17+ games, you need to verify with gov id, those games have blood alcohol, unplayable gambling and "romance". I say that we do the same. Giving up personal info to view bad things doesn't seem so bad to me. ] (]) 03:44, 15 December 2024 (UTC)
:::::Building up a database of people who have applied to view bad things on a service that's available in restrictive regimes sounds like a way of putting our users in danger. -- ] (]) 07:13, 15 December 2024 (UTC)
:::::Roblox =/= Misplaced Pages. I don’t know why I have to say this, nor did I ever think I would. And did you read what I already said about the “bad list”? Do you want people to have to submit their ID to look at poop, a woman with her baby, the Hezbollah flag, or ]? How about we age-lock articles about adult topics next? ] (]) 15:55, 15 December 2024 (UTC)
:::::Ridiculous. '''] <sup>(] • ])</sup>''' 16:21, 15 December 2024 (UTC)
:::::So removing a significant thing that makes Misplaced Pages free is worth preventing underaged users from viewing certain images? I wouldn't say that would be a good idea if we want to make Misplaced Pages stay successful. If a reader wants to read an article, they should expect to see images relevant to the topic. This includes topics that are usually considered NSFW like ], ], et cetera. If a person willingly reads an article about an NSFW topic, they should acknowledge that they would see topic-related NSFW images. <span style="font-family:Times New Roman;font-size:100%;color:#00008B;background-color:transparent;;CSS">]]</span> 16:45, 15 December 2024 (UTC)
:::::What "bad things"? You haven't listed any. --] (]) (]) 15:57, 17 December 2024 (UTC)
:::::This is moot. Requiring personal information to use Misplaced Pages isn't something this community even has the authority to do. ] (]) 16:23, 17 December 2024 (UTC)
::Yes, if this happens it should be through a disable all images toggle, not an additional blur. There have been times that would have been very helpful for me. ] (]) 03:52, 15 December 2024 (UTC)
:'''Support''' the proposal as written. I'd imagine WMF can add a button below the already-existing accessibility options. People have different cultural, safety, age, and mental needs to block certain images. ] <i><sup style="display:inline-flex;rotate:7deg;">]</sup></i> 13:04, 15 December 2024 (UTC)
:I'd support an option to replace images with the alt text, as long as all you had to do to see a hidden image was a single click/tap (we'd need some fallback for when an image has no alt text, but that's a minor issue). Blurring images doesn't provide any significant bandwidth benefits and could in some circumstances cause problems (some blurred innocent images look very similar to some blurred blurred images that some people regard as problematic, e.g. human flesh and cooked chicken). I strongly oppose anything that requires submitting personal information of any sort in order to see images per NatGertler. ] (]) 14:15, 15 December 2024 (UTC)
::Fallback for alt text could be filename, which is generally at least slightly descriptive. -- ] (]) 14:45, 15 December 2024 (UTC)
* These ideas (particularly the toggle button to blur/hide all images) can be suggested at ''']'''. ] (]) 15:38, 15 December 2024 (UTC)
== Class icons in categories ==
:] ] 23:35, 22 December 2006 (UTC)
This is something that has frequently occurred to me as a potentially useful feature when browsing categories, but I have never quite gotten around to actually proposing it until now.
== Not so random ''Random article'' / "Fuzzy search" ==
Basically, I'm thinking it could be very helpful to have ] class icons appear next to article entries in categories. This should be helpful not only to readers, to guide them to the more complete entries, but also to editors, to alert them to articles in the category that are in need of work. Thoughts? ] (]) 03:02, 7 December 2024 (UTC)
I think the '''' link is interesting but unwieldly. I think it would be more interesting if the ''random article'' link had an option so one could make it a bit less random-- i.e. make it so one can semi-randomly select:
:If we go with this, I think there should be only 4 levels - Stub, Average (i.e. Start, C, or B), GA, & FA.
* an article that was created in the last 30 days
:There are significant differences between Start, C, and B, but there's no consistent effort to grade these articles correctly and consistently, so it might be better to lump them into one group. Especially if an article goes down in quality, almost nobody will bother to demote it from B to C. <span style="font-family:cursive">]]</span> 04:42, 8 December 2024 (UTC)
* articles in a specific area (i.e. ], ], ], ])
:: Isn't that more of an argument for consolidation of the existing levels rather than reducing their number for one particular application?
* by article length (i.e. so one can look for random stub-like articles... or long unreferenced ones)
:: Other than that, I think I would have to agree that there are too many levels - the difference between Start and C class, for example, seems quite arbitrary, and I'm not sure of the usefulness of A class - but the lack of consistency within levels is certainly not confined to these lower levels, as GAs can vary enormously in quality and even FAs. But the project nonetheless finds the content assessment model to be useful, and I still think their usefulness would be enhanced by addition to categories (with, perhaps, an ability to opt in or out of the feature).
* ... so one can select articles with a combination of the above.
:: I might also add that including content assessment class icons to categories would be a good way to draw more attention to them and encourage users to update them when appropriate. ] (]) 14:56, 8 December 2024 (UTC)
* <add a criterion>
:::I believe anything visible in reader-facing namespaces needs to be more definitively accurate than in editor-facing namespaces. So I'm fine having all these levels on talk pages, but not on category pages, unless they're applied more rigorously.
* <add a criterion>
:::On the other hand, with FAs and GAs, although standards vary within a range, they do undergo a comprehensive, well-documented, and consistent process for promotion and demotion. So just like we have an icon at the top of those articles (and in the past, next to interwiki links), I could hear putting them in categories. <span style="font-family:cursive">]]</span> 18:25, 8 December 2024 (UTC)
:Isn't the display of links Category pages entirely dependent on the Mediawiki software? We don't even have ]s displayed, which would probably be considerably more useful.{{pb}}Any function that has to retrieve content from member articles (much less their talkpages) is likely to be somewhat computationally expensive. Someone with more technical knowledge may have better information. ] (]) 18:01, 8 December 2024 (UTC)
::Yes, this will definitely require MediaWiki development, but probably not so complex. And I wonder why this will be more computationally expensive than scanning articles for ] tags in the first place. <span style="font-family:cursive">]]</span> 18:27, 8 December 2024 (UTC)
:::{{tpq| And I wonder why this will be more computationally expensive than scanning articles for ] tags in the first place}} my understanding is that this is not what happens. When a category is added to or removed from an article, the software adds or removes that page as a record from a database, and that database is what is read when viewing the category page. ] (]) 20:14, 8 December 2024 (UTC)
:I think that in the short term, this could likely be implemented using a user script (displaying short descriptions would also be nice). Longer-term, if done via an extension, I suggest limiting the icons to GAs and FAs for readers without accounts, as other labels aren't currently accessible to them. (Whether this should change is a separate but useful discussion).<span id="Frostly:1733699202975:WikipediaFTTCLNVillage_pump_(proposals)" class="FTTCmt"> — ] (]) 23:06, 8 December 2024 (UTC)</span>
:: I'd settle for a user script. Who wants to write it? :) ] (]) 23:57, 8 December 2024 (UTC)
::: As an FYI for whoever decides to write it, ] may be useful to you. ]] 01:04, 9 December 2024 (UTC)
::::@], the ] already exists. Go to ] and scroll about two-thirds of the way through that section.
::::I strongly believe that ordinary readers <ins>don't</ins> care about this kind of ], but if you want it for yourself, then use the gadget or fork its script. Changing this old gadget from "adding text and color" to "displaying an icon" should be relatively simple. ] (]) 23:43, 12 December 2024 (UTC)
*I strongly oppose loading any default javascript solution that would cause hundreds of client-side queries every time a category page is opened. As far as making an upstream software request, there are multiple competing page quality metrics and schemes that would need to be reviewed. — ] <sup>]</sup> 15:13, 18 December 2024 (UTC)
== Cleaning up NA-class categories ==
The above is related to "fuzzy searching"... by "]" I mean one that isn't so well defined in the search sense, i.e. inexact matching of search terms. It would be interesting if one could search articles by content, i.e. search articles for specific words (and get a list as output). Sometimes, I find it is not possible to remember the name of the article... but I remember the content. Google seems to be better at finding things then... than the Misplaced Pages's 'search' function. It would be interesting if Misplaced Pages had a search function (not unlike ])... that has the option of generating a ranking of articles instead of taking one to one specific article. ] <small>]|]</small> 23:18, 22 December 2006 (UTC)
:Yeah, I've always wanted a feature like this. Sometimes I'm lost for things to do on Misplaced Pages (too much choice). It would be great if I could get a random article within, eg., Category:Science and fix what needs to be fixed. --] ] 02:35, 23 December 2006 (UTC)
We have a long-standing system of double classification of pages, by quality (stub, start, C, ...) and importance (top, high, ...). And then there are thousands of pages that don't need either of these; portals, redirects, categories, ... As a result most of these pages have a double or even triple categorization, e.g. ] is in ], ], and ].
::I'd also like to have similar filters for "some tasks you can do": I sometimes have a look at it but almost never find topics I have enough knowledge about. '''Support'''. —]] 04:44, 23 December 2006 (UTC)
My suggestion would be to put those pages only in the "Class" category (in this case ]), and only give that category a NA-rating. Doing this for all these subcats (File, Template, ...) would bring the at the moment 276,534 (!) pages in ] back to near-zero, only leaving the anomalies which probably need a different importance rating (and thus making it a useful cleanup category).
== Wiktionary integration? ==
Since the wiktionary project has really taken off, how about including a little blurb "wiktionary has a definition of this word" (with a link, of course!) or something like that for wikipedia articles that are also featured in the wiktionary? I'm not sure if this would be best done with a bot walking through the wiktionary and adding tags to wikipedia or if the databases could be synced...
Just an idea... ] 23:55, 22 December 2006 (UTC)
{{wiktionary|example}}
:You can use the template {{tl|wiktionary}} to do this where <nowiki>{{wiktionary|example}}</nowiki> gives the box shown on the right. ] ] 00:06, 23 December 2006 (UTC)
:Interesting that you should say that Wiktionary has 'really taken off'. There was a question recently about whether it was appropriate for Misplaced Pages to have an article on Wiktionary at all due to a lack of media coverage (see ]). --User:Ceyockey (<small>'']''</small>) 17:30, 23 December 2006 (UTC)
It is unclear why we have two systems (3 cat vs. 2 cat), the tags on ] (without class or NA indication) have a different effect than the tags on e.g. ], but my proposal is to make the behaviour the same, and in both cases to reduce it to the class category only (and make the classes themselve categorize as "NA importance"). This would only require an update in the templates/modules behind this, not on the pages directly, I think. ] (]) 15:15, 9 December 2024 (UTC)
== Actual edit summary inclusion in "edit summary" ==
:Are there any pages that don't have the default? e.g. are there any portals or Category talk: pages rated something other than N/A importance? If not then I can't see any downsides to the proposal as written. If there are exceptions, then as long as the revised behaviour allows for the default to be overwritten when desired again it would seem beneficial. ] (]) 16:36, 9 December 2024 (UTC)
At the moment the only way the nature of an edit can be discovered is by clicking the 'diff' link, and using the edit summaries provided by the editors. However edit summaries provided are often of little or no use - anonymous vandalism with no edit summary being one example. What about the possibility of categorizing edits based on their nature, e.g. text removal, text change, text insertion, link insertion... the options could be as complicated or as simple as necessary. Display this information in brief form next to the edit summary, and it could be useful when browsing an article's history, recent changes or a watchlist. ]] 06:35, 23 December 2006 (UTC)
::As far as I know, there are no exceptions. And I believe that one can always override the default behaviour with a local parameter. {{ping|Tom.Reding}} I guess you know these things better and/or knows who to contact for this. ] (]) 16:41, 9 December 2024 (UTC)
::Looking a bit further, there do seem to be exceptions, but I wonder why we would e.g. have redirects which are of high importance to a project (]). Certainly when one considers that in some cases, the targets have a lower importance than the redirects? E.g. ]. ] (]) 16:46, 9 December 2024 (UTC)
:::I was imagining high importance United States redirects to be things like ] but that isn't there and what is is a very motley collection. I only took a look at one, ]. As far as I can make out the article was originally at this title but later moved to ] over a redirect. Both titles had independent talk pages that were neither swapped nor combined, each being rated high importance when they were the talk page of the article. It seems like a worthwhile exercise for the project to determine whether any of those redirects are actually (still?) high priority but that's independent of this proposal. ] (]) 17:17, 9 December 2024 (UTC)
:::{{clc|Custom importance masks of WikiProject banners}} is where to look for projects that might use an importance other than NA for cats, or other deviations. <b>~</b> <span style="font-family:Monotype Corsiva; font-size:16px;">] (] ⋅])</span> 17:54, 9 December 2024 (UTC)
:Most projects don't use this double intersection (as can be seen by the amount of categories in ], compared to ]). I personally feel that the bot updated page like ] is enough here and requires less category maintenance (creating, moving, updating, etc.) for a system that is underused. ] (]) 17:41, 9 December 2024 (UTC)
:Support this, even if there might be a few exceptions, it will make them easier to spot and deal with rather than having large unsorted NA-importance categories. ] (] · ]) 18:04, 9 December 2024 (UTC)
:Strongly agree with this. It's bizarre having two different systems, as well as a pain in the ass sometimes. Ideally we should adopt a single consistent categorization system for importance/quality. ] (]) 22:56, 16 December 2024 (UTC)
Okay, does anyone know what should be changed to implement this? I presume this comes from ], I'll inform the people there about this discussion. ] (]) 14:49, 13 December 2024 (UTC)
:Edit summaries are now automatically supplied in many cases, see ]. In addition, ] now includes a count of characters (bytes) added or deleted by each edit. There is an existing software change request to add this count to the watchlist display, please see ]. -- ] <small>(])</small> 16:34, 23 December 2006 (UTC)
:So essentially what you are proposing is to delete ] and all its subcategories? I think it would be best to open a CfD for this, so that the full implications can be discussed and consensus assured. It is likely to have an effect on assessment tools, and tables such as ] would no longer add up to the expected number — Martin <small>(] · ])</small> 22:13, 14 December 2024 (UTC)
:Yes, but automatic edit summaries don't (and can't) help in the "normal" cases. A typical abuse of them is editing a section and leaving the section name nicely enclosed in <code>/* */</code> as summary. A cheat, at best. —]] 17:05, 23 December 2006 (UTC)
::There was a CfD specifically for one, and the deletion of ] doesn't seem to have broken anything so far. A CfD for the deletion of 1700+ pages seems impractical, an RfC would be better probably. ] (]) 08:52, 16 December 2024 (UTC)
:::Well a CfD just got closed with 14,000 categories, so that is not a barrier. It is also the technically correct venue for such discussions. By the way, all of the quality/importance intersection categories check that the category exists before using it, so deleting them shouldn't break anything. — Martin <small>(] · ])</small> 08:57, 16 December 2024 (UTC)
::::And were all these cats tagged, or how was this handled? ] (]) 10:21, 16 December 2024 (UTC)
:::::]. HouseBlaster took care of listing each separate cateory on the working page. — Martin <small>(] · ])</small> 10:43, 16 December 2024 (UTC)
::::::I have no idea what the "working page" is though. ] (]) 11:02, 16 December 2024 (UTC)
I'm going to have to '''oppose''' any more changes to class categories. Already changes are causing chaos across the system with the bots unable to process renamings and fixing redirects whilst ] is being overwhelmed by the side effects. Quite simply we must have no more changes that cannot be properly processed. Any proposal must have clear instructions posted before it is initiated, not some vague promise to fix a module later on. ] (]) 13:16, 16 December 2024 (UTC)
::I thought people cheat in games, and we aren't in one. ]<sup> ]</sup> |]| 17:23, 23 December 2006 (UTC)
:Then I'm at an impasse. Module people tell me "start a CfD", you tell me "no CfD, first make changes at the module". No one wants the NA categories for these groups. What we can do is 1. RfC to formalize that they are unwanted, 2. Change module so they no longer get populated 3. Delete the empty cats caused by steps 1 and 2. Is that a workable plan for everybody? ] (]) 13:39, 16 December 2024 (UTC)
::I don't think @] was telling you to make the changes at the module first, rather to prepare the changes in advance so that the changes can be implemented as soon as the CfD reaches consensus. For example this might be achieved by having a detailed list of all the changes prepared and published in a format that can be fed to a bot. For a change of this volume though I do think a discussion as well advertised as an RFC is preferable to a CfD though. ] (]) 14:43, 16 December 2024 (UTC)
:::Got it in one. There are just too many problems at the moment because the modules are not being properly amended in time. We need to be firmer in requiring proponents to identify the how to change before the proposal goes live so others can enact it if necessary, not close the discussion, slap the category on the working page and let a mess pile up whilst no changes to the module are implemented. ] (]) 19:37, 16 December 2024 (UTC)
::::Oh, I got it as well, but at the module talk page, I was told to first have a CfD (to determine consensus first I suppose, instead of writing the code without knowing if it will be implemented). As I probably lack the knowledge to make the correct module changes, I'm at an impasse. That's why I suggested an RfC instead of a CfD to determine the consensus for "deletion after the module has been changed", instead of a CfD which is more of the "delete it now" variety. No one here has really objected to the deletion per se, but I guess that a more formal discussion might be welcome. ] (]) 10:09, 17 December 2024 (UTC)
*'''Oppose''' on the grounds that I think the way we do it currently is fine. ] (]) 05:33, 18 December 2024 (UTC)
**What's the benefit of having two or three categories for the same group of pages? We have multiple systems (with two or three cats, and apparently other ones as well), with no apparent reason to keep this around. As an example, we have ] with more than 50,000 pages, e.g. ] apparently. But when I go to that page, it isn't listed in that category, it is supposedly listed in ] (which seems to be a nonsense category, we shouldn't have NA-class, only NA-importance). but that category doesn't contain that page. So now I have no idea what's going on or what any of this is trying to achieve. ] (]) 08:30, 18 December 2024 (UTC)
**:Something changed recently. I think. But it is useful to know which NA pages are tagged with a project with a granularity beyond just "Not Article". It helps me do maintenance and find things that are tagged improperly, especially with categories. I do not care what happens to the importance ratings. ] (]) 09:20, 18 December 2024 (UTC)
== Category:Current sports events ==
:::Not sure whether you got the irony. Did you? —]] 03:12, 24 December 2006 (UTC)
I would like to propose that sports articles should be left in the ] for 48 hours after these events have finished. I'm sure many Misplaced Pages sports fans (including me) open CAT:CSE first and then click on a sporting event in that list. And we would like to do so in the coming days after the event ends to see the final standings and results.
== A logical improvement drive ==
Currently, this category is being removed from articles too early, sometimes even before the event ends. Just like yesterday. ], what do you say about that?
I was wondering if it was possible to list all the articles sorted by decreasing "what links here" number of links. That way, we'd have a pretty accurate measure of the importance of an article to the whole encyclopedia, both in content and community. We could work to make the most important articles GAs and FAs, without the constant debate about article importance that generally cripples COWs and improvement drives.--] 12:33, 23 December 2006 (UTC)
:See ], and please don't post the same question on multiple village pump pages. -- ] <small>(])</small> 16:14, 23 December 2006 (UTC)
So I would like to ask you to consider my proposal. Or, if you have a better suggestion, please comment. Thanks, ] (]) 16:25, 9 December 2024 (UTC)
== Stop fair use ==
:Thank you for bringing up this point. I agree that leaving articles in the Category:Current sports events for a short grace period after the event concludes—such as 48 hours—would benefit readers who want to catch up on the final standings and outcomes. ] (]) 18:19, 9 December 2024 (UTC)
The end of Fair use has begun:
: Sounds reasonable on its face. ] (]) 23:24, 9 December 2024 (UTC)
]
:How would this be policed though? Usually that category is populated by the {{tl|current sport event}} template, which every user is going to want to remove immediately after it finishes. '''] <sup>(] • ])</sup>''' 19:51, 11 December 2024 (UTC)
--] 17:44, 23 December 2006 (UTC)
:It is already ]. ]<sup>]</sup> 21:03, 23 December 2006 (UTC)
::{{ping|Lee Vilenski}} First of all, the ] has nothing to do with the ]; articles are added to that category in the usual way.
== "Line-item veto" ==
::You ask how it would be policed. Simply, we will teach editors to do it that way – to leave an article in that category for another 48 hours. AnishaShar have already expressed their opinion above. ] is also known for removing 'CAT:CSE's from articles. I think we could put some kind of notice in that category so other editors can notice it. We could set up a vote here. Maybe someone else will have a better idea. ] (]) 20:25, 14 December 2024 (UTC)
I find too often that I get a page in my watchlist that I'd rather not be there. And it becomes such a pain in the neck, especially when it's one of those '''Misplaced Pages:Articles for deletion..../...../December.../14/....'''; I takes forever to single it out of the humongous list I have in there!
:Would it not be more suitable for a "recently completed sports event" category. It's pretty inaccurate to say it's current when the event finished over a day ago. '''] <sup>(] • ])</sup>''' 21:03, 14 December 2024 (UTC)
Okay Lee, that's also a good idea. We have these two sports event categories:
What I suggest is to somehow make a button that'll remove a page from your watchlist right from the watchlist. All you would have to do is look to the left of the page that has been recently edited and click "remove" or something. It'd be very helpful to quickly remove one or two pages you don't want to look at any more.
* ]
* ]
* ] can be a suitable addition to those two. ], you are also interested in categories and sporting events; what is your opinion? ] (]) 18:14, 16 December 2024 (UTC)
::I don't have any objection to a Recent sports events category being added, but personally, if I want to see results of recent sports events, I would be more likely to go to ], which should include all recent events. ] (]) 23:30, 16 December 2024 (UTC)
Suggestions? ] <sup>]</sup>  16:06, 24 December 2006 (UTC)
:Well, you could uncheck the box that says "watch this page" when you edit a page you don't want on your watchlist. You can also set the box to be unchecked by default in your preferences, I believe. That would solve the problem before it starts. Cheers, ]<sup>]</sup> 16:40, 24 December 2006 (UTC)
::There's a script at ] that does what you're suggesting. You can copy it into your ]. ] ] 19:03, 24 December 2006 (UTC)
== User-generated conflict maps ==
== Semi-automatic article quality ratings ==
In a number of articles we have (or had) user-generated conflict maps. I think the mains ones at the moment are ] and ]. The war in Afghanistan had one until it was removed as poorly-sourced in early 2021. As you can see from a brief review of ] the map has become quite controversial there too.
How does one (especially an inexperienced reader) determine at a glance how reliable or thorough an article is, or how many well-written and poorly-written articles there are on a specific topic, or in what ways an article is lacking and in what ways it isn't? I propose a semi-automated system that would answer these questions. It's a method to rate articles on several criteria -- Reliability, Neutrality, Thoroughness, Subject Importance, Text Quality -- by combining automated scoring with editor votes.
My personal position is that sourcing conflict maps entirely from reports of occupation by one side or another of individual towns at various times, typically from Twitter accounts of dubious reliability, to produce a map of the current situation in an entire country (which is the process described ]), is a ]/]. I also don't see liveuamap.com as necessarily being a highly reliable source either since it basically is an ]/Wiki-style user-generated source, and ]. I can understand it if a reliable source produces a map that we can use, but that isn't what's happening here.
The automated scoring would look at things like cleanup/unsourced/stub/dispute tags, (ex-)good/featured status, page protection (and the reason for it), being up for or having survived a VfD, and WikiProject quality/importance ratings; it would also analyze the article content to detect things like stubbishness or lack of references. To reduce the motivation for vandalism, it wouldn't re-evaluate after an edit by a non-admin until that edit had sat unchallenged for half an hour.
Part of the reason this flies under the radar on Misplaced Pages is it ultimately isn't information hosted on EN WP but instead on Commons, where reliable sourcing etc. is not a requirement. However, it is being used on Misplaced Pages to present information to users and therefore should fall within our PAGs.
The voting portion would have a variable weight that increased asymptotically from zero to 60~70% with the number of votes cast. New, anonymous or banned users' votes would be ignored, and admins might get multiple votes (no more than five), but experience metrics such as edit count would not determine voting strength. Votes would have to be renewed when they were, say, three months and fifty non-minor edits to the article old. One could vote on each criterion with a single click from the article page, or make a vote with a comment. The votes could even be a section of the talk page, with a template for each vote and a bot in place to stop people from changing each others' votes.
I think these maps should be deprecated unless they can be shown to be sourced entirely to a reliable source, and not assembled out of individual reports including unreliable ] sources. ] (]) 16:57, 11 December 2024 (UTC)
The ratings would be displayed on the side bar as a bar chart with red-yellow-green colour codes, one bar for each criterion, with numerical ratings from 0 to 1000 (although they'd actually range from 1 to 999, both as a built-in disclaimer and to stress that there's always room for improvement). Anyone who clicked the ratings could see what positive and negative factors affected them, who had voted them up or down and how the final calculation was made -- in short, it would be an open-source set of scores.
Willthiswork?Iknowitwouldbeabitcomplex,but I couldproduceamoredetaileddraftdesign,withallthefactors,numbersandequations. ]] 18:21, 24 December 2006 (UTC)
:A lot of the maps seem like they run into SYNTH issues because if they're based on single sources they're likely running into copyright issue as derivative works. I would agree though that if an image does not have clear sourcing it shouldn't be used as running into primary/synth issues. ] <sup><small>]</small></sup> 17:09, 11 December 2024 (UTC)
::Though simple information isn't copyrightable, if it's sufficiently visually similar I suppose that might constitute a copyvio. ''']]''' 02:32, 13 December 2024 (UTC)
:I am seeing two immediate problems with this. First, this could/would be hopelessly vandalized by patient users who wait out the auto-confirmed time limit. This could easily skew the results, rendering them essentially invalid.
:I agree these violate OR and at least the spirit of NOTNEWS and should be deprecated. I remember during the Wagner rebellion we had to fix one that incorrectly depicted Wagner as controlling a swath of Russia. ] (]) 05:47, 13 December 2024 (UTC)
::It's not just a matter of "waiting out," it's a matter of keeping the tag's addition un-reverted for that length of time. Keeping vandalism from reversion for half an hour would probably be difficult, and if not we can raise it to a few hours. ]] 20:52, 24 December 2006 (UTC)
]
:Second, in my opinion, administrators should not get multiple votes. Administrators are simply users with a couple extra buttons. I believe voting strength and weight should be equal for all users. I think that this could be good if the kinks are ironed out, but there is just too much potential for misuse at the current time. ]<sup>]</sup> 18:29, 24 December 2006 (UTC)
* The ] ''(right)'' seems quite respectable being based on the work of the ] and having lots of thoughtful process and rules for updates. It is used on many pages and in many Wikipedias. There is therefore a considerable consensus for its use. ]🐉(]) 11:33, 18 December 2024 (UTC)
::I said "admins ''might'' get multiple votes." If the consensus is against multiple votes for admins, that's fine, but as I understand it an admin is someone whom the community consensus trusts more than they trust non-admins. ]] 20:52, 24 December 2006 (UTC)
:'''Oppose''': First off, I'd like to state my bias as a bit of a map geek. I've followed the conflict maps closely for years.
:::While technically it is true that an average admin is more verified than an average user, we really don't want to create arbitrary levels - when people are given admin access, they are given a specific set of tools, not a level up; and extra votes aren't included, as of now. ]<sup> ]</sup> |]| 05:03, 25 December 2006 (UTC)
:I think the premise of this question is flawed. ''Some'' maps may be poorly sourced, but that doesn't mean all of them are. The updates to the Syrian, Ukraine, and Burma conflicts maps are sourced to third parties. So that resolves the OR issue.
:The sources largely agree with each other, which makes SYNTH irrelevant. Occasionally one source may be ahead of another by a few hours (e.g., LiveUaMap vs. ISW), but they're almost entirely in lock step.
:I think this proposal throws out the baby with the bathwater. One bad map doesn't mean we stop using maps; it means we stop using ''bad'' maps.
:You may not like the fact that these sources sometimes use OSI (open-source intelligence). Unfortunately, that is the nature of conflict in a zone where the press isn't allowed. Any information you get from the AP or the US government is likely to rely on the same sources.
:Do they make mistakes? Probably; but so do ''all'' historical sources. And these maps have the advantage that the Commons community continuously reviews changes made by other users. Much in the same way that Misplaced Pages is often more accurate than historical encyclopedias, I believe crowdsourcing may make these maps more accurate than historical ones.
:I think deprecating these maps would leave the reader at a loss (pictures speak a 1,000 words and all that). Does it get a border crossing wrong here or there? Yes, but the knowledge is largely correct.
:It would be an absolute shame to lose access to this knowledge. ] (]<small> • </small>]) 22:59, 19 December 2024 (UTC)
::@] ] is frowned upon as an argument for good reason. Beyond that: 1) the fact that these are based on fragmentary data is strangely not mentioned at all (] says 'Military situation as of December 18, 2024 at 2:00pm ET' which suggests that it's quite authoritative and should be trusted; the fact that it's based off the ISW is not disclosed.) 2) I'm not seeing where all the information is coming from the ISW. The ISW's map only covers territory, stuff like bridges, dams, "strategic hills" and the like are not present on the ISW map. Where is that info coming from? ] <sup><small>]</small></sup> 23:10, 19 December 2024 (UTC)
:::The Commons Syria map uses both the ISW and Liveuamap. The two are largely in agreement, with Liveuamap being more precise but using less reliable sources. If you have an issue with using Liveuamap as a source, fine, bring it up on the talk pages where it's used, or on the Commons talk page itself. But banning any ''any'' map of a conflict is throwing out the baby with the bathwater. The Ukraine map is largely based on ISW-verifiable information.
:::With regards to actual locations like bridges, I'm against banning Commons users from augmenting maps with easily verifiable landmarks. That definition of SYN is broad to the point of meaningless, as it would apply to any user-generated content that uses more than one source. ] (]<small> • </small>]) 23:50, 20 December 2024 (UTC)
:'''Weak Oppose''' I've been updating the Ukraine map since May 2022, so I hope my input is helpful. While I agree that some of the sources currently being used to update these maps may be dubious in nature, that has not always been the case. In the past, particularly for the Syria map, these maps have been considered among the most accurate online due to their quality sourcing. It used to be that a source was required for each town if it was to be displayed on these maps, but more recently, people have just accepted taking sources like LivaUAMap and the ISW and copying them exactly. Personally, I think we should keep the maps but change how they are sourced. I think that going back to the old system of requiring a reliable source for each town would clear up most of the issues that you are referring to, though it would probably mean that the maps would be less detailed than they currently are now. <span style="font-family:Copperplate Gothic, Ebrima;background-color:OrangeRed;border-radius:7px;text-shadow:2px 2px 4px#000000;padding:3px 3px;">]</span><sup>]</sup> 07:23, 21 December 2024 (UTC)
*'''Oppose''' The campaign maps are one of our absolute best features. The Syrian campaign map in particular was very accurate for much of the war. Having a high quality SVG of an entire country like that is awesome, and there really isn't anything else like it out there, which is why it provides such value to our readers. I think we have to recognize of our course that they're not 100% accurate, due to the fog of war. I wouldn't mind if we created subpages about the maps? Like, with a list of sources and their dates, designed to be reader facing, so that our readers could verify the control of specific towns for themselves. But getting rid of the maps altogether is throwing out the baby with the bathwater. ] <sup>]</sup>] 23:33, 22 December 2024 (UTC)
== Google Maps: Maps, Places and Routes ==
:I can envision a variant of this approach that starts with a smaller scope. We already have a list of known spelling mistakes that can be used to count the number of spelling errors - this would be a hard, indisputable metric.
::Great idea; a spelling check would be one of the factors in the Text Quality score under my system. But it would have to be on a per-thousand-words basis. ]] 20:55, 24 December 2006 (UTC)
:As this starts to prove itself we could add in other tests that flag the articles as deficient in some other areas. Start with a rating of 0 and then deduct points for errors. Going positive only invites problems as stated by ]. --] 18:40, 24 December 2006 (UTC)
::So "positive" just means "free of serious deficiencies." (Instead of a scale of 1 to 999, maybe it would be –999 to –1; in an ideal world, perfect scores ''would'' be the baseline.) It's still the same idea. ]] 20:55, 24 December 2006 (UTC)
:::Yes, "positive" wherein 0 is the topmost score that denotes an article free from computationaly detectable mistakes. Allowing people to rate articles subjectively invites all the issues mentioned here by others and obliterates the baby steps we can take now to encourage minimal adherence to proper English usage. Opening the ratings issue to human intervention just opens huge Pandora's Box. It is easier for people to agree on usage errors than it is to identify positive qualities. Start small with the errors, let people get accustomed to it then build on it. In other terms, you will never have perfection, just the pursuit of it. --] 21:22, 24 December 2006 (UTC)
:The potential for problems is too large, such rating polls are ]. Besides, a rating system already exists ] and is far from complete and needs help.
]
::That's what automated evaluation tools, multiple scores and voting can provide. ]] 01:15, 25 December 2006 (UTC)
Google Maps have the following categories: Maps, Places and Routes
:Why implement another system of assessment, articles with problems already greatly outnumber the better ones. We should be concentrating on improving them rather than judging them. ] 18:49, 24 December 2006 (UTC)
for example:
::I have to agree with the above; there are just too many factors and potential problems involved. The proposal also sounds similar to the stable versions test currently being developed, where a "stable version" is identified and shown on the article page, depending on votes by users on its "completeness". Thanks! ] <small>(])</small> 21:01, 24 December 2006 (UTC)
most significant locations have a www.google.com/maps/place/___ URL
How about this then: We'll implement the automated scoring and display first, see how well it works on its own, then talk about maybe adding the voting component later. ]] 01:15, 25 December 2006 (UTC)
these should be acknowledged and used somehow, perhaps
:Yes, definitely start with an automated system first, and get some feedback. For example, I suggest NOT evaluating after any edit by an anonymous user. Also, am I correct to assume that the rating will be posted on an article's talk page, not on the article itself? And will the rating template include a category? ] | ] 01:31, 25 December 2006 (UTC)
] (]) 00:22, 12 December 2024 (UTC)
]
::I was actually thinking of the ratings being displayed on the sidebar, and handled completely separately from the wiki code. ]] 04:12, 26 December 2006 (UTC)
:What is the proposal here? If its for the google maps article, that would be more suitable for the talk page. As I see it, your proposal is simply saying that google maps has an api and we should use it for... something. I could be missing something, though ] (]) 08:20, 17 December 2024 (UTC)
:About the system as a whole: Too complex, in my opinion. Maybe we would be fine with something very simple (like the system on Uncyc). Or the machine can provide its own automated estimate, to make it easier for someone's assessment, done as usually, manually. The problem with voting is that voting is too slow and inert, and wouldn't say much more than a simple glance. ]<sup> ]</sup> |]| 05:03, 25 December 2006 (UTC)
::As I understand it, the IP is proposing embeds of google maps, which would be nice from a functionality standpoint (the embedded map is kinda-rather buggy), but given Google is an advertising company, isn't great from a privacy standpoint. ''']]''' 16:25, 17 December 2024 (UTC)
:::I think they're proposing the use of external links rather than embedding. ] (]) 18:16, 17 December 2024 (UTC)
== Allowing page movers to enable two-factor authentication ==
::Yet you're proposing something like the system on Uncyclopedia, which is pure voting. I agree that at least for now, we should just do the automated system. And it wouldn't have to be terribly complicated either; see the algorithms I'm building at ]. ]] 04:12, 26 December 2006 (UTC)
I would like to propose that members of the ] user group be granted the <code>oathauth-enable</code> permission. This would allow them to use ] to enable ] on their accounts.
==Admin list==
The ] is getting kind of tough to load (crazy right, who the heck would ever want to check and see if someone is an admin). Any ideas about perhaps chopping it up in some way so as to alternatively load an alpha TOC and go from there? --] ] 21:57, 25 December 2006 (UTC)
:My first thought would be a simple alphabetical split like A-K on one page, L-Z on the next, and semi-active and inactive on a third. Of course the place in the alphabet would have to be determined, but I think doing it alphabetically would be the most neutral and useful, while still retaining the usefulness of listing semi-active and inactive admins separately. ]-] 22:21, 25 December 2006 (UTC)
=== Rationale (2FA for page movers) ===
:Strongly agree. Why does it take so long to load, there aren't that many lines? It's a lot faster to use the link to <span class="plainlinks"><font color="002bb8"></font></span> currently. Also, the inactive section at the end seems to have a problem - entries from #65 onward don't list the name properly, but just link to the word ] (I can't see anything wrong/different with the code there). —] 22:27, 25 December 2006 (UTC)
The page mover guideline already obligates people in that group to ], and failing to follow proper account security processes is grounds for ] of the right. This is because the group allows its members to (a) move pages along with up to 100 subpages, (b) override the title blacklist, and (c) have an increased rate limit for moving pages. In the hands of a vandal, these permissions could allow significant damage to be done very quickly, which is likely to be difficult to reverse.
Additionally, there is precedent for granting 2FA access to users with rights that could be extremely dangerous in the event of account compromise, for instance, ], ], and ] have the ability to enable this access, as do most administrator-level permissions (sysop, checkuser, oversight, bureaucrat, steward, interface admin).
::Short answer: the list is over the maximum ]. ] 02:55, 26 December 2006 (UTC)
=== Discussion (2FA for page movers) ===
== new marketing idea ==
* '''Support''' as proposer. ]<sub>]<sub>]</sub></sub> (]/]) 20:29, 12 December 2024 (UTC)
* '''Support''' (but if you really want 2FA you can just request permission to enable it on Meta) ] ] 20:41, 12 December 2024 (UTC)
*:For the record, I do have 2FA enabled. ]<sub>]<sub>]</sub></sub> (]/]) 21:47, 12 December 2024 (UTC)
*::Oops, that says you are member of "Two-factor authentication testers" (testers = good luck with that). ] (]) 23:52, 14 December 2024 (UTC)
*::: A group name which is IMO seriously misleading - 2FA is not being tested, it's being actively used to protect accounts. ] ] 23:53, 14 December 2024 (UTC)
*::::] still says "currently in production testing with administrators (and users with admin-like permissions like interface editors), bureaucrats, checkusers, oversighters, stewards, edit filter managers and the OATH-testers global group." ] ] 09:42, 15 December 2024 (UTC)
*'''Support''' as a pagemover myself, given the potential risks and need for increased security. I haven't requested it yet as I wasn't sure I qualified and didn't want to bother the stewards, but having <code><nowiki>oathauth-enable</nowiki></code> by default would make the process a lot more practical. ] (] · ]) 22:30, 12 December 2024 (UTC)
*: Anyone is qualified - the filter for stewards granting 2FA is just "do you know what you're doing". ] ] 22:46, 12 December 2024 (UTC)
*'''Question''' When's the last time a page mover has had their account compromised and used for pagemove vandalisn? Edit 14:35 UTC: I'm not doubting the nom, rather I'm curious and can't think of a better way to phrase things. ''']]''' 02:30, 13 December 2024 (UTC)
*Why isn't everybody allowed to enable 2FA? I've never heard of any other website where users have to go request someone's (pro forma, rubber-stamp) permission if they want to use 2FA. And is it accurate that 2FA, after eight years, is still ]? I guess my overall first impression didn't inspire me with confidence in the reliability and maintenance. ] (]) 06:34, 14 December 2024 (UTC)
** Because the recovery process if you lose access to your device and recovery codes is still "contact WMF Trust and Safety", which doesn't scale. See also ]. ]] 15:34, 14 December 2024 (UTC)
**:We should probably consult with WMF T&S before we create more work for them on what they might view as very low-risk accounts. Courtesy ping @]. –] <small>(])</small> 16:55, 14 December 2024 (UTC)
**:No update comment since 2020 doesn't fill me with hope. I like 2FA, but it needs to be developed into a usable solution for all. '''] <sup>(] • ])</sup>''' 00:09, 15 December 2024 (UTC)
**::I ain't a technical person, but could a less secure version of 2fa be introduced, where an email is sent for any login on new devices? ''']]''' 01:13, 15 December 2024 (UTC)
**:::Definitely. However email addresses also get detached from people, so that would require that people regularly reconfirm their contact information. —] (] • ]) 11:01, 18 December 2024 (UTC)
*:For TOTP (the 6-digit codes), it's not quite as bad as when it was written, as the implementation has been fixed over time. I haven't heard nearly as many instances of backup scratch codes not working these days compared to when it was new. The WebAuthn (physical security keys, Windows Hello, Apple Face ID, etc) implementation works fine on private wikis but I wouldn't recommend using it for CentralAuth, especially with the upcoming SUL3 migration. There's some hope it'll work better afterward, but will still require some development effort. As far as I'm aware, WMF is not currently planning to work on the 2FA implmentation.{{pb}} As far as risk for page mover accounts goes, they're at a moderate risk. Page move vandalism, while annoying to revert, is reversible and is usually pretty loud (actions of compromised accounts can be detected and stopped easily). The increased ratelimit is the largest concern, but compared to something like account creator (which has noratelimit) it's not too bad. I'm more concerned about new page reviewer. There probably isn't a ton of harm to enabling 2FA for these groups, but there isn't a particularly compelling need either. ] (]) 12:47, 19 December 2024 (UTC)
*'''Support''' per nom. PMV is a high-trust role (suppressredirect is the ability to make a blue link turn red), and thus this makes sense. As a side note, I have changed this to bulleted discussion; # is used when we have separate sections for support and oppose. <b>]]</b> (] • he/they) 07:19, 14 December 2024 (UTC)
*'''Oppose''' As a pagemover myself, I find pagemover is an ''extremely'' useful and do not wish to lose it. It is nowhere near the same class as template editor. You can already ask the stewards for 2FA although I would recommend creating a separate account for the purpose. After all these years, 2FA remains experimental, buggy and cumbersome. Incompatible with the Microsoft Authenticator app on my iphone. ] ] 23:59, 14 December 2024 (UTC)
*:The proposal (as I read it) isn't "you must have 2FA", rather "you have the option to add it". '''] <sup>(] • ])</sup>''' 00:06, 15 December 2024 (UTC)
*::@], ] is correct. This would merely provide page movers with the option to enable it. ]<sub>]<sub>]</sub></sub> (]/]) 00:28, 15 December 2024 (UTC)
*:::Understood, but I do not want it associated with an administrator-level permission, which would mean I am not permitted to use it, as I am not an admin. ] ] 09:44, 15 December 2024 (UTC)
*::::It's not really that. It would be an opt-in to allow users (in the group) to put 2FA on their account - at their own digression.
*::::The main reasons why 2FA is currently out to admins and the like is because they are more likely to be targeted for compromising and are also more experienced. The 2FA flag doesn't require any admin skills/tools and is only incedentally linked. '''] <sup>(] • ])</sup>''' 12:58, 15 December 2024 (UTC)
*:::::Wait, so why is 2FA not an option for everyone already? ] (]) 01:15, 18 December 2024 (UTC)
*::::::@] the MediaWiki's 2FA implementation is complex, and the WMF's processes to support people who get locked out of their account aren't able to handle a large volume of requests (developers can let those who can prove they are the owner of the account back in). My understanding is that the current processes cannot be efficiently scaled up either, as it requires 1:1 attention from a developer, so unless and until new processes have been designed, tested and implemented 2FA is intended to be restricted to those who understand how to use it correctly and understand the risks of getting locked out. ] (]) 09:36, 18 December 2024 (UTC)
*It probably won't make a huge difference because those who really desire 2FA can already ], and because no page mover will be required to do so. However, there will be page movers who wouldn't request a global permission for 2FA yet would enable it in their preferences if it was a simple option. And these page movers might benefit from 2FA even more than those who already care very strongly about the security of their account. ] (]) 03:18, 15 December 2024 (UTC)
*'''Support''' and I can't think of any argument against something not only opt-in but already able to be opted into. ] (]) 08:09, 15 December 2024 (UTC)
*'''Oppose''' this is a low value permission, not needed. If an individual PMV really wants to opt-in, they can already do so over at meta - no need to build custom configuration for this locally. — ] <sup>]</sup> 15:06, 18 December 2024 (UTC)
*'''Support'''; IMO all users should have the option to add 2FA. ] (]) 10:26, 19 December 2024 (UTC)
*'''Support''' All users should be able to opt in to 2FA. Lack of a scalable workflow for users locked out of their accounts is going to be addressed by WMF only if enough people are using 2FA (and getting locked out?) to warrant its inclusion in the product roadmap. – ] (]) 14:01, 19 December 2024 (UTC)
*:That (and to @] above) sounds like an argument to do just that - get support put in place and enable this globally, not to piecemeal it in tiny batches for discretionary groups on a single project (this custom configuration would support about 3/10ths of one percent of our active editors). To the point of this RFC, why do you think adding this for this '''specific''' tiny group is a good idea? — ] <sup>]</sup> 15:40, 19 December 2024 (UTC)
*::FWIW, I tried to turn this on for anyone on meta-wiki, and the RFC failed (]). — ] <sup>]</sup> 21:21, 19 December 2024 (UTC)
*:::Exactly. Rolling it out in small batches helps build the case for a bigger rollout in the future. – ] (]) 05:24, 20 December 2024 (UTC)
*:I'm pretty sure that 2FA is already available to anyone. You just have to want it enough to either request it "for testing purposes" or to go to testwiki and request that you made an admin there, which will automatically give you access. See ]. ] (]) 23:41, 21 December 2024 (UTC)
*::We shouldn't have to jump through borderline manipulative and social-engineering hoops to get basic security functionality. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 04:40, 22 December 2024 (UTC)
*'''Oppose'''. It sounds like account recovery when 2FA is enabled involves Trust and Safety. I don't think page movers' account security is important enough to justify increasing the burden on them. <span style="white-space: nowrap;">—] <sup>(]·])</sup></span> 14:10, 21 December 2024 (UTC)
*:Losing access to the account is less common nowadays since most 2FA apps, including Google Authenticator, have implemented cloud syncing so that even if you lose your phone, you can still access the codes from another device. – ] (]) 14:40, 21 December 2024 (UTC)
*::But this isn't about Google Authenticator. ] (]) 02:58, 22 December 2024 (UTC)
*:::Google Authenticator is a 2FA app, which at least till some point used to be the most popular one. – ] (]) 07:07, 22 December 2024 (UTC)
*::::But (I believe), it is not available for use at Misplaced Pages. ] (]) 07:27, 22 December 2024 (UTC)
*:::::That's not true. You can use any ] authenticator app for MediaWiki 2FA. I currently use Ente Auth, having moved on from Authy recently, and from Google Authenticator a few years back. {{pb}}In case you're thinking of SMS-based 2FA, it has become a thing of the past and is not supported by MediaWiki either because it's insecure (attackers have ways to trick your network provider to send them your texts). – ] (]) 09:19, 22 December 2024 (UTC)
*'''Support'''. Even aside from the fact that, in 2024+, everyone should be able to turn on 2FA .... Well, {{em|absolutely certainly}} should everyone who has an advanced bit, with potential for havoc in the wrong hands, be able to use 2FA here. That also includes template-editor, edit-filter-manager, file-mover, account-creator (and supersets like event-coordinator), checkuser (which is not strictly tied to adminship), and probably also mass-message-sender, perhaps a couple of the others, too. Some of us old hands have several of these bits and are almost as much risk as an admin when it comes to loss of account control. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 04:40, 22 December 2024 (UTC)
*:Take a look at ] - much of what you mentioned is already in place, because these are groups that could use it '''and''' are widespread groups used on most WMF projects. (Unlike extendedmover). — ] <sup>]</sup> 17:22, 22 December 2024 (UTC)
*Comment: It is really not usual for 2FA to be available to a user group that is not defined as privileged in the WMF files. By default, all user groups defined at CommonSettings.php (iirc) that are considered to be privileged have the <code>oathauth-enable</code> right. Also, the account security practices mentioned in ] are also mentioned at ], despite not being discussed at all. Shouldn't it be fair to have the <code>extendedmover</code> userright be defined as privileged. ] (]) 08:33, 23 December 2024 (UTC)
*'''Support'''. Like SMcCandlish, I'd prefer that anyone, and particularly any editor with advanced perms, be allowed to turn on 2FA if they want (this is already an option on some social media platforms). But this is a good start, too.{{pb}}Since this is a proposal to allow page movers to ''opt in'' to 2FA, rather than a proposal to ''mandate'' 2FA for page movers, I see no downside in doing this. – ] (]) 17:02, 23 December 2024 (UTC)
*'''Support''' this opt-in for PMs and the broader idea of '''everyone having it by default'''. Forgive me if this sounds blunt, but is the responsibility and accountability of protecting ''your'' account lie on ''you'' and not WMF. Yes, they can assist in recovery, but the burden should not lie on them. <span style="font-family:monospace;font-weight:bold">]:<]></span> 17:13, 23 December 2024 (UTC)
== Photographs by Peter Klashorst ==
TO whom this may concern,
Back in 2023 I ] a group of nude photographs by ] for deletion on Commons. I was concerned that the people depicted might not have been of age or consented to publication. Klashorst described himself as a "painting sex-tourist" because he would travel to third-world countries to have sex with women in brothels, and also paint pictures of them. On his Flickr account, he posted various nude photographs of African and Asian women, some of which appear to have been taken without the subjects' knowledge. Over the years, other Commons contributors have raised concerns about the Klashorst photographs (e.g. ).
My name is Simon Farquhar, I am a 4th year Univerisity of Guelph student and recently while relaxing with my roommates over a nice cool refreshing drink I came up with what I believe to be two great new marketing slogans to be used by Wikimedia...they go as followed...
I noticed recently that several of the Klashorst images had disappeared from Commons but the deletions hadn't been logged. I believe this happens when the WMF takes an office action to remove files. I don't know for sure whether that's the case, or why only a small number of the photographs were removed this way.
"In a quiki...search for it on Wiki" -or-
"In a jiffy...search for it on Wiki"
My proposal is that we stop using nude or explicit photographs by Klashorst in all namespaces of the English Misplaced Pages. This would affect about thirty pages, including high-traffic anatomy articles such as ] and ]. ]] 18:29, 16 December 2024 (UTC)
now, the first slogan can be altered as followed...
:@]: This seems as if it's essentially a request for a community sanction, and thus probably belongs better on the ]. Please tell me if I am mistaken. ]<sub>]<sub>]</sub></sub> (]/]) 23:12, 16 December 2024 (UTC)
"In a qwiki...search for it on Wiki"
::{{re|JJPMaster}} I am fine with moving the discussion elsewhere, if you think it more suitable. ]] 02:16, 17 December 2024 (UTC)
:{{ping|Genericusername57}} I disagree with JJPMaster in that this seems to be the right venue, but I also disagree with your proposal. Klashorst might have been a sleazeball, yes, but the images at the two listed articles do not show recognizable subjects, nor do they resemble “creepshots”, nor is there evidence they’re underage. If you object to his images you can nominate them on Commons. Your ‘23 mass nomination failed because it was extremely indiscriminate (i.e. it included a self portrait of the artist). ] (]) 00:30, 17 December 2024 (UTC)
:: {{re|Dronebogus}} According to ], Commons users repeatedly contacted Klashorst, asking him to provide proof of age and consent for his models, but he did not do so. I am planning on renominating the photographs on Commons, and I think removing them from enwiki first will help avoid spurious ] arguments. The self-portrait you are referring to also included another naked person. ]] 02:16, 17 December 2024 (UTC)
:::{{ping|Genericusername57}} replacing the ones at ] and ] wouldn’t be difficult; the first article arguably violates ] and conflicts with ] only showing a single image anyway. However I think it’s best if you went to those actual articles and discussed removing them. I don’t know what other pages use his images besides his own article but they should be dealt with separately. If you want to discuss banning his photos from Wikimedia in general that’s best discussed at Commons. In all cases my personal view is that regardless of whether they actually run afoul of any laws purging creepy, exploitative pornography of third-world women is no great loss. ] (]) 01:16, 18 December 2024 (UTC)
::::I have to confess that I do not remember the details of the attempts to clarify things with Peter. If this turns out to be something upon which this decision might turn, I will try to do more research. But I’m afraid it’s lost in the mists of time. ++]: ]/] 01:25, 24 December 2024 (UTC)
== Move the last edited notice from the bottom of the page to somewhere that's easier to find ==
and here i'm thinking wiki media should develop a search bar that can be put on to ones desktop known as the "Qwiki" search bar
Currently, if you want to check when the last page edit was, you have to look at the edit history or scroll all the way to the bottom of the page and look for it near the licensing info. I propose moving it under the view history and watch buttons, across from the standard "This article is from Misplaced Pages" disclaimer. Non-technical users may be put off by the behind-the-scenes nature of the page or simply not know of its existence. The Mobile site handles this quiet gracefully in my opinion. While it is still at the bottom of the page, it isn't found near Licensing talk and is a noticeable portion of the page ] (]) 08:32, 17 December 2024 (UTC)
Anyways that my new idea slash suggestion and Ishould mention that I do not seek any royalty (although perhaps a Quizno's sub might do)from this. If you would like to get a hold of me here is my contact information...you know...have your people get back to my people.
:Editors can already enable {{slink|mw:XTools#PageInfo gadget}}, which provides this information (and more) below the article title. I don't think non-editors would find it useful enough to be worth the space. ] (]) 18:12, 17 December 2024 (UTC)
Simon Farquhar
sfarquha(at)uoguelph(dot)ca <small>—The preceding ] comment was added by ] (] • ]){{#if:{{{2|}}}| {{{2}}}|}}.</small><!-- Template:Unsigned -->
:Pardon me, but I have to ask...did the cool refreshing drink contain alchohol? Cheers, ]<sup>]</sup> 04:04, 26 December 2006 (UTC)
== I wished Misplaced Pages supported wallpapers in pages... ==
== Hungarian Names ==
It would be even more awesome if we could change the wallpaper of pages in Misplaced Pages. But the fonts' colors could change to adapt to the wallpaper. The button for that might look like this: ] ] ] (]) 11:02, 21 December 2024 (UTC)
I'm not sure if this should be posted here or under miscellaneous, but please hear me out: in doing research on the PRC, I noticed that pages about Chinese personages have their ] first, according to ]: it's ] and ], not Zedong Mao and Xiaoping Deng. ] even has a little ] on it: "This is a Chinese name; the family name is X." This is all well and good. So why is this not followed for pages about Hungarians, who have the ]? It's downright awkward for a Hungarian to say "]" and "]" instead of "Kossuth Lajos" and "Petőfi Sándor." Nonetheless, this is how it is: Arany János's page (of course, at ]) even has a ] to the opposite effect of the Chinese: "The native form of this personal name is X. This article uses the Western name order."<br>
This, to me, seems unfair.<br>
] 04:01, 26 December 2006 (UTC)
:I think we already tried this. It was called ] ;) —] (] • ]) 11:51, 21 December 2024 (UTC)
== Moving the main page ==
:See ] for information on creating your own stylesheet. ] (]) 18:03, 21 December 2024 (UTC)
== Change page titles/names using "LGBTQ" to "LGBTQ+" ==
Please see ] for a proposal to move the main page to the Misplaced Pages: namespace. —<span style="font: small-caps 14px times; color: red;">] (])</span> 04:31, 26 December 2006 (UTC)
Please see my reasoning at ] (and please post your thoughts there). It was proposed that I use this page to escalate this matter, as seen on the linked talk page. ] (]) 20:42, 23 December 2024 (UTC)
RfC: Log the use of the HistMerge tool at both the merge target and merge source
Currently, there are open phabtickets proposing that the use of the HistMerge tool be logged at the target article in addition to the source article. Several proposals have been made:
Option 1a: When using Special:MergeHistory, a null edit should be placed in both the merge target and merge source's page's histories stating that a history merge took place.
(phab:T341760: Special:MergeHistory should place a null edit in the page's history describing the merge, authored Jul 13 2023)
Option 1b: When using Special:MergeHistory, add a log entry recorded for the articles at the both HistMerge target and source that records the existence of a history merge.
(phab:T118132: Merging pages should add a log entry to the destination page, authored Nov 8 2015)
Option 2: Do not log the use of the Special:MergeHistory tool at the merge target, maintaining the current status quo.
Should the use of the HistMerge tool be explicitly logged? If so, should the use be logged via an entry in the page history or should it instead be held in a dedicated log? — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)
Option 1a/b. I am in principle in support of adding this logging functionality, since people don't typically have access to the source article title (where the histmerge is currently logged) when viewing an article in the wild. There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. As for whether this is logged directly in the page history (as is done currently with page protection) or if this is merely in a separate log file, I don't have particularly strong feelings, but I do think that adding functionality to log histmerges at the target article would improve clarity in page histories. — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)
Option 1a/b. No strong feelings on which way is best (I'll let the experienced histmergers comment on this), but logging a history merge definitely seems like a useful feature. Chaotic Enby (talk · contribs) 16:02, 20 November 2024 (UTC)
1b would be most important to me but but 1a would be nice too. But this is really not the place for this sort of discussion, as noted below. Graham87 (talk) 16:28, 20 November 2024 (UTC)
Option 2 History merging done right should be seamless, leaving the page indistinguishable from if the copy-paste move being repaired had never happened. Adding extra annotations everywhere runs counter to that goal. Prefer 1b to 1a if we have to do one of them, as the extra null edits could easily interfere with the history merge being done in more complicated situations. * Pppery *it has begun...16:49, 20 November 2024 (UTC)
Could you expound on why they should be indistinguishable? I don't see how this could harm any utility. A log action at the target page would not show up in the history anyways, and a null edit would have no effect on comparing revisions. Aaron Liu (talk) 17:29, 20 November 2024 (UTC)
2 History merges are already logged, so this survey name is somewhat off the mark. As someone who does this work: I do not think these should be displayed at either location. It would cause a lot of noise in history pages that people probably would not fundamentally understand (2 revisions for "please process this" and "remove tag" and a 3rd revision for the suggested log), and it would be "out of order" in that you will have merged a bunch of revisions but none of those revisions would be nearby the entry in the history page itself. I also find protections noisy in this way as well, and when moves end up causing a need for history merging, you end up with doubled move entries in the merged history, which also is confusing. Adding history merges to that case? No thanks. History merges are more like deletions and undeletions, which already do not add displayed content to the history view. Izno (talk) 16:54, 20 November 2024 (UTC)
They presently are logged, but only at the source article. Take for example this entry. When I search for the merge target, I get nothing. It's only when I search the merge source that I'm able to get a result, but there isn't a way to know the merge source.
If I don't know when or if the histmerge took place, and I don't know what article the history was merged from, I'd have to look through the entirety of the merge log manually to figure that out—and that's suboptimal. — Red-tailed hawk(nest)17:05, 20 November 2024 (UTC)
... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
But ignoring that, why is it valuable to know this information? What do you gain? And is what you gain actually valuable to your end objective? For example, let's take your There have been several times I can think of when I've been going diff hunting or browsing page history and where some explicit note of a histmerge having occurred would have been useful. Is not the revisions left behind in the page history by both the person requesting and the person performing the histmerge not enough (see {{histmerge}})? There are history merges done that don't have that request format such as the WikiProject history merge format, but those are almost always ancient revisions, so what are you gaining there? And where they are not ancient revisions, they are trivial kinds of the form "draft x -> page y, I hate that I even had to interact with this history merge it was so trivial (but also these are great because I don't have to spend significant time on them)". Izno (talk) 17:32, 20 November 2024 (UTC)
... Page moves do the same thing, only log the move source. Yet this is not seen as an issue? :)
Page moves do leave a null edit on the page that describes where the page was moved from and was moved to. And it's easy to work backwards from there to figure out the page move history. The same cannot be said of the Special:MergeHistory tool, which doesn't make it easy to re-construct what the heck went on unless we start diving naïvely through the logs. — Red-tailed hawk(nest)17:50, 20 November 2024 (UTC)
It can be *possible* to find the original history merge source page without looking through the merge log, but the method for doing so is very brittle and extremeley hacky. Basically, look for redirects to the page using "What links here", and find the redirect whose first edit has an unusual byte difference. This relies on the redirect being stable and not deleted or retargetted. There is also another way that relies on byte difference bugs as described in the above-linked discussion by wbm1058. Both of those are ... particularly awful. Graham87 (talk) 03:48, 21 November 2024 (UTC)
In the given example, the history-merge occurred here. Your "log" is the edit summaries. "Created page with '..." is the edit summary left by a normal page creation. But wait, there is page history before the edit that created the page. How did it get there? Hmm, the previous edit summary "Declining submission: v - Submission is improperly sourced (AFCH)" tips you off to look for the same title in draft: namespace. Voila! Anyone looking for help with understanding a particular merge may ask me and I'll probably be able to figure it out for you. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)
Here's another scenario, this one from WP:WikiProject History Merge. The page history shows an edit adding +5,800 bytes, leaving the page with 5,800 bytes. But the previous edit did not leave a blank page. Some say this is a bug, but it's also a feature. That "bug" is actually your "log" reporting that a hist-merge occurred at that edit. Voila, the log for that page shows a temp delete & undelete setting the page up for a merge. The first item on the log:
clues you in to where to look for the source of the merge. Voila, that single edit which removed −5,633 bytes tells you that previous history was merged off of that page. The log provides the details. – wbm1058 (talk) 16:03, 21 November 2024 (UTC)
Again, there are times where the clues are much harder to find, and even in those cases, it'd be much better to have a unified and assured way of finding the source. Aaron Liu (talk) 16:11, 21 November 2024 (UTC)
Yeah. I don't think that we can permanently rely on that, given that future versions of MediaWiki are not bound in any real way to support that workaround. — Red-tailed hawk(nest)04:24, 3 December 2024 (UTC)
Support 1b (log only), oppose 1a (null edit). I defer to the experienced histmergers on this, and if they say that adding null edits everywhere would be inconvenient, I believe them. However, I haven't seen any arguments against logging the histmerge at both articles, so I'll support it as a sensible idea. (On a similar note, it bothers me that page moves are only logged at one title, not both.) Toadspike17:10, 20 November 2024 (UTC)
Option 2. The merges are already logged, so there’s no reason to add it to page histories. While it may be useful for habitual editors, it will just confuse readers who are looking for an old revision and occasional editors. Ships & Space(Edits)18:33, 20 November 2024 (UTC)
But only the source page is logged as the "target". IIRC it currently can be a bit hard to find out when and who merged history into a page if you don't know the source page and the mergeperson didn't leave any editing indication that they merged something. Aaron Liu (talk) 18:40, 20 November 2024 (UTC)
1B. The present situation of the action being only logged at one page is confusing and unhelpful. But so would be injecting null-edits all over the place. — SMcCandlish☏¢ 😼 01:38, 21 November 2024 (UTC)
Option 2. This exercise is dependent on finding a volunteer MediaWiki developer willing to work on this. Good luck with that. Maybe you'll find one a decade from now. – wbm1058 (talk) 05:51, 21 November 2024 (UTC)
And, more importantly, someone in the MediaWiki group to review it. I suspect there are many people, possibly including myself, who would code this if they didn't think they were wasting their time shuffling things from one queue to another. * Pppery *it has begun...06:03, 21 November 2024 (UTC)
That link requires a Gerrit login/developer account to view. It was a struggle to get in to mine (I only have one because of an old Toolforge account and I'd basically forgotten about it), but for those who don't want to go through all that, that group has only 82 members (several of whose usernames I recognise) and I imagine they have a lot on their collective plate. There's more information about these groups at Gerrit/Privilege policy on MediaWiki. Graham87 (talk) 15:38, 21 November 2024 (UTC)
Sorry, I totally forgot Gerrit behaved in that counterintuitive way and hid public information from logged out users for no reason. The things you miss if Gerrit interactions become something you do pretty much every day. If you want to count the members of the group you also have to follow the chain of included groups - it also includes https://ldap.toolforge.org/group/wmf, https://ldap.toolforge.org/group/ops and the WMDE-MediaWiki group (another login-only link), as well as a few other permission edge cases (almost all of which are redundant because the user is already in the MediaWiki group) * Pppery *it has begun...18:07, 21 November 2024 (UTC)
Support 1a/b, and I would encourage the closer to disregard any opposition based solely on the chances of someone ever actually implementing it. —Compassionate72712:52, 21 November 2024 (UTC)
Fine. This stupid RfC isn't even asking the right questions. Why did I need to delete (an expensive operation) and then restore a page in order to "set up for a history merge" Should we fix the software so that it doesn't require me to do that? Why did the page-mover resort to cut-paste because there was page history blocking their move, rather than ask a administrator for help? Why doesn't the software just let them move over that junk page history themselves, which would negate the need for a later hist-merge? (Actually in this case the offending user only has made 46 edits, so they don't have page-mover privileges. But they were able to move a page. They just couldn't move it back a day later after they changed their mind.) wbm1058 (talk) 13:44, 21 November 2024 (UTC)
Option 1b – changes to a page's history should be listed in that page's log. There's no need to make a null edit; pagemove null edits are useful because they meaningfully fit into the page's revision history, which isn't the case here. jlwoodwa (talk) 00:55, 22 November 2024 (UTC)
I'm noticing some commentary in the above RfC (on widening importer rights) as to whether or not this might be useful going forward. I do think that having the community weigh in one way or another here would be helpful in terms of deciding whether or not this functionality is worth building. — Red-tailed hawk(nest)15:51, 20 November 2024 (UTC)
True, but I agree with Red-tailed hawk that it's good to have the English Misplaced Pages community weigh on whether we want that feature implemented here to begin with. Chaotic Enby (talk · contribs) 16:05, 20 November 2024 (UTC)
I agree that this is an odd thing to RFC. This is about a feature in MediaWiki core, and there are a lot more users of MediaWiki core than just English Misplaced Pages. However, please do post the results of this RFC to both of the phab tickets. It will be a useful data point with regards to what editors would find useful. –Novem Linguae (talk) 23:16, 21 November 2024 (UTC)
I'm pretty sure that even if we had enough checkuser capacity to routinely run checks on every new user that doing so would be contrary to global policy. Thryduulf (talk) 04:14, 22 November 2024 (UTC)
Setting aside privacy issues, the fact that the WMF wouldn't let us do it, and a few other things: Checking a single account, without any idea of who you're comparing them to, is not very effective, and the worst LTAs are the ones it would be least effective against. This has been floated several times in the much narrower context of adminship candidates, and rejected each time. It probably belongs on WP:PEREN by now. -- Tamzin (they|xe) 04:21, 22 November 2024 (UTC)
Why can't it be automated? What are the privacy issues and what would WMF concerns be? There has to be a better system than SPI which imposes a huge burden on the filer (and often fails to catch socks) while we just leave the door open for LTAs. Mztourist (talk) 04:39, 22 November 2024 (UTC)
How would it be automated? We can't just block everyone who even sometimes shares an IP with someone, which is most editors once you factor in mobile editing and institutional WiFi. Even if we had a system that told checkusers about all shared-IP situations and asked them to investigate, what are they investigating for? The vast majority of IP overlaps will be entirely innocent, often people who don't even know each other. There's no way for a checkuser to find any signal in all that noise. So the only way a system like this would work is if checkusers manually identified IP ranges that are being used by LTAs, and then placed blocks on those ranges to restrict them from account creation... Which is what already happens. -- Tamzin (they|xe) 04:58, 22 November 2024 (UTC)
I would assume that IT experts can work out a way to automate CheckUser. If someone edits on a shared IP used by a previous sock that should be flagged and human CheckUsers notified so they can look at the edits and the previous sock edits and warn or block as necessary. Mztourist (talk) 05:46, 22 November 2024 (UTC)
We already have autoblock. For cases it doesn't catch, there's an additional manual layer of blocking, where if a sock is caught on an IP that's been used before but wasn't caught by autoblock, a checkuser will block the IP if it's technically feasible, sometimes for months or years at a time. Beyond that, I don't think you can imagine just how often "someone edits on a shared IP used by a previous sock". I'm doing that right now, probably, because I'm editing through T-Mobile. Basically anyone who's ever edited in India or Nigeria has been on an IP used by a previous sock. Basically anyone who's used a large institution's WiFi. There is not any way to weed through all that noise with automation. -- Tamzin (they|xe) 05:54, 22 November 2024 (UTC)
Addendum: An actually potentially workable innovation would be something like a system that notifies CUs if an IP is autoblocked more than once in a certain time period. That would be a software proposal for Phabricator, though, not an enwiki policy proposal, and would still have privacy implications that would need to be squared with the WMF. -- Tamzin (they|xe) 05:57, 22 November 2024 (UTC)
I believe Tamzin has it about right, but I want to clarify a thing. If you're hypothetically using T-Mobile (and this also applies to many other ISPs and many LTAs) then the odds are very high that you're using an IP address which has never been used before. With T-Mobile, which is not unusually large by any means, you belong to at least one /32 range which contains a number of IP addresses so big that it has 30 digits. These ranges contain a huge number of users. At the other extreme you have some countries with only a handful of IPs, which everyone uses. These IPs also typically contain a huge number of users. TLDR; is someone is using a single IP on their own then we'll probably just block it, otherwise you're talking about matching a huge number of users. -- zzuuzz03:20, 23 November 2024 (UTC)
T-Mobile USA is a perennial favourite of many of the most despicable LTAs, but that's besides the point. New users with an account can actually edit from T-Mobile. They can also edit from Jio, or Deutsche Telecom, Vodafone, or many other huge networks. -- zzuuzz03:50, 23 November 2024 (UTC)
It would apply to every new User as a protective measure against sockpuppetry, like a credit check before you get a card/overdraft. WP:NOTFISHING is archaic like the whole burdensome SPI system that forces honest users to do all the hard work of proving sockpuppetry while socks and vandals just keep being welcomed in under WP:AGF. Mztourist (talk) 05:46, 22 November 2024 (UTC)
What you're suggesting is to just inundate checkusers with thousands of cases. The suggestion (as I understand it) removes burden from SPI filers by adding a disproportional burden on checkusers, who are already an overworked group. If you're suggesting an automated solution, then I believe IP blocks/IP range blocks and autoblock (discussed by Tamzin, above) already cover enough. It's quite hard to weigh up what you're really suggesting because it feels very vague without much detail - it sounds like you're just saying "a new SPI should be opened for every new user and IP, forever" which is not really a workable solution (for instance, 50 accounts were made in the last 15 minutes, which is about one every 18 seconds) BugGhost🦗👻18:12, 22 November 2024 (UTC)
And most of those accounts will make zero, one, or two edits, and then never be used again. Even if we liked this idea, doing it for every single account creation would be a waste of resources. WhatamIdoing (talk) 23:43, 22 November 2024 (UTC)
CU's use their tools to identify socks when technical proof is necessary. The problem you're linking to is caused by one particular LTA account who is extremely obvious and doesn't really require technical proof to identify - check users would just be able to provide evidence for something that is already easy to spot. There's an essay on the distinction over at WP:DUCKBugGhost🦗👻14:45, 23 November 2024 (UTC)
LTA MAB is using a peer-to-peer VPN service which is similar to TOR. Blocking peer-to-peer VPN service endpoint IP addresses carries a higher risk of collateral damage because those aren't assigned to the VPN provider but rather a third party ISP who is likely to dynamically reassign the blocked address to a completely innocent party. 216.126.35.235 (talk) 00:22, 27 November 2024 (UTC)
The question I ask myself is why must we realize that it is not meant for fishing? To catch fish, you need to fish. The no-fishing rule is not fit for purpose, nor is it a rule that other organizations that actively search for ban evasion use. Machines can do the fishing. They only need to show us the fish they caught. Sean.hoyland (talk) 05:24, 27 November 2024 (UTC)
I think for the same reason we don't want governments to be reading our mail and emails. If we checkuser everybody, then nobody has any privacy. Donald Albury20:20, 27 November 2024 (UTC)
I sympathize with Mztourist. The current system is less effective than it needs to be. Ban evading actors make a lot of edits, they are dedicated hard-working folk in contentious topic areas. They can make up nearly 10% of new extendedconfirmed actors some years and the quicker an actor becomes EC the more likely they are to be blocked later for ban evasion. Their presence splits the community into two classes, the sanctionable and the unsanctionable with completely different payoff matrices. This has many consequences in contentious topic areas and significantly impacts the dynamics. The current rules are probably not good rules. Other systems have things like a 'commitment to authenticity' and actively search for ban evasion. It's tempting to burn it all down and start again, but with what? Having said that, the SPI folks do a great job. The average time from being granted extendedconfirmed to being blocked for ban evasion seems to be going down. Sean.hoyland (talk) 18:28, 22 November 2024 (UTC)
WhatamIdoing, me too. I'm doubtful about everything I say because I've noticed that the chance it is slightly to hugely wrong is quite high. The EC numbers are work in progress, but I got distracted. The description "nearly 10% of new extendedconfirmed actors" is a bit misleading, because 'new' doesn't really mean new actors. It means actors that acquired EC for a given year, so newly acquired privileges. They might have registered in previous years. Also, I don't have 100% confidence in the way count EC grants because there are some edge cases, and I'm ignoring sysops. But anyway, the statement was based on this data of questionable precision. And the statement about a potential relationship between speed of EC acquisition and probability of being blocked is based on this data of questionable precision. And of course, currently undetected socks are not included, and there will be many. Sean.hoyland (talk) 03:39, 23 November 2024 (UTC)
I'm not interested in clicking through to a Google file. Here's my back-of-the-envelope calculation: We have something like 120K accounts that would qualify for EXTCONF. Most of these are no longer active, and many stopped editing so long ago that they don't actually have the user right.
Misplaced Pages is almost 24 years old. That makes convenient math: On average, since inception, 5K editors have achieved EXTCONF levels each year.
If the 10% estimate is true, then 500 accounts per year – about 10 per week – are being created by banned editors and going undetected long enough for the accounts to make 500 edits and to work in CTOP areas. Do we even have enough WP:BANNED editors to make it plausible to expect banned editors to bring 500 accounts a year up to EXTCONF levels (plus however many accounts get started but are detected before then)? WhatamIdoing (talk) 03:53, 23 November 2024 (UTC)
Suit yourself. I'm not interested in what interests other people or back of the envelope calculations. I'm interested in understanding the state of a system over time using evidence-based approaches by extracting data from the system itself. Let the data speak for itself. It has a lot to tell us. Then it is possible to test hypotheses and make evidence-based decisions. Sean.hoyland (talk) 04:13, 23 November 2024 (UTC)
More than 100 XC socks? Or more than 100 detected socks, including socks with zero edits?
Making a lot of accounts isn't super unusual, but it's a lot of work to get 100 accounts up to 500+ edits. Making 50,000 edits is a lot, even if it's your full-time job. WhatamIdoing (talk) 01:59, 24 November 2024 (UTC)
Lots of users get it done in a couple of days, often through vandal fighting tools. It really is not that many when the edits are mostly mindless. nableezy - 00:18, 26 November 2024 (UTC)
But that's kind of my point: "A couple of days", times 100 accounts, means 200–300 days per year. If you work five days per week and 52 weeks per year, that's 260 work days. This might be possible, but it's a full-time job.
Since the 30-day limit is something that can't be achieved through effort, I wonder if a sudden change to, say, 6 months would produce a five-month reprieve. WhatamIdoing (talk) 02:23, 26 November 2024 (UTC)
Imagine that it takes an average of one minute to make a (convincing) edit. That means that 500 edits = 8.33 hours, i.e., more than one full work day.
Imagine, too, that having reached this point, you actually need to spend some time using your newly EXTCONF account. This, too, takes time.
If you operate several accounts at once, that means:
You spend an hour editing from Account1. You spend the next hour editing from Account2. You spend another hour editing from Account3. You spend your fourth hour editing from Account4. Then you take a break for lunch, and come back to edit from Accounts 5 through 8.
At the end of the day, you have brought 8 accounts up to 60 edits (12% of the minimum goal). And maybe one of them got blocked, too, which is lost effort. At this rate, it would take you an entire year of full-time work to get 100 EXTCONF accounts, even though you are operating multiple accounts concurrently. Doing 50 edits per day in 10 accounts is not faster than doing 500 edits in 1 account. It's the same amount of work. WhatamIdoing (talk) 05:13, 29 November 2024 (UTC)
Sure it’s an effort, though it doesn’t take a minute an edit. But I’m not sure why I need to imagine something that has happened multiple times already. Icewhiz most recently had like 4-5 EC accounts active, and there are probably several more. Yes, there is an effort there. But also yes, it keeps happening. nableezy - 15:00, 29 November 2024 (UTC)
Many of our frequent fliers are already adept at warehousing accounts for months or even years, so a bump in the time period probably won't make much off a difference. Additionally, and without going into detail publicly, there are several methods whereby semi- or even fully-automated editing can be used to get to 500 edits with a minimum of effort, or at least well within script-kid territory. Because so many of those are obvious on inspection some will assume that all of them are, but there are a number of rather subtle cases that have come up over the years and it would be foolish to assume that it isn't ongoing. 184.152.68.190 (talk) 17:31, 28 November 2024 (UTC)
Ban evading actors who employ deception via sockpuppetry in the WP:PIA topic area are here to improve Misplaced Pages, from their perspective, rather than damage it. There is no need to use faith. There are statistics. There is a probability that a 'new user' is employing ban evasion. Sean.hoyland (talk) 18:46, 22 November 2024 (UTC)
My initial comment wasn't a direct response to yours, but new users and IPs won't be able to edit in the WP:PIA topic area anyway since they need to be extended confirmed. Some1 (talk) 20:08, 22 November 2024 (UTC)
Let's not hold up the way PIA handles new users and IPs, in which they are allowed to post to talk pages but then have their talk page post removed if it doesn't fall within very specific parameters, as some sort of model. CMD (talk) 02:51, 23 November 2024 (UTC)
Strongly support automatically checkusering all active users (new and existing) at regular intervals. If it were automated -- e.g., a script runs that compares IPs, user agent, other typical subscriber info -- there would be no privacy violation, because that information doesn't have to be disclosed to any human beings. Only the "hits" can be forwarded to the CU team for follow-up. I'd run that script daily. If the policy forbids it, we should change the policy to allow it. It's mind-boggling that Misplaced Pages doesn't do this already. It's a basic security precaution. (Also, email-required registration and get rid of IP editing.) Levivich (talk) 02:39, 23 November 2024 (UTC)
I don't think you've been reading the comments from people who know what they are talking about. There would be hundreds, at least, of hits per day that would require human checking. The policy that prohibits this sort of massive breach of privacy is the Foundation's and so not one that en.wp could change even if it were a good idea (which it isn't). Thryduulf (talk) 03:10, 23 November 2024 (UTC)
A computer can be programmed to check for similarities or patterns in subscriber info (IP, etc), and in editing activity (time cards, etc), and content of edits and talk page posts (like the existing language similarity tool), with various degrees of certainty in the same way the Cluebot does with ORES when it's reverting vandalism. And the threshold can be set so it only forwards matches of a certain certainty to human CUs for review, so as not to overwhelm the humans. The WMF can make this happen with just $1 million of its $180 million per year (and it wouldn't be violating its own policies if it did so). Enwiki could ask for it, other projects might join too. Levivich (talk) 05:24, 23 November 2024 (UTC)
"Oh now I see what you mean, Levivich, good point, I guess you know what you're talking about, after all."
I seem to have missed this comment, sorry. However I am very sceptical that sockpuppet detection is meaningfully automatable. From what CUs say it is as much art as science (which is why SPI cases can result in determinations like "possilikely"). This is the sort of thing that is difficult (at best) to automate. Additionally the only way to reliably develop such automation would be for humans analyse and process a massive amount of data from accounts that both are and are not sockpuppets and classify results as one or the other, and that anaylsis would be a massive privacy violation on its own. Assuming you have developed this magic computer that can assign a likelihood of any editor being a sock of someone who has edited in the last three months (data older than that is deleted) on a percentage scale, you then have to decide what level is appropriate to send to humans to check. Say for the sake of argument it is 75%, that means roughly one in four people being accused are innocent and are having their privacy impinged unnecessarily - and how many CUs are needed to deal with this caseload? Do we have enough? SPI isn't exactly backlog free and there aren't hoards of people volunteering for the role (although unbreaking RFA might help with this in the medium to long term). The more you reduce the number sent to CUs to investigate, the less benefit there is over the status quo.
In addition to all the above, how similar is "similar" in terms of articles edited, writing style, timecard, etc? How are you avoiding legitimate sockpuppets? Thryduulf (talk) 18:44, 23 November 2024 (UTC)
You know this already but for anyone reading this who doesn't: when a CU "checks" somebody, it's not like they send a signal out to that person's computer to go sniffing around. In fact, all the subscriber info (IP address, etc.) is already logged on the WMF's server logs (as with any website). A CU "check" just means a volunteer CU gets to look at a portion of those logs (to look up a particular account's subscriber info). That's the privacy concern: we have rules, rightfully so, about when volunteer CUs (not WMF staff) can read the server logs (or portions of them). Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs. Privacy is only an issue when those logs are revealed to volunteer CUs.
So... feeding the logs into software in order to train the software doesn't violate anyone's policy. It's just letting a computer read its own files. Human verification of the training outcomes also doesn't have to violate anyone's privacy -- just don't use volunteer CUs to do it, use WMF staff. Or, anonymize the training data (changing usernames to "Example1", "Example2", etc.). Or use historical data -- which would certainly be part of the training, since the most effective way would be to put known socks into the training data to see if the computer catches them.
Anyway, training the system won't violate anyone's privacy.
As for the hit rate -- 75% would be way, way too low. We'd be looking for definitely over 90% or 95%, and probably more like 99.something percent. Cluebot doesn't get vandalism wrong 1 out of 4 times, neither should CluebotCU. Heck, if CluebotCU can't do better than 75%, it's not worth doing. A more interesting question is whether the 99.something% hit rate would be helpful to CUs, or whether that would only catch the socks that are so obvious you don't even need CU to recognize them. Only testing in the field would tell.
But overall, AI looking for patterns, and checking subscriber info, edit patterns, and the content of edits, would be very helpful in tamping down on socking, because the computer can make far more checks than a human (a computer can look at 1,000 accounts and a 100,000 edits no problem, which no human can do), it'll be less biased than humans, and it can do it all without violating anyone's privacy -- in fact, lowering the privacy violations by lowering the false positives, sending only high-probability (90%+, not 75%+) to humans for review. And it can all be done with existing technology, and the WMF has the money to do it. Levivich (talk) 19:38, 23 November 2024 (UTC)
The more you write the clearer you make it that you don't understand checkuser or the WMF's policies regarding privacy. It's also clear that I'm not going to convince you that this is unworkable so I'll stop trying. Thryduulf (talk) 20:42, 23 November 2024 (UTC)
If you are are unable to distinguish between reasoned disagreement and insults, then it's not at all weird that reasoned disagreement fails to convince you. Thryduulf (talk) 22:44, 23 November 2024 (UTC)
@Levivich: Whatever existing data set we have has too many biases to be useful for this, and this is going to be prone to false positives. AI needs lots of data to be meaningfully trained. Also, AI here would be learning a function; when the output is not in fact a function of the input, there's nothing for an AI model to target, and this is very much the case here. On Wikidata, where I am a CheckUser, almost all edit summaries are automated even for human edits (just like clicking the rollback button is, or undoing an edit is by default), and it is very hard to meaningfully tell whether someone is a sock or not without highly case-specific analysis. No AI model is better than the data it's trained on.
Also, about the privacy policy: you are completely incorrect when you "Those rules do not apply to WMF staff, like devs and maintenance personnel, nor do they apply to the WMF's own software reading its own logs". Staff can only access that information on a need to know basis, just like CheckUsers, and data privacy laws like the EU's and California's means you cannot just do whatever random thing you want with the information you collect from users about them.--Jasper Deng(talk)21:56, 23 November 2024 (UTC)
So which part of the wmf:Privacy Policy would prohibit the WMF from developing an AI that looks at server logs to find socks? Do you want me to quote to you the portions that explicitly disclose that the WMF uses personal information to develop tools and improve security? Levivich (talk) 22:02, 23 November 2024 (UTC)
@Levivich: Did you read the part where I mentioned privacy laws? Also, in this industry no one is allowed unfettered usage of private data even internally; there are internal policies that govern this that are broadly similar to the privacy policy. It's one thing to test a proposed tool on an IP address like Special:Contribs/2001:db8::/32, but it's another to train an AI model on it. Arguably an equally big privacy concern is the usage of new data from new users after the model is trained and brought online. The foundation is already hiding IP addresses by default even for anonymous users soon, and they will not undermine that mission through a tool like this. Ultimately, the Board of Trustees has to assume legal responsibility and liability for such a thing; put yourself in their position and think of whether they'd like the liability of something like this.--Jasper Deng(talk)22:13, 23 November 2024 (UTC)
So can you quote a part of the privacy policy, or a part of privacy laws, or anything, that would prohibit feeding server logs into a "Cluebot-CU" to find socking?
Because I can quote the part of the wmf:Privacy Policy that allows it, and it's a lot:
We may use your public contributions, either aggregated with the public contributions of others or individually, to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ...
Because of how browsers work, we receive some information automatically when you visit the Wikimedia Sites ... This information includes the type of device you are using (possibly including unique device identification numbers, for some beta versions of our mobile applications), the type and version of your browser, your browser's language preference, the type and version of your device's operating system, in some cases the name of your internet service provider or mobile carrier, the website that referred you to the Wikimedia Sites, which pages you request and visit, and the date and time of each request you make to the Wikimedia Sites.
Put simply, we use this information to enhance your experience with Wikimedia Sites. For example, we use this information to administer the sites, provide greater security, and fight vandalism; optimize mobile applications, customize content and set language preferences, test features to see what works, and improve performance; understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites, and analyze trends. ...
We actively collect some types of information with a variety of commonly-used technologies. These generally include tracking pixels, JavaScript, and a variety of "locally stored data" technologies, such as cookies and local storage. ... Depending on which technology we use, locally stored data may include text, Personal Information (like your IP address), and information about your use of the Wikimedia Sites (like your username or the time of your visit). ... We use this information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. ...
We and our service providers use your information ... to create new features or data-related products for you or to learn more about how the Wikimedia Sites are used ... To fight spam, identity theft, malware and other kinds of abuse. ... To test features to see what works, understand how users interact with the Wikimedia Sites, track and study use of various features, gain understanding about the demographics of the different Wikimedia Sites and analyze trends. ...
When you visit any Wikimedia Site, we automatically receive the IP address of the device (or your proxy server) you are using to access the Internet, which could be used to infer your geographical location. ... We use this location information to make your experience with the Wikimedia Sites safer and better, to gain a greater understanding of user preferences and their interaction with the Wikimedia Sites, and to generally improve our services. For example, we use this information to provide greater security, optimize mobile applications, and learn how to expand and better support Wikimedia communities. ...
We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use, this Privacy Policy, or any Wikimedia Foundation or user community-based policies. ... We may also disclose your Personal Information if we reasonably believe it necessary to detect, prevent, or otherwise assess and address potential spam, malware, fraud, abuse, unlawful activity, and security or technical concerns. ... To facilitate their work, we give some developers limited access to systems that contain your Personal Information, but only as reasonably necessary for them to develop and contribute to the Wikimedia Sites. ...
Yeah that's a lot. Then there's this whole FAQ that says
It is important for us to be able to make sure everyone plays by the same rules, and sometimes that means we need to investigate and share specific users' information to ensure that they are.
For example, user information may be shared when a CheckUser is investigating abuse on a Project, such as suspected use of malicious "sockpuppets" (duplicate accounts), vandalism, harassment of other users, or disruptive behavior. If a user is found to be violating our Terms of Use or other relevant policy, the user's Personal Information may be released to a service provider, carrier, or other third-party entity, for example, to assist in the targeting of IP blocks or to launch a complaint to the relevant Internet Service Provider.
So using IP addresses, etc., to develop new tools, to test features, to fight violations of the Terms of Use, and disclosing that info to Checkusers... all explicitly permitted by the Privacy Policy. Levivich (talk) 22:22, 23 November 2024 (UTC)
@Levivich: "We, or particular users with certain administrative rights as described below, need to use and share your Personal Information if it is reasonably believed to be necessary to enforce or investigate potential violations of our Terms of Use" – "reasonably believed to be necessary" is not going to hold up in court when it's sweepingly applied to everyone. This doesn't even take into consideration the laws I mentioned, like GDPR. I'm not a lawyer, and I'm guessing neither are you. If you want to be the one assuming the legal liability for this, contact the board today and sign the contract. Even then they would probably not agree to such an arrangement. So you're preaching to the choir: only the foundation could even consider assuming this risk. Also, it's clear that you do not have a single idea of how developing something like this works if you think it can be done for $1 million. Something this complex has to be done right and tech salaries and computing resources are expensive.--Jasper Deng(talk)22:28, 23 November 2024 (UTC)
What I am suggesting does not involve sharing everyone's data with Checkusers. It's pretty obvious that looking at their own server logs is "necessary to enforce or investigate potential violations of our Terms of Use". Five people is how big the WMF's wmf:Machine Learning team is, @ $200k each, $1m/year covers it. Five people is enough for that team to improve ORES, so another five-person team dedicated to "ORES-CU" seems a reasonable place to start. They could double that, and still have like $180M left over. Levivich (talk) 22:40, 23 November 2024 (UTC)
@Levivich: Yeah no, lol. $200k each is not a very competitive total compensation, considering that that needs to include benefits, health insurance, etc. This doesn't include their manager or the hefty hardware required to run ML workflows. It doesn't include the legal support required given the data privacy law compliance needed. Capriciously looking at the logs does not count; accessing data of users the foundation cannot reasonably have said to be likely to cause abuse is not permissible. This all aside from the bias and other data quality issues at hand here. You can delude yourself all you want, but nature cannot be fooled. I'm finished arguing with you anyways, because this proposal is either way dead on arrival.--Jasper Deng(talk)23:45, 23 November 2024 (UTC)
As a statistician/data scientist, @Levivich is correct about the technical side of this—building an ML algorithm to detect sockpuppets would be pretty easy. Duplicate user algorithms like these are common across many websites. For a basic classification task like this (basically an ML 101 homework problem), I think $1 million is about right. As a bonus, the same tools could be used to identify and correct for possible canvasing or brigading, which behaves a lot like sockpuppetry from a statistical perspective. A similar algorithm is already used by Twitter's community notes feature.
IANAL, so I can't comment on the legal side of this, and I can't comment on whether that money would be better-spent elsewhere since I don't know what the WMF budget looks like. Overall though, the technical implementation wouldn't be a major hurdle. – Closed Limelike Curves (talk) 20:44, 24 November 2024 (UTC)
Third-party services like Sift.com provide this kind of algorithm-based account fraud protection as an alternative to building and maintaining internally. czar23:41, 24 November 2024 (UTC)
Building such a model is only a small part of a real production system. If this system is to operate on all account creations, it needs to be at least as reliable as the existing systems that handle account creations. As you probably know, data scientists developing such a model need to be supported by software engineers and site reliability engineers supporting the actual system. Then you have the problem of new sockers who are not on the list of sockmasters to check against. Non-English-language speakers often would be put at a disadvantage too. It's not as trivial as you make it out to be, thus I stand by my estimate.--Jasper Deng(talk)06:59, 25 November 2024 (UTC)
I don't think we need to spend more time speculating about a system that WMF Legal is extremely unlikely to accept. Even if they did, it wouldn't exist until several years from now. Instead, let's try to think of things that we can do ourselves, or with only a very little assistance. Small, lightweight projects with full community control can help us now, and if we prove that ____ works, the WMF might be willing to adopt and expand it later. WhatamIdoing (talk) 23:39, 25 November 2024 (UTC)
That's a mistake -- doing the same thing Misplaced Pages has been doing for 20+ years. The mistake is in leaving it to volunteers to catch sockpuppetry, rather than insisting that the WMF devote significant resources to it. And it's a mistake because the one thing we volunteers can't do, that the WMF can do, is comb through the server logs looking for patterns. Levivich (talk) 23:44, 25 November 2024 (UTC)
Not sure about the "building an ML algorithm to detect sockpuppets would be pretty easy" part, but I admire the optimism. It is certainly the case that it is possible, and people have done it with a surprising level of success a very long time ago in ML terms e.g. https://doi.org/10.1016/j.knosys.2018.03.002. These projects tend to rely on the category graph to distinguish sock and non-sock sets for training, the categorization of accounts as confirmed or suspected socks. However, the category graph is woefully incomplete i.e. there is information in the logs that is not reflected in the graph, so ensuring that all ban evasion accounts are properly categorized as such might help a bit. Sean.hoyland (talk) 03:58, 26 November 2024 (UTC)
Thankfully, we wouldn't have to build an ML algorithm, we can just use one of the existing ones. Some are even open source. Or WMF could use a third party service like the aforementioned sift.com. Levivich (talk) 16:17, 26 November 2024 (UTC)
Let me guess: Essentially, you would like their machine-learning team to use Sift's AI-Powered Fraud Protection, which from what I can glance, handles safeguarding subscriptions to defending digital content and in-app purchases and helps businesses reduce friction and stop sophisticated fraud attacks that gut growth, to provide the ability for us to automatically checkuser all active users? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:25, 26 November 2024 (UTC)
The WMF already has the ability to "automatically checkuser all users" (the verb "checkuser" just means "look at the server logs"), I'm suggesting they use it. And that they use it in a sophisticated way, employing (existing, open source or commercially available) AI/ML technologies, like the same kind we already use to automatically revert vandalism. Contrary to claims here, doing so would not be illegal or even expensive (comparatively, for the WMF). Levivich (talk) 16:40, 26 November 2024 (UTC)
So, in my attempt to get things set right and steer towards a consensus that is satisfactory, I sincerely follow-up: What lies beyond that in this vast, uncharted sea? And could this mean any more in the next 5 years? 2601AC47 (talk·contribs·my rights) Isn't a IP anon 16:49, 26 November 2024 (UTC)
So, @2601AC47, I think the answer to your question is "tell the WMF we really, really, really would like more attention to sockpuppetry and IP abuse from the ML team". -- asilvering (talk) 17:31, 26 November 2024 (UTC)
3 days! When I first posted my comment and some editors responded that I didn't know what I was talking about, it can't be done, it'd violate the privacy policy and privacy laws, WMF Legal would never allow it... I was wondering how long it would take before somebody pointed out that this thing that can't be done has already been done and has been under development for at least 7 years now.
Of course it's already under development, it's pretty obvious that the same Misplaced Pages that developed ClueBot, one of the world's earlier and more successful examples of ML applications, would try to employ ML to fight multiple-account abuse. I mean, I'm obviously not gonna be the first person to think of this "innovation"!
Unlike what is being proposed, SimilarEditors only works based on publicly available data (e.g. similarities in editing patterns), and not IP data. To quote the page Sean linked, in the model's current form, we are only considering public data, but most saliently private data such as IP addresses or user-agent information are features currently used by checkusers that could be later (carefully) incorporated into the models.So, not only the current model doesn't look at IP data, the research project also acknowledges that actually using such data should only be done in a "careful" way, because of those very same privacy policy issues quoted above.On the ML side, however, this does proves that it's being worked on, and I'm honestly not surprised at all that the WMF is working on machine learning-based tools to detect sockpuppets. Chaotic Enby (talk · contribs) 17:50, 26 November 2024 (UTC)
Right. We should ask WMF to do the later (carefully) incorporated into the models part (especially since it's now later). BTW, the SimilarUsers API already pulls IP and other metadata. SimilarExtensions (a tool that uses the API) doesn't release that information to CheckUsers, by design. And that's a good thing, we can't just release all IPs to CheckUsers, it does indeed have to be done carefully. But user metadata can be used. What I'm suggesting is that the WMF should proceed to develop these types of tools (including the careful use of user metadata). Levivich (talk) 17:57, 26 November 2024 (UTC)
Not really clear that they're pulling IP data from logged-in users. The relevant sections reads:
USER_METADATA (203MB): for every user in COEDIT_DATA, this contains basic metadata about them (total number of edits in data, total number of pages edited, user or IP, timestamp range of edits).
In a few years people might look back on these days when we only had to deal with simple devious primates employing deception as the halcyon days. Sean.hoyland (talk) 18:33, 26 November 2024 (UTC)
This may be surprising, but it turns out there's more than one person on Misplaced Pages, and many of us have different opinions on things. You're probably thinking of @Guy Macon's essay.
I disagree with his argument that the WMF is incompetent, but at the same time, smart thinking happens on the margin. Just because the WMF spent their first $20 million extremely well (on creating Misplaced Pages) doesn't mean giving them $200 million would make them 10× as good. Nobody here thinks the WMF budget should be cut to $0; there's just some of us who think it needs a haircut.
For me it comes down to, "if you don't donate to the WMF, what does that money go instead"? I'd rather you give that money to some other charity—feeding African children is more important than reskinning Misplaced Pages—but if you won't, I'd doubt giving it to the WMF is worse than whatever else you were going to spend it on. Whether we should cut back on ads depends on whether this money is coming out of donors' charity budgets or their regular budgets. – Closed Limelike Curves (talk) 03:10, 29 November 2024 (UTC)
I already struggle enough with prioritizing charities and whether which ones are ethical or not and how I should be spending every single penny I get on charities dealing with PIA and trans issues because those are the most oppressed groups in the world right now. The WMF is not helping people who are actively getting killed and having their rights taken away therefore they are not important. 2600:1700:69F1:1410:C812:78B7:C08A:5AA5 (talk) 03:15, 29 November 2024 (UTC)
So goes this whole discussion; but to give a slightly longer answer to the IP: We’re not telling them to get lost on a different path, we’re trying (despite everything) to establish relations, consensus and mutual trust. And hopefully long-term progress on key areas of contention. We don’t hate them, or else they’ll dismiss us completely. 2601AC47 (talk·contribs·my rights) Isn't a IP anon 03:44, 29 November 2024 (UTC)
Any such system would be subject to numerous biases or be easily defeatable. Such an automated anti-abuse system would have to be exclusively a foundation initiative as only they have the resources for such a monumental undertaking. It would need its own team of developers.--Jasper Deng(talk)18:57, 23 November 2024 (UTC)
Absolutely no chance that this would pass. WP:SNOW, even though there isn't a flood of opposes. There are two problems:
The existing CheckUser team barely has the bandwidth for the existing SPI load. Doing this on every single new user would be impractical and would enable WP:LTA's by diverting valuable CheckUser bandwidth.
Even if we had enough CheckUser's, this would be a severe privacy violation absolutely prohibited under the Foundation privacy policy.
The vast majority of vandals and other disruptive users don't need CU involvement to deal with. There's very little to be gained from this.--Jasper Deng(talk)18:36, 23 November 2024 (UTC)
It is perhaps an interesting conversation to have but I have to agree that it is unworkable, and directly contrary to foundation-level policy which we cannot make a local exemption to. En.wp, I believe, already has the largest CU team of any WMF project, but we would need hundreds more people on that team to handle something like this. In the last round of appointments, the committee approved exactly one checkuser, and that one was a returning former mamber of the team. And there is the very real risk that if we appointed a whole bunch of new CUs, some of them would abuse the tool. Just Step Sideways18:55, 23 November 2024 (UTC)
And its worth pointing out that the Committee approving too few volunteers for Checkuser (regardless of whether you think they are or aren't) is not a significant part of this issue. There simply are not tens of people who are putting themselves forward for consideration as CUs. Since 2016 54 applications (an average of per year) have been put forward for consideration by Functionaries (the highest was 9, the lowest was 2). Note this is total applications not applicants (more than one person has applied multiple times), and is not limited to candidates who had a realistic chance of being appointed. Thryduulf (talk) 20:40, 23 November 2024 (UTC)
The dearth of candidates has for sure been an ongoing thing, it's worth reminding admins that they don't have to wait for the committee to call for candidates, you can put your name forward at any time by emailing the committee. Just Step Sideways23:48, 24 November 2024 (UTC)
Generally, I tend to get the impression from those who have checkuser rights that CU should be done as a last resort, and other, less invasive methods are preferred, and it would seem that indiscriminate use of it would be a bad idea, so I would have some major misgivings about this proposal. And given the ANI case, the less user information that we retain, the better (which is also probably why temporary accounts are a necessary and prudent idea despite other potential drawbacks). Abzeronow (talk) 03:56, 23 November 2024 (UTC)
Oppose. A lot has already been written on the unsustainable workload for the CU team this would create and the amount of collateral damage; I'll add in the fact that our most notorious sockmasters in areas like PIA already use highly sophisticated methods to evade CU detection, and based on what I've seen at the relevant SPIs most of the blocks in these cases are made with more weight given to the behaviour, and even then only after lengthy deliberations on the matter. These sort of sockmasters seem to have been in the OP's mind when the request was made, and I do not see automated CU being of any more use than current techniques against such dedicated sockmasters. And, has been mentioned before, most cases of sockpuppetry (such as run-of-the-mill vandals and trolls using throwaway accounts for abuse) don't need CU anyways. JavaHurricane08:17, 24 November 2024 (UTC)
These are, unfortunately, fair points about the limits of CU and the many experienced and dedicated ban evading actors in PIA. CU information retention policy is also a complicating factor. Sean.hoyland (talk) 08:28, 24 November 2024 (UTC)
As I said in my original post, recidivist socks often get better at covering their "tells" each time making behavioural detection increasingly difficult and meaning the entire burden falls on the honest user to convince an Admin to take an SPI case seriously with scarce evidence. After many years I'm tired of defending various pages from sock POV edits and if WMF won't make life easier then increasingly I just won't bother, I'm sure plenty of other users feel the same way. Mztourist (talk) 05:45, 26 November 2024 (UTC)
Honestly, the main function of that sort of thing seems to be compiling data that is already available on XTools and various editor interaction analyzers, and then presenting it nicely and neatly. I think that such a page could be useful as a sanity check, and it might even be worth having that sort of thing as a standalone toolforge app, but I don't really see why the WMF would make that particular extension a high priority. — Red-tailed hawk(nest)17:58, 26 November 2024 (UTC)
Well, it doesn't have to be that particular extension, but it seems to me that the entire "idea" has been stalled, unless they're working on another tool that I'm unaware of (very possible). (Or, it could be because of recent changes in domestic and int'l privacy laws that derailed their previous development advances, or it could be because of advancements in ML elsewhere making in-house development no longer practical.)
As to why the WMF would make this sort of problem a high priority, I'd say because the spread of misinformation on Misplaced Pages by sockpuppets is a big problem. Even without getting into the use of user metadata, just look at recent SPIs I filed, like Misplaced Pages:Sockpuppet investigations/Icewhiz/Archive#27 August 2024 and Misplaced Pages:Sockpuppet investigations/Icewhiz/Archive#09 October 2024. That involved no private data at all, but a computer could have done automatically, in seconds, what took me hours to do manually, and those socks could have been uncovered before they made thousands and thousands of edits spreading misinformation. If the computer looked at private data as well as public data, it would be even more effective (and would save CUs time as well). Seems to me to be a worthy expenditure of 0.5% or 1% of the WMF's annual budget. Levivich (talk) 18:09, 26 November 2024 (UTC)
This looks really interesting. I don't really know how extensions are rolled out to individual wikis - can anyone with knowledge about that summarise if having this tool turned on (for check users/relevant admins) for en.wp is feasible? Do we need a RFC, or is this a "maybe wait several years for a phab ticket" situation? BugGhost🦗👻18:09, 26 November 2024 (UTC)
I find it amusing that ~4 separate users above are arguing that automatic identification of sockpuppets is impossible, impractical, and the WMF would never do it—and meanwhile, the WMF is already doing it. – Closed Limelike Curves (talk) 19:29, 27 November 2024 (UTC)
I think what's happening is that people are having two simultaneous discussions – automatic identification of sockpuppets is already being done, but what people say "the WMF would never do" is using private data (e.g. IP addresses) to identify them. Which adds another level of (ethical, if not legal) complications compared to what SimilarEditors is doing (only processing data everyone can access, but in an automated way). Chaotic Enby (talk · contribs) 07:59, 28 November 2024 (UTC)
"automatic identification of sockpuppets is already being done" is probably an overstatement, but I agree that there may be a potential legal and ethical minefield between the Similarusers service that uses public information available to anyone from the databases after redaction of private information (i.e. course-grained sampling of revision timestamps combined with an attempt to quantify page intersection data), and a service that has access to the private information associated with a registered account name. Sean.hoyland (talk) 11:15, 28 November 2024 (UTC)
Yes, automatic identification of (these) sockpuppets is impossible. There are many reasons for this, but the simplest one is this: These types of tools require hundreds of edits – at minimum – to return any viable data, and the sort of sockmasters who get accounts up to that volume of edits know how to evade detection by tools that analyse public information. The markers would likely indicate people from similar countries – naturally, two Cypriots would be interested in Category:Cyprus and over time similar hour and day overlaps will emerge, but what's to let you know whether these are actual socks when they're evading technical analysis? You're back to square one. There are other tools such as mediawikiwiki:User:Ladsgroup/masz which I consider equally circumstantial; an analysis of myself returns a high likelihood of me being other administrators and arbitrators, while analysing an alleged sock currently at SPI returns the filer as the third most likely sockmaster. This is not commentary on the tools themselves, but rather simply the way things are. DatGuyContribs17:42, 28 November 2024 (UTC)
Idk, the half dozen ARBPIA socks I recently reported at SPI were obvious af to me, as are several others I haven't reported yet. That may be because that particular sockfarm is easy to spot by its POV pushing and a few other habits; though I bet in other topic areas it's the same. WP:ARBECR helps because it forces the socks to make 500 edits minimum before they can start POV pushing, but still we have to let them edit for a while post-XC just to generate enough diffs to support an SPI filing. Software that combines tools like Masz and SimilarEditor, and does other kinds of similar analysis, could significantly reduce the amount of editor time required to identify and report them. Levivich (talk) 18:02, 28 November 2024 (UTC)
I think it is possible, studies have demonstrated that it is possible, but it is true that having a sufficient number of samples is critical. Samples can be aggregated in some cases. There are several other important factors too. I have tried some techniques, and sometimes they work, or let's say they can sometimes produce results consistent with SPI results, better than random, but with plenty of false positives. It is also true that there are a number of detection countermeasures (that I won't describe) that are already employed by some bad actors that make detection harder. But I think the objective should be modest, to just move a bit in the right direction by detecting more ban evading accounts than are currently detected, or at least to find ways to reduce the size of the search space by providing ban evasion candidates. Taking the human out of the detection loop might take a while. Sean.hoyland (talk) 18:39, 28 November 2024 (UTC)
If you mean it's never going to be possible to catch some sockpuppets—the best-hidden, cleverest, etc. ones—you're completely correct. But I'm guessing we could cut the amount of time SPI has to spend dramatically with just some basic checks. – Closed Limelike Curves (talk) 02:27, 29 November 2024 (UTC)
I disagree. Empirically, the vast majority of time spent at SPI is not on finding possible socks, nor is it using the CheckUser tool on them, but rather it's the CU completed cases (of which there are currently 14 and I should probably stop slacking and get onto some) with non-definitive technical results waiting on an administrator to make the final determination on whether they're socks or not. Extension:SimilarUsers would concentrate various information that already exists (EIA, RoySmith's SPI tools) in one place, but I wouldn't say the accessibility of these tools is a cause of SPI backlog. An AI analysis tool to give an accurate magic number for likelihood? I'm anything but a Luddite, but still believe that's wishful thinking. DatGuyContribs03:02, 29 November 2024 (UTC)
Something seems better than nothing in this context doesn't it? EIA and the Similarusers service don't provide an estimate of the significance of page intersections. An intersection on a page with few revisions or few unique actors or few pageviews etc. is very different from a page intersection on the Donald Trump page. That kind of information is probably something that could sometimes help, even just to evaluate the importance of intersection evidence presented at SPIs. It seems to me that any kind of assistance could help. And another thing about the number of edits is that too many samples can also present challenges related to noise, with signals getting smeared out, although the type of noise in a user's data can itself be a characteristic signal in some cases it seems. And if there are too few samples, you can generate synthetic samples based on the actual samples and inject them into spaces. Search strategy matters a lot. The space of everyone vs everyone is vast, so good luck finding potential matches in that space without a lot of compute, especially for diffs. But many socks inhabit relatively small subspaces of Misplaced Pages, at least in the 20%-ish of time (on average in PIA) they edit(war)/POV-push etc. in their topic of interest. So, choosing the candidate search space and search strategy wisely can make the problem much more tractable for a given topic area/subspace. Targeted fishing by picking a potential sock and looking for potential matches (the strategy used by the Similarusers service and CU I guess) is obviously a very different challenge than large-scale industrial fishing for socks in general. Sean.hoyland (talk) 04:08, 29 November 2024 (UTC)
And to continue the whining about existing tools, EIA and the Similarusers service use a suboptimal strategy in my view. If the objective is page intersection information for a potential sock against a sockmaster, and a ban evasion source has employed n identified actors so far e.g. almost 50 accounts for Icewhiz, the source's revision data should be aggregated for the intersection. This is not difficult to do using the category graph and the logs. Sean.hoyland (talk) 04:25, 29 November 2024 (UTC)
There is so much more that could be done with the software. EIA gives you page overlaps (and isn't 100% accurate at it), but it doesn't tell you:
how many times the accounts made the same edits (tag team edit warring)
how many times they voted in the same formal discussions (RfC, AfD, RM, etc) and whether they voted the same way or different (vote stacking)
how many times they use the same language and whether they use unique phraseology
whether they edit at the same times of day
whether they edit on the same days
whether account creation dates (or start-of-regular-editing dates) line up with when other socks were blocked
whether they changed focus after reaching XC and to what extent (useful in any ARBECR area)
whether they "gamed" or "rushed" to XC (same)
All of this (and more) would be useful to see in a combined way, like a dashboard. It might make sense to restrict access to such compilations of data to CUs, and the software could also throw in metadata or subscriber info in there, too (or not), and it doesn't have to reduce it all into a single score like ORES, but just having this info compiled in one place would save editors the time of having to compile it manually. If the software auto-swept logs for this info and alerted humans to any "high scores" (however defined, eg "matches across multiple criteria"), it would probably not only reduce editor time but also increase sock discovery. Levivich (talk) 04:53, 29 November 2024 (UTC)
This is like one of my favorite strategies for meetings. Propose multiple things, many of which are technically challenging, then just walk out of the meeting.
The 'how many times the accounts made the same edits' is probably do-able because you can connect reverted revisions to the revisions that reverted them using json data in the database populated as part of the tagging system, look at the target state reverted to and whether the revision was an exact revert. ...or maybe not without computing diffs, having just looked at an article with a history of edit warring. Sean.hoyland (talk) 07:43, 29 November 2024 (UTC)
I agree with Levivich that automated, privacy-protecting sock-detection is not a pipe dream. I proposed a system something like this in 2018, see also here, and more recently here. However, it definitely requires a bit of software development and testing. It also requires the community and the foundation devs or product folks to prioritize the idea. Andre🚐02:27, 10 December 2024 (UTC)
Comment. For some time I have vehemnently suspected that this site is crawling with massive numbers of sockpuppets, that the community seems to be unable or unwilling to recognise probable sockpuppets for what they are, and it is not feasible to send them to SPI one at a time. I see a large number of accounts that are sleepers, or that have low edit counts, trying to do things that are controversial or otherwise suspicious. I see them showing up at discussions in large numbers and in quick succession, and offering !votes consist of interpretations of our policies and guidelines that may not reflect consensus, or other statements that may not be factually accurate.
I think the solution is simple: when closing community discussions, admins should look at the edit count of each !voter when determining how much weight to give his !vote. The lower the edit count, the greater the level of sleeper behaviour, and the more controversial the subject of the discussion is amongst the community, the less weight should be given to !vote.
For example, if an account with less than one thousand edits !votes in a discussion about 16th century Tibetan manuscripts, we may well be able to trust that !vote, because the community does not care about such manuscripts. But if the same account !votes on anything connected with "databases" or "lugstubs", we should probably give that !vote very little weight, because that was the subject of a massive dispute amongst the community, and any discussion on that subject is not particulary unlikely to be crawling with socks on both sides. The feeling is that, if you want to be taken seriously in such a controversial discussion, you need to make enough edits to prove that you are a real person, and not a sock. James500 (talk) 15:22, 12 December 2024 (UTC)
The site presumably has a large number of unidentified sockpuppets. As for the identified ban evading accounts, accounts categorized or logged as socks, if you look at 2 million randomly selected articles for the 2023-10-07 to 2024-10-06 year, just under 2% of the revisions are by ban evading actors blocked for sockpuppetry (211,546 revisions out of 10,732,361). A problem with making weight dependent on edit count is that the edit count number does not tell you anything about the probability that an account is a sock. Some people use hundreds of disposable accounts, making just a few edits with each account. Others stick around and make thousands of edits before they are detected. Also, Misplaced Pages provides plenty of tools that people can use to rapidly increase their edit count. Sean.hoyland (talk) 16:12, 12 December 2024 (UTC)
I strongly oppose any idea of mass-CUing any group of users, and I'm pretty sure the WMF does too. This isn't the right way to fight sockpuppets. QuicoleJR (talk) 14:35, 15 December 2024 (UTC)
Can I ask why? Is it a privacy-based concern? IPs are automatically collected and stored for 90 days, and maybe for years in the backups, regardless of CUs. That's a 90 day window that a machine could use to do something with them without anyone running a CU and without anyone having to see what the machine sees. Sean.hoyland (talk) 15:05, 15 December 2024 (UTC)
Primarily privacy concerns, as well as concerns about false positives. A lot of people here probably share an IP with other editors without even knowing it. I also would like to maintain my personal privacy, and I know many other editors would too. There are other methods of fighting sockpuppets that don't have as much collateral damage, and we should pursue those instead. QuicoleJR (talk) 15:16, 17 December 2024 (UTC)
Also, it wouldn't even work on some sockpuppets, because IP info is only retained for 90 days, so a blocked editor could just wait out the 90 days and then return with a new account. QuicoleJR (talk) 15:19, 17 December 2024 (UTC)
@Levivich—one situation where I think we could pull a lot of data, and probably detect tons of sockpuppets, is !votes like RfAs and RfCs. Those have a lot of data, in addition to a very strong incentive for socking—you'd expect to see a bimodal distribution where most accounts have moderately-correlated views, but a handful have extremely strong-correlations (always !voting the same way), more than could plausibly happen by chance or by overlapping views. For accounts in the latter group, we'd have strong grounds to suspect collusion/canvassing or socking.
RfAs are already in a very nice machine-readable format. RfCs aren't, but most could easily be made machine-readable (by adopting a few standardized templates). We could also build a tool for semi-automated recoding of old RfCs to get more data. – Closed Limelike Curves (talk) 18:56, 16 December 2024 (UTC)
Would that data help with the general problem? If there are a lot of socks on an RfA, I'd expect that to be picked up by editors. Those are very well-attended. The same may apply to many RfCs. Perhaps the less well-attended ones might be affected, but the main challenge is article edits, which will not be similarly structured. CMD (talk) 19:13, 16 December 2024 (UTC)
Would that data help with the general problem? If there are a lot of socks on an RfA, I'd expect that to be picked up by editors.
Given we've had situations of sockpuppets being made admins themselves, I'm not too sure of this myself. If someone did create a bunch of socks, as some people have alleged in this thread, it'd be weird of them not to use those socks to influence policy decisions. I'm pretty skeptical, but I do think investigating would be a good idea (if nothing else because of how important it is—even the possibility of substantial RfA/RfC manipulation is quite bad, because it undermines the whole idea of consensus). – Closed Limelike Curves (talk) 21:04, 16 December 2024 (UTC)
I think we've put the cart before the horse here a bit. While we've established it's possible to detect most sockpuppets automatically—and the WMF is already working on it—it's not clear what this would actually achieve, because having multiple accounts isn't against the rules. I think we'd need to establish a set of easy-to-enforce boundaries for people using multiple accounts. My proposal is to keep it simple—two accounts controlled by the same person can't edit the same page (or participate in the same discussion) without disclosing they're the same editor.– Closed Limelike Curves (talk) 04:41, 14 December 2024 (UTC)
And as there are multiple legitimate ways to disclose, not all of which are machine readable, any automatically generated list is going to need human review. Thryduulf (talk) 10:13, 14 December 2024 (UTC)
Yes, that's definitely the case, an automatic sock detection should probably never be an autoblock, or at least not unless there is a good reason in that specific circumstance, like a well-trained filter for a specific LTA. Having the output of automatic sock detection should still be restricted to CU/OS or another limited user group who can be trusted to treat possible user-privacy-related issues with discretion, and have gone through the appropriate legal rigmarole. There could also be some false positives or unusual situations when piloting a program like this. For example, I've seen dynamic IPs get assigned to someone else after a while, which is unlikely but not impossible depending on how an ISP implements DHCP, though I guess collisions become less common with IPV6. Or if the fingerprinting is implemented with a lot of datapoints to reduce the likelihood of false positives. Andre🚐10:31, 14 December 2024 (UTC)
I think we are probably years away from being able to rely on autonomous agents to detect and block socks without a human in the loop. For now, people need as much help as they can get to identify ban evasion candidates. Sean.hoyland (talk) 10:51, 14 December 2024 (UTC)
or at least not unless there is a good reason in that specific circumstance,
Yep, basically I'm saying we need to define "good reason". The obvious situation is automatically blocking socks of blocked accounts. I also think we should just automatically prevent detected socks from editing the same page (ideally make it impossible, to keep it from being done accidentally). – Closed Limelike Curves (talk) 17:29, 14 December 2024 (UTC)
Requiring registration for editing
Note: This section was split off from "CheckUser for all new users" (permalink) and the "parenthetical comment" referred to below is: (Also, email-required registration and get rid of IP editing.)—03:49, 26 November 2024 (UTC)
@Levivich, about your parenthetical comment on requiring registration:
Part of the eternally unsolvable problem is that new editors are frankly bad at it. I can give examples from my own editing: Create an article citing a personal blog post as the main source? Check. Merge two articles that were actually different subjects? Been there, done that, got the revert. Misunderstand and mangle wikitext? More times than I can count. And that's after I created my account. Like about half of experienced editors, I edited as an IP first, fixing a typo here or reverting some vandalism there.
But if we don't persist through these early problems, we don't get experienced editors. And if we don't get experienced editors, Misplaced Pages will die.
Requiring registration ("get rid of IP editing") shrinks the number of people who edit. The Portuguese Misplaced Pages banned IPs only from the mainspace three years ago. Have a look at the trend. After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. The number of contributions has dropped, too. They went from 160K to 210K edits per month down to 140K most months.
Some of the experienced editors have said that they like this. No IPs means less impulsive vandalism, and the talk pages are stable if you want to talk to the editor. Fewer newbies means I don't "have to" clean up after so many mistake-makers! Fewer editors, and especially fewer inexperienced editors, is more convenient – in the short term. But I wonder whether they're going to feel the same way a decade from now, when their community keeps shrinking, and they start wondering when they will lose critical mass.
The same thing happens in the real world, by the way. Businesses want to hire someone with experience. They don't want to train the helpless newbie. And then after years of everybody deciding that training entry-level workers is Somebody else's problem, they all look around and say: Where are all the workers that I need? Why didn't someone else train the next generation while I was busy taking the easy path?
In case you're curious, there is a Misplaced Pages that puts all of the IP and newbie edits under "PC" type restrictions. Nobody can see the edits until they've been approved by an experienced editor. The rate of vandalism visible to ordinary readers is low. Experienced editors love the level of control they have. Have a look at what's happened to the size of their community during the last decade. Is that what you want to see here? If so, we know how to make that happen. The path to that destination even looks broad, easy, and paved with all kinds of good intentions. WhatamIdoing (talk) 04:32, 23 November 2024 (UTC)
Size isn't everything... what happened to their output--the quality of their encyclopedias--after they made those changes? Levivich (talk) 05:24, 23 November 2024 (UTC)
Well, I can tell you objectively that the number of edits declined, but "quality" is in the eye of the beholder. I understand that the latter community has the lowest use of inline citations of any mid-size or larger Misplaced Pages. What's now yesterday's TFA there wouldn't even be rated B-class here due to whole sections not having any ref tags. In terms of citation density, their FA standard is currently where ours was >15 years ago.
But I think you have missed the point. Even if the quality has gone up according to the measure of your choice, if the number of contributors is steadily trending in the direction of zero, what will the quality be when something close to zero is reached? That community has almost halved in the last decade. How many articles are out of date, or missing, because there simply aren't enough people to write them? A decade from now, with half as many editors again, how much worse will the articles be? We're none of us idiots here. We can see the trend. We know that people die. You have doubtless seen this famous line:
All men are mortal. Socrates is a man. Therefore, Socrates is mortal.
I say:
All Misplaced Pages editors are mortal. Dead editors do not maintain or improve Misplaced Pages articles. Therefore, maintaining and improving Misplaced Pages requires editors who are not dead.
Trends don't last forever. Enwiki's active user count decreased from its peak over a few years, then flattened out for over a decade. The quality increased over that period of time (by any measure). Just because these other projects have shed users doesn't mean they're doomed to have zero users at some point in the future. And I think there's too many variables to know how much any particular change made on a project affects its overall user count, nevermind the quality of its output. Levivich (talk) 06:28, 23 November 2024 (UTC)
If the graph to the right accurately reflects the age distribution of Misplaced Pages users, then a large chunk of the user base will die off within the next decade or two. Not to be dramatic, but I agree that requiring registration to edit, which will discourage readers from editing in the first place, will hasten the project's decline.... Some1 (talk) 14:40, 23 November 2024 (UTC)
There are significantly more barriers to entry than there were 20 years ago, and over that time the age profile has increased (quite significantly iirc). Adding more barriers to entry is not the way to solve the issued caused by barriers to entry. Thryduulf (talk) 15:50, 23 November 2024 (UTC)
Or you could say it's about a user called PaperQA2 that writes Misplaced Pages articles significantly more accurate than articles written by other users. Sean.hoyland (talk) 16:55, 23 November 2024 (UTC)
No, it is very clearly about a language model. As far as I know, PaperQA2, or WikiCrow (the generative model using PaperQA2 for question answering), has not actually been making any edits on Misplaced Pages itself. Chaotic Enby (talk · contribs) 16:58, 23 November 2024 (UTC)
That is true. It is not making any edits on Misplaced Pages itself. There is a barrier. But my point is that in the future that barrier may not be there. There may be users like PaperQA2 writing articles better than other users and the demographics will have changed to include new kinds of users, much younger than us. Sean.hoyland (talk) 17:33, 23 November 2024 (UTC)
In re "What do you suppose that chart looked like 20 years ago": I believe that the numbers, very roughly, are that the community has gotten about 10 years older, on average, than it was 20 years ago. That is, we are bringing in some younger people, but not at a rate that would allow us to maintain the original age distribution. (Whether the original age distribution was a good thing is a separate consideration.) WhatamIdoing (talk) 06:06, 24 November 2024 (UTC)
I like looking at the en.wikipedia user retention graph hosted on Toolforge (for anyone who might go looking for it later, there's a link to it at Misplaced Pages:WikiProject Editor Retention § Resources). It shows histograms of how many editors have edited in each month, grouped by all the editors who started editing in the same month. The data is noisy, but it does seem to show an increase in editing tenure since 2020 (when the pursuit of a lot of solo hobbies picked up, of course). Prior to that, there does seem to be a bit of slow growth in tenure length since the lowest point around 2013. isaacl (talk) 17:18, 23 November 2024 (UTC)
I'd say that the story there is: Something amazing happened in 2006. Ours (since both of us registered our accounts that year) was the year from which people stuck around. I think that would be just about the time that the wall o' automated rejection really got going. There was some UPE-type commercial pressure, but it didn't feel unmanageable. It looks like an inflection point in retention. WhatamIdoing (talk) 06:12, 24 November 2024 (UTC)
I don't think something particularly amazing happened in 2006. I think the rapid growth in articles starting in 2004 attracted a large land rush of editors as Misplaced Pages became established as a top search result. The cohort of editors at that time had the opportunity to cover a lot of topics for the first time on Misplaced Pages, requiring a lot of co-ordination, which created bonds between editors. As topic coverage grew, there were fewer articles that could be more readily created by generalists, the land rush subsided, and there was less motivation for new editors to persist in editing. Boom-bust cycles are common for a lot of popular things, particularly in tech where newer, shinier things launch all the time. isaacl (talk) 19:07, 24 November 2024 (UTC)
Ah yes, that glorious time when we gained an article on every Pokemon character and, it seems, every actor who was ever credited in a porn movie. Unfortunately, many of the editors I bonded with then are no longer active. Some are dead, some finished school, some presumably burned out, at least one went into the ministry. Donald Albury23:49, 26 November 2024 (UTC)
Have a look at what happened to the size of their community.—I'm gonna be honest: eyeballing it, I don't actually see much (if any) difference with enwiki's activity. "Look at this graph" only convinces people when the dataset passes the interocular trauma test (e.g. the hockey stick).
On the other hand, if there's a dataset of "when did $LANGUAGEwiki adopt universal pending changes protections", we could settle this argument once and for all using a real statistical model that can deliver precise effect sizes on activity. Maybe then we can all finally drop the stick. – Closed Limelike Curves (talk) 18:08, 26 November 2024 (UTC)
This particular idea will not pass, but the binary developing in the discussion is depressing. A bargain where we allow IPs to edit (or unregistered users generally when IPs are masked), and therefore will sit on our hands when dealing with abuse and even harassment is a grim one. Any steps taken to curtail the second half of that bargain would make the first half stronger, and I am generally glad to see thoughts about it, even if they end up being impractical. CMD (talk) 02:13, 24 November 2024 (UTC)
I don't want us to sit on our hands when we see abuse and harassment. I think our toolset is about 20 years out of date, and I believe there are things we could do that will help (e.g., mw:Temporary accounts, cross-wiki checkuser tools for Stewards, detecting and responding to a little bit more information about devices/settings ). WhatamIdoing (talk) 06:39, 24 November 2024 (UTC)
Temporary accounts will help with the casual vandalism, but they’re not going to help with abuse and harassment. If it limits the ability to see ranges, it will make issues slightly worse. CMD (talk) 07:13, 24 November 2024 (UTC)
I'm not sure what the current story is there, but when I talked to the team last (i.e., in mid-2023), we were talking about the value of a tool that would do range-related work. For various reasons, this would probably be Toolforge instead of MediaWiki, and it would probably be restricted (e.g., to admins, or to a suitable group chosen by each community), but the goal was to make it require less manual work, particularly for cross-wiki abuse, and to be able to aggregate some information without requiring direct disclosure of some PII. WhatamIdoing (talk) 23:56, 25 November 2024 (UTC)
Oh look, misleading statistics! "The Portuguese Misplaced Pages banned IPs only from the mainspace three years ago. Have a look at the trend. After the ban went into effect, they had 10K or 11K registered editors each month. It's since dropped to 8K. " Of course you have a spike in new registrations soon after you stop allowing IP edits, and you can't sustain that spike. That is not evidence of anything. It would have been more honest and illustrative to show the graph before and after the policy change, not only afterwards, e.g. thus. Oh look, banning IP editing has resulted in on average some 50% more registered editors than before the ban. Number of active editors is up 50% as well. The number of new pages has stayed the same. Number of edits is down, yes, but how much of this is due to less vandalism / vandalism reverts? A lot apparently, as the count of user edits has stayed about the same. Basically, from those statistics, used properly, it is impossible to detect any issues with the Portuguese Misplaced Pages due to the banning of IP editing. Fram (talk) 08:55, 26 November 2024 (UTC)
@Jo-Jo Eumerus:, the dashboard is here although it looks like they stopped reporting the data in late 2021. If you take "Number of reverts" as a proxy for vandalism, you can see that the block shifted the number of reverts from a higher equilibrium to a lower one, while overall non-reverted edits does not seem to have changed significantly during that period. CMD (talk) 11:44, 28 November 2024 (UTC)
I agree that one should expect a spike in registration. (In fact, I have suggested a strictly temporary requirement to register – a few hours, even – to push some of our regular IPs into creating accounts.) But once you look past that initial spike, the trend is downward. WhatamIdoing (talk) 05:32, 29 November 2024 (UTC)
But once you look past that initial spike, the trend is downward.
I still don't see any evidence that this downward trend is unusual. Apparently the WMF did an analysis of ptwiki and didn't find evidence of a drop in activity. Net edits (non-revert edits standing for at least 48 hours) increased by 5.7%, although edits across other wikis increased slightly more. The impression I get is any effects are small either way—the gains from freeing up anti-vandalism resources basically offset the cost of some IP editors not signing up.
TBH this lines up with what I'd expect. Very few people I talk to cite issues like "creating an account" as a major barrier to editing Misplaced Pages. The most common barrier I've heard from people who tried editing and gave it up is "Oh, I tried, but then some random admin reverted me, linked me to MOS:OBSCURE BULLSHIT, and told me to go fuck myself but with less expletives." – Closed Limelike Curves (talk) 07:32, 29 November 2024 (UTC)
But once you look past that initial spike, the trend is downward.
Not really obvious, and not more or even less so in Portuguese wikipedia than in e.g. Enwiki, FRwiki, NLwiki, ESwiki, Svwiki... So, once again, these statistics show no issue at all with disabling IP editing on Portuguese Misplaced Pages. Fram (talk) 10:38, 29 November 2024 (UTC)
Aside from the obvious loss of good 'IP' editors, I think there's a risk of unintended consequences from 'stopping vandalism' at all; 'vandalism' and 'disruptive editing' from IP editors (or others) isn't necessarily a bad thing, long term.
Even the worst disruptive editors 'stir the pot' of articles, bringing attention to articles that need it, and otherwise would have gone unnoticed. As someone who mostly just trawls through recent changes, I can remember dozens of times when where an IP, or brand new, user comes along and breaks an article entirely, but their edit leads inexorably to the article being improved. Sometimes there is a glimmer of a good point in their edit, that I was able to express better than they were, maybe in a more balanced or neutral way. Sometimes they make an entirely inappropriate edit, but it brings the article to the top of the list, and upon reading it I notice a number of other, previously missed, problems in the article. Sometimes, having reverted a disruptive change, I just go and add some sources or fix a few typos in the article before I go on my merry way.
You might think 'Ah, but 'Random article' would let you find those problems too. BUT random article' is, well, random. IP editors are more targeted, and that someone felt the need to disparage a certain person's mother in fact brings attention to an article about someone who is, unbeknownst to us editors, particularly contentious in the world of Czech Jazz Flautists so there is a lot there to fix. By stopping people making these edits, we risk a larger proportion of articles becoming an entirely stagnant. JeffUK15:00, 9 December 2024 (UTC)
I feel that the glassmaker has been too clever by half here. "Ahh, but vandalism of articles stimulates improvements to those articles." If the analysis ends there, I have no objections. But if, on the other hand, you come to the conclusion that it is a good thing to vandalize articles, that it causes information to circulate, and that the encouragement of editing in general will be the result of it, you will oblige me to call out, "Halt! Your theory is confined to that which is seen; it takes no account of that which is not seen." If I were to pay a thousand people to vandalize Misplaced Pages articles full-time, bringing more attention to them, would I be a hero or villain? If vandalism is good, why do we ban vandals instead of thanking them? Because vandalism is bad—every hour spent cleaning up after a vandal is one not spent writing a new article or improving an existing one.
On targeting: vandals are more targeted than a "random article", but are far more destructive than basic tools for prioritizing content, and less effective than even very basic prioritization tools like sorting articles by total views. – Closed Limelike Curves (talk) 19:11, 9 December 2024 (UTC)
I mean, I only said Vandalism "isn't necessarily a bad thing, long term", I don't think it's completely good, but maybe I should have added 'in small doses', fixing vandalism takes one or two clicks of the mouse in most cases and it seems, based entirely on my anecdotal experience, to sometimes have surprisingly good consequences; intuitively, you wouldn't prescribe vandalism, but these things have a way of finding a natural balance, and what's intuitive isn't necessarily what's right. One wouldn't prescribe dropping asteroids on the planet you're trying to foster life upon after you finally got it going, but we can be pretty happy that it happened! - And 'vandalism' is the very worst of what unregistered (and registered!) users get up to, there are many, many more unambiguously positive contributors than unambiguously malicious. JeffUK20:03, 9 December 2024 (UTC)
intuitively, you wouldn't prescribe vandalism
Right, and I think this is mainly the intuition I wanted to invoke here—"more vandalism would be good" a bit too galaxy-brained of a take for me to find it compelling without some strong empirical evidence to back it up.
Although TBH, I don't see this as a big deal either way. We already have to review and check IP edits for vandalism; the only difference is whether that content is displayed while we wait for review (with pending changes, the edit is hidden until it's reviewed; without it, the edit is visible until someone reviews and reverts it). This is unlikely to substantially affect contributions (the only difference on the IP's end is they have to wait a bit for their edit to show up) or vandalism (since we already de facto review IP edits). – Closed Limelike Curves (talk) 04:29, 14 December 2024 (UTC)
Point 1 of Procedural removal for inactive administrators which currently reads "Has made neither edits nor administrative actions for at least a 12-month period" should be replaced with "Has made no administrative actions for at least a 12-month period". The current wording of 1. means that an Admin who takes no admin actions keeps the tools provided they make at least a few edits every year, which really isn't the point. The whole purpose of adminship is to protect and advance the project. If an admin isn't using the tools then they don't need to have them. Mztourist (talk) 07:47, 4 December 2024 (UTC)
Oppose - this would create an unnecessary barrier to admins who, for real life reasons, have limited engagement for a bit. Asking the tools back at BN can feel like a faff. Plus, logged admin activity is a poor guide to actual admin activity. In some areas, maybe half of actions aren't logged? —Femke 🐦 (talk) 19:17, 4 December 2024 (UTC)
Oppose. First, not all admin actions are logged as such. One example which immediately comes to mind is declining an unblock request. In the logs, that's just a normal edit, but it's one only admins are permitted to make. That aside, if someone has remained at least somewhat engaged with the project, they're showing they're still interested in returning to more activity one day, even if real-life commitments prevent them from it right now. We all have things come up that take away our available time for Misplaced Pages from time to time, and that's just part of life. Say, for example, someone is currently engaged in a PhD program, which is a tremendously time-consuming activity, but they still make an edit here or there when they can snatch a spare moment. Do we really want to discourage that person from coming back around once they've completed it? Seraphimblade21:21, 4 December 2024 (UTC)
We could declare specific types of edits which count as admin actions despite being mere edits. It should be fairly simple to write a bot which checks if an admin has added or removed specific texts in any edit, or made any of specific modifications to pages. Checking for protected edits can be a little harder (we need to check for protection at the time of edit, not for the time of the check), but even this can be managed. Edits to pages which match specific regular expression patterns should be trivial to detect. Animal lover|666|11:33, 9 December 2024 (UTC)
Oppose While I have never accepted "not all admin actions are logged" as a realistic reason for no logged actions in an entre year, I just don't see what problematic group of admins this is in response to. Previous tweaks to the rules were in response to admins that seemed to be gaming the system, that were basically inactive and when they did use the tools they did it badly, etc. We don't need a rule that ins't pointed a provable, ongoing problem. Just Step Sideways19:19, 8 December 2024 (UTC)
Oppose If an admin is still editing, it's not unreasonable to assume that they are still up to date with policies, community norms etc. I see no particular risk in allowing them to keep their tools. Scribolt (talk) 19:46, 8 December 2024 (UTC)
Oppose: It feels like some people are trying to accelerate admin attrition and I don't know why. This is a solution in search of a problem. Gnomingstuff (talk) 07:11, 10 December 2024 (UTC)
Oppose Sure there is a problem, but the real problem I think is that it is puzzling why they are still admins. Perhaps we could get them all to make a periodic 'declaration of intent' or some such every five years that explains why they want to remain an admin. Alanscottwalker (talk) 19:01, 11 December 2024 (UTC)
Oppose largely per scribolt. We want to take away mops from inactive accounts where there is a risk of them being compromised, or having got out of touch with community norms, this proposal rather targets the admins who are active members of the community. Also declining incorrect deletion tags and AIV reports doesn't require the use of the tools, doesn't get logged but is also an important thing for admins to do. ϢereSpielChequers07:43, 15 December 2024 (UTC)
Oppose. What is the motivation for this frenzy to make more hoops for admins to jump through and use not jumping through hoops as an excuse to de-admin them? What problem does it solve? It seems counterproductive and de-inspiring when the bigger issue is that we don't have enough new admins. —David Eppstein (talk) 07:51, 17 December 2024 (UTC)
Oppose I quite agree with David Eppstein's sentiment. What's with the rush to add more hoops? Is there some problem with the admin corps that we're not adequately dealing with? Our issue is that we have too few admins, not that we have too many. CaptainEek⚓23:20, 22 December 2024 (UTC)
Discussion (Admin inactivity removal)
Making administrative actions can be helpful to show that the admin is still up-to-date with community norms. We could argue that if someone is active but doesn't use the tools, it isn't a big issue whether they have them or not. Still, the tools can be requested back following an inactivity desysop, if the formerly inactive admin changes their mind and wants to make admin actions again. For now, I don't see any immediate issues with this proposal. Chaotic Enby (talk · contribs) 08:13, 4 December 2024 (UTC)
Looking back at previous RFCs, in 2011 the reasoning was to reduce the attack surface for inactive account takeover, and in 2022 it was about admins who haven't been around enough to keep up with changing community norms. What's the justification for this besides "use it or lose it"? Further, we already have a mechanism (from the 2022 RFC) to account for admins who make a few edits every year. Anomie⚔12:44, 4 December 2024 (UTC)
I also note that not all admin actions are logged. Logging editing through full protection requires abusing the Edit Filter extension. Reviewing of deleted content isn't logged at all. Who will decide whether an admin's XFD "keep" closures are really WP:NACs or not? Do adminbot actions count for the operator? There are probably more examples. Currently we ignore these edge cases since the edits will probably also be there, but now if we can desysop someone who made 100,000 edits in the year we may need to consider them. Anomie⚔12:44, 4 December 2024 (UTC)
I had completely forgotten that many admin actions weren't logged (and thus didn't "count" for activity levels), that's actually a good point (and stops the "community norms" arguments as healthy levels of community interaction can definitely be good evidence of that). And, since admins desysopped for inactivity can request the tools back, an admin needing the bit but not making any logged actions can just ask for it back. At this point, I'm not sure if there's a reason to go through the automated process of desysopping/asking for resysop at all, rather than just politely ask the admin if they still need the tools.I'm still very neutral on this by virtue of it being a pretty pointless and harmless process either way (as, again, there's nothing preventing an active admin desysopped for "inactivity" from requesting the tools back), but I might lean oppose just so we don't add a pointless process for the sake of it. Chaotic Enby (talk · contribs) 15:59, 4 December 2024 (UTC)
To me this comes down to whether the community considers it problematic for an admin to have tools they aren't using. Since it's been noted that not all admin actions are logged, and an admin who isn't using their tools also isn't causing any problems, I'm not sure I see a need to actively remove the tools from an inactive admin; in a worst-case scenario, isn't this encouraging an admin to (potentially mis-)use the tools solely in the interest of keeping their bit? There also seems to be somewhat of a bad-faith assumption to the argument that an admin who isn't using their tools may also be falling behind on community norms. I'd certainly like to hope that if I was an admin who had been inactive that I would review P&G relevant to any admin action I intended to undertake before I executed. DonIago (talk) 15:14, 4 December 2024 (UTC)
As I have understood it, the original rationale for desysopping after no activity for a year was the perception that an inactive account was at higher danger of being hijacked. It had nothing to do with how often the tools were being used, and presumably, if the admin was still editing, even if not using the tools, the account was less likely to be hijacked. - Donald Albury22:26, 4 December 2024 (UTC)
And also, if the account of an active admin was hijacked, both the account owner and those they interact with regularly would be more likely to notice the hijacking. The sooner a hijacked account is identified as hijacked, the sooner it is blocked/locked which obviously minimises the damage that can be done. Thryduulf (talk) 00:42, 5 December 2024 (UTC)
I was not aware that not all admin actions are logged, obviously they should all be correctly logged as admin actions. If you're an Admin you should be doing Admin stuff, if not then you obviously don't need the tools. If an Admin is busy IRL then they can either give up the tools voluntarily or get desysopped for inactivity. The "Asking the tools back at BN can feel like a faff." isn't a valid argument, if an Admin has been desysopped for inactivity then getting the tools back should be "a faff". Regarding the comment that "There's no indication that this is a problem needs fixing." the problem is Admins who don't undertake admin activity, don't stay up to date with policies and norms, but don't voluntarily give up the tools. The 2022 change was about total edits over 5 years, not specifically admin actions and so didn't adequately address the issue. Mztourist (talk) 03:23, 5 December 2024 (UTC)
obviously they should all be correctly logged as admin actions - how would you log actions that are administrative actions due to context/requiring passive use of tools (viewing deleted content, etc.) rather than active use (deleting/undeleting, blocking, and so on)/declining requests where accepting them would require tool use? (e.g. closing various discussions that really shouldn't be NAC'd, reviewing deleted content, declining page restoration) Maybe there are good ways of doing that, but I haven't seen any proposed the various times this subject came up. Unless and until "soft" admin actions are actually logged somehow, "editor has admin tools and continues to engage with the project by editing" is the closest, if very imperfect, approximation to it we have, with criterion 2 sort-of functioning to catch cases of "but these specific folks edit so little over a prolonged time that it's unlikely they're up-to-date and actively engaging in soft admin actions". (I definitely do feel criterion 2 could be significantly stricter, fwiw) AddWittyNameHere05:30, 5 December 2024 (UTC)
Not being an Admin I have no idea how their actions are or aren't logged, but is it a big ask that Admins perform at least a few logged Admin actions in a year? The "imperfect, approximation" that "editor has admin tools and continues to engage with the project by editing" is completely inadequate to capture Admin inactivity. Mztourist (talk) 07:06, 6 December 2024 (UTC)
I've been a "hawk" regarding admin activity standards for a very long time, but this proposal comes off as half-baked. The rules we have now are the result of careful consideration and incremental changes aimed at specific, provable issues with previous standards. While I am not a proponent of "not all actions are logged" as a blanket excuse for no logged actions in several years, it is feasible that an admin could be otherwise fully engaged with the community while not having any logged actions. We haven't been having trouble with admins who would be removed by this, so where's the problem? Just Step Sideways19:15, 8 December 2024 (UTC)
"Blur all images" switch
Although i know that WP:NOTCENSORED, i propose that the Vector 2022 and Minerva Neue skins (+the Misplaced Pages mobile apps) have a "blur all images" toggle that blurs all the images on all pages (requiring clicking on them to view them), which simplifies the process of doing HELP:NOSEE as that means:
You don't need to create an account to hide all images.
You don't need any complex JavaScript or CSS installation procedures. Not even browser extensions.
You can blur all images in the mobile apps, too.
It's all done with one push of a button. No extra steps needed.
Blurring all images > hiding all images. The content of a blurred image could be easily memorized, while a completely hidden image is difficult to compare to the others.
And it shouldn't be limited to just Misplaced Pages. This toggle should be available on all other WMF projects and MediaWiki-powered wikis, too.
67.209.128.126 (talk) 15:26, 5 December 2024 (UTC)
Wow, @Chaotic Enby, is that usable on all skins/browsers/devices? If so, we should be referring people to it from everywhere instead of the not-very-helpful WP:NOSEE, which I didn't even bother to try to figure out. Valereee (talk) 15:00, 17 December 2024 (UTC)
I haven't tested it beyond my own setup, although I can't see reasons why it wouldn't work elsewhere. However, there are two small bugs I'm not sure how to fix: when loading a new page, the images briefly show up for a fraction of a second before being blurred; and the images in Page Previews aren't blurred (the latter, mostly because I couldn't get the html code for the popups). Chaotic Enby (talk · contribs) 16:57, 17 December 2024 (UTC)
Ah, yes, I see both of those. Probably best to get at least the briefly-showing bug fixed before recommending it generally. The page previews would be good to fix but may be less of an issue for recommending generally, since people using that can be assumed to know how to turn it off. Valereee (talk) 18:28, 17 December 2024 (UTC)
@Valereee -- the issue with a script would be as follows:
Even for logged-in users, user scripts are a moderate barrier to install (digging through settings, or worse still, having to copy-paste to the JS/CSS user pages).
The majority of readers do not have an account, and the overwhelming majority of all readers make zero edits. For many people, it's too much of a hassle to sign up (or they can't remember their password, or a number of other reasons etc, etc)
What all readers and users have, though, is this menu:
I say instead of telling the occasional IP or user who complains to install a script (there are probably many more people who object to NOTCENSORED, but don't want to or don't know how to voice objections), we could add the option to replace all images with a placeholder (or blur) and perhaps also an option to increase thumbnail size.
On the image blacklist aspect, doesn't Anomie have a script that hides potentially offensive images? I've not a clue how it works, but perhaps it could be added to the appearance menu (I don't support this myself, for a number of reasons)
That's User:Anomie/hide-images, which is already listed on WP:NOSEE. I wrote it a long time ago as a joke for one of these kinds of discussions: it does very well at hiding all "potentially offensive" images because it hides all images. But people who want to have to click to see any images found it useful enough to list it on WP:NOSEE. Anomie⚔22:52, 17 December 2024 (UTC)
Out of curiosity, how does it filter for potentially offensive images? The code at user:Anomie/hide-images.js seems rather minimal (as I write this, I realize it may work by hiding all images, so I may have answered my own question). JayCubby22:58, 17 December 2024 (UTC)
That's my point: if you are unregistered, you will see whatever the default setting is (which I assume will be unblurred, which might lead to more complaints). We had similar problems dealing with image thumbnail sizes, a setting that unregistered users can't adjust. Masem (t) 01:10, 6 December 2024 (UTC)
I'm confused about how this would lead to more complaints. Right now, logged-out users see every image without obfuscation. After this toggle rolls out, logged-out users would still see every image without obfuscation. What fresh circumstance is leading to new complaints? ꧁Zanahary꧂ 07:20, 12 December 2024 (UTC)
What would be the goal of a blur all images option? It seems too tailored. But a "hide all images" could be suitable. EEpic (talk) 06:40, 11 December 2024 (UTC)
I suggest that the "hide all images" display file name if possible. Between file name and caption (which admittedly are often similar, but not always), there should be sufficient clue whether an image will be useful (and some suggestion, but not reliably so, if it may offend a sensibility.) -- Nat Gertler (talk) 17:59, 11 December 2024 (UTC)
Regarding not limiting image management choices to Misplaced Pages: that's why it's better to manage this on the client side. Anyone needing to limit their bandwidth usage, or to otherwise decide individually on whether or not to load each photo, will likely want to do this generally in their web browsing. isaacl (talk) 18:43, 6 December 2024 (UTC)
Definitely a browser issue. You can get plug-ins for Chrome right now that will do exactly this, and there's no need for Misplaced Pages/Mediawiki to implent anything. — The Anome (talk) 18:48, 6 December 2024 (UTC)
I propose something a bit different: all images on the bad images list can only be viewed with a user account that has been verified to be over 18 with government issued ID. I say this because in my view there is absolutely no reason for a minor to view it. Jayson (talk) 23:41, 8 December 2024 (UTC)
Well, that means readers will be forced to not only create an account, but also disclose sensitive personal information, just to see encyclopedic images. That is pretty much the opposite of a 💕. Chaotic Enby (talk · contribs) 23:44, 8 December 2024 (UTC)
I can support allowing users to opt to blu4 or hide some types of images, but this needs to be an opt-in only. By default, show all images. And I'm also opposed to any technical restriction which requires self-identification to overcome, except for cases where the Foundation deems it necessary to protect private information (checkuser, oversight-level hiding, or emails involving private information). Please also keep in mind that even if a user sends a copy of an ID which indicates the individual person's age, there is no way to verify that it was the user's own ID whuch had been sent. Animal lover|666|11:25, 9 December 2024 (UTC)
Well, yes, but I rank that as “harmless”. I don’t know why anyone would consider a woman with her newborn baby so inappropriate for children it needs to be censored like hardcore porn. Dronebogus (talk) 14:53, 12 December 2024 (UTC)
The Hezbollah flag might be blacklisted because it's copyrighted, but placed in articles by uninformed editors (though one of JJMC89's bots automatically removes NFC files from pages). We have File:InfoboxHez.PNG for those uses. JayCubby16:49, 13 December 2024 (UTC)
This is an even better idea as an opt-in toggle than the blur one. Load no images by default, and let users click a button to load individual images. That has a use beyond sensitivity. ꧁Zanahary꧂ 02:46, 13 December 2024 (UTC)
Yes I like that idea even better. I think in any case we should use alt text to describe the image so people don’t have to play Russian roulette based on potentially vague or nonexistent descriptions, i.e. without alt text an ignorant reader would have no idea the album cover for Virgin Killer depicts a nude child in a… questionable pose. Dronebogus (talk) 11:42, 13 December 2024 (UTC)
An option to replace images with alt text seems both much more useful and much more neutral as an option. There are technical reasons why a user might want to not load images (or only selectively load them based on the description), so that feels more like a neutral interface setting. An option to blur images by default sends a stronger message that images are dangerous.--Trystan (talk) 16:24, 13 December 2024 (UTC)
Also it'd negate the bandwidth savings somewhat (assuming an image is displayed as a low pixel-count version). I'm of the belief that Misplaced Pages should have more features tailored to the reader. JayCubby16:58, 13 December 2024 (UTC)
At the very least, add a filter that allows you to block all images on the bad image list, specifically that list and those images. To the people who say you shouldnt have to give up personal info, I say that we should go the way Roblox does. Seems a bit random, hear me out: To play 17+ games, you need to verify with gov id, those games have blood alcohol, unplayable gambling and "romance". I say that we do the same. Giving up personal info to view bad things doesn't seem so bad to me. Jayson (talk) 03:44, 15 December 2024 (UTC)
Building up a database of people who have applied to view bad things on a service that's available in restrictive regimes sounds like a way of putting our users in danger. -- Nat Gertler (talk) 07:13, 15 December 2024 (UTC)
Roblox =/= Misplaced Pages. I don’t know why I have to say this, nor did I ever think I would. And did you read what I already said about the “bad list”? Do you want people to have to submit their ID to look at poop, a woman with her baby, the Hezbollah flag, or graffiti? How about we age-lock articles about adult topics next? Dronebogus (talk) 15:55, 15 December 2024 (UTC)
So removing a significant thing that makes Misplaced Pages free is worth preventing underaged users from viewing certain images? I wouldn't say that would be a good idea if we want to make Misplaced Pages stay successful. If a reader wants to read an article, they should expect to see images relevant to the topic. This includes topics that are usually considered NSFW like Graphic violence, Sexual intercourse, et cetera. If a person willingly reads an article about an NSFW topic, they should acknowledge that they would see topic-related NSFW images. ZZ'S16:45, 15 December 2024 (UTC)
This is moot. Requiring personal information to use Misplaced Pages isn't something this community even has the authority to do. Valereee (talk) 16:23, 17 December 2024 (UTC)
Yes, if this happens it should be through a disable all images toggle, not an additional blur. There have been times that would have been very helpful for me. CMD (talk) 03:52, 15 December 2024 (UTC)
Support the proposal as written. I'd imagine WMF can add a button below the already-existing accessibility options. People have different cultural, safety, age, and mental needs to block certain images. Ca13:04, 15 December 2024 (UTC)
I'd support an option to replace images with the alt text, as long as all you had to do to see a hidden image was a single click/tap (we'd need some fallback for when an image has no alt text, but that's a minor issue). Blurring images doesn't provide any significant bandwidth benefits and could in some circumstances cause problems (some blurred innocent images look very similar to some blurred blurred images that some people regard as problematic, e.g. human flesh and cooked chicken). I strongly oppose anything that requires submitting personal information of any sort in order to see images per NatGertler. Thryduulf (talk) 14:15, 15 December 2024 (UTC)
This is something that has frequently occurred to me as a potentially useful feature when browsing categories, but I have never quite gotten around to actually proposing it until now.
Basically, I'm thinking it could be very helpful to have content-assessment class icons appear next to article entries in categories. This should be helpful not only to readers, to guide them to the more complete entries, but also to editors, to alert them to articles in the category that are in need of work. Thoughts? Gatoclass (talk) 03:02, 7 December 2024 (UTC)
If we go with this, I think there should be only 4 levels - Stub, Average (i.e. Start, C, or B), GA, & FA.
There are significant differences between Start, C, and B, but there's no consistent effort to grade these articles correctly and consistently, so it might be better to lump them into one group. Especially if an article goes down in quality, almost nobody will bother to demote it from B to C. ypn^204:42, 8 December 2024 (UTC)
Isn't that more of an argument for consolidation of the existing levels rather than reducing their number for one particular application?
Other than that, I think I would have to agree that there are too many levels - the difference between Start and C class, for example, seems quite arbitrary, and I'm not sure of the usefulness of A class - but the lack of consistency within levels is certainly not confined to these lower levels, as GAs can vary enormously in quality and even FAs. But the project nonetheless finds the content assessment model to be useful, and I still think their usefulness would be enhanced by addition to categories (with, perhaps, an ability to opt in or out of the feature).
I might also add that including content assessment class icons to categories would be a good way to draw more attention to them and encourage users to update them when appropriate. Gatoclass (talk) 14:56, 8 December 2024 (UTC)
I believe anything visible in reader-facing namespaces needs to be more definitively accurate than in editor-facing namespaces. So I'm fine having all these levels on talk pages, but not on category pages, unless they're applied more rigorously.
On the other hand, with FAs and GAs, although standards vary within a range, they do undergo a comprehensive, well-documented, and consistent process for promotion and demotion. So just like we have an icon at the top of those articles (and in the past, next to interwiki links), I could hear putting them in categories. ypn^218:25, 8 December 2024 (UTC)
Isn't the display of links Category pages entirely dependent on the Mediawiki software? We don't even have Short descriptions displayed, which would probably be considerably more useful.Any function that has to retrieve content from member articles (much less their talkpages) is likely to be somewhat computationally expensive. Someone with more technical knowledge may have better information. Folly Mox (talk) 18:01, 8 December 2024 (UTC)
Yes, this will definitely require MediaWiki development, but probably not so complex. And I wonder why this will be more computationally expensive than scanning articles for ] tags in the first place. ypn^218:27, 8 December 2024 (UTC)
And I wonder why this will be more computationally expensive than scanning articles for ] tags in the first place my understanding is that this is not what happens. When a category is added to or removed from an article, the software adds or removes that page as a record from a database, and that database is what is read when viewing the category page. Thryduulf (talk) 20:14, 8 December 2024 (UTC)
I think that in the short term, this could likely be implemented using a user script (displaying short descriptions would also be nice). Longer-term, if done via an extension, I suggest limiting the icons to GAs and FAs for readers without accounts, as other labels aren't currently accessible to them. (Whether this should change is a separate but useful discussion). — Frostly (talk) 23:06, 8 December 2024 (UTC)
I strongly believe that ordinary readers don't care about this kind of inside baseball, but if you want it for yourself, then use the gadget or fork its script. Changing this old gadget from "adding text and color" to "displaying an icon" should be relatively simple. WhatamIdoing (talk) 23:43, 12 December 2024 (UTC)
I strongly oppose loading any default javascript solution that would cause hundreds of client-side queries every time a category page is opened. As far as making an upstream software request, there are multiple competing page quality metrics and schemes that would need to be reviewed. — xaosflux15:13, 18 December 2024 (UTC)
My suggestion would be to put those pages only in the "Class" category (in this case Category:Portal-Class United States articles), and only give that category a NA-rating. Doing this for all these subcats (File, Template, ...) would bring the at the moment 276,534 (!) pages in Category:NA-importance United States articles back to near-zero, only leaving the anomalies which probably need a different importance rating (and thus making it a useful cleanup category).
It is unclear why we have two systems (3 cat vs. 2 cat), the tags on Category talk:2nd millennium in South Carolina (without class or NA indication) have a different effect than the tags on e.g. Category talk:4 ft 6 in gauge railways in the United Kingdom, but my proposal is to make the behaviour the same, and in both cases to reduce it to the class category only (and make the classes themselve categorize as "NA importance"). This would only require an update in the templates/modules behind this, not on the pages directly, I think. Fram (talk) 15:15, 9 December 2024 (UTC)
Are there any pages that don't have the default? e.g. are there any portals or Category talk: pages rated something other than N/A importance? If not then I can't see any downsides to the proposal as written. If there are exceptions, then as long as the revised behaviour allows for the default to be overwritten when desired again it would seem beneficial. Thryduulf (talk) 16:36, 9 December 2024 (UTC)
As far as I know, there are no exceptions. And I believe that one can always override the default behaviour with a local parameter. @Tom.Reding: I guess you know these things better and/or knows who to contact for this. Fram (talk) 16:41, 9 December 2024 (UTC)
I was imagining high importance United States redirects to be things like USA but that isn't there and what is is a very motley collection. I only took a look at one, Talk:United States women. As far as I can make out the article was originally at this title but later moved to Women in the United States over a redirect. Both titles had independent talk pages that were neither swapped nor combined, each being rated high importance when they were the talk page of the article. It seems like a worthwhile exercise for the project to determine whether any of those redirects are actually (still?) high priority but that's independent of this proposal. Thryduulf (talk) 17:17, 9 December 2024 (UTC)
Support this, even if there might be a few exceptions, it will make them easier to spot and deal with rather than having large unsorted NA-importance categories. Chaotic Enby (talk · contribs) 18:04, 9 December 2024 (UTC)
Strongly agree with this. It's bizarre having two different systems, as well as a pain in the ass sometimes. Ideally we should adopt a single consistent categorization system for importance/quality. – Closed Limelike Curves (talk) 22:56, 16 December 2024 (UTC)
So essentially what you are proposing is to delete Category:NA-importance articles and all its subcategories? I think it would be best to open a CfD for this, so that the full implications can be discussed and consensus assured. It is likely to have an effect on assessment tools, and tables such as User:WP 1.0 bot/Tables/Project/Africa would no longer add up to the expected number — Martin (MSGJ · talk) 22:13, 14 December 2024 (UTC)
Well a CfD just got closed with 14,000 categories, so that is not a barrier. It is also the technically correct venue for such discussions. By the way, all of the quality/importance intersection categories check that the category exists before using it, so deleting them shouldn't break anything. — Martin (MSGJ · talk) 08:57, 16 December 2024 (UTC)
I'm going to have to oppose any more changes to class categories. Already changes are causing chaos across the system with the bots unable to process renamings and fixing redirects whilst Special:Wantedcategories is being overwhelmed by the side effects. Quite simply we must have no more changes that cannot be properly processed. Any proposal must have clear instructions posted before it is initiated, not some vague promise to fix a module later on. Timrollpickering (talk) 13:16, 16 December 2024 (UTC)
Then I'm at an impasse. Module people tell me "start a CfD", you tell me "no CfD, first make changes at the module". No one wants the NA categories for these groups. What we can do is 1. RfC to formalize that they are unwanted, 2. Change module so they no longer get populated 3. Delete the empty cats caused by steps 1 and 2. Is that a workable plan for everybody? Fram (talk) 13:39, 16 December 2024 (UTC)
I don't think @Timrollpickering was telling you to make the changes at the module first, rather to prepare the changes in advance so that the changes can be implemented as soon as the CfD reaches consensus. For example this might be achieved by having a detailed list of all the changes prepared and published in a format that can be fed to a bot. For a change of this volume though I do think a discussion as well advertised as an RFC is preferable to a CfD though. Thryduulf (talk) 14:43, 16 December 2024 (UTC)
Got it in one. There are just too many problems at the moment because the modules are not being properly amended in time. We need to be firmer in requiring proponents to identify the how to change before the proposal goes live so others can enact it if necessary, not close the discussion, slap the category on the working page and let a mess pile up whilst no changes to the module are implemented. Timrollpickering (talk) 19:37, 16 December 2024 (UTC)
Oh, I got it as well, but at the module talk page, I was told to first have a CfD (to determine consensus first I suppose, instead of writing the code without knowing if it will be implemented). As I probably lack the knowledge to make the correct module changes, I'm at an impasse. That's why I suggested an RfC instead of a CfD to determine the consensus for "deletion after the module has been changed", instead of a CfD which is more of the "delete it now" variety. No one here has really objected to the deletion per se, but I guess that a more formal discussion might be welcome. Fram (talk) 10:09, 17 December 2024 (UTC)
What's the benefit of having two or three categories for the same group of pages? We have multiple systems (with two or three cats, and apparently other ones as well), with no apparent reason to keep this around. As an example, we have Category:Category-Class film articles with more than 50,000 pages, e.g. Category talk:20th century in American cinema apparently. But when I go to that page, it isn't listed in that category, it is supposedly listed in Category:NA-Class film articles (which seems to be a nonsense category, we shouldn't have NA-class, only NA-importance). but that category doesn't contain that page. So now I have no idea what's going on or what any of this is trying to achieve. Fram (talk) 08:30, 18 December 2024 (UTC)
Something changed recently. I think. But it is useful to know which NA pages are tagged with a project with a granularity beyond just "Not Article". It helps me do maintenance and find things that are tagged improperly, especially with categories. I do not care what happens to the importance ratings. PARAKANYAA (talk) 09:20, 18 December 2024 (UTC)
Category:Current sports events
I would like to propose that sports articles should be left in the Category:Current sports events for 48 hours after these events have finished. I'm sure many Misplaced Pages sports fans (including me) open CAT:CSE first and then click on a sporting event in that list. And we would like to do so in the coming days after the event ends to see the final standings and results.
Currently, this category is being removed from articles too early, sometimes even before the event ends. Just like yesterday. AnishaShar, what do you say about that?
So I would like to ask you to consider my proposal. Or, if you have a better suggestion, please comment. Thanks, Maiō T. (talk) 16:25, 9 December 2024 (UTC)
Thank you for bringing up this point. I agree that leaving articles in the Category:Current sports events for a short grace period after the event concludes—such as 48 hours—would benefit readers who want to catch up on the final standings and outcomes. AnishaShar (talk) 18:19, 9 December 2024 (UTC)
You ask how it would be policed. Simply, we will teach editors to do it that way – to leave an article in that category for another 48 hours. AnishaShar have already expressed their opinion above. WL Pro for life is also known for removing 'CAT:CSE's from articles. I think we could put some kind of notice in that category so other editors can notice it. We could set up a vote here. Maybe someone else will have a better idea. Maiō T. (talk) 20:25, 14 December 2024 (UTC)
Would it not be more suitable for a "recently completed sports event" category. It's pretty inaccurate to say it's current when the event finished over a day ago. Lee Vilenski21:03, 14 December 2024 (UTC)
Okay Lee, that's also a good idea. We have these two sports event categories:
In a number of articles we have (or had) user-generated conflict maps. I think the mains ones at the moment are Syrian civil war and Russian invasion of Ukraine. The war in Afghanistan had one until it was removed as poorly-sourced in early 2021. As you can see from a brief review of Talk:Syrian civil war the map has become quite controversial there too.
My personal position is that sourcing conflict maps entirely from reports of occupation by one side or another of individual towns at various times, typically from Twitter accounts of dubious reliability, to produce a map of the current situation in an entire country (which is the process described here), is a WP:SYNTH/WP:OR. I also don't see liveuamap.com as necessarily being a highly reliable source either since it basically is an WP:SPS/Wiki-style user-generated source, and when it was discussed at RSN editors there generally agreed with that. I can understand it if a reliable source produces a map that we can use, but that isn't what's happening here.
Part of the reason this flies under the radar on Misplaced Pages is it ultimately isn't information hosted on EN WP but instead on Commons, where reliable sourcing etc. is not a requirement. However, it is being used on Misplaced Pages to present information to users and therefore should fall within our PAGs.
I think these maps should be deprecated unless they can be shown to be sourced entirely to a reliable source, and not assembled out of individual reports including unreliable WP:SPS sources. FOARP (talk) 16:57, 11 December 2024 (UTC)
A lot of the maps seem like they run into SYNTH issues because if they're based on single sources they're likely running into copyright issue as derivative works. I would agree though that if an image does not have clear sourcing it shouldn't be used as running into primary/synth issues. Der Wohltemperierte Fuchs17:09, 11 December 2024 (UTC)
Though simple information isn't copyrightable, if it's sufficiently visually similar I suppose that might constitute a copyvio. JayCubby02:32, 13 December 2024 (UTC)
I agree these violate OR and at least the spirit of NOTNEWS and should be deprecated. I remember during the Wagner rebellion we had to fix one that incorrectly depicted Wagner as controlling a swath of Russia. Levivich (talk) 05:47, 13 December 2024 (UTC)
The Syrian map(right) seems quite respectable being based on the work of the Institute for the Study of War and having lots of thoughtful process and rules for updates. It is used on many pages and in many Wikipedias. There is therefore a considerable consensus for its use. Andrew🐉(talk) 11:33, 18 December 2024 (UTC)
Oppose: First off, I'd like to state my bias as a bit of a map geek. I've followed the conflict maps closely for years.
I think the premise of this question is flawed. Some maps may be poorly sourced, but that doesn't mean all of them are. The updates to the Syrian, Ukraine, and Burma conflicts maps are sourced to third parties. So that resolves the OR issue.
The sources largely agree with each other, which makes SYNTH irrelevant. Occasionally one source may be ahead of another by a few hours (e.g., LiveUaMap vs. ISW), but they're almost entirely in lock step.
I think this proposal throws out the baby with the bathwater. One bad map doesn't mean we stop using maps; it means we stop using bad maps.
You may not like the fact that these sources sometimes use OSI (open-source intelligence). Unfortunately, that is the nature of conflict in a zone where the press isn't allowed. Any information you get from the AP or the US government is likely to rely on the same sources.
Do they make mistakes? Probably; but so do all historical sources. And these maps have the advantage that the Commons community continuously reviews changes made by other users. Much in the same way that Misplaced Pages is often more accurate than historical encyclopedias, I believe crowdsourcing may make these maps more accurate than historical ones.
I think deprecating these maps would leave the reader at a loss (pictures speak a 1,000 words and all that). Does it get a border crossing wrong here or there? Yes, but the knowledge is largely correct.
@Magog the OgreWP:ITSUSEFUL is frowned upon as an argument for good reason. Beyond that: 1) the fact that these are based on fragmentary data is strangely not mentioned at all (Syrian civil war says 'Military situation as of December 18, 2024 at 2:00pm ET' which suggests that it's quite authoritative and should be trusted; the fact that it's based off the ISW is not disclosed.) 2) I'm not seeing where all the information is coming from the ISW. The ISW's map only covers territory, stuff like bridges, dams, "strategic hills" and the like are not present on the ISW map. Where is that info coming from? Der Wohltemperierte Fuchs23:10, 19 December 2024 (UTC)
The Commons Syria map uses both the ISW and Liveuamap. The two are largely in agreement, with Liveuamap being more precise but using less reliable sources. If you have an issue with using Liveuamap as a source, fine, bring it up on the talk pages where it's used, or on the Commons talk page itself. But banning any any map of a conflict is throwing out the baby with the bathwater. The Ukraine map is largely based on ISW-verifiable information.
With regards to actual locations like bridges, I'm against banning Commons users from augmenting maps with easily verifiable landmarks. That definition of SYN is broad to the point of meaningless, as it would apply to any user-generated content that uses more than one source. Magog the Ogre (t • c) 23:50, 20 December 2024 (UTC)
Weak Oppose I've been updating the Ukraine map since May 2022, so I hope my input is helpful. While I agree that some of the sources currently being used to update these maps may be dubious in nature, that has not always been the case. In the past, particularly for the Syria map, these maps have been considered among the most accurate online due to their quality sourcing. It used to be that a source was required for each town if it was to be displayed on these maps, but more recently, people have just accepted taking sources like LivaUAMap and the ISW and copying them exactly. Personally, I think we should keep the maps but change how they are sourced. I think that going back to the old system of requiring a reliable source for each town would clear up most of the issues that you are referring to, though it would probably mean that the maps would be less detailed than they currently are now. Physeters07:23, 21 December 2024 (UTC)
Oppose The campaign maps are one of our absolute best features. The Syrian campaign map in particular was very accurate for much of the war. Having a high quality SVG of an entire country like that is awesome, and there really isn't anything else like it out there, which is why it provides such value to our readers. I think we have to recognize of our course that they're not 100% accurate, due to the fog of war. I wouldn't mind if we created subpages about the maps? Like, with a list of sources and their dates, designed to be reader facing, so that our readers could verify the control of specific towns for themselves. But getting rid of the maps altogether is throwing out the baby with the bathwater. CaptainEek⚓23:33, 22 December 2024 (UTC)
What is the proposal here? If its for the google maps article, that would be more suitable for the talk page. As I see it, your proposal is simply saying that google maps has an api and we should use it for... something. I could be missing something, though Mgjertson (talk) 08:20, 17 December 2024 (UTC)
As I understand it, the IP is proposing embeds of google maps, which would be nice from a functionality standpoint (the embedded map is kinda-rather buggy), but given Google is an advertising company, isn't great from a privacy standpoint. JayCubby16:25, 17 December 2024 (UTC)
Allowing page movers to enable two-factor authentication
I would like to propose that members of the page mover user group be granted the oathauth-enable permission. This would allow them to use Special:OATH to enable two-factor authentication on their accounts.
Rationale (2FA for page movers)
The page mover guideline already obligates people in that group to have a strong password, and failing to follow proper account security processes is grounds for revocation of the right. This is because the group allows its members to (a) move pages along with up to 100 subpages, (b) override the title blacklist, and (c) have an increased rate limit for moving pages. In the hands of a vandal, these permissions could allow significant damage to be done very quickly, which is likely to be difficult to reverse.
Additionally, there is precedent for granting 2FA access to users with rights that could be extremely dangerous in the event of account compromise, for instance, template editors, importers, and transwiki importers have the ability to enable this access, as do most administrator-level permissions (sysop, checkuser, oversight, bureaucrat, steward, interface admin).
Support as a pagemover myself, given the potential risks and need for increased security. I haven't requested it yet as I wasn't sure I qualified and didn't want to bother the stewards, but having oathauth-enable by default would make the process a lot more practical. Chaotic Enby (talk · contribs) 22:30, 12 December 2024 (UTC)
Question When's the last time a page mover has had their account compromised and used for pagemove vandalisn? Edit 14:35 UTC: I'm not doubting the nom, rather I'm curious and can't think of a better way to phrase things. JayCubby02:30, 13 December 2024 (UTC)
Why isn't everybody allowed to enable 2FA? I've never heard of any other website where users have to go request someone's (pro forma, rubber-stamp) permission if they want to use 2FA. And is it accurate that 2FA, after eight years, is still "experimental" and "in production testing"? I guess my overall first impression didn't inspire me with confidence in the reliability and maintenance. Adumbrativus (talk) 06:34, 14 December 2024 (UTC)
No update comment since 2020 doesn't fill me with hope. I like 2FA, but it needs to be developed into a usable solution for all. Lee Vilenski00:09, 15 December 2024 (UTC)
I ain't a technical person, but could a less secure version of 2fa be introduced, where an email is sent for any login on new devices? JayCubby01:13, 15 December 2024 (UTC)
Definitely. However email addresses also get detached from people, so that would require that people regularly reconfirm their contact information. —TheDJ (talk • contribs) 11:01, 18 December 2024 (UTC)
For TOTP (the 6-digit codes), it's not quite as bad as when it was written, as the implementation has been fixed over time. I haven't heard nearly as many instances of backup scratch codes not working these days compared to when it was new. The WebAuthn (physical security keys, Windows Hello, Apple Face ID, etc) implementation works fine on private wikis but I wouldn't recommend using it for CentralAuth, especially with the upcoming SUL3 migration. There's some hope it'll work better afterward, but will still require some development effort. As far as I'm aware, WMF is not currently planning to work on the 2FA implmentation. As far as risk for page mover accounts goes, they're at a moderate risk. Page move vandalism, while annoying to revert, is reversible and is usually pretty loud (actions of compromised accounts can be detected and stopped easily). The increased ratelimit is the largest concern, but compared to something like account creator (which has noratelimit) it's not too bad. I'm more concerned about new page reviewer. There probably isn't a ton of harm to enabling 2FA for these groups, but there isn't a particularly compelling need either. AntiCompositeNumber (talk) 12:47, 19 December 2024 (UTC)
Support per nom. PMV is a high-trust role (suppressredirect is the ability to make a blue link turn red), and thus this makes sense. As a side note, I have changed this to bulleted discussion; # is used when we have separate sections for support and oppose. HouseBlaster (talk • he/they) 07:19, 14 December 2024 (UTC)
Oppose As a pagemover myself, I find pagemover is an extremely useful and do not wish to lose it. It is nowhere near the same class as template editor. You can already ask the stewards for 2FA although I would recommend creating a separate account for the purpose. After all these years, 2FA remains experimental, buggy and cumbersome. Incompatible with the Microsoft Authenticator app on my iphone. Hawkeye7(discuss)23:59, 14 December 2024 (UTC)
Understood, but I do not want it associated with an administrator-level permission, which would mean I am not permitted to use it, as I am not an admin. Hawkeye7(discuss)09:44, 15 December 2024 (UTC)
It's not really that. It would be an opt-in to allow users (in the group) to put 2FA on their account - at their own digression.
The main reasons why 2FA is currently out to admins and the like is because they are more likely to be targeted for compromising and are also more experienced. The 2FA flag doesn't require any admin skills/tools and is only incedentally linked. Lee Vilenski12:58, 15 December 2024 (UTC)
@Closed Limelike Curves the MediaWiki's 2FA implementation is complex, and the WMF's processes to support people who get locked out of their account aren't able to handle a large volume of requests (developers can let those who can prove they are the owner of the account back in). My understanding is that the current processes cannot be efficiently scaled up either, as it requires 1:1 attention from a developer, so unless and until new processes have been designed, tested and implemented 2FA is intended to be restricted to those who understand how to use it correctly and understand the risks of getting locked out. Thryduulf (talk) 09:36, 18 December 2024 (UTC)
It probably won't make a huge difference because those who really desire 2FA can already request the permission to enable it for their account, and because no page mover will be required to do so. However, there will be page movers who wouldn't request a global permission for 2FA yet would enable it in their preferences if it was a simple option. And these page movers might benefit from 2FA even more than those who already care very strongly about the security of their account. ~ ToBeFree (talk) 03:18, 15 December 2024 (UTC)
Oppose this is a low value permission, not needed. If an individual PMV really wants to opt-in, they can already do so over at meta - no need to build custom configuration for this locally. — xaosflux15:06, 18 December 2024 (UTC)
Support All users should be able to opt in to 2FA. Lack of a scalable workflow for users locked out of their accounts is going to be addressed by WMF only if enough people are using 2FA (and getting locked out?) to warrant its inclusion in the product roadmap. – SD0001 (talk) 14:01, 19 December 2024 (UTC)
That (and to @Stifle above) sounds like an argument to do just that - get support put in place and enable this globally, not to piecemeal it in tiny batches for discretionary groups on a single project (this custom configuration would support about 3/10ths of one percent of our active editors). To the point of this RFC, why do you think adding this for this specific tiny group is a good idea? — xaosflux15:40, 19 December 2024 (UTC)
I'm pretty sure that 2FA is already available to anyone. You just have to want it enough to either request it "for testing purposes" or to go to testwiki and request that you made an admin there, which will automatically give you access. See H:ACCESS2FA. WhatamIdoing (talk) 23:41, 21 December 2024 (UTC)
We shouldn't have to jump through borderline manipulative and social-engineering hoops to get basic security functionality. — SMcCandlish☏¢ 😼 04:40, 22 December 2024 (UTC)
Oppose. It sounds like account recovery when 2FA is enabled involves Trust and Safety. I don't think page movers' account security is important enough to justify increasing the burden on them. —Compassionate72714:10, 21 December 2024 (UTC)
Losing access to the account is less common nowadays since most 2FA apps, including Google Authenticator, have implemented cloud syncing so that even if you lose your phone, you can still access the codes from another device. – SD0001 (talk) 14:40, 21 December 2024 (UTC)
That's not true. You can use any TOTP authenticator app for MediaWiki 2FA. I currently use Ente Auth, having moved on from Authy recently, and from Google Authenticator a few years back. In case you're thinking of SMS-based 2FA, it has become a thing of the past and is not supported by MediaWiki either because it's insecure (attackers have ways to trick your network provider to send them your texts). – SD0001 (talk) 09:19, 22 December 2024 (UTC)
Support. Even aside from the fact that, in 2024+, everyone should be able to turn on 2FA .... Well, absolutely certainly should everyone who has an advanced bit, with potential for havoc in the wrong hands, be able to use 2FA here. That also includes template-editor, edit-filter-manager, file-mover, account-creator (and supersets like event-coordinator), checkuser (which is not strictly tied to adminship), and probably also mass-message-sender, perhaps a couple of the others, too. Some of us old hands have several of these bits and are almost as much risk as an admin when it comes to loss of account control. — SMcCandlish☏¢ 😼 04:40, 22 December 2024 (UTC)
Take a look at Special:ListGroupRights - much of what you mentioned is already in place, because these are groups that could use it and are widespread groups used on most WMF projects. (Unlike extendedmover). — xaosflux17:22, 22 December 2024 (UTC)
Comment: It is really not usual for 2FA to be available to a user group that is not defined as privileged in the WMF files. By default, all user groups defined at CommonSettings.php (iirc) that are considered to be privileged have the oathauth-enable right. Also, the account security practices mentioned in wp:PGM are also mentioned at wp:New pages patrol/Reviewers, despite not being discussed at all. Shouldn't it be fair to have the extendedmover userright be defined as privileged. ToadetteEdit (talk) 08:33, 23 December 2024 (UTC)
Support. Like SMcCandlish, I'd prefer that anyone, and particularly any editor with advanced perms, be allowed to turn on 2FA if they want (this is already an option on some social media platforms). But this is a good start, too.Since this is a proposal to allow page movers to opt in to 2FA, rather than a proposal to mandate 2FA for page movers, I see no downside in doing this. – Epicgenius (talk) 17:02, 23 December 2024 (UTC)
Support this opt-in for PMs and the broader idea of everyone having it by default. Forgive me if this sounds blunt, but is the responsibility and accountability of protecting your account lie on you and not WMF. Yes, they can assist in recovery, but the burden should not lie on them. ~/Bunnypranav:<ping> 17:13, 23 December 2024 (UTC)
Photographs by Peter Klashorst
Back in 2023 I unsuccessfully nominated a group of nude photographs by Peter Klashorst for deletion on Commons. I was concerned that the people depicted might not have been of age or consented to publication. Klashorst described himself as a "painting sex-tourist" because he would travel to third-world countries to have sex with women in brothels, and also paint pictures of them. On his Flickr account, he posted various nude photographs of African and Asian women, some of which appear to have been taken without the subjects' knowledge. Over the years, other Commons contributors have raised concerns about the Klashorst photographs (e.g. ).
I noticed recently that several of the Klashorst images had disappeared from Commons but the deletions hadn't been logged. I believe this happens when the WMF takes an office action to remove files. I don't know for sure whether that's the case, or why only a small number of the photographs were removed this way.
My proposal is that we stop using nude or explicit photographs by Klashorst in all namespaces of the English Misplaced Pages. This would affect about thirty pages, including high-traffic anatomy articles such as Buttocks and Vulva. gnu5718:29, 16 December 2024 (UTC)
@Genericusername57: I disagree with JJPMaster in that this seems to be the right venue, but I also disagree with your proposal. Klashorst might have been a sleazeball, yes, but the images at the two listed articles do not show recognizable subjects, nor do they resemble “creepshots”, nor is there evidence they’re underage. If you object to his images you can nominate them on Commons. Your ‘23 mass nomination failed because it was extremely indiscriminate (i.e. it included a self portrait of the artist). Dronebogus (talk) 00:30, 17 December 2024 (UTC)
@Dronebogus: According to User:Lar, Commons users repeatedly contacted Klashorst, asking him to provide proof of age and consent for his models, but he did not do so. I am planning on renominating the photographs on Commons, and I think removing them from enwiki first will help avoid spurious c:COM:INUSE arguments. The self-portrait you are referring to also included another naked person. gnu5702:16, 17 December 2024 (UTC)
@Genericusername57: replacing the ones at vulva and buttocks wouldn’t be difficult; the first article arguably violates WP:ETHNICGALLERY and conflicts with human penis only showing a single image anyway. However I think it’s best if you went to those actual articles and discussed removing them. I don’t know what other pages use his images besides his own article but they should be dealt with separately. If you want to discuss banning his photos from Wikimedia in general that’s best discussed at Commons. In all cases my personal view is that regardless of whether they actually run afoul of any laws purging creepy, exploitative pornography of third-world women is no great loss. Dronebogus (talk) 01:16, 18 December 2024 (UTC)
I have to confess that I do not remember the details of the attempts to clarify things with Peter. If this turns out to be something upon which this decision might turn, I will try to do more research. But I’m afraid it’s lost in the mists of time. ++Lar: t/c01:25, 24 December 2024 (UTC)
Move the last edited notice from the bottom of the page to somewhere that's easier to find
Currently, if you want to check when the last page edit was, you have to look at the edit history or scroll all the way to the bottom of the page and look for it near the licensing info. I propose moving it under the view history and watch buttons, across from the standard "This article is from Misplaced Pages" disclaimer. Non-technical users may be put off by the behind-the-scenes nature of the page or simply not know of its existence. The Mobile site handles this quiet gracefully in my opinion. While it is still at the bottom of the page, it isn't found near Licensing talk and is a noticeable portion of the page Mgjertson (talk) 08:32, 17 December 2024 (UTC)
I wished Misplaced Pages supported wallpapers in pages...
It would be even more awesome if we could change the wallpaper of pages in Misplaced Pages. But the fonts' colors could change to adapt to the wallpaper. The button for that might look like this: Change wallpaperGnu779 (talk) 11:02, 21 December 2024 (UTC)
Just out of curiosity: If a certain case of IPs spamming at Help Desk is any indication, would a CU be able to stop that in its track? 2601AC47 (talk|contribs) Isn't a IP anon 14:29, 23 November 2024 (UTC)
Note: This section was split off from "CheckUser for all new users" (permalink) and the "parenthetical comment" referred to below is: 
.png)
.svg)
.jpg){kind=link}
.jpg)){kind=link}
Change wallpaper Gnu779 (talk) 11:02, 21 December 2024 (UTC)