Wikipedia:Village pump (idea lab)/Archive 39

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (idea lab) archive  

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.

---

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62

URFA addition to article milestones

Hi! I was recently made aware of WP:URFA by SandyGeorgia. I was not aware of this before and I noticed there are many articles there that have notes such as "satisfactory", etc. to indicate they still satisfy FA criteria. However, this is not shown in article talk pages in the milestones thing but could be useful information (e.g. seeing an article passed FAN in 2004 but its FA status was last discussed/checked positively in 2019), both to make the great work volunteer editors do in maintaining the curatorial standard in Wikipedia be more transparent to newcomers and lurkers, and also to encourage more participation in that process. Articles can change immensely in the years (sometimes decade+) since they were listed as FA, but that does not necessarily mean their quality has dropped in relation to the encyclopedia's other articles. I'm not saying there is a dire need for more reviews (nor saying there is not), but just a small idea. I thought of posting this in URFA's talk page but was also wondering about the perspective of less involved editors on this. My main concerns have to do with increasing the visibility of these reviews while not making them too bureaucratic to perform (e.g. many links, templates, etc. to perform), as well as the fact I myself am not experienced with this process so might be unaware of previous consensus in regards to something like this.Santacruz ⁂ Please ping me! 22:33, 27 November 2021 (UTC)

Hi, AC! So glad you have taken an interest. Actually, the current link is WP:URFA/2020 (URFA is the original, but old, effort).

Yes, we need more reviewers; WP:FAR was moribund for years, and now we have quite a backlog to get through. And we sure do need a way to draw more attention to the effort to review older FAs.

As far as Article milestones go (I was involved in helping develop that), we really shouldn't include the informal "satisfactory" marks from URFA as a milestone, because those are only intended to indicate FAs that are good enough to not need to be submitted to FAR, whereas those that are actually submitted to FAR, are recorded as an entry at article milestones. With so many needing review, we had to have a process that allowed us to focus on those that are truly outdated or neglected, because we can't actually review that many thousands! @Hog Farm, Buidhe, and Z1720: (the other main participants at URFA/2020) and @FAR coordinators: . Open to ideas, though Best, SandyGeorgia (Talk) 22:42, 27 November 2021 (UTC)

I missed some others who have worked at URFA/2020: @HJ Mitchell, David Fuchs, and Femkemilene: (probably missed more, but didn't mean to :) SandyGeorgia (Talk) 22:47, 27 November 2021 (UTC)

Not opposed to this idea. A concern I've had with URFA is that, at our current pace, it will take years to check every article. An article marked satisfactory today may deteriorate in five years, but will not be rechecked at URFA/2020 because it is already deemed "satisfactory". Having this added to article history might allow us to keep track of the satisfactory FAs and know to re-check them after a certain number of years. Something like the above idea might not be necessary if URFA/2020 were to complete at a quicker pace, which is why I hope more editors will get involved in this process. I welcome more brainstorming and ideas on this topic. Z1720 (talk) 22:51, 27 November 2021 (UTC)

(ec, essentially duplicating Z1720) I like the idea of including it in the article milestones, or noting somewhere that the article has been looked at and deemed satisfactory. A record might come in handy in another few years when we come to review our oldest FAs again. HJ Mitchell | Penny for your thoughts? 22:54, 27 November 2021 (UTC)

Z and HJ, possibly one way to add those marked Satisfactory by at least three reviewers to Template:Article history would be to name a new process to be added to the template (something akin to FAR-light), but then someone would have to program that in to the template, and we'd have to either add those deemed satisfactory manually, or get a bot to do it ... and we'd need a page to record them (like a FAC or FAR page, unless we just used a diff to the URFA page) ... so quite some work is involved in adding a whole new thing to article milestones, just food for thought, because some of those template editors are always coming up with good stuff. I'm not sure we're ready for it yet ... we need more FA-experienced reviewers first! SandyGeorgia (Talk) 22:56, 27 November 2021 (UTC)

I would rather add URFA to the template in our early process. This will advertise the project on talk pages, causing editors to discover or become reminded about the process. Also, adding it early will mean there are less articles to update when this is first implemented. And I fully agree with Sandy that URFA/2020 needs more reviewers. Z1720 (talk) 23:21, 27 November 2021 (UTC)

Maybe someone with the technical expertise will come along and suggest how we might do that via only using diffs, rather than having to institute new archive pages ... or something ... creative ... SandyGeorgia (Talk) 23:29, 27 November 2021 (UTC)

HJ Mitchell we do have a record (see here) but as AC has pointed out, it’s not very visible, in fact, is quite transparent to most people, who would never know where to look for it. But when/if we have to do this again, we do know where to get the data. SandyGeorgia (Talk) 23:44, 27 November 2021 (UTC)

The milestones idea was the first thing to come to mind, and I do see your point above not including informal marks as a milestone. I don't have enough experience here I think to have any great ideas to propose, but perhaps I can be of help as a representative for the new editor/lurker perspective :P. Backlogs are truly the wildest horses to tame. Santacruz ⁂ Please ping me! 22:53, 27 November 2021 (UTC)

Yep, but not my first rodeo :) The original WP:URFA looked insurmountable when we first tackled it, but that we did. Keep the ideas coming; I see that both Z and HJ like your idea, so maybe someone can put all the pieces in place to make it work, as the list is becoming unwieldy. SandyGeorgia (Talk) 22:59, 27 November 2021 (UTC)

I don't necessarily have too many ideas here for the actual article history thing, but I wonder what y'all's stance on finding some way to implement quid-pro-quo into the GA/FA process would be. I have found being made to do a QPQ when nominating for DYK a great way to make sure too many of those aren't ignored, so maybe some way of "include qpq link of urfa review when nominating for FA" might go some way to slow the backlog creep Z1720 accurately identified above. Santacruz ⁂ Please ping me! 23:04, 27 November 2021 (UTC)

That has been talked about quite a few times at WT:FAC, and it opens the door to some problems so that it has been repeatedly rejected. It would be better to ask that at WT:FAC, so we can keep your ideas going here on how to advance the WP:URFA/2020 effort. SandyGeorgia (Talk) 23:07, 27 November 2021 (UTC)

I'm a little bit hesitant to put an informal assessment such as URFA/2020 into article history, but I think this is a good idea in background and there's going to be a way to do this right. I'm pretty sure the GA sweeps from years ago was in article history, but I'm not sure if that's comparable, because GA is a one-reviewer process, which makes it quite different from FA. One way to solve the linking problem would be to make it a standard practice to create a URFA section on the talk page and note that you're marking it as satisfactory there, which could then be linked to in the article history section. The one issue would be if old items are auto-archived, but I reckon this could be worked around by fixing the thread so that it does not get archived. Hog Farm _Talk 00:55, 28 November 2021 (UTC)

As long as the URFA log line is clear enough I don’t think there’s much difference between URFA and peer review, which does get an article history notice. People can either ignore it or hit the link and get an explanation of the process like everything else in article history. Der Wohltemperierte Fuchs ^talk 14:20, 28 November 2021 (UTC)

That is now three in favor (and some against). If we go this direction, I suspect we need to go to subpages for the process, which I fear will deter involvement, and we need involvement! On the other hand, perhaps it will encourage involvement from those who want the line in article milestones … SandyGeorgia (Talk) 15:06, 28 November 2021 (UTC)

Could you explain a bit more the issue with subpages? I agree they're not an ideal solution but want to understand your personal perspective here a bit better, SandyGeorgia. Santacruz ⁂ Please ping me! 15:10, 28 November 2021 (UTC)

Most events that are recorded in article milestones have an event link entry to a subpage where the evaluation occurred (DYK, Peer review, GA, FA process, etc). There are a few that don’t (ITN, OTD, main page date as TFA— all involving only a date). Those are typically recording only a date, rather than an assessment. (Study Template:Article history). I’m not sure a one-line-link assessment like ITN or OTD or maindate will work for this case, as we expect at least three reviewers to assess an article as satisfactory before marking it at WP:URFA/2020, so that seems to be calling for a full assessment page. A whole ‘nother process, which would be akin to WP:FAR lite. As an example, look at Talk:Malcolm X in edit mode, where you will see the difference between events and dates, and then look at it not in editing mode. My concern is that, to go this way, we would have to essentially repeat a FAR-like process so that we could record an event page. Easier said than done, and will there be unintended consequences? SandyGeorgia (Talk) 15:19, 28 November 2021 (UTC)

So, to summarize my points above, the short question for those who like this idea is, would it suffice to add only a one-line link (like this with a date) to articlehistory, or would we be forced to a full subpage event? @Z1720, HJ Mitchell, and David Fuchs: If we are forced to a full subpage new event process, I would be seriously opposed, as we would essentially be creating a FAR-lite new process. If we can add a one-line event, the template coding to that might be simple, but not my skillset, could be wrong. Also ping Hog Farm to revisit this idea based on this new feedback. SandyGeorgia (Talk) 15:29, 28 November 2021 (UTC)

If we could add a one-link item to articlelhistory, it would essentially be the same way OTD is done— where we add a date and a diff, the diff in this case being the third editor to mark satisfactory and move the article to the Kept or FAR not needed section at WP:URFA/2020. SandyGeorgia (Talk) 15:31, 28 November 2021 (UTC)

DYKs also have subpages, albeit for their nominations, and are edited by at least 3 people (nom, reviewer, and promoter). I haven't found the subpage issue to be as impactful there. One possibility that could maybe work here is when an article promotes to FA a bot automatically creates a subpage (either of the article, URFA or elsewhere). If there is a minimum time for when it will be reviewed by URFA, that could be added to article milestones with that link (e.g. 18 February, 2023 - Next scheduled URFA (the accurate wording here is hard for me to find)). This could greatly increase the visibility of URFA throughout the project, as editors wouldn't learn about it only through articles who have gone through urfa (which seems like not enough). The bot-generated subpage could also include pre-made text/templates to make editing there less cumbersome, which could also help make it easier for new editors to be involved. As a new editor, noticeboards and pages like URFA that have many sections, tables, and stats can be quite scary, so maybe subpages could help from that point of view. DYK subpages felt like a very accessible way to get involved in that. Santacruz ⁂ Please ping me! 15:38, 28 November 2021 (UTC)

I'm not necessarily for or against the idea but I think the way to do it without involving a subpage is to use the specific revision current at the time the third person "signs off" on the URFA listing. It shouldn't need a devoted subpage but a link to the specific revision that was ruled satisfactory is useful, especially as it means if the article does deteriorate in future there's a "last good version" that can be referred to. ᵹʀᴀᴘᴘʟᴇ ꭗ 15:42, 28 November 2021 (UTC)

Yes, that agrees with what I see as the easiest way to do it, should we decide to do it. I will later ping some others in, but want to first see if this idea truly has support, and then would also want an RFC (since I don’t like adding things to milestones without broad consensus). SandyGeorgia (Talk) 15:45, 28 November 2021 (UTC)

The FA process already has automatically generated subpages (for FAC, FAR), and those are maintained in articlehistory by a bot, as are DYK entries. (TFA is a manual addition by TFA Coords). I’m not entirely following what you are suggesting. If we hear back from HJ, Fuchs and Z, I will try to ping in others familiar with how to make this happen … later today. SandyGeorgia (Talk) 15:43, 28 November 2021 (UTC)

Agree with Grapple X. I don't see a need for individual subpages. That would add a whole new layer of bureaucracy to the process. A one-line link is fine as a record that the article was looked at and deemed satisfactory. As was mentioned above, the GA sweeps were recorded in article history and some of those reviews were only very slightly more verbose than "satisfactory". HJ Mitchell | Penny for your thoughts? 15:44, 28 November 2021 (UTC)

Great, so far we agree on this part then. SandyGeorgia (Talk) 15:45, 28 November 2021 (UTC)

I would not like to use a new subpage. I think linking the revision version that was deemed "Satisfactory" by the third editor will suffice, as noted by Grapple above. Z1720 (talk) 16:07, 28 November 2021 (UTC)

I also don't think a new subpage would do anything good here, and would just bog down the process. I know article history can handle an item with no link - that was done for some of the old GA sweeps ones, and I've seen it for GA reviews from before they created dedicated GA subpages. Would be certainly doable to just have a link in there. Hog Farm _Talk 16:20, 28 November 2021 (UTC)

If we were to ask

... template and bot editors how to make this happen, I suggest it would look something like this. (I don't want to actually ask them until/unless we are in agreement, but it does appear that all agree that a new process/subpage should not be created, and we should just link to the third "Satisfactory" diff.)

Sample diff: This is what an edit that marks the third "Satisfactory" at WP:URFA/2020 looks like, as it also moves that entry from the list of articles that need review to the list that has been marked as "FAR not needed". (Those that are "Kept at FAR" are already automatically processed by FACbot.) That would be the diff upon which the Template:Article history entry would be based.

1. Who is programming/maintaining Template:Article history these days? (Gimmetrow, who designed and used to run a bot to add every content review process to the milestones is basically gone.) That is, who can code this new entry in to the template?
2. If the editor who made the final "Satisfactory" move, then placed that diff (sample) at a subpage (WP:URFA/2020/Bot archive or something similar), could that be the trigger to call a bot to process the item in to article history, just as the move to FAC and FAR archives now triggers FACbot to do the rest of the bookkeeping?
3. Can a bot pull the article name from a diff like that ?
4. Just as FACbot then pulls a diff to the corresponding version of the article at the time it was marked satisfactory, could that be done here as well ?
5. Can FACbot do this ? Or is this type of task more suited to the bot that processes DYK, or the bot that processes ITN?
6. Then, could FACbot (or another) process that archived diff in to article history with an event that looks like this (where x represents the next open event number and the sample diff listed is used)?
7. And then, could that result in a line in articlemilestones that reads: Date (linking to article oldid) ... Unreviewed featured articles (linking to sample diff) ... Marked satisfactory ?

| actionx       = URFA
| actionxdate   = date from diff as in sample above
| actionxlink   = diff as in sample above
| actionxresult = Satisfactory (this would not technically be needed, as they would all be "satisfactory" by definition of how we are doing this, but leaving it off may confuse article editors)
| actionxoldid  = oldid that the bot pulls from the article that corresponds with the date of the sample diff

| currentstatus = (this would not change ... the article remains an FA)
}}

If I have this right, I will next ping in those who can opine. I would also recommend a formal RFC before we do this, if the bot and template people sign on. SandyGeorgia (Talk) 16:59, 28 November 2021 (UTC)

This makes sense (to me anyway). However, to play devil's advocate—anyone monitoring URFA is likely already an experienced editor familiar with article history templates; could we theoretically begin doing this manually at first to see how it pans out before engaging a bot to automate it once we see how a few instances of it will pan out? There are still some article history entries that are entirely handled manually (FTC/FTRC for example) so this wouldn't be unheard of and I for one don't mind doing the bookkeeping of updating these things if someone wants to pawn it off, but it might identify the best method to automate if we do it in practice for a bit first. ᵹʀᴀᴘᴘʟᴇ ꭗ 17:00, 28 November 2021 (UTC)

ugh ... I do TONS of manual maintenance of article milestones, and It's a Bitch. The worst part of doing it manually is that DrPda's (or Gimme's, can't remember) script to return an oldid based on a date is no longer working, so finding the oldid is a bunch of work, that is (somehow) already programmed in to FACbot. One of the main things you find is the number of times unfamiliar editors mess them up! Also, most of the code for this should be already present in the (at least three) bots that are already doing this.

But I do agree with you in principle ... that we would a) first ask it to be coded in to the template, b) second add all (or most) of those already done manually to see how it goes (I could do that), and only after that, then c) ask for a bot to continue. Great thoughts ! SandyGeorgia (Talk) 17:08, 28 November 2021 (UTC)

If this were something I anticipated a lot more newer or intermediately-experienced editors doing then sure, the ability to mess up or miss a step would certainly be magnified but I think it's a safe bet we're likely to only see editors much more familiar with intricate operations working on this. If we want to identify some initial articles to test it out on after any RFC then I'd be happy to take a list of a few dozen and grunt through it just to see what works. ᵹʀᴀᴘᴘʟᴇ ꭗ 17:15, 28 November 2021 (UTC)

OK, when/if we get to that stage, you and I can divide the list to be initially processed. Thanks! SandyGeorgia (Talk) 17:20, 28 November 2021 (UTC)

PS, we already have a perfect division of labor at WP:URFA/2020, as we have two different sets of "FAR not needed" by date. You could take one, and I could take the other ... when/if the time comes, we're on! SandyGeorgia (Talk) 17:38, 28 November 2021 (UTC)

Hawkeye's MilHist Bot and FAC Bot already add to the Article History template, so if he has time perhaps a bot task would be something Hawkeye7 could help with. HJ Mitchell | Penny for your thoughts? 17:42, 28 November 2021 (UTC)

I was hoping to wait until I was sure we were all on the same page, and only then ping in all those technical people at once. So, since you've already pinged Hawkeye, I will go ahead and ping the rest of them, via a post at the talk page of the articlehistory template. SandyGeorgia (Talk) 18:07, 28 November 2021 (UTC)

Queried Template talk:Article history (and I also placed crossposts at WT:FAC and WT:FAR). SandyGeorgia (Talk) 18:20, 28 November 2021 (UTC)

SandyGeorgia seeing how it's been a while since you posted the notice and there has been no response, I wonder if there are other talk pages that get attention from experienced template/bot editors that could give some advice/opinions on the discussion above while we wait for editors at the pages you notified to respond. Santacruz ⁂ Please ping me! 19:23, 8 December 2021 (UTC)

Out of my league; I really don’t know. I suspect we had a bit of cart before the horse here, and if the idea gathers enough steam, it is something FACbot can most easily do. My hunch is that the template people were pinged too early, and are waiting to see if the idea really has traction. SandyGeorgia (Talk) 19:52, 8 December 2021 (UTC)

• This seems like a reasonable idea to me --Guerillero ^{Parlez Moi} 23:51, 8 December 2021 (UTC)

Wiki Paper (electronic publishing)

Electronic publishing

It would be nice if Wikipedia made it so people can write an article or paper using the Wiki Markup Language and publish it to the web so people can link to it. I think this would drive more traffic to Wikipedia also. I used my sandbox to write an article for my website the other day and it works good Sandbox article. If people had 5 or 10 articles they could make in a document text editor or Source-code editor that would be dope. Maybe have a paid version for people or organizations to have wikipedia host those articles. It would be a better version of Google Docs or other online publishing software like Medium (website), No one does a very good job of Electronic publishing yet.

--Wikideas1 (talk) 04:51, 8 December 2021 (UTC)

The underlying MediaWiki software is freely available for anyone to install, and some web hosting providers support it from their app-installation control panels. isaacl (talk) 18:40, 8 December 2021 (UTC)

Very complicated to even download. I couldn't figure it out.

--Wikideas1 (talk) 09:53, 10 December 2021 (UTC)

@Wikideas1 Comparison of wiki hosting services --Ahecht (TALK
PAGE) 20:41, 10 December 2021 (UTC)

Looks like Larry Sanger is creating the Encyclosphere Encyclosphere.org to try and solve this problem. --Wikideas1 (talk) 10:01, 11 December 2021 (UTC)

Adding "AfD closer" status

So, AfD sometimes works non-excellently, help from non-admins is needed, non-admins can't really process AfDs well since they can't make "delete" closes because they can't delete articles, so let's address that. We're not ever going to (and shouldn't) give non-admins the bit to delete articles, so forget that, on to Plan B.

More exposition on this (optional)

