Wikipedia:Village pump (idea lab)/Archive 29

Alternate Community Amendment Thoughts
Per some views developing that the current community amendment on ARBCOM's ability to delete pages, both leaves it unclear whether ARBCOM possesses deletion power at all and doesn't fully prevent future devolvement issues, I'm looking for views on a possible variant:


 * 1 possible thought comes to mind of whether we allow them to devolve undeletion to DRV (or its equivalent body, if it changes) - obviously this couldn't work for off-wiki evidence cases, but could be appropriate for other instances? Nosebagbear (talk) 10:12, 5 May 2019 (UTC)


 * Additionally, as it's not entirely clear whether ARBCOM has this power to start with, the passing of the ongoing amendment and any failure of this one wouldn't indicate either way that ARBCOM does/doesn't already have this power (in its own right). Nosebagbear (talk) 10:14, 5 May 2019 (UTC)

Thoughts, issues, etc

 * I like it, the wording is better than my draft. :)  EdChem (talk) 10:40, 5 May 2019 (UTC)
 * Cheers, I'm also pinging given the former's consideration of wording and the latter's obvious knowledge and practice crafting such. Nosebagbear (talk) 10:50, 5 May 2019 (UTC)


 * I think this raises the "hard cases make bad law" issue again. I can't speak for the other arbs, but it never occurred to me that we could authorise deletion apart from in very limited circumstances involving abusive private information (basically as a variant of oversight, which we all hold). Because we don't do content. Has it ever come up apart from the recent hullabaloo over User:Dlthewave/Whitewashing of firearms articles? –&#8239;Joe (talk) 17:05, 5 May 2019 (UTC)
 * - People have mentioned possible other instances but it's the only clearcut DS deletion I've seen. I think it was somewhat the inability of ARBCOM to find consensus on the issue that meant people were concerned what might happen in the future (in effect, if you ruled it a legitimate DS action, "lots" of individual admins might do it, with only AE to combat it (which is quite tricky to overturn things in). I've somewhat written this with it in mind that "experienced editors generally trust ARBCOM. BUT they are both nervous about being on the wrong side of DS and many think it's morally/ethically/philosophically/effectively (take your pick) dubious as an entire concept - at best a necessary evil." Nosebagbear (talk) 17:33, 5 May 2019 (UTC)
 * , the fact that ArbCom failed to reach consensus on the limits of its authority on deletions made some clarification desirable. The fact that it then proceeded to ensure that a deletion with claimed DS protection could not be reversed at DRV – despite knowing that DRV had already concluded that the deletion should be reversed – made a clarification necessary.  The fact that some Arbs commented at AE that there was no reason to overturn because the decision might be wrong but was within discretion, and that a former Arb then closed the AE endorsing and re-imposing the deletion despite it having neither policy nor consensus support, and in the face of the DRV, because there was not a substantial majority of administrators (because non-administrators are worthless / irrelevant according to the prevailing AE culture, about which ArbCom does nothing) who saw it as invalid, and despite the lack of ArbCom authority to delete such materials nor to delegate deletions outside the deletion policy as valid DS actions, collectively made a modification of ARBPOL necessary and urgent.  The mess about resysops, another area where ARBPOL gives ArbCom no authority, proves that ArbCom ignoring its limits of authority is a trend and not simply a one-off.  These proposals are entirely the product of ArbCom overreach and were totally avoidable if ArbCom had simply said "ArbCom authority over deletions is unclear and in any case would only be used in rare and unusual circumstances (like the privacy issues Rob has raised).  We recognise that GoldenRing and Bishonen acted in good faith, and wish to clarify that it is our view that DS / AE should not be used for deletions, and any deletions that may be needed should be undertaken in line with the existing deletion policy and be subject to standard review.  Deletions that may need consideration that would not be supported by the deletion policy may be raised directly with the Committee at ARCA or by email if privacy considerations require."  Instead, having side-stepped the authority / policy question, ArbCom modified procedures (beyond the community ability to edit) to entrench any claim of AE protection as beyond community review without jumping through hoops.  Simply to hold a DRV, a significant majority consensus is needed at AE or AN (where non-admins can't see the page in question anyway), in either case subject to further appeal to ARCA.  Both AE and ARCA can reject an appeal without considering the merits of the deletion by focusing on admin discretion.  All of this was done unanimously (IIRC) by a Committee that can't even agree it has authority over deletion... and you are surprised there is push back?  ArbCom needs to learn that its authority has limits and if it won't respect them, the community can act to codify and restrict those limits.  EdChem (talk) 02:04, 6 May 2019 (UTC)
 * If you're worried about a possible future where admins start going around deleting willy-nilly despite clear statements from ArbCom at the ARCA that we would highly frown upon any deletions in mainspace, the fact that the community can review such deletions at AN under existing procedure and overturn them, and the reality that any such action would drag such a hypothetical admin through a couple months of discussions on the topic, doesn't it at least make sense to wait for that to actually happen before amending ARBPOL? ~ Rob 13 Talk 08:18, 11 May 2019 (UTC)
 * I think I'd usually classify changing a policy due to a single incident as WP:CREEPy behavior. There should be at least two clear-cut incidents that weren't easily resolved before anyone should try to write down the One True™ Answer.  WhatamIdoing (talk) 17:53, 13 May 2019 (UTC)

Wizard that suggests article/image pairs (using Wikidata images)
Many English Wikipedia articles have no illustration despite the Wikidata item having a picture. Why? Because many non-English speakers set Wikidata pictures using tools like HarvestTemplates, WDFIST, or the Commons Android app's Nearby items map.

It would be great if the English Wikipedia could benefit from all of these pictures.

How about a tool that would:


 * 1) Suggest me one article and one picture, showing:
 * 2) * The rendered article
 * 3) * The image
 * 4) * The image's English caption and English description
 * 5) Let me either skip, or edit the article to add the image. It could even suggest me some wikitext.
 * 6) Automatically go back to step 1 with another article/image.

The Arabic Wikipedia and some others automatically transclude images from Wikidata, the wizard I describe above is a more conservative approach, but still better than doing nothing and letting all of these great images unused.

If anyone implement this please let me know, I will be your most dedicated user :-) Syced (talk) 10:02, 16 May 2019 (UTC)
 * Some templates using Wikidata already fetch images from WD, like Infobox person/Wikidata. – Finnusertop (talk ⋅ contribs) 16:40, 16 May 2019 (UTC)
 * Great! I see in that template's documentation that Wikidata fetching is "opt-in", though, which means that all templates ignore Wikidata except when someone has taken the time to go check Wikidata and manually edit the article to switch on the "fetchwikidata" parameter. So, the tool I described above could switch on fetchwikidata if the article uses such a Wikidata-compatible template. :-) Syced (talk) 02:33, 17 May 2019 (UTC)

Is it a good idea to allow non-admin closure?
I realize that some people who created an article don't have a whole lot of Wikipedia experience and don't understand why the article they created should be deleted. I think a lot of them if they know about non-admin closure, then they would close the discussion about their article as keep that way because that is allowed unlike just removing the AfD template. Maybe some of them would just do it in the wrong situation when it actually was worthy of deletion and not understand and think there was nothing wrong with what they were doing. Blackbombchu (talk) 18:08, 9 May 2019 (UTC)
 * Admins, as editors, do not have special rights over any other editor on any issue, which includes the ability to assess consensus and give summaries of discussions. Admins have special tools (like the ability to block users or the ability to protect articles) that other editors don't have, but those tools do not give them any additional authority over things like assessing consensus and writing summary statements.  Any editor in good standing with sufficient experience at Wikipedia can do that.  As a practical matter, discussions that require an admin to use their tools (for example, a discussion that shows a consensus to block some user) should be left to an admin to close, if only because an admin is needed to block the user anyways, but for any discussion that doesn't directly and immediately require one of the admin tools, any uninvolved editor in good standing and sufficiently experienced can summarize the results.  -- Jayron 32 18:15, 9 May 2019 (UTC)
 * In addition to what Jayron32 said, this is a situation in which you need to actually point to a case of its happening before it's actually considered a problem. Eman  235 / talk  19:14, 9 May 2019 (UTC)
 * I'd take that one step further. You'd need to show an instance where this has happened and it has caused a problem. There are several very experienced editors who routinely patrol AfD. I'd guess this probably has happened, but I'm much more certain that if it did (or does) happen, it would be promptly reverted. This strikes me as a solution in search of a problem. John from Idegon (talk) 19:23, 9 May 2019 (UTC)


 * Misunderstood the initial complaint - yes, I've never spotted this happen. Yes this would require at least the nominator, plus any other deleter, not to pay attention to the close. Any self-close is an automatic bad-close, and would be taken poorly. Nosebagbear (talk) 08:28, 10 May 2019 (UTC)
 * Such a closure would be an involved close, which is not allowed. ~ Rob 13 Talk 16:14, 11 May 2019 (UTC)
 * Well, it is done. We tend to call such instances "withdrawn" rather than "closed as keep by the nominator", but it's the same effect.  WhatamIdoing (talk) 18:05, 13 May 2019 (UTC)
 * I don't think non-admin closures or relists at AfD are a good thing and there was some support for this concept (especially the relist part) in a semi-recent discussion over at WT:NAC. Best, Barkeep49 (talk) 01:06, 16 May 2019 (UTC)
 * That's a fairly significant extension from the raised point in this discussion. In fact the discussion at NAC I considered fairly insulting to cut such a wide remit from NACs, as it implied all relists I'd made were incorrect and unwarranted. Your statement is actually beyond that and indicates my closes lack value (or that the total value of all NACs is insufficient to consider alternate resolutions). You could combat NOQUORUM by prohibiting NA-relists when only the nominator has participated or filter out non-admin closers with insufficient policy knowledge by tying it to a user-script permission in the same way as AfC reviewers are. Nosebagbear (talk) 21:07, 17 May 2019 (UTC)

Idea - bot to tag orphans
Before filing a BRFA, or even opening an RfC, I'd like to get some feedback about a bot to conduct a one-time run to tag orphans.

This would be similar to the RfC on a onetime run for tagging unreferenced pages

Currently, I count 27215 pages that are
 * Have no incoming links from mainspace
 * Are not disambiguation pages
 * Are not categorized as set indexes, given names, surnames, orphans, soft redirects to wikitionary, redirects currently at RfD, or candidates for undeletion
 * Are not redirects
 * Are in mainspace

To be clear, these have absolutely no incoming links from mainspace - a link from a disambiguation page, though not enough to meet the orphan criteria, keep the page out of the list

What would users think of a bot to automatically tag these 27k pages? If you have any suggestions for other categories to exclude, let me know. Thoughts?

Thanks, --DannyS712 (talk) 04:03, 29 April 2019 (UTC)
 * This can only be helpful, as far as I can reckon. But you're missing the other subcats of Category:Wikipedia interwiki soft redirects. Eman  235 / talk  21:57, 29 April 2019 (UTC)
 * Thanks, I'll run the query again with "Redirects_to_%" to filter those out to, but it won't have much of a difference. --DannyS712 (talk) 21:59, 29 April 2019 (UTC)
 * With an updated query, I count  untagged orphans - the number fluctuates, obviously. Thanks for the tip --DannyS712 (talk) 23:43, 29 April 2019 (UTC)


 * Unlike unrefed, there is nothing "wrong" with these pages per se, if people want to just work adopting orphans, can't they just use Special:LonelyPages already? — xaosflux  Talk 00:02, 30 April 2019 (UTC)
 * And yet, we currently tag orphans - there are over 110,000 pages in Category:All orphaned articles - the same argument against tagging these articles extends to tagging those - if we are going to be tagging orphans at all, we should tag these 27k untagged orphans --DannyS712 (talk) 16:30, 30 April 2019 (UTC)
 * AWB as part of its general fixes tags orphans. It may be a good idea to review the AWB source to see what criteria it uses to select an orphaned page. --Izno (talk) 17:04, 30 April 2019 (UTC)
 * by default it only tags pages with 0 incoming links --DannyS712 (talk) 17:55, 30 April 2019 (UTC)
 * DannyS712, "We're doing something apparently pointless, so I'd like to do it on a massive scale" sounds like the opposite of a good idea. We're already hiding these templates on most articles.  Maybe AWB should stop tagging them.  A potentially useful thing to do would be generating lists for individuals or groups that are interested in Building the web to these articles.  If you do proceed, then I'd suggest that you only tag articles that are not about people or businesses.  Because of the quirks of our notability guidelines, we end of with a lot of these articles, and it's very difficult to create legitimate links to most of them, unless you want to create a bunch of unencyclopedic navboxes for things like "Plastic surgeons in Alaska" or spam article with sentences like "Some plastic surgeons, such as Alice and Bob, are in Alaska."  WhatamIdoing (talk) 16:56, 3 May 2019 (UTC)
 * What she said. The whole notion of "orphans" is a remnant of the early days of Wikipedia, when "Build the Web" was the vogue and there was a general feeling that it was necessary there be a path for readers to find every Wikipedia page from elsewhere on Wikipedia. Now that the main route to each page is from search engines, the entire concept is obsolete; if anything we should be deprecating the existing orphan tags, not massively spamming thousands more. &#8209; Iridescent 17:36, 3 May 2019 (UTC)
 * In that case, what would the community think of TfD'ing the orphan template? DannyS712 (talk) 17:49, 3 May 2019 (UTC)
 * Not a bad idea. Especially if the functionality can be replaced by a query. –xenotalk 17:55, 3 May 2019 (UTC)
 * Just to put this in scope, we currently have 116042 pages that are tagged as orphans, and a further 27k that aren't but meet the criteria. I'm neutral about whether we should deprecate the tag or not, but here are the numbers. --DannyS712 (talk) 18:49, 3 May 2019 (UTC)
 * What said,  and deprecate the tpl. With  the huge advances in  both  Google's and Wikipedia's search  engines, the reason  for  interlinking  (except  of course for  outgoing Wikilinks) Wikipedia articles is now practically  obsolete.Kudpung กุดผึ้ง (talk) 05:26, 12 May 2019 (UTC)
 * Back in the day, links were the only way to reach articles. Special:Search didn't exist in Wikipedia's early days.  I think a gentle "deprecation" (stop adding it, especially automatically) should come first, and consider removals only later (like, a couple of years from now).  The obvious baby step to take is to tell editors to only add the tag, if, in their best judgment, they believe that a non-spammy, non-navbox link could be made.  We can backstop that with a rule that if there's no sensible reason given, then any editor who attempts to de-orphan the link can remove the template.   In terms of the procedure, should we take the template to TFD, or have an RFC on the template's talk page about updating the "rules"?  What do you all think?  Izno, are you available to figure out how AWB's role?  It looks like it's in Twinkle (better to remove, than to try to control, or just leave it?), too.  Kudpung, do the various page-curation tools add this tag?  WhatamIdoing (talk) 18:02, 13 May 2019 (UTC)
 * , the curation tool can tag for  orphans. However, the new page reviewer right  does not  prevent other users from  applying  maintenance tags using  Twinkle. Kudpung กุดผึ้ง (talk) 01:28, 14 May 2019 (UTC)


 * If someone is going to go to the trouble of thinking of a reason they should just de-orphan it, no? So I think yes, deprecating from use is a good first step. –xenotalk 18:13, 13 May 2019 (UTC)
 * I can see very occasional circumstances where the  field might be valid—namely, where there's an obvious topic that will contain links to the article, but that article hasn't been written (e.g. when we have an article on a notable product but not the manufacturer), and consequently it will be de-orphanable in theory but would take some effort to do. These would be so few and far between, I wouldn't think it would be worth the effort as it would just confuse people. Regarding AWB, remember that's a product used by hundreds of wikis, including sites outside the WMF family, so we need to be careful about changing its code; on something like a Wikia fansite, I can entirely see how orphans and walled gardens would be an issue. My inclination would be to keep the template for the moment but deprecate all its output—so no maintenance tags and no adding to any category—and see if anyone even notices, let alone comes up with a valid complaint. That way, we can just roll back the template if it turns out there was a hidden pool of people who find the tag useful, rather than having to remove 100,000 tags only to need to re-add them later. &#8209; Iridescent 20:01, 13 May 2019 (UTC) BTW, @user:WhatamIdoing, if you want to ping a bunch of people to a post without actually including their names the bcc template is a lot more elegant than linking words to usernames. &#8209; Iridescent 20:01, 13 May 2019 (UTC)
 * The template currently hides itself after some period (1-2 months) after some fairly-recent RFC. It still emits the category even after that date, which seems reasonable. --Izno (talk) 20:14, 13 May 2019 (UTC)
 * Any broader discussions should also involve WikiProject Orphanage. I agree with the general trend of the thread so far: in most cases there's no need to tag orphans, and if there are automatic tools that add such tags, then should stop doing that. – Uanfala (talk) 13:29, 23 May 2019 (UTC)

