This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Now and then we see a new editor making piles of trivial edits in order to gain the 500 needed (along with 30 days) for extended confirmed status. There's no way to completely prevent that, but here are some common-sense proposals to help make sure that at least a portion of an editor's edits get at least some scrutiny before he/she receives x-confirmed status:
Proposal 1: Edits to User and User_talk spaces don't count toward the 500
Proposal 2: Only edits to article space and article Talk space count toward the 500
Proposal 3: The 500 edits must touch at least 20 distinct pages. A page and its talk (Article X and Talk:X, or WP:X and WP talk:X, count as one.)
Proposal 4: In page histories, edits by editors not x-confirmed are identified as such.
Proposal 3 (acknowledged to probably overdoing it) could be combined with 1 or 2. Thoughts? EEng 14:03, 9 August 2018 (UTC)
Good plan, this tactic of quick editing is also used on other websites and is seen as an end-around the policy. Could this be codeable though? The 20 distinct pages (10?), is that codeable? You must have had your thinking cap on. Randy Kryn (talk) 14:10, 9 August 2018 (UTC)
(edit conflict) I'll pretty much support any proposal to cut down on confirmation gaming. The three modes I see most often (for both auto- and extended- gaming) are
user creates a sockpuppet and does nothing for [4|30] days, then creates a userspace sandbox, makes an edit with just a period, then reverts that edit, then repeats [5|250] times, then edits a protected article.
user creates a sockpuppet and does nothing for [4|30] days, then wikilinks common terms across a variety of articles and self reverts, also [5|250] times, then edits a protected article.
user creates a sockpuppet and does nothing for [4|30] days, then rapidly adds a nonsense category to [10|500] different pages, then edits a protected article.
The patterns are so reliable that I think someone should be able to code a filter (I know this doesn't work with edit filters but some kind of code, a bot, I don't know) to detect it. To throw a really big wrench into the works, I suggest that for extended-confirmed, the account must make edits on some percentage of the days in the 30 day period. For example, instead of just measuring 30 days from the account's creation date, the account must have actually made an edit on, say, 10 out of the 30 days. Or just require that the account has made edits (maybe an edit of at least 10 bytes) on 30 (or some number of) different days before granting extended-confirmed status, and get rid of the edit count requirement altogether. It will really slow down the persistent sockpuppeteers if instead of just making some number of minor mass edits once and then waiting, they have to come back to do something without being detected on 30 different days. Of course, I have no idea how we would code such a thing, I just have the ideas. Ivanvector (Talk/Edits) 14:26, 9 August 2018 (UTC)
I really like the distinct-days idea. Listen, guys and gals, I'm just throwing this idea out for the community to do with what it will. I doubt I'll be participating much more. EEng 17:24, 9 August 2018 (UTC)
I have suggested that an edit filter bot be implemented on this wiki at the AN/I thread mentioned above. SemiHypercube✎ 21:30, 9 August 2018 (UTC)
@Ivanvector: No need of bot or inefficient edit filter. Upping EC promotion based on the pattern you just described seems easily configurable in MediaWiki and not without precedent. It is even trivial when compared with this currently working and more intricate criteria for automatic promotion to reviewer group on Wikibooks; it contains all the niceties in your comment and even more. Albeit I know setting this up will require wider RfC which may not necessarily found consensus to do so, as there is more to the social aspect of suitability of this than on the technical feasibility. –Ammarpad (talk) 21:19, 13 August 2018 (UTC)
@Ammarpad: thank you! I'm going to follow up on this further down the thread. Ivanvector (Talk/Edits) 21:33, 13 August 2018 (UTC)
From a technical perspective, I do not think this is presently possible. From a non-technical perspective, seeing these kinds of edits makes it trivial to identify editors who clearly are gaming the system; OTOH, someone contributing to 20 articles, adding some whitespace or changing a letter (possibly with minor vandalism), would not obviously be gaming the system. And I think that would be a loss. --Izno (talk) 14:43, 9 August 2018 (UTC)
(e/c) Noting that currently the auto promotion technology cannot distinguish between any type of edit. See mw:Manual:$wgAutopromote#Possible_conditions. Not sure what the impact is if that needs to be added (there might be performance problems, since the number being asked to test against, is not currently tracked anywhere and thus would have to be calculated upon every edit) —TheDJ (talk • contribs) 14:46, 9 August 2018 (UTC)
Yeah, I wouldn't think that what I suggested can be done with current code, it would be a feature request. It is apparently possible to gather that info, though: using this tool (it's slow to load) I can see that Izno has edited on 2,965 different days, or if I limit the number of edits it checks I can see that I've edited on 19 out of the last 21 days (oof). I'm sure that's the external site pulling edit info from Wikipedia and doing the math itself, but demonstrates that it can be calculated. Ivanvector (Talk/Edits) 14:59, 9 August 2018 (UTC)
There izno reason to single out a particular editor for scrutiny.[FBDB]EEng 17:33, 9 August 2018 (UTC)
Well, now I know edited on nearly 80% of the days that I've had an account. That's something. --Izno (talk) 17:56, 9 August 2018 (UTC)
It is easy to detect these trivial userspace edits. OTOH if a cheating user does trivial rapid fire whitespace/spelling/formatting to hundreds of articles - it is much more difficult to detect. The EC bit can be (and has been) stripped from users caught gaming.Icewhiz (talk) 17:27, 9 August 2018 (UTC)
May be we just need a manual grant. But that would require a way to request, and then admins looking at the queue and granting the permission. Perhaps a bot could detect the suitable users based on the rules we make up. How many new grants per day are there? Would this be burdensome to implement? Graeme Bartlett (talk) 22:25, 9 August 2018 (UTC)
Has anyone quantified how big a problem this is? I.E. How many badfaith accounts have snuck through to extended confirmed status before doing something dodgy? I'm not convinced we should complicate things further unless we actually have a problem. ϢereSpielChequers 22:43, 9 August 2018 (UTC)
I doubt it's a big problem, just a problem. I'm suggesting a (conceptually) simple change to cut off at least the most ridiculous way to game the system i.e. making a lot of edits in your own userspace. But if it's not easy to do it's not worth bothering with. And it may be that others' suggestions for an edit filter, or database report, that flags rapid blocks of certain types of edits (or editors that rarely get out of their user space, or ...) might be easier, just as effective, and more flexible. EEng 23:25, 9 August 2018 (UTC)
In my experience (I'm an SPI clerk so my experience is skewed) there are about as many instances of users gaming extendedconfirmation as there are gaming regular confirmation, in terms of numbers of sockmasters - obviously we pick out more socks at the autoconfirmed level because you can create them faster, but the additional problem with extended is that it's more natural to have sleeper accounts older than the CheckUser data retention window, so they're more likely to go undetected. The larger problem is that users who are persistent enough to have the patience to game autoconfirmation (it takes 30 days ffs) often end up causing articles to be protected at a very high bar for a very long period of time (i.e. ec-protecting an article for less than a month is silly), making the encyclopedia more difficult to edit for thousands of other users. And we've talked here about the ones who make 500 junk edits to a single page in their userspace, but there are also those that have made their 500 junk edits on 500 different articles over a month ago, with intervening edits, which makes everything much more difficult to clean up.
I recall asking about an edit filter for this some time ago, and remember having it explained that edit filters are for detecting issues with single edits, but aren't suited to detecting editing patterns involving multiple edits (courtesy ping MusikAnimal who I think explained it better). Some kind of semi-automated tool to detect the pattern would be fine, say an edit tag ("new user rapidly reverting" comes to mind) but still involves human intervention to do anything about it, plus we already have WP:SPI for that, perpetually backlogged though it is.
The idea behind my suggestion (and I think EEng's) is not really to make confirmation a higher bar, but to make it more difficult and labour-intensive to cheat it. A good-faith user would still meet the bar after some time of gaining experience, but a user who only wants to break things will need to put a lot more effort into it. Ivanvector (Talk/Edits) 13:44, 10 August 2018 (UTC)
Oppose all as unneeded. Admins and NPP (yeah you know me) have no trouble spotting even the 10 dummy edits to game the system for standard auto confirm. 500 is even easier to spot. This isn't needed.--Jayron32 00:01, 10 August 2018 (UTC)
This is just the idea lab, where editors kick around ideas, develop and modify them. It's way too early for boldface supports and opposes, because the proposals are still evolving. Why don't you just wait to see where the discussion takes things? For example, right now the idea is evolving that an edit filter might be better. EEng 00:30, 10 August 2018 (UTC)
My idea for developing and modifying this idea is to abandon the effort because, at its core, it's a bad idea that serves no useful purpose. You can't polish a turd. --Jayron32 13:28, 10 August 2018 (UTC)
I think the current policy is fine (500 edits and 30 days tenure. Do not game this.). That said, tools that help Admins identify when gaming has occurred should be welcomed, and used as appropriate. Tazerdadog (talk) 02:57, 10 August 2018 (UTC)
Proposal 1 is good, I am not convinced with the others. Proposal 3 sounds like an epic faff, proposal 2 means ignoring edits that significantly add to the guide's quality. Before I'd gathered 500 mainspace edits, I had participated in AfD etc, and that should certainly count towards the total. Proposal 4 sounds like it would extend the reduced status that is often given towards IP edits. As to effort/benefit analysis, I leave that to those who can tell us how much a namespace filter would be. Nosebagbear (talk) 10:54, 10 August 2018 (UTC)
Agree with 1 off the bat based off all my readings of ANI and personal experience, not so sure about the others. Thanks, L3X1◊distænt write◊ 17:52, 10 August 2018 (UTC)
I could see myself supporting proposal 1, but as I am mainly an editor of the Current Events portal, I'd certainly be opposed to the others. I have seen more than one user do a great deal of good work in portal space without touching other areas much. Icarosaurvus (talk) 22:40, 10 August 2018 (UTC)
Support the thrust of
proposal 1 (edits to User and User_talk spaces don't count)—completely in the spirit of extended confirmed
proposal 2 (only edits to article space and article talk space count)—why extended confirmed is needed as that's where contention, POV pushing, etc. occur, in the main
proposal 3 (must touch at least 20 distinct pages)—also completely in the spirit of requiring a minimum familarity with Wikipedia to edit contentious articles
Agnostic as to
proposal 4 (mark of newby)—if necessary could be a component of ORES (and probably already is).
Just make it reportable and auto-blocking infraction to do so, their is no need to modify the requirements for gaining extended confirmed protection, the limited privileges granted by the status also make it easy to investigate users suspected of abusing it as their are only a limited number of places it can be used. Zubin12 (talk) 06:34, 12 August 2018 (UTC)
I think it'd still be too easy to game the system even if the 500 were restricted to mainspace, since it's still possible for any user to e.g. install Cat-a-lot using their common.js and quickly categorize a few dozen articles that no one looks at. Jc86035 (talk) 07:48, 12 August 2018 (UTC)
An idea - a user with some technical expertise, Ammarpad, suggested that the technical framework to implement an "edits on a certain number of days" type automatic permission condition, based on the system currently in use for Wikibooks reviewers (see here), is at least technically configurable in the current mediawiki software. So, a pretty wild idea I know, but what if we:
mostly scrap the "confirmed" automatic permission levels, and the protection levels based on them,
keep a 4/10 [auto]confirmed level only for the purposes of WP:ACPERM (i.e. you must be confirmed to create an article; many new users do decide to create accounts just because they have an idea for an article),
create a "trusted user" (just a working title) permission level, wherein a user must make (numbers are suggestions):
100 edits
on at least 15 different days (to avoid rapidly making 100 edits and then waiting)
with non-canned edit summaries on at least 20 of those edits (to avoid fixed typo, fixed typo, fixed typo, and to teach new users to use edit summaries)
and must not have been blocked before automatic granting of the permission ("trusted user" may be granted by [admins|capable users] upon request and review in cases where users have been blocked, and it would not be automatically revoked if users are blocked subsequently),
change semiprotection so that users must be "trusted" to edit, and scrap extended-confirmed protection altogether (pages where semiprotection is not effective will simply be full-protected, plus we still have pending changes available)
Thoughts? Keep in mind that these are just ideas. Ivanvector (Talk/Edits) 21:58, 13 August 2018 (UTC)
My first thought is "why did FlaggedRevs implement its own autopromotion system?" I don't know if it's usable for things other than FlaggedRevs. Anomie⚔ 23:36, 13 August 2018 (UTC)
I think it's a bit complicated - it risks confusing those working towards it. I'm not sure of the where those who still cause disruption on semi-protect (and thus currently warrant extended protection) lie in terms of edits. Are they in the 10-150 edit range, or do they have a wider spread towards the 500? As my third and final point, I think this makes editing on SP too hard. Frequently it is implemented just to stop IPs and <24hr old accounts, and to significantly expand the limitations I think risks discouraging a fair few newbies from participating on articles (which includes many of the more active pages). Nosebagbear (talk) 13:20, 15 August 2018 (UTC)
Wikipedia already has a problem attracting new editors and a hostile overly bureacrtic enviorment, this will only worsen the problem by creating even more complication with attracting them to the project.Zubin12 (talk) 10:58, 16 August 2018 (UTC)
I also think modifying the requirements for being extended confirmed would be confusing and maybe a bit WP:BITEy towards newcomers. Also, if the requirements were to change, what would happen to those who are already x-confirmed, particularly if they didn't fit the new requirements? SemiHypercube✎ 01:08, 17 August 2018 (UTC)
Input requested
See the proposed idea here in the Signpost Op-Ed discussion for the article The last leg of the Admin Ship's current cruise. Need editor input to either help make it happen, or kill it. Please comment there. Thanks in advance! Atsme📞📧 21:38, 13 August 2018 (UTC)
I'd appreciate feedback on an idea. I'm thinking of establishing a free expert review service for Wikipedia featured articles on academic topics - topics well-covered by reliable journals, such as medicine and astronomy. Once an article meets the FA criteria, the world's leading experts on the topic would fact-check it and tell you what they think of its comprehensiveness and neutrality.
I can only offer this service if I'm allowed to put two prominent links at the top of the current article version, one linking the reader to the version that passed review, and the other linking to a simple diff between the current version and the fact-checked version.
The world's topic experts aren't going to review an article if the version they endorse disappears into the article's history in a day or a month. They will if we link to the reviewed version. And the "simple diff" is a service to the reader: it shows them at a glance how the article (and topic) has evolved since the expert-review.
I've thought deeply on this for a long time. I asked BMJ, the publisher of The BMJ, to recruit experts to review Parkinsons disease, and they obliged. One of the reviewers was a main author of the current PD diagnostic criteria and another is the most-published author on the illness. This was a very high quality review. That's the standard of review I intend to maintain.
Do you think rigorous independent expert-review of featured articles is a good thing, and would you support prominently linking to the reviewed version and the diff? --Anthonyhcole (talk · contribs · email) 13:34, 30 May 2018 (UTC)
I'd be in favour of this, for what would inevitably be a rather limited number of articles, with some kind of simple control/approval process. In line with WP:MEDRS principles, I think there should a time-limit of up to 5 years set on the links, unless there's some kind of re-review. Johnbod (talk) 13:58, 30 May 2018 (UTC)
How do you feel about those two prominent links at the top of the current version, Atsme? --Anthonyhcole (talk · contribs · email) 16:48, 30 May 2018 (UTC)
I'm fine with it. When I was researching for Project Accuracy, I spoke to quite a few academics (various teaching levels) and explained the significance of the GA & FA symbols on articles. Their responses are what inspired me to design the Seal. I still believe that once an FA goes through the drill of expert/academic review, they should be afforded some protection which makes that "seal" worth something. Atsme📞📧 16:59, 30 May 2018 (UTC)
Thank you, Atsme. I'm not sure where I stand on universal automatic protection for articles that have passed expert review. I think I'm against it but need to do more thinking about it. --Anthonyhcole (talk · contribs · email) 17:14, 30 May 2018 (UTC)
You're quite welcome, AHC - and if I may briefly explain why I feel some level of protection is needed...once an article has been reviewed to top level, any additions that follow will not have been reviewed; therefore, any newly introduced inaccuracies may be read/cited before the err is caught. The onus will fall on the promoting reviewers (presumably whose links are at the top). At least with some level of protection, it will allow the time needed to review & clear the new material. It is not that we are changing "the encyclopedia anyone can edit", it's simply a brief delay from time of edit to time of publication, but only for those promoted articles. Atsme📞📧 19:45, 30 May 2018 (UTC)
I think Dengue fever has been semi-protected since it was published in a peer-reviewed journal in 2014 and that hasn't ruffled any feathers. I see your point about protection. It may further encourage expert collaboration, too. As I say, I'm still making up my mind on this. But it's something for later, anyway. It's by no means a deal-breaker for me. Before I start spending my time and money on this, though, I need to know whether the community will let me do it. --Anthonyhcole (talk · contribs · email) 02:53, 31 May 2018 (UTC)
Semi-protection, perhaps even autoconfirmed protection, is reasonable, but articles cannot be totally locked down from non-admin edits, or basic maintenance is impeded. The highest tolerable protection level might be WP:Template editor, since at least people already doing "dangerous" tech work would still be able to implement markup corrections, category renames, and other "gnome" edits at such articles. — SMcCandlish☏¢ 😼 13:06, 30 July 2018 (UTC)
Hmm, the prominent links could be a hatnote, like the one we have linking to introduction articles, e.g like on General relativity. I think that at-least would be accepted by the community, and having a reviewed version does seem good; I'm just thinking - if we're not using the reviewed version as the default, we're sort of un-endorsing it; at the same time the fact that the reviewed versions would get out of date +general principles means we can't keep articles fixed on that. Not precisely related to this, but looking at the Project Accuracy pitch; most readers are not really critically looking at Wikipedia, and thus I don't think having reviewed versions would somehow make Wikipedia more reliable in the eyes of people Galobtter (pingó mió) 17:29, 30 May 2018 (UTC)
Agreed. Pull up, say, Rotavirus; you'll see a book icon next to the Featured Article star. - Dank (push to talk) 14:15, 31 May 2018 (UTC)
Was also here to say this, we already have Wikijournal where people can send FAs to get peer reviewed by professionals. Having one more similar process would drain the reviewer man-power. FunkMonk (talk) 14:16, 31 May 2018 (UTC)
It doesn't have to be separate - it can be coordinated in those topic areas. There's more to WP than just meds and science. Atsme📞📧 14:24, 31 May 2018 (UTC)
I've added more info lower down, but I thought I'd note here that I like the idea of coordinated mechanisms. I think that scholarly journals are an efficient way of incentivising expert engagement (whether WikiJournals or other journals), but I think that multiple mechanisms can work. E.g. an article gets written via WikiEdu, then undergoes GA, then expert review, then journal publication, then FA... etc. NB, There is also a WikiJournal of Humanities in the works. T.Shafee(Evo&Evo)talk 03:20, 15 June 2018 (UTC)
Agreed with Atsme; having a process already extant that hardly anyone knows about or uses doesn't preclude us from doing more and integrating with the extant process, not competing against it. The final proposal on this will just need to be written to make this clear. — SMcCandlish☏¢ 😼 13:06, 30 July 2018 (UTC)
Jens, Mike, Dank and FunkMonk, I've been watching the development of Wikijournal of Medicine since its inception. My model differs in several important ways from Wikijournal of Medicine. The quality of the reviewers I'm offering is the highest possible. That's not the case with Wikijournal of Medicine. I won't be using the same pool of reviewers as Wikijournal of Medicine so I won't be draining that resource. I'm proposing we offer the Wikipedia reader a link to a simple diff showing them clearly the difference between the last reviewed version and the current version; Wikijournal of Medicine doesn't have anything like this in its model. My proposal includes a prominent link to the "reliable" version. The Wikijournal of Medicine model uses a tiny, essentially meaningless little book icon that no readers will understand without clicking and few will click. The names of all my reviewers will be published and prominently displayed on the reliable version; in the WikiJournal model the reviewers may remain anonymous. I'm not proposing to start a new journal to host the reliable version - the reliable version of an article that has passed review simply sits in the history of the article, available to readers who click the prominent link. There are other important differences too but this list should make it plain these are not the same product.
Let me emphasise this important distinction: The traditional academic publishing model relies on the reputation of the publisher, whom the reader trusts to run a high quality review by anonymous peers/experts, and the reputation of the authors, whose names are all disclosed. Both elements - the reputations of the publisher and the authors - are essential to rigorous science publishing. Wikipedia permits authors to remain anonymous and Wikijournal of medicine allows the reviewers to remain anonymous - leaving only the reputation of the publisher as a guarantee of reliability. That's not enough. WikiJournal has no reputation to speak of yet; in my model we use highly esteemed journal editorial boards with an already-established strong reputation for reliability to select only the very best reviewers. But even if WikiJournal were to develop a reputation rivalling Lancet and BMJ the WikiJournal model would still be inadequate. Humans - with careers and personal reputations and egos to protect - need to put their name behind the article. In my model the experts stake their reputations on the reliability of the reviewed article. I can't stress enough how important this particular difference between the two models is. (Although several of the other differences are very significant too, in terms of epistemology.) ---Anthonyhcole (talk · contribs · email) 15:45, 31 May 2018 (UTC)
I'm not saying that WikiJournal of Science meets all our needs and we don't have to consider other journals. I'm saying that there's already precedent for putting a special symbol (the book symbol) at the top of an article to notify readers that there's been some external form of review, and the symbol serves to send them to that paper. - Dank (push to talk) 16:28, 31 May 2018 (UTC)
Would this idea only be for featured articles?Vorbee (talk) 10:15, 2 June 2018 (UTC)
Yep. I only want to submit our very best work to experts (they're busy people) and the FA process is the best system we have for assessing quality. --Anthonyhcole (talk · contribs · email) 11:39, 2 June 2018 (UTC)
Support Both the concept of the expert review process as well as the inclusion of a link to the reviewed version. I see a suggestion that it can be done with a hatnote. I agree that it should be something akin to a hatnote but there may be a legitimate argument for making it look a little different than a hatnote as the concepts aren't exactly the same. (Generally, a hatnote is going to direct you to a completely different article, and if I'm looking at an article and it seems to be the right subject, I might not pay attention to a hat note, even though in this case it might be the one I'd prefer to see.)--S Philbrick(Talk) 20:11, 2 June 2018 (UTC)
Question – How many articles would this actually affect, in practice? I count 52 FAs in the Health and medicine category, which isn't that many when you think about it. I haven't counted FAs in other "academic" categories like astronomy, but let's be generous and say there are 250 of them. Is it really worth it to create a whole new system for the benefit of 300 articles, many of which figure to be in less need of expert help than B- and C-class articles? It's not like the medical WikiProject is cranking out FAs like crazy; most of the time we don't see any medical articles coming through FAC. Never mind that the vast majority of readers aren't going to bother clicking on a small icon that goes to a potentially years-out-of-date version of an article (they don't do it often for the talk page links to the version that passed a given process), or that experts might propose edits that would damage an article (not knowing our norms for a given topic). Without enough work on relevant articles, I fear that such an idea wouldn't be worth the effort. There's no point in pushing for experts to sign up for a review service if they won't have anything to do. Giants2008 (Talk) 00:49, 4 June 2018 (UTC)
Thanks, Giants2008, for your thoughtful response. As Johnbod suggested above, there'll be very few - at least to begin with. There are relatively few medical FAs and very few new ones rolling out.
There's no system or infrastructure required to implement this service - it piggy-backs on the peer-review process already in place at all the top journals. It will take a bit of my time to commission each review, and I'll supervise the review to make sure the reviewers aren't proposing off-policy changes (like adding dose information to drug articles). Scan the right hand column of this review, where you'll see this happening. I'm more than willing to put that time in.
You mention "... the vast majority of readers aren't going to click on a small icon ...". That's the point of this thread. It won't be a small icon. It'll be a prominent link of some kind. Galobtter, above, suggested a hatnote and Sphilbrck supported a hatnote or something like that. I'm not wedded to any particular format for the links, as long as it's not ugly, fits our style and is obvious to the reader. The hatnote (or whatever it ends up being) will only go up if a version of the article has passed the experts' review. --Anthonyhcole (talk · contribs · email) 10:08, 9 June 2018 (UTC)
Mixed Support encouraging such reviews, oppose fossilizing the reviewed version with a diff anywhere, especially in the article space itself. There should be no marker on the article text, and I'm leery of even a talk page notice, which would tend to encourage WP:OWN-type issues and fossilization of articles. I like that experts want to help review our articles, I don't like that someone will use this to prevent future improvement. --Jayron32 01:50, 8 June 2018 (UTC)
We're already linking readers to a peer-reviewed version of our articles, where one exists, Jayron23. See Dengue fever. Click the little book icon in the top right hand corner. This proposal is to make that link prominent and obvious when named experts perform the review and the review is managed by an established, highly regarded publisher with a strong reputation for reliability (a publisher who publishes highest quality reliable sources).
Experts of the calibre I'm talking about won't be interested in reviewing an article if the reviewed version is going to disappear forever into the article's history the moment another editor saves a revision.
Regarding "someone will use this to prevent future improvement", experience does not bear this out. Take Dengue fever, for example. It passed peer-review in 2014. I made this simple diff in 2016. The topic evolved over that time and the article kept up. None of those editors seem to have been remotely concerned about offending the reviewers or messing with a sacred cow. Even if someone does feel that way, Wikipedia's policies and guidelines prevail.
As for the reviewed version getting stale: above, Johnbod recommended a time limit on how long we should leave the link up, and I agree with him. --Anthonyhcole (talk · contribs · email) 10:54, 9 June 2018 (UTC)
If they're not interested in reviewing articles that will later get improved, that's what Wikipedia is'. If you want to have some permanent, unchanging encyclopedia written by experts, find somewhere else to do it. --Jayron32 11:55, 10 June 2018 (UTC)
Could you expand on that a little for me please Jayron32? I'm not proposing an unchanging encyclopedia. Editors will still edit the public-facing article. It will evolve just as Dengue fever did after its review. I can see you're strongly opposed to this but can't yet see what your objection is. What's the down side you're seeing that I'm not? --Anthonyhcole (talk · contribs · email) 02:42, 11 June 2018 (UTC)
Support: I think that there is room for several models of trying to engage expert review of articles. I agree that attracting high-quality reviewers is essential and collaborating with an established journal such as BMJ is a good way to achieve this. I think a hatnote and category would work well, or possibly a note at the top of the references section (e.g. Rotavirus#References). I agree that just the symbol alone is insufficient (most readers are similarly unaware of the FA star). As well as simple diffs in markup, the visual diffs viewer is pretty good these days or even lust a link to the version after review (same as done with GAs and FAs).
I think that locking or any sort should be handled in the same way as it would for any FA. For example, Circular_permutation_in_proteins has undergone several changes since its publication in PLOS CompBiol. Of course, thew ideal in my point of view would be for BMJ to publish the article if it passes their peer review standards, but that would of course rely on them being happy to publish CC-BY-SA and comfortable with large group authorship attribution, which is uncommon in many journals.[1]
Mostly PLOS CompBiol.,[2]Open Med.,[3]Wiki.J.Med.,[4] and Wiki.J.Sci.[5]
RNA Biology[6] and Gene[7] have both also added peer reviewed content to Wikipedia by parallel publishing with review articles
Here is a review of some of the interactions between Wikipedia and expert peer review (with a focus on dual publishing)[1]
I don't think that there will be any great need to lock the pages after expert review (or at least, no more than for FAR). — Preceding unsigned comment added by Evolution and evolvability (talk • contribs) 03:13, 15 June 2018 (UTC)
Oppose, with an emphasis on my conflict of interest as creator of Wikiversity:WikiJournal of Medicine, where the WikiJournals can be regarded as competitors to this idea. I do think the WikiJournals serve the main purpose of this proposal already. It is already aiming at having the quality of the reviewers to be "the highest possible". If the problem is that the WikiJournal review symbol is too tiny, I think a better solution would be to make that one more prominent. As for having a latest version and a last reviewed version, I think we already have this mechanism in the form of Wikipedia:Pending changes. And as for a system for reviewers to clearly mark their contributions to articles, we already have Template:External peer review (its usage can be seen on its WhatLinksHere). Regardless, I support having experts review Wikipedia articles, I just don't think we need yet another system for it. Mikael Häggström (talk) 04:45, 16 June 2018 (UTC)
Mike, I won't support putting a prominent link at the top of a Wikipedia medicine article, linking the reader to a version that has passed review organised by WikiJournal. As discussed recently, here, WikiJournal is not a reliable publisher and its journals are not reliable sources by the standards of WP:MEDRS. --Anthonyhcole (talk · contribs · email) 10:01, 3 July 2018 (UTC)
I accept that, and by the same reason I don't see why this proposal should be allowed to have even more prominent links at the top of mainspace articles. Is there anything making these reviews more reliable than those of WikiJournal? Mikael Häggström (talk) 10:10, 3 July 2018 (UTC)
Here, I see support for prominent links to the reviewed version when the review is conducted under the model described above. If you want to put prominent links at the top of articles, linking to WikiJournal, open a discussion like this one and get input from others. I'll elaborate on my opposition there, if you like, Mikael. --Anthonyhcole (talk · contribs · email) 09:13, 9 July 2018 (UTC)
Support: Expert peer review in Wikipedia is currently a marginal practice, and it would be good to test various mechanisms. If there were several mechanisms, they would probably not compete with one another, but rather help one another by making the practice more mainstream. And I do not see what harm would be done by linking to the reviewed version and the diff. This said, I fail to understand precisely what is the aim of the proposal. If it is to improve the quality of science articles in Wikipedia, why start with the ones that a priori need it the least, i.e. the featured articles? (In contrast, the rationale for WikiJournals is straightforward: incite academics to contribute more to Wikipedia, by making Wikipedia-style articles count in publication lists. This is why I am participating in WikiJSci.) Sylvain Ribault (talk) 19:41, 16 June 2018
A key element of this proposed service is the involvement of the editorial boards of the most prestigious science and medicine journals in reviewer recruitment, and the selection of field leaders and other recognised experts as reviewers.
They simply won't take on the review of an article that needs a lot of work, any more than they would accept such an article for review and publication in their journals. --Anthonyhcole (talk · contribs · email) 03:36, 18 June 2018 (UTC)
Hi Anthony, I have two questions. First, is this proposal for science articles only? Second (the perennial problem), how are you going to persuade the reviewers to do it? SarahSV(talk) 04:03, 18 June 2018 (UTC)
Personally, Sarah, I'm not taking this any further than medicine. Medicine is a fairly "hard" (as opposed to soft) topic that's underpinned by a great deal of rigorous publishing and robust systems for consensus-building. If it works and is useful in medicine, then it might work and be useful in the hard sciences, too, but I won't be taking it there. I don't know if it will work in softer topics like the social sciences, history and literature, and it won't work for the vast majority of Wikipedia topics that aren't well-supported by academic publishing.
It's the editor-in-chief of the relevant journal/s who needs persuading. Then their managing editor goes through her Rolodex and offers the gig to the relevant experts.
The editorial teams at the top relevant journals have the expertise, experience and relationships to do this well.
IF we begin with and stick with only the most highly-regarded journals, and IF they consistently come through with stellar review panels, I hope experts will soon become proud to be asked to review Wikipedia articles, and it will be something they'll put in their resume. IF that's how it unfolds then, as the reputation of expert-reviewed Wikipedia articles grows, the managing editors may find it easier to recruit the best reviewers. We'll see. It's early days. --Anthonyhcole (talk · contribs · email) 05:08, 18 June 2018 (UTC)
Anthony, what do you see as the benefit for the editors of the journals? They will have to reward the reviewers in some way. It used to be easier to get academics to do reviews. But the more we grew, and the more money the Foundation became associated with, the less eager reviewers have been to volunteer their time. I can imagine that someone might pay reviewers (e.g. some charitable medical foundation), although there's a risk that the payer would interfere editorially, and we would face the unfairness of reviewers being paid while writers are not. SarahSV(talk) 01:29, 23 June 2018 (UTC)
Sarah, many of the top journals are published by scholarly societies and professional associations that have, as a part of their mission, education and the dissemination of knowledge about their specialism. If we present the reader with a prominent link to the fact-checked version, it'll be fairly easy to convince those journals it is worth the effort to manage a review, I think. The reward for the reviewers is (1) altruism, like you and me, and (2) prestige, per my last paragraph above. This latter isn't an afterthought. It's a key element of the model. I expect a Wikipedia medical article reviewed under this model to be regarded as the most reliable source on the topic, period. And I expect scholars and experts to see an invitation to review as a very visible public acknowledgement of their standing in their field.
As for money:
There is a role for a very experienced Wikipedian in each review, liaising between the experts and the writers: (1) ensuring the expert suggestions are compliant with our policies, (2) finding reliable sources that support proposed changes, (3) updating the article in collaboration with other editors in response to the review, (4) re-presenting the updated article to the reviewers for endorsement and (5) formatting the "reliable version" with relevant templates, etc. This is pretty onerous, tedious, exacting work and I can see it becoming a paid role at some point.
I would be very disappointed and a bit surprised if it turned out the reviewers needed paying. I think, I'm pretty confident actually, it can be avoided.
Any money supporting this effort can't come from the WMF because of perceived (at least) conflict of interest. There are a number of non-profits out there with education in their remit. Anthonyhcole (talk · contribs · email) 09:39, 23 June 2018 (UTC)
I'm thinking about the consequences of Google linking searchers directly to the fact-checked version. That could cost us a lot of editors, like me, who love clicking publish. I'd lose interest in editing if my edits took months or years to appear. A few years ago, Google committed to privileging reliability over popularity in its search results. If this journal-driven expert review service becomes a thing, I'll make sure Google knows the harm direct-linking would do. --Anthonyhcole (talk · contribs · email) 12:49, 25 June 2018 (UTC)
Support. Only expert reviewers who spend many hours every week doing research in their field of expertise, who read vast numbers of papers can have a good judgment to weed out subtle problems with review articles written by non-experts. A review article written by scientists is always based on a huge amount of literature research, this is obviously not the way we go about writing articles here. We cruise on autopilot by summarizing the contents of review articles, but this can lead to inaccuracies. The main problem here is caused by our reliance on the top journals like e.g. the BMJ, the Lancet etc., while these journals only publish a small percentage of the research results. A lot more is going on behind the scenes, the vast majority of the relevant research for any particular topic is published in technical journals that we cannot possibly keep track of. While our articles will end up presenting most of the relevant information, things tend to go wrong with giving the right weight to different ideas. Different ideas that are not considered to be equally likely to be true, tend to get presented in a more equal way in the top journals, because one wants to see what the most rigorous evidence tells us and not be biased based on the previously known less rigorous evidence. That's a good way to eventually get to the rigorously verified truth, but it may sometimes mislead lay people about how researchers in the field think about the different ideas. Count Iblis (talk) 15:42, 25 June 2018 (UTC)
Strong support — Per proposal/idea, an expert's experience and knowledge would be much appreciated in technical/non-technical articles written and/or edited by non-experts. This is a no-brainer and is easy to support, in all honesty. Regards, SshibumXZ (Talk) (Contributions). 19:44, 22 July 2018 (UTC)
Support, with integration with WikiJournals, so we combine the related efforts. It's unfortunate that the proposal wording didn't make it clear this is not a competing/replacement idea. Anyway, this would clearly be a boon to the quality of certain kinds of articles and thus a service to readers, with a secondary benefit of reputability of Wikipedia with regard to certain topics. After some "practice" on stable stuff, it could even be used to shut down pointless WP:FRINGE dispute in the long run (e.g. push articles on vaccination, electronic cigarettes, etc., to FA quality, then peer review them and protect them from typical drive-by PoV edits that swarm around these topics. As I noted above, I don't support the idea of protecting the reviewed articles beyond auto-confirmed or maybe template-editor protection at most, or it'll interfere with routine maintenance. Semi-protection to auto-confirmed protection at least would be well-justified. — SMcCandlish☏¢ 😼 13:23, 30 July 2018 (UTC)
Oppose – Sorry, I don’t think this is a good idea at all. I have never met an expert who didn’t want to promote their own views; particularly experts in the fields of medicine and science where making a name for oneself is so important. And I suggest that those willing to undertake the task are going to be precisely the sort with an agenda, who are less likely to tolerate the inclusion of alternative viewpoints. In short they can’t be relied upon to be neutral. And you are asking to highlight it as something better or more accurate.
No, far better to have an article that has been reviewed (through the usual WP:BRD process) by a multitude of reasonably well-informed amateurs than a single partisan expert. Nor do I think it ought to be protected. We have too much protection as it is without locking down more articles.
And lastly, because this isn’t feasible for all articles (who are we going to get to give an expert opinion on Halo 3? Some 14 year-old gamer?), it will create a two-tier encyclopaedia where only a few topics are able to attain a level of "better than featured article".— Preceding unsigned comment added by Ykraps (talk • contribs) 12:17, 9 August 2018 (UTC)
Support and propose variant ideas. A long, long time ago, I used to contribute a bit to the development of the Citizendium, which now appears to be more-or-less fully inert, and I think it had some good ideas, though I also think it took some things a bit too far, and thus I'd think some form of median between it and the existing anarchic, expert-averse Wikipedia environment might have some merit and this proposal therefore looks attractive to me. But I would say, taking some cues from that defunct project, that ideally the experts to review should be Wikipedia editors, not just those from outside (though an external review, if it exists, might be an acceptable surrogate that could waive the process), and there should be some form of mechanism by which their expert status could be confirmed (what defines "an expert" is difficult but could be hashed out in a similar manner to how other guidelines/policies have been made, e.g. WP:Notability which I also helped work on in that prior eon.), and the review should be effectively the final step in approving featured status. I think that'd provide a decent median - it gives a special place that experts could have which is one of the things WP has long, long been criticized for by more than just the creators of the CZ and thus might help to attract more of them, yet still retains almost entirely the open quality of WP that made it able to get to the point it has been able to (and which CZ greatly restricted - in particular I think their onerous registration process was one of their worst mistakes.). And moreover, it'd require a panel (say at least 3) to approve, not just one, with suitable distance due to the aforementioned concerns about POV pushing, i.e. they should not be colleagues outside of WP, not have any conflict of interest in the specific article subject (e.g. work for a company whose article is the one submitted to them for review), etc. Also, I'd renforce the suggestion hinted above that once articles are made featured, they should be protected (not just semi), with any new input going to the article Talk page. It's very often been the case that these articles have later drifted and lost their prior quality and that is a detriment to Wikipedia. Not everything needs "continuous improvement" and I think the CZ people were right to realize that eventually there comes a peak and then things start to get worse. It might also be possible to have another feature or process such that for articles which would be considered very close to this level could be passed to such a panel of approved expert WP editors to work on bringing it the "last few yards" so to speak and then finally mark it, provided that such would not take too long (i.e. could be done over a period of maybe 7-14 days in spare time). mike4ty4 (talk) 11:43, 19 August 2018 (UTC)
I'm not convinced that the GNG is the proper threshold for creating biographies of minors. We have some rules already (WP:YOUNGATH) that exclude certain coverage and articles. I think this should be stronger.
My initial thought is to exclude all biographies of people under the age of 13, but that would have some problems; Prince George of Cambridge being the most obvious one. Perhaps that could be perhaps merged to a semi-bio Family of William, Duke of Cambridge. I'd also like to have a rule that simply meeting the GNG is insufficient for a person under the age of 18 to be a suitable encyclopedic topic; they must have a credible claim of importance or significance (such as meeting WP:ENT, being in the Olympics, winning a Nobel Prize, etc.). Some language regarding whether being the youngest person to do XYZ would be necessary, and there are almost certainly multiple other corner cases.
Is it feasible to create such a proposal? And, if created, is there a chance there would be consensus to implement such a proposal? power~enwiki (π, ν) 02:28, 19 August 2018 (UTC)
I have some doubts. My impression is that problematic biographies of minors usually don't meet GNG but get included anyway for meeting the more specific notability guidelines. Jo-Jo Eumerus (talk, contributions) 08:47, 19 August 2018 (UTC)
Counterproductive. If someone has amassed GNG-levels of coverage even before their prime, that only makes the argument from GNG stronger vs. someone who inches above GNG on their deathbed. – Finnusertop (talk ⋅ contribs) 09:08, 19 August 2018 (UTC)
Pointless per Finnusertop.simply meeting the GNG is insufficient for a person under the age of 18 is the worst, as GNG is king, only disputed by NOT folks.Thanks, L3X1◊distænt write◊ 14:52, 19 August 2018 (UTC)
Only aspect where being a minor should carry a lot more weight is in regards to BLP and privacy, using a lot more care if we need to name or document minors. A minor that has recieved GNG-level coverage for their merits that otherwise doesn't fail something like BLP1E has the same right to having an article as a non-minor. --Masem (t) 14:59, 19 August 2018 (UTC)
I haven't seen a clear articulation of the problem. I agree with Masem that we have to be particularly cognizant of privacy issues when it comes to minors but at most, that sounds like a minor tweaking if it's not already codified.--S Philbrick(Talk) 20:15, 20 August 2018 (UTC)
This AfD is an example of the type of discussion I'd like to short-circuit with a clear rule that no amount of coverage without any claim of importance or significance will meet WP:GNG. power~enwiki (π, ν) 20:27, 20 August 2018 (UTC)
Maybe the best way to deal with it is repeat what User:Ansh666 said in the AfD: meeting GNG .. doesn't mean that we have to have an article, particularly if it's overridden by things like a WP:NOT criteria or BLP/BLP1E, especially in the case of a minor. We really need to get away from this notion that meeting GNG means a subject must have an article (or must be kept at AfD). That's really not supported by the guideline. Sure, it's usually a good indicator of suitability, but it's hardly the only consideration in play. -- GreenC 21:04, 20 August 2018 (UTC)
There was no closing comment, but the gist of it seems to be WP:PROMO and WP:CRYSTAL, so it's a WP:NOT issue. WP:NOT always overrides WP:N, so there's no need to reinvent the wheel here. There is plenty of coverage about today's weather, but we won't create an article about it because it would be very WP:NOT. – Finnusertop (talk ⋅ contribs) 21:06, 20 August 2018 (UTC)
An amendment to the way in which topic bans are issued out by Wikipedia Administrators
It is no secret that I was recently topic banned on Wikipedia (see Incident 989). My personal view is that the ban was too harsh, although I will not challenge the ban until at least six-months have expired, when, hopefully, I will then submit an appeal to have the topic ban removed.
What has mostly struck me is the way I was attacked by so many people, each one trying to find some fault with me (which I'm sure no one is without), and whenever they found something on which they could possibly hold to my discredit, they railed on me - while willfully overlooking the preponderance of good edits by this editor to point out only the bad. Sigh. I am the first to admit that no man is unassailable, and that I have my own shortcomings and faults, and perhaps even cannot see my own disabilities. However, does this warrant a topic ban on a subject that is close to my heart? Only God knows.
I have thought about my actions, and have even apologized for any wrong that I may have caused, but this was all to no avail. The topic ban was issued against me, and I have only to accept it and perhaps learn from it how to deal more courteously with my fellow co-editors.
With that said, I have also thought about our current Wikipedia policy outlined under Wikipedia:Banning policy. I noticed something there that struck me as unusual. It says in the second paragraph: "Bans are a possible outcome of dispute resolution. They may be imposed by community consensus, by the Arbitration Committee, or by administrators (in certain topic areas)" [END QUOTE]. It puts power into the hands of the community to decide who should be punished or meted out disciplinary measures for alleged wrong-doing. Unfortunately, some of our community members are themselves inexperienced editors, or who may have issues with levity, or else those who lack jurisprudence. I raised the idea that perhaps the Wikipedia:Banning policy needs amending. My suggestion was to amend the second paragraph, so that it reads: "Bans are a possible outcome of dispute resolution. They may be imposed by community consensus after an unequal number of non-involved administrators (acting as judges) have read the deliberations made by an equal number of advocates and prosecutors - either for or against disciplinary actions being taken, or by the Arbitration Committee, or by administrators (in certain topic areas)."
In talking with my fellow co-editors, some thought that the idea was too far-fetched, thinking it would not gain much traction here. My view is that what have I got to lose? We can try. If it fails, it fails.
The reasons stated by me to them were as follows:
It is my view that when incidents are brought before the Wikipedia:Administrators' noticeboard for a decision, due to the overwhelming number of incidents, that some minor incidents may occasionally be brought, haphazardly, before the board without prior consideration or thorough inspection of the edit history of the person in question against whom the complaint is made. By the nature of the Administrators' noticeboard's set-up and arrangement (based on current standing-laws governing its conduct), arriving at a fair and equitable (impartial) decision/verdict by means of "community consensus" may, in fact, be sometimes compromised if, let's say, those editors attracted to the site and who comment on the particular case are either inexperienced, or display toxic tendencies towards their fellow-editors because of their preconceived notions about that editor. Wherefore, the best way to handle incidents brought before the Administrators' noticeboard is to have an equal number of advocates and prosecutors (arguing for and against the editor), while the administrators rendering the verdict will be made-up of an unequal number of three or five, and their decision - based on the arguments heard from the advocates and the prosecutors - made by a majority vote of 2 to 1 (in the case of there being only 3 administrators). In this manner, we can avoid miscalculation of an editor's behavior or intent. Of course, this will require setting up a team of editors who will agree to work in the capacity of advocates (working to highlight the editor's good qualities), and another team who works solely as prosecutors (looking for the editor's bad qualities). Perhaps Wikipedia can compile a list of willing editors who will take in these roles, and when they are summoned to respond to a specific incident, will be given 48-hours to respond.
Perhaps, too, it can be left-up to the Arbitration Committee to decide which direction they wish to take in each case brought before them for resolution, since, obviously, some editors are clearly problematic. Administrators should also be given the opportunity to forego such a panel of advocates and prosecutors, if it's clear from the outset that the editor has been very disruptive. I humbly submit this for your review, wishing us all the best.Davidbena (talk) 00:54, 17 August 2018 (UTC)
You should remember that at WP:ANI one mistake is no mistake (except for obvious WP:NLT). It takes a pattern of mistakes to ban anyone. If it becomes too tedious to ban editors, Wikipedia will suffer: administrators are not that many, many of them are busy in real life and usually they only ban someone when the need for it becomes fairly obvious. You should know that the meek will inherit Wikipedia. I am so blunt that many see me as offensive, yet I would never start WP:ANI actions against anyone would has not clearly violated WP:RULES, wrote WP:CB in articles or has expressed appalling viewpoints. So, I am quite meek, unless provoked. I advise you to avoid all quarrels unless they are quite necessary. And, yes, Israel/Palestine matters are covered by discretionary sanctions, so bans will be imposed quite easily for violations which would otherwise be unimportant. Admins have to deal with plenty of disruption in that area, so they are biased for precautionary banning. Also, you should never leave the impression that your excuses are just formal and that you will thus persist in the behavior which you have excused for. Always require lifting your ban as having been caused by your own actions, instead of blaming others for your ban. As for having brought you before WP:ANI, I have no grudge against you: the best way to get along with me is obeying WP:RULES. Tgeorgescu (talk) 01:52, 18 August 2018 (UTC)
There's probably good cause to reign in ANI somewhat. It can be a disorganized free for all. It can be disorganized and chaotic. However what you propose is cumbersome and it seems to be an off the cuff reaction to what to you. Not exactly focused on improving anything. One might suggest a more organized format standard for discussion at ANI (note that arbcom use a specific format for organization.) One might also suggest excluding matters related to any active arbitration case from ANI (ARBCOM is brute force on wikipedia there to break the back of issues that the community has been unable to resolve by some other means. So let them handle matters that were under arbitration.) These are two generic ideas. One to generically improve ANI. The other would meet your goal with out sanctioning actually wikilawyers and making ANI to cumbersome to be useful.-Serialjoepsycho- (talk) 08:24, 18 August 2018 (UTC)
Thanks, User:Serialjoepsycho and User:Tgeorgescu. I appreciate your feedback. I agree that whatever the outcome, we should not make dealing with complaints more cumbersome upon ARBCOM AN/I than what it already is. Frankly, I know very little about how the system works, but what I've seen in my own case, it does seem to be wanting. There is room for improvement on AN/I. I have done my utmost best to follow by the rules set by Wikipedia, and still, look at what has happened to me. Anyway, the matter has certainly given me time to reflect on my overall actions and how I should be more humble and meek before our fellow co-editors, since what we do here is a collaborative effort. We are all interested in the well-being and success of our online encyclopedia.Davidbena (talk) 20:14, 18 August 2018 (UTC)
I think you're still missing something: WP:AN and WP:AN/I are not ArbCom territory -- they have nothing to do with the arbitration process, except that reports and behavior there (like everything else on Wikipedia) can be used as evidence in an arbitration case. Arbitration is the very last step in dispute resolution, while the Administrators' noticeboards are a middle step. ArbCom doesn't control the Administrators' noticeboards, the community does -- which is why your request at ARCA was denied and I suggested that you take it here, to a community discussion board.I understand that changing the way AN/I works is your goal, but you need to get rid of the idea that doing so has anything to do with ArbCom. Beyond My Ken (talk) 21:08, 18 August 2018 (UTC)
Beyond My Ken, Okay, that was my mistake. I have since crossed-out ARBCOM and put in AN/I. So, if you would please excuse my ignorance, are you saying that this is not the proper venue for discussing these issues? If not, what is the proper venue for raising these issues before a "community" discussion board?Davidbena (talk) 22:38, 20 August 2018 (UTC)
No, I think this is an appropriate place. Beyond My Ken (talk) 00:18, 21 August 2018 (UTC)
So, perhaps as a first step in improving the effectiveness of the AN/I and to avoid making future mistakes or misjudgments, I (in all my frailness and vulnerability) would like to suggest to our fellow co-editors who handle such arcane issues that any contributing editor who wishes to state a grievance against the person unto whom a complaint has been lodged that they (his accusers) make sure that they have at least done the following: (1) If, for example, the person unto whom a complaint is being lodged is accused by them of infringing either WP:IDHT and WP:CIR (as I have been accused), or any other stated policy, that they cite at least THREE diffs to prove that this has indeed been the case, or what can clearly be seen as a recurring trend with him or her. If, however, they cannot come-up with three diffs to prove such an allegation, the allegation will be dropped, in consideration of the fact that the editor (against whom a complaint has been lodged) has mostly worked collaboratively and in WP:Good Faith with all the other editors on Wikipedia. A single diff should never be indicative of an editor's conduct as a whole. Is this reasonable? Of course, this stipulation would not apply to physical threats, vulgarity or vandalism - which even once would be enough to censure that person.Davidbena (talk) 06:28, 21 August 2018 (UTC)
I just want to note that the ANI discussion cited by the OP was not a standard ANI discussion leading to a standard ANI ban. Those usually are handled after many reports, over many years, where someone is repeatedly creating problems after many less-strident methods are used to cut down on disruption. The OP was not banned under that normal mechanism; instead the ban was enacted by invoking WP:ARBPIA; it was a community discussion, true, but it was a topic area under Arbitration sanction, and in such events, the patience of the community is much shorter. Per WP:ARBPIA, sanctions are not expected to take the normal course of events, but are expedited to minimize the high level of friction at Palestine-Israel articles over many, many years. If the OP were bringing up a ban, or a series of bans, unrelated to such a contentious area, it would represent what more typically happens at ANI. Instead, since the ban was an ARBPIA-related ban, it's easy to see why the normal process was short circuited. --Jayron32 18:09, 22 August 2018 (UTC)
User:Jayron32, thanks for interjecting here. I'm not arguing against the specific topic ban, but rather at how some of our Wikipedia contributors accused the OP of matters totally unrelated to the topic ban, such as how, in one case, an editor complained about how he discussed a matter with Arab contributors from Yemen on the Ali Abdallah Saleh Talk-Page, or how another editor complained about how the OP, in her view, did not "inwardly" accept the community consensus concerning what was considered a Reliable Source, when, in actuality, the editor did indeed accept the consensus by deleting those old sources. You see, in that particular AN/I everyone threw out different reasons - some unrelated - for why the OP should be topic banned! When the administrators tallied all the "votes" together they decided on a topic ban. Sigh. This alone should be reason enough to revamp the way things are handled in the AN/I. I, for my part, will be more considerate to my fellow editors in the future. BTW: The WP:ARBPIA-related discussions were always a two-way street and handled, for the most part, with utmost courtesy. Davidbena (talk) 02:32, 23 August 2018 (UTC)
Table of Contents entry for Closed discussions
Taking a look at WP:AN, with so many closed discussions. I felt it would be appropriate if a tag in the Table of contents (ToC) indicating that the thread is already closed can be added. (may be an extra word such as (closed/resolved) or colour coding for open vs closed threads in the (ToC). I believe it Will save some time for the admins and users on several noticeboards who can then jump in directly at the open threads and contribute. --DBigXrayᗙ 20:25, 22 August 2018 (UTC)
I suggest WT:AN instead. This is exactly the kind of thing it's intended for. ―Mandruss☎ 20:30, 22 August 2018 (UTC)
This is such a great idea. I'll write the user script. Enterprisey (talk!) 22:58, 22 August 2018 (UTC)
User:Mandruss AN is just one example, This idea is applicable not only to AN on Wikipedia but a lot more pages wherever the discussions are regularly closed. Eg. AfD. (edit conflict) thanks for the support Enterprisey --DBigXrayᗙ 22:59, 22 August 2018 (UTC)
Pay writers of articles
Hey everyone! My proposal is this: Writers of articles (in the same wiki model) paid by the Wikipedia donation fund.
The reason for that is to improve the quality of the articles, by encouraging people to dedicate more TIME to write them.
And I have some suggestions for the details of this payment. I think the payment must be monthly, and involve six factors:
F, The total fund of Wikipedia in a month.
PC, The percentage of contribution of a writer in a current article.
VC, The total time that the current article was visualized in a month.
SC, the average stars that the current article received by the users (and that stars are a new suggestion).
VT, the total time that all articles in Wikipedia were visualized in a month.
ST, the total average stars that all articles in Wikipedia received in a month.
Then, the total payment to a writer in a current article will be:
F * PC * VC * SC * 1/(VT * ST)
A note on the meaning of ‘current article’: If, say, there be three editions in an article within a month, there will be three accounts for pay for that article, that is, three “current” articles, each specifying the percentage of contribution, the total time visualized, and the total stars received.
Also to avoid vandalism, I think must be an easier way to protect an article. Maybe a minimum of average stars given by a minimum of users could protect it. In addition, someone that makes a new edition or write a new article may ask for protection, and then the article will be automatically protected until a minimum of users gives less than a maximum average of stars (say, less than four). And the administrators, who can edit a protected article, may become an administrator by the same easy way: writing a minimum of articles with a minimum of stars given by a minimum of users.
Obs: I searched for proposals like mine, but I didn't find. So, forgive me if it is somewhere. — Preceding unsigned comment added by Ea8698 (talk • contribs) 11:03, 21 August 2018 (UTC)
We are a volunteer project. Motivation of volunteers is very different to motivation of paid staff, and combining paid and volunteer staff is notoriously difficult. The only ways I have known it work well are when the paid staff are recruited from the volunteers, the paid staff are there to do things that volunteers want to have happen but aren't volunteering to do, or the paid staff do things that the volunteers are not qualified to do. It may be possible that there are areas of the pedia where we could employ a few writers to improve areas that the volunteers identify as low quality articles that are a high priority for us. But it would be very difficult to agree that. As for your proposal, consider the income that Wikipedia currently has and the hundreds of thousands of contributors, I don't see how we could start such a payment system without it doing more harm than good, even if income increased to the point where we could pay a hundred million a year to contributors, that would average less than a hundred dollars a year each. Simply agreeing who had contributed what percentage to an article, and protecting against editors getting friends and family to add stars to articles that earned them income, would be huge time sinks and causes of argument in your proposed system. As for your proposal to change the protection system; I suggest you read the current policy and some of the warnings about article ownership, then if you still want to make such a proposal, give it a separate thread to your proposal about paying writers. ϢereSpielChequers 10:19, 22 August 2018 (UTC)
Also, why would we pay people when we've already gotten all of Wikipedia without paying anyone. To just start paying people for work they already did for free seems like a pointless idea. I'm not sure what the money is supposed to improve. --Jayron32 15:25, 22 August 2018 (UTC)
It’s a neat idea toward bringing more editors to Wikipedia and raising time investment, but I just don’t think this is the way to go at the moment. Jayron32 has a point; it’s been a bit slow but we do have a lot of fantastic work in this encyclopedia, and I think it makes for a better community where everyone is donating their time without a “corporate hierarchy” based on payment - if someone was making more or less money than you, you’d listen to them differently. That being said, I always appreciate a good attempt to drum up more activity here. Red Phoenixtalk 17:53, 22 August 2018 (UTC)
The barrier-to-entry at Wikipedia isn't any lack of pay, it's two issues. Firstly it's mostly already written. All of the low-hanging fruit has been picked as of probably 10 years ago, and what's left to do is either a) basic clean-up of existing, low-quality articles (grammar, spelling, referencing, organization, etc.) or b) missing or stub articles on more obscure topics that few people have an innate interest in. People get to Wikipedia and want to be useful, but they find what they want to do, which is to create a brand new article about something they know about, and they find there isn't that much need for that. Secondly, and perhaps a greater problem than the first, is that Wikipedia's arcane, complex, and rigid rules, and existing unhelpful power base, tends to drive away noobs by treating their earnest, good-faith work like shit. People would stick around and would learn the rules if we actually tried to help them become better editors, instead of rejecting or deleting their contributions with no real explanation and no attempt to help them do it right. Pay would only exacerbate these problems. --Jayron32 18:00, 22 August 2018 (UTC)
Only about a quarter of our new editors start trying to write new articles, the vast majority want to improve existing ones. as for arcane rules, the big change was in requiring editors to cite sources when adding new material. That change was necessary, but it has changed the pedia and aged its editing community. To those who support such standards the consequent loss of new and especially adolescent editors is an acceptable cost of quality. Even those of us who criticise the way it has emerged don't necessarily criticise the change so much as the way it has happened. Yes unsourced edits are often treated like shit, and the editing and on boarding processes don't spell out to newbies that unsourced edits will probably be reverted without any consideration. But sourced edits are a different story, especially as much of the early community has moved on, so the "unhelpful powerbase" of editors who watchlist articles and attempt to WP:OWN them is smaller relative to the number of articles than it was a decade ago. ϢereSpielChequers 09:36, 23 August 2018 (UTC)
JEREMY LINDSAY 77 SOUTH WASHINGTON STREET SEATTLE INTERNATIONAL BLVD WASHINGTON 98402`9989 904C SOUTH TACOMA WAY SEATTLE WASHINGTON TACOMA 2139 SOUTH L STRE=ET 98405 MAILINGS BANK ACCOUNT qUAL STAR CREDIT UNION 252 UNION LABORERS ownership, then if you still want to make such a proposal, give it a separate thread to your proposal about paying writers. ϢereSpielChequers 10:19, 22 August 2018 (UTC)
[reply]
Also, why would we pay people when we've already gotten all of Wikipedia without paying anyone. To just start paying people for work they already did for free seems like a pointless idea. I'm not sure what the money is supposed to improve. 63.147.207.130 (talk) 19:40, 1 November 2022 (UTC)
I think volunteering is a great thing, one that can certainly make the world a better place. But it has its limits. One person who hasn’t money enough will not spend a long time doing volunteering. And that’s my concern. I think payment could speed up the quantity and quality of contents, by allowing people to spend more time writing, especially some few talented writers (or teachers). There is no doubt that Wikipedia today has several articles of amazing quality, at least in English. But I think there is still a lot of important work to do in several areas, especially in other languages. And precisely to accelerate this work, I think payment would be a good idea. Forgive me if I didn’t notice some obvious counter-arguments. Ea8698 00:02, 23 August 2018 (UTC)
There are a lot of arguments already in this section, let alone the archives - shifting from a volunteer model to one more like the Encyclopaedia Britannica is one of those perennial topics that litter the archives. But the simplest is still that we can't afford to pay a reasonable amount to everybody who we need, so any proposal to pay some writers has to address the issue of how you do this without losing more volunteer writers than you gain through pay. That's a hard problem with no easy answers. ϢereSpielChequers 09:36, 23 August 2018 (UTC)
There are many questions about payment that need further elucidation. I understand that it is a delicate issue. But for now, I won’t go further in that. I just wanna tell that what first motivated me to propose payment was my personal desire to work in didactic contents for basic education, work which will take a considerable amount of my time. Despite there is a lot of content of this type, I think they still can be improved. And I also think that Wikipedia is the best place to get together these contents, the best place to be the center of education. But now I’m not prepared to do that. If possible, let’s put my proposal as archived, and when I’m ready and with more persuasive arguments, let’s revive this discussion. Can it be like this, guys? In advance: thank you so much for your attention! Ea8698 15:38, 23 August 2018 (UTC)
Timed reminders/notifications
From time to time I propose things on talk pages (or similarly via, say, Mergeto/Mergefrom templates on articles) with the intention of going ahead at a suitable future time, typically a few days or a couple of weeks. (Unless, of course, there is debate whose consensus is against.) Very often, there is no feedback whatsoever; this I would intend to interpret as tacit approval to proceed. But... then it slips my all-too-human mind and I forget to follow up.
Is there some sort of reminder-to-self function that can be set to notify me that the intended period has elapsed? It might be something like "{{remind-me|period=7days}}" or "{{remind-me|at=dd-mm-yyyy}}".
Imagine something like when a "thank" is issued from a revision-history page. The delivery mechanism might be something like the notification when a {{reply|UserFoo}} is done. Its trigger (driven from MediaWiki software perhaps?) would be after a specified time-delay, or at a specified time. Or it might be an event related to the "watching" of a page.
The point is to set some sort of alarm on the page that can notify me to check it.
(I can think of other aspects such as letting the alarm notify not just me but other users. But that is for the next iteration, assuming it gets through this first iteration.)
Thoughts? (Obviously, if it already exists, let me know!)
For example, in this very case. Suppose there is no discussion at all. Suppose I forget. Wouldn't it be nice if I could have set, right here and now, a "{{remind-me|period=7days}}" to give this very discussion a nudge? Feline Hymnic (talk) 22:28, 22 August 2018 (UTC)
Outside the scope and mission. The Web has many free reminder services. I use http://www.memotome.com/ from time to time, although there are probably better ones. And then there's the old-fashioned way, write it on your calendar or daybook. But we shouldn't spend resources duplicating functionality already readily available elsewhere. ―Mandruss☎ 22:40, 22 August 2018 (UTC)
I partially take the point about dupliction. But take Wiktionary. There are lots of official dictionaries (Oxford, Mirriam-Webster, Collins) online. Does their presence mean that "we shouldn't spend resources duplicating functionality (i.e. our Wiktionary) already readily available elsewhere"?
The prompting thought was "how do I do this". But I could immediately see much wider-ranging possibilites such as "how does an WP admin keep track of 'user BadGuy suspended for a week'?" when there may be many hundreds of such cases simultaneously.
Anyway, thanks for replying, which I appreciate. All the best. Feline Hymnic (talk) 09:41, 23 August 2018 (UTC)
Basically one of the most-requested features, and I think it's a good idea. I even took a crack at it a couple of years ago, but it turns out it's technically difficult to implement. Maybe since I have a bit more free time now I could try it again. Anyway, all methods of implementing this are tracked at T88781. Enterprisey (talk!) 22:54, 22 August 2018 (UTC)
@Enterprisey:: Glad to hear it is frequently requested feature. (I was sure I wouldn't be the first!) I've just started tracking T88781. Thanks. I would be happy to consider participating. I see it mentions PHP and Python, which I know somewhat. Keep me informed if you wish. Feline Hymnic (talk) 09:41, 23 August 2018 (UTC)
Selective delete of edits in a page's history?
Please when will we be able to delete only some of the edits of a page? I read that this lack has been in a Mozilla bug list for a long time. Currently, to delete a few edits off a long edit history, I must delete all the page' edits, then undelete most of them. This wastes Wikipedia's server's time (and also my time).
Also useful would be ability to:
Move some of the edits of a page.
Move all or some of the deleted edits of a page, while keeping them deleted, without disturbing the page's undeleted edits.
Wikipedia:Revision deletion has got rid of most of the need to delete individual edits. as for moving some of the edits of a page, it can be fiddly, but delete, then restore and move one subset, then restore and move another subset works for me. ϢereSpielChequers 22:17, 24 August 2018 (UTC)
No. Revision deletion is a way of marking a revision so that ordinary users cannot read it. It is not the same as ordinary deleting / undeleting. Each edit can have TWO markers set, each on or off: (1) choosing between ordinarily deleted or not; (2) choosing between "revision-deleted" or not. Anthony Appleyard (talk) 13:02, 25 August 2018 (UTC)
Because these two processes are so fiddly, few work on the backlogs for history splitting or selective page merges. But if there were simple facilities, I think more admins would do it. Then again these issues are mainly a hidden mess, and there is little benefit to our readers to get it right. Graeme Bartlett (talk) 23:18, 24 August 2018 (UTC)
Edit Page Notices for all articles with Discretionary Sanctions
I feel there is a strong case for any page on which discretionary sanctions has been authorised to indicate that in the edit/edit source tab of the article. Please read my explanation below and give me your thoughts
A hefty number of the pages on which discretionary sanctions are authorised don't actually let you know that is the case until you get sent the message. Mahammed Edit Page, Pakistan Edit page, Waldorf Edit Page etc.
This comes with a couple of potential issues. One, as discussed ad nauseam in a recent RfC, is the notices are generally sent (and/or perceived) in a rather hostile fashion - reducing the number sent because users are more careful because they are aware of DS being in place after clicking on edit would be beneficial. A more clear-cut issue is that of people forgetting that DS applies to a specific article after they've been warned - this can happen for edits who receive multiple ones (thus they blur) or received it a while in the past (since they stay "active" for so long).
Given the standard protection levels this point is more focused on intermediate/more experienced eds, since it shouldn't directly impact newcomers either way.
Didn't want to dive in with this, in case there is some clear-cut reason why it isn't already done - but hoped there might be some initial support for it. Nosebagbear (talk) 15:17, 27 August 2018 (UTC)
Seems like a fine idea, so long as the notices are not very intrusive: as you said, the goal is to just remind people of their existence. Enterprisey (talk!) 15:56, 27 August 2018 (UTC)
As a practical matter, the discretionary sanctions process is solely under the scope of the Arbitration Committee, so you'll have to convince it of any proposed changes. Personally, I don't think it's inclined to change the current alert requirement by replacing it with an edit notice, as I think there is a strong desire to ensure that editors have been personally notified that a given area is under discretionary sanctions. isaacl (talk) 03:50, 28 August 2018 (UTC)
isaacl - this most definitely would not alter the personally notifying set-up (including changing the fact that editors only count as warned once they have received a notice). This is a tack-on to help with the reasons given above. Additionally, if it has appeared over prior arbitration notices, that suggests their either ArbCom has agreed to it before (in which case it's just implementation) or that it doesn't need their agreement Nosebagbear (talk) 09:16, 28 August 2018 (UTC)
A check on the ArbCom page Alerts notes "Any editor may advise any other editor that discretionary sanctions are in force for an area of conflict." - it just doesn't count for formal alert purposes unless the template is used on someone's talk page. Nosebagbear (talk) 12:42, 28 August 2018 (UTC)
I find the banner editnotices in wikipedia quite helpful. I've not quizzed a statistically significant sample (though they'd have to either be completely useless or actively unhelpful to a significant group for it to be a counter-acting argument Nosebagbear (talk)
The first benefit you originally listed was to reduce the number of notices sent to individual editors; however with the current process this isn't achievable. Unless the process is changed to make an edit notice mandatory on applicable articles, editors can still be subject to discretionary sanctions if the edit notice is missing, which I'm not sure is what you are intending. isaacl (talk) 14:43, 28 August 2018 (UTC)
That point was to suggest that most people receive their formal DS notice once they do something that provokes irritation on the article. My suggestion was that if editors were aware that DS was in place from the start, then they might be less likely to make edits (esp unilateral edits) that caused said irritation (and thus the sending of notices). Nosebagbear (talk) 14:58, 28 August 2018 (UTC)
I'm all for the idea of using edit notices on DS topics to inform editors that an article is in a subject area under discretionary sanctions and what that means. That being said, I think there are a couple of issues here with what Jo-Jo Eumerus said about banner blindness -- we've seen that for years at Sega Genesis with editors ignoring an edit notice on what to do before suggesting a page move, and the edit notice banner there is bright and attention-grabbing. What we may have to do, and I recognize this is a side idea, is make edit notices more "noticeable". Making them a pop-up window instead of just a banner may be one idea, for instance, although I'm not qualified to comment on what might be the best answer from a technical perspective. It would also be helpful if those edit notices extended to mobile edits - as of right now, they don't, so users on a cell phone who are editing will never see the edit notice. Just some thoughts to consider here. Red Phoenixtalk 03:16, 29 August 2018 (UTC)
A pop-up notice would be wildly OTT and drive users insane. People would have to be pretty banner-blind before it ceased to be of at least worthwhile usage. Not being a graphic designer I can't provide any great suggestions on what I'd use to make it more obvious without being more annoying than it's worth Nosebagbear (talk) 15:05, 29 August 2018 (UTC)
Doing something about Twitter
I've seen a couple of heated situations over this week Naomi Wu and Sarah Jeong come to mind where the debate ultimately boils down to "should Wikipedia comment on somebody's tweets?" Considering the ephemeral nature of Twitter and the tendency of Twitter to produce drama my tendency is to say, we should not be commenting on tweets at all until such time as they become real-world news such as in the case of James Gunn or Canada-Saudi Arabia relations and even then we should only be commenting inasfar as those tweets had an impact on anything relevant.
Of course, WP:DUE exists. So does WP:BLP and those are supposed to provide some cover. But it would appear those policies are not working; this is especially the case when we have canvassing going on off-site and end up with a host of new accounts who want to make sure that a person's 3AM rage-tweet becomes a matter of permanent encyclopedic record. I think a clear and unambiguous policy on when a tweet can be considered notable, with very strict delineation is necessary. However right now my idea is only half-baked, which is why I brought it here to thresh it out. Thoughts? Simonm223 (talk) 19:16, 17 August 2018 (UTC)
Concur. Twitter is a bane to Wikipedia's reliable source policy also. If someone notable wants to discredit a report or finding, they don't need to use facts, just twitter bash it. There is no journalist providing context or counter-views, no report explaining their position, a factless simplification of complex issues - pure rhetoric. It bypasses the journalists. Wikipedia is founded on using reliable secondary sources of which Twitter is neither. Maybe all we need is a good essay that draws on the various policies. -- GreenC 20:26, 17 August 2018 (UTC)
I think at the very least, Wikipedia should have a policy that states that Wikipedia doesn't comment on Twitter drama until such time as the drama has independently sourced and long-term consequences. Simonm223 (talk) 17:21, 18 August 2018 (UTC)
There is already wp:twitter (ie. wp:socialmedia) is the policy. Also a guideline WP:Twitter-EL. It might help to have an essay that expands on these things in more detail with examples. -- GreenC 17:55, 18 August 2018 (UTC)
I think we should strengthen the policy towards Twitter, Facebook etc. The Web 2.0 public forum nature of these sites tends to lead to an even worse mess than the old (static) vanity websites. DaßWölf 21:11, 18 August 2018 (UTC)
I wasn't aware of that policy and I haven't seen it cited previously so I appreciate that. Simonm223 (talk)
The heart of the matter is people extending social media storms into WP. We are vulnerable to this as people mistake us for an extension of social media all the time. It is a matter of people misunderstanding the mission, which is described in WP:NOT. The relevant bit is WP:NOTGOSSIP (read it!) and also somewhat WP:NOTNEWS. These efforts to extend the storms into WP don't fit perfectly into either but NOTGOSSIP is closest. (There is also WP:NOTSOCIALMEDIA but that is directed more to people using WP like their own blog or twitter account...) Jytdog (talk) 16:00, 29 August 2018 (UTC)
There's a few places where I want to pin item #3 of WP:NOTGOSSIP to the top of the talk page. In 140 point font. In bold. With underlines. Simonm223 (talk) 16:09, 29 August 2018 (UTC)
Comment: WP:NOTNEWS and WP:NOTGOSSIP apply. The lasting impact of any given news cycle may not be known until the dust settles. And of course WP:BLP calls for a concervative treatment. That said, is there a concrete proposal here? K.e.coffman (talk) 23:17, 31 August 2018 (UTC)
What to do for stub articles meeting WP:NSPORT but failing WP:GNG?
Now that this AfD has closed, I feel comfortable starting an RfC following up on this June 2017 RfC, specifically on what to do with articles meeting WP:NSPORT but remaining unsourced and with no sources forthcoming. This is intended to be a preliminary step before putting up an RfC to a) Give a sense of where community consensus stands and if it has changed significantly since 2017 and b) flesh out some options that are possible before putting it to the wider community. I see several options right now as to what should be done both in the interim and as a final result. First, it is possible to keep these articles in their current form, without further action, if community consensus has sufficiently changed towards including micro-bios on athletes. Tagging with the appropriate maintenance templates may be a more likely option. Alternatively, we can reformat these articles, perhaps merge them to consolidated articles (maybe a new type, associated with the events) or transwiki them to Wikidata. Finally, it may be possible to tag them then allow some time to find sources, after which the article can be deleted orredirected. Finally, if consensus has changed in the other direction, it may be that these articles will be deleted. Draftifying is also possible, but I feel it would be counter-productive to improving the articles. If there are any options I have missed, or if you want to shout down this proposal, please comment below. Thanks!— Alpha3031 (t • c) 09:53, 27 August 2018 (UTC)
I see no problem with tagging articles for improvement when improvement is necessary. But I don't want to open the door for mass deletions, since that'd disruptive to AfD. Maybe a merge would work if there were a logical place to merge them, but many of these events have 80+ competitors, and merging that many articles into one is unmanageable. Not to mention many of these athletes have competed at multiple events, or in multiple competitios, so where would they redirect/merge/consolidate? Smartyllama (talk) 10:54, 27 August 2018 (UTC)
I do find it both poor, unfair and imbalanced that the grounds for WP:NSPORT can be so much lower than for other articles - giving enormous numbers of athletes the same lower grounds that, say, populated locations have seems unjustified. Nosebagbear (talk)
That said, while I would institute higher requirements for new articles of this nature, I am a little torn about what to do about pre-existing ones. Clearly it would be a veritable deluge to delete/draftify all failing articles (whether now, or after a period of time). Obviously tagging would be the minimal requirement - I'm not sure if any other step should be taken. Nosebagbear (talk) 11:58, 27 August 2018 (UTC)
In any case, we'd need to establish consensus to change the guidelines before we go about deleting anything, even if we were to do that. And I wasn't seeing that consensus last time. Smartyllama (talk) 13:08, 27 August 2018 (UTC)
Obviously. Though at least a split/consensus lack on this is/would be less of an issue than the SCHOOLOUTCOMES saga, where the AfD Reviewer consensus clashes with the global RfC consensus Nosebagbear (talk) 13:46, 27 August 2018 (UTC)
Not allowing mass deletions is indeed sensible, and it was raised in the last RfC as well. I think there is a need to limit the rate these articles are reviewed at, or propose some other interim measure should consensus trend towards delete. Transwikiing might in fact be the simplest option after tagging, but I'm not sure if it's ideal. I'd agree that merging would seem to be one of the least favorable options. — Alpha3031 (t • c) 00:26, 28 August 2018 (UTC)
From the standpoint of notability, the subject-specific notability guides like NSPORT are meant to establish bounds for the presumption of notability that can be challenged later. That challenge is supposed to follow the advice of WP:BEFORE - the one nominating for AFD has to do the legwork to show that no sourcing appears to exist. That would likely mean in a case of this AFD getting local libraries in Jordan to review the newspapers of the time. Without that BEFORE, a proper test of the presumed notability cannot be made. So the AFD was launched on a bad note. But I do see a lot of people just iterating back "Notable because meets NSPORT" which is also not right. One can call out the bad challenge to notability by the AFD nominator, but re-iterating back NSPORT doesn't prove anything and its an empty !vote. When this type of AFD is raised, editors should be looking for sources. --Masem (t) 13:53, 27 August 2018 (UTC)
Exactly. Notability is fundamentally about sources, so it's demoralizing to see AfDs where no one is trying to demonstrate the availability of sources. Crying "Notable because meets NSPORT" is in essence saying "there are likely GNG-levels of coverage, none of which I am going to show to you even though that's what you're asking", i.e. the WP:MUSTBESOURCES fallacy. Conversely, a proper WP:BEFORE search should be presented by the nominator, although it isn't based on the presumption that the possible sources are of the most obscure kind. "Did you even go to the local library in his hometown and read through literally five decades worth of local newspapers they have in three languages?" is not an appropriate rebuttal. In the mass-media era, reliable sources that contribute to a volume of significant coverage about any given topic leave a substantial trail of records plus citations in secondary sources. WP:BEFORE recognizes this and explicitly sets the standard by listing the records you are supposed to search at minimum. – Finnusertop (talk ⋅ contribs) 14:46, 27 August 2018 (UTC)
In this specific case, we have a person that participated in the 1984 olympics, pre-2000 (my personal cutoff date where I'd expect finding digital information should be easy over print). One needs to look through Jordan national newspapers around that time (not a very large data set) to find if there is coverage. As I recall, the Olympics SNG for NSPORT is based on the fact that these people by virtue of participating for their country are going to get bios published in the country's national newspapers to build up on notability and expand the article, so that makes the target for finding sources very easy. --Masem (t) 15:05, 27 August 2018 (UTC)
Articles should need sourcing. We should delete articles that lack sourcing to the level of verifiability.John Pack Lambert (talk) 01:46, 28 August 2018 (UTC)
Johnpacklambert, since this pre-RfC is mainly intended to enumerate our options, what would you think about a transwiki to Wikidata? — Alpha3031 (t • c) 03:25, 28 August 2018 (UTC)
For SNG-meeting articles (like this one) you need reliable sources to prove the SNG criteria was met (was he an Olympic athlete for Jordan?) WP:V is not optional. Yes, we want more in time, but that's the nature of the presumed notability of an SNG that we don't need deeper sources until they can be found (or shown they don't readily exist). --Masem (t) 03:45, 28 August 2018 (UTC)
WP:V wasn't the issue in this AfD. We had citations from the IOC and from Sports Reference showing he did, in fact, compete in the Olympics and as such met WP:NOLYMPICS. Pretty much any Olympian is going to at least meet WP:V given Olympic competitors are well-documented. So is pretty much anyone meeting WP:NSPORTS in general - there is ample documentation of pretty much every sporting competition that would rise to that level. The issue is WP:GNG. Sports Reference and the IOC's website don't cover anything beyond the fact that the subject existed and competed at the Olympics, plus their results and brief biographical information. The delete !voters asserted there were no sources that met WP:GNG, not that there was no proof the subject even existed. Smartyllama (talk) 12:47, 28 August 2018 (UTC)
Right, so why would the information need it's own page, then? If all we have is 1-2 lines of text to say about a subject, it is much more efficient to put it in another article. If all we have is a single line in a results table that we can possibly say about a person, the results table is sufficient. There's no need to have an article about a subject where there's not enough text to justify having a completely separate page. The information is sufficiently covered in other pages. --Jayron32 16:38, 31 August 2018 (UTC)
I am surprised but maybe I'm just not searching right, but I would think that an article like "List of Olympics athletes representing (nation)" would be a reason set of lists to have and while for the big countries like US, China, Russia, etc. that send 100s of athletes, for these smaller countries this would be very maintainable, and could serve as redirect targets. If someone later comes to actually flesh out more than just a stub with reliable sources, great, otherwise we still have a searchable term and in a location that logically makes sense. --Masem (t) 17:09, 31 August 2018 (UTC)
That would be reasonable. Following WP:SUMMARYSTYLE is always good; if a list is small enough to be maintained on one page that's fine, if the list becomes larger, then we break it into smaller lists. The issue is that having a separate page for every athlete is not necessarily the best way to organize this information. I'm not saying that information about such athletes needs to be scrubbed from Wikipedia, I'm just saying that having a bunch of separate pages to house tiny amounts of information each is not the best way to organize it. --Jayron32 17:30, 31 August 2018 (UTC)
I have to think on this, but I wonder if for most SNGs, where a topic does meet the SNG but all you can say about the topic is a stub (1-2 sentences at most + infobox) if it should also be possible to have that information placed in a list/table article for redirection purposes until the stub can actually be expanded. It may be perhaps that we need something at WP:N and SNGs that strongly urge that SNG-meeting stubs should be assumed that they can be expanded, thus not deleted and remain search terms, but should avoid the stub nature if they can be grouped into logical lists that include the same information. But that's beyond this conversation's scope and represented a sea change in our approaches. --Masem (t) 17:37, 31 August 2018 (UTC)
That explicit guidance has already been here at Wikipedia for at least as long as I've been active, 12 years or so. See WP:PAGEDECIDE which discusses when it is, and is not, appropriate to create stand-alone pages AND how to handle information when a stand-alone page is not the best option, to wit "Sometimes, understanding is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context. A decision to cover a notable topic only as part of a broader page does not in any way disparage the importance of the topic. Editorial judgment goes into each decision about whether or not to create a separate page, but the decision should always be based upon specific considerations about how to make the topic understandable, and not merely upon personal likes or dislikes." There's lots of other places where Wikipedia guidance encourages keeping the information together in one page rather than breaking out sub-stubs. --Jayron32 17:45, 31 August 2018 (UTC)
Leave them be, as long as they meet WP:V due to the IOC site. I don't see any good way to improve on the existing guideline at WP:NOLYMPICS. It will be easy enough to do a mass action in 10 years if consensus changes, or maybe editors will add other (likely non-English) sources. power~enwiki (π, ν) 16:42, 31 August 2018 (UTC)
Watchlist notification
The watchlist notification currently reads:
You have 654 pages on your watchlist (excluding talk pages). Changes to pages you haven't visited since the changes occurred are shown with solid markers.
It's the second sentence that bugs me. It's awfully pedantic. I would like to change it to the following but have not been able to locate the template or its talk page, so I'm suggesting here that it be changed to the following:
Changes to pages since you last visited them are shown with solid markers.
Thank you. Akld guy (talk) 06:24, 21 August 2018 (UTC)
Looks like a solid idea to me. Enterprisey (talk!) 06:26, 21 August 2018 (UTC)
@Akld guy: I am not sure you copied the second sentence correctly, because this is what I am seeing: (compare with yours)
Pages that have been changed since you last visited them are shown in bold with a green marker.
TYVM, and please note that the bolding in my original post was for highlighting and does not appear in the displayed version. Akld guy (talk) 14:55, 21 August 2018 (UTC)
Update: I left a message on the Talk page of MediaWiki:Rcfilters-watchlist-showupdated, but there has been no response. In disgust, I have checked the "Hide the improved version of the Watchlist" in my preferences, thus going back to the watchlist's original version. A far nicer looking version, and it loads instantaneously versus the 3-4 seconds of the "improved version". Akld guy (talk) 21:59, 24 August 2018 (UTC)
I deactivated the ER, however if anyone would like to revisit it please verify and just set the answered= back to no. — xaosfluxTalk 21:13, 26 August 2018 (UTC)
I did not withdraw my request, which I still feel has merit and has met with the approval of two other editors here. I am reinstating the request. Akld guy (talk) 21:23, 26 August 2018 (UTC)
And I would prefer not to have to reset but would still like the simple phrasing, as above — Preceding unsigned comment added by Nosebagbear (talk • contribs) 2018-09-04T15:05:53 (UTC)
Units of measurement and simplifying text in science articles
In the climate pages were I edit (recent example Sea level rise, often there are numbers followed by units, and alternative units are presented in parentheses. This makes the text look intimidating to the non-nerd. Do we already have tools that allow editors to format their numbers with one system of measurement, and a button the reader can click to convert all such numbers to the reader's system of measurement when the page is rendered? That way the text would be clean lean mean but it would also be well globalized. NewsAndEventsGuy (talk) 14:12, 24 August 2018 (UTC)
@NewsAndEventsGuy: there is no tool to allow a reader to re-render a page with a different system of measurement. That is why we use {{convert}} (or similar templates) to present a measurement in one system with the alternative unit(s) in parentheses behind it. Imzadi 1979→ 21:24, 4 September 2018 (UTC)
Thanks, That's what I thought. IMO it would make science articles much more user friendly to allow some toggling in user preferences. Option-A like we do now, Option-B display first number entered in the template, Option-C convert first number (or only number) into system of user's preference. Would that be hard to code or hard to render NewsAndEventsGuy (talk) 21:44, 4 September 2018 (UTC)
One problem with this idea (which has been discussed before) is that it can be misleading. What is the correct conversion of "about four feet"? Of of "less than a millimetre"? In a sourced, encyclopedic context, I believe the correct approach is first to quote the source accurately, and then give a conversion to aid readers not familiar with the units in question. Peter coxhead (talk) 08:38, 5 September 2018 (UTC)
Wikipedia news
Feel free to improve or suggest ideas about my new project Template:Wikipedia News. I'm going offline now and will be checking tomorrow on the discussion. Thanks, L293D (☎ • ✎) 02:58, 4 September 2018 (UTC)
What will this do that Signpost doesn't? --Redrose64 🌹 (talk) 18:33, 4 September 2018 (UTC)
Possibly, he hasn't discovered it yet. Any rate I am suspicious of anyone, who in a burst of initial enthusiam wants to reinvent the wheel. I have a long list of articles that need an immense amount of TLC that could use all that energy. --ClemRutter (talk) 19:09, 4 September 2018 (UTC)
Agreed that more context would be useful, but when I look at this I don't see anything like the Signpost (ongoing basis vs. every 1-6 weeks, short lines/notes/news vs. features/stories/op-eds...). Sure, some overlap, but if anything these sort of short bits would probably be better moved out of the Signpost and then transcluded/linked if others are interested to help out. What it does look to have some (a lot) of overlap with is Wikipedia:Goings-on. Looks like Enterprisey is involved at Goings-on, though -- pinging for $0.02 on this. — Rhododendritestalk \\ 19:21, 4 September 2018 (UTC)
Give Extended Confirmed Users/Non-Admin Users the right to semi-protect a page in order to deal with vandalism.
Today I was engaged in a suppression of a particular persistent vandal on theDracula (Castlevania) who was able to continually vandalize the page despite a RPP being filed along with an administrator request for intervention due to lag and Admin-Shortage. Perhabs a way to reduce the demand for admin services would be to re-distribute some of their powers down to other users by giving them the ability to semi-protect pages for a short period of time(1-2 hours) to reduce the delay and improve counter-vandalism efforts.Zubin12 (talk) 12:42, 28 August 2018 (UTC)
There was a recent major RfC on the creation of an additional userright to allow short term page protection. Strictly speaking only the original proposal which allowed quite a long time was closed as major consensus against. A mid-discussion proposal fairly similar to this got mixed views (I think that one mooted 6 hours). The userright would need to be significantly tougher to acquire than rollback/NPP (the general "intermediate" rights). Worthwhile having a hunt through the archives to find it to avoid duplication. Nosebagbear (talk) 12:57, 28 August 2018 (UTC)
Oh that's disappointing, Could I have a link to the discussion I'm not able to find it looking back through the archives.Zubin12 (talk) 13:01, 28 August 2018 (UTC)
Link to RfC. I'd suggest linking in NeilN if you want to discuss the concept in more detail - it would need to be excellent to even get some reasonable discussion as this is a functional perennial. You can have a look at his proposal if you search ctrl+f " I agree the original " Nosebagbear (talk) 13:03, 28 August 2018 (UTC)
I just went through a discussion today where if an extended-confirmed editor had been able to exercise their wish for protection they would have unjustly prevented an editorial opponent with a valid concern from editing and pretty much destroyed three months' work without scrutiny. I know this is a one-off anecdote, but I do see it happening regularly enough that I'm convinced that granting any blocking or protection powers to non-admins is and remains a bad idea. Ivanvector (Talk/Edits) 23:34, 28 August 2018 (UTC)
Just giving it to ECs would be an insane idea and wildly OTT. As I mentioned, were this 3-hr protect proposal to progress you'd need a firm set of requirements for an extra user-right to be provided/denied at WP:PERM.
Ivanvector,and Nosebagbear I understand your concerns that this power may-be misused in edit-wars but I don't think that a short duration 45 minute block with instant permanent revocation for misuse will be that much of a problem. Surely responding to handful users abusing a tempory protect function will take far less admin time than the current RPP system ?Zubin12 (talk) 14:19, 29 August 2018 (UTC)
EC is too short, 5 months 2 thousand edits would be better, and at PERM admins would look for a proven track record in counter vandalism. As for duration of application, I think 45 minutes max would be quite ok, and not against the Wiki Way. The perm could be limited to the mainspace only, and could also be made have its own tag and show up at a Special:UserTempProtected noticeboard where patrolling/subscribed admins could attend to it. Also, a rate limit of 2 temp semi-protects an hour would further prevent rogue users from abusing it. The standard "Users take all responsibility for their edits while using this permission and may receive sanctions up to and including indefinite blocks for misuse" would cover anything else. I can see an occasional user being confused (AGF) and using it enforce their preferred reversion (off the top of my head, when BMK was last dragged before AN3, it wasn't strictly vandalism, but he wasn't edit warring for his own sake, rather the good of the 'pedia.) but either the removal of the right, a community talking-to, or a block would solve the problem. It's fairly hard to disrupt the encylcopedia when you can only semi-protect the same page for 45 minutes out of each hour. I'd view rollback as a more dangerous tool than this. Thanks, L3X1◊distænt write◊ 13:46, 29 August 2018 (UTC)
Beyond prove track record in CV, a demonstrated correct use of RFPP would be necessary. A couple more thoughts: depending on coding complexity, preventing the same user page-protecting the same article twice within any 24 hr block would also hinder mis-use. I would say if this is in place, then a simpler 1 hr SP could be used. There are quite a few cases though where a 2hr SP would be better (particularly either in really peak times or the (0400-0700 UTC) "bubble" when the amount of admins online drops heavily). Nosebagbear (talk) 15:03, 29 August 2018 (UTC)
Nosebagbear, I agree with you on the RFPP trackrecord and on the once-per-day rules. I also agree with what Zubin12 said just above. Thanks, L3X1◊distænt write◊ 20:42, 29 August 2018 (UTC)
I'm just going to specifically link in @NeilN: since he was the one who wrote a proposed motion in the middle of the rejected one that is reasonably similar to this one and I think his thoughts might be helpful Nosebagbear (talk) 21:22, 29 August 2018 (UTC)
Neil's on wikibreak, since the 5th of this month. Thanks, L3X1◊distænt write◊ 21:12, 30 August 2018 (UTC)
So some summary thoughts from the couple of us currently involved, I'm not sure I'm fully in favour, but I think a pre-pre proposal would help clarify (italics indicate known queries):
Protection would be limited to semi-protect.
Protection duration would be limited to between 45m-2 hours (TBD).
Right holders ("RHs") could only protect the same page once within 24 hours.
RHs could only protect 2 pages within one hour.
There would be stringent requirements at WP:PERM to acquire this right. At a minimum: 2000 posts (or 1500 mainspace?), a clean 6 month block record, registered user for 150 days, proven track record in Counter-vandalism, proven track record in Requests for Page Protection.
Use of the right must be accompanied by a full request for some form of page protection at WP:RFPP. Failure to do so would be deemed a mis-use of the right.
The right could only be used in Main or Talk (not including User Talk) namespaces.
Right could only be used in instances of vandalism from multiple IPs/newly registered accounts. Alternate uses of protection (such as against unsourced details etc) would not be permitted
That's a good summary, but I would ammend the requirment for RPP to simply record of previous vandalism on the page. The whole point of this proposal is to reduce the work-load on admins so requirng an RPP is kinda counter-produtive. Zubin12 (talk) 23:45, 30 August 2018 (UTC)
A good summary, but there are some points (I am directly responsible for a few, it seems,) which over time I have come to second guess. While we all agree EC30/500 is too short, I am not convinced 6 months is a good minimum, 3 months (or 90-100 days)might seem better. Our goals here are twofold (correct me if I am wrong): prevent misuse by the novices, and to prevent abuse by those with malicious intentions, such as socks and LTAs. Well, socks, LTAs and those who are NOTHERE usually either show their hand in the first week of editing, or are quite capable of playing a long game to get their way. (Jay, SwisterTwister, TheGraceful-Not-Slick-Enough, and Dr.Strauss fit into the sock category, they ran sock accounts for months and years before being discovered. Now TBH, they had other intentions than the disruption of the Pedia, but still, they can serve as a template) For these people 6 months isn't long enough, but neither is 5 years. For maximum effective use, to our own benefit and to the RH, I think shortening it would work just fine. As for edit count, I am fine to pitch that to the community, as I started out editing with all my heart and soul, and racked up 2000 edits quite fine. However, if our Service Awards are to indicate the general or expected progression of editting progress, if we are going to lower it from 6 months, the edit count requirement should correspondingly drop to 1000 edits as well. I have seen in recent discussions just about everywhere here, that more and more of us are delineating mainspace edits apart from all edits, and that is good, but admins at PERM aren't stupid, and would detect gaming when they saw it. Bots aren't giving out permissions to anyone who just breaks the minimum threshold, anybody making piddlesome edits to their sandbox would be shot down. I also think it would be beneficial to us and to novice CVU operators if the permission requirements weren't carved too deeply into stone. The goal here is to protect the encyclopedia against vandals in a more effective manner while helping to take a few straws off admins' busy backs. Assuming point 5 is accepted by the community sans amendments, I would like admins to not decline a RH just because they were 10 days or 200 mainspace edits short, if everything checkout.
Another thing (sorry I am running on) about point 5, (and I know these are just brainstorming points) 150 days is 5 months, so if 150 is going to be accepted, the block log thing should be amended (on paper at least) to reflect that.
Re: Point 6, I agree with Zubin a bit, it seems counterproductive to file a duplicate report. One thing I have noticed through my work in CVU is that it would seem that a short "Go away stop that please" technical restriction would be of infinite more use to the encyclopedia than actually having to fight prolonged revert actions against vandals. (Basically, for an obvious vandal, a 30 minute no frills block after just one penis edit would be more effective and better to all involved than having to wait for 4+ vandal edits, multiple warnings, and then AIV. If I were in charge I would rewrite the blocking and protection policies to encourage the use of very short term measures. But I digress…) If the Special:NonAdminSemiProtect page/queue were implemented, or maybe just for the first 10 uses by the RH, I think that would allow misuse to be corrected and abuse to be stopped easily enough, without requiring RFPPs all the time. I expect this tool (if enacted by the community) to be used quite often, and if point 6 was the rule, RFPP would be spammed into useless oblivion, requiring a dozen or so "clerks" to sort through them all and try to keep up.
If each mini-protection had a tag attached to it, a MW query (we are now in technical territory where I am quite ignorant) or bot could trawl through them all and look for anything suspicious: pages being mini-protected when they hadn't been previously edited by IPs/non-AC users for a week or more, repeitious protections that might indicate misuse, and flag those for human review. I'd expect a large false postive rating (how many of us have clicked the wrong button in TW or rollback and not noticed it?)
Currently, I think we have enough to prevent abuse, indeed Point 2 and 3 would make this harder to abuse than rollback, where one could cause an awful lot of damage in 4 minute if they so desired. Playing devil's advocate, if we hand out RB to over 6 thousand editors and let it be, why should it be so hard to get a right limiting you to disrupting 48 pages a day?
Last one for tonight, something should be done about spaces where this tool is applicable: main only? Main and Talk: spaces? If use in the userspace at all allowed? I can see a lot of newer users getting a nasty comment from a reverted IP (vandal or no) and applying temporary protection when they really of oughtn't. Thanks, L3X1◊distænt write◊ 00:59, 31 August 2018 (UTC)
Drops mike...saunters away
2 hours still seems short. During the RFC mentioned above I visited RFPP during off hours (early morning UTC, US holiday). Four requests took over 12 hours to be answered, the average answered request took over 9 hours to be answered, and there were 10 requests that were still unanswered after over two hours. I think 6 hours would be reasonable, although NeilN's proposed 3 hours is better than nothing. There would be a requirement to report all temporary protection at RFPP, so if admin response time at RFPP suddently improves, improper application of protection could be swiftly be dealt with by admins. --Ahecht (TALK PAGE) 17:48, 5 September 2018 (UTC)
Response - Right, the comments above seem to pertain to points 5 & 6. I'll attempt to reply to this, bit by bit:
The time span was less "filter out bad eggs" and more "let policies fully seep in" - you can gather lots of CV experience and a fairly high hit rate, but I think accuracy still improves over time. Still, I'd be happy to say 90 days so long as CV and RFPP track record were fairly firm
I disagree about reducing the edit count. I think that level of participation is necessary - you might do it in (say) 120 days, you might take 200, but I think that 1000-2000 step is a fairly key one in "basic grasp on the intermediate bits" to "being firm on all the standard areas". I believe this right could be more troublesome than rollback error, and thus a higher level of edits should be required. If nothing else, it needs to be made clear that this will be a fairly rare user-right.
I'm fairly happy for a general all-space edit count, and leave it to the WP:PERM admins (who are definitely aggressive investigators) to check for system-gaming (even non-deliberate cases). I'm also happy for admins to judge edge-case exceptions - they usually do so via probation.
I originally did write time-in and block-free times the same, but amazingly all the user-rights are like this. I think it is there in the viewpoint that an newish editor with 3 months exp is easier to trust with tools than an 8 month editor with a block 4 months ago. I'm not sure myself either way, but if that is the general viewpoint then I'm not sure I'd dispute. I would want to note that perhaps it should be a 90 day clean-period for a single 3RR block.
Hmm, I can see the arguments here as regards time saving, duplicative, even more admin-time use etc. I can also see some massive concerns that RHs would be getting admin-lite powers without proper oversight - it'd be a shift of direction from "holding the fort while awaiting an admin" to "dealing with smaller cases alone". I'm concerned by the thought (and potential significant disagreement) - might be nice to get a couple more opinions.
I 100% agree that it should only be usable in Main and Talk spaces (not including User Talk). In fact, I'm going to add it as a mooted agreed point above.
My own thoughts A "Special:NonAdminSemiProtect" queue would be needed, however perhaps two other things could be useful: a more active use of parole when giving the right then usual, and some comment/tick box log that would require RHs to note 2 things: why they were using the right, and why it had to be used in place of other measures/warnings and AIV-block etc.
As well as an individual "1 use per page per 24 hours" perhaps we should make that a "1 (maybe 2?) use per page per 24 hours" in total". After all, if it is being that much of a problem it is most definitely a case for a "proper" protect.
Thanks for reading (and if you aren't L3X1, congrats for reading both posts!) - thoughts, especially on point 6? Nosebagbear (talk) 17:23, 31 August 2018 (UTC)
I've also amended another bit of NeilN's usage - the right should only apply against vandalism from multiple users, rather than the other reasons RFPP being used Nosebagbear (talk) 16:09, 2 September 2018 (UTC)
I get that other reasons (disruption, unsourced additions and removals, annoying edits etc) would be disallowed but are we sure "from multiple users" is a useful clause? I can't really remember anytime I was dealing with multiple accounts or IP hopper on the same article at the same time while an RFPP was filed. Most vandalism I know of is single-author.
Thinking point, allowing other reasons to protect would open a can of worms, but might it be worth it? This was on my watchlist this morning, Special:Contributions/Brent_william. None of the edits are vandalism, (wolf characterising the last one is up to him, I won't dispute it, but I wouldn't have done that myself), but the editor in question did need assistance in making whatever changes he wanted, and a technical nudge to a talk page might have helped hium. Thanks, L3X1◊distænt write◊ 18:56, 2 September 2018 (UTC)
L3X1 - Multiple users is necessary - otherwise these RHs would have lower requirements than formal RFPP. I also agree with them - I think the disruption of short protect is greater than the 4 or so actions to block a single user/IP and refer to AIV (which is more reliably quick than RFPP).
While of course there would be some benefits for additional benefits for blocking other categories, we need to limit to extremely clear-cut cases and the only general category where that is the case is vandalism. Nosebagbear (talk) 10:43, 3 September 2018 (UTC)
Only noting that "protecting against widespread vandalism" could be seen on the other side of the coin as "rump caucus trying to subvert the page consensus". The protection better get an endorsement by an admin in good standing otherwise the protection and permission needs to be revoked, for cause. Hasteur (talk) 16:39, 8 September 2018 (UTC)
Removing official website
I would suggest the members who would like to comment on the question I am going to ask, to visit [1] link before answering my question. My question is: from the link, I was able to understand that the subpages like 1970 Stockholm Open and 1989 Stockholm Open doesn't have official website and doesn't needs to be linked. So, am I allowed to remove the official website link from the specific wikipedia pages or do I need to remove the magic word official website and provide it as a normal link? Currently, for the official website section, they follow single value constraint ie. only one page can have same official website. Adithyak1997 (talk) 15:07, 1 September 2018 (UTC)
Just as a note, original discussion here. I don't think we should replace {{official website|http://www.stockholmopen.se/en/}} with [http://www.stockholmopen.se/en/ Official website] in 1970 Stockholm Open only for the sake of a cross-wiki category check, since the use of the template on the page will let people know if there is an official website being linked to on the page. That being said, if a consensus determines that having an "official website" (of the organization) for an individual year of a tournament is inappropriate, then by all means feel free to remove the template (though linking to the Swedish Open website on the 1970 SO page makes sense to me). Primefac (talk) 15:15, 1 September 2018 (UTC) (please ping on reply)
This seems like primarily a Wikidata problem with P856. But anyway, the template only defaults to the Wikidata property if left blank. So {{Official website}} on Google will to to https://www.google.com. But {{Official website|https://www.yahoo.com}} on Google will go to https://www.yahoo.com, even though it's placed on the Google article. GMGtalk 15:16, 1 September 2018 (UTC)
Oh. That seems like a bit of a silly category actually. Poor Abraham Lincoln's got no website at all. GMGtalk 16:03, 1 September 2018 (UTC)
You won't see that category in the article Abraham Lincoln because what it really says is Official-website-defined-in-article-but-there-is-no-official-website-defined-on-Wikidata
As for the 1970 Stockholm Open etc., we shouldn't use the template or the phraseology. Remove the link because it contains nothing about the 1970 tournament. – Finnusertop (talk ⋅ contribs) 17:01, 1 September 2018 (UTC)
Since many of them are saying answers, I suggest somebody(after discussion)to tell a final response to this message as I am not familiar in doing that. It needs to be done only after discussion and not now. Adithyak1997 (talk) 17:33, 1 September 2018 (UTC)
So what change needs to be made?Any final result from this discussion?Adithyak1997 (talk) 14:36, 10 September 2018 (UTC)
"Helper" account for a user assisting another disabled user
There was a request yesterday that bounced around a few forums, about how a user could go about assisting another user who has a disability (arthritis, I think it was) and finds it difficult to edit directly. The "helper" user, Izzat Kutebar, proposed creating a second account for the disabled user, which they would then operate on the disabled user's behalf. By the time the question got to my attention Izzat had already been advised to ask in a different place several times, and was unfortunately but understandably upset about the situation. I responded that shared accounts are not allowed, but I think I need to go back on that in the interest of accessibility. This seems like as good a time as any to have a discussion on this topic, even though Izzat has supposedly permanently retired apparently because we did not jump fast enough for their liking; that's partly my fault.
On the issue of a "helper" account, I think it's fine, and if there is some policy that forbids it, we should revise it. Let me use the example (inapt here, but maybe not) of a deaf person's assistant, or a translator (or an ASL interpreter, I suppose). In sensitivity training, we are taught that even though the disabled person interacts with the assistance of a helper, you are not interacting with the helper but with the disabled person. I see this as an analogue for a disabled person who cannot operate a keyboard editing Wikipedia with the assistance of a helper who types for them - per our policies, the disabled person must have their own account, not share the helper's account. I think we can and should accommodate that.
As far as policy is concerned, the sockpuppetry policy (the policy on the use of multiple accounts) doesn't explicitly cover this situation, but I think it ought to fall under something similar to a designated role - the helper is a role and should not edit from their own account while helping the disabled user. But the policy also says that role accounts of this sort are forbidden (presumably meaning those roles that aren't "designated"), so if this is the approach then the policy needs to be adjusted. I'm not sure if we need to require disclosure or just advise that helpers can disclose privately to Arbcom if they wish.
I'm posting this here at the idea lab because I'm not really sure where to go with it, so input and/or other ideas are appreciated. Ivanvector (Talk/Edits) 23:30, 28 August 2018 (UTC)
If User 1 wouldn't be able to operate a keyboard, then wouldn't the account belong to User 2, with User 2 editing by proxy for User 1? WP:PROXYING is only prohibited in the case of users who are sanctioned. There is, AFAIK, no policy forbidding proxy editing for users in good standing. GMGtalk 23:35, 28 August 2018 (UTC)
As a concrete example, I was in the middle of the woods in February on a training exercise, and I spotted what I thought was copyvio, but was on mobile with crap for internet access. So I logged onto IRC and asked for someone else to look into it. That, to my mind, is proxy editing for reasons of accessibility, although in my case, not related to disability. GMGtalk 23:40, 28 August 2018 (UTC)
I suppose you're right, and I've done the same. I guess what I'm looking for is a way for us to recognize, for reasons of administration and dignity, that the account actually belongs to the disabled user, who edits with the assistance of the helper. The same as if the user edited with an assistive device, or text-to-speech or whatever technology is used for this purpose (I don't mean to offend anyone, I just don't know). I may be overthinking it. Ivanvector (Talk/Edits) 00:09, 29 August 2018 (UTC)
(edit conflict) Well you can't let it "belong" to User 1 (that would be shared), but you can have it "dedicated" to User 1. Something like:
This is a declared alternate account of User:2, for the sole purpose of proxy editing for User:1, for the reasons of accessibility or disability. Please note that proxy editing is allowed for users in good standing. All responses and other edits from this account should be treated as if they come from User:1, as all edits will be proxy edits for User:1.
It's not perfect, but it puts someone else in the position of having to open an RfC to disallow it, rather than you opening an RfC to allow it as a form of shared account. GMGtalk 00:43, 29 August 2018 (UTC)
I suppose if serious behavioral issues arose, all three accounts would be subject to sanctions. Just as if you asked me by email to join in your edit war by proxy, and then when I was blocked, I gave your email to ArbCom. GMGtalk 00:51, 29 August 2018 (UTC)
Wikipedia will bend over backwards to help with accessibility for to the project by the disabled, definitely including editing assistance by arthritic users. If User_1 needs assistance from User_2 to perform some edits, and these two people feel more comfortable not using their main accounts where User_2 is doing something for User_1, then by all means create a new User account, such as User:User_2 on behalf of User_1, making it clear on the main userpage that User:User_2 on behalf of User_1 is an account controlled solely by User_2 for the sole purposes of performing edits requested by User_1. This way, each account is technically controlled by a single person, and no one is sharing passwords. Ideally, User_1 will use their main account to confirm the arrangement.
This is off the top of my head. I am sure there are other solutions. --SmokeyJoe (talk) 00:34, 29 August 2018 (UTC)
I think that we're overthinking this. Two editors need two accounts (one each). We don't care whether those users type on keyboards, sing to their speech-recognition software, or ask someone else to press the buttons. What matters is that 100% of the words posted under each username are actually the words chosen by a single human. It is not a "shared account" if you are typing someone else's words. That makes you a meat-based implementation of speech-recognition tools. It does not make you a joint owner/participant in the account's activities. The only significant policy problem there is Wikipedia:Meatpuppet, but that is not unique to disability/transcriptionists. That problem is no different from the problems experienced by people talking about their edits in university dorms, on Facebook, or around family dinner tables. WhatamIdoing (talk) 20:59, 10 September 2018 (UTC)
Taking everything that's been said here into consideration, I think perhaps that nothing necessarily needs to change. If a disabled person has their own account but gets assistance from another person to physically operate the account, this is either not a violation of any policy, or we should ignore the rule. As for "helpers" who also have their own account, I would suggest that they disclose privately to Arbcom, keep their own editing separate (with a separate account) from the editor they're assisting, and have that be the end of it. Ivanvector (Talk/Edits) 13:42, 12 September 2018 (UTC)
It's like an amanuensis. Consider Eric Fenby writing out a musical score: if it's his own work, then his name appears at the top; but if it was composed by his employer, then the name Frederick Delius is given. --Redrose64 🌹 (talk) 19:49, 12 September 2018 (UTC)
Discussion for feasibility of a two password system
How hard would it be to implement a two password system in the database? A system that:
Allows for using a second password in conjunction with the first for increased user security. Password entropy increases by orders of magnitude when you have two.
Is an additional layer of security for those who are not comfortable using 2FA but it could be used with 2FA as well. Should also work with the "keep me logged in" 365 day cookies for simplicity and convenience. Transparent. See the admin newsletter from March where it is reported that only 16% of admins have enabled 2FA. I believe that editors/admins would be much more comfortable using a two password system.
Is optional for existing editors but recommended for those with advanced permissions. Possibly required for all new accounts; this may help stifle all existing automated account creation scripts (spambots) used by prolific sockmasters and UPE sock farmers. It would also slow down those creating multiples by hand, too.
Would allow the user more time to help prevent a compromised account in the event the first password is breached. The user should be able to change the breached password to maintain account control and the alert should encourage contacting a checkuser to go after the hacker.
First alerts the user when the first password has been breached as opposed to alerting on attempts at the first password. Current attempts at hacking passwords result in alerts that are causing disruption by encouraging users to change their passwords. Aside from alarming people, sometimes en masse, this has led people into locking themselves out of their accounts. If their password was already strong then they shouldn't have to change it. We shouldn't be allowing hackers and sockmasters the ability to cause that much disruption (see this article and Attack on Wikipedia accounts over).
Allows checkusers to check those that breach the first password and hopefully block underlying IP addresses. Currently checkusers cannot check hacking attempts although there is something in the works to remedy that.
Is this something that others would be interested in having? — Berean Hunter(talk) 16:42, 5 September 2018 (UTC)
It sounds interesting, but I'm having a hard time coming up with situations in which an attacker would be able to obtain the first password without obtaining the second. It's not like attackers are just running dictionary attacks against wikipedia (as that is easily detected and shut down). The only feasible ways are a) password reuse from compromised sites, b) phishing, or c) a breach of wikimedia servers. For password reuse, rather than activate a two password system, a security-concious user could simply use a unique password for wikipedia. For phishing or a breach of servers, the attacker would get access to both passwords. In terms of increasing entropy, a security-concious user could obtain the same result by simply concatenating the two passwords (or joining them with punctuation or something). --Ahecht (TALK PAGE) 16:50, 5 September 2018 (UTC)
Random note: I haven't enabled 2FA because I don't want my ability to edit Wikipedia to rely on my ability to pay my phone bill. --SarekOfVulcan (talk) 16:57, 5 September 2018 (UTC)
2FA, i.e. Google Authenticator, works offline. Just like a RSA security key generator. I suppose without a data connection, clock drift would eventually become a problem. But key generation doesn't depends on an active data connection. ☆ Bri (talk) 18:37, 5 September 2018 (UTC)
To me that Google Authenticator looks like it would negate much of the security benefit if it's all stored in the same device. Nevermind the added complexity... Jo-Jo Eumerus (talk, contributions) 19:11, 5 September 2018 (UTC)
Using google authenticator means that someone needs either physical access to your device or something like a remote-desktop connection to it. It prevents the vast majority of attacks where a remote attacker obtains your password either through password reuse, phishing, or a database breach that includes passwords but not OTP keys. --Ahecht (TALK PAGE) 20:33, 5 September 2018 (UTC)
Ahecht, if your home was your account then the analogy is that I'm suggesting adding a type of entryway that is a mantrap (interesting that they have put that article up for deletion...it can be sourced but I'll have to do it later today or tomorrow..example of mantrap). Instead of having one solid door with a deadbolt, you would have two where the design slows down an attacker and allows a better chance to respond. If someone gets your keys elsewhere because they picked your pocket (phishing) or left copies elsewhere (password reuse) or they got master keys from the manufacturer (compromised wiki servers) then they could still get in. My suggestion was never meant to be solutions for those problems. That would not negate the security value of the added entryway. Lock pickers would have two to get through. The analogy doesn't work fully because you would be able to do something about a person trying to break in the first door in real life but in our current situation, we can't.
"In terms of increasing entropy, a security-concious user could obtain the same result by simply concatenating the two passwords (or joining them with punctuation or something)." No, because each password field has a character limit; you can't currently do what I'm suggesting. You can use one long sentence consuming most of the limit like Guy Maconrecommended. With what I'm suggesting, you would have two long sentences in separate fields with separate constraints. Entropy potential increases greatly.
If the mantrap is a sound, security best practice then why wouldn't it be in the virtual sense? Security is best practiced in layers and having more options is better. — Berean Hunter(talk) 11:30, 6 September 2018 (UTC)
Berean Hunter, so basically you propose the current 2FA system, but without the key changing every single time... —TheDJ (talk • contribs) 11:40, 6 September 2018 (UTC)
It is similar to 2FA in that you are using multiple tokens for authentication but would not require separate apps or timing sync. This would be built in just like the current password. It is simpler than conventional 2FA and you wouldn't have the opportunity to lock yourself out because of scratch codes. — Berean Hunter(talk) 12:01, 6 September 2018 (UTC)
Breaking a password isn't like picking a lock. Generally, it's not a brute-force attempt (as those are easily detected and blocked), but it's the equivalent of someone having the key to the door because they found your keys lying on the street. If you keep both keys on your keychain and someone steals it, a mantrap won't help. If you're trying to stop someone from picking the lock, instead of adding a second lock, you can just add more pins and use security pins. --Ahecht (TALK PAGE) 13:25, 6 September 2018 (UTC)
I am wondering whether a person is more likely to use two 12 character passwords or one 24 character password. And whether they will remember the two 12 character passwords more than the 24 character password. If the answer to both questions is yes as I suspect then that would be a sound argument in favour of 2PA. Jo-Jo Eumerus (talk, contributions) 13:54, 6 September 2018 (UTC)
Re: " '...user could obtain the same result by simply concatenating the two passwords' No, because each password field has a character limit; you can't currently do what I'm suggesting. You can use one long sentence consuming most of the limit like Guy Macon recommended."
If I remember correctly from my conversation with the developers, you can enter a passphrase of 65535 bytes (possibly larger -- I would have to check) but (and I did look this up before posting) only the first 256 bytes are used. Unless you are doing something fancy with Unicode characters, 256 bytes equals 256 characters equals 2048 bits.
Anything larger than 32 characters doesn't increase security -- it would take longer than the age of the universe to guess, so whoever is first in the concatenation could use up to 224 characters without compromising security. (Pro tip: always place the shortest password first when concatenating, just in case some bozo has a million-character password.)
Technical details: Wikipedia stores a hash of passwords using PBKDF2/HMAC-SHA-256 with 64000 rounds and a 128-bit salt. If you have a unified login on multiple projects, each project uses a different salt, so cracking a password hash on Wictionary or the French Wikipedia doesn't allow the attacker to log in to the English Wikipedia.
Re: "...alerts the user when the first password has been breached...", this is a terrible idea. Lets say we combine passwords using your scheme or concatenation -- it doesn't matter for the purposes of this illustration. You choose "ab" and I choose "XY", giving us a password of "abXY". That's 32 bits, so it would take 32768 guesses to try all possible 4-byte passwords. Now allow the fact that someone correctly guessed the first two characters leak out (Per Kerckhoffs's principle, we have to assume that the attacker can monitor the alert) So the attacker only needs to make 256 guesses to get the "ab", them 256 guesses to get the "XY". By alerting the user of a partial breach you have substantially reduced the strength of your password.
Re: Google Authenticator; really really bad idea. You are putting software on a smartphone, and if the smartphone is an Apple or Android device, it isn't secure. And closed source from a company which is known to gather user data? No thank you.
Here is how I protect my Wikipedia login:
My Wikipedia passphrase consists of 256 random printable characters, which I generated from my hardware True Random Number Generator. I recommend BitBabbler ( http://www.bitbabbler.org/ ). Every website gets a unique password, with the longest length they will accept.
I can't remember the passwords, so they are stored as ASCII text files, which I only access using Linux. The files live on on an SD card, encrypted with Veracrypt ( https://www.veracrypt.fr/ ) using a long but easy-to-remember passphrase, plus a 1MB keyfile on another sd card.
I keep copies of the two sd cards in multiple locations in multiple countries (I have a deal with two other crypto nerds -- they send me their encrypted backups and I send them mine).
And of course c0c5e71bca550e99a8ae6641e66c428e232051bade39cd47355634ff159c9475fffa1d12eee339aa401bfe5b31ff7fc352c2b9c6f002bfe82d03a6b3f9e40047 is a SHA-512 commitment my real-life identity. See Template:Committed identity. --Guy Macon (talk) 14:30, 6 September 2018 (UTC)
I'm in favor of multiple passwords, but not in this variety. I think we should be able to have "privileged" and "non-privileged" types of passwords as described here: phab:T153454. I don't think changing logon security from "something you know" to "something you know+something you know" is that beneficial. 2FA is a great idea, but we need to make 2FA recovery easier to use. — xaosfluxTalk 14:34, 6 September 2018 (UTC)
Ahecht, I disagree. With our specific problems and existing system, the more frequent occurrences of hacking attempts are done by hand and perhaps to harass users because they can invoke the alert system and alarm them. It can be somewhat akin to repeatedly pinging someone as a form of harassment. "as those are easily detected and blocked" No, they are not easily detected and blocked. I'm a checkuser and I can't detect the IPs being used at all and no, they aren't usually blocked. What do you know that I don't? For me it is frustrating to see people get locked out of their accounts or they otherwise become alarmed/upset and we couldn't detect them. That is why your suggestion of security pins doesn't work as an optional instead of but perhaps built in as an additional feature. That would not forego our ability to have a crow's nest built in for the checkusers to see them and then detect and block. You may also be missing the value that this system could break existing automated account creation scripts and force a reset. Most operators aren't the coders and that sends them all back to the blackboard. Zombie machines would break, too. Not a bad way of performing a purge.
"If you keep both keys on your keychain and someone steals it, a mantrap won't help." I've already accounted for that with "My suggestion was never meant to be solutions for those problems." It is understood that if someone gets your keys elsewhere that there could be a compromise...no claim to the contrary has been made. Are you suggesting that the concept of a mantrap does not have value or isn't a security best practice?
Guy, I wasn't suggesting that someone does this idea instead of yours but rather in addition to it. I think the long passphrases are a very good idea. "By alerting the user of a partial breach you have substantially reduced the strength of your password." You lost me with that. The person that possesses both passphrases has the ability to reset the first. That beats the current system where they own you as soon as they have used the first password. If you had a mantrap entry, you wouldn't want your alarm to go off at the first door? Huh?
Also Guy, this isn't about what professionals are doing...this is security for the masses. Like you, I use GNU Linux but we both know that it remains in the minority from a user experience perspective. Sometimes, it is hard to get people to try it, isn't it? Perhaps not for everyone. People aren't going to do all that you describe above because they are not as technically adept as the professional. They aren't enabling 2FA, either. Wiki editors could simply check a box in their gadgets and enable what I'm talking about. With new accounts having them enabled by default (still an optional idea), there would be no further complication than simply entering the second password. Remember that many folks don't perform regular backups so getting a more satisfactory security practice is a balance between the practical and the ideal. KISS principle applies over Kerckhoffs's principle here. This would offer a pragmatic approach where a solution has not been realized for the masses of our editors/admins. If there is a hole (exploit) to what I suggest then help me fix it but we need other options available. This option could also be quantified by similar results as those used to determine only 16% admins have 2FA enabled. We don't have a way of quantifying who decided to take your long passphrase suggestion so easily. — Berean Hunter(talk) 15:15, 6 September 2018 (UTC)
I just want to respond specifically to User:Xaosflux's two password idea. I think what we need is some kind of privilege escalation mechanism, like unix's sudo. I maintain two accounts (User:RoySmith and User:RoySmith-Mobile). I use the later on my phone because I don't want to leave an admin-enabled login session on a device that's easy to lose. It's a common practice, but it's awkward, and fails KISS. I'd rather have a single account, and a way to say, "authenticate and grant me admin rights, which automatically expire in N minutes". BTW, the best 2FA device I've ever used was the Yubi Nanokey. It lived in a USB-A port on my laptop, so it was always within reach, and totally convenient. If you make things easy to use, people will use them. If you make them awkward to use (i.e. having to type in a code), people won't use them. That's human factors for you. -- RoySmith(talk) 15:44, 6 September 2018 (UTC)
Can I add that you do not need a smartphone (or any phone) to have 2FA. There are other systems to generate that data, so long as that system has your 16 digit code and the current time, then it can work it out. I've enabled 2FA on my account and my Bot account (an adminbot). All I use is a simple python routine to give me both numbers (User:Ronhjones/2FA). I suspect there are other ways it can be done on the PC (you could always load up a Memu android emulator). Ronhjones (Talk) 21:25, 12 September 2018 (UTC)
There's also Winauth, a portable open-source Windows 2FA authenticator that also supports encrypting your TOTP seeds with a FIDO U2F hardware token. --Ahecht (TALK PAGE) 21:08, 13 September 2018 (UTC)
A bot to ping pending changes reviewers
So I'm looking at the pending changes backlog, and there are 39 pages in it. The oldest revision has been waiting for 45 hours; the next oldest, 25. We have over eight thousand users who could review these changes (probably less, once activity is taken into account), and somehow all of them have just not looked at Special:PendingChanges. I propose we have a bot that pings random pending changes reviewers (opt-in or experienced (>50 reviews) PCRs only? let me know) when the backlog gets over 10 pages (threshold up for debate) or a revision is over 24 hours old. Thoughts? Enterprisey (talk!) 06:14, 8 September 2018 (UTC)
So you are proposing having a bot nag me about pages with pending changes that are not on my watchlist? Editing Wikipedia is like drinking from a fire-hose; you need to focus on the articles you are interested in improving.--Guy Macon (talk) 06:45, 8 September 2018 (UTC)
It's opt-in. (Probably.) Enterprisey (talk!) 07:06, 8 September 2018 (UTC)
I imagine this falls under same de-facto policy as reporting AIV backlogs to AN. That is to say – don't. :P Although if people want to opt-in to the pain, then by all means. TheDragonFire (talk) 07:10, 8 September 2018 (UTC)
The thing is, the people at AN are probably very aware that AIV exists, and likely check it from time to time. I imagine many pending-change reviewers just don't check the pending changes page whatsoever, and this would just be a reminder. Enterprisey (talk!) 07:11, 8 September 2018 (UTC)
Who says that pending changes reviewers are supposed to respond to all pending changes requests on all pages? I certainly never signed up for that. Sure some reviewers would be willing to do that , but for them we have Template:Pending Changes backlog and Template:Pending Changes backlog-defcon --Guy Macon (talk) 18:11, 8 September 2018 (UTC)
This has started to go slightly off-topic, but I don't think many reviewers stick to a single topic area, as there's nothing in the pending changes guidelines that requires topic knowledge.
Another thing I could do is exempt editors above a certain number of edits, on the grounds that they would get annoyed by such a notification. Enterprisey (talk!) 18:40, 8 September 2018 (UTC)
I'm glad you mentioned those templates. I now have an instance on my user page, where I'm more likely to notice it. — AfroThundr (u · t · c) 13:47, 10 September 2018 (UTC)
I mostly just forget that Special:PendingChanges exists, because I don't have these pages on watchlist. I will add it as a thing To Do. --Izno (talk) 12:04, 8 September 2018 (UTC)
SOunds nice, ATM. I don't put those pages on my watchlist because there are a few thousand of them, and also all the normal ok edits that happen to them would clog it. If you are willing to spend the tiem to make a trial bot, I might opt in for a few weeks next spring when I have time. Thanks, L3X1◊distænt write◊ 16:02, 8 September 2018 (UTC)
Yeah, since there are so many PCRs I'd imagine, by default, the bot would ping a given user only once every six months or some massive time period like that, when the backlog gets quite high. Enterprisey (talk!) 18:42, 8 September 2018 (UTC)
I'd be interested in a ping when certain criteria are met, such as >50 entries outstanding, or >48 hours pending, with a cooldown of X days (configurable). This could even be entirely opt-in and user-customized with a template like the Miszabot config. The bot could just check the talk pages of all reviewers (or check for transclusions of the hypothetical template) so it can know who to ping. It doesn't even have to clutter the user's talk page either, since the bot could just post on a central PC status page or something. — AfroThundr (u · t · c) 13:47, 10 September 2018 (UTC)
I wonder if bots can just ping notifications without the talk page spam. I wouldn't mind a bot that did that for a lot of the things around the wiki. --Izno (talk) 15:52, 10 September 2018 (UTC)
Yes, that would definitely be a good idea. Enterprisey (talk!) 06:34, 12 September 2018 (UTC)
This looks like a nice idea, if only the bot could ping and not spam talk pages. I always forget about Pending changes L293D (☎ • ✎) 12:20, 12 September 2018 (UTC)
Yes, I've decided to have it ping users on a talk page, so that the targeted pages (maybe two or three per user pinged) will show up in the notification. I could also ping users from an edit summary directly, thus avoiding cluttering up a talk page, but that would be harder to audit. Enterprisey (talk!) 20:00, 12 September 2018 (UTC)
I think it is commons: that does this: displays a "pending changes is backlogged, please help" to only pc access people - might be on watchlist only. — xaosfluxTalk 12:40, 12 September 2018 (UTC)
Actually, that is "patrol backlog", but same concept. — xaosfluxTalk 12:41, 12 September 2018 (UTC)
I've opened a discussion at VPPR. Thank you all very much for the input. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)
Logout tool
I made this suggestion over at meta 3 months ago and nothings come of it, so I wanted to post it here and see if perhaps a more active project would be interested in running with it. I'd like to propose the creation of a universal logout tool that can see what devices currently read your account as being logged in and log out of all of them so as to better insure account security. I know that certain password protected services (such as Gmail) have this option in place to unilaterally log out of all devices that read as having logged onto or into your account, so utilizing the tool for Gmail logs you out of your desktop, laptop, smartphone, and ipad devices which then require you to log in to all devices again. Such a tool would be a good fit for Wikipedia, I think, especially since many of us edit from public computers, mobile devices and the like. Being given the option to log out of all devices at once would increase account security and help keep accounts in account holder's hands. TomStar81 (Talk) 19:10, 17 September 2018 (UTC)
Showing a list of logged-in devices would require wiki servers to keep a log of which devices are issued persistant cookies. I'm not sure what the current data rentention policy is for data such as device type/browser/etc, but IP addresses used to access the site are currently only stored for three months (which is shorter than the 1-year expiration for checking the "keep me logged in" buton). As to the second part, clicking the "log out" link on any device should regenerate your login token, signing you out on all devices. See phab:T51890. --Ahecht (TALK PAGE) 20:25, 17 September 2018 (UTC)
Thinking more about this, there might be some merit in allowing all users to run the WP:CheckUser tool on themselves, to see if they can spot unusual activity. It wouldn't exactly show a list of logged-in devices, but it would give users a window into their own account activity. Only downside is that access to such a tool could help sockpuppets to make sure they are properly covering their tracks. --Ahecht (TALK PAGE) 20:41, 17 September 2018 (UTC)
I don't think a hacker getting access to your account should be able to see your IP address. PrimeHunter (talk) 21:53, 17 September 2018 (UTC)
@TomStar81: actually using Special:UserLogout on any session should log you out of every session already - though it doesn't let you 'display' the sessions. — xaosfluxTalk 23:17, 17 September 2018 (UTC)
Well that's good news! If you log out from any machine you should log out form all machines, which helps keep accounts secure. Thanks for the reply and for entertaining the idea (although in this case it appears you guys were one step ahead of me :) TomStar81 (Talk) 23:52, 17 September 2018 (UTC)
Only tangentially related, but for what it's worth, you can see any applications you've granted authorization to at Special:OAuthManageMyGrants. ~ Amory(u • t • c) 01:29, 18 September 2018 (UTC)
2 new ideas
I don't know if this is the right place to ask but I came up with these 2 ideas:
recognizing blocked users on history pages
When viewing history pages there should be a way to tell that a user is blocked, for example, to have the word "(blocked)" after the blocked user's username. ------ 06:13, 20 September 2018 (UTC)
Check out the "Strike out usernames that have been blocked" gadget in your user preferences. DMacks (talk) 06:31, 20 September 2018 (UTC)
thanks, that was quick. ------ 07:42, 20 September 2018 (UTC)
watchlist for all Wikimedia sisterprojects
To have all of my watchlists on a single page, so that I shouldn't have to visit each sisterproject separately in order to check my watchlists. Thanks in advance, ------ 06:13, 20 September 2018 (UTC)
thanks, I'll check when I'll have a chance. ------ 07:42, 20 September 2018 (UTC)
Possible rules for top icons?
WITHDRAWN
This a non-issue that I should not have brought up here. I seem to be the only one who cares about top icons. No one seems to want to have a guideline for this right now. So I’ll just continue what I’m doing. funplussmart (talk) 15:11, 24 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I came across a WikiProject Topicons a while ago, and I was interested. I added myself to the list of participants, but it appears that the only other member is mostly inactive. So I came here in order to get attention to possible rules when it comes to page top icons. I want to standardize the way we make and name top icon templates, and I have a few ideas.
Here's my proposed set of rules regarding the creation and use of top icons:
1. Top icons meant for userpages must only show what a user does on Wikipedia (or in some cases other WMF wikis). Examples include:
For project pages, this may include a top icon describing the page's role, such as those showing the kind of policy of information page.
3. Any top icon template clearly does not adhere to these rules may be speedily deleted under CSD T2.
Examples of top icons that are not allowed include those showing a person's activity on a non-WMF site (such as a social media site), those displaying a user's personal life practices (such as their religion, job, or hobbies), or spoiler templates and other templates that are clearly against established policy.
4. Top icon templates must follow a standard naming procedure.
For userspace top icons, the titles of the templates must end with "topicon". Those showing WikiProject membership should normally follow "WikiProject (name of WikiProject) topicon", although exemptions to some WPs (such as {{AFC topicon}}) are appropriate.
For other top icons, consensus should determine the template title.
I would like hear what you guys think before I officially propose this. funplussmart (talk) 17:22, 22 September 2018 (UTC)
I don't think it's an issue if rules 1 or 3 are broken. Rule 2 is sensible but it's WP:CREEPy and I don't think anyone really breaks it. Rule 4 is sensible but we can just make a redirect or something, and it doesn't cause any disruption. Enterprisey (talk!) 18:38, 22 September 2018 (UTC)
So far as people want to decorate their userpages, so long as it is not deceptive (e.g. claiming to be an admin when not), interfering with the page display, or already covered by a CSD I'm not seeing much problem. Some people like to notate FA's they authored, or even that they like trout....and I don't see any problem there. As far as article, and perhaps portals, go (things that are primarily reader-facing) these should be standardized and well supported. — xaosfluxTalk 18:48, 22 September 2018 (UTC)
I don't have a problem with that either. I just don't think there should be the same variety of userspace top icons that we have with userboxes. funplussmart (talk) 03:06, 23 September 2018 (UTC)
The majority of the ones I've seen (or used) fall under Category:User top icon templates, which all seem like decent top icon uses to me. Have you seen any examples in particular that seem ill suited as a top icon? — AfroThundr (u · t · c) 06:27, 23 September 2018 (UTC)
I have found a few related to the user's nationality, like {{Bangladeshi topicon}}, which would not be allowed because it is unrelated to their activity on Wikipedia. However, a similar top icon template that says that the user is a member of WikiProject Bangladesh would be allowed. funplussmart (talk) 15:41, 23 September 2018 (UTC)
What's the issue with that one? We not only allow users to declare their nationality, political views, religion, employment history etc, we encourage it, as it allows other editors to get a picture of who they're dealing with. Why would you ban {{Bangladeshi topicon}} but allow that same editor to say "I am Bangladeshi" on their userpage? ‑ Iridescent 15:46, 23 September 2018 (UTC)
This is just the idea lab. We already have userboxes for that fulfill that role btw. The point is that I think the rules for userspace top icon templates should be stricter than those for userbox templates. That's why I brought this up, to try to address issues like this. funplussmart (talk) 15:55, 23 September 2018 (UTC)
If you want a change made—especially a change that goes so squarely against the usual Wikipedia practice of letting people put what they like on their userpage provided it's not disruptive—the onus is on you to explain why you think it's a good idea. You can't just say I think the rules for userspace top icon templates should be stricter than those for userbox templates without explaining why you think we need another layer of bureaucracy. ‑ Iridescent 16:03, 23 September 2018 (UTC)
The primary reason why I proposed the rules here is because I seem to be the only active member of the WikiProject. funplussmart (talk) 15:50, 23 September 2018 (UTC)
(edit conflict)Unless there is a problem we don't need rules on user pages. Far too WP:CREEPy and will only cause another acre or two of arguments. Martin of Sheffield (talk) 15:59, 23 September 2018 (UTC)
I noticed that. I guess that puts me in charge of the entire WikiProject. We definitely need members, that way we can work this stuff out and not be so WP:CREEPy. funplussmart (talk) 16:07, 23 September 2018 (UTC)
I repeat: unless there is a problem we don't need rules and regulations. Consensus is the only way to get things accepted, and calling yourself "in charge of the entire WikiProject" will do nothing except annoy experienced editors of many years standing. WP:DROPITMartin of Sheffield (talk) 16:11, 23 September 2018 (UTC)
The primary issue at this point is not the top icons themselves but the status of the WikiProject. I am going to stop arguing for my idea for rules on the top icons over here per Martin of Sheffield. I would like to know where to go to try to more people who are interested in top icons, so that we can build consensus on what to do. funplussmart (talk) 16:22, 23 September 2018 (UTC)
When I said "I am in charge of the WikiProject", I meant that it is a situation that is not good. I know that concencus is the way to go, and I said "I am in charge" as a sarcastic way to gain people's attention to the lack of consensus. Obviously that didn't work because all of you are yelling at me over it. funplussmart (talk) 16:39, 23 September 2018 (UTC)
Do nothing - Common sense should prevail, We don't need policies and rules for everything. –Davey2010Talk 19:08, 23 September 2018 (UTC)
At this point I think we should just stop talking about this. I seem to be the only person over here that it interested in creating and maintaining top icons. I came over here for suggestions, but I executed this whole thing very poorly. I'll just continue what I'm doing, and we can bring up issues later if they come up. As Davey said, it's mostly common sense here. funplussmart (talk) 19:33, 23 September 2018 (UTC)
Agree with you both. I didn't want to weigh in earlier as per DIY Wikipedia is open for anyone to work and don't want to discourage funplussmart from working in the area. Thanks, L3X1◊distænt write◊ 02:27, 24 September 2018 (UTC)
(edit conflict)@Funplussmart: If that's the case, then you could just WP:CLOSE the discussion as withdrawn. FWIW, you're not the only one who cares about top icons. The community just doesn't seem interested in adopting a formal policy or guideline on the matter at this time. — AfroThundr (u · t · c) 02:33, 24 September 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Converting currencies
Values of currencies are always changing and to still have correct informations a template might be usefull, which displays the past amount or different currency in todays and own currency/value. Do you think that is possible? --2003:C3:EF27:FA6B:28C8:ADD0:41A4:1989 (talk) 19:24, 23 September 2018 (UTC)
Now blocked, as after being warned over a month ago this user is continuing to spam-bomb Wikipedia with inappropriate lengthy posts like this. Their main area of activity is on Wikiversity rather than here; I suspect this is a good faith editor who doesn't understand that what's acceptable over there isn't acceptable here, but they've ignored more than enough warnings by now. ‑ Iridescent 12:19, 6 October 2018 (UTC)
steamboats in the mon
Hi, I have an idea on steamships. I have already created 2 articles, and would want more help. Thank you.Huff slush7264Chat With Me 13:17, 7 October 2018 (UTC)
If you want any help at all you need to start by giving a bit more information out. What is meant by "steamboats in the mon"? Which articles have you created and what help do you require? I was glad to see you removed that l33t nonsense, it has no place in Wikipedia. Regards, Martin of Sheffield (talk) 16:38, 7 October 2018 (UTC)
Temporary non-admin page protection
Will it be a good idea to have a new permission where a non-admin can temporarily protect a page to stop heavy Vandalism? For example, sometimes there are pages which get vandalised at a very fast rate and due to a very large backlog, an admin might take some long time. An example is this article, which was vandalised so heavily by different users and IPs that it not only took a lot of time, but also confusion. The page protection took some time due to the backlog. The permissions of this protection can be made strict, and only trusted users who are active in RC patrolling can be given it. What do you people think? Knightrises10 (talk) 12:21, 1 October 2018 (UTC)
@Knightrises10: Actually, there was an RfC on this not too long ago. Reading this might be helpful for developing this, if it will pass. SemiHypercube✎ 12:31, 1 October 2018 (UTC)
@SemiHypercube: I'm going through that discussion and think that it's correct to say that an admin can take away the right in case of abuse, just like they do on rollback. Also, the page can be protected just for like 15 minutes or less. Need some suggestions. Should I take this to proposals? Knightrises10 (talk) 12:46, 1 October 2018 (UTC)
Probably dead on arrival. This is proposed about every six months and no formulation has come close to reaching a broad consensus in favor of implimentation. GMGtalk 13:42, 1 October 2018 (UTC)
So it should rather be forgotten it means? Knightrises10 (talk) 13:53, 1 October 2018 (UTC)
At least in my opinion, it's almost guaranteed to be a non-productive use of time, at least until some future date when the feelings of the community at large shift toward more radical unbundling of sysop rights. No idea when or if that might actually happen. GMGtalk 14:40, 1 October 2018 (UTC)
I'm not often in disagreement with GMG (And to be fair that editor isn't opposing this idea, just opining that it is unlikely to be successful).
I could be in support of a proposal to give very limited protection capability to some class of users. My proposed class would be extended confirmed (I wouldn't mind a somewhat more stringent criteria but this one is easy and creating a new class sounds like a lot of work). The capabilities would be semi-protecting only (not full protection) and limited to 15 minutes. The harm that could come to the encyclopedia if someone incorrectly semi'd an article for 15 minutes is absurdly small, while the benefit is meaningful. Abusers, after a first warning, could have the right removed. If even this small proposal seems too much, make it a six-month trial and see how it works. Seems to me that an immediate semi on an article being repeatedly vandalized to give time to post to AIV to request more substantial measures (longer semi, blocking offending party) is a pretty reasonable step.--S Philbrick(Talk) 14:51, 1 October 2018 (UTC)
Oh yes. To clarify, I would personally support such a proposal, and I even drafted one myself last year at User:GreenMeansGo/Page protector. I simply don't think the community will support it, and more to the real problem, the opposition isn't on one or two central issues that can be fixed by amending the proposal itself. Opposition has always been broad and based on a half-dozen or more issues that can't be easily reconciled. GMGtalk 14:56, 1 October 2018 (UTC)
Unfortunately, the last time it was proposed, most of the community opposed it with the reason it will lead to abuse. Rollback also has same concern, but isn't it working pretty well - users who abuse the rollback have their rights taken away. Knightrises10 (talk) 15:21, 1 October 2018 (UTC)
Looking over it broadly, the opposes include all the following:
Potential for abuse/protection warring
Conflict with having a protect button but not a block button, and/or not a delete button, and/or not an unprotect button, and/or not able to see deleted edits
Users who can be trusted to protect should just become admins anyway/users who can't become admins shouldn't be given this right to begin with
How this tool might interact with the ability to unprotect, to unprotect pages protected by another non-admin, or to unprotect pages protected by an admin
Potential degradation of status as “the encyclopedia anyone can edit”
Solution looking for a problem/ RFPP works well enough to render the right unnecessary
Concern that it is easier to grant an unbundled right than it is to remove it
Concern that this would add an unofficial prerequisite to RfA
Semiprotection is already overused
I don't see a way to adjust a proposal to account for the majority of those oppose rationales. GMGtalk 15:35, 1 October 2018 (UTC)
As told before, permissions can be taken away.
Protecting button should be considered different from deleting button. I don't think they should be compared, as block and deletion are something more sensitive.
Rollbackers, reviewers are also trusted users but not admins. A user can be trusted and yet not an admin.
The pages will only be protected on case of heavy Vandalism, so it will remain an encyclopedia that anyone can edit. Admins also protect pages, but we don't call it degradation of encyclopedia because it's necessary at that time.
Again users shouldn't be allowed to unprotect pages protect by others.
I can answer some. But as Sphilbrick said, we can at least try this for some months, giving this right at the moment to only a few very trustworthy users. Knightrises10 (talk) 15:47, 1 October 2018 (UTC)
One idea that could be considered is NeilN's proposal that was suggested in the RfC, which many people thought was good. SemiHypercube✎ 15:58, 1 October 2018 (UTC)
Read his idea and I think that should have no concern - Knightrises10 (talk) 16:05, 1 October 2018 (UTC)
So guys, I'm taking this to proposals as I think it can have another debate. :| Knightrises10 (talk) 18:53, 1 October 2018 (UTC)
Just a tech note: Adding new "access groups" is EASY, adding a new technical workflow is not - for one it would require that there are developers that want to work on it (in this case a new tech process to build this protection workflow). — xaosfluxTalk 19:58, 1 October 2018 (UTC)
@Knightrises10: - as well as the full, recent, RFC there was a also a discussion following on to specifically consider shorter protection. In a sense it was a discussion of NeilN's proposal that garnered more support during the RFC. I was unsure enough both of the level of support and of my own personal views to take it onto proposals, but it's worth a read, I feel.
I've also cut out a rough summary of points that were agreed as a good starting basis:
Protection would be limited to semi-protect.
Protection duration would be limited to between 45m-3 hours (TBD).
Right holders ("RHs") could only protect the same page once within 24 hours.
RHs could only protect 2 pages within one hour.
There would be stringent requirements at WP:PERM to acquire this right. At a minimum: 2000 posts (or 1500 mainspace?), a clean 6 month block record, registered user for 150 days, proven track record in Counter-vandalism, proven track record in Requests for Page Protection.
The right could only be used in Main or Talk (not including User Talk) namespaces.
Right could only be used in instances of vandalism from multiple IPs/newly registered accounts. Alternate uses of protection (such as against unsourced details etc) would not be permitted
There was some specific dispute on this point:
8. Use of the right must be accompanied by a full request for some form of page protection at WP:RFPP. Failure to do so would be deemed a mis-use of the right.
I would support any attempts to create a non-admin page protection right given that RPP is one of the most frustrating parts of the site given the current admin shortage, the criteria listed above were created in a discussion I participated in but feel that they are far too stringent.The harm 1 or 2 innaporitate semi-protects can do is minimal compared to the amount of vandalsim granting this ability could prevent.Zubin12 (talk) 15:13, 6 October 2018 (UTC)
Hi @Zubin12: - The harm of some inappropriate semi-protects could do bigger than some missed vandalism - on some active pages it could prevent dozens of individuals from editing, it also grants certain users significant power in any potential editing dispute without them having gone through the full RfA rigmarole. Additionally, you need to look at the maximum size the RFPP backlog gets to - the issue is usually some remaining on the list for extensive periods of time, rather than dozens at once overwhelming present admins. Thus a fairly small additional core of users with limited abilities would at least reduce the issues. Finally, on a bluntly pragmatic front, strict criteria improve the chances of agreement that one of the triple-prong of core admin rights isn't being challenged. Nosebagbear (talk)
I do think a time in point 2 could be higher, but I don't think longer than 4-6 hours could be justified, however a time of 3 hours seemed a rough compromise of the points up to the point when I scribbled the above down Nosebagbear (talk)
Idea: Watchlist page flagging
I think I've pitched this before, but with the recent changes to the watchlist I figured I'd bring it up again. I have close to 15,000 pages on my watchlist and I'd love to be able to flag certain pages in my watchlist with color-coded labels, to make it easier to get to articles that have been recently problematic. Example: If a sock operator is known for editing at Vijay (actor), I would flag the article with the sockmaster's name to make it easier to spot recent flare-ups. Another example: If a film article has seen a lot of users perniciously inflate or deflate box office figures, I might flag the article with a green label so I could get a quick reminder to check it out.
I deal with many Indian film articles, about films in the many languages of India (Hindi, Tamil, Malayalam, etc.) A lot of the titles are meaningless to me, so I might gloss over them in my watchlist. The flagging would be helpful. Thanks for listening! Cyphoidbomb (talk) 13:50, 8 October 2018 (UTC)
@Cyphoidbomb: The poll is run each year. The next one starts accepting new wishlist items pretty soon. --Izno (talk) 02:06, 12 October 2018 (UTC)
2 grades of watchlist
I find that there are 2 types of article that I have in my watchlist. The first are those that I have edited and have some general interest in any changes/developments. It is not a big problem if I miss something or if there is no activity on the article for a long while. The second category is where I (or another editor) have flagged a problem and am awaiting a response. This could be a {{Citation needed}} tag, or a comment on a talk page. For some "low traffic" articles, it seems to me appropriate to leave these alerts in place for some time before acting on them if there is no response. (I have had another editor get upset when I have acted after flagging an issue 2 weeks previously - so a longer delay seems to avoid dispute.) Relying on memory and a filtered contributions page do not seem to be 100% reliable in picking up any article that I intend to watch in this way.
The solution would be to have an "enhanced watchlist" - just an extra flag you can put on an article where you do not want to miss any activity - and perhaps a facility to show only those enhanced watchlist articles/talk pages with no edits since switching to the enhanced status. (It is this last category that seem most difficult to track effectively.) I would be interested to see if anyone else felt there was value in this change - or if there is an existing solution of which I am not aware. ThoughtIdRetired (talk) 07:44, 3 October 2018 (UTC)
Yeah, this is a good feature. You can approximate this with MusikAnimal's awesome script User:MusikAnimal/customWatchlists, by creating a "high-priority" custom watchlist. I don't think that last feature is supported, but I pinged Musik to check. Enterprisey (talk!) 07:55, 3 October 2018 (UTC)
That script badly needs rewriting! But it should mostly work :) You can view the "raw list" of pages, not just ones with recent changes, if that helps. By the way this proposal is basically Wikipedia:Perennial proposals#Multiple watchlists. I think we're still a long ways away before we have native support for it. But I can improve customWatchlists, it's been on my to-dos for some time — MusikAnimaltalk 17:02, 3 October 2018 (UTC)
Thanks. I think my requirement for spotting cases of no activity (after tagging or talk page comment) on certain watchlist articles is different from the archived discussions. It is an editing methodology that seems to work with apparent "fossils" that may or may not have a following with strong opinions. (Some of these fossils are full of the most amazing nonsense, sometimes referenced with sources whose content has little similarity to the article.)
Being more of an "article content" editor, rather than someone who is into the nuts and bolts of Wikipedia, I only have a passing understanding of the technical issues. Bearing in mind that I might have only about 10 articles where I am waiting to see if anyone reacts to a tag or a talk page comment, I might start cutting and pasting a handful of selected article names into a corner of my sandbox. (Or perhaps I could put a section on my user page: "waiting for answers on...") It is only one step better than using a post-it note, but at least it is simple. ThoughtIdRetired (talk) 19:12, 3 October 2018 (UTC)
That's a good idea, PaleoNeonate. I think it would work for a lot of people.
MusikAnimal, do you remember whether multiple watchlists has been in the m:Community Wishlist in the past? I think that the maps item last year proved that a little organization can go a long way towards getting what editors need, and I believe that nominations begin soon. WhatamIdoing (talk) 18:10, 4 October 2018 (UTC)
I use a cruder "top and bottom" method. I first look at the top of my watchlist. Most changes are on articles that are not urgent for me, and I don't check them until they approach the bottom of my five days watchlist (recently re-preferenced from six). This has the advantage of keeping me aware of boring, raging content disputes on an interesting topic, without being tempted to stick my nose too deeply into them. On some pages, such as VP, I look into each change when it arrives at the top of the page, at least if the section header and edit summary give a hint that it will interest me. Jim.henderson (talk) 09:58, 5 October 2018 (UTC)
A few years back, I talked with an editor who skipped the first week of her watchlist. This allowed her to skip nearly all contentious discussions and focus on adding content. It seemed like a good idea (only I can't see myself doing it). WhatamIdoing (talk) 03:17, 10 October 2018 (UTC)
We specialize based on our talents. I lack the discipline to cut my watchlist below 5,500 pages, but have the power to detach myself from reaction and take a longer view. So, having left the necessary pig-wrestling to those who have the stomach for it, I come along after the battle to kill the crippled sentences, plug the leaking modifiers, rearrange the disordered paragraphs and so forth. Jim.henderson (talk) 10:43, 13 October 2018 (UTC)
Change "Publish changes" button in Draft Space
Apologies if this has been suggested before - I looked in the archives and didn't see anything - but I think the "Publish changes" button is confusing to many newer editors who are working in draft space. I would like to suggest that in draft space the "Publish changes" button read "Save draft". I don't know how feasible in the mediawiki software this would be to do but think it would help make clearer that what the user's doing by pressing the button. Best, Barkeep49 (talk) 15:50, 8 October 2018 (UTC)
Yes, please. This seems to confuse many new editors that are working on drafts at AfC. Natureium (talk) 15:51, 8 October 2018 (UTC)
@Whatamidoing (WMF): Since I'm pretty sure you have the history/know the people for the last time this button was changed. --Izno (talk) 16:38, 8 October 2018 (UTC)
That being said, back then, it was determined that "some editors worried that this change would confuse new editors. There have been no indications so far that this is the case." That perception may have changed. – Finnusertop (talk ⋅ contribs) 16:47, 8 October 2018 (UTC)
I say this only based on my experience trying to help people on IRC who are confused about how to save their drafts. I figured this was not a "easy change" and am glad to know now that it's even more involved than I had realized. Best, Barkeep49 (talk) 22:47, 8 October 2018 (UTC)
As barkeep49 said, this confuses a number of people that come to #wikipedia-en-help and can't figure out how to save their draft to keep working on later, without "publishing" it. Natureium (talk) 22:49, 8 October 2018 (UTC)
I have also seen it repeatedly, coaching at edit-athons, though more often it's a Talk Page that confuses. I would prefer "send" but if that is thought to create an expectation of privacy, then "send public". Jim.henderson (talk) 22:59, 8 October 2018 (UTC)
IMO "Post" might be more appropriate (in English) for talk pages, but there's a fundamental problem: In MediaWiki, all pages get the same button, regardless of namespace.
Barkeep49, would you do me a favor, the next time you get this question? Would you please ask the person if they're looking for a way to privately save their drafts? My impression is that when people ask for a way to save their drafts, they're correctly recognizing that "Publish" is going to make the draft public, and that's not what they want to do. So "Where's the save button?" doesn't mean they can't figure out what the Publish button does; it means they know exactly what the Publish button does, and what that button actually does is not what the users want to do. They want to save the draft privately, until they think it's good enough to post on the internet – which, of course, can't be done. Whatamidoing (WMF) (talk) 20:56, 9 October 2018 (UTC)
It's been quiet on this front for the last week. I did have someone tonight with this question. They reported that they were looking to save privately but if the button had said "Save draft" they would not have been confused. So mixed result from a sample size of 1. Best, Barkeep49 (talk) 04:01, 16 October 2018 (UTC)
I think one consideration is that even Draft space is not entirely private; stuff posted there can still be found by anyone who gets there through other Wikipedia categories/project pages or through search engines which don't exclude Draft space. Jo-Jo Eumerus (talk, contributions) 09:06, 16 October 2018 (UTC)
Minor canned edit summaries
For convenience, I think that when a user selects a minor canned edit summary, the minor edit check box should be automatically checked if it hasn't been checked already. Care to differ or discuss with me?The Nth User 23:51, 15 October 2018 (UTC)
@The Nth User: But what if an IP is using it (unregistered users cannot mark edits as minor)? Also, I don't think this is such a good idea, since vandals could use auto-minor edits to further evade vandalism, (in fact, seeing "canned edit summary" tagged onto an edit only attracts my attention when I am recent changes patrolling) so this isn't a good idea even if unregistered users cannot mark edits as minor. SemiHypercube✎ 00:03, 16 October 2018 (UTC)
@SemiHypercube: The first point is easy to fix; just code it so it only checks the checkbox if there is one. The second point may or may not be a problem depending on how most users search for vandalism. I use a personal filter setup at Special:Recent changes, and I doubt that the filters pay attention to the edit summary for the reason that you pointed out: Vandals might use edit summaries like "fixed typos" to mask disruptive edits. However, if most users pay attention to edit summaries when searching for vandalism, then your point is valid, and my change should not be enacted. Care to differ or discuss with me?The Nth User 00:13, 16 October 2018 (UTC)
Redesigned page-protection padlock icons
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Redesigned icons (right) compared to the existing icons and descriptions (left)
I redesigned the page-protection padlock icons for a more minimalist and intuitive look. The redesigned icons use solid colors, since the shiny reflections off of the current ones make the edge hard to distinguish from the background. Some less-used protection icons now have symbols on them for clarity. For example, a create-protected page has a plus sign, and a cascade-protected page — where all pages transcluded onto the page are also protected — has a chain symbol.
One solid color instead of colored metallic texture
No shadows
No glow
Minimum 3:1 contrast ratio (WCAG AA 2.0 compliant)
Thicker shackle that matches the color of the main body
Rounded rectangle main body
Embedded white symbol for some padlocks
Posted by XYZt (talk) at 00:17, 29 September 2018 (UTC) — Updating over time — Thank you for your feedback and suggestions! I think I'll have a proposal posted by next weekend. Due to school projects, I won't be able to post the proposal and respond to questions from Monday to Wednesday.
The edges on the padlocks have a glow that make them appear to be fading into the background
Looks nice. I don't think really need to change the locks though. funplussmart (talk) 00:38, 29 September 2018 (UTC)
Thanks! In my opinion, the main problem that the current locks have is that they have parts that blend in with the white background (e.g. the white glow at the edges, a thin shackle). I think having a solid colored version is easier to see. The embedded icons are another idea that I think would help people identify the locks' different purposes. XYZt (talk) 00:49, 29 September 2018 (UTC)
These look great! The addition of icons to some of the less common locks is really helpful, I'm not sure how anyone can remember them from colour alone. the wub"?!" 16:43, 29 September 2018 (UTC)
I agree, these look great and are a clear improvement.Tazerdadog (talk) 18:58, 29 September 2018 (UTC)
Hmm, I think the current set looks a little "smarter", however these are significantly clearer and more useful when it comes to easily knowing what each padlock indicates. Given that clarity is key, I'd happily support these as better. They would require alteration of some of the most used templates, so I imagine there might be some opposition just on those grounds, rightly or not. Nosebagbear (talk) 22:53, 29 September 2018 (UTC)
Support implementation. The fade into background was a particular problem on mobile and for us editors with Corrected vision. I like the symbols int he middle as well. Thanks for doing this. Thanks, L3X1◊distænt write◊ 00:03, 30 September 2018 (UTC)
Support implementation, seems like they could be usable in mobile view. @XYZtSpace: Side note, if these were actually implemented, would these images be new files or replace the old ones? SemiHypercube✎ 01:01, 30 September 2018 (UTC)
I'd advocate making them with new names so the old ones would stay around for archival purposes. Thanks, L3X1◊distænt write◊ 01:03, 30 September 2018 (UTC)
The old ones will still be visible on each file's revision history (note that for files, the image history is available on the same page as the main image). Posted byXYZt (talk | contribs)on 01:12, 30 September 2018 (UTC)
Thanks. These images would probably be uploaded as an revision on the old files' pages, as these icons are linked by about 30 protection templates combined. Changing the file link on each template would be time-consuming. Posted byXYZt (talk | contribs)on 01:12, 30 September 2018 (UTC)
@Galobtter: Got it, thanks! I guess that eliminates the need to upload the redesigns to the same file names then. -- XYZt (talk | contribs) 23:04, 30 September 2018 (UTC)
I believe all wikis use the locks, so I think any change like this should probably be proposed on meta. I'm not sure though. funplussmart (talk) 01:03, 30 September 2018 (UTC)
@Funplussmart: we can change these locally without impacting any other project. The "default" is nothing; we shadow the commons file names (e.g. File:Padlock.svg) to maintain local protection and control of the image. — xaosfluxTalk 01:53, 30 September 2018 (UTC)
That's why I said "I'm not sure". funplussmart (talk) 01:54, 30 September 2018 (UTC)
If you want to propose these globally, the template one shouldn't rely on the English "T" as it's interior markup. — xaosfluxTalk 01:56, 30 September 2018 (UTC)
Perhaps having "{{}}" instead of "T" would do it. funplussmart (talk) 02:03, 30 September 2018 (UTC)
Someone else suggested that too. I'm not sure if it would fit though. Will test it out later. Posted byXYZt (talk | contribs)on 02:25, 30 September 2018 (UTC)
Update: I'm not sure if it's as eligible as the "T". Posted byXYZt (talk | contribs)on 02:31, 30 September 2018 (UTC)
The two brackets on the right are too close together. Can you try to make them equidistant? funplussmart (talk) 02:36, 30 September 2018 (UTC)
They are actually the same distance apart as the left pair. I made the distance between them farther now
Instead of {{}} try just {}. — xaosfluxTalk 02:48, 30 September 2018 (UTC)
I think the last one looks okay. funplussmart (talk) 02:50, 30 September 2018 (UTC)
(←) I would say that { is probably sufficient, even, if we didn't want to use a T. The T has the advantage that there are less curves and points to render relatively. --Izno (talk) 23:28, 30 September 2018 (UTC)
It seems that Wikidata uses a lock design similar to this already, though the color appears to be somewhat different. For example, check the lock on the top-right of Wikidata's main page. Does this have any relation to you, XYZt? —Nøkkenbuer (talk • contribs) 15:25, 30 September 2018 (UTC)
That's cool! I don't use WikiData often and didn't notice it. No relation whatsoever. -- XYZt (talk | contribs) 16:23, 30 September 2018 (UTC)
Pale colors, especially yellow but also pale blue, do not stand out well on white background. They need a black border or other detail. Jim.henderson (talk) 02:34, 30 September 2018 (UTC)
Thanks for the feedback. I made the yellow, teal, and light blue locks a bit darker. Posted byXYZt (talk | contribs)on 02:56, 30 September 2018 (UTC)
In general, please ensure these are WCAG AA if not AAA compliant against the background. --Izno (talk) 06:24, 30 September 2018 (UTC)
Well, they're certainly better than the current locks. Create and Pending Changes were always the hardest to spot, for me. Thanks, L3X1◊distænt write◊ 13:45, 30 September 2018 (UTC)
I make no judgement of the current locks; just asking that WP:Accessibility#Color be observed. --Izno (talk) 14:25, 30 September 2018 (UTC)
For an aesthetic point of view the originals look like padlocks whereas the new ones look like so many handbags. Tinky Winky anyone? Martin of Sheffield (talk) 16:21, 30 September 2018 (UTC)
I thought that the similar lock designs currently used at Wikidata also somewhat resembled handbags. However, the padlock icon is deeply embedded in Wikipedia symbolism, so I doubt anyone will be confused about it and newcomers can easily figure it out. It will, at worst, be a potential accessibility improvement at the cost of creating an obscure running joke in the commmunity. As far as I am concerned, being able to better see the icons and distinguish them without referring to the documentation is worth the unending terror of administrators saying that "protection of article X is now in the bag" and that they "bagged the article". —Nøkkenbuer (talk • contribs) 17:49, 30 September 2018 (UTC); edited at 17:53, 30 September 2018 (UTC)
Do not awaken my ability to rant for hours on locks and lock types… :P Thanks, L3X1◊distænt write◊ 01:11, 1 October 2018 (UTC)
I'll be honest I do prefer the current ones only because I hate change and because it's what I've been used to seeing for the last 5-6 years, That being said I do like these and I also like the little symbols on the locks which helps to differentiate between locks, Somewhat unrelated but touching on Nøkkenbuer's comment I also like the fact they're near-identical to the ones used on Wikidata, (Never used WikiData but just liked the locks).
All in all I think they look great although I do wonder if having a black border around the padlock and lock may be better?, Dunno but anyway I like these :). –Davey2010Talk 16:53, 30 September 2018 (UTC)
I guess when it comes to minimalism, even divergent designing tends to converge due to the constraints of minimalist aesthetics. In any case, I have no opposition to the new designs. Like Davey2010, I also like the internal icons, which help with decoding the padlocks and reinforce the meaning of the color scheme.My only suggestions would be to check for color accessibility and ensure AAA-level contrast, which may be achievable by simply darkening the colors if they are not already compliant; and to consider disambiguating all the padlocks with icons so that they are useful even when stripped of their color. For the latter, the semi-protection symbol can be a shield icon with the left half filled and the other, empty half given a dotted outline; full protection can be a full shield; and extended confirmed protection can be something like a shield outline with a smaller shield filling it. —Nøkkenbuer (talk • contribs) 17:26, 30 September 2018 (UTC)An addendum: I want to note that the additional icons suggestion is just that and I understand multiple reasons why including icons on those three may be undesirable. Even without any internal icons, I am still not opposed to the change, if only because the new design is more visually accessible. —Nøkkenbuer (talk • contribs) 17:36, 30 September 2018 (UTC)
I was able to make them meet AA-large standards, but meeting AAA would turn the gold lock into a (frankly disgusting) shade of brown, and make Pending Changes darker than what Semi is now. However, black outlines is a viable solution to this. – XYZt (talk | contribs) – 07:52, 1 October 2018 (UTC)
I am fine with that and understand it entirely. The prior colors were no issue for me; I just want to encourage accessibility considerations as a matter of principle. The fact that it's even AA-compliant is already far more accessible than is often the case in the Internet, nevermind the fact that the design itself improves accessibility over the current one. Whether AAA-level compliance is reached is probably not an issue; and the demographic for which AA and AAA compliance is a determinative difference is probably very, very small. None may even use Wikipedia, at least not in ways that are relevant to this proposal, and I frankly doubt Wikipedia is generally AAA-compliant. If I recall correctly, our wikilink colors aren't.Regardless, I don't think it will be ground for anyone to oppose your proposals, myself included. Thanks for being so responsive to the feedback. —Nøkkenbuer (talk • contribs) 14:41, 1 October 2018 (UTC)By the way, XYZt, it seems your design is indeed at the vanguard of contemporary web aesthetic, since Mozilla Firefox and Google Chrome also use a similar padlock to indicate valid HTTPS connections. If these are "handbags", as has been alleged, then it seems the movers and shakers of the Internet are into handbags, too. —Nøkkenbuer (talk • contribs) 14:51, 1 October 2018 (UTC)
@XYZtSpace: Even though the black lock is hardly used (but probably since Office actions are very rare), do you think you could change the black lock so that it has a silhouette of the on it to emphasize that it is done by the WMF Office? SemiHypercube✎ 23:22, 30 September 2018 (UTC)
Good idea. – XYZt (talk | contribs) – 23:26, 30 September 2018 (UTC)
@SemiHypercube: I tried it out and it isn't quite as legible as the "O" even after increasing the thicknesses of the lines. – XYZt (talk | contribs) – 02:30, 1 October 2018 (UTC)
@XYZtSpace: Have you tried making the lock, and the others, SVG files instead of PNG? The current locks are SVG files, so making the new ones SVG might make them legible. SemiHypercube✎ 12:24, 1 October 2018 (UTC)
That's not how svg files work. My graphics software rendering a vector shape at 15x20px is the same quality as Wikipedia rendering an svg at 15x20px. And at this scale, file size doesn't matter much anyway. – XYZt (talk | contribs) – 14:57, 1 October 2018 (UTC)
I assume all present understand that this will require a consensus at WP:VPR, and we're just deciding the specifics of that proposal. In my opinion that should be an RfC, considering the very high visibility of the change. Thanks, just making sure. ―Mandruss☎ 16:07, 1 October 2018 (UTC)
I think I'll divide the proposal into two parts — One for changing the locks into solid colors, and one for the embedded symbols. – XYZt (talk | contribs) – 17:06, 1 October 2018 (UTC)
Gray shackles
I like the concept, but I would make the shackels a standard gray color on all the locks to make them look less like shopping bags (#949494 is the lightest gray that meets accessibility requirements). I've seen lots of colorful locks, but almost all have silvery shackles. Also, while the PNGs are fine as a concept, I would like to see these as SVGs before implementation. --Ahecht (TALK PAGE) 21:38, 1 October 2018 (UTC)
I think the idea is to be very symbolic, not realistic. Also, I care less than none about resembling a handbag. I remember significant opposition to the "Your notices" icon now in use at the top of each page, because it would look like a bra to some. The predicted outcry did not materialize. I also note that the handle of a handbag often has a different color from the body. ―Mandruss☎ 21:53, 1 October 2018 (UTC)
I'll upload all the SVGs in a few hours. – XYZt (talk | contribs) – 00:29, 2 October 2018 (UTC)
@XYZtSpace: Could you upload a template-protect padlock with curly braces as you said? And could you also try making the office protect lock with the WMF logo on it? (Though the licensing might(?) have to be different because it uses a logo? Or is a licensing change not needed?) SemiHypercube✎ 21:23, 2 October 2018 (UTC)
As the one who first commented about the new designs looking like hand/shopping bags, may I say that the grey shackle design is much clearer and they do look like padlocks now. Martin of Sheffield (talk) 22:01, 2 October 2018 (UTC)
Given that comments seem to have stalled out, I'd say once @XYZtSpace: is free (hopefully on Thursday (11th Oct)) they should shift this to Wikipedia:Village pump (proposals) - it should also be requested to be placed on centralised discussions Nosebagbear (talk) 19:13, 7 October 2018 (UTC)
These are great. A lot easier to understand than the old locks, too. MoonyTheDwarf (BN) (talk) 19:35, 10 October 2018 (UTC)
The new locks are easier to understand and more noticeable than the older ones. I support changing the locks, as long as all the locks are changed to have a grey shackle. 344917661X (talk) 00:47, 11 October 2018 (UTC)
@XYZtSpace: I like the new icons. Are they based on the ones used at Wikidata? I think the two sets should probably use consistent colours (except maybe where the older set doesn't have enough colour contrast). Jc86035's alternate account (talk) 06:10, 14 October 2018 (UTC)
Semi-protected suggestion@XYZtSpace: These are very good icons, and I support the change. I have one suggestion, though: a different one for "semi-protected"; something that emphasizes the semi aspect. → Michael JⓉⒸⓂ 14:20, 17 October 2018 (UTC)
That's a good suggested change by @Michael J:, I like it. Not sure which school system @XYZtSpace: is on, but next week is half term in a lot of places, so that might offer a chance to move this great set of work to Proposals for the full RfC. I think the key bit we really need to hear now is from the template experts who can tell us of how much difficulty a change on this scale may have. Nosebagbear (talk) 22:50, 19 October 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
"Citation needed" button
A big part of RC patrollers' workflow at the moment is reverting unsourced good-faith edits. If an added sentence has a good chance of being correct, I think we should be putting a citation needed tag (or one of the other verifiability inline cleanup tags) after it instead of reverting it. I propose a button be added to all commonly-used RC patrolling tools (Twinkle, Huggle, STiki, etc) that adds such a tag after a sentence, and that use of it be encouraged instead of just reverting good-faith edits. This proposal came out of a discussion Legoktm, Pharos, and I had during WikiConference North America 2018. Enterprisey (talk!) 18:05, 23 October 2018 (UTC)
We'd have to be super careful to not encourage overtagging with such a button. I could see a user using it to slap the tag all over the place, instead of where it's truly necessary. Tazerdadog (talk) 18:52, 23 October 2018 (UTC)
Sure. I think it's "truly necessary" in quite a few cases, though. Of course, another action is just "do nothing", but I don't think patrollers would take that option. Enterprisey (talk!) 18:57, 23 October 2018 (UTC)
I think this is a really good idea. Anything that encourages expansion of valid Wikipedia content, and discourages blind reverting is a Good Thing. Having a larger toolset to help RCP folks out is also a good idea. --Jayron32 18:58, 23 October 2018 (UTC)
I liked the idea then, and I still do. My hope is that this gives patrollers another option besides the big revert.--Pharos (talk) 02:06, 25 October 2018 (UTC)
I absolutely will, and if it doesn't end up getting taken I will work on this, as I believe it is a needed feature. Enterprisey (talk!) 04:27, 26 October 2018 (UTC)
Honestly, I might just start working on it sooner rather than later, as it would be nice to have something to talk about at Wikipedia Day 2019. Enterprisey (talk!) 06:48, 27 October 2018 (UTC)
Pursuing legal action?
Has Wikimedia (or some subset) ever pursued or considered pursuing legal action against users that disrupt the project? There are a handful of users that cause non-negligible disruption to the project(s) to the point that areas may essentially be shut down for some period of time, damaging our utility and reputation. This was prompted by the recent events on the Reference Desk, but it has happened a number of times in the past, to greater or lesser degrees, to other areas as well. Just to be completely clear, I'm not talking about users that put "poop" into articles or even the ones that engage in more intense bursts of vandalism, but rather the ones that engage in determined, ongoing, patterns of disruption. Vandalism on Wikipedia has nothing, nor does Wikipedia:Vandalism, at least as far as I can see. Matt Deres (talk) 15:55, 24 October 2018 (UTC)
I don't believe so. Wikipedia:Long-term abuse/JarlaxleArtemis/Grawp and Wikipedia:Long-term abuse/MascotGuy have historically been as bad as the current troll, and I don't recall the foundation ever taking legal action against them. I am aware of some off-wiki legal actions the Foundation has been involved in, but AFAIK, they don't involve direct disruption of Wikipedia per se and also they are of a sensitive enough nature that I don't think I can share much details here. --Jayron32 16:18, 24 October 2018 (UTC)
@Jayron32:I distinctly remember at-least one case of off-wiki legal action but that was not against a LTA.I can find another example, where ArbCom asked WMF to look into a case but the results are unknown (and have been certainly unproductive).∯WBGconverse 16:54, 24 October 2018 (UTC)
Well the LTA says it was on their list of things to do. That case is a little different from here in that the editor concerned is AFAIK still openly editing via their normal ISP. This makes it easier both to bring a case, but also to tell the ISP 'we've told this person they're not welcome to edit our site, but they keep at it'. I know that some ISPs have been fairly dismissive of such requests in the past especially when they're been for anonymous editing (rather than continual creation of accounts). But AFAIK these have generally come from random editors rather than the WMF themselves. (Although perhaps the WMF has tried a lot more than I know about.) Who knows of course, but I can't help wondering whether it's either still on the WMF's list of things to do, or has dropped off that list without action perhaps even unintentionally. The example which I assume is the primary reason for this post, is different in that the editor is now using a large number of open proxies or VPNs or whatever making actually tracking them down or asking their ISP/s to get them to stop likely difficult. OTOH, their posts are also the sort of think I would hope few ISPs especially in the developed world, would simply brush aside. Nil Einne (talk) 04:46, 31 October 2018 (UTC)
Even assuming that this was feasible, what 'legal action' would be taken? I can't remember what US State Wikipedia is hosted in off the top of my head, but what grounds would WMF have for pursuing a lawsuit?
Also, in my opinion such a move would be a PR nightmare. Could you imagine news articles written about the Foundation taking action against people? It would shut off people's interest in joining and damage the general goodwill that the internet seems to have towards us. ProgrammingGeek talktome 00:06, 25 October 2018 (UTC)
Well, sort of. If you ran a business, and a man came in every day and pissed all over the floor of your business and walked out, you might seek some legal protections to stop him from doing so. I'm not sure this is any different. --Jayron32 03:24, 25 October 2018 (UTC)
I'm not sure how that's relevant. The question asks if the Foundation has ever sought real-world legal retribution against people who have attacked the project in a deliberate attempt to disrupt it. --Jayron32 12:01, 25 October 2018 (UTC)
To some extent, it illustrates how toothless our current protections are: if we can't stop you from disrupting the project we'll super-duper ask you to stop disrupting the project. Matt Deres (talk) 14:00, 25 October 2018 (UTC)
I am not able to discuss specific cases and what we've done in those situations but there have indeed been times where we have run out of available technical or social options and pursued legal options to try and curtail abuse or harassment. The legal system is never fast and usually asks a lot when bringing a case, so by its nature it’s not suitable for every situation either. Some of the times we have brought cases, we’ve had an outcome I would call successful, but not all. We do, however, continue to look for options where this option makes sense. Jalexander--WMF 02:07, 26 October 2018 (UTC)
Semi-automate DELSORT based on Project tags
A lot of effort goes in to correctly sorting AFD nominations, both for Category:AfD debates and for Wikipedia:WikiProject Deletion sorting. Much of the information needed to do this is already implied in the Projects listed on the article's talk page.
If Template:WPBannerMeta were expanded to accommodate a |DELETION_CAT= and a |DELSORT_LIST= or perhaps |DELSORT_LIST1=, |DELSORT_LIST2= & |DELSORT_LIST3= then projects could indicate the preferred sorting of articles under their remit in their project template, and a bot could implement that choice for AfDs on articles that have been "claimed" for that project.
It's not a complete solution, but I feel it could automate the mundane work in those cases where some interest has previously been indicated. In the long run it could encourage more project tagging rather than delsort tagging. This in turn would have beneficial long-lasting effects for those articles which are kept at AFD, in that the project tag is still useful, and the delsort's usefulness is spent.
Thoughts please, Cabayi (talk) 14:02, 31 October 2018 (UTC)
Cabayi, I would support this wholeheartedly. A bot could be designed to automatically add sorting to articles based on Wikiproject tags. I wonder if the AfD top template itself could be designed to automatically transclude this data dependent on the contents of the talk page? — Insertcleverphrasehere(or here) 14:11, 31 October 2018 (UTC)
I also would support this. The current delsort is very limited. Onel5969TT me 14:21, 31 October 2018 (UTC)
Nice idea but I think it is effectively already implemented via Wikipedia:Article alerts — Martin (MSGJ · talk) 14:54, 31 October 2018 (UTC)
Not quite. A lot of stuff comes up for deletion without being claimed by a project. Not everybody interested in a topic signs up for, or watchlists, the project. If it can all be done through Wikipedia:Article alerts, where's the value in Wikipedia:WikiProject Deletion sorting? Cabayi (talk) 15:16, 31 October 2018 (UTC)
Maybe User:AAlertBot could perform this task as well? Pinging @Headbomb: for comments — Martin (MSGJ · talk) 15:50, 31 October 2018 (UTC)
Using categories to automatically delsort could work better/at-least be more specific than WikiProject tags. Galobtter (pingó mió) 15:53, 1 November 2018 (UTC)
Accounts without email addresses
Background:
Many editors forget their passwords. If they have an email address associated with their account, they can request a password reset, but if they don't have an email address associated with their account they are out of luck. This is understandably upsetting and disappointing to such editors. Wikipedia's policy is that registered users are not required to maintain a working email address, but many editors are unaware that there is no provision to reset a password without such an address.
If you've worked at the helpdesk, you've seen occasional such requests. If you are an OTRS agent, you've seen hundreds of such requests over the last few years. It's never fun to explain to someone with an active account that they have to discard it and start over. I'd like to cut those down considerably, and I'd like to be in a position that if it happens ever again, I can politely point out that they affirmatively chose this option knowing the consequences.
Proposal:
I suspect that there will be resistance to requiring that registered editors have a working email address, so I don't propose to change that. However, I think it would be worth making it clearer to editors that lack of an associated email address means that in the case of a lost password, their only option is to create a new account.
At present, if you create an account through the ACC tool found at: Wikipedia:Request an account, you will have to initially supply a working email address. In contrast, if you create an account here: Special:CreateAccount, The request for an email address is marked optional. There is nothing on that page informing editors of the severe consequences of failing to provide an email address.
One option is to change that page to make it clear that while optional failure to include the address could lead to severe consequences if you forget your password. I know we want that page as simple as possible, but we could let people create an account without an address only if they affirmatively check a box indicating that they understand the consequences.
A second option is to make it mandatory on that page but let them know that they could remove the email address if they choose at a later time.
Removing the address can be done through preferences which does indicate some of the consequences but I'd like to see it more explicit. I wouldn't uglify that page with bold red text, But if an editor chooses the option to remove their email address they are to receive a pop up box with ugly bold red text informing them of the consequences of this action and insisting that they click a checkbox indicating that they understand.--S Philbrick(Talk) 18:18, 1 October 2018 (UTC)
I support the principle of having a huge "do you understand the risks?" warning box before allowing account creation without an email address. I totally oppose making it mandatory; the WMF has notoriously lax security, and as someone who themselves has had their email address leaked by them, I can entirely empathise with someone not wanting the WMF to get their paws on any personally identifying information, particularly if they're working on something politically or culturally sensitive. If we do go down the mandatory email route, at the very least we need to point out the risks of sharing information with the WMF, and ideally to talk signups through the mechanics of creating a burner account on a free email site. ‑ Iridescent 18:30, 1 October 2018 (UTC)
As an admin, when I'm about to move a page over another page that already exists, when I click the move button, the dialog reloads with an informational message informing me of what I'm about to do, and includes a new check box forcing me to acknowledge that I'm about to delete the other page. It's an extra-step nag screen that forces me to acknowledge my action, you know, in case I didn't understand what I was about to do and might be about to break something. I don't see any reason why we wouldn't do something similar for a user about to create an account with no email address, currently our only password recovery method, just an extra confirmation step that they really want to create an account they'll never be able to recover if they lose access. However, like Iridescent said, I strongly oppose forcing users to supply a working email. Ivanvector (Talk/Edits) 18:58, 1 October 2018 (UTC)
We can easily change the prompt at MediaWiki:Createacct-emailoptional, I'll have to check if we can add wikitext there - perhaps to a page about why it is so important? — xaosfluxTalk 19:50, 1 October 2018 (UTC)
Wikitext breaks there due to the special load on the right panel; but it can easily be changed from "optional" to "required for password recovery" or the like. — xaosfluxTalk 19:54, 1 October 2018 (UTC)
Support the required for password recovery language offered by xaosflux. Best, Barkeep49 (talk) 22:41, 1 October 2018 (UTC)
Support/Oppose per Iri. I didn't start off with a password. Thanks, L3X1◊distænt write◊ 21:32, 2 October 2018 (UTC)
Support this is basically what I suggested a while ago in phab:T159837. Though I move the 'consequence' into an additional confirmation step, instead of into the main interface. —TheDJ (talk • contribs) 07:53, 3 October 2018 (UTC)
Support (though this is the idea lab!) language as indicated by Xaosflux. I would be against any mandatory requirement. Nosebagbear (talk) 18:37, 8 October 2018 (UTC)
Support per Xaosflux. I've lost count of how many times I've used the "En-Account details" message in OTRS, it's a constant stream of lost accounts Ronhjones (Talk) 16:04, 3 November 2018 (UTC)
Why isn't mobile number and / or email required for new User Creation?
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
A lot of time is wasted in sockpuppet investigations and still they seem to have infested Wiki.My suggestion is to require email and / or mobile validation to create new accounts on Wiki. Existing users should also provide them to continue using their IDs. Email authentication is free of cost and easiest to set up, while mobile number verification may require sending an OTP to the number which can have a minuscule cost involved of sending an SMS. Email verification would be sufficient since to create new email IDs, the companies send OTPs to the mobile and user cannot register multiple email IDs linked to a single mobile number. Even small websites have these type of validations then why can't Wiki? Since sockpuppetry is becoming a nuisance on Wiki. Hopefully something gets done in this regard, if this is not the place for suggestion kindly let me know where to write it. Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 13:21, 8 October 2018 (UTC)
For the reasons I've already explained to you in detail last time you asked this, and as also given in detail literally immediately above this post. When you don't like the reply you've been given in one place, the solution is rarely to ask exactly the same question somewhere else. ‑ Iridescent 15:37, 8 October 2018 (UTC)
This is the first time I have brought this issue up myself. That may be someone else you are talking about. Anyways, so wwhat was your opinion back then? Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 16:53, 8 October 2018 (UTC)
O RLY? You are aware that this is a wiki and we can see the threeotheroccasions you've asked this, right? ‑ Iridescent 01:13, 9 October 2018 (UTC)
Seems like an SPA except it's an IP, also it was a diffrent person just above that proposed it but still. Remagoxer (talk) 11:23, 12 October 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The template is often distracting for readers (example: DE) and looks so unprofessional. We have more readers than editors and the reason this template still around in the article mainspace is because those who edit Wikipedia are ... editors. In general, I believe that a hatnote from the article mainspace should not link to any namespace except to the article mainspace. My proposed solution is either one of the following:
Design the template so it somehow would only appear in the article mainspace by logged-in users.
Remove the template in the article mainspace, any editors should be expected to write "WP:" on the search box if they want to go to the project mainspace.
It can be shown to only logged-in users and I think that would be better than deprecating it at all, even though, its usage in mainspace is somewhat discouraged even at this time. But of course, there are places where it's very important, but even then, largely to only logged-in users. –Ammarpad (talk) 09:19, 2 November 2018 (UTC)
Is the option one possible to do? Hddty. (talk) 10:32, 2 November 2018 (UTC)
Yes. <span class="user-show">This only appears to logged-in users</span> produces: This only appears to logged-in users. It can be combined with {{Main other}} to only hide the text in mainspace for unregistered users. PrimeHunter (talk) 10:44, 2 November 2018 (UTC)
Ok, can you edit the template? It also means that {{selfref}} should only be used in the article mainspace because it would be inconvenient for the user in the project namespace who doesn't logged in. Hddty. (talk) 14:48, 2 November 2018 (UTC)
I don't support it, I just said it's possible. PrimeHunter (talk) 11:34, 3 November 2018 (UTC)
The "On Wikipedia..." phrasing does seem a little aloof, but typical hatnote phrasing should be fine, e.g. "For Wikipedia's guideline on foo, see Wikipedia:Bar". I think this amount of self-referencing is acceptable. DaßWölf 22:44, 3 November 2018 (UTC)
Teahouse hosts
WRONG PLACE
There is an existing consensus on handling inactive Teahouse hosts formed at WT:TEAHOUSE. If you want to change that, it would behoove you to try to do so first there, prior to appealing to the wider community. John from Idegon (talk) 04:45, 9 May 2019 (UTC) (non-admin closure)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi everyone,
On the Teahouse hosts page, there are a lot of hosts. I noticed that some hosts have not edited Wikipedia in a while. Others currently edit Wikipedia, but are not active at the Teahouse. I am hereby proposing the procedural removal of hosts that have been active here on Wikipedia and/or the Teahouse because the people helping out here may be different 5 years from now or 10 years from now (if Wikipedia is still around then). Any thoughts? Interstellarity (talk) 23:11, 8 May 2019 (UTC)
Just a note, this was originally posted at the Teahouse. -A lad insane(Channel 2) 23:19, 8 May 2019 (UTC)
I am one of the most active Teahouse hosts. I support removing any editor from the host page who has posted a "retired" banner, or has been indefinitely blocked, or has not edited in six months. Sometimes people take extended Wikibreaks and later return to editing. Cullen328Let's discuss it 23:41, 8 May 2019 (UTC)
@Cullen328: A similar situation happens with administrators. If an admin has not edited for the past 12 months, their rights can be procedurally removed. Interstellarity (talk) 00:00, 9 May 2019 (UTC)
Does the Teahouse Host thing still mean what it used to? Back when in 2012 when this was an actively managed project by Sarah and Heather, there was some vetting of the Host application process; but the Teahouse seems to have changed its character over the past 7 years, and it doesn't seem to be as actively managed anymore. The efforts of Cullen328 and other active users there notwithstanding (and meaning no disrespect to Cullen328, who is consistently one of the most courteous hosts we have at Wikipedia, across the board, not just at the Teahouse) it doesn't seem like the "Host" job has much meaning anymore. The Teahouse has become the defacto "New User Help Desk", and there's little left of the original project that made it distinct. I was one of the early Hosts, and I have the T-Shirt to prove it (thanks to Sarah, who mailed me one to thank me for my early involvement in the project), but it doesn't seem to mean much more than "Here's a list of people who respond to questions at the Teahouse" anymore. --Jayron32 23:56, 8 May 2019 (UTC)
Jayron32, I never got a T-shirt, so that will give me something to kid Sarah about the next time I see her. How can one define "meaning" on a decentralized volunteer project like Wikipedia? Personally, I am very proud of the work that I have done quite consistently at the Teahouse for quite a few years now, although I guess my subjective assessment of my own work there has taken quite a hit as a result of your questioning of the "meaning" of that work. I am really disconcerted by your observation that "there's little left of the original project" because I feel quite the opposite. Why do you think that "active management" is required, and how does that fit into the Wikipedia ethos? Why don't you return to the Teahouse (where you and Sarah and Heather are always welcome)? Cullen328Let's discuss it 00:24, 9 May 2019 (UTC)
I'm surprised this is being discussed here, rather than at Wikipedia talk:Teahouse, but I, too, am somewhat disconcerted by the comment made above by Jayron32. Despite being a relative newcomer (invited there by Cullen328 some 18 months ago) I'm also very proud of what we offer those who come there, and would question which of these original Teahouse Goals are no longer being met by the Hosts who volunteer there today? Where else on Wikipedia, other than the Teahouse, would a new user seeking advice get a reply like this one?
That aside, the project does have an inordinately complicated sub-page structure , and our list of Hosts Profiles is open to anyone to add their name to, as it's not a permission anyone grants (though maybe we could do with a little more rigour in removing entries that clearly aren't appropriate, or where editors are no longer active. A useful task that a bot could maintain, perhaps? (pinging Jtmorgan) I'm probably guilty of leaving a few names in that shouldn't really be there - like the autistic new users I've just been guiding and trying to keep on track who's only ever made 20 mainspace edits in their 600+ edits here!) - but it's doing little harm, and not many people look at that list compared to our total daily pageviews. What's important is how active hosts respond and welcome new users - and I think we still do that very well, and in a friendly manner. More out of date are the c.30 or so names and images that cycle round on the main Teahouse Banner, some who haven't edited there for quite some years, and some no longer active on Wikipedia at all. A while back I did start working through those entries with a view to at some time gaining consensus at the Teahouse Talk page to update the banner display with just currently active hosts, and I reckon that's our first priority to give new users topical names and faces/images representing only the most currently active Teahouse hosts at any given time. Nick Moyes (talk) 02:37, 9 May 2019 (UTC)
I've never said the people who frequent the Teahouse didn't do a fantastic job. Indeed, I'm pretty sure I said the exact opposite of that. I just was wondering what the role of "host" means anymore. --Jayron32 02:50, 9 May 2019 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Moved from WP:Village pump (miscellaneous)
.png)
on it to emphasize that it is done by the WMF Office? SemiHypercube ✎ 23:22, 30 September 2018 (UTC)
.png)