So, my basic starting point is the admin corps is understaffed (IMO it's worse than people think, because while few admin tasks aren't taken care of, some seem rushed. And, IMO AfD doesn't work as well as it might. So, one way of dealing with that has been to offload tasks onto editors -- flag to allow non-admins to edit templates etc etc etc.

So, we have Wikipedia:Non-admin closure. And non-admins close various things, and WP:NACAFD addresses closes of AfDs specifically. Any editor can close an AfD but really only speedy-keeps, or expired ones, and those have to be closed as "keep".

That's not very useful. Only being able to do "keep" closes is inherently unbalancing, like being a judge who can only acquit. And also, I'm not going to spend an hour or hours looking at a discussion (old ones are often the thorniest), only to determine that "delete" is in order so I have to throw away my work. Who would.

And I mean, I personally am not convinced that admins overall are really any better at closing AfD than any other good editor. Admins are good at many other things, they are carefully vetted because they do important and difficult things and handle sensitive info and situations -- edit wars and ANI complaints and vandals and reviewing deleted articles etc etc etc. and I'm confident they're good at it. But they're not really extensively vetted, usually, on their qualifications for AfD closes specifically. I'm not saying admins are bad at that but I'm not convinced they're any better than other good editors.

Another point is that AfD closer would be a helpful step for people who do want to be admins. You know, like "100 AfD closes with no complaints" would be another data point for someone wanting to undergo RfA, in addition to the useful experience.

This suggestion is that we make a new page, "Wikipedia:Requests for permissions/AfD closer", which looks and works a lot like say Wikipedia:Requests for permissions/Template editor. An editors applies there and, just as for template editors etc., an admin grants or denies the status after consideration. (Presumably the editor would have previously participated thoughtfully in AfD discussions, gaining experience and also WP:AfD stats to aid consideration).

If "AfD closer" status is granted, there's no bit added, the editor just gets put in Category:AfD closers. A new criterion is added to Wikipedia:Criteria for speedy deletion and in Twinkle, something like "A12, deletion requested by a certified AfD closer following an AfD 'delete" close".

If an AfD closer closes an AfD as "keep", the procedure is the same as before. But if she closes it as "delete", she slaps an A12 CSD on it. The next admin clearing out CSD deletes it. But as you see there's an an admin backstopping the process and catching anything that looks wrong.

Criticism and advice requested. Herostratus (talk) 17:27, 27 November 2021 (UTC)

I realize this is contradicted a bit by the existence of non-admin closures but closing contentious AfD discussions has always seemed to me like an area requiring enough wisdom and discretion that there is value in having community input into who is given that responsibility. It seems different than things like page mover or template editor permissions where the main issue is that the user can be trusted to not break things too badly with the tools. CapitalSasha ~ talk 18:38, 27 November 2021 (UTC)

OK, but as I said a person who can only close "keep" is like a judge who can only acquit -- not helpful. Yes and let's say all admins are good AfD closers, there are also many non-admins who would also be good closers, and there aren't enough admins. We need some sort of solution.

And remember, an admin cannot be removed except in rare exceptional cases, so if they're a mediocre AfD closer and can't be talked out of doing it they could still be doing it in 2040. An "AfD closer" can be instantly removed from the category by a single admin (and allowed to re-apply). Herostratus (talk) 00:58, 28 November 2021 (UTC)

• I would oppose. It would be a hassle for admins to regulate and monitor these closers, AfD is incredibly subjective and conflict-ridden. The thing about admins, they have a lot more at stake then someone with a special-purpose bit, admins are more judicious in deciding a close. A special power is a hammer looking for nails, once you have it you will want to exercise it. Such a power is a mandate of one's supposed superior abilities in deciding to delete. It would also form a club of sorts, where fellow bit holders will find it useful to support one another, making it difficult to oppose a group of deletion specialists and their supporters. -- GreenC 18:43, 27 November 2021 (UTC)

OK. I don't agree with some of your points, but I've been wrong before. But do you agree that AfD closes sometimes don't get the involved consideration they require, and if so what should we do instead? Herostratus (talk) 00:58, 28 November 2021 (UTC)

• The thing about admins, they have a lot more at stake then someone with a special-purpose bit - is this actually true? It is very rare for an admin to be de-adminned, and I can't recall it happening over bad AfD closures in recent memory. --Aquillion (talk) 22:31, 30 November 2021 (UTC)

• I'm intrigued. I have no intention of ever becoming an admin, but I could imagine requesting this permission. I find it interesting to keep an eye on the book-related AfDs and I think I have gotten to know the process well. I'd close uncontroversial deletes periodically. Some threshold requirements -- e.g., account at least a year old, !votes in at least X AfDs, whatever seems likely to increase AfD competency -- could go a long way in screening for good candidates. But none of those metrics will do a good job of screening for the interpersonal skill and judgment, not just "experience", which makes for a good AfD close. Having admins do the actual delete provides some "safety net" but a bad AfD closer could sow a lot of discord. I think it's worth considering what processes might give this permission to the most suitable candidates. ~ L 🌸 (talk) 06:05, 30 November 2021 (UTC)

Yes of course, votes in X number of AfDs would be necessary. I don't know if X should be a hard number. Ten is not enough, 100 is, in between it depends; obviously nobody is going to consider someone with ten, we hardly need to say that. And OK, Interpersonal skill is fine, but I don't have it and I've closed hundreds of AfDs with no complaint. Patience, analytic skill, very good knowledge of the relevant rules and usual practices, and diligence are more important IMO.

Since this the idea lab, I'll keep idea'ing. I like simple, cos that give best chance for adoption, but you could add all kinds of stuff:

1. Rrequire the signoff of X admins... 3 or 5 or whatever, instead of just 1.
2. Or, instead of just an admin(s) given the status (as in Wikipedia:Requests for permissions/Template editor etc, You could have a full-blown "Wikipedia:Requests for closership" -- like WP:RFA but very much simpler and shorter (see hatted material).
3. Or, other. Let's hear it.

Some important points which I'd recommend reading, but skip if you wish

The editor is not asking for the ability to block persons, see deleted material, edit protected pages, adjudicate WP:ANI cases, and so on. Just for the one ability (which isn't even a bit, and is backstopped). All questions could revolve just around that. Extensive knowledge of rules outside those useful at AfD, being good at vandalism patrol, at handling edit wars, etc etc aren't in play. (Demonstration of good character and intelligence would be of course.)

And, to that end, we have Wikipedia:AfD stats. here's mine. Easy to read charts showing the editor's level of engagement. How often the editor did or didn't vote in accordance with the eventual outcome. How "deletiony" or "keepy" the person is, compared to the general population. Links right there to check her contributions, a random sample or all. You can also see just her AfD nominations, read them, and see what percentage were agreed with. Your vote practically writes itself. (Of course this info is also available to admins if we go the "Requests for permission/xxx" route.)

Also, good grief, I just saw Wikipedia:Successful requests for adminship. We have had seven new admins this year. This isn't sustainable and sooner rather than later we are likely to end up with some AfDs being closed too hastily. If that hasn't happened already. And remember, a big effect isn't just to help AfD but to free admins to do other tasks better.

Come, on, people, we have got a non-excellent situation here. It is not going to get better. We need a fix. IMO we don't need to hear "Well, but then there's this downside" (EV-ER-Y thing has downsides) or "Well, but maybe this bad thing might happen" (In which case, we just stop doing it or fix it) or "Well but maybe a troll or deep-cover vandal might get in" (trolls and vandals get in everywhere, a few; we unddo their work and deal with them) or "But what if the AfD closer turns out suck at it after all" (a single admin can kick him out of the category (and he can re-apply), and so on. Don't take counsel of your fears, don't fear that our experienced editors who want to help out here are dolts. If they are, let's find out. Individual dolts are removed -- no trial (unless people want that). If the new AfD closers turn out to be dolts generally, the admin corps will stop appointing (or the community electing) new AfD closers, and it just dies and is eventually deleted. There's only one way to find out. We need to keep adjusting to circumstances -- 7 new admins this year, under 20 in a typical year, and that's not accounting for retirements -- or face a decline.

Seven new admins this year. We have to take some burden off the admin corps. If you've got a better idea, let's hear it. Don't just be a naysayer, please. Herostratus (talk) 19:04, 30 November 2021 (UTC)

Herostratus, I've always thought of you as a good editor, but I guess I'd like a persuasive statement from you as to exactly why you think this new permission is needed. Sometimes, AfDs are not closed after exactly seven days, but usually there's a discernible reason (low participation, the possibility of further comments' leading to a clearer result, particularly problematic discussions that would probably be beyond the competence of your proposed AfD closers, etc.), but I've not noticed that there's often a severe backlog of AfDs that need closing. What prompted you to propose this? Deor (talk) 21:53, 30 November 2021 (UTC)

Hi. Well, I explained in detail above, such detail that that I hatted a lot of it to avoid TL;DR syndrome. It's been in the back of my mind for some months. So anyway, I'm not so much concerned about lack of backlog, as quality. Don't get me wrong; quality is good! Most closes are fairly easy anyway. Most are deletes, and properly so, or they wouldn't be at AfD. Occasionally we lose an OK article. I personally hate to see that, but it's not a crisis. Occasionally I see (IMO) a close, keep or delete, that seems rushed. It's not a crisis. I guess... maybe 19 out 20 closes are OK. That's good. It's not humanly possible to get that last 5%, probably. I don't know... A part of what I'm trying to do here is think of ways to allow the admin corps to have more time and energy to focus on the many things that only they can do.

As to "beyond the competence", mnmh. I don't see a clear admin/editor line such that the editor corps is mostly blockheads, and I mean after all you're talking about people who have participated significantly in AfD, competently, have not shown poor character, and want to be closers, and meet any other requirements the people granting the status want to personally impose, such as length of service or whatever. But that's my opinion. Herostratus (talk) 00:46, 1 December 2021 (UTC)

• TBH while there are areas that lack for admins, I'm not sure AfD tops the list. The really big problem is WP:AE, which is largely handled by just a few admins - until recently El_C was doing a huge chunk of it, and right now it's just a handful of people. Fortunately we've generally had evenhanded admins handling it, but no matter how good they are it's still not ideal to have so few people making those decisions, not in the least because of the load it puts on them. And AE isn't really something we can farm out to non-admins. --Aquillion (talk) 22:31, 30 November 2021 (UTC)

Well... I mean if El_C needs help, what about the admins who are closing AfDs right now? I don't know how fungible admin time is, but maybe some. And I mean you cannot have non-admins doing WP:AE, so where can we find a way to support the admin corps?

Let's see... at AfD, 24 November, 95 articles. 25 November, 68. 26 November, 87. That's a lot. Lot of those are quick slam dunks, a fair amount aren't. Some of those, you need to check that BEFORE was done well enough, weigh other matters. It can take time. How many man hours to close 95 articles? Say 15 minutes average, that's 24 person-hours right there. 15-20 admin-hours every single day that could be spent on WP:AE or elsewhere. I don't know if we average 15 minutes per close, but if we don't that may just mean we can't, not that we shouldn't. Herostratus (talk) 00:46, 1 December 2021 (UTC)

I don't know that they would. Closing AFDs (even the controversial ones!) is usually a lot easier than handling AE. And another concern I have is that if we start slicing off the "easier" parts of adminship and handing them out as individual roles, we're going to both see fewer people applying as admins, and even higher standards at RFA (because people will invariably say "oh, if all you're going to do with the tools is close AFDs, why not just become a closer?" or "I'd like to see you get closer permission and close a bunch of AFDs first, since that's a big part of what admins do.") --Aquillion (talk) 19:20, 1 December 2021 (UTC)

• Meh, if we want to empower some group to delete pages, we can give them access to delete pages. It doesn't require the ability to also undelete or viewdelete - if they screw up, they can just ask for help at AN. — xaosflux ^Talk 23:39, 30 November 2021 (UTC)

  • That's a reasonable and logical point, but unfortunately it hasn't been the consensus whenever unbundling of the delete function has been brought up. --Ahecht (TALK
    PAGE) 21:09, 2 December 2021 (UTC)

• I'm in the "AFD is basically never backlogged, if they're so great at closing discussions they can run an RFA" crowd. As a more productive suggestion -- it shouldn't be a category easily added to user pages, it should be a full-protected project-space page like WP:AFC uses. User:力 (powera, π, ν) 03:15, 1 December 2021 (UTC)
• I don't get where this is coming from. AfD is not significantly backlogged, I haven't heard any of the other admins who close them asking for help, and I haven't seen any signs of declining quality of closes (e.g. an uptick in DRVs). If you want to be an "AfD closer", you can ask at WP:RFA. And I guarantee you will be 'vetted' on your knowledge of the deletion policy and conduct in deletion discussions. – Joe (talk) 08:29, 1 December 2021 (UTC)
• The main issue with AfD is lack of participants, rather than lack of closers. Large backlogs of discussions needing closure aren't exactly common, so adding more AfD closers won't necessarily improve things. Hut 8.5 08:48, 1 December 2021 (UTC)

That's an excellent point. After all, other considerations aside, lack or participants offering data and cogent arguments leaves more burden on the closer to do research rather than just adjudicating what's presented. I'll open a section below to address this. Herostratus (talk) 21:04, 4 December 2021 (UTC)

• What problem is this solving? We haven't had a spate of inaccurate or ill-founded non-admin closures lately. Typically those few NACs that are challenged end up being upheld. --WaltCip-(talk) 13:04, 1 December 2021 (UTC)
• As someone who works AfD when I have time and when there is a need (i.e. a large number of open AfDs and/or AfDs which are eligible to be closed but have not been for more than a day or so) I have not recently seen a need beyond a few short periods. On the whole, and in comparison to other processes, such as AE, I think AfD is appropriately staffed by admin and already overstaffed by non-admin. Best, Barkeep49 (talk) 18:05, 2 December 2021 (UTC)
• I rather like the idea but have trouble with the logic presenting it. It seems to me the closure part of deletion discussions, by admins, works remarkably well and doesn't really need tinkering from a quality point of view. That being said, unbundling the admin toolkit is a Good Thing, and I could see a plausible argument that weighing consensus needs a different skillset than using the block button well. Finally, I could see that it would be more efficient to allow wholly noncontroversial Delete NAC just as we now allow Keep ones; which could presumably be implemented by a nonadmin Delete closure slapping a (new) CSD tag on that an admin would act on, implicitly endorsing the NAC close but having to do less work. However, controversial closes would continue to be left to Admins. So, the idea maybe has legs, just I feel it's currently being approached from the least-strong angle. Martinp (talk) 20:19, 2 December 2021 (UTC)
• I'm of the mindset this could be accomplished much more effectively by adjusting the WP:NACD policy and the WP:CSD#G6 to include a non controversial/contentious AFD NAC close. At this point I don't think we are in need of any different approach here for AFD to be more effectively handled. This is defiantly a tool looking for a purpose at this point. McMatter ^(talk)/_(contrib) 23:19, 2 December 2021 (UTC)

• OK OK I get that editors think AfD closing is basically OK as it is and no change is needed, and fine. It's the idea lab here and no way to find out these things without running it up the flagpole and see who salutes, and thank you all for your time.

(I personally continue to question whether the closing process is entirely excellent, as for instance right now I'm kind of rolling my eyes over a four-word close on a contended (not slam dunk) AfD, and I can't figure why we're (even if only occasionally) seeing that. It's not time constraint, it's not ability constraint, so....?? Color me puzzled, but that's just me I guess.)Herostratus (talk) 21:04, 4 December 2021 (UTC)

NB, autopatrolled has just been unbundled from admin status. This would seem to contradict the assertions above that admins, having been carefully and closely vetted, are necessarily always better at all aspects of editing than other editors. I suppose this could also include AfD closes; we're assured here that it doesn't, but sometimes people are wrong. Herostratus (talk) 20:49, 11 December 2021 (UTC)

@Herostratus: According to Special:ListGroupRights#sysop, autopatrol is still part of the admin bundle. But yes, it will be removed during week commencing Monday 13 December, see WP:AN#Administrators will no longer be autopatrolled. --Redrose64 🌹 (talk) 22:18, 11 December 2021 (UTC)

OK. Looking at the RfC (Wikipedia:Requests for adminship/2021 review/Proposals#Passed: 7D Remove autopatrolled from default toolkit a main reason for that unbundling was to remove the requirement to be a good article writer from admin requirements, to make RfA a little bit easier to pass. So my point is pretty weak, there. Herostratus (talk) 00:14, 12 December 2021 (UTC)

Participants

It's a point well taken that participation is a sticking point. It's often fine but sometimes sparser that you'd like to ssee. I don't know how to address that. But since it's the idea lab, I'll throw these against the wall.

1) "Did you know" has a mechanism to ensure that each entry gets someone to look at it, similarly we could have "If you want to nominate an article, you have to meaningfully participate on one (or X number of) AfD first". There's an obvious downside tho: articles that should be nominated and normally would be, wouldn't be. Maybe there's a way to adjust for that, dunno.

2) You could have a robo-invite of random editors to random AfD as there is now for RfC. This is opt-in so not that likely to bring in many new participants, and there's the chance of getting lower-quality input (altho input from editors who are not familiar with subject is actually helpful often). And I personally do got to RfC where I wouldn't without the invite.

3) Other? Herostratus (talk) 21:04, 4 December 2021 (UTC)

Project banners should be mostly determined by categories, rather than applied to pages individually

I'm guessing this has been considered before at some point, but it's quite inefficient that we try to remember to tag each biography talk page with {{WikiProject Biography}} rather than just automatically having every article in a person category (or defined as a person on Wikidata) fall into that project's scope automatically. Ditto with most other project banners—rather than having to remember to tag every page for Iranian topics with {{WikiProject Iran}}, just have the project cover everything within Category:Iran. This would require us to solve leaky categories, but we need to do that anyways (and if we can't, maybe we should use Wikidata instead). {{u|Sdkb}} ^talk 04:36, 5 December 2021 (UTC)

Would this be something a bot is capable of doing? We could manually approve a few core categories for each WikiProject and then have a bot assign the WikiProject tags for those. I don’t think that this is something that should go into every category , but something like this could work in a limited scope. — Mhawk10 (talk) 04:42, 5 December 2021 (UTC)

I'm thinking about this mostly in the less practical, more abstract sense of how we might totally overhaul our category system. But yes, in the practical realm, there's a lot of work to be done in this area. Anomie's WP:WikiProjectTagger could be put to much wider use than it has been so far. {{u|Sdkb}} ^talk 06:51, 5 December 2021 (UTC)

Before any large scale overhaul happens, we should be clear on what project tagging is supposed to be good for. The only thing I really use is that they feed into article alerts so I get informed about what is going on at some projects I watch. That wikiprojects operate with a "tag" system instead of a "tree" system based on categories might actually be beneficial. —Kusma (talk) 11:42, 5 December 2021 (UTC)

As many projects currently are more or less inactive, I don't think doing this would be productive for every possible project. Perhaps a trial of the idea with more active projects willing to opt into it would clarify the benefits. - Donald Albury 17:44, 5 December 2021 (UTC)

@Donald Albury I think WikiProject Disability might be a good candidate for testing these ideas. It is a fairly small project and is quite neatly associated with a category tree with Category:Disability as the "root". -- Roger (Dodger67) (talk) 17:54, 5 December 2021 (UTC)

I thought the purposes of talk page banners were mostly to make empty talk pages look fancier and to advertise WikiProjects, neither of which is accomplished by doing this with article categories. User:力 (powera, π, ν) 17:46, 5 December 2021 (UTC)

@力 That's probably how it looks from the article end, but having a project banner on an article enables various functions and tools at the project page, so it's definitely not mere decoration. Roger (Dodger67) (talk) 17:58, 5 December 2021 (UTC)

• We could still display the banners in the same way, even if they're determined differently. {{u|Sdkb}} ^talk 18:16, 5 December 2021 (UTC)

I think that's a good idea if possible. However, there are WikiProjects which tag articles with things other than just importance+class. Would any of these present implementation difficulties? Dege31 (talk) 18:35, 5 December 2021 (UTC)

Dege31 I don't think that's a serious concern, once the basic tag has been added the project members can easily add their additional parameters. I sometimes do it for WP:MILHIST (which has a particularly comprehensive set of banner parameters. Roger (Dodger67) (talk) 19:26, 5 December 2021 (UTC)

• A semi-related comment: I'd like to see the whole stub category system go away. It more or less duplicates the project hierarchy and I don't see that it serves any useful purpose now that projects are an established part of how the encyclopedia is organized. -- RoySmith (talk) 18:49, 5 December 2021 (UTC)

  Definitely related, and I agree. I think the ultimate goal should be to only have to categorize stuff once, and to have everything else build off that core system. {{u|Sdkb}} ^talk 22:26, 5 December 2021 (UTC)

  @DannyH (WMF), did you ever write up the "neighborhoods" idea? A tag-once system would be useful for that. Whatamidoing (WMF) (talk) 20:31, 6 December 2021 (UTC)

  RoySmith Re the stub categories, I second the idea of doing away with them. The only time I've seen it referred to outside of the article, is that DYK says no nomination should be a stub. In practical terms at DYK, that means remove the stub rating, because no two editors actually agree on what a stub is. Useless. — Maile (talk) 02:06, 12 December 2021 (UTC)

• The solution here is do both. We have dozens of tagging bots. But categories need to be super specific to be bot-friendly. Just because something mentions Canada doesn't mean it's of interest to WikiProject Canada. Headbomb {t · c · p · b} 18:53, 5 December 2021 (UTC)

• Adding to Headbomb's point User:AlexNewArtBot has a far too high false-positive rate. At WP:DISAB my thumbsuck estimate is that only about a quarter of the new articles it lists are actually sufficiently relevant to receive the project's tag. So we should look at how the bot identifies relevant projects and try to do better than that. Roger (Dodger67) (talk) 19:26, 5 December 2021 (UTC)
  • The new article alerts bot just searches new articles for a list of regular expressions, giving and taking away points based on which ones are contained, and then lists all of the articles which are above the threshold. The particular rules for WP:DISAB are here – and are fairly limited. (My experience is mostly with the Classical Antiquity articles, which has a rather more substantial ruleset and seems to do relatively well at picking relevant articles). Caeciliusinhorto-public (talk) 11:01, 6 December 2021 (UTC)

Please remember the guidelines of WP:CATVER and WP:CATDEF. That means that there are some articles that might not be in a category but are eligible to be part given wikiproject. MarnetteD|Talk 15:10, 6 December 2021 (UTC)

• Strongly oppose the idea that WikiProject banners should only appear on category pages. Categories are likely to be viewed by far fewer readers of Wikipedia than are articles, and it is only by having WikiProject banners on the talk pages of articles that we can ensure that our readers know which WikiProjects are available. YTKJ (talk) 20:47, 7 December 2021 (UTC)

  @YTKJ: You are misinterpreting the proposal. The idea isn't to have project banners only show up on category pages, but rather to use categories to help determine which banners show up on a talk page. (Also, per the idea lab instructions, please don't make bolded !votes here.) Best, {{u|Sdkb}} ^talk 20:51, 7 December 2021 (UTC)

• I support the spirit of this proposal, and think it would be quite valuable both when creating new pages but also older pages who might not have gotten attention in the talk page but are filed in the appropriate categories. Also, I would imagine assigning categories to projects (e.g. Category:Women scientists to Wikipedia:WikiProject Women scientists as an easy example) would take much less time than assigning individual pages, which means editors creating or contributing to formulaic topics (e.g. 2022 FIFA World Cup matches) could benefit greatly from a bot like this. Santacruz ⁂ Please ping me! 18:25, 8 December 2021 (UTC)
• While I understand the reasoning, the implementation would almost assuredly be flawed. Categories are added, or removed, by either the article creator or/and subsequent editors who come across it. Most new editors don't know what categories to add, and even the seasoned editors don't know all the categories that apply to a given article. Active projects prefer to apply their own talk page banner. Some, like Wikipedia:WikiProject Women in Red/Article alerts tie in to the banners to post their alerts. And in the case of WIR, in addition to their project banner, they have special talk page banners for given subject drives and different years. It wouldn't be productive across the board to have the categories determine the talk page banners. — Maile (talk) 01:31, 12 December 2021 (UTC)

Article wizard - Check reference reliability and do some notability checks

The aim is to avoid new editors rage quitting after article deletion, by telling them as early as possible that the article will be deleted at AfD, The idea is to make the article stay in wizard and in draft space until some notability requirements are met,

Steps In the Wizard