Re-enabling downloadability of Books / Collections
Hi,

A Wikipedia Book is a collection of Wikipedia articles.

In former days there used to be a rendering service on Wikipedia that created PDFs from Wikipedia Books. This service has been decommissioned. As detailed in the following post summarizing the discussion a replacement is not expectable in the near future.

https://www.mediawiki.org/w/index.php?title=Topic:Uxkv0ib36m3i8vol&topic_showPostId=uxsjbpkqfmgq1jyx#flow-post-uxsjbpkqfmgq1jyx

So I propose that I render a PDF for each Wikipedia Book in my home and upload them to Wikipedia. This way the PDFs are available to the users again.

I am going to use the following software to create the PDFs:

http://mediawiki2latex.wmflabs.org/

Since I need to buy hardware, do a considerable amount of setup and let it run for a few months, I need to prepare this operation well.

I am only going to do community maintained books.

I am happy to hear about your thoughts regarding this idea.

I know it is a bit unusual for a private person to follow such an approach, but currently I can not think of anything else I could do in order to re-enable PDF downloads for collections.

Yours Dirk Hünniger (talk) 14:00, 19 May 2019 (UTC)


 * Interesting—it would be kind of like the spoken Wikipedia files in that they could get out of date. Unless you made a bot that updated them periodically. Eman  235 / talk  18:59, 19 May 2019 (UTC)


 * Exactly. Regular updates are planned. But I expect something between a few month and one year of lag between the PDFs and the current wiki. Dirk Hünniger (talk) 19:19, 19 May 2019 (UTC)


 * So, I started a minimal setup now, 5 years old dual core laptop next to my fridge, with one process at a time. The first three resulting pdfs are available here https://drive.google.com/drive/folders/17g5Ey6jauKd3CLMDNBOnV3RYKcJN0QZu?usp=sharing . I need about 1 hour per pdf and each has got a size of 20 MByte on average. Since I got roughly 6000 pdf to make. This will take about 250 days an use about 120 GByte of disk space. Dirk Hünniger (talk) 13:01, 2 June 2019 (UTC)


 * I stopped my toy experiment. I processed 23 books, got 20 results (13% failure rate). It took 54 hours, 2.5 hours per book, 625 days for all books. Size 45 MByte per book on average. So 300 GByte needed for all books. The results are available https://drive.google.com/drive/folders/17g5Ey6jauKd3CLMDNBOnV3RYKcJN0QZu?usp=sharing . So I would have to pay 400 EUR for cloud fees to generate that, something I could afford. Dirk Hünniger (talk) 21:14, 4 June 2019 (UTC)

Google Doodles
Is there some way that we could learn about Google Doodles before the day on which they will occur in order to improve the articles? StudiesWorld (talk) 13:45, 10 May 2019 (UTC)
 * You know they differ depending on your location and there's not some standard global calendar they follow, right? I can't imagine they would ever agree to it; giving pre-notification of what they plan to run would mean Google opening the floodgates for every spammer and SEO-merchant to crapflood them. &#8209; Iridescent 13:56, 10 May 2019 (UTC)
 * Alternately, perhaps Google would consider improving the articles themselves while creating the Doodles? A lot of their value is in visitors' ability to discover context by clicking through to a free article explaining the subject. – Teratix ₵ 14:20, 10 May 2019 (UTC)
 * - that wouldn't work either. They'd be paid editors that people would eventually catch on edited the doodles pre-emptively. Or they'd need to create a bunch of one-time accounts...which is also not something we'd want to encourage in paid editors Nosebagbear (talk) 18:08, 10 May 2019 (UTC)
 * I don't see anything inherently wrong in creating many one-time accounts for this purpose, as long as they declared their paid status and connection. They would be benevolent paid editors, not harmful. Alternatively, if we want to restrict them to one account but avoid giving the game away early, Google could prepare an updated version of the article but only post it once a Doodle was live. Of course, this is assuming Google wants to take the time to do this, which may be doubtful. Still, it's worth asking the question. – Teratix ₵ 18:28, 11 May 2019 (UTC)
 * I think it could actually make sense, even if people would catch on the day before, because we still wouldn't know what the Doodles would look like, and part of the interest in them is because they're sometimes interactive or otherwise interesting in some way not derived from their being labelled Google Doodles. It also wouldn't be especially surprising if, for example, they were to improve Saint Patrick's Day and related articles every March. It would also serve as a way for Google to "give back" other than sending the WMF piles of cash. Jc86035 (talk) 11:01, 14 May 2019 (UTC)


 * Unless one actually worked for Google, how would one know what the Google doodles were the day before they occurred? Vorbee (talk) 17:22, 22 May 2019 (UTC)
 * @Vorbee, as I read it the proposal is that we pay (or encourage) Google themselves to write articles on the relevant topics before the Doodles run. Needless to say, if we actually did catch Google trying to influence our content that directly, we'd block the accounts on sight. &#8209; Iridescent 18:16, 22 May 2019 (UTC)

Whilst a Google Doodle briefly increases traffic to a Wikipedia subject page, I dislike a subject page being edited to state something like "on such and such date this person/thing was honored by a Google Doodle". For example, as I'm writing, the Google Doodle is on Elena Cornaro Piscopia, and on her page under "Legacy" it says "On 5 June, 2019, Google celebrated her 373rd birthday with a Google Doodle.", so what. Likewise, for Ada Lovelace under "In popular culture" it states "In 2017, a Google Doodle honored her on International Women's Day." It adds no value to any article. For me, these entries are just spam. It isn't notable that, for a short period, a search engine briefly acknowledges a person or subject, therefore it should not be in a subject's Wikipedia page. This topic has been mentioned before, see Village_pump_(policy)/Archive_119, and the few comments generally agree with my view. I would like to see a policy where adding an entry to a subject stating that it was briefly mentioned as a Google Doodle be disallowed, and when we come across such a mention it can be removed.GR8DAN (talk) 12:38, 5 June 2019 (UTC)

