The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
There is clear consensus to enable the new topic tool by default. Concerns regarding the reply tool and timestamps does not conflict with the rfc. Opened phab:T311023. 0xDeadbeef 01:35, 21 June 2022 (UTC)[reply]
Screenshot of the new topic tool
Should the new topic tool be enabled by default on English Wikipedia? {{u|Sdkb}}talk 21:33, 27 May 2022 (UTC)[reply]
Background
The WMF's editing team has been developing tools that aim to improve the functionality of talk pages for both newcomers and experienced editors under the umbrella of the talk pages project. A few months ago, we enabled their reply tool by default. The new topic tool is a similar tool for starting new sections on talk pages; you can preview it by clicking here and choosing "Add topic" at upper right, next to the history tab.
The editing team has informed usIn light of the recent A/B test results showing the positive impact of the New Topic Tool, the Editing Team is in support of enabling it by default at all projects, and has done so on 20 other projects, with it available here as a beta feature that can be turned on in your preferences. This RfC asks whether it should be enabled as a default-on feature, but with an opt-out option available to all logged-in editors in their preferences.
Survey (New Topic Tool)
Yes. This tool is the logical complement to the reply tool, which we have been using very successfully for several months. It makes starting discussions easier for both newcomers (vital for our future) and experienced editors (essential for our present). The ease of opting out (both fully in your preferences, and on a case-by-case basis by just editing in source if you need to) limits the potential for harm. We've already been using it successfully at the Teahouse since March. It's not at 100% perfect functionality quite yet, but it's close, and it's certainly much better than the status quo. Enabling it now rather than once development is fully complete will provide us with a more meaningful window to give the developers feedback that they'll be able to address before they wrap up their initial development work. {{u|Sdkb}}talk 21:33, 27 May 2022 (UTC)[reply]
Sure, why not. If it helps less-experienced users participate more (as the A/B results suggest), then that's probably worthwhile. Judging from Wikipedia:Talk pages project#Starting a new discussion, the big differences are the live preview (useful!) and the automatic signature (useful if "hyphen-hypen-space-tilde-tilde-tilde-tilde" hasn't already been permanently burned into your brain). Beyond that, the UX doesn't seem wildly different from the existing "+" setup, so there doesn't seem to be much to object to. -- Visviva (talk) 23:36, 27 May 2022 (UTC)[reply]
Yes. A/B tests show positive benefit, it's fairly easy to enable, and helps new contributors. 🐶 EpicPupper(he/him | talk) 01:56, 28 May 2022 (UTC)[reply]
Support, makes sense after the reply tool. ― Qwerfjkltalk 07:18, 28 May 2022 (UTC)[reply]
Strong support I think it's a great and simple-to-learn tool. — Ixtal( T / C ) ⁂ Join WP:FINANCE! 11:27, 28 May 2022 (UTC)[reply]
Support There are bunch of userscripts that help to do the same though. AXONOV(talk)⚑ 13:28, 28 May 2022 (UTC)[reply]
Support An improvement over the raw wikitext form. – SD0001 (talk) 16:41, 28 May 2022 (UTC)[reply]
Support I've found it to be an excellent counterpart to the reply tool. Sideswipe9th (talk) 15:25, 29 May 2022 (UTC)[reply]
Strong support Best discussion tool ever been made available to Mediawiki. Of course it should be available by-default. Lectrician1 (talk) 01:56, 2 June 2022 (UTC)[reply]
Support. I have used it for some time, and I find it very convenient even as an experienced editor. MarioGom (talk) 11:04, 4 June 2022 (UTC)[reply]
Support Will make adding a new topic consistent with the reply tool, no point having two different interfaces when you can have just one for a user to get used to for talk page comments. Terasail[✉️] 14:15, 7 June 2022 (UTC)[reply]
Support - nice job to the Editing Team working on this, thanks for the improvement! Retswerb (talk) 03:35, 11 June 2022 (UTC)[reply]
hi y'all – on the topic of, "How will people who prefer the existing section = new workflow be able to turn off the New Topic Tool?"...
In addition to what @Sdkb mentioned above about you being able to disable the New Topic Tool within Special:Preferences, the tool offers peoples the ability to switch back to the existing section = new experience from directly within the tool as pictured here: PPelberg (WMF) (talk) 02:04, 28 May 2022 (UTC)[reply]
Please see this.[1] "What's going on with the times here? Bakkster Man posts at 12:29 am, Today (UTC+1) with many diffs. Next, in line, (visually) a post by Gimiv 8:40 pm, Yesterday (UTC+1) complaining about a report with no diffs. Last, a post by RandomCanadian at 11:50 pm, Yesterday (UTC+1).[reply]
Why are times skipping around...23:29, 27 May 2022 (UTC), next 8:40 pm, Yesterday (UTC+1), next 11:50 pm, Yesterday (UTC+1). I have no connection with any of these editors, but it's very confusing, shouldn't our "software" organize this chronologically? Seems to make editors look as if they haven't read, or are mis-replying to posts."
— Preceding unsigned comment added by Doug Weller (talk • contribs) 12:17, 28 May 2022 (UTC)[reply]
I don't understand what you mean. That is not what I am seeing in that link; there isn't even a comment by Bakkster Man, and that is not how the timestamps look like for me. Can you include a screenshot of what you're seeing, and clarify what the problems are? (You can upload it to https://phabricator.wikimedia.org/file/upload/ if you don't want to clutter up Wikipedia.) Here's what the page looks like for me, and I don't see anything wrong: https://phabricator.wikimedia.org/F35185664. Matma Rextalk 21:43, 28 May 2022 (UTC)[reply]
@Matma Rex please take a look at the whole thread.[2]. You've pointed to an earlier version. I can't fit it into a screen shot. Doug Wellertalk 15:14, 29 May 2022 (UTC)[reply]
Oh, actually you linked to an earlier version, that's why I also looked at the earlier version. I thought that was intentional.
I am also still confused by the weird timestamps, I guess you're using some gadget to display them in your timezone and in different format? If it's showing some of them as "(UTC)" and others as "(UTC+1)", then that must be a bug in that tool. I have no idea what tool it is (it'd be slightly easier to guess if you shared a screnshot). You might find pages easier to read if you disable it, if that happens often.
The non-chronological order is expected for me. As far as I know, only replies at the same indentation level are supposed to be in chronological order. When you reply with deeper indentation to a comment earlier in the discussion, by necessity the result can't be chronological (unless you put your reply at the bottom of the thread, instead of making it a directly reply). I found a good example of this in the documentation pages: Wikipedia:Indentation#Indentation examples (admittedly it took me a while to find it). Matma Rextalk 18:56, 30 May 2022 (UTC)[reply]
Does this still have the "feature" of hijacking the "create a page" process for brand new talk pages? — xaosfluxTalk 14:33, 31 May 2022 (UTC)[reply]
Yes, although I'm hoping that we'll add a way to disable that while keeping the tool enabled otherwise. I proposed that in T297990. Matma Rextalk 17:41, 31 May 2022 (UTC)[reply]
[Update] The Editing Team is going to prioritize implementing what @Matma Rex mentioned above: a new setting that will enable people to decide for themselves whether they will immediately land in the source editor upon navigating to a talk page that has not yet been created or whether they will see the new empty state experience.
We expect this new setting to be available in the next few weeks. PPelberg (WMF) (talk) 16:04, 2 June 2022 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hey, all: I'll have to ask the devs about the schedule, but I think this could be done next week – maybe Wednesday, if the deployment calendar has a free spot? I'm not going to suggest WP:THURSDAY itself to them. If this coming week is too soon, please let me know. It can be postponed easily.
Many thanks to Sdkb for making this discussion happen. I would particularly appreciate it if someone would spread the word. I can tell VPT when the devs have settled on a day, but please let the non-technical editors know what to expect. It's super easy to opt-out if you don't like the new thing.
@Whatamidoing (WMF) how does reply deal with edit notices? Eg a lot of editors have them on their talk page, and if my chemotherapy really knocks me out I was going to add one making it clear I could not respond to help requests. Doug Wellertalk 17:42, 23 June 2022 (UTC)[reply]
@Xaosflux this looks like a major flaw. And I presume one that can’t be fixed. I wish I’d thought of this earlier. Doug Wellertalk 18:28, 23 June 2022 (UTC)[reply]
@Doug Weller the "Add topic" component has the edit notices,the "reply" one doesn't. So in your use case above, people newly starting a discussion on your user talk, while it had a page notice, would see it. People replying to a discussion would not. (c.f. phab:T269033) — xaosfluxTalk 18:35, 23 June 2022 (UTC)[reply]
@Xaosflux Ah, that makes a big difference. In most cases that would suffice. Thanks. Doug Wellertalk 18:42, 23 June 2022 (UTC)[reply]
Also, this is only about the "Add topic" component. Whatamidoing (WMF) (talk) 17:21, 24 June 2022 (UTC)[reply]
The devs say that they can do Wednesday, subject to all the usual disclaimers and caveats. Check https://wikitech.wikimedia.org/wiki/Deployments#Wednesday,_June_29 later if you want to know the exact time. Please ping me if anyone has questions (here or any other page).
These config changes have been deployed now. Matma Rextalk 13:38, 29 June 2022 (UTC)[reply]
@Matma Rex - are they working? I used a logged out session, went to a random article, went to talk tab, clicked "new section" - got the classic wikitext editor (link) as opposed to (dtenable forced) the new section discussion tool. — xaosfluxTalk 14:02, 29 June 2022 (UTC)[reply]
They do not appear deployed yet to me, either. {{u|Sdkb}}talk 14:03, 29 June 2022 (UTC)[reply]
We've investigating now, it seems like the changes haven't been deployed to all servers. Matma Rextalk 14:44, 29 June 2022 (UTC)[reply]
@Xaosflux @Sdkb Sorry about that – they should be deployed for real now. Apparently on some servers there was a caching problem and the new config wasn't being used, and I must have gotten one of the lucky ones when testing that the config change worked. SRE were able to fix it by just restarting stuff. I'll comment here when we know what exactly happened and how to prevent it in the future. Matma Rextalk 14:59, 29 June 2022 (UTC)[reply]
@Matma Rex - thank you, my last 3 tests seem to be working now. — xaosfluxTalk 15:25, 29 June 2022 (UTC)[reply]
In the most recent RfC on the topic of balance between voting and discussion at RfA, the community consensus was ...the bulk of opinions seem to be for keeping the balance as is with a slight skew towards making it more vote-like. This RfC attempts to build-off of that consensus by concentrating discussion, including the comments that happen currently in the neutral section, in the "General comments" section and on the talk page thus making the support and neutral sections more vote-like. This RfC would not change current practice of people explaining their supports/opposes/neutrals, merely where replies to them would belong.
Comments specific to the candidate/RfX will go in the "General comments" section, while more general comments will go on the talk page. An example of how this would work can be found at this RfB where discussion about a particular oppose occurred in general comments while a broader discussion about hypotheticals was moved to the talk page. Topics would continue to be seperated with a dividing line in general comments and by headings on the talk page.
Poll (RFA/RFB discussion)
Support both Our current status quo is a bad one, where on topic discussion about the candidate gets shunted to the talk page because of concerns about the tenor of discourse, while not actually doing much for that discourse because people still feel attacked by replies. By moving the comments to a general section, hopefully there will be a bit more remove (even if there are pings) and regardless when multiple people have similar concerns the discussion will be in one place rather than spread out over multiple opposes, something this recent RfA would have benefitted from. It also provides a standard (Comments specific to the candidate/RfX will go in the "General comments" section, while more general comments will go on the talk page on deciding which comments should be moved to the talk page. While I use Lee's RfB as an example of where this has worked, I would suggest it has also worked at Wugs' RfB where there was limited discussion about opposes compared to a more robust discussion in general comments. The neutral section at its best feels like it duplicates things that belong in general comments, where they should be considered by crats when determining consensus and considered by the community without tipping the balance towards or against the candidate, and at worst is needless signaling (i.e. "I intend to vote later") and since we're considering changes to increase that discussion I have paired the questions. Best, Barkeep49 (talk) 19:22, 13 June 2022 (UTC)[reply]
Support both per the nom almost verbatim. We might not have been able to reform RfA, but small changes like this might helpfully go a ways towards making the atmosphere and process of RfX slightly less adversarial. --WaltCip-(talk) 19:34, 13 June 2022 (UTC)[reply]
Support both (I never understood the reason for having a no-vote neutral section at all.) Schazjmd(talk) 19:53, 13 June 2022 (UTC)[reply]
support 1 only neutral section is required. "I will vote later" comments were discussed at WT:RFA. What if one finds a candidate who is excellent in some areas, and has zero experience in some other areas, and what if that voter gets torn between oppose vs support? They dont want to support because of lack of experience, but dont want to oppose as candidate is good, has clue, and solid contributions. I think neutral is necessary. We dont protect a page/article because of one inexperienced editor. Same should apply here. Crats can handle that. Rest of the norms for general comments should be kept as they are. If comments go off topic/RfX, any crat/uninvolved editor can move it to talkpage. —usernamekiran (talk) 19:59, 13 June 2022 (UTC)[reply]
Perhaps we need to advertise more widely that there is the option of abstaining from any RfA by simply not editing the page. —Kusma (talk) 21:18, 13 June 2022 (UTC)[reply]
Oppose option 1. RFA can be counterintuitive already, and not being able to reply to a statement immediately below it, the way you would on a talkpage would make that worse. I think it would also make the RFA experience worse for candidates. Currently if someone !votes with an easily rebutted rationale it can be pointed out in the next paragraph - having the statement "I've checked the deleted edits, and yes it was an attack page. There may well be a notable academic of the same name, but that was a valid deletion" in a completely different section rather than in the next paragraph is not going to make RFA a better place. ϢereSpielChequers 20:30, 13 June 2022 (UTC)[reply]
Oppose 1, Support 2. WereSpielChequers took the words right out of my mouth on option 1 -- demonstrably false claims in !votes need to be rebutted on the spot, not in a separate section down below. On option 2, I see absolutely no reason for someone who doesn't want to support, doesn't want to oppose, and doesn't want to leave a general comment to edit the page at all. !Voting at RFA is not mandatory, and no one's taking attendance. --Ahecht (TALK PAGE) 20:36, 13 June 2022 (UTC)[reply]
I support both proposals. Consolidating discussion about a given concern will reduce repetitiveness and improve efficiency: additional supporting or refuting evidence can be done in one thread, instead of having to repeat it across multiple threads. For convenience, I also support a slight modification to the first proposal, where pointers can be added in response to a support/oppose statement that would refer to the relevant discussion threads. I think the comments currently made in the neutral section can be posted within a general discussion section without loss of effectiveness, and so support this as well. isaacl (talk) 20:52, 13 June 2022 (UTC)[reply]
Support option 1 (we need to stop the way that discussions under a vote rationale tend to degenerate), but there should be a way to make factual corrections or perhaps a neutral "see discussion section for context". Also support merging "neutrals" into the general discussion. A lot of neutrals are either useless attention-seeking ("hey, I participated too!") or bring ammunition for the opposition that doesn't have to be sugarcoated as "neutral". —Kusma (talk) 21:14, 13 June 2022 (UTC)[reply]
I thought about allowing such pointers and would have no objection to those being permitted under this proposal. Best, Barkeep49 (talk) 21:20, 13 June 2022 (UTC)[reply]
Support option 2, support 1 with changes I never understood why there is a neutral section and a general comment section. I generally support option 1, but with two caveats. First, self replies should alway be allowed. Second, I do agree there should be a way for an editor to signal there is discussion as Issacl mentions above. --Enos733 (talk) 21:45, 13 June 2022 (UTC)[reply]
Oppose 1 per WereSpielChequers, et al. Support 2 as the Neutral section has never served a useful purpose. — SMcCandlish☏¢ 😼 23:15, 13 June 2022 (UTC)[reply]
Oppose both The "most recent RfC" was a war of attrition that cannot reasonably be interpreted as justification for these proposals. As stated above, if someone makes an incorrect claim in their vote, the problem needs to be corrected where the claim is made—not hidden in a large discussion 50KB further down the page. What is the problem with neutral? That section allows mild observations or reservations without recording a vote—it's fine. Johnuniq (talk) 23:53, 13 June 2022 (UTC)[reply]
Strong oppose 2 Keep the neutrals. Maybe ill be back with an opinion on #1, but not yet. Happy Editing--IAmChaos 00:15, 14 June 2022 (UTC)[reply]
Oppose 2 - RfX is a discussion, and one can add to the discussion without specifically supporting or opposing the candidate, I think that removing this will either dissuade people from contributing to the discussion at all or trying to shoe-horn themselves in to support/oppose as well so they 'get counted'. And I really don't want to see *'''Weakest possible support because the neutral section is gone''' blah blah blah ~~~~. — xaosfluxTalk 00:21, 14 June 2022 (UTC)[reply]
The proposal you are opposing does not remove the option to participate in the discussion without supporting or opposing. —Kusma (talk) 05:31, 14 June 2022 (UTC)[reply]
@Kusma I'm aware - but I think it may backfire because by not having a numbered entry, some people may not think they are "counted" like everyone else. — xaosfluxTalk 15:32, 14 June 2022 (UTC)[reply]
I don't think a person providing more clarity to crats on how their comments should be interpreted when deciding consensus is backfiring. Best, Barkeep49 (talk) 15:49, 14 June 2022 (UTC)[reply]
@Barkeep49 I'm specifically talking about people who would have previously !voted "Neutral" who now would not be allowed to. Yes, they could just put general comments in the comments section, but I think some of them will feel they are not "counted" that way because everyone else gets an incrementing number with higher visibility towards the top of the page. — xaosfluxTalk 00:08, 15 June 2022 (UTC)[reply]
Given the number of statements in the support and oppose sections, I think the most prominent ones will be the first few, and the last few before an editor places their comment. Comments in the current "neutral" section have greater prominence only because there are a small number of them. It's unclear to me, though, that this prominence is inherently warranted: why should someone's comments get greater prominence just for appearing in one section versus another? Comments in the general discussion section also get greater prominence if there are only a few; they lose prominence as more comments are added, as they do in all the other sections. There isn't a good solution for that. isaacl (talk) 00:33, 15 June 2022 (UTC)[reply]
Obviously we both know that this isn't how crats would read a discussion. But to the extent that it would be a fear among those who don't know better, I'm OK with it because it does send a signal about the intent of the person to the crats - that is there are mixed feelings that in the teeniest way tip towards oppose or tip towards support. As a believer in Wikipedia:Strong#What about "weak"? it seems like a legitimate way for the comments to get out there, while still having the same eventual effect on crats, as skilled diviners of consensus. Best, Barkeep49 (talk) 00:56, 15 June 2022 (UTC)[reply]
Keeping the neutral section because the folks who just want to hear their voice will still just want to hear their voice...that's sad. I guess it's better than a section headed "Place silly irrelevant stuff here, please." valereee (talk) 16:40, 22 June 2022 (UTC)[reply]
neutral Neutral votes do not hurt, and may express some useful point, but also don't help build an outcome. Graeme Bartlett (talk) 11:29, 14 June 2022 (UTC)[reply]
Oppose both — I see really no benefit in building up new regulations like this one because of the WP:CREEP. I think we have to pay attention to a more serious problem here: many adminship proposals are turned down too early. They are rarely discussed. Wikipedia has many problems that are non-technical. Cheers AXONOV(talk)⚑ 16:36, 14 June 2022 (UTC)[reply]
And with oppose !votes like this, it's easy to see why. For some reason, it's impossible to get any meaningful changes pushed through in RFA or any other realm of Wikipedia because of a widespread impulse to avoid anything that might hint at "changing the rules", as evidenced in the failure of the RFA reform effort last year. One thing that can be guaranteed by standing pat is that nothing will get better. WaltCip-(talk) 16:42, 14 June 2022 (UTC)[reply]
Support 1 Oppose 2 As long as people can reply to themselves then I support the first part of this proposal. Dr vulpes(💬 • 📝) 23:45, 14 June 2022 (UTC)[reply]
Support both, and especially the second. If you are torn between support and oppose, you can leave a comment explaining your justification, and that might help others decide (or not). 🐶 EpicPupper(he/him | talk) 23:53, 14 June 2022 (UTC)[reply]
Support 1, oppose 2 – Best to avoid staggering discussions across multiple sections or pages. The neutral section also helps for consolidation and offers a voice in the "main" thread for those who aren't comfortable supporting or opposing. ComplexRational (talk) 00:06, 15 June 2022 (UTC)[reply]
Support 1, oppose 2 - I don't see enough justification to convince me neutral votes are harmful in some way and understand the value some editors see in stating their opinions through such a vote. Nonetheless, I think the first proposal is a good one. — Ixtal( T / C ) ⁂ Join WP:FINANCE! 10:24, 15 June 2022 (UTC)[reply]
Oppose both — concurring with WereSpielChequers and Johnuniq, being able to directly comment on a user's vote is extremely important, not only for explaining why the vote might be inappropriate, but also highlighting the issue for the next or following participants hovering over that section; ultimately, greatly influencing the the way the next editor votes. The drive-by voters, of whom there are an abundance these days, might not bother to scroll all the way down to read various comments, many of which are more about the process than the candidate. Probably few participants take the time for a serious read of threads removed to the talk page unless it is about a juicy scandal.
Xaosflux's oppose of No.2 makes absolute sense.The 'neutral' section is also important because it is used and read by wavering voters. It is quite different from the quagmire of general chit-chat at the bottom of the page, and the neutrals could also be taken into consideration in a 'crat chat, or even by a single 'crat having a hard time reading a consensus in a close run RfA - it has happened but it would be suicide if I were to provide the diffs. (Sorry Barkeep49, I know you are hell bent on RfA reform - so was I for years, and still maintain that change is needed - but I think these 2 proposals are solutions looking for problems). Kudpung กุดผึ้ง (talk) 11:40, 15 June 2022 (UTC)[reply]
Oppose 1. Unless we disallow discussion entirely (I hope not), the only thing shunting replies to a different section or the talk page does is make it harder to follow. Support 2. Having a special section for people to explain why they're sitting on the fence is the most Wikipedia thing ever. There is no difference between a neutral vote and a comment. – Joe (talk) 11:54, 15 June 2022 (UTC)[reply]
Oppose 1. It would make it hard for the users to follow. Oppose 2: I agree with Xaosflux for the most part. --Baggaet (talk) 14:00, 15 June 2022 (UTC)[reply]
Oppose 1. The problem with RFA is not people responding inline, it's people responding uncivilly. This will not fix the problem and, per others above, will introduce others. Thryduulf (talk) 14:19, 15 June 2022 (UTC)[reply]
Support 1 Just a baby step towards what we need which is to organize a substantial, polite focused discussion (including participation by the nominee) in important areas of question. Mild oppose to #2 I was going to vote "neutral" on removing "neutral". :-) "Neutral" is a way to express actual sentiment and not remove participation by those who aren't in the other two choices. North8000 (talk) 14:37, 15 June 2022 (UTC)[reply]
Support both - I wanted to wait until my RfB was over before making any comments here. I feel like I'm in a unique position having been through two RfXs in two years. My general thoughts are that the neutral option is very similar to just not voting at all. I get that sometimes a user may want to spoil a ballot - but that information would be the same in general comments.
In my eyes, one of the bigger issues at RfA is badgering (or at least people being accused of it). Very few people strike their vote after having someone comment on it. Having the discussion over issues at a different place is helpful in my eyes. Having the discussion happen immediately after the !vote cast is quite combative, whilst a ping to a discussion thread would be a little bit more calm. I know I would feel like others were suggesting my comment was much less valid if I had a direct response than a ping to a discussion.
That being said, discussions that happen, but aren't actually about the user in question (such as at the RfB, where there was some valid concern about security risks for having additional users with higher rights/2FA) are helpful, but shouldn't fill up the RfA page. These should be more more swiftly to the talk, or better to WT:RfA. My rfA had a valid discussion about the state of WP:GAN, but it's not helpful in discussing the candidate. Lee Vilenski(talk • contribs) 17:09, 15 June 2022 (UTC)[reply]
Oppose 2: Neutral votes don't harm. No need to remove them. Someone might be great at one thing but not so much at the other. We may want to cast a neutral vote. Abstaining is not a solution, because someone else coming to the RfA may find the reasoning useful in deciding their vote. Maybe, of the points I raised, the "other thing" matters more to them. Because the candidate is not good at that "other thing", and my vote brought it to light, the voter now has a clearer picture and vote accordingly. That's what I do, keep reading every incoming vote (S/O/N) to ensure that I don't miss something. And ofcourse, when S/O ratio are in 'crat discretionary range, the crats may find something useful in the neutral section to base their final decision. Neutral on 1. —CX Zoom[he/him](let's talk • {C•X}) 09:13, 16 June 2022 (UTC)[reply]
As a 'crat that closes RfX's sometimes: I currently give more weight to a "Neutral, Leaning x" (though less weight than a "weak x" in the support/oppose sections) than just a comment in the general discussion area. The general discussion area is still relevant and important - especially if there are specific issues raised in the numbered section that get more resolved in expanded discussion. Most of this is only relevant in close-calls of course. — xaosfluxTalk 10:00, 16 June 2022 (UTC)[reply]
Oppose 1 per WereSpielChequers. Really don't care about 2, but it seems like a pointless change just for change's sake. Boing! said Zebedee (talk) 15:00, 16 June 2022 (UTC)[reply]
Oppose 1 per WereSpielChequers; far better would be more active clerking or consistently removing to the talk page after two extra comments instead of it sometimes happening & sometimes not.. Oppose 2 because it's a solution looking for a problem, and because the Neutral section can be of use. Happy days ~ LindsayHello 13:15, 18 June 2022 (UTC)[reply]
Endorse 1, oppose 2. The first option prevents users from bludgeoning another for their opinions. However, I believe the neutral page has its own utility, and should be kept (at least for bureaucratic consideration when closing an RfX). Thanks, NotReallySoroka (talk) 06:48, 19 June 2022 (UTC)[reply]
Oppose 1 because of the occasional newbie RfA !vote that's like "XTools says that the candidate has 3,000 deleted edits, so they must have made 3,000 bad edits!" – for blatantly erroneous statements like these, I think it is important to keep the factual correction as close as possible. DanCherek (talk) 21:58, 19 June 2022 (UTC)[reply]
Oppose both. I opposed to 1 because, in some circumstances, replies asking for clarification should be immediately asked instead of being asked on the Talk page purely because of procedural reasons. I agreed that if the conversation becomes long it should be taken to the Talk page, but there are circumstances where it should not be taken to the Talk page. I opposed to 2 because Neutral votes are valid votes regardless. Being Neutral and unable to form up your decision is different from abstaining in the RfA process. People that voted Neutral have their opinion and reasoning as well - and this may sway the Support/Oppose voters, and should be kept in the procedure. ✠ SunDawn ✠(contact) 11:22, 22 June 2022 (UTC)[reply]
Oppose both per WP:CREEP, WP:BROKE. I don't see these proposals as solving any problem, and they seem like they would needlessly stifle discussion. RfA has many problems, neither the neutral section nor the ability to reply to comments is one of them. ~Swarm~{sting} 05:24, 23 June 2022 (UTC)[reply]
Oppose both because this makes RFA a vote, not a discussion. --Rschen7754 05:48, 23 June 2022 (UTC)[reply]
Oppose both. The proposals just seem to make contributing more awkward. Flexibility is good, as is not having to switch to the talk page but rather simply to scroll down. Jmchutchinson (talk) 10:34, 23 June 2022 (UTC)[reply]
Oppose both don't really see how this would help anything and option 1 especially is at odds with how similar discussions usually work. Hut 8.5 17:27, 23 June 2022 (UTC)[reply]
Oppose both but remove the General comments section. I think off-topic discussion or further discussion about a vote can be moved to the talk page, the procedure exist for that. Also neutral votes may count as an idea (because some user may both support and oppose at some point) Weakest possible support/oppose may make it harder for crats to close RfX. Thingofme (talk) 02:39, 24 June 2022 (UTC)[reply]
Support both, less drama --> more productive conversation --> improving Wikipedia faster. Also, neutral votes can be moved to general conversation stuff, and there will be less stress to the nominees. CactiStaccingCrane (talk) 05:28, 24 June 2022 (UTC)[reply]
Oppose both (firstly, I thought I'd answered, but it seems to not be here. Please ping if I've double !voted). Neutrals provide a single clear reason (or set of reasons) for that position in a way that general discussion does not. I would not include general discussion in the consideration of the outcome, and without that, neutrals would be ignored when they shouldn't always be. It's also useful for other participants. I also find some degree of immediate clarification helpful, and thus would oppose the other point. More aggressive clerking to move to Tp as required, however, would be fine. Nosebagbear (talk) 12:38, 24 June 2022 (UTC)[reply]
Oppose both. I oppose 1 because discussion should be centralized, and that proposal would disperse it. I also oppose 2 because RfX is not a vote. It's valuable to count the balance of opinion, which is why we use numbers in the first place … and mixed opinions form part of that balance of opinion and should be counted, which 2 would discourage. Moreover, 2 would move things closer to looking like a vote, which should generally be discouraged. {{Nihiltres |talk |edits}} 16:03, 24 June 2022 (UTC)[reply]
Oppose 1: this cannot be done so long as RfA is not a vote, but determined by assessing consensus, and so long as people can make false comments in the Support/Oppose sections. My issue with the toxicity of RfA is most commonly the content of Oppose !votes, and second-most commonly the content of replies to Oppose !votes. This change would likely fix the second-most common issue at the expense of exacerbating the first. Additionally, though hardly the best way to run things, the possibility of replies to your Oppose !vote inline creates a social stigma against making inflammatory and unverifiable claims. Support 2 because I have never seen a use for the Neutral section that could not be served by general discussion and the section generally adds to the word count of the RfA without particularly increasing the quality of discussion—the length of each RfA page adds to the pressure of running as a candidate. — Bilorv (talk) 17:17, 24 June 2022 (UTC)[reply]
Oppose both. While RfA is in reality about the closest thing we have to a "vote" system, with perhaps the exception of ArbCom elections, we shouldn't be making it more that way. Rationales for an editor's position should be open to discussion and challenge right there, not put off somewhere that people reading it later might not see. Similarly, an editor who has chosen to neither support nor oppose but has something to say should be able to do that, and a "Neutral" position is already a logical way of doing that. If discussions get excessively long, they can still be moved to the talk page, but with a pointer to that discussion right there with the vote so that interested parties will know that there is a discussion about the matter and can read it if they choose. SeraphimbladeTalk to me 04:54, 25 June 2022 (UTC)[reply]
Oppose 1 per WereSpielChequers et al. I'm imagining trying to read my way through a long RfA and having to bounce up and down to figure out what people are responding to in the comments. No way is this interface up to that task. Indifferent leaning oppose 2 - Joe Roe is right, it's the most wikipedia thing ever—but is that really the heart of the RfA problems? It's mostly harmless and is appreciated by some. Retswerb (talk) 05:10, 25 June 2022 (UTC)[reply]
Oppose both. Solution in search of a problem. There are many issues with RfA, however these proposals wouldn't accomplish anything aside from introducing pointless complexity to the process. -FASTILY 06:50, 25 June 2022 (UTC)[reply]
Oppose 2 Forcing users to choose a side does a disservice to those who have mixed feelings about a candidate. Also, I trust the closing crats to properly interpret whether !votes in the neutral section should be weighed for or against promotion. Iffy★Chat -- 18:42, 25 June 2022 (UTC)[reply]
Oppose both - I was actually leaning towards supporting 1, because I've seen too many times people being uncivil in responses to opposers, but WereSpielChequers argued convincingly and ultimately the solution to uncivil behaviour is to make sure it is corrected directly. I don't really care whether people are neutral or not and I don't see how getting rid of the neutral section actually improves things. "Neutral" votes are typically just parking to see whether any momentum is going to get behind opposing the candidacy, or to share information and let others oppose, but these are not actually bad things. FOARP (talk) 13:56, 27 June 2022 (UTC)[reply]
Oppose 1, support 2 It's very difficult to follow a non-threaded discussion. Moving the replies to a particular support/oppose statement to a different section right out of the gate can be very confusing and, quite frankly, will be nigh impossible to enforce. If a reply thread gets out of hand , either collapse it or move it to the talk page and link to it. As far as eliminating the neutral section, it is my understanding that neutral statements aren't included in the final percentage calculation anyways, so the fear of not being "counted" is literally unfounded. As has been stated previously, no one except the nominee is required to participate in any RFA/RFB discussion. Many times I haven't felt strongly for or against a candidate, and I simply did not participate. Even if the neutral section is eliminated, an editor's comment is "counted" when they sign the comment and hit "Publish changes." — Jkudlick ⚓ (talk) 19:50, 27 June 2022 (UTC)[reply]
General comments
Q: what does it mean by The neutral section will be eliminated at Requests for Adminship/Bureaucrat? It sounds like there would be only two sections: support, and oppose. Did I get it right? —usernamekiran (talk) 19:36, 13 June 2022 (UTC)[reply]
OP has explained it in their support. duh me. —usernamekiran (talk) 19:38, 13 June 2022 (UTC)[reply]
You shouldn't have to read my support to make sense of this so I've slightly modified the statement to add clarity. Best, Barkeep49 (talk) 20:01, 13 June 2022 (UTC)[reply]
Probably too late now, but might have been better to split this into 2 RFCs originally. It's hard to take the pulse of this and see what way this is trending without a very thorough read, due to the mixing of two questions. –Novem Linguae (talk) 01:48, 15 June 2022 (UTC)[reply]
This may just be my pet peeve, and its not as bad as it used to be, but I always thought "placeholder" neutral votes are self-important nonsense. "I haven't taken the time to actually form an opinion, and I just wanted that noted for the record" is just noise. If nothing else we should ban/remove those. Beeblebrox (talk) 19:35, 16 June 2022 (UTC)[reply]
Huh, I totally missed that previous discussion. Interesting. I think just removing them is still the right move, but if we remove the neutral section altogether that will obviously be a moot point, so I guess we'll wait and see what happens here first. Beeblebrox (talk) 21:52, 19 June 2022 (UTC)[reply]
The basic issue is that although there have been placeholder statements from newcomers (perhaps thinking that their participation had been solicited and thus they felt compelled to say something), they've also come from long-time editors, who would likely be displeased with having their comments removed. Thus the benefit-to-dissatisfaction ratio of enacting a new rule is fairly low, particularly considering the small number of such statements. (On the other hand, perhaps it happens so infrequently now that a rule could gain acceptance with only minor discontent? On the third hand, if it's out of fashion then it's a non-issue.) isaacl (talk) 16:26, 21 June 2022 (UTC)[reply]
Cite physical work
Why there is no one template for cite physical work like there is one cite web? There are three different Cite magazine, Cite encyclopedia and Cite book and probably more but maybe there is something universal? What if PDF file isn't a book, magazine or encyclopedia? Eurohunter (talk) 17:04, 16 June 2022 (UTC)[reply]
Define what a "physical work" is here. Headbomb {t · c · p · b} 18:52, 16 June 2022 (UTC)[reply]
@Eurohunter If you cite a book you are holding in your hand, you use the same template, just don't add a weblink/url. Those are not mandatory, just practical when available. Gråbergs Gråa Sång (talk) 19:26, 16 June 2022 (UTC)[reply]
There are plenty available - see box at right. Whilst all of them accept a |url= parameter, they are primarily for hardcopy sources, with the exception of {{cite AV media}}, {{cite episode}}, {{cite web}} and one or two others. --Redrose64 🌹 (talk) 19:49, 16 June 2022 (UTC)[reply]
@Gråbergs Gråa Sång:@Redrose64: I mean their PDF versions so sometimes it's document which is not book or magazine - no one know what it exactly is so it need wider term than book or magazine. Eurohunter (talk) 19:50, 16 June 2022 (UTC)[reply]
If the pdf is a scan of a book, just cite to the book. If it's an original pdf, I would think that you would cite the website it came from.--User:Khajidha (talk) (contributions) 21:02, 16 June 2022 (UTC)[reply]
If there actually is a proposal in this section, it is hard to figure. The heading mentions "physical work" (presumably as opposed to a virtual work), but the OP mixes it up by mentioning pdf, a (virtual) file format. I was under the impression that the OP was asking for a catch-all {{cite xxx}} template for physical (real) works with no specific classification, similar to the way {{cite web}} may be used for some (virtual) online works, when such works cannot be otherwise classified. But the continuing references to pdf make me wonder. 50.75.226.250 (talk) 14:48, 17 June 2022 (UTC)[reply]
The point isn't to classify the source. The point is to get a properly formatted citation for the kind of thing that you're citing. In this case, magazine articles and generic documents use the same citation formatting, so it's the same template. You can use the redirect name if you want. WhatamIdoing (talk) 00:50, 23 June 2022 (UTC)[reply]
The whole point of citing anything is so the reader can go check the source and verify the claim. If you don't know what medium what you're citing even is, better not cite it. Nardog (talk) 01:27, 23 June 2022 (UTC)[reply]
I dunno about that. The difference between "an article" and "a report", or between "a long report" and "a short book" can be difficult to discern. That doesn't make the source unusable. WhatamIdoing (talk) 01:50, 23 June 2022 (UTC)[reply]
Temporarily lock an article
NBA 75th Anniversary Team clearly states: Statistics are correct through the end of the 2020–21 season, the season last completed before the list was announced. And also: which doesn't keep folks from adding Steph's and Steve Kerr's recent NBA title.
And since having an account on the wiki doens't induce reading skills, I suggest a hard lock for everyone until hte hype has died down.
The right place is WP:RFPP, but you'd have to make the argument there that this problem disrupts the article so much atm that protection is needed. I see someone commented on this at Talk:NBA 75th Anniversary Team, that may have some effect. Gråbergs Gråa Sång (talk) 11:06, 18 June 2022 (UTC)[reply]
Sections are archived automatically by a bot, just wait a couple of days without editing the thread. Sungodtemple (talk) 16:28, 18 June 2022 (UTC)[reply]
For this particular page, it's nine days after the most recent post. So if nobody else posts in this section, this will be eligible for archiving at 21:00, 27 June 2022 (UTC). --Redrose64 🌹 (talk) 21:00, 18 June 2022 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
This RfC attempts to gauge a consensus for a reform of clerking at RfAs/RfBs, which is proposed due to much discussion on that topic during a recent RfB. The general proposal is submitted below for evaluation, please share your thoughts. Szmenderowiecki (talk) 23:50, 20 June 2022 (UTC)[reply]
Bureaucrats may !vote but may not clerk discussions. If they submit a !vote, they shall not be active during the determination of consensus for approval of the request for adminship/bureaucratship and may not participate in the bureaucrat discussion, if it is started.
A clerk that has had substantial interaction with the candidate in question, or has nominated the candidate for RfA/RfB, must refrain from clerking it.
The clerks must refrain from making comments in support or opposition of the candidate, and shall not modify or remove the comments based on whether the clerk agrees or disagrees with the opinion expressed there, but may only do so in case of violation of civility. They shall make explicit any intervention in the comments, along with the reasoning of intervention.
Using their administrative tools (if they have access to them), the clerks may ban the editor from the RfA/RfB they are participating in case of persistent refusal to maintain decorum, but only for the duration of that RfA/RfB. A general ban from such discussions may only be enacted following a discussion at the administrator's noticeboard.
Any sockpuppetry/meatpuppetry investigations, or those of canvassing, if started by a clerk or a bureaucrat in relation to an RfA/RfB, must be resolved as a first priority.
The community will determine the venue of appeal or review of clerk's actions. (Formulated that way due to the current uncertainty over the existence of XRV and its scope)
The Arbitration Committee may, if the rational usage of user resources so requires, appoint more clerks.
Rationale (Clerk reform at RfA/RfB)
In 2011, there was a proposal to introduce clerking as an ad hoc role for administrators and non-administrators in good standing alike, but it was not approved. The 2015 RfC established that bureaucrats may have the right to clerk discussions. In the answers submitted as part of the most recent RfB, however, Wugapodes, an (unsuccessful) candidate for a bureaucrat, said that bureaucrats are reluctant to clerk the discussions themselves, particularly since they may be perceived as non-neutral if they intervene. There has been some discussion during the RfB of the proposal of more active clerking as a way to reduce the stress and drama that often accompany the process, and there seemed to be some support to let it have a try, though not much certainty over the effectiveness of such a solution.
This proposal suggests a change from the bureaucrat-enforced decorum (which apparently does not work) to clerk-enforced decorum. Clerks are supposed to be experienced in dealing with incivility, which is often in ample supply at ArbCom, and the ways to respond to it. A drawback to this solution is that there are few clerks to begin with, and some bureaucrats are already arbiters. That said, let's try this proposal to see if people agree to make some sort of change, or even if it fails, we could see where the community in general stands on this issue. Szmenderowiecki (talk) 23:50, 20 June 2022 (UTC)[reply]
Feedback (Clerk reform at RfA/RfB)
(summoned by the bot) I applaud such efforts but 'Oppose This would be 8 new rules and procedures to solve 2 non-existent problems. The big problem at RFA isn't uncivil decorum, the problem and fix is more complex than that. And Wikipedia already has rules and processes regarding uncivil behavior. But thanks for such efforts. Sincerely, North8000 (talk) 12:02, 21 June 2022 (UTC)[reply]
If approval for sanctions is determined at the administrators' noticeboard, then I think any uninvolved administrator should be able to evaluate consensus (and, if deemed necessary, implement any suitable blocks). I don't think it's a good idea to prioritize sockpuppet investigations for an internal procedure versus those for mainspace edits. If necessary, an internal procedure can be put on hold or extended, without consequences to readers. Regarding the 2015 RfC, note the option of "any editor" received almost as much support as "bureaucrats", which is in practice what is done today. (On more minor editorial notes, the first sentence of point 2 is redundant with point 1, and point 8 is always generally the case.) isaacl (talk) 16:03, 21 June 2022 (UTC)[reply]
Feedback on components:
I don't see any reason to forbid 'crats from clerking. I also don't like the idea of having arbcom be in charge of RfA's (as they are in charge of the arbcom clerks). I vote for arbcom members for dispute resolution skills, not for this.
'Crats already recuse when appropriate; this sets up a scenario that could prevent closure (as recusal isn't required if every active crat participated in an RFA it would be stuck - in practice this doesn't happen as the majority of 'crats do abstain from !voting.
There are currently only 4 active clerks - who are also active throughout the project - some are already likely to have interacted with admin candidates.
Volunteering to clerk arbcom cases should not disenfranchise someone from participating in RfA's.
"Bans" don't require admin tools, and I don't think we should have any situation where a single editor can ban another one.
CU's are volunteers - dictating the order of their work, or that they must volunteer to do something before they are allowed to volunteer to do other things is very anti-volunteer.
Um, sure.
Arbcom can already appoint as many clerks as they want.
So, I think there are many problems with this as proposed. I am fairly open to expanding the 'clerking' capacity of our 859 strong admin corps. — xaosfluxTalk 12:59, 22 June 2022 (UTC)[reply]
Oppose. While some RFA/RFB discussions could be better, this amount of bureaucracy isn't going to resolve the issues and could lead to others. Thryduulf (talk) 11:56, 23 June 2022 (UTC)[reply]
I'd quite like to see some sort of "authorized" clerking system, but this seems like too much. What's needed are a few admins who are clear on what won't fly at RfX and what to do about it. Whoever clerks an RfX shouldn't !vote in it, but otherwise they really don't need any special qualifications. valereee (talk) 13:34, 24 June 2022 (UTC)[reply]
I'd also oppose - let's have Crats (those who don't (!)vote) clerk. In the same way that admin actions don't make someone INVOLVED for a future admin action, clerking would not logically disqualify from 'cratchats anyway. Nosebagbear (talk) 16:26, 24 June 2022 (UTC)[reply]
Oppose - I'm a longstanding proponent of clerking at RfA, to the extent that I myself wrote a proposal over a decade ago. So this definitely caught my attention. And then immediately lost it with the very first point. I find the proposal to be tone deaf towards the RfB that inspired it. The RfB mostly failed because the user was an active arbitrator, and a significant group came out in opposition to the existence of an overlap between the two roles, with many comments clarifying that it is nothing personal against the user. I certainly don't think the community wants a special class of people hand-picked by Arbcom to be policing RfA, when they don't want even the most uncontentious arbitrator policing RfA as a crat. In spite of this result, it did not fail because the community doesn't want crats to clerk RfA. Indeed, the community has repeatedly established that it supports the notion of crats clerking RfA, it is supported by a formal RfC, and based on the RfB, this hasn't changed. ~Swarm~{sting} 05:36, 25 June 2022 (UTC)[reply]
Oppose: How does this solve anything is beyond me. I might be dumb but please don't tell me that sockstriking a sock's !vote at a RfA would get me blocked just because I'm not a ArbCom clerk. —CX Zoom[he/him](let's talk • {C•X}) 20:43, 25 June 2022 (UTC)[reply]
We are currently investigating a number of visual improvements to Special:Search, to enable users to better find the information they are looking for. This is part of a greater initiative that we are conducting, called “Search Improvements”, and we are interested in hearing your feedback.
What do we want to do?
As you will see, most of the proposed changes are graphical improvements to the current way Special:Search looks like. Our goal is to provide better context and better layout for casual readers who want to use the Wikipedia search page, as well as promote awareness for Wikipedia’s sister projects by rearranging the “sister projects” search section.
By clicking on the blue links, you can see a mockup of the proposed changes. You can also see all mockups at a glance by visiting the Search Improvements project page on Mediawiki.org.
What are we asking you?
We want to hear from you about these proposed changes. None of these suggestions is currently set into stone, and before deploying them we want to hear your opinion about them.
More specifically, we would like to know:
What do you think about the approach that we outlined above?
Do you think that any of these changes can affect the contribution flow? If yes, how?
Do you think that these changes can improve the experience of new users or casual readers?
Your opinion is important to us, and we want to use it to inform these changes before we eventually deploy them, if there is feedback to do so from all communities.
How can you give feedback?
You can reply to this message here (please remember to ping User:Sannita (WMF) when you do) or on Mediawiki.org. We plan to keep this consultation going for around three weeks, from today until July 10, 2022.
We are also planning on hosting an office hour on June 28 at 15:00 UTC (link to the meeting), where you can ask questions and directly reply to the team about the proposed changes.
If you want to improve the search page it would be great if you can fix phab:T215117. 90.227.175.244 (talk) 18:05, 21 June 2022 (UTC)[reply]
Hi 90.227.175.244, I just received a confirmation from the dev team that they will start working on that fix. I cannot promise anything about when the bug will be fixed, but it will be fixed for sure in the coming weeks. Thanks for bringing it up! Sannita (WMF) (talk) 17:20, 29 June 2022 (UTC)[reply]
@Sannita (WMF): Like Ahecht, I'd like to not have thumbnails until phab:T306246 is resolved. Also, I'm not sure if collapsing the advanced search options is a good idea. Instead I think, moving the "sort by" option between the "blue Search button" and "Results 1 – 20 of 859" would be more intuitive for casual readers. All the other proposals look really nice to me. Best. —CX Zoom[he/him](let's talk • {C•X}) 19:43, 21 June 2022 (UTC)[reply]
@Sannita (WMF): On second thought, casual readers would not care much about when a certain article was created or when it was last edited. Such sorting is useful on e-commerce sites but probably wouldn't be here. So sorting system is probably best placed where it already is. —CX Zoom[he/him](let's talk • {C•X}) 13:45, 22 June 2022 (UTC)[reply]
@Animal lover 666 It's better than nothing. I'd rather have a few "meh" images not appear than unexpected graphic images showing up in benign search results (for example, a search for "Iran's Penal Code" shouldn't show a thumbnail for Anal sex, and a search for "Canadian Holstein cows" shouldn't show a thumbnail for Anogenital distance). --Ahecht (TALK PAGE) 14:46, 22 June 2022 (UTC)[reply]
@Ahecht, @RoySmith, @CX Zoom, @Animal lover 666: thank you so much for your interventions and your feedback! I already reported your comments to the dev team.
Regarding T306246, someone is looking currently at the bug. I'll keep an eye on it too, just to be sure that it doesn't get in the way of our development. Regarding T146418, it doesn't apply to our current sprint, but we will take it into consideration for our next steps. I'll keep you posted about it.
Thanks again for your feedback, and if you have more, please keep it coming! :) Sannita (WMF)talk) 12:04, 23 June 2022 (UTC)[reply]
Love all except for 3 and 7 Most of these improvements look fantastic and greatly needed. I would personally oppose removing the outlines for the sister project search, as it makes it less clear and accessible, but I would support changing the color/transparency of the outline and making it rounded. The new position for the new article message also seems a bit wonky, but changing the position in general is fantastic. Thanks for all of your work! 🐶 EpicPupper(he/him | talk) 16:59, 24 June 2022 (UTC)[reply]
New page search engine NOINDEX duration
In 2012, an RFC decided that unpatrolled articles should be NOINDEXED until reviewed and accepted. In 2016, it was implemented differently as discussed here. At that time, it was assumed that new articles would be patrolled within 90 days and it would be sufficient to only honor NOINDEX on mainspace articles for 90 days. The New Page Reviewer user group is at present unable to review articles within 90 days (there is a backlog of 14,000) and proposes that the original RFC be fully implemented (that that the no-indexing of unreviewed articles be extended indefinitely).
There was some consideration of changing the NOINDEX period to 180 or 365 days to cope with the immediate backlog, but the NPP consensus is to follow the RFC which said Noindex unpatrolled new articles. There was also concern that since the RFC was 10 years ago, it would be good to get wider re-affirmation.
A quick summary of pros (may not be exhaustive)
preventing the dissemination of potentially harmful information (copyvio, attack pages)
preventing commissioned works by UPEs from slipping through
motivating authors to write better articles (properly sourced articles are usually patrolled quickly)
A quick summary of cons (may not be exhaustive)
an important news article may not be immediately visible in search engines (although obviously notable topics are usually patrolled quickly)
an increase in the number of WP:HELPDESK questions like "why doesn't my article show up in Google?"
As I noted at phab:T310974 - this doesn't yet seem to have been very well advertised; especially as it impacts all article writers. Suggest adding to CENT and tagging as an RFC. — xaosfluxTalk 21:07, 28 June 2022 (UTC)[reply]
I think it would be best to do as suggested by xaosflux, if only to ensure each of our behinds are adequately covered — does that sound okay MB? — TNT (talk • she/her) 19:50, 29 June 2022 (UTC)[reply]
@Xaosflux, TheresNoTime, and MB: This is only one of the immediate solutions required by NPP. Others are also being implemented in an attempt to keep the encyclopedia free of spam and other totally inappropriate mainspace content. This software modification request is essential and urgent and concerns uniquely the huge workload of the New Page Reviewers, and hence the need to avoid unpatrolled pages entering the encyclopedia corpus as verified suitable for indexing by search engines.
It is a request local to the New Page Review system and its authorised users and does not need a broadly publicised RfC. It does not impact all users in any way - having your article referenced is an advantage but not a right; nowadays most of the new articles that are submitted are unlikely to benefit greatly from being listed by Google. Like most websites, Wikipedia does have its own built-in search engine.
The vast majority of new pages that exceed the previous 90-day limit are borderline notability or suitability cases that have either been left for reviewing by more experienced patrollers or simply could not be reviewed in time - the backlog is immense; backlog drives have had some minor effect but it would still take a year or more to clear it. Each time the backlog has been successfully cleared by an all-out campaign, the reviewers have relaxed their participation and the backlog has very quickly grown again to an untenable extent.
Of the 700+ New Page Reviewers, less than 10% are active and very few are sufficiently experienced to patrol the pages quickly but accurately, and others are leaving due to burnout. New Page Patrollers, like all the other maintenance workers, are not paid for what has become a boring, mind-numbing, and thankless task and it is therefore irresponsible to continue submit them to stress. and make those who actually do it feel guilty for not doing enough. Enough is enough. Kudpung กุดผึ้ง (talk) 20:11, 29 June 2022 (UTC)[reply]
The English pages List of fifth intervals also talks about different fifth intervals. But the article has been moved, so that one can not link to other wikidata from List of fifth intervals.
Those mentioned above are a series of intervals. Some articles talks about exactly one interval, some others talk about several kind of intervals, other languages alike. It is for sure that different intervals are of different importance. I also suggest to look through all above to check consistency and the interlingual links if we can find a better solution.
I am confused as to what we are considering here… is the question about what to name the article? This isn’t the right venue for that. Raise it at WP:RM. Blueboar (talk) 21:59, 28 June 2022 (UTC)[reply]
Fix the wikidata. List of fifth intervals does not link to any articles of other languages now. I strongly suggest linking List of fifth intervals to wikidata:Q224169. Whether to rename it or move it, doesn't bother me. As mentioned above, it talks about the same thing, and should be linked to other wikis. --吳傲雪 (talk) 03:56, 29 June 2022 (UTC)[reply]
The situation at colors
Gulp, well I started something that I hope gains acceptance but at least others can look, advise, complain, etc. The situation:
Blue gets about 1400 views/day. Prior to yesterday, the article was 123,000 bytes long. It consisted of two main themes: technical content (optics, dyes, natural occurrence) and cultural material (artwork, symbolism). The cultural material included about 20-30% bulleted lists of where blue is somehow significant (politics, gender, sports, religion...).
So I split the article into blue, which retains and expands the technical content (34,000 bytes and growing) AND colour blue in culture (86,000 bytes). I have been actively cleaning up blue. I had asked the color project about my idea but concluded that that project was moribund. So I proceeded. Here, User:Mathglot comments on my edits and urges me to reach out more broadly, hence this message.
The implications of my actions are nontrivial because articles on colors are heavily consulted, and my action on blue vs colour blue in culture could be a model for future actions on primary and maybe secondary colors. These color articles tend to accrete a lot of imagery and factoids, by the way.
Another component of this message is that I could use some help. I will stop my editing of these articles if concerns outweigh support for this venture. --Smokefoot (talk) 18:15, 24 June 2022 (UTC)[reply]
Smokefoot is a good faith editor who initiated an undiscussed split of Blue, and has been doing a good job of tidying up. While the split was a WP:BOLD move, I see no reason to undo it at this point. However, as this may lead to similar splits at a number of other color articles (Orange (colour), Green, Red, etc.) I suggested at the Talk page that he seek consensus for future color-article splits at a forum with better traffic than an inactive project, and here we are. Mathglot (talk) 18:29, 24 June 2022 (UTC)[reply]
Why do we need consensus to split articles? Is there disagreement? This seems inline with WP:BRD — PerfectSoundWhatever (t; c) 01:58, 25 June 2022 (UTC)[reply]
I don't think you need consensus, but it's a good idea for a large and high-profile article like this, per WP:CAUTIOUS (which is policy, though a rather gently-phrased one). It's also good for the person making the changes, so that they don't end up doing a lot of work for nothing. But most of our articles and Wikiprojects bear rather obvious evidence to the fact that nobody's around to hear any proposals anymore, which I guess is why this would end up on the Village Pump. -- Visviva (talk) 05:00, 25 June 2022 (UTC)[reply]
The split seems logical to me. As for the other colours question, it should logically be dealt with on a case to case basis, when a section of an article becomes too long per WP:SPLIT. I'll try to help out to improve Blue where I think it could need it. But @Smokefoot:, shouldn't the title of the article be Blue in culture? What else would "blue" refer to? — PerfectSoundWhatever (t; c) 01:35, 25 June 2022 (UTC)[reply]
Perhaps Blues may be confused with this? 0xDeadbeef 02:11, 25 June 2022 (UTC)[reply]
I've never heard the non-plural "blue" used to refer to the genre. A hatnote to pointing Blues#In_popular_culture would probably solve any unlikely confusion. — PerfectSoundWhatever (t; c) 02:13, 25 June 2022 (UTC)[reply]
Honestly, I'm not seeing an intrinsically difference, topic-wise, between the color and the culture around the color, the essence of blueness is the core of each. Having said that, that is more of a preference and certainly not something to war over, or even vote to re-combine if it ever came to that. It is what it is. I do think Blue in culture would stylistically be a better title, per above, too. Zaathras (talk) 02:10, 25 June 2022 (UTC)[reply]
The split seems reasonable to me, and I applaud the use of a summary section in the main Blue article. But then again I have no idea what people are looking for when they search for a topic like "Blue", which would be a helpful thing to know in terms of how our coverage of topics like this should be configured. I wonder if there is any quantitative data on this. Are they looking for a definition? Technical information? Pretty pictures of blue stuff? -- Visviva (talk) 05:05, 25 June 2022 (UTC)[reply]
I Think that splitting blue in culture away from blue in optics is a very bad idea, It greatly reduces the utility and quality of both articles. Now you have to search two different articles to find basic information that should be in one. the German, Spanish and French Wikipedias do not split up color articles. the reduced lead montage on blue is also very unsatisfactory. Please return to a single article on each color, and use the format used in the other color articles. SiefkinDR (talk) 15:54, 25 June 2022 (UTC)
Wikipedia has a chronic bias toward the technical aspects of a topic over the cultural aspects. That's both because of the interests/background of the majority of editors, and because the technical aspects are easier to write about than the cultural aspects, especially for broad topics. When something has both technical and cultural aspects, like a color, there's substantial risk of poor weighting. So while I'll leave it to your discretion whether to split out the culture section, Smokefoot, the main article blue will almost surely have far more pageviews, so I'd definitely urge you to consider starting from a broad level how to make sure there's enough WP:DUEWEIGHT for the cultural aspects in that article. {{u|Sdkb}}talk 19:38, 25 June 2022 (UTC)[reply]
@PerfectSoundWhatever: It's not such a bad idea, because having Blue as the parent article of two child articles would solve the WP:DUEWEIGHT issue at Blue, and also allow the child articles to be independently developed to different sizes without regard to due weight, which only applies within articles and not across them. (That is, Shape of the Earth is 23 kb and barely says anything about "Flat Earth" theories, because it would be highly WP:UNDUE in that article for such a FRINGE theory, but the article Flat Earth itself is triple the size (77 kb), which is perfectly fine, because it is restricted to its own space and UNDUE does not apply. Same thing for articles like Fringe theories about the Shroud of Turin: once split off, they have their own DUEWEIGHT considerations that do not apply outside the article.) In this same way, Blue is 43kb (up from 30kb at the split), and Blue in culture is over twice that, which isn't a problem now, but might be a problem in a unified article, depending what one considers the appropriate WEIGHT between cultural and other aspects. As far as overall size is concerned, studies show that most readers don't even read past the LEAD of an article, so the idea of making Blue into a relatively brief article in WP:SUMMARY STYLE with a couple of smallish body sections summarizing optics or science on the one hand, and culture on the other, is not such a bad one, and would solve several of the problems mentioned above, while still serving our readers well without an overly long article that they won't read anyway; readers may even be *more* likely to read about both the science *and* the cultural aspects if the article is considerably shorter. (Wouldn't call it 'Blue in science' though; maybe 'Optics of blue' or something; t.b.d.) Mathglot (talk) 19:44, 27 June 2022 (UTC)[reply]
I agree with the above. "Blue" is not exclusively an article about optics; blue in culture is equally important, and should have equal space in the article. It does not make sense to have the article on "Blue" that completely ignore history, art and culture.SiefkinDR (talk) 20:12, 25 June 2022 (UTC)[reply]
Not clear if you're talking about how it was, or how it is now. With 8 kb in the culture section at Blue, that section is half-again larger than the science section. I'd say that's probably too long for one summary style-section in a parent article for which a stand-alone child article exists. Or perhaps that's what you meant? Mathglot (talk) 23:39, 27 June 2022 (UTC)[reply]
I posted my comment one minute before Smokeyfoot added a 6k summary. What a fast typist! :-) Levivich[block] 00:16, 28 June 2022 (UTC)[reply]
Oppose This split seems quite arbitrary as the original article still contains sections about clothing, religion and other cultural aspects. Denigrating some cultural aspects in this way is unwise because it tends to generate a repeating cycle. See WP:CARGO for details.
When a reader goes to a broad topic such as blue, they may have something specific in mind or they may wish to browse. To assist their navigation, we should address the topic at quite a high level as there are likely to be many sub-articles such as shades of blue, Blue (university sport) and so on. Just about every aspect has some cultural implications and so that's not a useful sub-division.
Note also that the concept of blue is not universal as some languages such as Russian do not have a single corresponding word. So, the very concept is a cultural artifact.
Now, we could remerge *Red in culture and Red because we know what is good for readers. Or we can recognize that Red is providing the information sought, by and large.--Smokefoot (talk) 23:35, 28 June 2022 (UTC)[reply]
Red in culture is another arbitrary and unhelpful split. Note that it has a section In religion which seems identical to the same section in the main article. It's just a WP:REDUNDANTFORK and so "the more recent article should be merged back into the main article". Andrew🐉(talk) 12:52, 29 June 2022 (UTC)[reply]
Add Armenian and Georgian languages to the other languages list on the bottom of English Wikipedia
Hi Wikipedia users and Admins!
I have a request which is to add Armenian and Georgian languages to the other languages list on the bottom of English Wikipedia since these two Wikipedia languages have more than 100K+ articles and should be finded quicker on the bottom of English Wikipedia in the other languages section.
Please note that is my desire to see these languages, the choice is of admins.
A single letter with a period should always be disambiguated
Most instances of a letter of the English alphabet followed by a period point to a disambiguation page for that letter (see A., B., C., D., E., F., G., H., I., K., N., O., P., Q., S., T., U., W., X., Z.).
There are, however, precisely six letters for which the letter-with-period is either a redirect to another article on a specific topic (i.e., a magazine, book, album, or person), or the title of an actual article, and would ask that editors try to guess what the article in question will be before hovering/clicking the link. I would imagine that in most cases it will be a surprise. These letters are: J., L., M., R., V., Y.
Because of the ubiquitous use of letters as abbreviations, I assert that there can never be a true primary topic for any instance of a single letter of the alphabet followed by a period. Although this could be addressed through a series of WP:RM and WP:RFD discussions, I think that it would be cleaner to have a single discussion of the broader principle. I therefore propose:
All instances of a single letter with a period should be redirected to the disambiguation pages for the respective letters, with the two at article titles being moved to appropriate disambiguators, and with the rule being established that a letter of the alphabet followed by a period should not have a specific subject as its primary topic.
Oppose, if there is a primary topic, we should not use unnecessary disambiguation, consistent with the rest of the encyclopaedia. Readers are unlikely to care for consistency between the pages presented here. —Kusma (talk) 16:21, 25 June 2022 (UTC)[reply]
And strong oppose for L., the most famous abbreviation in biology. —Kusma (talk) 16:23, 25 June 2022 (UTC)[reply]
I'm not sure about the "in biology" there. Maybe in the taxonomy of biological organisms, which is only a small part of biology. Phil Bridger (talk) 17:08, 25 June 2022 (UTC)[reply]
I'd also expect the most well-known taxonomic abbreviation to be the clear primary topic, but the data makes that seem shaky. In January, the redirect L. got 144 views, while the traffic from Carl Linnaeus to L (disambiguation) amounted to 67 link referrals. – Uanfala (talk) 18:31, 25 June 2022 (UTC)[reply]
Some of these will be clicks out of random curiosity though, and it is unclear how many of these are by people searching for something else and redirected through L. (many people seem to click the top couple of links no matter what they are). I don't know if there is any better data that would help us figure this out, or ways to interpret this better. Pinging @WhatamIdoing as I first heard about the clickstream tool from her whether she has further insight. —Kusma (talk) 18:42, 25 June 2022 (UTC)[reply]
Anyone can try it out. For example, https://wikinav.toolforge.org/?language=en&title=V. shows that most traffic from V. comes from the author's article and the most popular destination is to the article (presumably, this is mostly people who didn't start at that article). Only about 3% have gone to the dab page.
By contrast, the lower-traffic https://wikinav.toolforge.org/?language=en&title=V_(disambiguation) mostly sees people going to several television series. It would not seem unreasonable to me to move the book to V. (novel) (an existing redirect), with the idea that people might be looking for those television programs, but I'm not sure that it's an urgent task. WhatamIdoing (talk) 21:20, 25 June 2022 (UTC)[reply]
As King of Hearts points out below, when the dab isn't at the base title, it's difficult to draw watertight conclusions. Still, the data for V. can be informative. There were 53 clicks from V. to the dab page: that's 3% of the total outgoing traffic recorded in the dataset, but that excludes targets with fewer than 10 hits for the month, and it obviously doesn't account for readers who don't click onwards. A more meaningful ratio can be arrived at by comparing with the 7.5 thousand total views of the article for the same period. This means that only about 0.7% of visitors of the article followed the link to the dab. If the ratio were about ten times higher, I'd get suspicious of the primary topic status. But 0.7% is a good signal that things probably are fine where they are. I don't think the outgoing traffic from V (disambiguation) has much bearing here: we're not interested in readers searching for "V", we're interested in the ones who search for "V" + full stop. – Uanfala (talk) 21:40, 25 June 2022 (UTC)[reply]
Having said that, I do find Y. and J. rather questionable, but would suggest to do these case by case. —Kusma (talk) 18:21, 25 June 2022 (UTC)[reply]
I went ahead and converted R. into a formal disambiguation page because, as it was, the page was already a disambiguation page written as prose (it just described a bunch of different definitions of "R."). It was either that or nominate it for deletion per WP:NOTDICTIONARY. --Ahecht (TALK PAGE) 16:36, 25 June 2022 (UTC)[reply]
Are readers entering "J.", "V." or "Y." really most likely to be looking for the content that we redirect them to now? Phil Bridger (talk) 17:08, 25 June 2022 (UTC)[reply]
I would never have guessed the target of any of those titles. In particular v. case-folds to V., and most readers might expect something on case citation or sporting rivalries. Certes (talk) 17:53, 25 June 2022 (UTC)[reply]
Fortunately we have some data about what readers do! [3] Some readers seem to click on the disambig page, but many seem to be happy. For L., the disambiguation page is not in the top destinations. —Kusma (talk) 18:18, 25 June 2022 (UTC)[reply]
That says nothing at all about whether readers "seem to be happy". My guess, and it's only a guess because I'm not taken in by such spurious data, is that many readers simply go to other sites when they don't see what they are looking for here. Phil Bridger (talk) 18:25, 25 June 2022 (UTC)[reply]
If they find a better encyclopaedia somewhere else, I would be curious to know where. —Kusma (talk) 18:34, 25 June 2022 (UTC)[reply]
Who said anything about a better encyclopaedia? People do web searches for what they are lokking for, and if a semi-reliable site such as Wikipedia doesn't give it they go to a completely unreliable site. Phil Bridger (talk) 18:41, 25 June 2022 (UTC)[reply]
If I Google (also Google Books!) for "V.", I don't get V. on the first page of results. Instead, I get a bunch of random crap called "V", not "V.". Wikipedia seems more precise here. —Kusma (talk) 18:46, 25 June 2022 (UTC)[reply]
Yeah, why should we bother with the data when guesses are so much better! – Uanfala (talk) 18:36, 25 June 2022 (UTC)[reply]
Reliable data is good for what it covers. This data says nothing about the happiness of readers. Phil Bridger (talk) 18:41, 25 June 2022 (UTC)[reply]
I admit that I over-interpreted the data. But I think there were some people who did serious analysis of such data, and we should listen to them if they can teach us what it means (that's why I pinged WAID above). Perhaps "wrong target frustration" can be measured. —Kusma (talk) 18:48, 25 June 2022 (UTC)[reply]
If you want people who do serious analysis, you want to be talking to User:MGerlach (WMF) or other folks on his team. WhatamIdoing (talk) 21:22, 25 June 2022 (UTC)[reply]
In general, pageview and/or clickstream data is of little value when used in support of keeping a primary topic in place. When a disambiguation page currently occupies the main title, then statistics are helpful for determining which of the disambiguated topics are most prominent. And when there is an existing primary topic in place, being beat out by another topic is a good sign that the former is not actually the primary topic. But by virtue of occupying the main title, the data will be inherently biased in favor of the current primary topic, so we are limited in what we can interpret from it. -- King of ♥ ♦ ♣ ♠ 19:32, 25 June 2022 (UTC)[reply]
There is also the question of what readers are looking for. Sometimes, the thing I want to know is on the dab page. I don't need to click after that; therefore, there is no clickstream data to indicate that I found the name/word/thing that I was searching for. WhatamIdoing (talk) 21:23, 25 June 2022 (UTC)[reply]
We should assess each case on its merits rather than making an arbitrary rule. J., R., V. and Y. seem clear-cut with very strong cases for change. L. and M. probably need an RM/RfD. Certes (talk) 19:24, 25 June 2022 (UTC)[reply]
This seems like a good proposal to me, because a letter followed by a period is never going to have a primary topic (although I can see the case for L. and M.). Bearing in mind that we are here to build an encyclopedia and not a website, that seems like a sufficient reason for avoiding these, even if the existing arrangement doesn't disserve website users. OTOH, internal links provide another kind of information, and when I clicked on some backlinks for V. that I thought were questionable, I was surprised to find that all of them did in fact relate to the Pynchon novel. So unless there's been some recent cleanup, some of these may be more primary than they appear. (But I haven't clicked on all 115 incoming links.) As a side note, is there a tool that would give a concordance-style view of the wikitext generating the incoming links to a particular page? I've just been clicking through Special:Whatlinkshere and ctrl-F'ing the wikitext, but that seems kind of inefficient. -- Visviva (talk) 19:43, 25 June 2022 (UTC)[reply]
I usually go for an "insource:" search (example), though I suspect someone here may come up with a more elegant solution. – Uanfala (talk) 19:49, 25 June 2022 (UTC)[reply]
A search for linksto:"V." -Pynchon yields just one result: a false positive. I don't know how many links were once wrong; there are people who fix such things. Certes (talk) 21:47, 25 June 2022 (UTC)[reply]
Ooh, thank you very much! MW internal search seems to have improved a great deal since whenever I last tried to use it for anything. -- Visviva (talk) 04:53, 26 June 2022 (UTC)[reply]
Oppose, while WP:ASTONISH is a very integral part of the manual of style, I have a hard time finding sympathy for readers who look things up in the search bar just to see what comes up, and then get surprised at the result. If L. is a common abbreviation for Carl Linnaeus in reliable sources, and there's no better target, then I don't see why the link shouldn't stay as is. The other letter-with-period links will require their own "investigations", and a page-move may be necessary in some cases, but I oppose uniformly moving all of them into dab pages. --VersaceSpace🌃 23:18, 25 June 2022 (UTC)[reply]
Strong support per nom. The letters-followed-by-a-period's primary topic will probably be the letter, which is why the letter article is at the top of every letter disambiguation page. I do not believe that most readers typing in "L." in the search bar are looking for Carl Linnaeus. Some, sure, but not most. Even if Carl Linnaeus is the primary topic for L. in biology, that's still in biology, which is just one subject. That doesn't make it the primary topic for all subjects, for everything. I think it will surprise most readers if "L." redirects to pretty much anything other than a dab page or L, and let's be honest, we don't really know what someone is looking for when they put a period after a letter in the search bar. Is it a typo? The dab pages make the most sense as a target. Levivich[block] 04:42, 26 June 2022 (UTC)[reply]
Oppose a rule. If anyone thinks a title takes them to the wrong place they can nominate it at WP:RfD and/or for WP:RM as appropriate, and that includes single letters followed by a full stop, so there is no need for this policy. In addition to not being needed now, it could easily cause problems in future if something named in this pattern becomes a clear primary topic (e.g. an American president or global superstar band called "M." could easily become primary topic). Thryduulf (talk) 09:09, 26 June 2022 (UTC)[reply]
Oppose as worded / Support in general Never say never. All could redirect to a DAB be default, but may redirect elsewhere only per consensus (at a RM discussion, etc.). Rgrds. --Bison X (talk) 22:34, 26 June 2022 (UTC)[reply]
Oppose. Per WP:SMALLDETAILS, V. is not the same as V, and so on. Relatedly, it doesn't strike me as especially likely that someone searching for a letter will append a period when they could just as easily input the character alone. I think it makes sense to raise the disambiguation question on a case-by-case basis, but in my opinion a one-size-fits-all rule would do more harm than good. ModernDayTrilobite (talk • contribs) 21:01, 28 June 2022 (UTC)[reply]
I don't think WP:SMALLDETAILS is suitable for single letters, because there are countless instances where they will be used interchangeably with or without a period. For example, both UV and U.V. redirect to Ultraviolet, both NJ and N.J. redirect to New Jersey, and the punctuated "J" in J.League refers to Japan. BD2412T 00:30, 30 June 2022 (UTC)[reply]
Is there a specific issue this is meant to address? I can see plenty of reasons to protect without a specific request at RFPP. ScottishFinnishRadish (talk) 20:19, 28 June 2022 (UTC)[reply]
There are only 1,034 administrators on the English Wikipedia. If there is a valid reason to protect a page, an average Wikipedian would request protection of it before an administrator would. FAdesdae378 (talk·contribs) 20:38, 28 June 2022 (UTC)[reply]
Seems a bit arrogant to say that admins only act on requests from us mortals. The ones I see working around the project are pretty damm sharp. I note you didn't answer SFR's "specific issue" point?? - Roxy the bad tempereddog 20:59, 28 June 2022 (UTC)[reply]
Oppose This would delay protection in cases where it is needed. I've made several requests at WP:RPP/I that have taken a while to be reviewed, if an admin noticed a page with a need for protection during that time they would need to request the protection and presumably wouldn't be allowed to act on it themselves, this would significantly delay the time it takes to protect the page. People who unnecessarily protect pages often should be dealt with individually. PHANTOMTECH (talk) 20:29, 28 June 2022 (UTC)[reply]
If you want to be taken seriously then present evidence that this does not happen already. I note that you seem to be backtracking a bit from your initial proposal. Phil Bridger (talk) 21:20, 28 June 2022 (UTC)[reply]
Nope if there is an admin routinely making bad protections, bring them to WP:AN. — xaosfluxTalk 21:00, 28 June 2022 (UTC)[reply]
Or WP:XRV, depending how that discussion goes. Curbon7 (talk) 21:23, 28 June 2022 (UTC)[reply]
No. This is not a bureaucracy. Admins have (unless they have had that status since the early years of Wikipedia) been through a demanding selection process that demonstrates that they are trusted by the community to make such decisions. If one of them betrays that trust then we need to deal with that one admin, not create rules that get in the way of all thousand of them doing their job. Phil Bridger (talk) 21:20, 28 June 2022 (UTC)[reply]
No — it's fine if an admin notices a problem and steps in to solve it without a notice being posted on some acronym board first, or if a non-admin sees a problem and makes a direct request of an admin who is currently active. Mandating that every request be funneled through the same page would just mean a bigger backlog and a worse editing experience all around. XOR'easter (talk) 00:31, 30 June 2022 (UTC)[reply]
No I have watchlisted a lot of articles that are targets of vandalism. When they're hit, I just protect them. Why would I need to wait for an RFPP request rather than take the action myself? – Muboshgu (talk) 00:38, 30 June 2022 (UTC)[reply]
I agree with the others that this won't be workable. However, unwarranted protections do happen quite often. It's not a case of someone blatantly misusing the tools, so it's not a matter for the noticeboards, and, at least in my experience, it can't normally be resolved by a one-on-one discussion with the admin. I think we need to begin with updating the protection policy (a lot of it reflects the practices from before ECP existed), then make sure a neat summary is publicised though the admin newsletter so that all admins are aware of the newly codified community expectations. After that, we could start sampling the newly applied protections and let those admins know who fall short of those expectations (it's more difficult to ignore that sort of feedback when there's a clear policy passage to point to). Oh, and there's also the huge legacy of indefinite protections from the early days, many of which will need revising. – Uanfala (talk) 10:19, 30 June 2022 (UTC)[reply]
Again, any specific cases that you think certain page protections made were unwarranted? Was there conversation with the admin involved? – robertsky (talk) 11:13, 30 June 2022 (UTC)[reply]
TemplateScripts = Templates + JavaScript
Hi! I'd like to propose enabling TemplateScripts on the English Wikipedia. It's not a MediaWiki extension, but a few lines of JavaScript added to MediaWiki:Common.js that basically allow to run JavaScript from templates, as long as the code is on the MediaWiki namespace and with the "TemplateScript-" prefix, which requires an authorized user and community consensus to get there.
The system is enabled on the Spanish Wikipedia where it's used for easy signing of polls and projects (see blue button here), for navigating excerpt trees (see box with tree icon here) for injecting interactive widgets on some articles (here and here) and more recently for creating interactive forms that inject content into other pages (see template here, soon to be used on admin boards).
However these are only teasers. It doesn't require much effort to imagine countless other useful applications. So what do you think? Sophivorus (talk) 21:12, 29 June 2022 (UTC)[reply]
Wait wait, is this another one of those "Check every single page load to see if it has text on it, then go load a script" requests? We've shot those down a LOT. — xaosfluxTalk 23:00, 29 June 2022 (UTC)[reply]
...and yep it appears to be. This should be fixed in core or with an extension, not with this sort of hack. Even an extension was refused by developers (c.f. phab:T8883). It looks like the next possible incarnation is phab:T241524. — xaosfluxTalk 23:06, 29 June 2022 (UTC)[reply]
I would prefer something more focused on improving the encyclopedia. JavaScript is a potential security nightmare and there would need to be a good reason to add more. This tool would appear to give enthusiasts an ability to add animations and games which may or may not be desirable. However, spending time arguing about such animations and games would definitely be undesirable. Johnuniq (talk) 23:19, 29 June 2022 (UTC)[reply]
Well, talking of games, I did wish if there were a quiz thing on Wikipedia. 5 or 10 questions everyday. At the end of quiz you get your score, with short descriptions about all questions asked, nudging them to read the article. If we can run DYK daily, this one shouldn't be hard either, except that I presumed it'll probably require a sitewide javascript to run. I firmly believe that it'll help increase engagement and attract more users. —CX Zoom[he/him](let's talk • {C•X}) 23:48, 29 June 2022 (UTC)[reply]
@CX Zoom We currently can have most anything where someone "clicks a button" kick off a javascript (either via the old ?withJS handler, or with the new gadget argument) - that's how pages like WP:TWA work. Of course, building and curating constant new quiz data requires volunteers. — xaosfluxTalk 10:16, 30 June 2022 (UTC)[reply]
Support, makes sense after the reply tool. ― Qwerfjkltalk 07:18, 28 May 2022 (UTC)
Blocked sockpuppet) —CX Zoom[he/him] (let's talk • {C•X}) 07:15, 8 June 2022 (UTC)
Previous discussion: Talk:Blue § Colour blue in culture
Oppose per WP:INSTRUCTIONCREEP. This is overly specific. ― Qwerfjkltalk 14:44, 26 June 2022 (UTC)
.png){kind=link}