1. Requires a portal/category, and the notability requirements would be advised
2. A notability quiz is done for GNG
3. Proposed References are added in
4. NPP page curator checks the reference reliability
5. A new development would check the reference for relevance (# of mentions in google books)
6. The editor can then delete the failed references and find a better one
7. Once these issues are fixed, then the article leaves Wizard
8. If the article is still in article wizard in 30 days it is deleted

—Wakelamp d[@-@]b (talk)

• I'm a bit lost on exactly what this idea wants to do? It seems like it is proposing that a new article workflow gets "google" to evaluate the article, and some "fact check" provider to provide some sort of feedback to the editor? Am I missing something? — xaosflux ^Talk 23:43, 30 November 2021 (UTC)

  "The Wizard" is just a guided form that helps people set up a new page before the first revision of it is published (even as a draft or sandbox page) - I don't think it would be a good idea to prevent saving (and therefore collaborative editing) of drafts until they meet new standards, or require that a page go from idea to this point in only one editing session. I do think that giving people additional tools to help determine if a current version of a draft or sandbox is in good order prior to moving it to an article space could be helpful though. — xaosflux ^Talk 14:37, 1 December 2021 (UTC)

  1. I agree it's currently guided, but I was hoping that the wizard could be extended to have a link chooser like complicated.
  2. With collaboration on drafts, AfC has a 2 month wait and an 80 % fail because the article has no hope of notability.
  3. Ir we wait until the article is saved, before we do a rough notability check then there may be a great chance they have wasted their work
  4. I also want more checks on articles to be available for the editor in the article.I don't want the article marked up with tags though, but highlighted with the possible error. But I do want Rater to use
  5. Saving an article causes NPP to review it within 5 minutes, which 20 % of AfD articles survive (as this page by {{User:JPxG}} shows. Wakelamp d[@-@]b (talk) 16:02, 1 December 2021 (UTC)

  • Note, I wasn't talking about publishing an "article" - I was talking about publishing to Draft space, or to a sandbox. — xaosflux ^Talk 16:52, 1 December 2021 (UTC)

New User Experience and emotional states

New User Experience and emotional states (talk) 14:18, 23 November 2021 (UTC) New Editor interaction Exp Editor Opinion Good Article Good Artticle AfD Good Article AfC Vandal Vandal AfD Creates Login NA Confusion Anticipation Starts an article style="background-color:#32cb00;";" Excitement Joyful Uses Wizards Confusion Edits Worry Saves - Draft Article NA Worry NA Saves - Draft Article to AfC Uncertainty Waits for AfC Backlog to fix Indifference Frustration AfC - Disccussion Satisfaction Frustration Pleased Confusion Upset AfC - Fail Uease Anger AfC - Pass Satisfaction Relief Publish Article Backlog Pride Amusement Screen dump of article NA Pride Status Publishes Article accidently and NPP/Other Edits immediately Satisfaction Upset Amusement Tools - tags Satisfaction Frustration NPP - AFD Pride NA Shame Anger Fear Further Edits NA Ok Upset Pride the longer it lasts Amusement Edit Reverts Satifaction Guilt Anger Amusement Amusement AfD -Pass NA Relief Annoyed Amusement Amusement AfD - More work Frustration Frustration Amusement Amusement AfD - Fail Anger Anger Amusement Amusement User page for Deletion Indifference Anger Hatred Amusement Amusement User Page edited (Personal Page) Anger Hatred Amusement Amusement User Talk (personal space) Safety Thankful Friendly Relief Confusion Rejection Frustration Anger Troll Talk Satisfaction Tea house Satisfaction Unease Frustration Thankful Relief Frustration Help Desk Satisfaction Stress Frustratio — Preceding unsigned comment added by Wakelamp (talk • contribs) 14:23, 23 November 2021 (UTC) User:Wakelamp, I especially appreciate the analysis of emotional states, which is often so overlooked. As the rest, can you provide an executive summary of what you're saying here, and thinking as to possible actions? I'm not super smart and am having trouble interpreting the chart. I think you are thinking along lines of changes to some software rather than just rules? Herostratus (talk) 16:31, 24 November 2021 (UTC)

Notability Standards reduction for underrepresented topics

NO Notability Standards reduction for underrepresented topics If nothing else, en-wiki has made it very clear that it does not support reducing notability standards for under-represented topics, even if the WMF would like it. The notability standard holds two purposes: it acts as a filter from everything being included, but it also works to ensure a certain minimum standard of sourcing and thus content and accuracy for that article. Changing it (and also changing our definition of reliable/independent source) would inherently have a negative impact on every article, not just those within the category, as readers would note a decline in quality but not be aware of the split-structure (just as they aren't aware of, say, Geoland's lower hurdle or NCORP's higher hurdle). There is a semi-automated tool for rating, but we deliberately require a manual look, because automating what makes a good wikipedia article isn't the same as a regular piece of text. — Preceding unsigned comment added by Nosebagbear (talk • contribs) 14:59, 23 November 2021 (UTC) @NosebagbearI can see your point, but I find it unfair that New (non-sockpuppets)Editors can no longer create a new article and pass AfD; Even experienced editors disagree about what is notable, so how can we expect them to? And after wasting 4 hours on their first one I can see why they leave. https://wiki.riteme.site/wiki/Wikipedia:Articles_for_deletion/Log/2021_November_26. # Notability standards :Can you point me to the last RfC? "en-wiki has made it very clear that it does not support reducing notability standards" BUT WP:CONEXCEPT WMF is responsible for legal issues. Equal opportunity is a legal issue, a charity issue, and a reputation issue. Women who starred in a major film - no. But a minor cartoon character - yes. IMDB reputability is a particular problem. We use their information without acknowledgement. Either with no references. TV shows have all the non-main cast/crew in the order as IMDB (number of episodes), even many of those people do not appear on credits. Movies have them same order. or we have used them to inspire our own searches for often incredibly obscure links (posters, blogs, and very low rep. blogs) Wikipedia:WikiProject_Film/Resources#Questionable_resources IMDb content is mostly user-submitted and often subject to speculation, rumor, hoaxes, and inaccuracies. The use of the IMDb on Wikipedia as a sole reference is usually considered unacceptable and is discouraged. Its romanization of Chinese titles does not follow the standard. Reliable sourcing from established publications cannot be stressed enough. Anonymous or pseudonymous sources from online fansites are generally unacceptable. So, while itself discouraged as a source, IMDB might provide information leading editors to the preferable reliable sites. Wakelamp d[@-@]b (talk) 14:53, 26 November 2021 (UTC) The WMF didn't do the easiest job at archiving, so the best way to see how hostile the Community was to changing the notability rules is to go to any page in the strategy recommendation process on it and take a look at the talk pages. For example this was the first draft of one, and then there are multiple talk pages of the later iterations. It was also made clear on the village pump, and in innumerable zoom calls. As the WG was responsible for assessing commentary on its own work, it still persisted into the final form, despite a unanimous opposal on the final version. Take from that what you will. While the WMF has responsibility for legal functions, equal opportunity a) applies to things like employment, not encyclopedic content, b) would require a level playing field. Were we to say "female biographies need 8 good sources, male need 3", that would be uneven (though still not a legal matter). In futher response to what you say, in a sense, we don't expect new editors to know how to handle the notability guidelines. We discourage writing a new article as the first thing to do, and also heading straight to AfD. However new editors can create new articles (but through AfC) and pass AfD - it's not like we auto-fail any argument backed by a new editor in AfD, they just may not be aware of what those are (as are some experienced editors). Nosebagbear (talk) 17:16, 26 November 2021 (UTC) A question. If you created an Article what do you think your chances would be to get no NPP templates, or fail at AFd? ( and 30 % or the Articles that end up at AfD have no notability issues) 1/I am sure I read about it on an EU website applying to written work...There is also something about allowing equal access to work and not discriminating,,, In Australia, volunteering and work have the same safety rules. Our current process removes far more more women 2/ With discouraging - not so much with the 'Be Bold' everywhere. And after a SIMPLE :-) spelling error on search, you get "Create the page "SdifjoIWEHF" on this wiki!" 3/ AfC is not forced, but they told me that 80 % fail for lack of references 4/ I would love the split for New Article into speedy, AfD (pass, fail, quit, rename)m AfC 5/ And I just found out that ORES does rated articles up to C CLass using Rater Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 19:55, 26 November 2021 (UTC) In Australia, volunteering and work have the same safety rules. Our current process removes far more more women. Those "safety rules" would apply to the volunteers themselves, not to the articles they write. Do we have statistics that new editor retention is far worse for women? --Ahecht (TALK PAGE) 20:12, 26 November 2021 (UTC) I will post in women in red. I think Our male/female split has got worse, which means that it must be so Anyway I have seen 4 articles Women and men are far nearer to 50/50 to edit WP, but are far more find it unwelcoming, And are far likely to leave. Educated women are more likely to leave workplaces that are aggressive Women are more likely to respond negatively and personally to critical computer warning messages Women in power imbalance situations are more likely to be passive or avoidant. There only restorative is to exit Wakelamp d[@-@]b (talk) 13:50, 27 November 2021 (UTC)

What about leaving the wizard as is, but giving all editors away to check reference notability and other issues on a pageWakelamp d[@-@]b (talk) 13:54, 12 December 2021 (UTC)

Do editors quit because of changes to their user page and aggression on user talk? Options?

User pages are hidden from google and main search. So, does it matter what legal things people do on their user page? Or if there is a  ? (As an aside many MfD discussions seem to be look like payback, are petty, or are people imposing their views.)

Experienced editors (especially admins) see talk as a collaborative space, a place to show appreciation, a task list, and a place to show achievements. New editors and overwhelmed prolific editors see their user page similarly, but also as a private safe space. If they do see it like, then changes to user, anger on talk, or complaints on MfD would be seem as deeply personal. They might perceive these chnages as stalking, harassment, as deeply critical and disrespetcful, or as vandalism. Any of these perceptions might make them quit. if another editor is going to be angry, they should do it the full light of day on article or their own talk.

So, what do people think, and what should we do>? Wakelamp d[@-@]b (talk) 23:51, 2 December 2021 (UTC)

First, what exactly is it that you're asking? You made a lot of semi-related claims (not all of them seem to be substantiated/valid), alongside some that are hard to understand (what 'legal things' are you talking about), and talk in vague generalities. Once you have a clearer question in mind, we can opine more substantially. There are lots of "someone might do this" in there. The realm of possibilities in the human condition is vast. I can post a link to a song on youtube, and someone might get offended by it. But that doesn't mean we need to do anything about the perceived offense.

In general MfDs are for dealing with miscellaneous pages that violate one or more policies or guidelines. We are, amongst other things, not a webhost, and user pages have guidelines to which they must adhere. While in general we tend to let people put more or less what they want on their user page concerning their own interests, background, etc..., there are limits to it because this is specifically not a social networking website. If User:Example is interested in wargaming or baking, they can say so, maybe even put a picture or two up. But userpages dedicated to painting techniques they've personally used, or their grandmother's roast beef sandwich recipe belong on other sites.

Hope that answers some of your question. Headbomb {t · c · p · b} 03:38, 3 December 2021 (UTC)

Thank-you for your reply. I do have some ideas (referenced even). But I would like to understand your viewpoint as an experienced editor first

• Do you really think that Wikipedia has no features of a social network? And are social networks important for retention? (See the Discord channel with avatars and off topic areas)
• Now that user space is hidden from search, what do you see as the benefit to Wikipedia of the MfD policies? And is the cost of editors leaving worth it?
• Can you see how a new editor might find aggression on talk, more upsetting than on article?
• Lastly, do you think younger editors should conform to our policies, or we should acknowledge they may be different? Wakelamp d[@-@]b (talk) 22:29, 3 December 2021 (UTC)

First you need to understand that Wikipedia is an existing community, with its own dynamics, and your questions seem to be mostly an academic/corporate HR exercise concerning what ifs and other hypotheticals, rather than concrete situations.

1. "Do you really think that Wikipedia has no features of a social network?" It doesn't matter if Wikipedia has some features of a social networking site, it is not our goal to be one. We tolerate/encourage social network-like things to the extent that they align with our goals of building an encyclopedia. Letting others know you have a general interest in wargaming lets others know, if they stumble upon a wargaming article and they are unsure what to do with it, that you might be a person with an informed opinion on the subject. So yes, networking between people is a thing, but we are still not a social networking site like MySpace or Facebook, or Livejournal (see WP:NOTWEBHOST).
2. "Now that userspace is hidden from search" It was always hidden, or at least has been hidden for longer than I can remember. As for MFD, see WP:MFD for what it deals with. It ranges from misuse of userpages (from attack pages, hosting copyright violations, violations of WP:WEBHOST like a memorial page to deceased members of your family), to various issues found in the Wikipedia:, Help:, Draft:, Mediawiki:, etc... namespaces.
3. "Can you see how a new editor might find aggression on talk, more upsetting than on article?" Sure, but again, unless you have specifics, this is really a discussion about generalities. I really doubt telling something upsetting (Anywhere from "I disagree with you for these reasons" to "This violates our policies" to "PISS OFF U IDIOT") on a talk page would upset them less if they were told the same thing at a different location (for example, in the edit summary of an article).
4. "Do you think younger editors should conform to our policies" Everyone who wants to edit Wikipedia should conform to our policies. It doesn't matter if they're 82, 28, or 12. Anyone that's here to build an encyclopedia is welcomed to join and help. Anyone that's WP:NOTHERE is welcomed to stay away. Age only matters the extent that competence is needed.

Headbomb {t · c · p · b} 22:54, 3 December 2021 (UTC)

@Wakelamp and Headbomb: Regarding Now that userspace is hidden from search, this has been the case since phab:T104797 was actioned on 23 November 2015. Before that, you needed either an explicit __NOINDEX__ or an option in a header template such as {{userpage|noindex=yes}}, something that I did here but never got around to removing again. --Redrose64 🌹 (talk) 12:18, 4 December 2021 (UTC)

Starting off with point 3.

1. You stated "not all of them seem to be substantiated/valid), see references below.
2. Can you advise your proof that"I see no evidence that harassment on user pages is more damaging than harassment on user talk pages."
3. "It is not that "someone might get offended by it", but it is whether WP:5P4 causes them to leave. Maybe think of it from the perspective of a new editor, or someone who avoids conflict

• They don't have your power to protect your page https://wiki.riteme.site/wiki/Wikipedia:Requests_for_comment/Protect_user_pages_by_default
• Women are the far more likely to use user space to collaborate and to thank, they create more content edits, and avoid conflict [[1]] [[2]] [[3]]. [[4]]

"We revisited their talk pages and found that in many such cases the editors had to face bullying from other editors. Those bullying instances are usually mentioned as a part of the article talk pages. Sometimes the user has also been found to express his/her grievances on their personal user page. Figure 5 shows few example cases of toxic arguments and explicit reasons for leaving the platform that the editor had to face ...When expertise gone missing: Uncovering the loss of prolific contributors in Wikipedia

• New users don't have your experience and are judged far harder than in the past; they react to user page templates negatively. A WMF paper by Epochfai 50 % of good faith new editors have their first edit reverted and a template added to their user page automatically, They were then less likely to use user talk, create content, and were more likely to leave within 2 months. Don’t Bite the Newbies: How Reverts Affect the Quantity and Quality of Wikipedia Work Don’t Bite the Newbies
• A new editor would see the current policies as offering little support; they cane be summarised as toughen up Wikipedia:Harassment#User_space_harassment, Wikipedia:KEEPOFF "it is not enforceable to tell somoene to stay of your talk page", Wikipedia:RPA "t "Reving unquestionable personal attacks from your own user talk page is RARELY a matter of concern.", "Similarly, discussion of a user's conduct or history is not in itself a personal attack when done in the appropriate forum for such discussion (for example, the other editor's talk page, ..." , but this disagrees with [Universal code], WP:AVOIDYOU, WP:HOUNDING and [Wikimedia terms of use] Wakelamp d[@-@]b (talk) 14:00, 5 December 2021 (UTC)

I'm going to ask what any of that has to do with the price of beans [i.e. WP:MFD as a process to remove pages that don't belong in userspace (or elsewhere)]. And give concrete/specific examples, not general 'what if' situations. Headbomb {t · c · p · b} 15:56, 9 December 2021 (UTC)

I am going through the MfD page, why don't you put your comments on and we will see what is different

I also asked you "Can you advise your proof thatb"I see no evidence that harassment on user pages is more damaging than harassment on user talk pages" Wakelamp d[@-@]b (talk) 15:05, 10 December 2021 (UTC)

• A lot of things cause users to stop editing. While I think editor retention is important, I think one should be cautious in making changes to things mainly on the basis of preventing editors from leaving. They might perceive these chnages as stalking, harassment, as deeply critical and disrespetcful, or as vandalism. Any of these perceptions might make them quit. This is true of any editor-to-editor interaction on Wikipedia. That includes having an article you made nominated to AfD, or an edit reverted, or a talk page objection to an edit you made, or being criticised. Ultimately, editors who continue editing have to accept that unpleasant situations will arise. They could decide dealing with those isn't worth it to them, to contribute to a volunteer site, but that's a decision the volunteer makes. I would say that there are times when other editors notice valid policy violations and should still let them go, if they're truly insignificant, and in many cases that is what happens. I don't think a policy change is required for that, just editor discretion. Aside, there doesn't really seem to be a proposal here, but there are some decent thoughts and you might be interested in Wikipedia:WikiProject Editor Retention as a place to discuss them. ProcrastinatingReader (talk) 15:18, 10 December 2021 (UTC)

  Some editors stop editing because a thread was opened about them at AN or ANI. Some because they were sent to ArbCom. --Redrose64 🌹 (talk) 22:01, 10 December 2021 (UTC)

  @ProcrastinatingReader I just joined then Wikipedia:WikiProject_Editor_Retention. I agree that AfD is quite confronting for new editors with 500 K articles having ended up there. The decisions are mostly just, but I still think it is wasteful that we don't advise them that they have will fail notability because they insufficient references from unreliable sources I often see the counter accusations thaat new editor is a scammer or sock puppet because their first article was too good. I agree that we should not change because new editors may leave, but all editors deserve civility if they are civil. Also to make it clear, this issue also causes many long time editors to leave. The cycle seems to be that there is an argument on article, and someone won't give up and they attack on user talk.

  My current suggestion is that we modify the MFD policy to stop wasting time on ragpickers some of whom seem to specialize in MfDs nominations. We need allow people to have personal stuff unless it is quite excessive,and stop project space page deletions nominations etc .I also think we should clarify the current contradictory rules about what is acceptable for user talk, and make it easy for editors to do so. Some editors. especially Wikiepedia:wikikings have the emotional range of a dead chook and don't understand when to back off Wakelamp d[@-@]b (talk) 14:44, 12 December 2021 (UTC)

  @Redrose64 I agree on the AN , ANI, and Arb Com exits for new editors, but do many genuine new editors end up there Wakelamp d[@-@]b (talk) Wakelamp d[@-@]b (talk) 14:44, 12 December 2021 (UTC)

Some diff and Watchlist Ideas

There are some aspects of the Watchlist (and diffs more generally) that I think could do with a little improvement. I don't want to necessarily propose these changes in their current form, but I think they are ideas that could do with some discussion.

Aggregating changes by the same user in quick succession

Tracked in Phabricator
Task T9904

It is extremely common for an editor to make changes in quick succession. Some of the most common examples of this include correcting for typos, minor additions and amending word choice. Such edits create three problems for a user who sees them on their Watchlist:

1. It obscures how significant that user's contributions have been to the article as a whole
2. It makes the "diff" button functionally useless, as you always know you may not get the full picture. In fact, I always view the page history by default, just in case.
3. It means that substantive edit comments are pushed off the Watchlist and replaced by "typo" (or whatever).

I would suggest that, by default, the Watchlist shows an aggregate diff of changes that meet the following criteria:

• The changes must be within what you could reasonably call a "same editing session". In other words, the time between the changes should be short enough to give a user time to read over their changes, notice any mistakes, and correct them. If they've had a chance to go out for lunch in between, that isn't going to be the same editing session. I would suggest 30 minutes as a starting point, but there may be ways of refining this.
• The changes must be by the same user.

Watching page sections

Tracked in Phabricator
Task T2738

It would be useful to have the option of watching sections of pages. I'm saying this primarily with talk pages in mind, and particularly notice boards, as they routinely contain multiple active discussions where many users only care about one. Not only will this stop users from being spammed with irrelevant updates, but it also prevents any changes to discussions they do care about from being hidden. Theknightwho (talk) 17:57, 8 December 2021 (UTC)

Showing edit distance

Tracked in Phabricator
Task T53506

Currently, diffs show the difference in the pagesize, with changes of 500 bytes or more being bolded. This is a crude marker for an encyclopaedia, where we care about quality and not quantity, but it does provide a very rough signpost that a change is likely to be significant in some way. However, the major downside to this is that additions and subtractions obviously cancel each other out, and so you may end up with significant changes to pages that appear to be more minor than they really are. Examples of where this happens are:

• Moving text, for obvious reasons.
• Replacement of a whole sentence or paragraph by another of roughly the same length.
• Coincidence.

I would therefore suggest that Watchlist, page history (and so on) also show something that represents edit distance. There are various ways of measuring this, but the general idea is that it takes into account the number of operations required to change one set of text into another, and therefore more closely aligns with what we mean when we talk about how much an article has been "changed". To be clear, this is still a long way off from capturing the meaningfulness of any given change, but it is at least an objective measure that provides a better sense of what has happened. Going any further than that would require some level of semantic interpretation, which I think is already adequately covered by the various Watchlist filters.

I also wonder if this could have application in abuse filters, but it's not a topic I'm familiar enough with.

—Theknightwho (talk) 17:57, 8 December 2021 (UTC)

Discussions

I really like the first two proposals and would be very interested in improvements similar to the ones you have proposed. The third one seems a bit more finicky to implement, but I'm sure more capable editors will be able to comment on that with more experienced opinions. Santacruz ⁂ Please ping me! 18:09, 8 December 2021 (UTC)

Follow phab:T2738 for "Watching page sections". — xaosflux ^Talk 18:11, 8 December 2021 (UTC)

Follow phab:T9904 for some on combining sequential edits by the same user, it is specifically for history (may address your "diffs" part) but could possibly be leveraged for WL if it is done. — xaosflux ^Talk 18:15, 8 December 2021 (UTC)

Follow phab:T53506 for more on adding "edit distance" to the revision data. — xaosflux ^Talk 18:16, 8 December 2021 (UTC)

Thanks! Reassuring to know that these ideas are on the radar. Theknightwho (talk) 18:22, 8 December 2021 (UTC)

Getting notifications for edits to a section (beneath a second-level heading) is available as part of the discussion tools beta feature. See Wikipedia:Talk pages project § Notifications for topic subscriptions for a description. To enable it, go to the beta feature preferences page and look for the "Discussion tools" section. isaacl (talk) 18:48, 8 December 2021 (UTC)

@Isaacl: I never checked, but think this is for "talk" pages only not any section of any page. (May still be a partial solution to the OP's idea). — xaosflux ^Talk 19:18, 8 December 2021 (UTC)

It is indeed for discussions rather than article sections, which does seem to fit what the OP had in mind. It's not limited to the talk namespaces, though, as the subscriptions I have tested are in the Wikipedia namespace. (Under the hood, it's the first signed comment that is being subscribed to, so notifications will continue to be generated even if the section is moved to another page.) isaacl (talk) 19:49, 8 December 2021 (UTC)

Ironically, I've noticed that I'm now able to subscribe to anything except this discussion. I have no idea what could be causing that, but it's not really an issue for this page. Theknightwho (talk) 20:18, 8 December 2021 (UTC)

@Theknightwho:, If I had to guess, it might be because the "first signed comment" created multiple (sub)sections, so it might not have a method to handle that? Nosebagbear (talk) 10:22, 9 December 2021 (UTC)

Sound plausible. Theknightwho (talk) 14:20, 9 December 2021 (UTC)

Collapsing edits is a great idea, edit distance is a great idea, and as said above you can subscribe to talk page sections using "Discussion Tools". User:Enterprisey/section-watchlist used to allow watching sections in general, in any namespace including the article namespace, but it was a little tricky to run so I don't run the server anymore. For the former two, I would support user script prototypes, as arbitrary changes to MediaWiki seem pretty tough to make these days. Enterprisey (talk!) 07:51, 11 December 2021 (UTC)

Thanks. It's occurred to me that it may be better to display edit distance as a pair "(+X, -Y)", showing characters added and characters removed. Gives a more intuitive idea of what has happened, and is trivial to calculate by comparing the page size change with the edit distance (X + Y = edit distance; X - Y = page size change). This is more relevant to other Wikis, but this would need to be the page size in characters, and not the page size in bytes (which I think is what we see at the moment). Theknightwho (talk) 15:20, 12 December 2021 (UTC)

New Years Logo Proposal

I think on December 31 and January 1, Wikipedia should change its logo to represent the new year. I don't exactly know what it should change its logo to. Maybe fireworks, maybe something else.

Either way, I think a logo change on the new year would be a good idea. ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 17:15, 9 December 2021 (UTC)

I like the idea as we need something fun after 2 rubbish years Wakelamp d[@-@]b (talk) 14:46, 12 December 2021 (UTC)

You might enjoy c:Category:New Year Wikipedia logos to see what some other Wikipedias have done (I like the Chinese New Year subcategory). —Kusma (talk) 22:58, 13 December 2021 (UTC)

What am I missing: Requiring email for admins

Tracked in Phabricator
Task T32018

I was having a little look at November's inactive admins and noticed that GermanJoe was unable to be email notified of their inactivity - this got me thinking, could we make having a verified email a requirement for administrators?

I can't think of any real negatives, and the security benefits are fairly significant:

• Password resets
• Notification of failed logins
• Contactable by bureaucrats

Similar sorts of discussions (i.e. "requiring 2FA for admins") tends to fall down on implementation and availability of 2FA devices as not everyone has access to a mobile phone - there are a number of email providers, such as Gmail, which are entirely free and are no more difficult to use than MediaWiki...

For what its worth, 989 of our current 1067 admins (~93%) do have email enabled already.

So, save me typing out a doomed RfC, what am I missing here? -- TNT (talk • she/they) 04:00, 4 December 2021 (UTC)

I think it's a reasonable proposal and I would support it. It's also possible to use email as a 2FA method, but that's tangential.

One question I have though, is the requirement to just have an email set, or would it be to have a working email set? Email addresses do regularly stop working or people lose access to them. Would we have regular pings and confirmations to make sure the email keeps working? If emails bounce enough and the address becomes unconfirmed, do they automatically lose their admin privileges? Legoktm (talk) 05:28, 4 December 2021 (UTC)

I think it's reasonable to discuss this, and I'd tentatively support the tenets premised in the original posting. I will, however, say: I do not think we could (for reasons of privacy) or even should (for multiple reasons) require an affirmation of receipt or reply in any form. Best regards.--John Cline (talk) 15:37, 4 December 2021 (UTC)

@John Cline: why would there be a privacy issue? Legoktm (talk) 12:00, 5 December 2021 (UTC)

Thank you for asking this of me Legoktm; I'll offer this clarification:
Of the many possible ways a negative issue with privacy could affect our ability to mandate email access and, in particular: email correspondence, the one I referred to (in my comment) which almost certainly would, involves the apparent conflict (and inherent direct contravention) that exists with formalizing such a mandate in light of the painstakingly deliberate implementation efforts associated with Wikipedia's system of email delivery.
That system thoroughly describes:
1.) the efforts emplaced to prevent disclosure of your email address (as the recipient)
2.) an allusion to reasons for emplacing this protective measure enveloped in cautioning against arbitrarily disclosing your email address without due consideration, and
3.) the belabored instruction that a reply is not required coupled with the belabored explanation that choosing to reply would, thereby, effect and include the very disclosure ill-advised therein.
Consider, for example, the statements given to the recipient in advance of the email message itself; which says:
"The sender has not been given the recipient's email address, nor any information about the recipient's email account; and the recipient has no obligation to reply to this email or take any other action that might disclose their identity. If you respond, the sender will know your email address." emphasis mine.
I apologise for the lengthy reply but know not of another way when efforts at concision have failed, having been tried. Please follow-on, if questions remain, and (Lord forbid) I haven't been clear regarding the answer to the question asked. Best regards.--John Cline (talk) 19:08, 6 December 2021 (UTC)

@John Cline: I think this feature could be implemented without revealing your email address. If the email contained a unique link that you click on to confirm receipt (maybe to a Toolforge tool, or built into MediaWiki), then you'd be able to verify you received the email without the sender ever learning what your email address is, as the reply/ack doesn't happen over email. Legoktm (talk) 19:24, 11 December 2021 (UTC)

It's difficult to see what problem this is addressing. An inability to do password resets is a risk anyone is entitled to take. Failed logins are a non-issue - we rarely notify anyone about them. Contact by bureaucrats can be done on the talk page. I have certainly been through periods where the only wiki emails I get are harassment, or not interesting, or I have simply had no need for private communications. Adding to that, email accounts may be free, but they usually require regular logins. And if someone is logging in only every few months to keep an email account alive, what is the point of email? What you're probably wanting is an email address which will reach a user promptly. At times I offer no such thing, and I don't see why anyone else should. -- zzuuzz ^(talk) 16:04, 4 December 2021 (UTC)

I haven't thought about this enough to decide if I'd support it, but one thing to be clear about is that there's a difference between having an email for your account and having the "let other users email me" option checked. Some admins may prefer not to have that option checked, since it opens up vectors for harassment, and some prefer on principle to handle everything in the open for transparency. {{u|Sdkb}} ^talk 04:30, 5 December 2021 (UTC)

How does adding an additional attack surface (a possibly poorly secured email account) help to increase security? Also, we need more admins, and desysopping people because they do not have an email address set seems to go in the wrong direction. —Kusma (talk) 13:33, 5 December 2021 (UTC)

I have an email attached to my account, just not enabled for "let other users email me" option. I get emails all the time from editors I know well, notifications from the Wikipedia Library, or various others. Before I became an admin, I had to change my email address and remove the option to let others email me - because an editor added me to receive their daily blog. I am not interested in what users do in their personal lives. And then there were a few others who wanted to dish dirt on other editors, or trying to get me to take an admin action without discussing it on Wikipedia. Not enabling the "let other users email me" option allows me to remain above board on admin actions. — Maile (talk) 13:58, 5 December 2021 (UTC)

I have a gmail attached, and an emailnotice which discourages frivolous or harassing emails. I see no problem requiring email access to admins, just as I see no reason it should be an IRL email address. We can only assume GermanJoe made a conscious decision about email and was aware of the possible consequences. Cabayi (talk) 15:08, 6 December 2021 (UTC)

Having any form of privileged account where it is literally impossible to reliably contact the account owner is absolutely bonkers. Does a verified email address guarantee that its owner will see an email sent to it later? Of course not. The owner could be on vacation. Or dead. Does it mean that you can at least try to contact them with a reasonable probability of success? Yes. That's the best that you can hope for as the operator of a service and a baseline requirement everywhere - except, apparently here. Any administrator who doesn't respond to email verification within a set period should lose the bit until they can verify themselves. Is that going to be painful? Maybe, but dragging our absurdly lax and antiquated system into 2021 is never going to be a fun process. This is also contingent on having a competent email verification system in MediaWiki, so don't expect it to happen soon even if sufficient consensus emerges in discussion.  — Scott • talk 17:33, 10 December 2021 (UTC) Struck - see below.  — Scott • talk 20:54, 11 December 2021 (UTC)

@Scott: can you expand on what's missing in MediaWiki's email verification system? Legoktm (talk) 19:25, 11 December 2021 (UTC)

@Legoktm: Sorry, that comment was a brain fart and now that I've checked something I'll try again. The original post says "could we make having a verified email a requirement for administrators?" - this has been being proposed for a very, very long time but never any significant effort expended on it. The most recent time time that we had an RfC about this was in 2018 which was very poorly-attended and only ended up with the wishy-washy conclusion "There is no consensus to require admins to have their email enabled, but a significant number of comments suggested that it would be best practice." Amusingly, Help:Email confirmation has directly contradicted this since 2006, the year that the verification system was implemented. To give you an idea of just how long this has been going on, check out this discussion from August 2005, which starts "About a year back it was mentioned somewhere that candidates should have entered a valid email id. This seems to have disappeared." I could probably spend a while longer scouring the history to find that, but you get the idea. The first revision of Wikipedia:Administrators to mention contacting admins is 20 November 2002 (coincidentally, a week after I arrived here), which said that they can be emailed through the system, implying it to have been de rigeur at some point.

When writing my comment I'd actually forgotten that the confirmation system exists at all because of how long it's been since I had to use it. Several comments above added to my confusion because they also seem to be under the impression that the confirmation system doesn't exist.

With all that out of the way, and to answer your question, I'll rephrase. Having a system that allows privileged accounts without a confirmed email address creates the possibility of having a power user who's literally impossible to reliably contact, and that's not good at all. What's missing from the verification system is that account status isn't tied to it - a bureaucrat can flip the bit on a user who hasn't set an email address for themselves. This should be physically impossible, which would require a change to MediaWiki. This is simply to bring us up to baseline standard of how multi-user systems work in general, which is what prompted me to describe our current system as absurdly lax in the first iteration of this comment. Your comments above about periodic re-validation, and the linked Phabricator task, are interesting and something that I'd support, but they seem beyond the scope of the particular question being asked by TNT.

My apologies for being crotchety earlier - when I saw this come up, I suddenly felt very, very old. It also brought to mind the 2FA for admins RfC in 2019, which was extremely frustrating and riddled with misunderstandings.  — Scott • talk 20:54, 11 December 2021 (UTC)