I note that Wikidata has a property for recording Google Doodles. (See https://w.wiki/4eg for examples.) Perhaps we should divert the efforts of google-doodle-recorders over there. This gives us the option to display Google Doodle links automatically in infoboxes or whatever, depending on local policy. Bovlb (talk) 17:45, 5 June 2019 (UTC)

AWB-alternatives for Linux
Is there any alternative of AWB for linux? Now AWB can run through Wine. But it may not support in all systems. Other AWB-like softwares such as PyAWB, JWB, etc are not working currently (correctly). It is better that creating a linux/mac supporting versions for AWB like huggle 3, huggle version which is compatible for linux also. It will help Linux/Mac using Wikipedians for using AWB more efficiently. Thank you.-- PA TH  SL OP U  03:07, 28 May 2019 (UTC)
 * AWB is a pretty complex piece of software bundling a lot of functionality. Is there a particular feature or set of feature(s) you were interested in? -  F ASTILY   04:17, 3 June 2019 (UTC)
 * I interested it's features such as doing repetitive edits in in a set of pages. For example adding a particular text, template, etc in several articles. Creating a set of new articles (usually stubs) of on topics such as places, geo-features, etc. Thank you.-- PA TH  SL OP U  07:15, 3 June 2019 (UTC)

At one time I used AWB on Windows with programs in Unix (linux). Basically AWB does all the login authentication and uploading diffs, while the core logic is done under unix via AWB external script function. It can be done with Cygwin, or virtual box. More info User:GreenC/awb/cygwin. AWB runs under windows natively and the bot program runs under Unix natively, best of both worlds. -- Green  C  14:39, 3 June 2019 (UTC)
 * But this is done in a shared system, isn't it? Regards.-- PA TH  SL OP U  15:54, 4 June 2019 (UTC)
 * A virtual machine. Linux can be guest and windows as host, or other way around. In my experience there is no performance or other problem with decent CPU and memory. VMs are quite common even at Wikipedia, most hosting providers, Amazon etc.. --  Green  C  16:07, 4 June 2019 (UTC)
 * BTW so long as the Windows and Linux machine share a common folder such as with network attached storage they don't need to be hosted on the same computer. -- Green  C  16:12, 4 June 2019 (UTC)
 * Thank you for advice. But it means the users must need a Windows system, mustn't it? Regards.-- PA TH  SL OP U  15:49, 5 June 2019 (UTC)


 * I don't think there are any plans at the moment to make a cross-platform AWB. (Incidentally, what issues are you having with JWB? You might want to bring that up here.) But it is freely licensed, so anyone with the ability and initiative could modify (or rewrite, which is what I think happened with Huggle 3) the code to run cross-platform. Eman  235 / talk  03:29, 6 June 2019 (UTC)

Yet another Main Page redesign proposal
I have created a draft of a Main Page redesign that can be seen here, even though I know redesigns are rarely sucessful. It is by no means meant to be a final design, but maybe it could serve as a starting point for some discussion. There are certainly areas that are up for debate or could be refined. Feel free to give some input, or use as basis for other suggestions. -- Jsdo1980 (talk) 11:21, 19 May 2019 (UTC)
 * Well, I like it—personally I think the small color palette is more consistent with the rest of Wikipedia. It should definitely be reflowable, though (i.e., shrinking the browser window size should switch it to a one-column layout). Also, I think the (for want of a better word) looming puzzle ball looks redundant with the logo being in the sidebar and all. Eman  235 / talk  12:10, 19 May 2019 (UTC)
 * Reflowable is a good suggestion, that would be good. I also agree somewhat with the logo as background as well, I just felt that the header area looked empty. Maybe some other backround could work? -- Jsdo1980 (talk) 12:44, 19 May 2019 (UTC)
 * I've added another more generic background. -- Jsdo1980 (talk) 14:34, 19 May 2019 (UTC)
 * Ooh, I like that; it's reminiscent of Monobook. Eman  235 / talk  19:02, 19 May 2019 (UTC)
 * Yeah, I like the simple palette and the larger spacing around the text, but I'm not sure it's sufficiently better than the current design to justify the endless discussion and editor hours that would be spent evaluating and implementing the new design. There is a reason there hasn't been a redesign since 2006. – Teratix ₵ 13:46, 19 May 2019 (UTC)
 * Yeah, I've noticed that it's no easy task... I would however say it might be worth it. - Jsdo1980 (talk) 14:34, 19 May 2019 (UTC)
 * I think you need a little more margin/padding around the labels - for example the "Today's featured picture" text is abutting/being partially obscured by the image below. — xaosflux  Talk 17:42, 19 May 2019 (UTC)
 * In monobook at least. For the same section in minerva, the image so tiny it is hard to see.  Try out any workups with all the skins to make sure they work well. —  xaosflux  Talk 17:43, 19 May 2019 (UTC)
 * Good point. Vector has increased the line height. I've tried to fix that. Does it look better now? -- Jsdo1980 (talk) 18:06, 19 May 2019 (UTC)
 * Better, note TFP looks bad in minerva. — xaosflux  Talk 23:51, 19 May 2019 (UTC)
 * TFP looks bad in Minerva with the current design as well. I'm using the same template, so I can't change that. -- Jsdo1980 (talk) 13:08, 20 May 2019 (UTC)


 * Well, I think the header is at least better than what we have now. It looks quite more modern. – Ammarpad (talk) 15:53, 20 May 2019 (UTC)
 * I don't have any specific suggestions, but wanted to say that I like it better than the current main page. Good work. – Levivich 03:15, 22 May 2019 (UTC)


 * If you use TemplateStyles you can do cool stuff like making the content responsive. I think it already looks nice but would agree that it's not yet enough of an improvement to justify replacing the current main page. (Also, it's probably better not to specify Arial specifically, since most of the skins don't use it as the default font. You should probably leave font selection to the website's CSS.) Jc86035 (talk) 10:47, 22 May 2019 (UTC)
 * , considering that the last attempt at making a change (non-visual) to the main page was reverted because someone with a tiny screen laptop 'suddenly' had 1 column instead of 2 columns, I'd say, be prepared to engage for a long time and to face stiff opposition if you want to make a change. I'm personally pretty done with trying to get anything moving on the main page, the community is just too stuck in their ways. —Th e DJ (talk • contribs) 11:24, 22 May 2019 (UTC)


 * I really like it. Especially the borderless sections and the headings. It's on a par with the Russian and Spanish main pages which are probably my favourite out of the existing versions (this 2014 proposal is also quite nice). As for subjective aesthetic criticism, the only things I'm not sure about are the gradients in the bordered boxes which are gradual enough that it makes it look a bit like they're just filled with differently coloured rectangles, the right-hand side (the non-book bit) of the main banner's background image which you could argue takes away from the simplicity, and possibly the portals bar, though it's growing on me. I think it's that it looks a bit out of place since there are no other blue bits or fade-out gradients. (Personally, I'd get rid of the portals altogether.) ─ ReconditeRodent « talk · contribs » 22:52, 5 June 2019 (UTC)
 * I think that this new mainpage design looks nice. Personally, it looks a lot better than the current one. This new design is a lot cleaner and simpler. Especially seeing as the current design uses many different colours and is filled with many boxes. I agree with ReconditeRodent that the portal bar is a bit different from everything else. Personally, I would not be opposed to moving these links down the page, however, if the links are going to stay in their current location, I would want them too not stand out as much. Dreamy Jazz 🎷 talk to me &#124; my contributions 10:18, 7 June 2019 (UTC)
 * Thanks! I've made an alternate version where I have removed the gradients and replaced the portal bar with an "information bar" to the right, and moved portal contets to a section at the bottom instead. I've used the subportals or related portals for the old portals. In some cases it becomes a bit weird in my opinion, like for Biography. -- Jsdo1980 (talk) 12:08, 8 June 2019 (UTC)
 * , I like that version even better. I think having links to the Wikipedia introduction, help pages and contact page at the top of the main page will help to make the main page more accessible for new users.
 * One thing, there a good number of portals you have placed in the portals section. I would say that with the recent controversy of single page portals based on navboxes, links to portals based on navboxes won't be accepted by the community. From what I can see you have only linked maintained / non-navbox based portals. (For your interest you can see Miscellany for deletion/Mass-created portals based on a single navbox and Miscellany for deletion/Second batch of mass-created portals based on a single navbox). Dreamy Jazz 🎷 talk to me &#124; my contributions 12:39, 8 June 2019 (UTC)
 * I was not aware of that. Thanks for the heads-up. -- Jsdo1980 (talk) 15:35, 8 June 2019 (UTC)
 * I was not aware of that. Thanks for the heads-up. -- Jsdo1980 (talk) 15:35, 8 June 2019 (UTC)


 * I edited the alternate version to see how it looked with File:Wikipedia logo letters banner.svg. I kind of like that as well. Had not seen the Russian and Spanish main pages before. -- Jsdo1980 (talk) 15:35, 8 June 2019 (UTC)
 * It might be good actually if there's a way for the welcome message and the date to stack if the window is resized and they would overlap. (It shouldn't be a massive problem though since presumably the mobile version will stay the same.) ─ ReconditeRodent « talk · contribs » 15:58, 8 June 2019 (UTC)
 * Yeah that would be great. Or maybe even better if the right element is hidded if there is an overlap. This is a test design, so currently it doesn't seem possible due to all the overlapping elements in the banner (the background and the gradient), meaning I'm forced to use the position property. I'm sadly not proficient enough to know how to solve that. -- Jsdo1980 (talk) 18:04, 8 June 2019 (UTC)
 * , you could use @media styles. (i.e. under a certain width you could say that other styles apply). For example, you could set bottom:0; (and remove top:0;) the statistics part of the welcome message and increase the height of the welcome message.
 * For example (illustrative only):
 * @media all and (max-width: 334px) {
 * # welcome-message-statistics {
 * top:auto;
 * bottom:0;
 * }
 * # welcome-message {
 * height:12em;
 * }
 * }
 * I got a working draft version using chrome's inspect element. It is supported by virtually all browsers (minus IE <9) (caniuse statistics). Bearing in mind that this would only be used if the screen was made very narrow and wouldn't affect anything if the browser is less than IE 9, I suspect that the issue with pre IE 9 support won't be a big deal. There may be other ways to deal with this, but this is the first one that popped into mind. Dreamy Jazz</i> 🎷 talk to me &#124; my contributions 21:57, 8 June 2019 (UTC)
 * I don't view or use the Main Page much, but I'm neutral to mildly positive on the new design. My only complaint is that I dislike the pale blue gradient near the top. Alsee (talk) 01:06, 9 June 2019 (UTC)
 * Comment. I really like this. Good job so far, !! I hope you have received the constructive feedback you were looking for as well. If you continue with this proposal elsewhere, please ping me. { &#8211; MJL &thinsp;‐Talk‐☖ 02:45, 10 June 2019 (UTC)
 * Oh, I do like that you include the time top-right corner (I kid you not; I sometimes make edits just to figure out what time it is here.. this would be a lifesaver), but I suggest that maybe it not be linked and be appended (UTC) just like in a signature (ie. no periods). Readers might get confused otherwise, and if we link them then suddenly Monday will get a spike in views that we really aren't equipped to deal with. &#8211; MJL &thinsp;‐Talk‐☖ 02:49, 10 June 2019 (UTC)
 * The second box under Preferences -> Gadgets -> Appearance has the option to display the UTC time by the user buttons. Might be useful. -A la d insane  <small style="color:#006600">(Channel 2)  03:03, 10 June 2019 (UTC)
 * I appreciate the suggestion! &#8211; MJL &thinsp;‐Talk‐☖ 03:09, 10 June 2019 (UTC)

The possibilities of a custom magic word variable to get the number of watchers on a page
I recently discovered User Centijimbo calculator. I assumed that it could automatically calculate the number of Centijimbo's a person had, but this was not the case. I discovered that to keep templates such as this one up to date, an editor has to periodically update the number of watchers on userpage. It also requires editors who use the templates to update the number of watchers on their userpage periodically.

An idea I have to alleviate the amount of maintenance needed for these templates is, to either add a new magic word variable into mediawiki or define a custom magic word variable for enwiki, which could return the number of watchers for the current page or a specific page. I envisage this would work similarly to the magic word variable which either returns the current page's ID or the ID of a named page. This magic word may have more applications than just keeping a users Centijimbo count up to date, however, currently I am unsure what else it could be used for. I would appreciate any opinions and thoughts on this idea, including other ways such a magic word variable could be used. Thanks, Dreamy <i style="color:#d01e1e">Jazz</i> 🎷 talk to me &#124; my contributions 10:08, 7 June 2019 (UTC)
 * What conceivable use could this have other than to allow a handful of WP:NOTHERE types to goof around with userboxes? (The userbox you mention is currently used by a total of four people.) I struggle to think of any legitimate reason for ever wanting to know that the number of watchers of any given page has changed; there's arguably a case that on a handful of topics it might be useful to track spikes in the numbers of watchers over time, but those would be vanishingly rare as the pageview numbers will almost invariably be a better indicator of levels of interest (the majority of watchers of any given page are virtually without exception long-departed accounts which never unwatched the page before they retired or were blocked). &#8209; Iridescent 10:14, 7 June 2019 (UTC)
 * , there are other templates. The most popular (I think) is User:Audacity/centijimbo (however this only has 149 uses). I do see that this magic word variable would have little use apart from counting Centijimbo's. Thanks, Dreamy <i style="color:#d01e1e">Jazz</i> 🎷 talk to me &#124; my contributions 10:22, 7 June 2019 (UTC)
 * Indeed, and Template:Annual readership (and the like) covers any relevant uses of page views, which is as you mention the more interesting and useful metric. Watchers are vanity, pageviews are coverage. ~  Amory <small style="color:#555"> (u • t • c) 11:00, 16 June 2019 (UTC)
 * Indeed, and Template:Annual readership (and the like) covers any relevant uses of page views, which is as you mention the more interesting and useful metric. Watchers are vanity, pageviews are coverage. ~  Amory <small style="color:#555"> (u • t • c) 11:00, 16 June 2019 (UTC)

Button for the opposite of "minor" edit?
I suspect something like this has probably been proposed before, but I couldn't find it.

The "minor" button is useful for editors to flag their edit to be (in their opinion) unlikely to be of interest to other editors to review. That helps other editors focus their efforts elsewhere, where it's more likely to do some good. It's a great button (except when misused, but that's a different subject).

Now, how about the opposite? I make an edit that's a needed improvement, well and good, but compared to average kind of changes I make,  rather than unlikely, I think this is one more likely to benefit from review. Maybe it's a bit complicated, might have some possible consequences or side-effects, or maybe it could be just a start for other editors to come and expand upon.

Okay, "that's what the talk page is for", I'd bet I'd hear. From what I've seen on talk pages, almost all the sections (except for bot-generated ones) are about issues that demand discussion. I don't see how there's an obvious bright line between those issues that absolutely need discussion and those that don't; so it seems we err on the side of not discussing things on talk pages. That's understandable; no one wants to go through the whole process of formalizing a new discussion on the talk page, just to find that (as they suspected but weren't certain) no other editor finds its worthy of any notable response. Talk pages are basically used as the last resort for editing, and I wouldn't change that. I'm sure we don't want to try forcing editors to start more discussions on the talk page when they may not be needed; that's a lot of additional effort, and the talk page would get cluttered with unimportant issues obscuring the important ones.

This button fills the gap between those edits requiring discussion and those that might benefit from it. The editor clicks this button on their edit of interest, and if any other editor, seeing the button's tag on the edit, reviews it and thinks it should be discussed, they can start a discussion, knowing for certain that there's a discussion to be had. If none do, everyone's happy, and there was no wasted effort.

Although the opposite of "minor", rather than calling this proposed button "major", I think I'd go for something like "interesting".

And, interestingly enough, this could be the default button for all new users. After the user has become savvy enough to know how and why, the user can remove this default setting in preferences.

Oh, and at least some of that bot-generated discussion clutter could be eliminated by those bots simply using this button instead.

--A&#8239;D&#8239;Monroe&#8239;III(talk) 22:45, 14 June 2019 (UTC)
 * can you describe the problem you are seeing with bots a bit more? Bots can already pick normal/minor AND bot/not-bot flags on each edit. Most routine bot edits are marked 'bot' already to avoid bothering watchlists and recent changes. —  xaosflux  Talk 23:07, 14 June 2019 (UTC)
 * I don't have any problem with bots that warrant specific attention; I only mentioned bots here as sort of an allegory. But since I mentioned bots, I'll respond, but I don't want this whole idea to center on bots; this button's value isn't based on bots.
 * Yes, bots can and do use the "minor" or "bot" flags, and that's fine. The "bot" flag means "automated edit", and the "minor" flag means "small and obvious change", with both indicating less review is needed.  But, again, I'm talking about the opposite kind of edit.  Say there's a bot that, despite its excellent massive contributions, can sometimes cause additional work to be done depending on the article's current detailed context, which only the article's current editors can know.  So the bot must alert those humans to review its work.  This is currently done by the bot adding a new section to the talk page.  (Being bots, their template-driven context-free overly-formal talk page entries, by necessity, are... um... let's say "less than thrilling".)  Only a couple bots now running do this; I suspect there could be more bots like this, but we're reluctant to have a lot of bots cluttering talk pages, so we reluctantly decide to not let them run, loosing their potential great mass of good contributions.  But this new button could do much of the same job to urge review without the annoying talk page clutter.  More bots!
 * (I haven't heard of this, but guess that a bot that uses "bot" flag but not the "minor" flag could be interpreted as "please review this bot's edit". Is that true?  If so, great, we should announce this better, but more importantly, where's my button for the same thing?)
 * Again, bots are not the main point here; I bought it up as an example of the kind of edit that could use this new button. --A&#8239;D&#8239;Monroe&#8239;III(talk)  15:13, 15 June 2019 (UTC)
 * thanks for the updates, just looking for ways we can improve bot interactions even if this doesn't go anywhere. In general bots making content-related edits that should be reviewed should not use the "bot" flag on that edit.  These should be uncommon at best, but if you have some good examples we can look at that behavior (and feel free to bring it up at WP:BOTN. —  xaosflux  Talk 16:43, 15 June 2019 (UTC)


 * Not a bad idea, but what is wrong with putting something to the effect of "please review" in the edit summary? There's also the ORES review tool, which flags "potentially damaging" edits. Eman  235 / talk  23:11, 14 June 2019 (UTC)
 * ("Potentially damaging" is, I hope, not applicable to an "opposite of minor" edit; I don't think editors should be encouraged to have their edits cross this line just to get some attention.)
 * I agree that edit summaries are the best way to do this right now. Edit summaries are limited, so this works best if the indication is terse, right?  To be most effective, we could advise people to have the edit summary include the phrase "please review" (as suggested) or "interesting" or whatever we decide.  If we go that way, to be sure they get it correct, we should have some way to have this phrase generation automated, like with a button.  And then we could have reviewing tools search for this exact phrase.
 * Taken together, that's identical to my proposal here. I think a tag is better than a phrase, though.  But, maybe we could start implementing this by just a new guideline on edit summaries?  --A&#8239;D&#8239;Monroe&#8239;III(talk)  15:45, 15 June 2019 (UTC)


 * Don't we already have the opposite of "This is a minor edit" with the "Watch this page" box? Vorbee (talk) 15:03, 16 June 2019 (UTC)
 * Watchlist is similar, but it works the other way around. Putting something on my watchlist means I want to review other editors' changes. If I want other editors to review my edits, I can't force it onto others' watchlists.  And, watchlist is per page, not per edit.  --A&#8239;D&#8239;Monroe&#8239;III(talk)  14:32, 17 June 2019 (UTC)


 * Is it possible to mark content which changes a fair percentage of an article as major automatically? I think as we already have the diff size, this could be easily done by tweaking the ui. Viztor (talk) 21:23, 16 June 2019 (UTC)
 * We kind of have a weak version of this already, as edit history gives the size of each edit (it's the delta size, so not perfect in this respect). I'm okay with enhancing tools to automate finding edits to review based on various criteria, but that wouldn't address what I'm asking for here.  I want a tag that I decide to attach to one my own edits, indicating that despite any and all superficial characteristics of this edit, it still might be good for others to double-check it.  --A&#8239;D&#8239;Monroe&#8239;III(talk)  15:07, 17 June 2019 (UTC)

and  even if they don't have the ability to access checkuser or oversight "data". — xaosflux  Talk 16:35, 23 August 2019 (UTC)
 * and  as well - to further support non-admin arbs. —  xaosflux  Talk 16:36, 23 August 2019 (UTC)
 * While I agree with these ideas, if memory serves developers may object towards adding "checkuser-log", "suppressionlog" and "checkuser" to nonstandard user groups; flagging and  as they may be more familiar with any problems that such a change would cause. Jo-Jo Eumerus (talk, contributions) 16:40, 23 August 2019 (UTC)
 * I specifically didn't add "checkuser" in to that mix. — xaosflux  Talk 16:43, 23 August 2019 (UTC)
 * The contents of the checkuser log are as sensitive as the checkuser data itself. Maybe moreso since data rotates after 90 days but the logs are perpetual. Ivanvector (Talk/Edits) 16:46, 23 August 2019 (UTC)
 * What I mean by that is the log entries often read something like " got edits for, reason: sock check for " which inherently reveals restricted private information (an account's IP address). The data expires but the notes in the log do not. Ivanvector (Talk/Edits) 16:49, 23 August 2019 (UTC)
 * that is private information, but it doesn't have the result - just who the checker suspected. — xaosflux  Talk 17:09, 23 August 2019 (UTC)
 * You're right, but if you have access to the log of which IPs were checked for which accounts, and to the obviously public logs of which accounts are checkuser-blocked, you can easily discover the IP addresses of checkuser-blocked accounts, for the vast majority of reports. Ivanvector (Talk/Edits) 17:26, 23 August 2019 (UTC)
 * And similar could be said for OS, SDBAM would indicate that someone is a minor. As currently written the global policies would likely prevent this from happening. WMF Legal would have to sign off on whatever potential proposal came up. --Rschen7754 00:13, 26 August 2019 (UTC)
 * that is private information, but it doesn't have the result - just who the checker suspected. That's not true. If I were to check you with the reason Suspect socking, similar edits to editors edit warring at Foo and then immediately check an IP address or IP range with the same reason, it would be exceedingly obvious to anyone what your IP address is. If you use Comcast or Spectrum residential int he United States and don't move, it'd likely be the same IP address years later. The CU log can't confirm because it doesn't provide the other technical details, but the actual privacy stuff that people are concerned about is readily available for anyone with +checkuser to read without creating a log entry. TonyBallioni (talk) 00:33, 30 August 2019 (UTC)
 * My gut feeling is that this makes sense. I'm not privy to arbcom's day-to-day workload, but I'm guessing there's no real reason for arbs to need CU or OS to do their daily work, and it doesn't seem like there's a lot of overlap in the skills required, other than handling confidential information appropriately.  Arb is mostly about conflict resolution.  CU is mostly about looking at system logs and interpreting the technical information contained therein.  OS is mostly about making judgement calls on privacy questions.  If arbcom needs the services of CU or OS, they know where to find them.  Lumping them all together is kind of silly.  -- RoySmith (talk) 16:28, 23 August 2019 (UTC)
 * I'm conflicted about this. Three thoughts, somewhat contradictory: first, I personally like very much the notion of separation of powers. In an ideal universe, I think, crats, checkusers, and arbitrators would be three entirely non-overlapping sets of people (OS is different, because it's not an investigative power at all; it's simply to remove private information; as such, I don't really see a problem with tool overlap). Second, I think that as long as ARBCOM is tasked with dealing with private info, they're going to have to meet the same threshold of trust as CUOS, regardless of whether they hold the permissions or not. Third, and this is where it breaks down for me; I think the community as a whole is failing when it comes to electing people to positions of trust. We make it a hazing process, which does keep most bad people out, but which takes out a lot of good people also, and/or makes good people unwilling to put themselves forward. I'm referring here both to standards at RFA, and to the abuse that we subject administrators and (especially) arbitrators to. It's a rather paradoxical fact that our best arbitrator and admin candidates are often those who have skillfully negotiated areas ridden with conflict, but their having done so makes their candidacies attract a very unpleasant sort of opposition. Take a look at WP:CUOS2018, for instance; how many of us who were eventually selected would have received the tools in an RFA-type election? To sum up, I guess what I'm saying is this; in principle, I like the RFA-style system; in practice, I much prefer ARBCOM appointments, because the RFA system encourages blandly non-controversial candidates, and discourages those with actual experience with conflict. Vanamonde (Talk) 16:59, 23 August 2019 (UTC)
 * Leaving aside the role of Arbcom in all this and to what extent they would be more or less electable if CU/OS is unbundled from their permission set, I'm pretty neutral on whether functionaries should be appointed or elected. I'm leaning towards appointment because it's what we do now, and has the benefit of Arbcom being able to select candidates based on technical qualifications and their own criteria (last year they were specifically looking for functionaries who were regularly available to cover certain times of day, for example). But Arbcom could just as easily set that as a suggested framework for a community election. Someone mentioned the atypically acrimonious appointments from last year and the lack of any resulting drama: as far as I know the only functionary appointed in that round who is not currently a functionary is myself, and that was a resignation, not anything to do with conduct (as far as I'm aware anyway). I'm aware of functionary permissions having been abused in the past, but don't recall who or when except that it was dealt with quite silently. Ivanvector (Talk/Edits) 17:02, 23 August 2019 (UTC)
 * The main driver for my idea was that by splitting this element out, we could get more and better arb's as part of the "should Ivanvector be an arb" election wouldn't also need to be a "should he be a CUOS too" referendum. Perhaps that could be achieved by keeping the appointment process, but just not automatically making arbs CUOS's - if they want to become one they should use the existing framework of going through community consultation first? —  xaosflux  Talk 17:07, 23 August 2019 (UTC)
 * , part of the issue for me is that I am pretty unconvinced that CUOS is driving ArbCom elections - the electorate is just too huge and it's my deep suspicion that the overwhelming number of voters don't understand CUOS in any meaningful way. Am I correct that you think in the last three elections (e.g. recently) that some number of people new to ArbCom would have been elected? Because that's not quite my impression though admittedly I'm looking at two of those elections purely as they're documented now rather than having "lived through them". Best, Barkeep49 (talk) 17:20, 23 August 2019 (UTC)
 * I think it might be dissuading some non-admins from even running in the first place, and the 'voter guides' had some recurring themes of not an admin. The resignation thread is what brought me here, and was thinking this is a barrier that is keeping volunteers away. —  xaosflux  Talk 17:31, 23 August 2019 (UTC)
 * I do see what you're getting at, and I tend to agree but I think the proposed implementation is difficult - specifically I don't see how electing functionaries instead of appointing them accomplishes your goal. Arbs need to be able to see private data but not necessarily have access to the tools to collect it, so they need to be qualified to sign the nondisclosure agreement even if they're not also CU/OS (assuming they're unbundled). I suppose that's already a precondition in the arbcom election process though - candidates are made to state whether they have signed it or will sign it if they are elected and have not already. Do you think it would be an improvement to unbundle CU/OS even though they would still need to sign the NDA? Ivanvector (Talk/Edits) 17:35, 23 August 2019 (UTC)


 * One thing that's perhaps worth stating is why this is being proposed. From the delay of Arbitration/Requests/Case/Antisemitism in Poland, 's comment on accepting Arbitration/Requests/Case/Palestine-Israel articles 4 and the suspension of that case and the discussion here it seems like the Committee may be running into capacity issues; is that the reason why this proposal was made? (Note that I am already convinced; but it's worth saying so for other people). Incidentally, with respect to 's #3 concern perhaps we can say up front in the RfX process for CU and OS that people's arguments need to be on-point and that it's not a free for all - that RfA and RfB do not have such requirements does not imply that a RfX can't have one. Jo-Jo Eumerus (talk, contributions) 17:42, 23 August 2019 (UTC)
 * Hi, yes my primary "why" is that by not including some of these technical toolkits that people can be picky about we may get more otherwise qualified and active arbs during the next election. WP:NAC goes a long way to helping admins, and I'd be welcoming of more candidates applying to the arbcom election this year who wouldn't also have to be judged for fitness as a functionary (or admin while we're at it). —  xaosflux  Talk 17:53, 23 August 2019 (UTC)
 * That's a good point, we could state up front that off-topic comments or votes making up arbitrary irrelevant criteria will be clerked away. Dropping in on an RfOS and saying "oppose - hasn't written 9 featured articles" ought to be not just discouraged or expected to be disregarded, but actively removed. Or better yet, just make the elections more formal like the existing arbcom elections, with an election committee and secret ballot. Could even run mostly concurrently. Ivanvector (Talk/Edits) 17:58, 23 August 2019 (UTC)
 * Strict clerking would help, to be sure; but I think there's too many grudge-bearing contributors who know how to avoid being clerked out of the process. As another exhibit, I'd point you to Jbhunley's RFA, and the crat-chat that followed. I think there's three possible ways to get around that process; make the actual decision the purview of a small number of trusted users (this is what we're doing right now); make the electorate large enough that the grudges don't matter (difficult, because you can't make people vote); or limit the electorate in some way (even more difficult, because it runs contrary to a lot of our principles, and even the usual "who do we notify" discussions become very acrimonious. To make this workable, we could have CUOS elections at the same time as ARBCOM elections, and thereby ensure high participation; but then would it still have the effect that is looking for? Vanamonde (Talk) 18:09, 23 August 2019 (UTC)
 * Also, another thing, but CU and OS (especially OS) do not carry the same implication of authority that adminship has and most people never encounter the CU and OS processes, so I suspect there will be less problem behaviours in a RfCUOS than in RfA. Jo-Jo Eumerus (talk, contributions) 18:16, 23 August 2019 (UTC)
 * Take a look at WP:CUOS2018... Vanamonde (Talk) 18:17, 23 August 2019 (UTC)
 * As I see it, there are two interconnected but separable issues here. One is how to design the OS and CU selection process, and the other is whether someone on ArbCom must also be required to qualify as an OS and CU. It seems to me that the goal here is to get more qualified people onto ArbCom, to open the process up to more persons. That being the case, it is worth pursuing further the idea of allowing some Arbs to be non-functionaries. (If that were to become the case, then not all Arbs could participate in some of the private off-site responsibilities of the Committee.) But we do not need to change the selection process for functionaries in order to accomplish that. It seems to me that the current system of ArbCom running the selection of OS and CU is working, so if it isn't broke, we don't need to fix it. That would just mean that a subset of ArbCom would run that selection. --Tryptofish (talk) 18:51, 23 August 2019 (UTC)
 * perhaps just void the auto CUOS for arbcom, having them run through the normal community consultation/appointment process (obviously they would be recused from voting on themselves in the committee). — xaosflux  Talk 19:07, 23 August 2019 (UTC)
 * Yes. --Tryptofish (talk) 19:14, 23 August 2019 (UTC)
 * Huh - to me it sounded like the point of this effort was to offload the CU/OS vetting process from Arbcom. Jo-Jo Eumerus (talk, contributions) 20:20, 23 August 2019 (UTC)
 * my main idea point was to get things (like on-demand becoming an CUOS) out of the way of people becoming arbs. — xaosflux  Talk 20:33, 23 August 2019 (UTC)
 * I feel that I should add that I think, especially after reading the comment just below, that there are sufficiently many problems with having non-CUOS Arbs, that this idea probably won't really work. --Tryptofish (talk) 21:18, 23 August 2019 (UTC)
 * I'd be fervently against not automatically giving Arbs CUOS access. Cases already take forever, while they'd obviously have first call on CU time, it just seems like something else that would put grit into the process. Someone who thinks an Arb might be problematic as a CU/OS should be asking those questions in the election. In terms of the 2nd question of should non-ARBs have an election for CU/OS rather than it being decided by ARBCOM. I'm just inclined to ask...why? We Wikipedians like saying "solution without a problem" and I feel it applies here. As a third possible RfC, we should amend it so that ARBs no longer automatically retain their CU/OS after leaving their position (and concluding their final case). Nosebagbear (talk) 19:43, 23 August 2019 (UTC)
 * A few comments based on long experience. Really, really think about how an election will happen and who can be candidates *before* proposing a change to the Arbcom policy. Pre-vetting of candidates is the genuine Arbcom contribution to the CU/OS election process, and I can speak from 5 years of arbcom experience in saying that there have been a lot of problem applicants, at least a few of whom might have been successfully elected. There's a lot of trolling value in opening the doors too wide, and it's possible that a genuine problem editor could pass the 70% threshold and get hold of these privacy-related tools.  So really, really think about it.  And then think about it some more. Once candidates have been selected, the community could pretty much run the election, setting voter rules and everything else, and arbcom would pretty well be certain to appoint successful candidates. But really think about how the community is going to control who gets to be a candidate - particularly if the "red flags" aren't publicly documented.  SecurePoll is a bad idea for these roles. We've learned from the one CU/OS SecurePoll "election" and from Arbcom elections that it really lowers the level of support as compared to public voting.  The fact that, even in much more liberal 2010 and with a lot of good candidates, only one candidate passed on the CU/OS SecurePoll election, suggests we'd be lucky to have anyone pass today. Note that most arbitrators aren't hitting 70% support in the last few arbcom elections.  So...public voting or don't waste everyone's time.  If Arbcom is taken out of the picture for appointing CU/OS, and they aren't going to be in a position to monitor their behaviour because they won't automatically be given access to the tools, who will be responsible for *removing CU/OS*?  We already know that the numbers on the Audit statistics don't really show the whole picture - for example, there's no way to indicate the number of requests that an oversighter turns down, or which checkuser has focused on building up data on checkuserwiki - so even inactivity stats are a pretty shaky way to determine tool removal, especially for oversighters. Note that this isn't the role of the ombuds. Term limits are always an issue, because experience and knowledge of historical socks really is important for CUs especially (oversighters not so much).  We get more malicious socks here than pretty much the rest of the projects combined.  It's pretty likely that IP masking is going to come into effect at some point in the next few years. This will have a big effect on managing vandalism. While there are already efforts to work on tools so that administrators and perhaps other trusted users can look at range blocks and so on, it's pretty likely that this project's need for active, knowledgeable checkusers will increase.  How is the community going to deal with that?  In other words, if you're thinking of stripping the responsibility of CU/OS from arbcom, just creating elections isn't enough.  You have to think about ALL aspects of CU/OS - screening candidates, addressing problems, oversight of the rights holders, removal of permissions, what to do when arbitrators *need* access to CU or OS information (it's the main reason why they have this permission nowadays), everything.  We're the biggest project, and we do more suppressions than the rest of the projects combined. We do more checkusers, and block more socks, and deal with more problem users.  This discussion doesn't seem to be about doing things better. It seems to be about reducing arbcom's workload.  We have enough CU/OS to make it through to the end of this arbcom's term; they don't have to do anything about us right now.  They've already lifted permissions from the inactive folks, the recent resignations have not had a significantly negative impact; most OS requests are managed within an hour of receipt, and SPIs requiring CU are handled in a reasonable time. There's a case to be made that CU/OS should be managed by the community; it was certainly the direction we were heading when I was on Arbcom back in the days of electing CU/OS, but those goals were derailed by the poor outcome of the SecurePoll election in 2010.  But proposing a major change like this mainly to lighten arbcom's workload...that isn't the case.  Risker (talk) 00:23, 24 August 2019 (UTC)
 * thank you for the history! I think we are making good use of Idea Lab here - as I certainly didn't want to bring some half-baked RfC to the larger community.  My primary motivation was to try to "lower the bar" to volunteers wanting to be on ArbCom that may otherwise be opposed because of our defacto "you get elected to arbcom - you get CU/OS access (basically for life)" situation.  Do you have any thoughts in to the ideas of "all CU/OS's should go through the same process" (community input, followed by appointment).  There have been some good arguments to get non-admins on arbcom, but with them jumping over RFA and going straight to CUOS it has (reasonable) opposition each term.  As far as the lifetime appointment item - I would have brought up options for fixed terms/reconfirmations during an actual RfC. —  xaosflux  Talk 02:12, 24 August 2019 (UTC)
 * Hi . I suspect most people in the community are currently unaware that both the checkuser and the oversight function are not dependent on having adminship; the tools are built in a way that a non-admin can use them, and we can thank for that initiative.  In reality, it's a bit challenging to be a fully effective checkuser if you don't have blocking permissions, although it is possible, and some checkusers doing SPI (including myself) leave blocks to others already. We did have an AUSC member who was not an admin at the time of election/appointment, and the lack of adminship didn't impair his function, although he did go on to RFA not long after his appointment.  Something else to keep in mind is that about half of the former arbs who still have CU/OS were either arbs before our project really got into granting CU/OS bits to community members in 2009 ( for CU and myself for both), or they were already CU/OS when they became arbs. In 2009-10, with the advent of revision-deletion, we made major changes to the goals of OS, so that the key factor is getting it done quickly (most are done within the hour now). I doubt there are many people reading this who remember that prior to 2009, the normal OS request turnaround time was about a month. (Yes, you read that right.) I also do not think that most people are aware that looking at suppressed materials, suppression logs, CU logs, and CU results is something that arbs have to do in order to do their jobs.  The current confidentiality agreements that CU and OS have to sign off on would prevent us (including those who are current arbs) from sharing the information with non-CU/OS arbs; in fact, CU can't share with OS, and vice versa. Those tools are pretty much mandatory for them in the 2019 context.  There have been entire cases where access to that data has been a key factor in Arbcom decisions, both those that are mostly known to the community (except for the material covered under the privacy policy) and those that are carried out entirely sub rosa.  Example of the latter: person privately appeals a CU block to Arbcom (they can't do it onwiki), Arbcom does further checks and looks at the logs, may or may not find more socks, and decide to decline without a public statement.   Whether former arbs get to keep them for life is sort of a separate issue. As is pretty obvious from the list of current CU and OS, the majority of former arbitrators have neither tool, only a couple of us have had it for more than 5 years post arbcom and both of us are active in the tools and their related functions, and there's actually a "kill switch" built in so that if they don't meet activity requirements for a year post-arbcom, they lose them automatically.   As to non-admins on Arbcom, I'm pretty sure that the CU/OS issue isn't the determining factor in the lack of success there. Most users are probably wanting to see evidence of dealing with difficult situations that have resulted in blocks or sanctions, and non-admins generally don't have that kind of history. The non-admins who have run over many years have usually wound up near the bottom of the table, and I suspect it's more likely due to lack of what voters consider relevant experience, rather than that they'll skip RFA to get CU/OS.  That should be particularly true in light of the fact that non-admins can already run for and be appointed as CU/OS.  Is this helping?  Risker (talk) 03:30, 24 August 2019 (UTC)
 * yes, thanks - I'm getting a feeling this isn't going to be a way to get more quality volunteers in to arbcom, but that's why we have the idea lab :) — xaosflux  Talk 04:00, 24 August 2019 (UTC)
 * Quite agreed, - happy to provide some background information, and I'm quite happy that people are trying to come up with positive, community-based improvements in our "governance" model.  It was bittersweet to look back on all those hopes we had back in 2009 when so many of us were brand-new arbitrators. We did manage to make a lot of positive changes (a decent Arbcom policy, much more structure for functionaries with significant improvement in service, and pushing the WMF really hard to accept responsibility for things that are now carried out by "emergency@wikimedia" and Trust & Safety), but I've always been a tiny bit disappointed we weren't successful with getting CU/OS further embedded into community responsibility, even if they couldn't do 100% of it. Bottom line, though...at least half of current CU/OS, including the most active members of both teams, are appointed out of the community.  I admit I'm really worried that we're not seeing enough "fresh blood" on Arbcom, but that seems to be a lot more related to candidates coming forward than new candidates not succeeding, from what I can see.  Risker (talk) 04:16, 24 August 2019 (UTC)
 * I'm not quite sure what you mean with 'fresh blood', . Do you mean more, less experienced users, or users who have a good institutional memory but who do not run for Arbcom? The problem with Arbcom elections is that so few candidates are coming forward that there is a risk that all those with the qualifying %age  will get a seat on the committee but might not really be sufficiently qualified for it. I am reminded of 's concerns above why editors of the right calibre are not coming forward - for the same reasons as RfA has become a rare occurrence.  What we need back on Arbcom is you (or people with your knowledge)- but I would fully understand why you would not wish to com back for another 2-year stint.Kudpung กุดผึ้ง (talk) 08:12, 24 August 2019 (UTC)
 * I think you're wrong on a few counts here, . I don't think Arbcom as an entity is really benefitting from all its recycled members; in fact, I think it's the opposite.  I think my participating as an arbitrator again would be a very bad sign, indicating that this project is running out of fresh ideas, and that we don't have anyone but us old retreads to do certain jobs.  I think it's extremely concerning that there is only one current arb on his first term on the committee.  And no, I don't think that the problem is lack of people of the right calibre; there are plenty of them out there.  I want people with a lot less experience on arbcom. I want people who don't remember all the way back to the Ark.  We need less knowledge and experience and more willingness to try new things and give new people a chance at things. It's a durable project, it can survive a lot of things. The bigger danger is that we become so afraid to take any chances that we allow things to fossilize...and I'm afraid that's happening to Arbcom now.  I'm pretty sure nobody on the current committee really *wants* to do another term. I'm pretty sure most former arbs don't really want to do another turn (with the possible exception of a couple who really *were* problems). Those who do so are often doing it out of a sense of duty rather than interest or other motivating factor, and I'm not sure I'd trust a returning arb who said otherwise. No, we need new people to do things.  I will take a moment to throw in a very rare boast: when I was first appointed to arbcom in 2009, the majority of the committee was assuming these roles of authority and responsibility for the first time. We changed the committee and we changed the WMF and we changed the project in the five years that followed. We need to do that again. Risker (talk) 14:42, 24 August 2019 (UTC)
 * I agree with your analysis and would love some idea lab mooting on your question of "How do we attract and support a much wider range of community members to participate in dispute resolution, ones with different experiences and history". Best, Barkeep49 (talk) 15:26, 24 August 2019 (UTC)


 * I think Risker brings up valid concerns. While I was on ArbCom, while I didn't every day use the checkuser and/or oversight tools, I certainly did need them in the course of arbitration-related activities (in some cases, no more or less than the simple ability to review a suppressed revision when a question was raised about it). Had I had to request someone else to do that and wait on it, that would've added to the workload, not subtracted from it. I would also add that if I did not trust someone enough to grant them access to the checkuser and oversight tools, I damn sure do not trust them enough to grant them access to the type of sensitive information ArbCom does with some frequency handle. If someone is not extremely trustworthy with sensitive information, they should not be on ArbCom, period. If they are, it's not a problem for them to have CU and/or OS. Seraphimblade Talk to me 15:01, 24 August 2019 (UTC)


 * Thanks and all those participating. This is not a "waste of time". The idea is to examine all areas to see "if" there can be improvements "somewhere" that will address issues ultimately improving the operations side of Wikipedia. I think a discussion without a timeline, until it plays out or a solution is determined, is important. Knee-jerk reactions seem to be an inherent human response and can foster ill will even when that clearly was not the intent. A better approach is to "brain storm" with calmness and collaboration as opposed to some "us against them" mentality. Look at the "down-side" of things and consider ---but can we make it work? Mistakes will always happen but then it is time to rectify things moving forward and not try to lay blame or alienate others.
 * I think the community micro-managing the internal workings of ArbCom is not a great idea. Allow newer members to be elected so more work can be accomplished while having some restrictions and safety would be a great idea. This will not actually be "lowering the bar" of anything just ensuring we have necessary protections where it is critical. It would seem this may actually add an element of safety concerning new ArnCom members.


 * : On the thought of trust. The entire process from the start is that we can generally only go on what we "see", as evidenced by the history of certain editors. I have not examined this close enough but there is some merit of consideration, can this be figured out "if" it was implemented. The concern is the status-quo becomes the catch-22 as mentioned by Risker about needing "new people". If changes cannot be figured out we have a recurring situation similar to the lot of new US congressmen that was going to implement "sweeping change" in the US and found a brick wall at every turn because seniority held the purse strings. Here we have those we trust running again, and those that "might" do a great job or make a difference if they were to be allowed ---but not allowed because we "just don't know if we can trust them".
 * Here is my problem: I don't personally know anyone on Wikipedia. We largely operate under anonymous user names and there is no mandate for a persons real-life persona to be attached that I know of. Some do but that is not a requirement so many times we can only go on what we know here in the Wikipedia world. "IF" there is a potential that the wrong person could be given access to sensitive information, and there is a remote possibility of misusing it, then how can we make a move to allow "new blood" with assurances this can be minimized? We have Stewards that have CU and/or OS permissions. They are also a first point of contact (liaison) between the WMF and the community. Surely there can be a way a new ArbCom member could request this from them, other members of ArbCom, or both in the capacity of ArbCom members, without further need for community involvement? If it is a "new" member then possibly the Stewards and current members of ArbCom vote on if a request for permission is warranted or needed.
 * The idea goes along with expanding ArbCom. I am in the US so please excuse the continued reference in that regard but a new member of Congress does not "automatically" gain access to sensitive military information. That falls under a specific committee with oversight. I would offer that any current ArbCom member, or former member that has held the position in good standing would automatically grandfather. That would be a discussion to be had but if you currently have it, or had it without issue, ---then it would seem to be insane to consider stripping it for no reason right? I am just looking at this from a "how can we make improvements", ensuring that protections are in place, while also allowing a way others can hope to run and stand any chance of succeeding. It will do no good to expand the number of ArbCom members if there is no way to fill the spots.
 * The idea of "a panel (or committee) of three" to examine a case, with added "safe-guards" for appeals, does not seem a bad idea. I do not follow the complication. If there is not an available "Steward" or member with the permissions then some internal organization could mandate a temporary authorization to one of the panel. Some may not even want the permissions so why give it, or have it, if it is would never be used? That just seems too simple and if there are restrictions why this could not be implemented then change the "rules". We "trust" the Stewards and ArbCom members so why could we not trust that they will protect their own process within the guidelines the community provides.
 * After seeing some really crappy responses from at least one ArbCom member I am certain there needs to be "one" chosen as a "voice" when responding to the community. We saw from the T&S communications debacle that some people may be fantastic, great assets, maybe doing a super fantastic job, but their communications skills may be severely lacking so they might not need to be selected (or choose) to try to communicate with others. I don't know the internal working of ArbCom but our projects usually have an administrator or "lead" so if that is not the case within ArbCom why would it not be a consideration.
 * Panels or committees: Pick three members, that are available to handle a case, see if there is a member with the needed permissions, maybe one "veteran", and if one has to drop out --appoint a replacement and take a short break while the case is examined.
 * The same panel idea could apply specifically to any ArbCom case involving civility like attacks, harassment, or Admin issues.
 * A goal here would be more help, less caseload and stress, and not ever having to refuse an important case because of a case over-load. Also I would think, since this is not a US Supreme Court, remanding back down should be used when warranted but "if" say three or more Admins or community consensus deems it needed then ArbCom should possible re-examine a remanded case. None of this will matter if we cannot do something to allow more members to begin with.
 * There does have to be some "rules" like total transparency on all things where it is possible and those needed for clarification, so I also think the suggestions of Nosebagbear at Wikipedia talk:Arbitration Committee/Noticeboard are worthy of consideration. Some of my ideas may be insane or already attempted but just continuing in a catch-22 will never arrive at a solution. If figured out correctly I could see where more caseloads could be handled, as well as a committee to examine our application of policies according to any WMF mandates, and report to the community what is not "private". Otr500 (talk) 08:56, 25 August 2019 (UTC)
 * Thank you for raising that Otr500 - I do feel they have the benefit that they can be introduced regardless of how other discussions break down, would be nice to get a few more thoughts on their pros & (critically) cons. Particularly from an ARBCOM member or two Nosebagbear (talk) 11:41, 25 August 2019 (UTC)


 * I agree generally with, having talked with her about this in private before, but I do also want to add my own take: I am not actually at all concerned that the RfCU or RfOS would not elect qualified people. The much larger concern in my opinion is that the community would elect popular administrators who under no circumstances should be a functionary as functionaries. ArbCom does an exceedingly good job at controlling for this precisely because it can consider things privately and allow people to raise concerns that cannot be raised or they do not feel comfortable sharing in public.Without going into too many details, local communities electing individuals who should not be trusted with private data is a major issue on other projects and there are CUs serving on some projects that if they were active on en.wiki would be indefinitely blocked very quickly. We have even blocked elected CUs from other projects for socking on en.wiki (see ). In fact, the only recent example of a CU abusing their tools for political purposes was not one of the community appointed CUs, it was someone who gained CU through a democratic election to the Arbitration Committee, . This doesn't even get into the issues with zh.wiki, which was also a project that had elections, if I recall correctly.This is not to say projects with CU elections don't produce good CUs, many do. I have great cross-wiki relationships and have worked closely with CUs from projects where elections happen that I trust and think do an excellent job. It is saying that projects with appointed CUs have historically had significantly less issues than projects with CU elections. The issue here is not with not enough good candidates getting CU/OS, the issue is that Wikimedia communities have historically done a horrible job of screening abusive CU/OS via elections. TonyBallioni (talk) 00:11, 30 August 2019 (UTC)
 * I think the only way this could work would be if we did it how it was in 2008-2010ish: ArbCom remains involved in vetting candidates before the vote, voting doesn't use SecurePoll, and ArbCom retains the right to remove rights. I will say that steward elections are entirely public and generally that works - but there is a lot of scrutiny there. --Rschen7754 01:03, 30 August 2019 (UTC)

Wikipedia reform
In a 2005 Signpost article there were calls for reform It stated "Along with the criticism of the committee, various proposals and reforms have been suggested since the ArbCom began operation." as well as at the end it stated "Throughout ArbCom's existence, there have been many calls for reform." (what-4 years by then), "to make the system more effective". A two tiered system had been presented and reference that there be "magistrates" or a lower court, if you will. It was suggested that the Mediation Committee, Association of Members' Advocates (AMA), and RFC be used more extensively. I have not compared the ArbCom structure of then versus now but a grand scheme of the community to [close down MC did happen]. It was little used, toothless (no real authority), redundant, covered content and not behavior issues, so was ineffective. It might have been more effectual as an arm or extension of ArbCom but that was not apparently part of the discussion at the time. Some history was presented here. The AMA is also no longer and I have seen adamant statements that mentoring "does not work". There were suggestions that ArbCom be worked like "Request for Admin" but also stated it would be a popularity contest. If something like that happened there would absolutely need to be a protection system in place on CU and/or OS permissions other than those concerns I would think we can fix something a "new member" screwed up with minimum risk. We can't in effect digress in 14 years, not explore all options, and just blame ArbCom for failing after assuring the WMF we can handle our own affairs. I think around 12,000 editors with 1,149 Admins might give enough representation but only 8 ArbCom members (18 bureaucrats and 36 Stewards) might be enough "if" they functioned "just" as a sort of Supreme Court. We can't change the mindset of editors without being able to handle situations as fast as possible to prevent harm to editors or Wikipedia. Otr500 (talk) 14:18, 25 August 2019 (UTC)
 * Please don't for a minute, even as a passing thought, develop any plans that involve stewards. First off, they're solely responsible for checkuser/oversight on over 700 wikis, and also act as administrators on those that don't have admins. It's more than enough work for fewer than 40 volunteers, and it would be wrong for us to depend on them to do anything more than flipping the switches for the CU/OS rights; the Arbcom election committees have had enough of a challenge to get at least 3 volunteer stewards to handle SecurePoll for our Arbcom elections. They're also, as a group, quite vocal that their role is not dispute resolution in any way, shape or form. Again, given we're likely to see IP masking within the relatively near future, the global community is going to need more stewards just to carry out their assigned roles, and that precludes them taking on any new ones. For that matter, our own Bureaucrats have been pretty vocal over the years that their role is limited to assessing consensus for RFX, and approving bots; back before SUL, they did account renaming, but that was a very long time ago. They've actively avoided accepting any role in dispute resolution outside of their specific parameters, or even using their experience in assessing consensus to determine consensus in any other discussions but RFX.  Having said that, we've seen many 'crats take on additional roles as CU, OS, or arbitrator, and even a few enwiki-based stewards hold (or have held) CU or OS or both on this project. For that matter, as can be seen from the list of current arbitrators, many started off as CU or OS and took on the additional arb hat. Again, though...we're depending on the existing "leaders" to simply keep taking on more roles and responsibilities instead of actively developing and bringing forward new candidates. This is on all of us.  Arbcom is not now, nor has it ever been, a "supreme court".  It is probably this misdirected mindset that makes the role so unattractive to many, and I urge everyone to stop talking that way.  It just isn't.  The more people have treated it as a judicial system, the less effective it has been.  This is a website, it's not a nation-state.  There is almost nothing that can happen on this website that is addressed by Arbcom or any of the functionary roles that is of any import to the world outside the website; sure, there'll be passing references in the media about a big socking ring or someone messing around on a politician's article, but it's ephemeral. We should drop our pretense of self-importance, and recognize that Arbcom's role is dealing with problem users in a way that promotes the continued success of the encyclopedia. Frankly, they don't even have to be right to be effective.  Risker (talk) 20:13, 25 August 2019 (UTC)
 * It's true for the most part the enwiki 'Crat's are not interested in running any sort of dispute resolution processes. We do have a few other rare tasks, but they are indeed rare.  If a community desysop/recall process ever takes off I'd expect our 'crat to be involved in that.  Importantly, all of our 'crats are also admins, I spend a lot more time using my admin toolset then my 'crat one. I doubt there would be any strong support for using stewards here (the once a year ask of 3 of them to assist in the election process not withstanding) - probably just short of support for asking T&S to take over dispute resolution :D —  xaosflux  Talk 20:30, 25 August 2019 (UTC)
 * Wikipedia is one of the most popular websites in the world. When one searches Google or asks some knowledgebase a question, chances are the answer comes from Wikipedia.  This has a real impact.  If a cabal of Wikipedia editors label a major political party as fascist, and Arbcom decides this is perfectly legit, that party may very well lose some elections because of Wikipedia.  That said, it's still mostly just wikidrama.  Maybe a lot of people are turned off by the "supreme court" meme, but, personally, I suspect the workload, adjudicating boring content disputes, and the abuse hurled at Arbcom are the major reasons that people resist running. NinjaRobotPirate (talk) 00:50, 26 August 2019 (UTC)
 * If it were "adjudicating boring content disputes" I think there'd be more people willing to step up, as there'd be a direct effect on improving Wikipedia articles. The problem is that it's managing interpersonal conduct issues, one of the hardest tasks any group has to deal with, without anything more than personal motivation to provide satisfaction. isaacl (talk) 01:30, 26 August 2019 (UTC)
 * When I say "content dispute", I guess what I mean is "long-running content dispute that is now framed in terms of conduct". Arbcom doesn't hear cases about content disputes, but it will hear your complaint about how User:Example and a team of meat puppets are POV-pushing in some contentious topic. NinjaRobotPirate (talk) 02:54, 26 August 2019 (UTC)

Drafting a partial blocks RfC
A few weeks ago, I started a discussion on 's talk page regarding partial blocks and whether the English Wikipedia had any interest in adopting this feature. As a result of the discussion, I created a draft RfC which is now at Requests for comment/Partial blocks. I wanted to push this here to get more input on the draft. Is the format too messy? For "Option B", the limited implementation, should we include more subcases to start? Should we allow users to add their own suggested subcases during the RfC? Mz7 (talk) 21:35, 10 April 2019 (UTC)
 * In response to your question re. enforcing vs. recording editing restrictions, I was mostly trying to put into word the proposal about recording restrictions that MusikAnimal had suggested – presumably part of the purpose would be to help enforce editing restrictions, with the caveat that the restriction might apply to pages not covered by the block. I've added the word "enforcing" to B.3 to clarify this. Mz7 (talk) 21:39, 10 April 2019 (UTC)
 * I would like to ping to this discussion, since she has information about how other Wikipedia (e.g. Italian Wikipedia) have used partial blocks. Perhaps we might choose to follow the lead of other projects in deciding how to implement this. Mz7 (talk) 21:39, 10 April 2019 (UTC)
 * Mz7, I'm working on getting metrics and use cases for partial blocks for the wikis that are using them now during the testing phase. SPoore (WMF), Strategist, Community health initiative (talk) 20:00, 15 April 2019 (UTC)
 * What would the most common use cases for admins be if they had free-reign (Option C)? Tazerdadog (talk) 00:00, 11 April 2019 (UTC)


 * It seems to me that the way you've structured the RFC with respect to option B would get messy quick. I think as the RFC progresses people would add more use cases to B, and people who !vote early on may not come back to evaluate the later added options.  It might be better to make it a two part RFC, and if option B (allow partial blocks in specific use cases) passes, then have a second RFC on what use cases people want.  While discussion of the first part progresses, there should be a sub section for discussion (but not !voting) of possible use cases to be added to the second part. ~  ONUnicorn (Talk&#124;Contribs) problem solving 16:21, 12 April 2019 (UTC)
 * Right, I had that thought as well. Your two-parter RfC idea did cross my mind, and I think I will change the draft to that format. Thanks! Mz7 (talk) 02:05, 13 April 2019 (UTC)
 * I don't know if Sydney's got all the information together, but I hear that there are some cultural differences, partly based on how a community feels about blocking established editors/vested contributors. At some wikis, blocking a "regular", regardless of how bad the behavior is, brings down wrath on the admin, because now there will be a permanent badge of shame in the user's block log.  Blocking anyone except newbies is seen at some wikis as an insult, rather than a technical means to interrupt some bad behavior.  But since what they're calling "partial blocks" aren't regular blocks, and therefore aren't recorded in the regular Special:Log/block, some communities feel like this is a more appropriate way to deal with established editors – more like a technical way of saying "Hey, we like having you here overall, but you need to take a break from this particular page for a couple of days".
 * I don't know that we'd see the same dynamic in this community, but I think that team will have interesting things to say as they analyze what's been going on. Whatamidoing (WMF) (talk) 19:25, 23 April 2019 (UTC)
 * I'm not sure I understand. The current guidance seems to indicate that these are recorded in the block log as normal.  G M G  <sup style="color:#000;font-family:Impact">talk  11:00, 1 May 2019 (UTC)
 * I'm sure that it's logged somewhere, but I can't find any specifically in Special:Log/block. The feature's under active development, so they may have tried different things at different times.  Whatamidoing (WMF) (talk) 15:18, 3 May 2019 (UTC)
 * Not sure if this is off-topic or not, but is it technically possible to block a user from editing a page and all its subpages, or pages that contain a particular string in their names? For example, would it be possible to block a user from editing all subpages of Articles for deletion? feminist (talk) 10:26, 29 April 2019 (UTC)
 * does this feature allow an admin to block a user from editing a particular set of pages (subpages, etc.)? feminist (talk) 10:03, 1 May 2019 (UTC)
 * As far as I am aware, partial blocks only prevent editing on specific pages – I don't think you can block the user from a set of subpages, but you can block access to namespaces (e.g. can't edit articles, but can edit talk pages). Adding the ability to block over subpages sounds like something we can suggest to the developers of the feature if it is something we're interested in. Mz7 (talk) 21:37, 1 May 2019 (UTC)
 * OK then. It seems like an important feature to me, e.g. if someone is problematic at AfD we should be able to block her from editing AfD discussions, while continuing to allow her to edit, say, RFPP. But what we have is better than nothing. feminist (talk) 05:21, 2 May 2019 (UTC)


 * As a variant of B, can we have as an option preventing the use of them under WP:DS? As its not a current power, I don't feel we're revoking any authority that would otherwise require another ARBCOM amendment. I very strongly agree that B should be done in a distinct RfC - this is just a suggestion for "if and when B is selected" Nosebagbear (talk) 21:53, 1 May 2019 (UTC)
 * Maybe some day, but not yet. One of the ideas is to allow partial blocks to operate via categories.  The use cases look something like:
 * Keep the editor out of 1 to 10 named pages (currently available) – good for routine disputes.
 * Keep the editor out of this namespace – imagine being able to block a paid editor from the mainspace entirely, or stopping someone from breaking templates.
 * Keep the editor out of a large group of pages – routine POV pushing across more than 10 pages or imposing discretionary sanctions.
 * The last one is the category idea. You could create hidden categories for each of the ArbCom discretionary sanctions areas, or a specific list for an individual, and block the user from anything in that category.  You'd have to watch additions/removals from the cats closely, but there are tools to do that, and it might reduce the number of problems with accidental TBAN violations (e.g., if a subject is connected to the TBAN area, but the connection is not apparent to the editor).  Whatamidoing (WMF) (talk) 15:30, 3 May 2019 (UTC)
 * - in your initial discussion you raised basing it off the ECP discussions board (which seems reasonable enough). Having read that, since it predates my active existence by 19 months, the closer mentioned an ECP review to take place 3 months after. Did that occur? And in either case, I would say a 3 month review to discuss how it was working would seem wise here, too. (I don't mean on the ACTRIAL/ACPERM level of requiring re-authorisation, just a mandated discussion of how it was working for en.wiki). Nosebagbear (talk) 14:13, 5 May 2019 (UTC)
 * , I'm not sure whether the specific ECP review that was mentioned in the closing statement was ever conducted, but there have been several discussions since then about the role of ECP if you scroll through the archives of WT:PP. We also had a follow-up RfC that proposed expanding the scope of ECP at Requests for comment/Extended confirmed protection policy 2. Going back to partial blocks, I would be unopposed to a review after 3 months to evaluate how it's going. Mz7 (talk) 20:34, 6 May 2019 (UTC)
 * Comment - timed article t-bans work and serve the same cool-down purpose. Unfortunately, we now have admins using sole discretion to impose indefs and broadly construed t-bans. I'm not convinced that doing so best serves the project. When there is edit warring, and/or disruptive behavior on an article TP, all of the involved edit warriors/disruptors (be it 2 or 5+) should receive the same t-ban. Doing so further relieves the acting admin of having to choose sides or delve into content issues that spawned the disruption and eliminates any appearance of bias on behalf of the admin, perceived or otherwise. It will also encourage a more collegial environment. <span style="text-shadow:#F8F8FF 0.2em 0.2em 0.4em,#F4BBFF -0.2em -0.3em 0.6em,#BFFF00 0.8em 0.8em 0.6em;color:#A2006D">Atsme Talk 📧 11:03, 23 May 2019 (UTC)
 * Personally, I think we can experiment, and use the RFC to discuss best practices. By experimenting we can see where the tool would become useful in practice, and we can make changes and discussion and understand the logic behind the admin and the feedback from the target and other editors.  I have been waiting a while for something like this (partly because historically I have caused problems that could have been stopped with a partial block, and partly because I see full blocks as an invitation to create sockpuppets that last for years such as User:Scibaby), and I think the RfC should have a few sections:
 * no partial blocks, full blocks only
 * partial blocks only by arbitration decision
 * partial blocks only by either arbitration decision or community consensus
 * partial blocks only when an editor has been edit warring (in addition to ArbCom and CBAN)
 * partial blocks when an administrator has determined that a full block may cause more problems, such as sockpuppetry or WP:DONTBITE.
 * I would also have a section designed to formulate the partial block message which can be commented on by community consensus (relevant interface pages include MediaWiki:blocked-email-user and MediaWiki:blockedtext-partial). But I have been waiting for something like this because sometimes full blocks may not be super appropriate.  If a user only causes disruption to Wikipedia processes, only block them from the Project: namespace.  If a user makes bogus edit requests, only block them from talk pages.  If a user cannot stop criticizing Donald Trump, only block them from Donald Trump and related pages.  Full blocks prevent otherwise useful edits elsewhere from happening, and that is why I see this RFC as important.
 * I also have a question: when will this RFC open?   Awesome  <span style="color:blue;" title="Check my status before pinging or posting to my talk page!">Aasim  05:49, 3 June 2019 (UTC)
 * Currently we are still waiting for to send over her research on how this functionality is being used on other projects, but I recognize that it has been several months now since we started talking about this. I'm thinking we'll start the RfC "sometime this summer", maybe in July if SPoore hasn't gotten back to us by then. I'm also starting to dislike the current structure I have for the RfC (see Requests for comment/Partial blocks). Maybe the RfC should be in two phases: phase 1 would be "yes" or "no" to "should we enable partial blocks?", and phase 2 would be "what restrictions, if any, should we place?". Mz7 (talk) 20:06, 10 June 2019 (UTC)


 * - that all seems reasonable, both in terms of timing and split of RfC. July seems a good wait - partial blocks are currently getting an unfair blowback from the Fram saga, and it'd be nice to give them a fair hearing. Do we need extra discussion about the specific options for the "what restrictions" bit? Should that be now, or, if/when it's conceptually passed, we ask editors to suggest what they'd like to see? Nosebagbear (talk) 20:56, 15 June 2019 (UTC)
 * Hello! I'm Niharika, the product manager on Partial blocks (working alongside Sydney). I reached out to our data analyst to see if there was some preliminary data about partial blocks usage that we can share. Partial blocks is enabled on 17 websites at the moment. Many of these have only recently received partial blocks, so we don't have data to share for them all. Here is a handy table showing number of partial blocks imposed per month on some wikis with the caveat that it only counts blocks made on registered users and not IP addresses. Partial blocks are requently made for IP addresses but due to technical limitations we are not able to record them here.
 * Italian wikipedia was among the first to receive partial blocks and thus shows most usage of the feature so far. It is worth noting that all of these sites are much smaller than English wikipedia, so don't focus too much on the number itself. We are going to be updating that data periodically as we get more stats. Our data analyst (Morten aka Nettrom) will be sharing more about these numbers in the Research showcase next week that I encourage you all to attend, if you are interested. Happy to respond to any concerns or questions you might have on this! -- NKohli (WMF) (talk) 22:26, 19 June 2019 (UTC)
 * I want to give an update and check in with you. Over the month July, partial blocks was deployed to Finnish and German Wikipedia, and all language Wikisource, Wikivoyage, and Wiktioary. After the end of this month we have more data about usage from this group. Technical limitations do not let up pull data for ip addresses blocked. This unfortunate because my spot checking shows ip blocks to be a pretty common use. I'm happy to answer any questions. SPoore (WMF), Strategist, Community health initiative (talk) 01:09, 31 July 2019 (UTC)
 * Thanks for checking in, and I apologize for the lengthy delay and inattention this has gotten. I'm thinking we should be ready to start the discussion about this soon, perhaps this weekend. The main thing I would like to prepare is a list of potential use cases (see Requests for comment/Partial blocks for a preliminary list I've started) that the community could discuss and contribute to. To that end, I'm mainly interested in what kinds of disruptive activity other wikis have utilized partial blocks for, if you have any data on that. For example, edit warring or vandalism. Thanks! Mz7 (talk) 22:05, 1 August 2019 (UTC)
 * , thanks for getting back to me. I'm glad to help move this forward at a pace that works here. There are a few thing that we can do to get users good information to make a decision. 1) add any other use cases (I think I can add one or two) 2) spell out better how editing restrictions would work with partial block with current features and share the list of possible enhancements. 3) invite some admins from other wikis to share their uses. I can do that today. SPoore (WMF), Strategist, Community health initiative (talk) 22:45, 1 August 2019 (UTC)
 * Lessons learned and other feedback from the deployment on other language Wikipedias would be very helpful to provide additional context for the RfC. It might be desirable to wait for more usage on the German Wikipedia before any RfC goes forward. isaacl (talk) 04:49, 2 August 2019 (UTC)
 * That's fair. I think there's no rush, so I am also open to waiting a bit longer. Mz7 (talk) 10:54, 2 August 2019 (UTC)


 * I've reworked the RfC to be a yes-or-no question: Requests for comment/Partial blocks. I'm thinking we can decide the "what restrictions" bit a follow-up RfC. Wikipedians seem to like to keep policy discussions sweet and simple. Mz7 (talk) 22:11, 1 August 2019 (UTC)
 * I'm very keen to replace our current way of handling edit warring with user level page protection, though I'm keen to call this page protection rather than blocking. I would like us to move to a situation where edit warring usually resulted in the relevant page(s) being protected against the edit warrers with blocks only used where the edit warrers took their dispute elsewhere or there was another reason for escalation. It has long seemed odd to me that we go through four levels of warnings before blocking vandals but we block edit warrers on the first offence, especially as edit warrers are almost invariably goodfaith editors and members of the community whereas vandals who reform are and always have been rare.  Ϣere Spiel  Chequers  10:24, 27 August 2019 (UTC)

Six millionth article
As of now, there are currently 5,921,141 articles on Wikipedia.

Questions:
 * What will the 6,000,000th article look like?
 * Will we reach this milestone in late 2019 or early 2020?
 * Will the 6,000,000th article reach FA or GA status, or appear at DYK?

We are getting closer to reaching six million articles. GeoffreyT2000 (talk) 15:07, 1 September 2019 (UTC)
 * Close, but this time I'm no longer expected to have predicted when. Six-million_pool is the place to look for your second question. Specifically on Wikipedia_talk:Six-million_pool the odds are strong that user:Mercurywoodrose has the closest guess, though not until early 2020  Ϣere  Spiel  Chequers  20:21, 1 September 2019 (UTC)

Bots that update targets of wikilinks to moved articles?
In the sports world there are sometimes clubs that get dissolved due to bankruptcy, only to be re-formed under the same name. In this case there should be two separate articles, one for each club. I prefer that the article of the dissolved club be moved to another title (e.g. Club Name (activeyears)) and the article of the newly-formed club be placed under the original title. To avoid breaking links, all existing links to the original title must be changed to point to the disambiguation title. Are there any bots that can help out with this? I'm particularly concerned with IK Pantern. 37KZ (talk) 14:16, 3 September 2019 (UTC)
 * This is a WP:CONTEXTBOT and would be rejected at WP:BRFA. I am also unsure that your preferred method of dealing with change of name is the correct direction in the general case, but that's a problem for WP:Requested moves and WP:AT. --Izno (talk) 14:17, 3 September 2019 (UTC)
 * Is it WP:CONTEXTBOT to modify link targets to bypass redirects? One way of going about this is to move the current article to the new title and then wait for a bot to update the target of all existing links to that article to bypass redirect before putting the new club in the original article name. 37KZ (talk) 14:29, 3 September 2019 (UTC)
 * I believe this would entail WP:COSMETICBOT which is controversial as well. So from my understanding bots cannot help out in my case. 37KZ (talk) 14:33, 3 September 2019 (UTC)
 * For what you want to do I think you might want to look into WP:AWB, or you can just post a request (not sure where, probably WP:VPT) to have someone do it for you on a case-by-case basis. Ivanvector (Talk/Edits) 15:22, 4 September 2019 (UTC)

Idea: Before saving changes, Wikipedia software checks for basic fixes.
I sometimes run AWB and some basic errors I wind up fixing seem pretty minor and it seems that the Wikipedia software could check for these issues before saving the page. For example, smart quotes vs. straight quotes. If we prefer straight quotes ' and " vs “ and ” (etc.) then why can't the software check for that before we save the page? This, plus thousands of other basic changes, like miscapitalised proper nouns, links to disambiguation pages, whatever makes sense. Seems like we could save a lot of contributor time. Maybe there is a simple module built into the default editing system that corrects superficial stuff like common typos or miscapitalisations, with a slightly beefier opt-in AWB back-end extension for power users? Cyphoidbomb (talk) 15:46, 3 September 2019 (UTC)
 * The main issue here is that: If the software should automatically replace A with B, what about the time when it's actually B that we want?. These sort of small things need human to judge what's appropriate in each context. – Ammarpad (talk) 06:47, 4 September 2019 (UTC)
 * Easily addressed by having the software ask for clarification in ambiguous circumstances before saving. Also, we can use not a typo when we don't want a typo fixed, and when/if we need to use curly quotes for whatever reason, we can use/create templates similar to ' to make clear our intention. There are already bots that do this sort of thing without human oversight, and AWB has a lot of the built-in, uncontroversial fixes already. One potential hiccup, is that if Editor A makes a change and I'm in the edit history scrutinising their change, I'd probably like to know which aspects were changed automatically by the software. Cyphoidbomb (talk) 15:15, 4 September 2019 (UTC)
 * User:Cyphoidbomb I love this idea. Proposed something similar here
 * Initial draft by User:TheSandDoctor Still needs some more work though.
 * Would want to build it modular in nature so that different people / communities can have different modules. Doc James  (talk · contribs · email) 12:02, 7 September 2019 (UTC)
 * This seems like something that would never make it into MediaWiki itself. Every replacement of the sort suggested here would be additional complexity in the software, meaning additional opportunity for unexpected edge cases and bugs. Of the suggested replacements, I note that straight versus curly quotes could be decided in the opposite direction by a different wiki; proper nouns, as well as common typos and miscapitalizations, can be incredibly context-sensitive; and links to disambiguation pages cannot be automatically fixed and so would have to prevent the save entirely for the normal wikitext editor (VE could launch a wizard of some sort to fix it up, for people using VE). Bots or AWB users fixing these things up has the advantage in making it clear in the edit history what someone actually wrote and what (semi-)automated changes were applied.
 * But if people want to make opt-in gadgets or user scripts to do things for them, feel free. Anomie⚔ 12:31, 7 September 2019 (UTC)

Better citation needed system
I encounter many pages that include at least one tag. The problem is, these tags often remain on an article for a long time, in some case years, before someone replaces the tag with a citation, if that even happens at all. Not only that, but the longer the unreferenced information stays in an article, the more likely a proposed citation is actually an example of WP:CITOGEN. I propose a new system that will solve this problem and insure that all articles conform to WP:V.


 * 1) First, we deprecate all forms of the citation needed tag other than the tag. This way, the software will know which specific information needs to be referenced.
 * 2) Then, we create a special page that lists all articles that have this tag. This will give users the opportunity to add citations before step 3 occurs.
 * 3) After one week (or some other period if time), a bot removes the information highlighted by the CNS tag.

This new system will ensure the prompt removal of unreferenced materiel, but will still allow users the opportunity to add references before the information is removed. What do you think? --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  16:45, 28 August 2019 (UTC)
 * This is a truly terrible idea, which will leave gaping gaps in many articles. These days, we have far too few editors who actually write text for this to work. A high proportion of tagged information is completely correct, but so many tags have been added in the past that people can't be bothered digging out refs. Surely we already have lots of categories like: Category:All articles needing additional references (373,006) of these, plus subcats?  There are still 59 in Category:Articles needing additional references from June 2006.  Johnbod (talk) 17:11, 28 August 2019 (UTC)
 * I believe it is unfair to compare the current use of the citation needed tag with effects from its proposed use. Obviously, if implemented, users would use it more sparingly. Additionally, I am not proposing that we replace all the citation needed tags already in articles. I just want to stop using it in the future for the very reason that you mentioned. There are 373,006 articles that need more references. Obviously tags aren't working. If we want to continue to insure articles conform to WP:V we need to start removing unreferenced material instead of just adding a "citation needed" and forgetting about it. This system removes the unreferenced info while still giving users the time to add citations. There would only be "gaping gaps" in articles if the new tag was used like the old one, with articles being saturated with citation needed tags. I simply don't believe we should ignore adding reliable sources simply because editors assume "A high proportion of tagged information is completely correct...". --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  17:58, 28 August 2019 (UTC)
 * This is using a hammer to squash a fly and would cause more harm than good, IMO. Any deletion of text from an article for being uncited is far better handled by a human than a robot.--Sturmvogel 66 (talk) 22:27, 28 August 2019 (UTC)
 * It’s worth pointing out that the bot would only delete information that has been tagged by a human. So, this isn’t really changing anything. As is, unreferenced material should be removed, it just isn’t because people don’t bother, which is a problem considering that WP:V is one the most important policies on Wikipedia. No policies are changing, I just want to create a new version of “citation needed” that actually works. --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  01:31, 29 August 2019 (UTC)
 * I agree. Unfortunately, it's not being handled by humans, as Johnbod himself said. As a result, Wikipedia is riddled with potentially inaccurate "information" and the validity of accurate information is undermined. --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  23:01, 28 August 2019 (UTC)
 * And I'm OK with that as I think that the cure is worse than the problem.--Sturmvogel 66 (talk) 23:54, 28 August 2019 (UTC)
 * I've seen a fair number of erroneous cn tags left by editors who don't understand consolidating cites at the end of a paragraph or otherwise don't understand that the material already has a cite. So, again, no robot should be deleting text.--Sturmvogel 66 (talk) 01:41, 29 August 2019 (UTC)
 * If we avoided things because a new editor could make a mistake, we wouldn’t do anything. There are far worse things that new editors can do. Besides, if it does get out of hand, we can just prevent new editors from adding that template, the same way we stop them from indexing their userpage. --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  02:13, 29 August 2019 (UTC)


 * Overly aggressive solution. One really common issue is cn tags being placed when there are perfectly good general sources, as well as the issue that Sturmvogel noted. It also isn't a mistake that just new editors make. Also you want to deprecate all other cn tags, so that would make those editors you did prohibit completely unable to indicate missing citations. You'd need to demonstrate that major numbers of editors would sweep the board with these instances on them in order to either resolve, or even check the cn tags were placed legitimately, for this to not be an heavy overreaction. I don't think that's possible, so I'd be a firm oppose. Nosebagbear (talk) 10:09, 29 August 2019 (UTC)


 * The proposal is a bad solution to a serious problem. Another idea would be to make it technically easier to add citations. It is much easier to add text or even intra-wiki links than citations, and this may contribute to the lack of citations. As an editor of scientific articles in an underdeveloped area, I often find it a better use of my time to add text than citations, hoping that someone else will clean up later. But that calculus could change if I could add a citation to a given arXiv preprint in a few clicks. Ideally, give an URL and have a bot detect which type of source it is (arXiv, DOI, journal, Google Book, etc) and generate the citation. In other words, consolidate and complete the existing tools into a single, easy to use tool. Furthermore, it could be made easier to reuse an existing citation (even from a different WP article). And citations could be made less intrusive in the text editor. Sylvain Ribault (talk) 19:54, 29 August 2019 (UTC)
 * There is a Citation Bot that will allow you to use DOI numbers and will then expand out the citation correctly. — Will (talk) 15:47, 18 September 2019 (UTC)
 * DOIs are not enough. Arxiv preprints don't have DOIs. Even when the preprint is eventually published in a journal, I would rather send readers to arXiv than to a paywall. (The journal version might officially be considered the reliable version of record or whatever, but in practice scholars often use the arXiv version.) Sylvain Ribault (talk) 07:19, 20 September 2019 (UTC)
 * I would wholeheartedly support that proposal. Perhaps incorporate it into Twinkle? --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  13:56, 30 August 2019 (UTC)
 * I was hoping for tools that could be used by any editor, even editors who are unregistered or not very technically adept, and without installing anything. Thanks for mentioning Twinkle, which I did not know about, but this seems to be for relatively advanced editors. Sylvain Ribault (talk) 19:48, 30 August 2019 (UTC)


 * The Soviets built a Dead Hand system that is still operational. If the system ceases to receive regular check-ins from its human minders it automatically launches a massive nuclear strike and no one can stop it. -- Green  C  21:08, 29 August 2019 (UTC)
 * If that's meant to be a metaphor for my proposal, it doesn't work. I want to reiterate that the bots would only remove text that was higlighted by a real human. --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  21:40, 29 August 2019 (UTC)
 * A Dead Hand is targeted (configured) by real humans. Without human intervention after a set period of time it takes over and "deletes" automatically. -- Green  C  22:18, 29 August 2019 (UTC)
 * Which is exactly what my proposal does not do. --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  01:04, 30 August 2019 (UTC)
 * OK I misunderstood then. I thought one targets text with the CNS template and if nothing is done after a set period of time (1 week) it is deleted. -- Green  C  01:13, 30 August 2019 (UTC)


 * I would say that it would be nice to have a button at the top of the wikisource box that allowed us to use the ref auto-calculate feature that's in VE. Nosebagbear (talk) 21:32, 30 August 2019 (UTC)
 * I wouldn’t oppose that solution, but I doubt it will solve the problem. As is, it’s easy enough to create citations using the tools in the toolbar. --<u style="color:#0000ff"> Puzzledvegetable <sup style="font-family:Century Gothic">Is it teatime already?  01:07, 1 September 2019 (UTC)
 * Puzzledvegetable, if you are interested in improving Wikipedia by adding inline citations, then you might want to see WikiProject Reliability. WhatamIdoing (talk) 20:45, 13 September 2019 (UTC)

Non-commercial images
This came up on Commons recently. Didn't go anywhere, but that's Commons and this ain't. Maybe it's come up here and I haven't found it. Seems that surely it has been discussed before. But why exactly is it that we allow local fair use images, but we don't allow local non-commercial images? I mean, if we're trying to divine "degrees of free", non-commercial images must surely be "more free" than fair use. I can understand why a project that didn't allow local fair use, also wouldn't allow non-commercial, but I'm not sure it's obvious why the English Wikipedia doesn't.  G M G  <sup style="color:#000;font-family:Impact">talk  20:08, 30 August 2019 (UTC)
 * We (en.wiki) can use non-commercial, but that is required to be treated as non-free, as all free images must meet the definition given by WMF which is here: and any license not meeting that (including non-commercial reuse) must be treated as non-free. --M asem  (t) 20:11, 30 August 2019 (UTC)
 * Well, yeah, but how we treat "non-free" is (as far as I understand it) a local decision wrt m:Resolution:Licensing policy. Couldn't we just amend our EDP to accommodate non-com?  G M G  <sup style="color:#000;font-family:Impact">talk  20:20, 30 August 2019 (UTC)
 * To be more clear, I don't know that there is a hard barrier (as far as I understand it) to us creating a WP:NCCC (non-commercial content criteria) to compliment WP:NFCC, in cases where no completely free alternative exists, and yet a free non-commercial alternative does.  G M G  <sup style="color:#000;font-family:Impact">talk  21:33, 30 August 2019 (UTC)
 * There would be no point, as per wmf:Resolution:Licensing policy I don't think we could change it to allow us to do anything with "non-commercial" images that we can't already do by treating them the same as any other non-free image. They'd still have to be labeled as being allowed by the EDP (#2), they still couldn't be used where a free version can reasonably be expected to be uploaded (#3), and only for limited purposes (also #3), would still have to have a rationale (#4), and so on. About all we might do would be to try to prefer "non-commercial" to other types of non-free files. For which, why bother?
 * Besides which, I very much doubt any such change would get consensus. Anomie⚔ 21:35, 30 August 2019 (UTC)
 * To be fair, the issue was raised because the Foundation's own working group were the ones who suggested a change. We could still look to drop 2, 3 and 9 (and possibly 8 in favor of 5) from NFCC.  G M G  <sup style="color:#000;font-family:Impact">talk  21:44, 30 August 2019 (UTC)
 * Someone who is freely licensing their work for non-commercial reuse only has explicitly reserved their right for commercial exploitation. I don't think English Wikipedia should treat this intent as being less restrictive with respect to safeguarding the copyright's holder ability to benefit from the work. isaacl (talk) 21:52, 30 August 2019 (UTC)
 * As long as the Foundation has a binary distinction of free v non-free, we really can't change that (they want all content to be redistributable and modifyable by any end user to be able to call it free) But we can say in guideline that we would definitely more prefer a CC-BY-NC over a straight up standard copyright, if there was a choice between two images. And if a CC-BY-NC was up at FFD and on the border of whether it was appropriate, if it has a good strictly educational factor, I'd probably have it kept.
 * I will note we do talk about "freer" images when it comes to images that may carry multiple copyright, such as photographs of 3D artwork. (The artist's and the creator's), but this ends up as a non-free image.  --M asem  (t) 22:20, 30 August 2019 (UTC)
 * I think a generic statement to favour works that are licensed for non-commercial reuse could be somewhat perverse, in some cases. We'd be rewarding a copyright holder who is making their content available for pure non-commercial use by violating their copyright. I'm sure there are many situations where the copyright holder won't mind, but I'm wary of making it a general guideline. isaacl (talk) 22:38, 30 August 2019 (UTC)
 * For all purposes, WP is a non-commercial use and WMF non-profit, so we cared little on redistribution, we could be using -NC content left and right. The problem is that the -NC restricts redistribution and reuse to a portion of users (commercial), so because the Foundation wants freely redistributable materail, we tag -NC as non-free. But the thing to keep in mind is that our disclaimers do warn reusers that they are responsible for reviewing any File: content they wish to include. So for educational redistributors, NC is great and helps, but still poses the same problems to commercial users. --M asem (t) 20:08, 31 August 2019 (UTC)
 * We'd be rewarding a copyright holder who is making their content available for pure non-commercial use by violating their copyright. I'm not sure I follow the meaning here.  G M G  <sup style="color:#000;font-family:Impact">talk  14:44, 4 September 2019 (UTC)
 * Say someone takes a photo of an event, who wishes to sell it or license it to businesses. The copyright holder wishes to contribute to the non-commercial community and has graciously allowed it to use its photo for non-commercial use only. Your proposal suggests that in return, English Wikipedia should not respect the commercial opportunities for the photo (NFC criterion #2) and not limit the resolution of the photo (NFC criterion #3). In the name of fair use, the English Wikipedia community will have chosen to violate the non-commercial use license, and given an onus to the copyright holder to pursue any commercial re-users of Wikipedia who have infringed copyright, without making the accommodations that are given to protect the commercial value of works that offer no non-commercial license at all. I do suspect that some copyright holders won't mind the tradeoff in exchange for the greater visibility their work will receive, but I'm wary of making this a blanket guideline. isaacl (talk) 17:48, 4 September 2019 (UTC)
 * We at WP would not have violated the NC license. We would have made it more visible for others to use in a way that would violate the license, but there's a distinction. Every time we use a fair use image, we are making it visible for violators. Since most use of WP is probably noncommercial, the current policy could be seen as interfering with the possibility for legitimate use.   The onus in pursuing copyright is always with the owner, and in choosing to se a NC license in the first place, the owner will know perfectly well that there might be commercial uses that they may want to pursue. No major commercial publication would use a NC image--they watch out for liability.  Our responsibility is to  post a clear warning that the image is not under a free license. We would not be favoring works with a NC license. We would continue to favor works with a free license. We would only favor works with a NC license over those that were not licensed for reuse at all but which we ae using under the US fair use provisions.   I think it would be appropriate for us to do so. Every step towards free licensing is good.  We've been saying we can not liberalize our policy because the foundation would not let us, which has indeed been an absolutely valid argument. The question now is what would we best want to do if they did let us. I think this neeeds a general discussion. If it is rejected, and I think it is probable that it would be, it should be rejected with full awareness of the possibility DGG ( talk ) 14:53, 16 September 2019 (UTC)
 * Although I remain wary of making images more visible for unlicensed use, I agree upon further review of Wikipedia's licensing terms that only Wikipedia's text is covered. Since Wikipedia is not providing a licence for incorporated media, it does not violate the licence of works that are licensed only for non-commercial use. I still think that it would be more encouraging to rights holders to continue to respect the commercial value of their works. isaacl (talk) 18:03, 16 September 2019 (UTC)
 * There's also the slight possibility people who would otherwise take photos and license them under the CC license would release them under a non-commercial license instead. I know if I had the option to upload a photo under non-commercial or CC, I would pick the one more favourable to my rights unless I'm intentionally trying to help the project. SportingFlyer  T · C  05:43, 20 September 2019 (UTC)
 * Which Creative Commons licence are you thinking of? I imagine a lot of people licensing their works for non-commercial reuse are using Creative Commons Attribution-NonCommercial-ShareAlike. isaacl (talk) 05:58, 20 September 2019 (UTC)


 * In Foundationspeak, "free knowledge" means limiting knowledge so people can sell the knowledge at a profit. – Leviv<span style="display:inline-block;position:relative;transform:rotate(45deg);bottom:-.57em;">ich 04:50, 20 September 2019 (UTC)