@Scott: thanks for clarifying. I reviewed the code in MediaWiki earlier today and believe it's technically straightforward to have sysop rights tied to email confirmed status. Crats would still be able to flip the bit on users who don't have a confirmed email address, they just wouldn't be able to use those rights until they set and confirmed and address. I think that would be the preferred behavior because it also works well in the other direction, if you remove your email address or it becomes unconfirmed because it bounces too often, you immediately lose access to your rights until it's resolved.

I didn't explicitly say this above, but I'm very much in favor of this proposal, and can help with any necessary technical steps. Legoktm (talk) 04:09, 12 December 2021 (UTC)

@Legoktm: You make an interesting distinction between having rights and being able to exercise them. Sounds great, I'm all for it.  — Scott • talk 13:41, 13 December 2021 (UTC)

• As noted by several people above, we should absolutely change the policy to require emails for admins if it isn't already. I honestly thought that was already policy, and I've been an admin for over a decade. I completely thought it already was. --Jayron32 18:32, 10 December 2021 (UTC)

TheresNoTime, how do you know they haven't just disabled "Allow other users to email me"? And I've seen an admin once who disabled that because a vandal was mailing them. — Alexis Jazz (talk or ping me) 18:35, 10 December 2021 (UTC)

• See phab:T32018 for some more discussion on this idea. — xaosflux ^Talk 19:06, 10 December 2021 (UTC)

• Last time I checked, admins were volunteers. As long as admins are still volunteers then we need to think carefully before putting additional requirements on them. Yes admins need to meet some standards of activity to demonstrate they are still active members of the community who are keeping up with changes. It is also reasonable to expect admins to meet certain security standards such as a complex password, otherwise their accounts might be hacked. But before requiring a group of volunteers to enable an email we need to ask ourselves why we should do that, and who benefits from us doing so, other of course than dictatorial governments and those spammers and "reputation managers" who have the legal resources to sue the foundation and force it to disclose an editor's email address. ϢereSpielChequers 13:25, 14 December 2021 (UTC)

Add a "Funding & Donors" tab under large corporations/organizations

In the heart of democracy, transparency, and informative research, there should definitely be a more standardized category under most large corporations, organizations, non-profits, etc. that discloses said org's donors and funders. Open for discussion! — Preceding unsigned comment added by Tadism (talk • contribs) 00:15, 30 November 2021 (UTC)

@Tadism: our articles don't have "tabs". As far as categories go, not sure how you would want to integrate these to the category system? If the funding for an organization is noteworthy and referenced, you can add edit the article to add it already - either somewhere it fits, or in its own section. I don't think it would be encyclopedic to simply include a list of names of everyone that ever donated to an organization in their article, - only ones of special relevance. — xaosflux ^Talk 11:54, 30 November 2021 (UTC)

If you're using the mobile skin, then the ==Section headings== look like a bit like "tabs". Whatamidoing (WMF) (talk) 20:05, 6 December 2021 (UTC)

I imagine that the funding for particular organizations could be incorporated into the body of the article if it’s reliably sourced and constitutes due weight. I imagine that there could be space for “key people” to be listed in nonprofit infoboxes if there is a person or two who bankrolls an entire operation, but that has to be a case-by-case thing. — Mhawk10 (talk) 21:27, 30 November 2021 (UTC)

Showing special relevance makes sense, butI don't think WP should do things in detail, that NPOV groups do better. They are experts in collecting primary and secondary, sources and weighting it, Maybe, we could link to an article that discusses all the different transparency sites or financial declarations? Or we could use a tool to create an acknowledge current list. There are categories for this, but they are incomplete. Wakelamp d[@-@]b (talk) 22:37, 2 December 2021 (UTC)

Tadism this could be a good proposal for Template:Infobox organization or Template:Infobox company however the quality of sourcing will be key here. I've wondered in the past if Wikidata would be a way to leverage this change en mass, but only if there was sourcing. Still for many of the more complex companies, like Amazon, it's sourcing/funding is much more complex. For US non profits, 990 forms could be a solution. This doesn't require a policy change and I just want to say it's generally a good idea, even if the devil is in the details. ~ 🦝 Shushugah (he/him • talk) 16:23, 18 December 2021 (UTC)

Wikipedia Wrapped

Every year on or around the first of December a bot delivers fun facts about your editing habits over the past year straight to your talk page! Y'know, stuff like how many edits you've made, number of articles you've started, the article you started with the most edits by other users etc. Whaddaya think? But make it opt in and maybe give it a less, shall we say, "litigious" name. Americanfreedom (talk) 00:17, 13 December 2021 (UTC)

If it's opt-in, sure. --Ahecht (TALK
PAGE) 15:16, 13 December 2021 (UTC)

I'd opt in to that! Especially if it's able to come up with some insights beyond what XTools has. {{u|Sdkb}} ^talk 00:12, 22 December 2021 (UTC)

Add redirect templates to dropdown box in editing window

Currently, when editing an article if you click on "cite" & then on "templates," you can add "cite web" "cite journal" etc. templates. Can such a dropdown list be added when adding a redirect for "redirect from ... " such as listed in Template:R template index? I realize there are probably too many choices to have on a dropdown box, but it would be nice to choose the proper template for a redirect somehow. Rgrds. --Bison X (talk) 14:57, 13 December 2021 (UTC)

@Bison X, if you use the visual editor (or its 2017 wikitext mode), you can use Insert > Templates from the menus to search for any template. Whatamidoing (WMF) (talk) 22:15, 13 December 2021 (UTC)

@Bison X Also typing {{ in visual mode will open the template search prompt ~ 🦝 Shushugah (he/him • talk) 23:30, 13 December 2021 (UTC)

@Bison X: If you're using the 2010 wikieditor you could use TemplateWizard. ― Qwerfjkltalk 13:05, 26 December 2021 (UTC)

@Bison X See User:Wugapodes/Capricorn. Also, WP:Twinkle can be used to tag redirects after creation. --Ahecht (TALK
PAGE) 22:25, 19 December 2021 (UTC)

Well, I have been trying out visual editor, and have grown dissatisfied with it. Regular editing is much easier. I believe I'll continue to type out the templates from memory. Rgrds. --Bison X (talk) 22:51, 15 December 2021 (UTC)

@Ahecht: It's not exactly what I was looking for, but it looks worthwhile enough to install. I'll give it a try, thanks. Rgrds. --Bison X (talk) 23:36, 21 December 2021 (UTC)

@Qwerfjkl: I didn't even know that button was there, even though I think I had to activate it via my preferences at some point in the last 5 years. It has it pros & cons, I'll try that, too, for a while. Rgrds. --Bison X (talk) 13:35, 26 December 2021 (UTC)

Individual Wikidata items for Wikipedia articles

This idea was brought up initially with the Wikidata community awhile ago but I'd also like to hear the feedback of Wikipedians as well (particularly those who edit Wikidata).

Situation

Wikipedia articles may cover more, less, or different things than the Wikidata item that they are linked to.

Problem created by situation

The statements added to the item according to the article cause the item to represent more than one thing (this is called conflation) or different things. This is bad because Wikidata items are only supposed to represent 1 thing.

Examples of problems

(all of these should have separate items for the things they cover)

• A music album article covering both the album and it's reissued version
• A social media company article covering the company and their website
• The English Wikipedia articles talks about 2 things while the French Wikipedia article only talks about 1.
• Wikidata's messiest item: JPEG (Q2195)

Current solution

Make a Wikipedia article covering multiple topics (Q21484471) item and move the article sitelinks to it.

The problem with the current solution

If there are other language Wikipedia articles that cover less, more, or different things, they will be sitelinked on different items and Wiki users will not be able to find them!

Proposed solution

• Create a unique item for every article on every language Wikipedia (regardless if they're problematic or not).
  For example, the English Wikipedia article about JPEG will get it's own item and the Spanish Wikipedia article about JPEG will each get their own item.
• Add main subject (P921) statement(s) to each article item to specify what it talks about.
• Restructure the interwiki sitelink system so that it shows users articles in other languages that cover similar subjects, using Wikidata as a backbone.

Let me know your thoughts!

You can see the thoughts of the Wikidata community, an example problematic article, and a bit more technical explanation here. Lectrician1 (talk) 23:08, 18 December 2021 (UTC)

Simply allowing WD items to include wikipedia redirects would solve one major part of the problem right away. If we have an enwiki page "X and Y", then we surely have redirects to it from "X" and "Y", and wikidata has separate items for "X" and "Y". If frwiki has separate actual pages for "X" and "Y", then when each's interwiki links would point (via WD) to the enwiki "X" or "Y" page, which would transport readers to the "X and Y" page. The harder part is to link from enwiki "X and Y" to frwiki's separate pages, assuming they do not also have an "X and Y" page. Wikidata seems to have fundamentally designed itself to be not just "1 topic per item", but a 1:1 correspondence between any language's wikipedia articles and wikidata items. It seems like you're proposing a hack to circumvent that rather than addressing it head-on as a WD design issue. DMacks (talk) 23:54, 18 December 2021 (UTC)

The fundamental issue is that Wikipedia and Wikidata have a 1 to 1 relation, instead of a many to many or even something nuanced like a "primary and secondary relations". This is further complicated by the fact that some language wikipedias have tight coupling with wikidata. A recent example, I made an article about German housing movement Deutsche Wohnen & Co. enteignen, but there is a separate wikidata item (see discussion: d:Talk:Q105085635 that only has the referendum and the Catalan page ca:Referèndum de Berlín de 2021 needs to be linked to that, to make use of some referendum infobox template. I ended up just manually enclosing the non english pages at the bottom, just like it was done prewikidata. The fact this is the simplest way to do it...is mind baffling/defeats a major benefit of Wikidata for Wikipedia specifically. Of course wikidata has intrinsic value on its own. ~ 🦝 Shushugah (he/him • talk) 00:23, 19 December 2021 (UTC)

Just as an FYI, this is called the Bonnie and Clyde problem. Linking the relevant page for context. Theknightwho (talk) 00:24, 19 December 2021 (UTC)

@DMacks

interwiki links would point (via WD) to the enwiki "X" or "Y" page, which would transport readers to the "X and Y" page

That would mean that there would be links to the enwiki article "X" and "Y" on both the "X" item and the "Y" item. Allowing sitelinks on more than one item has been proposed as a solution to this problem before. However, I find it causes chaos from a sitelink management standpoint and confusion in regards to sitelinks present on user interfaces.

For example, let's say the name of article "X" and "Y" on enwiki is just called "X". Now, when someone is on the frwiki article for "Y", they see that "X" is a sitelinked article. This clearly causes them confusion as to why that is the case. Yes, they could look at that linked article and see that it covers also "Y", but this confusion could be avoided in the first place with my proposed system.

In the discussion with the Wikidata community, I created an example interface that would use the names of the linked Wikidata topics covered to explicitly let the user know that different topics are covered in different language articles.

Using my system, Wikipedia will run a query on Wikidata for other Wikipedia article items that have the same main subject (P921) and parse them into a readable view that separates and labels the articles by topic covered.

Here's an example of this in-action with the New Vector skin. The Languages menu now includes a previously-absent enwiki sitelink about only the Shimizu Tunnel on a jawiki article that covers the Shimizu Tunnel and the Daishimizu Tunnel:

The system works very cleanly here and if there are articles that have even more differences in topics covered, the UI also supports separating them by topic.

----

Wikidata seems to have fundamentally designed itself to be not just "1 topic per item", but a 1:1 correspondence between any language's wikipedia articles and wikidata items.

Wikidata editors like myself have begun to realize that this is an problematic trend because it makes for poor data structuring and therefore, a disorganized database that is hard to work with. Wikidata should not beholden itself to the Wikipedia articles that it is linked with. As seen with the problem that this proposal hopes to solve, Wikipedia articles already have a serious amount of confounding/mixing of topics and it only gets worse when comparing between different language Wikipedias. If we really want to make a powerful structured database, we're going to need consistent schemas and layers of items that extend far beyond the main items that are linked to most articles. Eventually these structures will be able to be reliably used on projects like Wikipedia to show complex data parsed in the form of readable tables or charts.

Having dedicated items for articles actually further improves the data structure because it abstracts these layers of data about topics behind one article item. Wikipedia editors that are looking to add what topics an article covers simply have to add the topic to the article item. They don't ever have to play around or touch any of the structured data about the topics if they don't want to. In fact, them not touching Wikidata topics that have been curated to fit a schemea is probably for the better as they would have a low chance of breaking anything. Lectrician1 (talk) 01:02, 19 December 2021 (UTC)

While I fully agree with your reasoning, this adds a degree of complexity that further increases the mis-match between the level of competence required to contribute to Wikidata, and the level of competence required to competently contribute. A lot of the incoherence on Wikidata items comes from the ease of adding new properties to items without necessarily being aware of the wider schema within which those items exist, and we already have enough problems with properties being added to Commons category items or disambiguation page items as it is. Introducing millions more is going to potentially cause chaos.

I would therefore propose a new form of entity (maybe W) for Wikimedia entries, which are designed as conduits for site links, containing the relevant metadata and connections to other W entities. We can then migrate all existing items for pages and create ones for each language. Theknightwho (talk) 16:24, 19 December 2021 (UTC)

@Theknightwho

While I fully agree with your reasoning, this adds a degree of complexity that further increases the mis-match between the level of competence required to contribute to Wikidata, and the level of competence required to competently contribute.

Agreed. As we add more layers of complexity it is totally going become harder for newcomers to correctly contribute. I see this already with explaining the "release group" vs. "release" music data model we've developed on Wikidata to newcomers. However, if we really want to have strong structured data, I see this as unavoidable. What's really going to solve this issue of increasing complexity is probably improvements to the Wikidata UI that allow users to grasp Wikidata and data structures more-easily. I don't know what those improvements would look like at the moment though.

I would therefore propose a new form of entity (maybe W) for Wikimedia entries, which are designed as conduits for site links, containing the relevant metadata and connections to other W entities. We can then migrate all existing items for pages and create ones for each language.

Yeah a new form of entity for Wikimedia pages would be nice. We already have dedicated items for disambiguation pages and creating dedicated items for Commons categories is in an RFC right now. All of this is going to create a lot of Wikimedia items and a dedicated structure would ensure consistency. Lectrician1 (talk) 17:39, 19 December 2021 (UTC)

Great. I’ll add my thoughts in more detail there when I’m home and not on my phone. The migration of thousands of pre-existing items will need thought, too. Theknightwho (talk) 18:09, 19 December 2021 (UTC)

Do you still have more thoughts? Lectrician1 (talk) 17:17, 23 December 2021 (UTC)

Sorry, yes I do! Life has been busy, but will add them shortly. Theknightwho (talk) 23:56, 29 December 2021 (UTC)

• I haven't fully absorbed all of this, but I think you're talking about the same thing as I mentioned in this wikidata help question. -- RoySmith (talk) 02:13, 19 December 2021 (UTC)

  @RoySmith correct! Lectrician1 (talk) 18:39, 19 December 2021 (UTC)

• Stop trying to shoehorn Wikidata into Wikipedia. The two projects serve different functions, and have different goals. They are often incompatible. Keep them separate. Blueboar (talk) 16:30, 19 December 2021 (UTC)
  • Nobody is doing that. This is an idea to solve a problem involving interlanguage site links, which Wikidata is already used for. Theknightwho (talk) 16:51, 19 December 2021 (UTC)
    • If I misunderstand, you have my apologies… it sounded like the proposal is to change how we organize things at WP in order to create better links to WD. I strongly oppose that. If the two projects don’t sync up perfectly… so be it. They serve different purposes, and so (to my mind) should be organized differently.Blueboar (talk) 17:28, 19 December 2021 (UTC)
      • You have it backwards. It’s the other way around, but affects WP insofar as it may change how WP articles are organised on WD, and should hopefully solve issues that come out of different language WPs structuring articles differently. The current interlanguage system was designed for every article in each language being exactly equivalent, but this isn’t the case and is known as the Bonnie and Clyde problem. Theknightwho (talk) 18:09, 19 December 2021 (UTC)
        • Ah… in which case, that is an issue to be discussed over at WD. Good luck. Blueboar (talk) 18:59, 19 December 2021 (UTC)

Another potential solution that User:Izno proposed while discussing this on the Wikimedia Discord server was waiting for the introduction mw:Multi-Content Revisions, the system behind Structured Data on Commons. Izno was concerned about massive quantity of 57,940,144 items this system would create. If we utilized structured data for pages across Wikimedia, we could avoid this.

An additional benefit of having structured data for Wikipedia articles (whether as Wikidata entities or something else) is the possibility of storing other data about it in the future. Besides using main subject (P921) to define what an article is about, maybe short descriptions for articles (that are independent of the linked Wikidata item) could also be stored in it without requiring a template at the top of the page. This also creates the opportunity to establish structured data for article sections.

And overall, all of this relates to the mw:Structured Data Across Wikimedia project. Lectrician1 (talk) 18:02, 19 December 2021 (UTC)

• Perhaps thinking of an encyclopedia as “data” to be structured is the problem? Blueboar (talk) 18:59, 19 December 2021 (UTC)

  A encyclopedia is data that should be structured though. Wikipedia is great for humans right now, but not for machines. If we improve the systems that allow machines to comprehend the vast amount of data we have on Wikipedia, we can improve the experience of humans at the same time.

  This is exactly what this proposal aims to do. It helps machines understand what an article is about and it helps humans find all of the articles that cover the same things in different languages. Lectrician1 (talk) 20:11, 19 December 2021 (UTC)

• There are both (apparently) superficial and deep issues here. The apparently superficial issue is the insistence on 1:1 links when this does not model how language wikis are organized. Freely allowing redirects to be linked would help, but would not totally solve the problem. Wikidata should attempt to model language wikis as they actually are, not how Wikidata editors seem to want them to be. (A specific set of issues relating to articles about taxa is discussed at User:Peter coxhead/Wikidata issues.)
  A deeper issue is shown up by a phrase at mw:Structured Data Across Wikimedia: "language-agnostic Wikidata concepts". Many concepts are intrinsically tied to a natural language and the cultures that use it. There's no reason why the ordinary language use of berry in English should correspond to a comparable concept in another language. Languages classify and conceptualize the world in ways that are useful in a particular cultural context. The particular small soft fruits grown in temperate climates make berry a useful classifying concept. In tropical climates, it may not be. Any linguist will be able to suggest many examples of concepts that apply only within a language or culture. Peter coxhead (talk) 19:24, 19 December 2021 (UTC)

I created a new discussion on the Structured Data Across Wikimedia project to let the developers know of this idea. Lectrician1 (talk) 21:53, 23 December 2021 (UTC)

@Lectrician1: Thanks for creating the new discussion. I was actually already following this discussion, but I chose not to intervene because I found myself at crossroads between my volunteer interest in Wikidata and my work interest in SDAW.

Anyway, I already wrote a note to the team, noting that this could be an interesting test field for the part of the project that will deal with topical metadata. Unfortunately I cannot promise you anything for now, but by mid-January I think I can resume this discussion with you (we're now in winter break, and then the first week of January was already allocated for other work). While I was reading, I came to your conclusion too, and I do hope something interesting could come out of this. :) Sannita (WMF) (talk) 14:57, 24 December 2021 (UTC)

Year Page Maps

Year, Decade, Century, and Millenia Pages, for example 1895 or [[14th century should have maps of the earth so readers can see who controlled what area during that time, if the borders changed alot during that time, you could even add a second map as a before and after or animate it so that readers can watch the changes happen. — Preceding unsigned comment added by AmazinglyLifelike (talk • contribs) 02:09, 1 January 2022 (UTC)

new kind of history navbox

I have made a new type of navbox for history topics, focusing upon one period in Europe's history. what do you think of this? feel free to comment, offer suggestions, etc. thanks!!!

---Sm8900 (talk) 🌍 04:38, 3 January 2022 (UTC)

Not seeing the link. Blueboar (talk) 17:01, 3 January 2022 (UTC)

ok, here is the link. thanks. {{Early Modern Europe}} ---Sm8900 (talk) 🌍 17:10, 3 January 2022 (UTC)

Why have you done it using #invoke:? --Redrose64 🌹 (talk) 20:22, 3 January 2022 (UTC)

Using #invoke reduces the post-expand include size by about 6,000 bytes. --Ahecht (TALK
PAGE) 21:24, 3 January 2022 (UTC)

I see that you have made a new navbox, but what is so different about it that it is a new kind/type of navbox? Phil Bridger (talk) 21:35, 3 January 2022 (UTC)

simply its content, meaning its focus upon one period in European history. ---Sm8900 (talk) 🌍 22:30, 3 January 2022 (UTC)

hey Phil Bridger, turns out there is indeed already a navbox for {{Middle Ages}}. well, makes sense there would be one. my navbox has a slightly different structure; by providing distinct groupings within the navbox itself for diferent types of entries and topics, it enables a more comprehensive overview of that era, and a deeper understanading of the era as a whole. Generally, other history navboxes simply provide a set of relevant entries as a sequential list for a single era, rather than grouping them into different subject areas as I have done above.

I feel this lends itself better to helping and encouraging the reader towards a broader understanding of the era as a whole, by illustrating and encouraging exploration of the the different facets of the era as they relate to each other. in the end, we are all here to learn; not all of us are necessarily here as experts on a given topic. for myself, I find this structure helps my own learning to progress, so I hope others find it helpful as well. I appreciate everyone's comments. thanks. ---Sm8900 (talk) 🌍 14:36, 4 January 2022 (UTC)

I recommend adding Journalism of Early Modern Europe, an article I significantly re-wrote. Santacruz ⁂ Please ping me! 15:08, 4 January 2022 (UTC)

Also wouldn't this discussion better happen within the History WikiProject? Santacruz ⁂ Please ping me! 15:08, 4 January 2022 (UTC)

@A. C. Santacruz:, I greatly appreciate the suggestion to discuss this at that wikiproject, and you are welcome to raise any part or all of this topic at WikiProject History.... especially since I happen to be the coordinator of that project!!! however, the wikiproject itself is only semi-active. but we would welcome your ideas, insights and input there!!

Re the article you cite, I will be glad to add that item to this navbox. thanks!! ---Sm8900 (talk) 🌍 05:02, 5 January 2022 (UTC)

Upload .CSV linked data to Wikimedia files

In the Summery section of the Wikimedia document there should be a way to upload linked data to a .csv file or .tsv file, so other people can update the data/graph/chart later. --Wikideas1 (talk) 06:46, 6 January 2022 (UTC)

You can upload it as mw:Help:Tabular data. There is a gadget that allows you to upload an entire csv to that. Or upload to commons archive and then link to it with Template:Source File location. —TheDJ (talk • contribs) 09:34, 6 January 2022 (UTC)

End of the Late modern period?

I would like to suggest an end date for the "Late Modern Period."

one problem with this, of course, is that the term "late modern" itself intrinsically suggests that it is still ongoing, as it is the "modern" period in which we all live. However, I would suggest that the "late modern period" was actually a period with a beginning and an end, and was typified by the great conflicts of the 20th century, starting with the Franco-Prussian War as a precursuor, and then of course World War I, World War II, and the Cold War.

I would submit that the "Late Modern Period" was succeeded by the "Information Age," which in fact is now the current period in which we all live. Obviously, one next step would be to find some published sources for this premise. equally obviously, clearly this is not a question that needs to be resolved immediately.

presumably, people may happen upon this question a decade or two from now. at some point, this question of delineating the "late modern period" from whatever comes next will in fact become more relevant. I am simply introducing this question for some initial discussion, if possible. I welcome any comments. thanks. ---Sm8900 (talk) 🌍 14:52, 4 January 2022 (UTC)

This seems in no way related to actually improving enwiki, and is a content discussion best had offwiki somewhere. Fram (talk) 14:59, 4 January 2022 (UTC)

Not entirely sure what relevance this has to the idea lab. We can't decide what labels are used, we must follow historians' use on a case-by-case basis. Santacruz ⁂ Please ping me! 15:06, 4 January 2022 (UTC)

This comment might have more appropriately been put on the talk page of this article. I would say that the period of history in which we now find ourselves is no longer the late modern period, but contemporary history. YTKJ (talk) 09:23, 7 January 2022 (UTC)

Split backlog drive?

Hi! There are hundreds of old split tags that need discussion or removal. Is it possible to do a drive to deal with them? It is immensely annoying to the eye when reading and quite sad when I see a single editor proposing a smart split in like, 2015 or something that got no response. Some months ago I dealt with a few dozen but there's just... many left. Santacruz ⁂ Please ping me! 13:26, 1 January 2022 (UTC)

Category:All articles to be split would be the category. There's about 350 from 2021 and over 400 from before this. A backlog drive on the pre-2021 discussions would be good. In lots of cases, it may be that more discussion is needed, but other resolutions would be somebody removing the split tag when unnecessary, or carrying out a split when uncontroversial. The problem is these often need extremely specialised attention: I'm not going to succeed in splitting Coexistence theory, for instance. Maybe there could be a month-long backlog drive and for those that are not dealt with, an appropriate WikiProject will be (manually) notified (in bulk, with a list of all items that are under their scope).

WikiProject Cleanup might be the projectspace place to host a backlog drive, but it'd need good noticeboard advertisement. — Bilorv (talk) 17:39, 1 January 2022 (UTC)

Bilorv I agree with the points you've raised, and appreciate your input here :).Santacruz ⁂ Please ping me! 18:30, 1 January 2022 (UTC)

If the older split tags are old enough, and especially if the tagger didn't offer any edit summary or talk page discussion to go by, or the article is small enough, you should just remove the tag as 'stale'. I see you tried to restart the 5-year-old Trini Lopez split proposal; I would have simply removed it. The article is small and the section (that was proposed to be split out) has hardly been changed in 5 years. Platonk (talk) 00:51, 2 January 2022 (UTC)

Narky Blert used to bring lists of pages with disambiguation problems to Wikipedia talk:WikiProject Medicine to ask for help (example). You might be able to coordinate something like that, to encourage the more active WikiProjects to clear out the older items. Wikipedia:WikiProject Medicine/Article alerts#SPL lists 12 open split proposals among the articles tagged by WPMED, and there may be a couple more that it considers too old to list. WhatamIdoing (talk) 20:39, 4 January 2022 (UTC)

That's a really cool type of post, and especially helpful for certain types of articles. From my experience most of the old split tags are in 3 categories: BLPs, Science, and Sports. AFAIK the 3 relevant WikiProjects are quite active, so perhaps this is a better way of going about cleaning the split backlog without needing to organize a drive, at least at first. However, seeing as there are 768 articles with split proposals I'm not sure what the best way to go about doing this would be. Thanks for bringing it up, WhatamIdoing! Santacruz ⁂ Please ping me! 11:37, 5 January 2022 (UTC)

@A. C. Santacruz, I'd suggest that you look at the oldest (e.g., in Category:Articles to be split from November 2015, Category:Articles to be split from July 2016, Category:Articles to be split from August 2016, and Category:Articles to be split from November 2016) and see if you can find people to resolve just those few. In that process, I think you'll learn a bit about what does/doesn't work. WhatamIdoing (talk) 19:35, 7 January 2022 (UTC)

Accessibility preference to disable the Wikipedia dropdown toolbar

See: Wikipedia:Help desk#How can I disable the Wikipedia dropdown toolbar? I will update this link when the thread is archived.

The Wikipedia main page does not have a dropdown toolbar when you scroll down from the top of the page. But most pages on Wikipedia do have it. For example:

Help:Contents.

We need a preference that eliminates that dropdown toolbar. It takes up too much usable space on my screen. Especially since I often have the font zoom bar setting on Firefox at around 150%, 170%, etc.. Which makes that toolbar even larger. So it is an accessibility issue too.

This CSS snippet could be made into a preference:

.vector-sticky-header{
  display: none !important;
}

See:

• https://wiki.riteme.site/wiki/User:Timeshifter/vector.css

I wish it was a preference, or a gadget. Many people would benefit. It's an accessibility setting. Discussion? --Timeshifter (talk) 12:22, 8 January 2022 (UTC)

Could the Wikipedia homepage be more random?

I haven't posted a message here or anywhere else on Wikipedia before. I love Wikipedia. I use it all the time. I particularly like the daily-updated homepage, which it is my ritual to look at while having lunch. However, I have noticed that in the did you know snippets (my favourite part) there are recurring themes (featured themes perhaps) for instance, lately, US radio stations and Missouri military history. In general, the did you knows, appear to be US-heavy. Presumably the did you knows are chosen/put forward by individuals. I was just wondering if it might be better (and possible) to generate these snippets randomly. It is the randomness and triviality that I like, as I find myself suddenly becoming interested in something far-removed from my knowledge, and going off at tangents. Would such a development be in the interests of other users? Whilst appreciating the news items are chosen (somehow) by significance, and are arrived at via media/politics-based decisions (and not my interest) I would also like to see the featured articles, the on this days, the anniversaries and the featured pictures, being random. I dare say, the very concept of randomness needs to be defined, is something which has different connotations to different people, and can be arrived at in different ways. Also, I have no idea how snippets could be plucked from an article. I'm sure software could be programmed to pick out several of the six million odd articles, but maybe it couldn't isolate something suitably bite-sized that could be put in the format of did you know...? — Preceding unsigned comment added by AdrianKeefe (talk • contribs) 12:44, 12 January 2022 (UTC)

AdrianKeefe if you like the snippets, one thing you can always do (and which I do from time to time) is go through the DYK archives and click on random dates. It's not totally random, but it does provide that sense of exploration that one would find cool. Note that DYKs are not only put forward by individuals, but also each day is curated for various reasons (not having too many DYKs of a single topic on the same date, specific DYKs nominated far in advance for specific dates, etc.) and so I think making it automated would probably not be very benefitial. I strongly encourage you to participate in the nomination of DYKs, if you wish. You don't need to create tons of content, just finding suitable articles and interesting facts is all you need. A. C. Santacruz ⁂ Please ping me! 12:57, 12 January 2022 (UTC)

You might also want to check out this page I made. Every time you purge the cache on this page, a different set of DYK hooks from a random date between 2005 and 2021 will appear. It's like browsing the DYK archives in the way that Santacruz described but with minimal clicking involved. —GMX^{(on the go!)} 17:28, 12 January 2022 (UTC)

That page is in a near-complete state, and now I have the strong urge to to make a Main Page design with randomized parts. —GMX^{(on the go!)} 20:25, 12 January 2022 (UTC)

• The desktop menu has a Random article entry so you can just use that. I tried this just now and got Ogden Tweto; culptural composition "Egyptian Pyramid"; and Benedikt Lampert. The latter is a weak stub but the others seem fine as random selections.

The iPhone app has a different style of main page. This is a scrolling selection including:

• Featured article
• Top read
• Picture of the day
• On this day
• Random article
• Places near

So, as well as the desktop main page items, you get some others including a random article each day. These seem to be filtered so that only articles which have pictures are shown and this helps cuts out the more boring stubs.

But if what you really want are oddities then the page you want is WP:WEIRD...

Andrew🐉(talk) 13:15, 12 January 2022 (UTC)

• User: Adrian_Keefe, are you talking about Wikipedia: Main page? You say that the "Did you know" snippets on Wikipedia tend to be U.S.-heavy, but that could be an aspect of Wikipedia that applies to all of Wikipedia, not just Wikipedia: Main page. I suspect that if one went through ALL of Wikipedia, one would find a bias to articles to do with North America, western Europe and Australasia. If one compares the article on Donald Trump with some past state leaders of India, you may not be surprised to see which one is longest. You may like to look at the article Racial bias in Wikipedia. YTKJ (talk) 14:29, 12 January 2022 (UTC)
• It's always wonderful to hear thoughtful feedback from readers, as many of us editors tend to get so absorbed in our various processes that we forget what the experience of casual readers actually is, so thank you for coming here and sharing, AdrianKeefe.
  To give you some background info, to appear in the Did you know (DYK) section of the Main Page, an article needs to be newly created, newly expanded, or have newly passed a good article review process. An editor (typically the primary editor who wrote the article) can then nominate it to appear, and after some feedback, it's usually approved, assigned a date/slot by a DYK coordinator, and runs. As a rule of thumb, the coordinators try to have no more than half the blurbs on the Main Page at a given time be U.S.-related. However, you're still going to see some topics popping up a lot, since some individual editors who are interested in certain subject areas have a habit of nominating their articles for DYK, which leads to a lot of appearances on those topics. These areas will reflect Wikipedia's systemic bias, which is unfortunate.
  The process for Today's Featured Article (TFA) is different. When we say "featured article", we don't mean it in the sense of "random article we decided to feature today"; rather, we're referring to a specific quality assessment, featured article-class (FA-class), which is currently given to only 6047 articles out of Wikipedia's 6 million, roughly 1 in 1000. To reach this status, articles need to undergo an extremely thorough peer review process (for instance, the combined length of the reviews for one article I recently improved to FA class reached 40,000 words, equivalent to about 80 pages). So there's a much more limited pool there, and it also unfortunately reflects systemic biases toward certain topics (many of which are comparatively easier to write about at an FA level, such as weather events).
  I think we need to do a much better job of communicating these processes to Main Page readers. For instance, we used to say something like "From Wikipedia's newest content" above the DYKs, but we took it out several years ago, and I've been waiting for someone to propose that we restore it. I also think we need to more actively prioritize interesting content readers will be most likely to appreciate, rather than prioritizing editors who wish to see their work featured prominently. Cheers, {{u|Sdkb}} ^talk 22:17, 12 January 2022 (UTC)

Showing user hostnames for anonymous users.

A large source of vandalism comes from school devices on school networks. Currently, there is no way for a school to identify which students are vandalizing the website, which gives me an idea. Many schools include student names or student id codes in the hostname of school devices (Such as 21-John-Doe, etc). If we included user hostnames in the edit logs alongside ip addresses, this could give some schools the ability to cut down on vandalism. I don't see this as a violation of privacy as this information is available to any website you visit anyways. Elijahr2411 (talk) 01:44, 15 January 2022 (UTC)

If an organization like a school wants to identify which of their clients used one of their IP's to connect to us, they can use their own logs for that already. — xaosflux ^Talk 01:51, 15 January 2022 (UTC)

Wait, so schools are sharing the full names of children with random strangers on the internet?! I did not know this, but I guess it shouldn't surprise me. But yes, that's a "violation of privacy" even if we aren't the ones doing it. We should not make the problem worse by storing this (possibly ephemeral) information in a permanent and widely-mirrored log.

The point is moot, however. See meta:IP Editing: Privacy Enhancement and Abuse Mitigation which is coming whether we like it or not. Suffusion of Yellow (talk) 04:25, 15 January 2022 (UTC)

Damn, I forgot the possible impact of this on our ability to do school blocks. Doug Weller talk 09:28, 15 January 2022 (UTC)

I should have looked first, it appears this may be taken into account. Doug Weller talk 09:29, 15 January 2022 (UTC)

At this point, these changes are up to the WMF with the feedback they receive following the roll-out. Very little up to us at the moment. We'll see what happens post roll-out with this school issue, and give the appropriate feedback then. Curbon7 (talk) 04:48, 15 January 2022 (UTC)

Elijahr2411, Suffusion of Yellow, I don't think hostnames of devices are included in http requests anyway, but correct me if I'm wrong. School devices are probably typically behind a Network address translation router or school VPN. Even if you could obtain hostnames that information wouldn't be legal to publish without permission. The school IT staff may be able to identify users, but not us. — Alexis Jazz (talk or ping me) 00:17, 17 January 2022 (UTC)

Allow Nutshell template be used on articles

I'd like to see {{nutshell}} templates to be partially allowed to be put on articles (main namespace), for concise summary about this topic on top of articles. 36.74.41.108 (talk) 15:58, 20 January 2022 (UTC)

Are you aware that the opening paragraph of any article is supposed to consist of just the sort of concise summary you are suggesting? (See: WP:MOSLEAD for more). Other than placing that leading text in a template, how is your idea different from what we currently do? Is there a benefit to placing it in a template? Blueboar (talk) 18:55, 20 January 2022 (UTC)

@Blueboar: This IP appears to just be using the {{nutshell}} template to vandalise, e.g. "Grand Theft Auto VI has been cancelled due to political correctness" on Social Credit System. [5]. I've reported at AIV. 192.76.8.73 (talk) 20:23, 20 January 2022 (UTC)

Universal notice for draftspace

Tracked in Phabricator
Task T6469

One of the hallmark characteristics of the draft namespace is that it is not rigorously patrolled. As anyone who ever done AfC patrolling knows, it has a lot of junk. Because of this, and also just because it's not part of the encyclopedia proper, we don't index it for search engines.

However, it's still not too hard for readers to stumble into it. For instance, if you go to a redlink for a page with a draft but no article yet (example: Cleo Abram), you'll be pointed to the draft. It's also possible for someone to share a direct URL to a draft off-wiki. And if reader does come across a draft, there's nothing really there to tell them what it is and to give them relevant disclaimers.

Therefore, I think it might be a good idea to add {{Draft article}} to the space permanently as an interface element (i.e. it'd be outside the wikitext). I also think we could improve the notice to tell readers This is a draft encyclopedia article. It is not yet part of the encyclopedia and has not been reviewed for compliance with Wikipedia's editorial standards.

Thoughts? {{u|Sdkb}} ^talk 23:27, 12 January 2022 (UTC)

I strongly agree with improving the notice. I also think that it would be a good idea to add {{draft article}} to the Draft space, especially for less wiki-fluent (I struggle to find the particular word I mean right now) visitors that may stumble upon a draft article and assume it is a mainspace article. A. C. Santacruz ⁂ Please ping me! 23:55, 12 January 2022 (UTC)

@Sdkb: where exactly do you want to insert this? I'm strongly opposed to hacking it in via the sitenotice and phab:T6469 was declined. — xaosflux ^Talk 00:05, 13 January 2022 (UTC)

@Xaosflux, I'm not sure—I don't know much about that technical aspect of Wikipedia (that's what I depend on editors like you for ). I see in that phab ticket that it was declined because there wasn't a strong use case, so if we found consensus for this, perhaps we'd revive that ticket and try to push it through. {{u|Sdkb}} ^talk 00:11, 13 January 2022 (UTC)

@Sdkb: meta:Community_Wishlist_Survey_2022 is open for proposals right now - so if you want to get a new piece of code (in this case "namespace notices") created for mediawiki in general, it could be the chance to propose that T6469 gets revisited. — xaosflux ^Talk 00:40, 13 January 2022 (UTC)

I have re-opened it and filed a patch. – SD0001 (talk) 18:41, 13 January 2022 (UTC)

@SD0001: thank you, I'm fairly supportive of putting something useful in a ns-118-notice (and maybe some other ns's, certainly not 0!) — xaosflux ^Talk 19:08, 13 January 2022 (UTC)

Awesome, thank you! Enterprisey (talk!) 05:40, 21 January 2022 (UTC)

Untighten rules on citing sources

I've seen that to create an article, you have to cite TENS of HUNDREDS of sources. I find this very difficult to work around because if you make even ONE edit without citing a source, it gets trashed and forgotten instantly. Because of this, it can sometimes be difficult to create articles without it being rejected for not citing enough sources. Maybe we can slightly untighten the rules on citing sources? (i.e. maybe like lowering the number of sources required to be cited?) CertifiedAmazing2 (talk) 02:18, 21 January 2022 (UTC)

P.S. The reason I ask this is because in a lot of articles, I find sources cited in nearly EVERY SENTENCE! Do we really need to cite THAT many?

@CertifiedAmazing2: Because of all the hyperbole in your question it's not clear what you are actually asking about, but it looks like you might have misunderstood the policies on verifiability, notability, and reliable sources. Drafts with only one or two sources can be declined for having (literally) too few sources. But it is much more common for drafts to be declined for "not enough sources" because there is a significant amount of information that has no source at all or that is only sourced to non-reliable sources; this can often happen with drafts that have half a dozen sources or more, because the draft creator believes it's all about the number of sources. As for your PS, there is often no need to cite a source for every single sentence in an article – but it is important that all the information is sourced. For instance, if an entire paragraph in an article summarises information from one source, that source only needs to be cited once for the paragraph. (Though if a paragraph summarises information from different pages in the same book, there should be citation markers showing which pages support which info.)

There are three principles involved. One is notability: to show that a topic is notable it's usually necessary to show that multiple people who are not connected to the topic have written about it, and that's why a draft with one or two sources will often be declined with a request to include more sources. Second, verifiability: information with no source at all can't be verified by Wikipedia's readers. Third, reliability: one or maybe two reliable sources will usually be enough to verify any particular piece of information in an article, and having five, or ten, or even more citations lined up after a sentence is very often a sign that the sources say more or less the same thing, or that some of them aren't actually relevant. So for notability, you need quantity – but "quantity" rarely means more than three; for verifiability and reliability you need quality. --bonadea contributions talk 08:17, 21 January 2022 (UTC)

Theoretically, drafts are supposed to be accepted if the page is WP:LIKELY (≥50%) to be kept after a trip to AFD. Theoretically, pages on notable topics are supposed to be kept if the subject is notable, even if zero sources are cited in the current version of the article.

In practice, I've occasionally seen editors decline drafts for anti-policy reasons (e.g., the use of WP:NONENG sources) or to push editors to expand the article past a stub. I think in some cases, editors are afraid that if they accept a policy-compliant but short/ugly article, they will be accused of having low standards, encouraging self-promotion and spammers, etc. The standards ratchet ever higher, especially for BLPs and organizations. WhatamIdoing (talk) 17:56, 21 January 2022 (UTC)

Redesigning and simplifying the English Wikipedia website

I would like to start a discussion on redesigning the English Wikipedia website. I'm not sure if the WMF would need to get involved with this. Here are some design changes I would like to see and would like to know your thoughts on them. To start, I would like to see the sidebar's contents be moved to the top of the page as menus and be replaced with the table of contents of a particular article. Britannica does it best there with its articles (example). I would also like to see the main page to be redesigned. Since the 2006 design, the design has changed very little and I think the main page is due for a redesign. Britannica also does good here with this factor with its modern look. The current main page is dated and I was hoping we could make an RFC on what we could do to make it more user friendly. I would appreciate any comments about where to start with how we can simplify and redesign the Wikipedia website and the main page. Interstellarity (talk) 23:04, 25 November 2021 (UTC)

@Interstellarity: have you tried the "new vector" interface? — xaosflux ^Talk 00:36, 26 November 2021 (UTC)

@Xaosflux: No, how do I access it? Interstellarity (talk) 01:29, 26 November 2021 (UTC)

@Interstellarity: in Special:Preferences#mw-prefsection-rendering select the skin "Vector", uncheck "Use legacy vector", check "enable responsive mode". You should be able to tell you are in it if you can collapse the left sidebar. — xaosflux ^Talk 02:26, 26 November 2021 (UTC)

Hi Xaosflux,

While I think this is an improved version of the old vector design, I think it could be improved by moving the sidebar's controls into tabs like most websites do. I think for articles, instead of placing the contents in the article, they should go where the sidebar's current controls are. I think if you want to navigate from one section of an article to another, you would have to scroll up to the contents to go where you want to go. If the contents were on the sidebar, it would be a lot of easier to navigate from one part of an article to another. These are my ideas of how to make the user interface of Wikipedia more user friendly. Interstellarity (talk) 16:09, 26 November 2021 (UTC)

@SGrabarczuk (WMF): Do you have any mockups or wireframes related to the upcoming proposals? Whatamidoing (WMF) (talk) 19:51, 6 December 2021 (UTC)

Workspaces

What about if editors could rearrange the window as workspace. If you edit a page the page appears on the left say, the talk on the right, and the history at the bottom. Wakelamp d[@-@]b (talk) 08:56, 26 November 2021 (UTC)

@Wakelamp, I'm thinking about integrating something much like this in meta:Teyora, so keep your eye out for its release :) ✨ Ed talk! ✨ 22:29, 10 January 2022 (UTC)

COOL!!! Wakelamp d[@-@]b (talk) 06:48, 23 January 2022 (UTC)

Just in case you haven't seen it yet, take a look at mw:Reading/Web/Desktop Improvements. It doesn't directly address your point, but if you're interested in site redesign, it's a good place to catch up on what others are doing. -- RoySmith (talk) 13:38, 20 December 2021 (UTC)

I would like to continue the discussion before this gets archived. Does anyone have any thoughts on how to structure the Wikipedia page? Interstellarity (talk) 15:28, 19 December 2021 (UTC)

I think having the table of contents always be easily accessed would be a useful navigation feature. Having it always-visible on the left makes WP comparable to other hierarchy-index+content UIs, such as Microsoft Outlook's mailbox view. Two features that could be added--one easier, one harder--are to have the items in it be collapsible (as is common in tree view UIs) and to have the currently-visible section gets highlighted on it (so one can keep track of one's place in the scope of a long article or long section). Some browsers have a "scroll-to-top" feature but others do not. Adding it as a universal UI button to mediawiki has been proposed before, such as MW:Reading/Web/Projects/In-page Navigation, and there are various local implementations ({{Skip to top and bottom}} and {{Top of page}}, for example). I thought there was a skin feature or gadget for that, but I can't find it in my preferences at the moment. And there is consensus not to use these templates in mainspace in a one-off manner, specifically because they are not universally deployed, though they are usable (and used) in other namespaces. DMacks (talk) 19:00, 19 December 2021 (UTC)

I saw some early work by @AHollender (WMF) on making the TOC always visible earlier this month. You may get what you wish for. :-) Whatamidoing (WMF) (talk) 23:55, 20 December 2021 (UTC)

@DMacks, @Whatamidoing (WMF): Have you seen this prototype? ― Qwerfjkltalk 09:50, 22 December 2021 (UTC)

@Qwerfjkl I think that design improves the page, but I think it would be better if the sidebar controls were at the top of the page rather than on the left of the page. Britannica does a good job at this. When comparing the two, Wikipedia looks more dated and Britannica is more modern. Interstellarity (talk) 14:13, 22 December 2021 (UTC)

@Qwerfjkl I hadn't seen that, but that's exactly one of the ways I was envisioning. +1! One technical nit is that when I "<<" to collapse the TOC, the old-style control-panel appears in the left column instead rather than actually collapsing the left column altogether. DMacks (talk) 06:09, 23 December 2021 (UTC)

@Interstellarity: archiving is based on elapsed time since the last comment, not the thread's location on the page. DMacks (talk) 22:11, 19 December 2021 (UTC)

Hello, you may try the mobile view on desktop computers. --NaBUru38 (talk) 17:43, 27 December 2021 (UTC)

(Late comment)- Not really sure if we need a redesign of entire interface, we already have more interface options in our "preferences". But I generally agree that Main Page needs a revamp, and look relatively modern. It's Wikipedia's very first page and it frankly doesn't look great, it looks a little outdated and boring even. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 18:25, 20 January 2022 (UTC)

@CX Zoom, if you are interested in Wikipedia:Main Page design, then you might be interested in looking at the su: and se: Wikipedias. These are both small Wikipedias with modern, professional-quality designs for their Main Pages. Whatamidoing (WMF) (talk) 19:26, 20 January 2022 (UTC)

su: has accessibility issues. --Redrose64 🌹 (talk) 21:48, 20 January 2022 (UTC)

Why should we just copy Britannica's interface? We're not Britannica, we're Wikipedia. X-Editor (talk) 00:21, 22 January 2022 (UTC)

Notice on talk page that the subject does not run their Wikipedia article

I find Template:Not a forum insufficient for this purpose. I've encountered instances of people reaching out to foundations, philanthropists, and politicians seeking aid (and posting personal info). There should be a specific template still does not exist.Hariboneagle927 (talk) 02:32, 20 January 2022 (UTC)

Can you explain more about what aid they are asking for? And also do the people they are asking to help do anything? I assume this is not editathons) Wakelamp d[@-@]b (talk) 06:53, 23 January 2022 (UTC)

A direct example would be Raffy Tulfo who runs a radio program where he helps people deal with their legal troubles by putting these people's issues on the limelight which would in theory would force the appropriate authorities or figures to take action. Some financially troubled folks would also received donations from Tulfo's team on his program. Lots of people would then reach out on various platforms to get a chance to get featured in Tulfo's program.

I imagine they would reach out to him through Facebook, public tweets, and yes even his Wikipedia talk page. Raffy Tulfo of course does not run his article himself, so nothing really happens. But some IPs have posted personal information like their contact info which is something that should not happen. It would be helpful if there is an explicit message on the talk page saying the subject is unaffiliated with the subjectHariboneagle927 (talk) 07:10, 23 January 2022 (UTC)

Converting WP templates on redirect?

Would it make sense for a bot to automatically convert all WikiProject templates to the redirect form when its article is redirected? I.e. either comment out the 'class' and 'importance' options, or set them to 'redirect' and 'na'. That would reduce maintenance on those templates. Praemonitus (talk) 22:40, 19 January 2022 (UTC)

It should not be necessary to set |class=redirect explicitly - if omitted or left blank, it's autodetected. Then, if the redir becomes an article again, it'll automatically revert to Unclassified. --Redrose64 🌹 (talk) 16:54, 20 January 2022 (UTC)

@Redrose64: Yes, I do know that. However, when an existing rated article is converted to a redirect, that update to the WikiProject templates usually does not happen. It is necessary to go through manually and check for these. I'd rather have a bot take care of it. Praemonitus (talk) 19:30, 20 January 2022 (UTC)

@Praemonitus, I think this is a good idea. You'd want the bot to run periodically (once a week might be enough) and to run both directions: Add |class=redirect for pages that are now redirects, and blank it to |class= when a redirect is turned into an article. I've once or twice gotten a list of mis-classified redirects for WPMED and fixed them by hand. It would be better to have a bot make such adjustments. WhatamIdoing (talk) 18:00, 21 January 2022 (UTC)

@WhatamIdoing: Good point. Usually I fill in the WP template when I expand a redirect, but it would be easy to forget or just not be aware. Praemonitus (talk) 18:39, 21 January 2022 (UTC)

@WhatamIdoing: Other than {{WikiProject Military history}} (which doesn't autodetect redirs), under what circumstances would it be better to set |class=redirect explicitly than to leave it blank? --Redrose64 🌹 (talk) 11:45, 22 January 2022 (UTC)

There are advantages to having the tag on redirects (e.g., so anyone watching the Wikipedia:Article alerts pages will get notifications about RFDs). The main problem with having the tag without a class is that it will clutter up Category:Unassessed articles. That makes it harder to find articles that need assessment. If you don't want |class=redirect, then it would be possible to use |class=NA ("not an article") instead. WhatamIdoing (talk) 18:34, 22 January 2022 (UTC)

No it won't clutter up Category:Unassessed articles. As I said, if the talk page of a redirect has a WikiProject banner (other than milhist) that lacks a |class= parameter, or has it present but empty, the page is automatically assessed as Redirect-Class. See for example Talk:Albert Hall tube station (|class= present and blank) or Talk:1976 Shippea Hill railway crossing accident (|class= absent). Neither of these is in any subcategory of Category:Unassessed articles: both are in Category:Redirect-Class rail transport articles and Category:Redirect-Class UK Railways articles. --Redrose64 🌹 (talk) 20:28, 22 January 2022 (UTC)

It works in a similar manner with categories, I believe. Praemonitus (talk) 17:08, 23 January 2022 (UTC)

This is Wikipedia:Bots/Requests for approval/EnterpriseyBot 10, but it runs sorta slowly. I guess I should make it run faster. Enterprisey (talk!) 23:10, 21 January 2022 (UTC)

I'm not sure that speed really matters. WhatamIdoing (talk) 18:35, 22 January 2022 (UTC)

I'd say it's a low priority, labor-saving task that's convenient for the WP's, so no need to tied up excessive resources. Praemonitus (talk) 22:19, 22 January 2022 (UTC)

idea or question re categories for "templates" versus categories for "navigational boxes"

we have a set of categories for templates that are used to provide content and links pertaining to specific topics; in other words, for templates that are actually navboxes, but are referred to in the name of the category as "templates," such as Category:Country templates, and then we have a whole set of categories which are also purely for nav boxes, and which do indeed refer to them correctly as "nav boxes"; such as Category: Country navigational boxes.

there are dozens if not hundreds of examples of this, of course; so I am not suggesting that we go back and try to sort through hundreds of categories and rename them or modify them in any way. there is no way to do so, it's not worth the effort, and this whole distinction is not so simple or easy to implement retroactively, anyway.

I simply wanted to ask, is there any possible rule, guideline, help page, etc that we might want to think about for the future, in order to guide editors to use the term "template" to refer to technical templates like talk page notices, citation labels, etc, and emphasize that navigational boxes should be referred to as "navigational boxes" in category names, in order to make a clearer distinction?

I'm deliberately posting this on the idea lab, to acknowledge that this is not a major problem in any way, but I'm open to ideas. thanks. ---Sm8900 (talk) 🌍 21:13, 24 January 2022 (UTC)

Concern about Pro-Vegan and Pro-Animal Rights Bias

I've noticed a... troublesome running thing about pages pertaining to animals, animal agriculture, and animal agriculture...

So I was on the Beef page and noticed that the page claimed that beef (and meat in general) have a huge negative environmental impact and make up most greenhouse gas emissions and would significantly reduce greenhouse gas emissions if everyone stopped eating beef and meat in general. This claim has proven to be exaggerated and animal agriculture only makes up about 5% of greenhouse gas emissions [[6]][[7]]. Multiple sources used in the article clearly had a pro-vegan bias.

Now that's just one article. But I went looking further and found some more... disturbing pro-vegan and pro-animal rights biases on tons of pages...

Ethics of eating meat, Carnism, Psychology of eating meat, among tons of other articles, clearly have an agenda on pushing veganism and animal rights, plus PETA is often used as a source despite the fact that the organization has actively been involved in misinformation campaigns (such as the "milk causes autism" thing). Then I found the WP:Animal rights project, ostensibly meant to educate readers about the concept of animal rights, but the people in the project seem to have an agenda. WP:ADVOCACY and WP:NPOV comes to mind in regards to this. — Preceding unsigned comment added by Greyhound 84 (talk • contribs) 04:30, 25 January 2022 (UTC)

@Greyhound 84 This is better discussed at WP:NPOVN. – SD0001 (talk) 13:42, 25 January 2022 (UTC)

QR Code

I am Masoud from Iran. I would like to share my interest about something that might be helpful for the Wiki website and Wiki users. I would suggest you have a QR code for every piece of information you have collected or will be collected. For example, considering "Toy" is my target, the Toy should have a QR code which connects you to the Wiki link belonging to the searched word. In addition, this QR code would be labeled on the real Toy we may see on the markets which can be scanned. It is just a theory and needs to be developed. Thank you in advance. — Preceding unsigned comment added by Massam6367 (talk • contribs) 06:29, 22 January 2022 (UTC)

@Massam6367: See QRpedia. --Redrose64 🌹 (talk) 13:23, 22 January 2022 (UTC)

So basically, anyone is welcome to put links to our articles, including by QR codes, anywhere they want - we don't have to do anything here to empower that. — xaosflux ^Talk 16:37, 25 January 2022 (UTC)

Multiple Timelines

I am trying to understand the sequence of major technological advances, and when they occurred in history. It occurred to it would help to have a timeline. I found this discussion about timelines, but the link is dead..

I suspect that all sorts of timelines would be helpful, for any discipline, for any country, for any war or historical movement, or for any company or organization. BooksXYZ (talk) 17:06, 14 January 2022 (UTC)

References

You can try entering Timeline in the search box. Near the top of the list in the results is Timeline of historic inventions. There apparently are 131,624 articles in the English Wikipedia with "Timeline" or "Timelines" in the title. - Donald Albury 18:14, 14 January 2022 (UTC)

A while back I stumbled upon one or two templates for timelines, but nothing like the tool that was mentioned at that link. I think the templates for diagramming railroad / subway lines are farther along than timelines, sadly. Perhaps the folks at Wikidata might have more insight on possibilities for this sort of thing? Jim Grisham (talk) 14:15, 27 January 2022 (UTC)

Systematic tracking and analyzation of sock bans

A few weeks ago, I asked the SPI clerks if they formally track and document every sock-related ban. Below, a link to that discussion.

Seeking statistics for SPI investigations/confirmations

To my surprise, no one was aware of any such process. Sock-related bans aren't systematically tagged and processed for future analysis. As such, we really have no idea what is going on with sockpuppetry on Wikipedia.

If the decision makers on Wikipedia aren't aware of the volume of sockpuppetry, it's unlikely they'll ever react to it. We have to know how much sockpuppetry is actually occurring in order to effectively respond to it.

Graciously, Tamzin (talk · contribs) was able to provide me with the closest thing to actual statistics on the number of bans. She created these charts by hand, and while they aren't official, she says they're the best we can get, at this point.

Year	Sockblocks
2004 (23 Dec. onward)	35
2005	3336
2006	13237
2007	20482
2008	28487
2009	25457
2010	26384
2011	24257
2012	21689
2013	21983
2014	22631
2015	29768
2016	35668
2017	38451
2018	37020
2019	34222
2020	34055
2021	45479

Year	All sockblocks	Non-sleeper sockblocks	Non-sleeper percentage
2004 (23 Dec. onward)	35	28	80
2005	3336	2368	70.98
2006	13237	8689	65.64
2007	20482	14296	69.8
2008	28487	16380	57.5
2009	25457	15323	60.19
2010	26384	16527	62.64
2011	24257	14369	59.24
2012	21689	11974	55.21
2013	21983	12895	58.66
2014	22631	14469	63.93
2015	29768	17618	59.18
2016	35668	20670	57.95
2017	38451	21893	56.94
2018	37020	20720	55.97
2019	34222	18669	54.55
2020	34055	17964	52.75
2021	45479	18682	41.08

Month of 2021	All sockblocks	Non-sleeper sockblocks	Non-sleeper percentage
1	3534	1541	43.6
2	2944	1319	44.8
3	2846	1527	53.65
4	2793	1438	51.49
5	3408	1820	53.4
6	3553	1609	45.29
7	8112	1529	18.85
8	4796	1617	33.72
9	3352	1574	46.96
10	3552	1749	49.24
11	4046	1615	39.92
12	2549	1343	52.69

Admittedly, I don't understand how Wikipedia's software works. So I am unfortunately unable to offer any ideas as to exactly how we could create an automated collection of this data. But I suspect such tools must be available. Wikimedia already knows how many people are editing Wikipedia, and how many edits they're making. So, how difficult can it really be?

All I know is that after 20 years, it's time to finally uncover the truth about sockpuppetry on Wikipedia.

As always, I appreciate your time and attention. - Hunan201p (talk) 15:01, 31 January 2022 (UTC)

Changing deletion-related theming from red to green?

After reading User:Ritchie333/How newbies see templates, I've got an idea for a proposal, but really don't know if it's a good idea or not. I feel like the red theming may negatively affect new users who get their pages nominated/tagged for deletion, speedy deletion, or proposed deletion, and that green theming may be a better choice. I would like to see what the rest of you think. ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 19:02, 31 January 2022 (UTC)

Green = Go, which means "you're doing the right thing". Red = stop, which means "You're doing something wrong". Red is appropriate. --Jayron32 19:05, 31 January 2022 (UTC)

It is the message rather than the colour of the template that has the negative impact. Phil Bridger (talk) 19:39, 31 January 2022 (UTC)

• I would favour nominations and warnings being in amber, actually - it gives the message of "caution" without coming off as negatively as red. A notice that a page has been deleted should remain in red. Theknightwho (talk) 20:31, 31 January 2022 (UTC)

I think the reason deletion messages are red or orange is because they are intended to grab attention. Neither green nor blue has the same effect as red when it comes to deletion messages. Users would then know which issues to fix, etc. Aasim - Herrscher of Wikis 20:45, 31 January 2022 (UTC)

Wikipedia Logan's Run

Looking at Encyclopedia Britannica over the decades, articles are occasionally wiped clean and rewritten from the ground up, old generations are retired and new take over via new editions. Wikipedia can do that too via incremental changes, but in practice if an article is already in pretty good shape and on a topic that doesn't change much, there usually isn't much effort to nuke it and start over. The inertia of replacing well done/sourced content is high. This is unfortunate as redoing from scratch can result in interesting new ideas and perspectives. A blank slate encourages creative energy. As such, Wikipedia's long-term prospects are it will become stale, ironically, as articles reach a higher level quality they change less frequently. (Some articles will be constantly changing.) A solution is a mechanism to retire candidate articles to an old folks home (Logan's Run Green Pastures) and clean slate the page for a new generation to have a go. This is not the same as incremental changes, rather a blank slate start over even though the content being replaced is largely fine. It's not the entire project or an unbending rule, rather those that have consensus to be "Loganized". The old article might be enshrined somewhere as a monument in recognition of its quality. The new article would be discouraged from sourcing from the old. -- GreenC 07:38, 26 January 2022 (UTC)

Would think the thing to do then would be really start over, with a brand new wiki named something else entirely (if you did it yourself, could call it GreenCPedia), with "no sourcing from Wikipedia" rule. Hyperbolick (talk) 08:41, 26 January 2022 (UTC)

Given how many articles there are which aren't in pretty good shape, even on very core topics, I think worrying about rewriting our few very high-quality articles is pretty low down most people's priority lists! Caeciliusinhorto (talk) 13:44, 28 January 2022 (UTC)

Not a worry rather an opportunity, for those interested in writing on a topic with a blank slate. Looking at it project-wide, in the same way we can have some articles that are nominated for FA without worrying about all articles needing to be FA. It's a per-article basis. -- GreenC 15:46, 28 January 2022 (UTC)

It is worth thinking about the motivations of editors past and present. The assumption behind your contributions being ruthlessly edited, is that if your work goes, it will have been supplanted by something newer and better. Deleting old but high quality articles on the assumption that others will rewrite from scratch ends that presumption in favour of keeping quality contributions and reduces people's motives to contribute. There's also the issue that creating a stub and establishing that there is space for a particular topic in Wikipedia is a task that most editors don't take part in. Most editors just improve or update existing articles, there is no guarantee that a missing article would be speedily recreated. Also we need to consider our readers,it isn't good for them for an article to disappear for a time eventually returning as something that might take a while to get to the same level of quality. Of course I do get the need to sometimes completely rewrite an article, but this can already be done in a sandbox with consultation withexisting contributors before replacing with a major rewrite. ϢereSpielChequers 15:30, 28 January 2022 (UTC)

No, unfortunately "Most editors just improve or update existing articles" isn't right - the majority of the small proportion of editors who make significant text edits at all do so to write new articles, mostly on subjects of diminishing importance. Generally I agree with Caeciliusinhorto. Johnbod (talk) 15:38, 28 January 2022 (UTC)

I think we have stats on this - 30% of new editors start by writing a new article and 70% start by improving one. Otherwise I can see it varies by area - DYK is obviously skewed towards people who start new articles. ϢereSpielChequers 14:00, 29 January 2022 (UTC)

On a somewhat related note, being able to avoid past baggage is why some of the concerns expressed about deleting articles in the draft namespace are less important to me. Some editors disagree with the deletion of unmodified drafts of promising subjects after six months, arguing that it would be desirable to leave a starting point. However, I think allowing a new interested editor to start anew may offer a better chance at avoiding the issues that caused the article to remain in a draft state. Yes, the editor could always do so anyway, but the whole collaborative Wikipedia ecosystem strongly encourages incremental editing. isaacl (talk) 21:36, 30 January 2022 (UTC)

What exactly does "interesting new ideas and perspectives" mean here? Care to provide an example? Dege31 (talk) 16:26, 31 January 2022 (UTC)

I would hope that one possible meaning would be the rewrite of many historical events after things get declassified under the 30 year rule or equivalent, or after the rush of obituaries and retrospectives that follow a notable death. However I'm not convinced that our biggest problem is in updating things that need updating. I'm more concerned that we have a bunch of alt med and pseudo science pushers and deleting a perfectly good article that was written by knowledgable but no longer active Wikipedians would open things up for a bad article to be written. The Logan's run proposal would mean that some good content was gone and the patrollers no longer had a good version to revert to. ϢereSpielChequers 16:38, 31 January 2022 (UTC)

Indeed, if an editor really thinks that it would be better or easier to rewrite an article from scratch than incrementally improve what was already there, then that is possible currently – I've certainly done that a few times! Caeciliusinhorto (talk) 22:57, 31 January 2022 (UTC)

Category for non-article pages with maintenance templates

Some non-article pages (mostly template documentations and Wikipedia namespace pages) has issues tagged with maintenance templates. It should be fixed soon just like the articles in the mainspace, but the problem is: it's not categorized like when the templates is placed in mainspace articles. If it's categorized, users can find non-mainspace pages with issues more easily. For some occasions (like few Wikipedia namespace pages with maintenance tags for illustration purposes, and humor pages which humorously using maintenance tags), an entire page or a tag should be opted out from categorization. Ijoe2003 (talk) 01:56, 2 February 2022 (UTC)

Protection of pages when put onto main page

Hello! I have this idea of protecting articles temporarily when they become a featured article on the main page as I noticed that usually articles that become featured quickly attract a lot of vandals and end up getting protected. I know Wikipedia tries to keep as many articles open to editing as possible, however when articles that become featured on the main page attract vandals and get protected anyways, it seems like it would be a good idea to retroactively apply protection to them when they become a featured article on the main page (and for that protection to expire when it gets moved off the main page). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:22, 3 February 2022 (UTC)

You can see previous related discussions about this at Wikipedia:Perennial proposals#Protecting Today's Featured Article on the Main Page. DanCherek (talk) 14:24, 3 February 2022 (UTC)

I'm seeing there was a trial for PC protection of featured articles. Do we know what the result of the trial was? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:27, 3 February 2022 (UTC)

See Wikipedia talk:Today's featured article/Archive 15 § TFA vandalism for more info. As of December 24, 2021, a bot was being worked on to implement a trial. isaacl (talk) 15:42, 3 February 2022 (UTC)

Interesting. I would help out with creating the bot but I would have no clue what I would be doing. GUess we should wait for the trial to happen before anything. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:46, 3 February 2022 (UTC)

Idea for an "Edit Wizard"

See User:Enterprisey/Edit Wizard design doc. I'll copy/paste a bit here:

The Edit Wizard is a proposed better edit request process. New editors will be guided step-by-step through building up an edit request.

There will be four workflows:

• Add Fact: Choose Source, Choose Quote (quote must appear exactly in source), Rephrase Quote (in your own words), Choose Place (for the new fact)
• Tag an Issue: Select Text (in the article), Choose Tag (Category:Inline cleanup templates), Choose Source+Quote (optional)
• Update Text: Select Text, Choose Source, Choose Quote, Rewrite Text
• Delete Text: Select Text, Choose Reason (irrelevant, incorrect (require source), misleading, redundant (require selection of other text))

Thoughts appreciated. Enterprisey (talk!) 07:23, 18 January 2022 (UTC)

@Enterprisey: as ER is a step wise process, do you have any samples of what the request output will be (what other editors will have to deal with)? These are often defective today. — xaosflux ^Talk 14:10, 18 January 2022 (UTC)

Have you seen Ed's code for handling {{fact}} tags? If memory serves, it's blocked on the two-parser problem, but it sounds like it would fit your goal. Whatamidoing (WMF) (talk) 00:12, 19 January 2022 (UTC)

I haven't thought much about that yet, but I don't think it'll be a difficult part of the project. We could start with a template sentence, like "Please insert the text '___' at this location '___'. It is supported by the quote starting with the words '___' from the website/book/journal ___". There will be as much detail as the user gave - . Possibly also a sample diff (copy existing text to sandbox, make edit, take diff). Where it gets interesting is that I want other readers to be able to offer feedback on the requests, perhaps by - gasp! - upvoting. @WAID, that sounds interesting and I haven't seen that. Would you happen to have a link? Enterprisey (talk!) 00:22, 19 January 2022 (UTC)

See phab:T211243 and phab:T225750. Whatamidoing (WMF) (talk) 01:01, 19 January 2022 (UTC)

Great idea. It would be worth creating a prototypical implementation. If it takes off it can later be made into a gadget (default-enabled on namespaces=1) or extension. – SD0001 (talk) 19:37, 21 January 2022 (UTC)

Thanks. I had a conversation with Legoktm about getting this deployed, because it'll need to do a bunch of API calls and HTML fetching that would need a server (e.g. fetching the HTML of a page to check if a chosen quote is actually from the page), and we concluded that it might be tough, but at least it's possible. Enterprisey (talk!) 23:11, 21 January 2022 (UTC)

Still a pure-JS prototype would be easier to have deployed for testing among real users. Server-side capabilities could be added as optimisations later. Couldn't the HTML fetches be done client-side? If a user is citing from a website it means they've already visited the site and trust it so there should be no privacy issue in making a cross-domain request. – SD0001 (talk) 06:40, 22 January 2022 (UTC)

Oh yeah, I expressed myself poorly. Yeah, the first prototype will certainly be pure-JS, just way down the line when this hits production it'll need a MW extension, which we all know isn't the speediest process. Enterprisey (talk!) 03:26, 23 January 2022 (UTC)

I made a Google Summer of Code proposal for this: T300454. If anyone wants to be listed as a mentor (*cough* @SD0001), let me know. Enterprisey (talk!) 09:14, 30 January 2022 (UTC)

@Enterprisey Happy to help with mentoring – I see there are already 2, so I'm guessing the time commitment would be light! – SD0001 (talk) 12:42, 30 January 2022 (UTC)

Strongly agree there should be some edit wizard. Don't agree with the exact workflows. What should be done IMHO is the user makes a wikitext edit, the edit gets noted, an {{edit protected}} is added to the talk page, the text to remove, change, or add is put down with the appropriate section with the reason, and then an experienced editor can either accept the change as is, make additional edits then accept, or reject the change. This could be a Wikipedia-exclusive script hosted on something like MediaWiki:Gadget-editrequest.js. This would work very very nicely and be extremely user friendly if implemented. Aasim - Herrscher of Wikis 20:53, 31 January 2022 (UTC)

Ah, I didn't explicitly state I was targeting new editors. Your proposed script should exist too, and I've certainly wished for it, but it's for experienced editors. New editors would still have a difficult time making the right change to the wikitext in the first place. My proposal's goal is to provide guidance for that part. Enterprisey (talk!) 06:42, 1 February 2022 (UTC)

Aasim's suggestion sounds like (plain) Wikipedia:Flagged revisions. Whatamidoing (WMF) (talk) 01:46, 5 February 2022 (UTC)

@SD0001 - yup, as light as you want. Feel free to add yourself in phabricator. I'd be happy to "take point" (running weekly checkins, keeping an eye on project requirements) so that any other mentors would be free to choose their level of time commitment. Although that's the default option, I'd also be happy to share that responsibility too :) Enterprisey (talk!) 08:11, 1 February 2022 (UTC)

I think this is a pretty great idea and I commend you for taking it on! Ganesha811 (talk) 02:16, 5 February 2022 (UTC)

Mass creation of articles

Idea: Editors wishing to mass create articles, whether manually or with the help of automated tools, must obtain a consensus from the community prior to doing so

It seems like a sensible measure; it adds minimal overhead to mass creations that are supported by the community, but will save a lot of time, both for the creator and those who are cleaning up afterwards, if it is not supported by the community.

I don't believe this is covered by any current policies, but I might be wrong. BilledMammal (talk) 04:24, 2 February 2022 (UTC)

Mass creation of articles with the assistance of tools is covered in Wikipedia:Bot policy § Mass page creation. Manual mass page creation at a speed similar to what would be done by bots is covered by Wikipedia:Bot policy § Bot-like editing. Prior consensus is not currently required for high-speed manual edits, though if there consensus against the type of edits, they can be treated in the same manner as bot edits (and so a new consensus in favour of the edits is required). isaacl (talk) 05:10, 2 February 2022 (UTC)

How many (manual) article creations a day would you consider to be "mass" creation? Jevansen (talk) 06:18, 2 February 2022 (UTC)

I think it is likely to be obvious when it is happening; though WP:MASSCREATION has a guideline "anything more than 25 or 50". BilledMammal (talk) 11:55, 2 February 2022 (UTC)

Would this include mass deletions as well? I've seen a couple of instances where a user deleted numerous pages for varying reason in one swoop and were given the stink-eye by other editors. Panini!^🥪 14:37, 3 February 2022 (UTC)

Deleting articles for non-CSD reasons without following process is an admin tools issue; we already have policies for that. BilledMammal (talk) 23:46, 3 February 2022 (UTC)

• Generally, “Mass editing” of any sort is considered disruptive. Large volumes of change can be overwhelming - and will often be rejected based on the volume rather than the merit of the changes. Eager editors can often achieve more by slowing down, taking more time and working in short chunks. Blueboar (talk) 01:16, 4 February 2022 (UTC)

• Such limits should be situational. I have used reliable databases to source the fast creation of several dozen articles on state supreme court justices for a given state. Howeer, I generally create these in draft space and then move them to mainspace at a more leisurely pace. I think that presents a possible solution. BD2412 T 18:03, 6 February 2022 (UTC)

Making all extended confirmed editors, pending change reviewers

I think once a user becomes extended confirmed the should have the ability to review pending changes. There's no special requirements to perform pending change task and sometimes the backlog can get bad, so this would help a lot. Iamreallygoodatcheckers (talk) 04:11, 4 February 2022 (UTC)

Pending changes reviewers should have a reasonable familiarity with guidelines and policy. This does not necessarily correlate with EC, although I do not know how admins treat the permission granting in practice. That said, when is the backlog that bad? It seems one of the most easily managed backlogs on Wikipedia, likely in part due to it appearing prominently on all reviewers' watchlists. CMD (talk) 04:57, 4 February 2022 (UTC)

Probably 95% of EC editors would be capable of pending changes reviewing. That's why PERM hands it out so freely. However, there is an aspect that PC reviewers commit to actually checking the other edits, while just giving PC to everyone might encourage someone to just press accept when their edit gets stuck behind something else in the queue. There is also the case of that 5% - some certainly couldn't be relied upon. As 'davis says, the status quo seems to be working fine --Nosebagbear (talk) 10:41, 7 February 2022 (UTC)

As someone that requested similar rights (rollback IIRC) while extended confirmed, but was denied, I personally believe that the fact one needs to request these rights is a good thing. If 95% of EC editors are granted PC rights, then I don't see a point in making them get PC automatically. I'd just see it as an increase in the risk of someone misusing the tools. However, there is some argument to be said that perhaps there are other ways to increase the visibility of PC rights requests that would lead to more people using these tools (such as displaying these prominently in the notifications editors receive when they achieve EC rights). I also wonder if increasing the visibility and use of these rights might encourage more editors to be admins in the future, which is something we desperately need. A. C. Santacruz ⁂ Please ping me! 10:50, 7 February 2022 (UTC)

Spoiler bar

I wounder if there could be some kind of spoiler bar that could be opened and closed, for movies, TV, and literature. — Preceding unsigned comment added by Mr.Lovecraft (talk • contribs) 15:51, 25 January 2022 (UTC)

• I think our readers expect that an encyclopedia such as Wikipedia will contain spoilers. So a notification is pointless. Blueboar (talk) 16:01, 25 January 2022 (UTC)

  @Mr.Lovecraft: its a reasonable idae, but has 2 issues: (a) see Wikipedia:Spoiler for recap of long running community discussions on that ; (b) we try to avoid any sort of hide/collapse in articles - as these technical features can be disruptive to some readers. — xaosflux ^Talk 16:34, 25 January 2022 (UTC)

Read WP:NOTCENSORED. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 19:57, 7 February 2022 (UTC)

Page Numbers

Moved from WP:AN

08 FEB 2022 It would be nice if page numbers appeared when the text of your article is printed or saved. It would also be nice if the date of retrieval was listed, but this is less important. You do a great job and I thank you. I contribute regularly to Wikipedia. — Preceding unsigned comment added by 2603:6080:6B00:2B00:DDCE:7446:84C5:A2B3 (talk) 13:46, 8 February 2022 (UTC)

A2B3, are you using Special:DownloadAsPdf - or the browser print function? — xaosflux ^Talk 16:36, 8 February 2022 (UTC)

WAV format

Not only WAV files automatically fail WP:NFCC#3b, they also go over one megabyte for minimally decent quality. Any more downgrading of a wav file would worsen its quality. Furthermore, I no longer think the .wav format is suitable for this project, especially when uploading non-free audio content. We already have ogg and mp3 as more preferable formats. WAV files are allowed on Commons but only for free content. I thought about proposing a technical blocking of newer uploads of wav files on Wikipedia. For some reason, I'm unable to upload WebP files locally here. Anyways, if successful, I may file a Phabricator task to implement this. Any other ideas about what else to do with WAV? --George Ho (talk) 23:01, 7 February 2022 (UTC)

I don't see how it fails 3b any more than an mp3 does. From an audio encoding perspective that makes no sense. —TheDJ (talk • contribs) 16:27, 8 February 2022 (UTC)

How does a non-free wav not fail 3b? From what I've seen, there aren't many non-free .wav files remaining. Rather the amount of them is under either fifty, thirty, or ten. How do you explain that? --George Ho (talk) 17:17, 8 February 2022 (UTC)

You say a WAV equals to being non-free (automatically as you say). I say some non-free files happen to be wav. That seems like a pretty substantial difference to me. —TheDJ (talk • contribs) 19:23, 8 February 2022 (UTC)

I don't understand this either. A lossy-compressed copy clearly satisfies 3b better than an uncompressed one (unless the latter has a really crappy sample rate). Nardog (talk) 17:26, 8 February 2022 (UTC)

I agree that we should be deprecating any use of WAV, but that's because lossless content should be uploaded as Ogg FLAC, or just FLAC. However, I disagree that using a lossy version satisfies 3b better than lossless: the issue is the length of the recording, and whether it's the minimum amount required to illustrate the point. We want to be able to do that in the best possible way. Uploading something in 64kbps mono wouldn't magically make it okay to have more of a non-free recording, after all, so the inverse goes for having lossless versions of anything that does fall under fair use. Theknightwho (talk) 18:25, 8 February 2022 (UTC)

Contrary to non-free wav files here, there are still bunch of wav files in Commons (use either c:Special:MediaSearch or c:Special:Search). --George Ho (talk) 18:51, 8 February 2022 (UTC)

I don't see why we should tell ppl what formats to use. Its hard enough already to add media files. And the transcoding pipeline will only serve back mp3/ogg for ppl anyway. Converting them manually to mp3s like George has been doing is just wasting storage by adding additional transcodes which ALREADY had been made. —TheDJ (talk • contribs) 19:21, 8 February 2022 (UTC)

Yeah, I agree that converting to MP3 is pointless - I hope we've not been getting rid of the lossless version as well, as that would be worse than pointless. Something in the back of my mind is telling me that Ogg and FLAC are preferred formats, but I can't remember why. Not that it matters much. Theknightwho (talk) 21:21, 8 February 2022 (UTC)

I'm... at loss of words. My replacing any wav (lossless) version with a lossy version is just time-wasting and pointless, right? Oh great. Now my rigid interpretation of WP:NFCC#3b is put into question. ...I hope you didn't mean that, right? --George Ho (talk) 21:29, 8 February 2022 (UTC)

I've already explained why I don't think it makes any sense under 3b, though: the issue is the length of the recording, and whether it's the minimum amount required to illustrate the point. We want to be able to do that in the best possible way. Uploading something in 64kbps mono wouldn't magically make it okay to have more of a non-free recording, after all, so the inverse goes for having lossless versions of anything that does fall under fair use. Theknightwho (talk) 21:34, 8 February 2022 (UTC)

Well 64kb mono would be something else perhaps (though I'd think you'd compromise the artist's artistic integrity by creating such a badly sounding derivative, which might also be a fair use problem). It's just that there is virtually no audible quality difference between most wav and an mp3s. MP3 is very good at compression or rather wav just doesn't do compression (only encoding) and wastes lots of bits. But users never get to hear the wav file after uploading, only the mp3. If you really try, maybe you'll find the 'original file' link, but.. who cares ? —TheDJ (talk • contribs) 09:05, 9 February 2022 (UTC)

Wait, the very old Special:Upload still allows WAV (and WebP), but the newer UploadWizard doesn't. --George Ho (talk) 23:07, 7 February 2022 (UTC)

It seems that MediaWiki:FileUploadWizard.js has a hardcoded set of allowed extensions. So that would indeed cause it to get out of sync with the actual allowed list of filetypes indeed. It should be fixed. —TheDJ (talk • contribs) 16:31, 8 February 2022 (UTC)

Well.... Please feel free to propose it if you wish as I did for mp3 and as I'm doing for webp and webm formats at Wikipedia talk:File Upload Wizard. However, I (or another editor) might oppose, or express my concerns about, adding "wav" to that Wizard out of my concerns that two of you don't see. George Ho (talk) 18:36, 8 February 2022 (UTC)

I ran into a very confusing comment by George Ho on the talk of an article I steward about this, and forgot to reply or look into it deeper. I'm happy I stumbled upon this, because it explains the matter is "one guy" rather than "a consensus I missed". Theknightwho, TheDJ, Nardog, it's worth making it clear George Ho is enforcing this on articles without any apparent discussion, which as TheDJ points out is creating unnecessary duplication. Vaticidalprophet 05:18, 9 February 2022 (UTC)

I don't know what I'm depicted as based on comments about me here. I think you made me feel guilty and look bad about my disdain toward WAV format. To reduce the risk of looking like a bad guy, I'll mention the files that I think you feel strongly for: File:Fifth Harmony - Write On Me.flac and File:Despacito by Luis Fonsi sample.wav. I PROD-ded them and replaced them with MP3. I thought about taking both WAV and MP3 files to FFD if de-PRODding happens, so the consensus can decide which one(s) to keep. I do feel strongly for FFD mostly because I'm unsure whether NFCC can allow non-free FLAC/WAV files. But maybe you want me to have the MP3 files deleted without FFD and shorten the length of a FLAC file, right? I just am wary about reducing its quality without ruining it too much. Don't worry: I saved the master copies of the samples recorded in Audacity.

Speaking of quality, File:Kiss & Cry (Sample).wav has subpar audio quality due to its low bit-rate, and I'm unsure whether you want me to improve the WAV quality further. Hopefully, the MP3 one I uploaded should have a better sound, despite being lossy. Also, I PRODded other remaining WAV files mostly due to "contextual significance" issues; that has nothing to do only just "minimal extend of use". I might mention more of them if necessary. Honestly, this situation is becoming more similar to SVG discussions unless I stand corrected.

BTW, I didn't know that additional transcodes would waste space. AFAIK, even transcoded files converted from lossless or uncompressed formats are often larger than other files using lossy formats. George Ho (talk) 07:38, 9 February 2022 (UTC)

As others have already said, from an NFCC perspective it doesn't matter whether it's wav, flac, mp3, or whatever. NFCC concerns would focus on the amount of the work used and the context in the article, not the file format. As an analogy with images, you might compare wav with bmp versus flac with png and mp3 with jpeg (and ogg/oga with webp, particularly since both can use both lossless and lossy compression). We do generally avoid bmp too, not because of any NFCC concern but simply because there are better formats available.

The FUD around SVGs and NFCC is an entirely different matter, which at least has better arguments (and, unfortunately IMO, more adherents) than the FUD you've expressed here regarding NFCC and wav or flac files. P.S. A good audio analogy for SVG would probably be something like a MIDI file.

The comments regarding uploading a transcoded version not saving space is simply that MediaWiki will still keep the old version of the file too. Even if it's deleted, MediaWiki keeps the original file in case it's later undeleted. It would take action by sysadmins to completely remove the old version of the file. Anomie⚔ 13:11, 9 February 2022 (UTC)

Wikipedians with degrees to show their subject

I do not know whether this idea has been formulated at Wikipedia: Perennial proposals, but I thought I would raise it here. If you look at the user pages of Wikipedians, one will often see that they categorise the Wikipedian according to the degree(s) that s/he has achieved. For example, we can see the categories "Wikiped- ians with B.Sc. degrees", "Wikipedians with B.A. degrees", "Wikipedians with M.Phil. degrees" and "Wikipedians with Ph.Ds." Would it be an idea to make Wikipedians who advertise that they have degrees indicate the subject in which they have degrees? That may help readers of Wikipedia appreciate where edits are likely to be reliable and valid. For example, I have a B.Sc., an M.Phil. and a Ph.D. in psychology, so my edits to articles to do with psychology may be based on a solid knowledge base. If my user page listed that this was the topic of my degrees, readers would be able to tell that any edits I made to the psychology articles in the encyclopedia would be based on greater expertise than, say, any edits I were to make on quantum mechanics. YTKJ (talk) 16:34, 8 February 2022 (UTC)

@YTKJ: All information you add to an article must be cited to published reliable sources. Your personal knowledge or expertise does not play into it. Just cite your sources. RudolfRed (talk) 16:44, 8 February 2022 (UTC)

See Wikipedia:Expert_editors for more on that topic. RudolfRed (talk) 16:45, 8 February 2022 (UTC)

@YTKJ: there are many templates you can use, see Category:Academic degree user templates. I just tweaked the PhD one, so you do something like this: {{user degree/PhD|field=[[topic]]}}

PhDThis user has a Doctor of Philosophy degree in awesomness.

— xaosflux ^Talk 16:45, 8 February 2022 (UTC)

But as RudolfRed points out, "being an expert" doesn't make your edit any more authoritative - but it may help other editors find you to let you know about topics you could be interested in. — xaosflux ^Talk 16:47, 8 February 2022 (UTC)

I gained a degree almost 50 years ago. It doesn't make me an "expert" now - not without checking more up-to-date information, at least. Ghmyrtle (talk) 16:49, 8 February 2022 (UTC)

I received a PhD in Linguistics 47 years ago, but never worked in the field. I quickly gave up on editing linguistics articles after I saw how many linguistics grad students were editing. :) - Donald Albury 18:09, 8 February 2022 (UTC)

I don't think you need a doctorate in psychology to figure out that not everything Wikipedians say about themselves is necessarily true... AndyTheGrump (talk) 16:50, 8 February 2022 (UTC)

• On the Internet, nobody knows you're a dog. We do want people who are experts in their field to edit Wikipedia, but that is useful only because they have access to sources that the rest of us may not, and that they are able to contextualize their fields so that the information is useful to a general knowledge encyclopedia like Wikipedia. What we don't particularly need is people claiming that credentials trump verifiability. Any formal recognition of credentials is just a slippery slope in that direction, coupled with the fact that we have no way of confirming anyone's credentials. --Jayron32 16:53, 8 February 2022 (UTC)

  I think you're understating the importance of that contextualisation, to be fair. I completely agree that credentials shouldn't be a factor in verifiability, but applying concepts such as WP:DUEWEIGHT inherently require good familiarity with the topic. Theknightwho (talk) 17:58, 8 February 2022 (UTC)

  It does, but you missed the context of my first link. We have no way to confirm that someone is who they say they are, so there is no point in even asking or recognizing it, and granting it any special privileges. Some of us have long memories of when we were burned by this in the past. --Jayron32 13:25, 10 February 2022 (UTC)

In a world where this exists, perhaps it is best that we remain focused upon WP:RS rather than contributors' alleged credentials. On a more personal but germane note, some of the most stupid people I have ever had the misfortune of dealing with hold the same advanced degree as me. And I'm not exactly Mister Peabody, either. JoJo Anthrax (talk) 18:15, 8 February 2022 (UTC)

Citation needed that you have those degrees. And that anyone with those things on their pages has the degrees they claim. Basically, this is another side of "nobody knows you're a dog". --User:Khajidha (talk) (contributions) 18:45, 8 February 2022 (UTC)

• Many thanks for your swift responses, everyone. Your points are well taken - I especially take the points of User: Ghmyrtle and User: Donald Albury, which seem to be saying that if a degree were taken a long time ago, it might not reflect expertise in contemporary knowledge of the field.YTKJ (talk) 22:15, 8 February 2022 (UTC)

  ... and alternative hypotheses are available. Thincat (talk) 22:33, 8 February 2022 (UTC)

• I have stated my own name, my academic degrees, and offered links to verify my academic degrees. This being said, I have never used my credentials in order to win a dispute at Wikipedia, they are just stated so that people know who they are talking to and what they can expect from me. tgeorgescu (talk) 16:32, 10 February 2022 (UTC)

Something I don't understand

Okay, so like I write an article. Let's use Cinema of Eritrea as an example. It's not translated or split from another article. It's just words from my brain straight into the page.

Now, my credit for that is found by looking at the history section. I know this going in, and I'm fine with it. If I translate an article from another Wikipedia, the expectation is that I put in the first edit summary that the work is a translation, and (at my discretion) post to the article talk page saying where the translation came from.

However, we have templates like {{Wikia content}} and a whole host of attribution templates which go right into the main page. I don't see what's so special about {{Peter Kemp}} that he gets his own fancy template (also like.. someone might want to look into that). Shouldn't these kinds of templates really be on the talk page instead of in mainspace? –MJL ‐Talk‐^☖ 06:23, 10 February 2022 (UTC)

This was created back in 2005 to "reference" text that, seemingly, was only agreed to be allowed on Wikipedia given this form of attribution. This was later accepted via OTRS in 2015.[8] It might be worth checking with OTRS to see what form of attribution is required. We often used to (and still do) cite public domain text in this way, see {{EB1911}}. If the text has been copied rather than "based on" then Wikipedia:Plagiarism would likely apply. Thincat (talk) 10:16, 10 February 2022 (UTC)

@Thincat: It appears the 12th and 13th editions (supplements) are now in the public domain; it might be worth incorporating the content from them as we did with the 11th. BilledMammal (talk) 10:32, 10 February 2022 (UTC)

Yes. In the early years when Wikipedia was desperately short of articles (!), I suppose before professional football had been invented, text was copied wholesale from public domain sources with no editorial intervention. Later that became disapproved of but often nothing was done about rewriting the content. Thincat (talk) 10:55, 10 February 2022 (UTC)

Coming back to your main questions, if the source is reliable and the use of it appropriate then yes, at the foot of the article itself is a suitable place. It is where citations go. Personally, I'm not too happy with attribution merely via an edit summary. I've never done a translation myself but I often copy text within Wikipedia and I use {{Copied}} on source and target talk pages. It looks to me that {{Translated page}} can be used for much the same thing. The translated text should still have citations on the article page. Thincat (talk) 11:13, 10 February 2022 (UTC)

@Thincat: I mean, I am highly doubtful that Forum:CT:Amendment to naming policy for real-world transgender individuals is considered a "reliable source" (it's not even a tertiary source which Wookiepedia as a whole is even if it is WP:USERGEN). Despite that, it's right there in the references section of Fandom (website). That's where I am getting at mostly here. –MJL ‐Talk‐^☖ 18:19, 10 February 2022 (UTC)

• If you translated from another WMF project, we can bring over the history as well post at WP:RFPI; links are sufficient generally, but we can do this. Some projects are more strict or accustomed to this (especially German), so if you do a DE->EN translation they normally appreciate that we bring the history over. — xaosflux ^Talk 18:44, 10 February 2022 (UTC)

Simplified lead sections

Complicated topics on Wikipedia are often explained in their lead sections in a way that people inexperienced with the subject or younger people could not understand.

Many times the Wikipedia link for a topic is the top result in a search engine and users often click on it expecting to learn what it is. However, if the topic's lead section description is beyond their scope of knowledge, it could lead them to go back and find a resource that explains it better. I'm sure this has happened to you...

An example article is Imaginary numbers. Unless you know what complex numbers, real numbers, and imaginary units are, you're immediately going to be distracted by learning what those things are when fundamentally you just need to know that imaginary numbers are the square roots of negative numbers and their squares produce negative numbers.

---

So, I am proposing that we create simplified versions of lead sections that can be accessed through a tab selector.

This is an example UI:

The switchable lead sections could be implemented with a template. It would just switch between the two types of lead sections. The rest of the article would remain the same.

The simplified versions should be explained at a level in which the fundamental pieces of knowledge needed to understand the topic are the only things mentioned. In the case of imaginary numbers, that would be numbers and squares.

If the reader does not know about those fundamental topics, the topics will at least be linked and they can further work their way through the knowledge tree and possibly visit other articles with simplified leads until they finally grasp what the topic they were originally searching for is about.

---

Some might say "the lead section is supposed to describe exactly what an article is about and nothing more or less. The Imaginary number article does that perfectly fine". And I would agree with that statement. But, we are truly causing a lot of people's days to be worse and decreasing the possible usefulness Wikipedia could provide. Wikipedia is supposed to be a free source of knowledge. It can't do that well if the readers can't even understand the knowledge to begin with.

Some might say "this is why we have the Simple English Wikipedia". The Simple English Wikipedia is meant to simplify topics only grammatically. This proposal is aimed at improving the comprehensibility of the knowledge itself (and a bit of the grammar). Additionally, as explained above, people click on the top-ranked English Wikipedia to learn about something. The Simple English Wikipedia is not top-ranked and does not provide a range of knowledge like the main Wiki. Fulfilling this demand for information on this wiki and not another will be extremely beneficial for both readers and editors alike.

Some might say "the Imaginary number article is an exception. The lead section just needs to be improved". There are countless examples of things that should be easy to explain but their lead sections do not. Here are some more examples: Schrödinger's cat, Order of operations, Atom. Lectrician1 (talk) 03:43, 20 January 2022 (UTC)

I'm afraid that this would make Wikipedia less of a encyclopedia, and more of a how-to guide in some cases. The proposed format is also probably too complex for the average user to intuitively understand without a explanation of the two purposes. Sea Cow (talk) 04:34, 20 January 2022 (UTC)

We have Category:Introductory articles, which is basically this, only applying to the entire article, and using hatnotes instead of the fancier UI in your mockup. Two are even FAs: Introduction to viruses and Introduction to general relativity.

Their existence is a little controversial; the main objections are that they are a form of WP:CONTENTFORKING that doubles the editor effort needed to cover a topic, and that they give non-introductory versions an unwarranted free pass to have inaccessible content. {{u|Sdkb}} ^talk 05:59, 20 January 2022 (UTC)

Lectrician1, your original point is a good one. But your proposed solution is cumbersome and highly unlikely to gain consensus. The real solution is to follow Wikipedia:Manual of Style/Lead section#Provide an accessible overview. I agree with you that explaining the concept of Imaginary number as fundamentally you just need to know that imaginary numbers are the square roots of negative numbers and their squares produce negative numbers is a good simple explanation. It is a real shortcoming that the lead section of this article does not mention or wikilink to negative number or square root. The solution is not to create a two-tiered system of competing "simple leads" and "complex leads". Instead, it is to bring the existing leads into compliance with the Manual of Style. It ought to be easy for you to write a new accessible introductory paragraph for that article that incorporates your simplified explanation. Cullen328 (talk) 06:38, 20 January 2022 (UTC)

I'm with Cullen here - the first paragraph of the lead ought to define and describe the subject in simple terms. Where it's not doing that, it needs to be improved. There is also Simple English Wikipedia as well - I wouldn't be averse to making links to the relevant article over there where it might help. Girth Summit _(blether) 06:48, 20 January 2022 (UTC)

Simple explanations can be misleading. Such as in in the humanities and politics. If we have to debate is it simple and accurate, no thanks, too constraining and fiddly. Person 1 changes to be more simple, person 2 changes to be less POV but person 3 thinks it's too complicated etc.. Accuracy competes with simplicity. Nevertheless, the creativity of the suggestion and image markup are noteworthy, the idea of parallel or complimentary text in a tab might have other application. -- 07:11, 20 January 2022 (UTC)

• Our coverage of Boolean algebra ran into a related problem in the early years, namely that the way the topic was developed by algebraists was a bad entry point to the many other users of this mathematical formalism. We 'solved' the problem by developing a parallel set of overlapping articles on the topic, including Boolean algebra (structure), Boolean algebra and Boolean algebras canonically defined. I seem to recall we used to have a treatment directed at engineers, but I don't find it. Separately considered, these are decent treatments, but the problem is that the lead of each article isn't ideal for helping readers who do not know what we have to offer which is likely to be the right article for them to start with.

This is the most extreme example I know of, but there are many examples of topics that have several articles on them that are pitched at different kinds of reader. The idea of a standard navigation interface like the tab suggested that users would know to consult if the feel they are not reading the right presentation is a promising one, but (i) I think the idea that we can just assume there is a simple vs an expert presentation of any given topic doesn't do justice to the wide variety of ways in which we have tried to accommodate the mismatch between what the treatment demands and what the new reader brings, and (ii) we have a fundamental competence issue here, which is that WP is mostly edited by people who have a relatively good feel for what material we have on a particular topic, and so are not good at putting themselves in the shoes of the new reader: good facilities for introductory jumping-off points is quite likely not to result in us writing up a lot of good jumping-off points. — Charles Stewart (talk) 11:53, 20 January 2022 (UTC)

Simple English Wikipedia already exists. X-Editor (talk) 00:30, 22 January 2022 (UTC)

@X-Editor I cover that in my initial post 😑. Lectrician1 (talk) 01:31, 22 January 2022 (UTC)

Sorry, I missed that. X-Editor (talk) 01:49, 22 January 2022 (UTC)

If this mainly a maths/math problem? what about having a link to the simple English version in the Lede?

Although this is the simple English version of https://simple.wikipedia.org/wiki/Complex_number and https://simple.wikipedia.org/wiki/imaginary_number

The imaginary is rather complex

This website is poorly named (it's a web site for people sceptical about climate sceptics), but it has a nice feature of explaining science in three different ways - basic /intermediate/advanced Wakelamp d[@-@]b (talk) 07:06, 23 January 2022 (UTC)

@User:Wakelamp That's a cool site! Lectrician1 (talk) 02:09, 27 January 2022 (UTC)

Just an update, I've decided to focus on improving lead sections for now. I would like to come back to this though, especially in regards to creating simplifications for things that a child can understand (like a kid Wikipedia). Lectrician1 (talk) 02:09, 27 January 2022 (UTC)

The TV Tropes wiki (they use pmwiki) has a “Laconic” subpage selector at the top of many (but not all) of their articles (example) that shows something sort of like our “Short Description”, but a similar UI concept might be worth considering if this kind of thing was implemented. It saves tons of reading time, especially for wiki readers that spawn tons of tabs when reading! Jim Grisham (talk) 14:59, 27 January 2022 (UTC) Couldn't we just flag the worst articles articles Wikipedia:Make_technical_articles_understandable? It looks like science and philsophy articles may the most issuesWakelamp d[@-@]b (talk) 01:45, 11 February 2022 (UTC) What about showing Lede/Article readability scores in the short XTOOLS stats?Wakelamp d[@-@]b (talk) 01:45, 11 February 2022 (UTC)

Alt text stored on image page?

John Oliver, comedian and satirist, pictured in 2016

For those of you unfamiliar with the alt text accessibility feature, quick primer: This image depicts John Oliver, a comedian and satirist, and below the image is the caption: John Oliver, comedian and satirist, pictured in 2016. However, this image also contains alt text, and its purpose is to tell screen readers (e.g. not you, but a bot that converts text to speech for the blind) what's in the image without being able to use the image as a visual aid. So, the alt text on this article reads Man in his 40s with a gray suit jacket and spectacles, visible only from the shoulders up. When screen readers come to the image, they will read the alt text instead of, y'know, trying to read off the pixel values (or the caption, which may explain what the image is doing in the article.)

As of now, this alt text has to be set when it is called by the file handler (e.g. [[File...). My question is: alt text, unlike the caption, is generally not specific to the article its in. Why be forced to redefine it in every image? When images are uploaded to wikipedia, there should be a "default alt text" option, which is automatically substituted in when the image is called. This can still be overridden by calling the alt parameter in the file-calling text of the article, but there should be a way to provide a centralized alt description in the image page, so that adding alt text is more convenient for the user (i.e. more widely used) and not just something that has to be done to promote an article to GA status. Plus, main page images (at least at DYK) don't generally come with alt text, so this would add it to at least some of them. Thoughts? theleekycauldron (talk • contribs) (she/they) 08:55, 31 January 2022 (UTC)

My understanding was that ALT text is actually specific to the way the image is used. Some images can be used to illustrate different things, and need different ALT texts. Jo-Jo Eumerus (talk) 10:27, 31 January 2022 (UTC)

There could be a "suggested alt text" but to do this properly you'd need to have suggested alt texts in all possible languages, and make sure you override the alt text on Commons if it is in a different language than the one you wish to use. Probably currently still easier to keep the alt text on each page using the image. —Kusma (talk) 11:24, 31 January 2022 (UTC)

No image needs to have the alt text in every language filled right away—It could be a template, something like: {{alt text |en=... |es=... |he=...}} and more are added as needed. When using an image on wiki, it would look for an alt text template with the parameter matching the language of the wiki. theleekycauldron (talk • contribs) (she/they) 11:30, 31 January 2022 (UTC)

We have enough difficulty getting image uploaders to describe what the image is that they are uploading. I don't think it would be practical to add another ask at upload. Worse, that could only address new media - you instantly create a backlog of epic proprtions re our existig content on Wikimedia Commons, and sooner or later someone would then annoy past uploaders by demanding that they add alt text to images they added to commons, some more than a decade ago. This then gets into the next practical problem, Wikimedia Commons is a multilanguage project, alt text has to be in one or more specific languages and don't asssume that the uploader you are requiring to add alt text is going to do so in the language of your choice. Lastly, alt text should be specific to the use in an article. The same photo of a church might be used to illustrate an article about round towers, thatched roofs, or locations used in a particular TV series, and the appropriate alt text would likely be very different in each. ϢereSpielChequers 12:04, 1 February 2022 (UTC)

I suppose that's fair—any way to add articles missing alt text to a maintenance category, then? And create an alt text addition helper, too- theleekycauldron (talk • contribs) (she/they) 06:23, 2 February 2022 (UTC)

I'm more positive about this idea than some of the others here. When we're talking about alt text, we have to consider our starting point, which is that our current approach isn't working. I'm not sure exactly what the percentage of images with alt text currently is, but I wouldn't be surprised if it's <1%. The only way that changes is if we change our approach, and that means either introducing AI or adopting something like this. I don't think a suggested alt text field on Commons would be used extensively, but even if it's only used occasionally, it could start to help. {{u|Sdkb}} ^talk 08:18, 2 February 2022 (UTC)

Consider review of meta:Community Wishlist Survey 2021/Reading/Alt-Texts and Image Descriptions and related tasks (and I think the tasks have much more reading), and meta:Community Wishlist Survey 2016/Categories/Multimedia#Default alt text in image file. Izno (talk) 23:27, 12 February 2022 (UTC)

Hosting scripts with non-CC licenses

rant

I've been extremely disappointed by the way many commenters have been shitting on me in Wikipedia:Miscellany for deletion/MediaWiki:Gadget-afchelper.js/core.js. Being widely used is not a reason not to nominate something for deletion (unless one wants to invoke WP:IAR, but, really?), it having been around for a long time isn't either, the shifting of the burden to prove compatibility is downright ludicrous, accusations of the nomination being disruptive and pretending I'm trying to change policy with it or something are a serious violation of WP:AGF if I ever saw one. Yes, I'm pissed and I needed to get that off my chest. I nominated it because I didn't think the license was compatible, and I'm still unsure whether it is. Nothing more, nothing less. I don't automatically assume there's a wider problem.

While I hate to have to be the one to initiate the discussion, there appears to be a desire to host third-party scripts on Wikimedia that have a free license that isn't compatible with CC BY-SA 3.0. A few options I have thought of that could achieve this:
1. Toolforge. Already available, but not readily accessible to everyone to upload. Will require CORS exceptions. May cause downtime/performance problems.
2. Add an exception to WP:Copyrights. Somewhat complicated. Would have to be well-written. Would only provide a solution for enwiki, assuming we don't want to host everything here for all projects in all languages.
3. Create an exception on Meta and load any non-CC scripts from there. No CORS or performance issues and available to anyone who isn't blocked on Meta. Similarly complicated, but would solve the issue for all projects.
4. Same, but on Commons. The likelihood of getting blocked on Commons without bad faith is probably higher than meta (copyright is hard) so I have rather mixed feelings about that.
5. Create a new wiki just for this. None of the problems, but even less trivial.
6. Create an exception on foundation:Terms of Use#7. Licensing of Content. I'm not sure about the implications there, if it would overrule WP:Copyrights, etc.
Or we simply ban non-CC scripts of course, but my gut tells me that won't be a popular option. — Alexis Jazz (talk or ping me) 19:58, 15 January 2022 (UTC)

As a few participants in the linked MfD noted, we should seek advice from qualified individuals (e.g. WMF Legal) before doing anything. Enterprisey (talk!) 07:33, 18 January 2022 (UTC)

I do not see a conflict with code under a permissive license in the current system, though GPL'd software could be a bigger problem. I would support something like using MCR to add a Wikitext field to JS and CSS pages, so they could be categorized and license tags could be used. This is definitely something that would have to be done in coordination with the WMF, and only if they think it is necessary or important. AntiCompositeNumber (talk) 21:35, 20 January 2022 (UTC)

AntiCompositeNumber, what does "MCR" refer to? (I don't recognize the abbreviation) Why do you think there is no conflict atm? In some cases (sufficiently permissive license or code written by the page creator) the code can be licensed as CC BY-SA 3.0. But in other cases, where is the exception in Wikipedia:Copyrights that allows uploading third-party scripts here? If Wikipedia:Copyrights#Re-use of non-text media would cover scripts there wouldn't be an issue I think. Whether scripts are "non-text media" is already questionable, but the reference to the "media description page" clarifies that exception is only meant to apply to files in the File: namespace.
Enterprisey, it would help if we vaguely knew what we maybe wanted before asking them. Though for this, depending on what we do, I don't think Legal strictly needs to be involved. Maybe to clarify the footer if we update policy. foundation:Resolution:Licensing policy doesn't dictate a specific license, only that the license meets https://freedomdefined.org/Definition/1.0. — Alexis Jazz (talk or ping me) 01:21, 21 January 2022 (UTC)

Message from Legal:

The Wikimedia legal team has received your message. It's somewhat difficult to answer a general question about relicensing, especially as relicensing isn't the only aspect of hosting content on the Wikimedia projects. For example, many Wikipedia pages host non-free fair use images according to the English non-free content policy. They're allowed to be on Wikipedia and no law is violated by the CC BY-SA page footer even though the specific work depicted on the page is not a CC BY-SA licensed work. In this case, the Foundation does not see any copyright violation from the apache 2.0 code on the mediawiki page mentioned in the discussion and there is no need to take down the code. That is likely true for apache licensed code reproduced in full original or modified form on any mediawiki page.

Apologies that I can't be more specific than that. We are limited both by the fact that Foundation attorneys can't give the community legal advice and also by the fact that a full analysis of all possible mixtures of apache and CC licensed works would likely be quite extensive and go well beyond what's possible on Wikimedia-hosted sites.

— Jrogers (WMF)

Basically what I had already said. Legal doesn't care about policy violations. But we should. Right? — Alexis Jazz (talk or ping me) 01:29, 21 January 2022 (UTC)

MCR is mw:Multi-Content Revisions, basically a way to have two different types of content on the same page. It's only used for Structured Data on Commons at the moment, but it could be used to create a description page for script pages. That would take some development work, there's still a few days to propose it for m:Community Wishlist Survey 2022. Ultimately that's a "nice to have", a header comment will suffice as a license statement.

I think it could be useful to add some clarifying language to WP:C, stating something along the lines of "User and site JavaScript (pages in the MediaWiki: and User: namespaces ending in .js) may be licensed under any free license, as designated by a comment at the top of the page. Any JavaScript pages without such a comment are licensed under CC BY-SA 3.0/GFDL". MediaWiki:Wikimedia-copyrightwarning should also be changed to state something similar on such pages (which requires WMF approval). An RfC on WT:C would probably be the place to start. AntiCompositeNumber (talk) 02:14, 21 January 2022 (UTC)

Based on the referenced discussion, I don't think a consensus view has been established yet to host scripts that cannot be licensed under terms compatible with CC BY-SA 3.0. The participants didn't feel comfortable with interpreting the license in question. I do agree, since WMF Legal has no immediate objections, that from a policy perspective, we can try to reach a consensus about tool content on the site (as opposed to mainspace content and other pages that directly affect mainspace, such as templates). Perhaps there is a set of open source licenses that the community deems acceptable for redistribution to anyone seeking to fork their own copy of the entire Wikipedia editing ecosystem. isaacl (talk) 02:08, 21 January 2022 (UTC)

With apologies, we generally do not evaluate specific pages in this manner and it would be not be good practice to do so. If it would be helpful, we can likely take my general answer on license compatibility and do a wikilegal article on the topic of posting licensed code around the internet in a few months. I'll add it to the queue for our legal fellows to research.

If you think material in a specific case was copied onto wikipedia in a way that doesn't match with its license, you can correct it as needed, remove it, or discuss with other users to determine what to do. The Foundation would generally only evaluate a page if the copyright owner sends us a DMCA notice.

— Jacob Rogers (Wikimedia Trust & Safety / Legal)

So we are free to violate both copyright law and our own policy as much as we want, as long as the copyright holder doesn't file a claim. At least as far as Legal is concerned. Legal isn't nearly as proactive as some users think it is. — Alexis Jazz (talk or ping me) 05:01, 26 January 2022 (UTC)

Sure; as far as I know, historically office actions related to copyright infringement have only been done in reaction to takedown notices. For better or worse, as a crowd-sourced site, editors bear individual responsibility for their edits. isaacl (talk) 05:25, 26 January 2022 (UTC)

I don't agree with your assertion that copyright law nor our own policies are being violated here. Legoktm (talk) 06:06, 26 January 2022 (UTC)

Legoktm, why do you twist my words? I said that as far as Legal is concerned we can do whatever we want as long as the copyright holder doesn't file a claim. There is no copyright violation as MediaWiki:Gadget-afchelper.js/core.js is used under the Apache 2.0 license and according to Kevin Brown-Silva the license link on MediaWiki:Gadget-select2.min.js is sufficient as this file is unmodified from the pre-compiled file for distribution and this particular case falls within their compliance guidelines for Select2. (I've already asked for more information on these compliance guidelines as I couldn't find them online)
Our own policy however is a different matter. WP:C contains no exception for scripts. While MIT/Expat licensed code can maybe be relicensed as CC BY-SA 3.0 (can't say for sure), it seems highly unlikely the same would be true for Apache 2.0. Josve05a, you said I've come to understand that the Apache license is a permissive license which allows you to relicense your whole project under a new license, as long as you details your specific modifications since permissive licenses do not force derivative works to use the same license in this discussion. But isn't this incompatible with CC BY-SA 3.0? BY-SA 3.0 would allow me to remove the modification notices. — Alexis Jazz (talk or ping me) 05:49, 28 January 2022 (UTC)

Local policy is meant to be interpreted with common sense, and in spirit rather than the letter. The policy must have been written with text content in mind, not code. It can be modified to match practise – such as by mentioning "code licensed under permissive open-source licenses can be hosted on-wiki if doing so is compliant with the terms of the license". – SD0001 (talk) 12:52, 28 January 2022 (UTC)

The key question is to what extent does the community want to promote the Wikimedia Foundation's mission, ... to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally. Does this include freely licensing the English Wikipedia editing ecosystem, going beyond the MediaWiki software itself and including commonly-used tools used by the community? (Think of the rationale underlying the Affero GPL: being able to ensure any modifications to how the service is provided can be replicated by others down the line.) If so, does it want to provide a unified licensing policy, as is done for English Wikipedia's text, or does it want to leave it to re-users to sort through the licensing requirements of each component? If the latter, do we try to roll up the licensing information to help re-users identify what needs to be done? All of the possible answers still support the overall mission; they just help draw boundaries around the scope. isaacl (talk) 21:58, 30 January 2022 (UTC)

We already require that of re-users by our use of files both locally with our NFCC policy and globally with our use of files from Commons, never mind our fair use of quotations. Izno (talk) 22:10, 30 January 2022 (UTC)

I'm not sure what "that" you're referring to. The non-free content criteria is related to content viewed or heard by readers, whereas I was referring to tools used by the community, such as the AFC helper script that was referred to in the original post. Re-users of the site don't have to replicate our editing processes, such as Articles for Creation, so we could choose to leave them out of scope entirely (and not worry about licensing at all), or keep them a little in scope by allowing tools that have contributions with free software licenses other than GFDL and CC BY-SA 3.0. isaacl (talk) 02:29, 31 January 2022 (UTC)

or does it want to leave it to re-users to sort through the licensing requirements of each component? is the that in question. Izno (talk) 20:58, 31 January 2022 (UTC)

Thanks for the clarification. The situation for content is a bit different. If the files are just being included from Commons, then they aren't being re-distributed by the re-user. The underlying basis for the non-free content criteria is fair use, where a free equivalent is not available or cannot be created. The requirements are stringent so re-users can feel reasonably assured that they can re-use the content without significant problems. With software components, though, the potential of a free equivalent being created is always there. "It would cost a lot to replicate" wouldn't be enough to claim that a legal free equivalent couldn't be made, from a copyright perspective (there could be patent issues, but there's no fair use for patents anyway). isaacl (talk) 21:32, 31 January 2022 (UTC)

(a bit off topic in regard to the policy question: Apache is compatible with by-sa in terms that you are free to modify it, as long as you attribute and specify changes. By-sa however does not allow you to remove the attribution (the -by part), and you need to keep the same license requirements (the -sa part).)

The question at hand is if we can host code which are not yet relicensed as cc-by-sa 3.0, but rather under other licenses. We have policy exceptions for Files, where other licenses can be used as long as they are more or as permissive as cc-by-sa (unless used under fair use policy), but we do not allow such exceptions in article space, nor in "code space" at the moment. Jonatan Svensson Glad (talk) 00:08, 29 January 2022 (UTC)

Concur with SD0001. If doing something useful (hosting AFCH) conflicts with policy, then changing the policy should at least be an option. Enterprisey (talk!) 08:10, 30 January 2022 (UTC)

It wasn't my intention to twist your words, I was just replying to "So we are free to violate both copyright law and our own policy as much as we want...", because I don't think neither copyright law nor our own policies are being violated. WP:COPYOTHERS says "If you want to import media (including text) that you have found elsewhere...you can only do so if it is public domain or available under terms that are compatible with the CC BY-SA license". I believe that clause is being complied with as IMO the general consensus is that Apache 2.0 is generally compatible with CC-BY-SA.

I do agree with others that WP:C would benefit from explicit clarification on this front. Legoktm (talk) 07:50, 4 February 2022 (UTC)

Important to note what the notice on the bottom of every page says.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. This is the equivalent of the "Unless otherwise noted". It means if we put a notice that the script is licensed under something else (like MIT or Apache) no terms are being violated. Aasim - Herrscher of Wikis 20:48, 31 January 2022 (UTC)

Awesome Aasim, that's more of a catch-all disclaimer, law and ToU and local policy are all different things. For example mw:Extension:WikiHiero, here's a non-compliant use of a GFDL-licensed work using the extension: I noticed that in 2018. But if S. Rosmorduc, G. Watson and J. Hirst ever decided to try and sue re-users, the re-users won't be able to pass the buck to the WMF because "additional terms may apply". — Alexis Jazz (talk or ping me) 16:19, 15 February 2022 (UTC)

I have some thoughts but been thinking on how best to respond to this.

First, history: We have generally been laissez faire on enforcement of copyrights in scripts and CSS from what I've observed of the detritus in the user space. However, all the cases I've observed have been freely-licensed (for various values of free, sometimes MIT, sometimes Apache, etc.). So that means either a) we don't generally care about what's in that space as long as it's free, or b) we don't know it's there (well, some people clearly do, so not b), or c) someone has maintained some minimal standard (i.e. any proprietary stuff has been removed), or d) people have generally thought "open license is reasonable to put here and proprietary license stuff would not be", or e) some combination of the above depending on admin and user.

I think from a practical perspective of wanting to control the scripts that are used here (for potential change) as well as a safety perspective, as well as the performance perspective, that we should minimize cross-site loading. So, I do not think requiring non-CC licensed code to be offsite is reasonable.

Regarding the TOU, do note The only exception is if the Project edition or feature requires a different license. I think it's reasonable to call a user script or a gadget a feature. YMMV.

Accordingly, I do not think any of the suggestions presented besides "modify WP:C to make the exception clear" +- some discussion on where that bar is (e.g. Toolforge uses the OSD crtieria) is appropriate, in the spirit of "we can decide how to treat spaces X or Y" that the WMF seems comfortable with to some degree. Izno (talk) 03:20, 5 February 2022 (UTC)

Izno, I think it's reasonable to call a user script or a gadget a feature. YMMV. I doubt it. I think structured data on Commons is a feature. And maybe Toolforge and mailing lists. I've asked Legal to clarify the meaning. — Alexis Jazz (talk or ping me) 14:26, 15 February 2022 (UTC)

What licences are acceptable? Where do we put the bar?

I think we should update WP:Copyrights to allow some licenses for .js pages in addition to CC BY-SA 3.0. MIT License and Apache License 2.0 seem like no-brainers. What about..
• GNU General Public License v2?
• GNU General Public License v3?
• GNU Lesser General Public License?
• Affero General Public License?
• BSD licenses?
• WTFPL?
• Anything else from Comparison of free and open-source software licences we should consider? — Alexis Jazz (talk or ping me) 17:12, 15 February 2022 (UTC)

Thinking about deprecating IRC in favor of something like Discord [proposal idea]...

This is just an idea, but I have only recently developed concerns for IRC as of recently. I am thinking maybe IRC be deprecated for privacy concerns and because of inactivity. I do not think I am ready to propose it, but I want to develop it into something that is ready for an RfC.

IRC by default displays IP addresses, which can actually be used for determining someone's location. WMF is currently in the process of cloaking these IPs which makes IRC essentially pointless if used uncloaked. Discord and Guilded on the other hand has IP addresses hidden by default from everyone except the staff that can access IP information for each user (that is how they do IP bans from Discord servers as well as Discord itself).

The next concern I have is activity. I checked some of Wikipedia's main IRC channels and only see a hundred or so users on IRC compared to, say, Discord's Wikimedia Community, which has ~3000 members and ~600 active users. IRC has mostly died as soon as Discord became a reasonable option for most.

Lastly, IRC does not allow for transmission of media, which is something that Discord and Guilded allow. Sometimes an image gets deleted from Commons for being potentially non-free, yet it is in line with Wikipedia non-free criteria. I remember asking once for a deleted file so I could upload it on Wikipedia with "do not move to commons". This is not possible with IRC. Attachment of media files on wiki could potentially violate wiki policy (particularly NFCC), and a lot of the forum software is public. Discord's privacy settings also means I can control who can direct message me in what guild on a per-server basis.

I heard WMF is working on a chat solution based on Mattermost, but I do not know how that stacks up to Discord and similar freemium services. I am not sure if it is even maintained, but anyway, here are some of my reasons why I'd want to deprecate IRC. Aasim - Herrscher of Wikis 23:17, 30 January 2022 (UTC)

I have seen the downsides of Discord (namely being for profit and its privacy policy not exactly aligned with WMF's), but personally I think the downsides of IRC (namely the privacy concerns with IRC, lack of usage, and limitations with IRC) are greater than the benefits we may get from continuing to use IRC. That is why I would like to build this proposal into something that might pass. Aasim - Herrscher of Wikis 23:21, 30 January 2022 (UTC)

Relevant xkcd. In all seriousness, I do not believe this idea is worth pursuing. It's not clear what it would mean to "deprecate" IRC. There is no requirement on Wikipedia that editors must use IRC for communication—if you are concerned by privacy or activity, there isn't anything to prevent users from simply not using IRC. In practice, I see management of the Wikipedia-related IRC channels as being WP:CONEXCEPT—at the end of the day, my understanding is that they're run by the IRC Group Contacts, so even in the unlikely event that we can get an RfC with consensus to "deprecate" IRC (which would probably have to be a global RfC on Meta Wiki, since it's not just enwiki that uses IRC), there's nothing stopping the Group Contacts from simply ignoring that discussion and keeping the channels running. In terms of privacy, one benefit of IRC is the lack of scrollback—any user that joins the Wikipedia Discord server now and in the future will be able to see the complete history of all messages that were ever sent, whereas IRC users can only see the messages that were sent while they were connected to the network. In my view, this is actually ideal for discussing privacy-related issues, such as requesting revision deletion in the channel #wikipedia-en-revdel ^connect. You're correct that IRC by default exposes a user's IP address, but it is easy to mitigate this by requesting a cloak (see [9] for instructions on how to get a generic one within seconds). As for transmission of media, what I like to do is upload the image I want to a third-party site like imgur, and then paste the link from that through IRC. Mz7 (talk) 01:55, 31 January 2022 (UTC)

To be honest, I'd prefer a more modern solution that does not have privacy concerns such as with IP exposure. I also think it is ridiculous that we promote channels on IRC without putting a disclaimer when they connect that their IP will be visible until cloaked. Personally, if we want to keep on using IRC, we ought to put a disclaimer before they connect to let them know that their IP information may be made publicly visible. Even if we use Discord we need to make it clear that 1. the service is not controlled by the WMF, and 2. Discord's guidelines take precedent over Wikipedia guidelines. That could be done with an update to the IRC template, but also Discord is what is being used as of latest for communication. I am guessing it could be untrivial to get Discord linked in the relevant notices like MediaWiki:Readonlywarning and MediaWiki:Readonlytext as editors also discuss Wikipedia off-site there as well. Aasim - Herrscher of Wikis 17:35, 31 January 2022 (UTC)

@Awesome Aasim Links to #wikipedia-en-help generally are passed through Wikipedia:IRC help disclaimer, and similar disclaimer pages could easily be spun off for other channels. --Ahecht (TALK
PAGE) 19:11, 14 February 2022 (UTC)

I think people should know what they are getting into before they connect to Discord or IRC or whatever. One thing we can do is we can make mention of the platform in the template (like Join on Discord, Join on IRC, etc.) so that people know what they are actually joining. But I'd also link Discord channels in places where they are useful as well. Aasim - Herrscher of Wikis 20:43, 15 February 2022 (UTC)

What about an IRC/Discord bridge? — xaosflux ^Talk 19:14, 31 January 2022 (UTC)

Hmm... That might work... I know the RedWarn Discord has an IRC to Discord bridge... I think a Toolforge solution would work best though... Aasim - Herrscher of Wikis 20:41, 31 January 2022 (UTC)

IRC and Matrix are already bridged; #foo on libera.chat is automatically connected to #foo:libera.chat. Matrix doesn't have the issues with privacy or features. We could recommend people join those instead. I was going to suggest we add a warning about IRC's low activity, but it's more that you'll get fewer responses on IRC, not zero. Concur in full w/ Mz7, with a further note that the two platforms have distinct cultures, and some users (myself included) prefer IRC's. Enterprisey (talk!) 07:23, 16 February 2022 (UTC)

One thing I've never understood is how does the average IRC user get messages that were sent when the IRC app isn't running? I know there are tools like IRCloud but it's not free. Is there a simpler way? – SD0001 (talk) 09:08, 16 February 2022 (UTC)

Some don't care that they'll miss stuff that was said while they're not there, or rely on people who are in the channel all the time to let them know if there was anything interesting. Others use a bouncer of some sort, but I don't know of any free bouncer services offhand; ZNC is popular free software (in both senses), but you'd still need to pay for hosting somewhere to run it. Anomie⚔ 12:55, 16 February 2022 (UTC)

Most IRC systems, including Libera Chat have a MemoServ for this purpose. For example, you can message me when I'm offline with /msg memoserv send xaosflux Please check your email when you get this!. — xaosflux ^Talk 14:52, 16 February 2022 (UTC)

Also, IRC is not designed to be a persistent message platform, it is designed to be a real-time message platform, non-archival of messages can be considered a feature. — xaosflux ^Talk 14:53, 16 February 2022 (UTC)

It is not for me, then :) I use discord and check messages just once or twice a day, or when I'm pinged. Such a workflow just doesn't fit with IRC, it seems. – SD0001 (talk) 04:01, 18 February 2022 (UTC)

Watchlisting sections, not pages

Hi all, I 'd like to propose something on watchlisting.

• Problem: high traffic pages (like various noticeboards) are hard to watch. They are almost always at the top of your list. And while you contribute to an issue that interests you and you would like to follow it, there is no way you can dοing that.
• Prob solution, if it is technical feasible: Watchlisting sections of certain pages.

What do you think? Cinadon36 08:31, 18 February 2022 (UTC)

@Cinadon36: Wikipedia:Talk pages project#Notifications for topic subscriptions may be what you're looking for (although it is pings and not watchlist). CMD (talk) 09:02, 18 February 2022 (UTC)

@Cinadon36: This is a frequent request, apparently difficult to implement in Media Wiki software. See Wikipedia:Perennial_proposals#Allow_watchlisting_individual_sections_of_a_page There is a user script there you can try out. RudolfRed (talk) 00:40, 19 February 2022 (UTC)

@Chipmunkdavis and RudolfRed: Thanks mates! Cinadon36 07:08, 19 February 2022 (UTC)

Create a new page

Guys I need help, I was asked to create a page for a social networking and book sharing site (feraahub). I do have a information and feraahub owner gave me it's logo but I need a link to create a page not a user page — Preceding unsigned comment added by B.matias brown (talk • contribs) 13:15, 20 February 2022 (UTC)

@B.matias brown: It sounds like you have a conflict of interest with feraahub. As such, you will need to create the article in WP:DRAFT space and it will be reviewed by the volunteers at article for creation. Please note that if the company does not meet the requirements of WP:NCORP the article will be rejected. BilledMammal (talk) 13:39, 20 February 2022 (UTC)

I blocked the originator of this thread as an unresponsive spam/advertising-only account. Graham87 05:01, 21 February 2022 (UTC)

Wikipedia:Notability (biology)

Hello all. There was recently a discussion at WT:WikiProject_Molecular_Biology#Notability_guidelines_for_science/database_topics? about notability in cases where there are large classes of possible items in databases (e.g. genes, species, proteins and RNA families). I summarised the results of that discussion at Wikipedia:Notability (biology) and listed it at WP:MOLBIO#Resources. I'm wary of policy creep, but in this case, I think it's reasonable since the topics have come up multiple times, most similar to geographic_features, astronomical_objects, and numbers. I'd be interested in people's suggestions or direct edits. The starting questions I listed at WT:MOLBIO are below, but feel free to approach from a more generalist perspective!

1. Are there classes of molbio (or other) topics with inherent/De facto notability?
2. What are the principles / common features for which classes are notable?
3. If a database is a sufficient secondary source to support notability, what are the features of such a database?
4. Does the number of items of that class matter? Would the call on RNA motifs have differed if there were 100,000 observed motifs?
5. Does it make a difference if the class is naturally occurring vs man-made? (e.g. observed microbial species vs created cell lines)
6. Does it make a difference if the class is stable vs changes rapidly?

T.Shafee(Evo&Evo)^talk 23:08, 14 February 2022 (UTC)

• I would oppose assigning inherent notability to anything; I would suggest that the guideline instead grants the presumption of notability, but that GNG needs to be met if the presumption is challenged. I would also note that a database is typically a primary source, as it usually doesn't contain an author's analysis, evaluation, interpretation, or synthesis of the facts, evidence, concepts, and ideas taken from primary sources. Beyond that, I need to consider further. BilledMammal (talk) 23:16, 14 February 2022 (UTC)

  For #2, the practically-always-notable subjects are things that "the world at large" pays a lot of attention to, e.g., heads of state or professional athletes. Individual molecules are not something that "the world at large" normally pays a lot of attention to, so they're unlikely to fall into this category.

  For #3, I'm not sure that a database is a secondary source. (I suspect that most of them aren't.)

  More generally, I think that you should consider WP:WHYN: could you actually write a decent, non-stub encyclopedia article with those sources, preferably including some directly sourced statement of why I should care about that gene/protein/molecule and a sentence about history (e.g., first described by Alice Expert in 19XX)? If not, then I'd suggest you contemplate whether your goal is better suited to species: and/or wikidata:. WhatamIdoing (talk) 20:48, 22 February 2022 (UTC)

• I think people fundamentally misunderstand the notion of notability; notability means "Is there enough good resources out there in the world to allow me to write a good encyclopedia article about this". It is not a mark of damnatio memoriae to lack the notability to create an article. We can mention and discuss such topics in the context of other articles, but there is not a need to have a stand-alone article about it. If we are destined to have only two sentences of text about some species of beetle, then there's no need to have an entire page for that species. Those two sentences could go into a different article. We're not refusing to cover a topic by not having a stand-alone article on it; it's just the recognition that for some topics, a stand-alone article is not the best way to cover the information. --Jayron32 13:57, 25 February 2022 (UTC)