Wikipedia:Village pump (proposals)/Archive 169

I propose that we add 'Fourth opinion' as a method of

It would make more sense to refactor or remove the If ... only two editors are involved precondition, or apply

WP:IAR if you think another opinion is necessary. --Izno (talk

) 13:31, 19 June 2020 (UTC)

I think the proposal is missing the entire point of WP:3O. Asking for a “third” opinion has nothing to do with the number of participants, it’s about seeking outside opinions (from those not already involved in the discussion). It is simply a less formal version of RFC. Blueboar (talk) 13:47, 19 June 2020 (UTC)

I'm inclined to agree. If three editors can't reach a consensus amongst themselves, then it may be time for

WP:DRN or an RFC. Otherwise we could just add 4O, 5O, 6O... DonIago (talk

) 14:10, 19 June 2020 (UTC)

While I agree that the intent is to seek outside opinions, the instructions make it clear that the process is to be used for when only two editors are involved, and the person providing the third opinion is instructed to remove the listing before weighing in to keep other volunteers from duplicating your effort. Perhaps a change allowing for more third-party opinions (as opposed to third opinions) might be useful. isaacl (talk) 16:40, 19 June 2020 (UTC)

Which is what I said. :) --Izno (talk) 16:59, 19 June 2020 (UTC)

Just a note that this is also being discussed on the 3O talk page with a slightly different twist, namely whether the existing 3O allows some use in multiparty disputes. (The answer is, practically, that it does in theory, but not in practice: volunteers enforce the two-party requirement pretty strictly almost all of the time.) Before seeing this here, I raised the idea there as well of possibly transforming 3O into a NthO (or, in the alternative, removing even the "possible in theory"). But having proposed it, I have some reservations about the NthO idea as well. Having worked at 3O for years now, I think that it's the most effective form of DR at WP and I'm loath to tinker with success, plus expanding it to an NthO project probably requires some procedural rebuilding about how opinions "work" as well. (And just to continue to flog a horse that's not just dead but one that's rotted to a skeleton, what we really need to deal with multiparty disputes is some form of binding content arbitration carefully crafted to allow community input and not go against the wiki principle, perhaps something like this.) Best regards, TransporterMan (TALK) 17:20, 19 June 2020 (UTC)

Yes, more specifically, I'm not suggesting there be a change to the guidance on the number of original disputants, but on the number of people who can offer a third-party opinion. This would need a procedural change in how the queue is managed. isaacl (talk) 17:47, 19 June 2020 (UTC)

Izno, I see what you’re saying, but isn’t it the general consensus that IAR should only be used occasionally and when necessary? If IAR is being used a lot for something, I believe we would usually just make it into an actual process. And we could remove the two editors requirement, but note that would necessitate some kind of name change since it’s called a third opinion and I wouldn’t want to confuse anyone.

third opinion page

it states that the process can only be used if there are two editors involved.

DonIago, yes I agree with that. As I stated, I believe that a 5O or 6O would be pointless, but 4O seems to me like the maximum degree of an extra participant that’s reasonable.

isaacl and TransporterMan, I think general concept of changing from “third” opinion to “third party” opinion is a good idea. However, this could easily cause confusion, so we would need to make some changes to certain project pages to clarify. MrSwagger21 (talk) 18:08, 19 June 2020 (UTC)

There's another possibility: Reopen

I think encouraging more third-party opinions is a good first step beyond soliciting just one third-party opinion. Regarding the mediation cabal, though: I liked how it provided informal mediation, and given that it was all voluntary, not much more was needed than a list of willing mediators. But... success of voluntary mediation depends on the co-operation of its participants, and their willingness to work towards a solution. I think mediation in general is most helpful in keeping participant replies focused on specific questions, to enable issues to be worked through methodically. Sadly, in too many disagreements I have seen, the disputants were not willing to be constrained in this way, preferring to jump to any line of reasoning at any time. I don't really know how to encourage a more patient culture where editors would work harder at finding common ground. As I said in the discussion that closed the mediation committee, sustained participation is a problem in many discussions, which is understandable given the time pressures people have but leads to impatience and a desire to make your points now, rather than waiting until later. isaacl (talk) 19:19, 19 June 2020 (UTC)

Thank you both for the insight. However, I think we should try not to get too off topic here. I would like to know what the general community consensus is on a ‘fourth opinion’ process, and its possible pros and cons. I think the Mediation Cabal was a little too narrow in terms of who could respond; responding to disputes should be open to any willing editor, not just volunteers who have expressly stated they would be willing to be on the list of users who respond to mediation disputes. This is how Third Opinion works (although there is a page called “Wikipedians willing to provide third opinions” and a userbox associated with such). Of course, I welcome you to begin another discussion concerning reviving the Mediation Cabal. MrSwagger21 (talk) 19:54, 19 June 2020 (UTC)

I do think that having more third-party opinions can help the original two disputants gain a broader perspective on the strengths and weaknesses of their arguments. I don't see a reason to arbitrarily limit it to two third-party opinions. isaacl (talk) 20:02, 19 June 2020 (UTC)

The problem with multiple opinions is that it just adds more disputants to the dispute. If the second opinion giver disagrees with the first opinion giver, then there are just more parties in dispute. And if we say another opinion can be given only if it agrees with the first one, then what good is that? There's already a mechanism to get multiple opinions on a dispute: RFC, with the benefit that all those additional opinions can actually form consensus. Moreover, allowing multiple opinions encourages opinion-shopping. Don't like the first opinion you get from 3O? Just ask for another one. One of the benefits of 3O is that it's once and done. Once you get a 3O, you don't get any more, but that's okay because it's just an opinion and you're not under any obligation to accept it since 3O's are not tiebreakers and thus don't "count" towards consensus. If you're not happy with it, you can move on to DRN or a RFC. Best regards, TransporterMan (TALK) 20:20, 19 June 2020 (UTC)

I don’t see having multiple disputants as a problem. As long as they are following

consensus. I don’t think opinion-shopping would be a problem. 4O would also be one-and-done. It would also be allowed to be used without first using 3O, like if there were originally three disputants. If there is still disagreement after 4O, then yes, move on to a request for comment. The key point of the “RfC” part of the proposal is that 4O is an informal method of dispute resolution, while RfC is a formal method of dispute resolution. It is preferable to get one extra opinion instead of requesting input from a wide community, unless necessary. RfCs are usually several days and can attract any number of editors. 4O would be designed to reduce the need for that. Consensus can be established by informal discussion, not just RfCs or other types of formal discussion. Pretty much any editor’s opinion “counts” towards consensus (this doesn’t mean votes though). Any opinions given would need to be objective and independent, and they would need to come from an uninvolved editor. It is important to note that this proposal would have almost exactly the same rules and ideology as 3O. The difference, of course, is there is one more editor already involved. MrSwagger21 (talk

) 21:17, 19 June 2020 (UTC)

I'm assuming that a discussion was already opened on a relevant talk page, and there are still only two persons involved, thus in theory the dispute is somewhat obscure and it is more likely that outside third parties won't be as vested in the outcome (of course it is not certain, but I also hope those who watch the third person opinion queue are more inclined to offer dispassionate discussion). Disputes between two persons can only get resolved without a larger discussion to establish consensus if the initial participants are convinced to yield ground, and I think there's a better chance with a few more voices. If they all disagree, then it's a good sign that a larger discussion such as an RfC is needed.

That being said, I also appreciate that many two-persons disputes are heading for an RfC, anyway, and so delaying beyond a single third-party opinion may not be helpful. isaacl (talk) 22:30, 19 June 2020 (UTC)

Actually, a very good example of how 4O would be useful is this very discussion right here. Me, you, and TransporterMan don't seem to completely agree on a proposal. We can't use

WP:NO DEADLINE. In any case, thank you for your perspective, I appreciate it. MrSwagger21 (talk

) 03:01, 20 June 2020 (UTC)

We can solicit additional opinions from relevant WikiProjects. Your initial proposal, as I understood it, was to solicit an outside fourth opinion after an outside third opinion had been given for a dispute between two parties. I don't agree that a fourth opinion program should apply to this case and to the case where there are three disputants at the start. Extending the third opinion initiative is, in my view, a more flexible way to cover more scenarios, and the simplest to implement.

This isn't a very contentious discussion, so it's not a great use case for the third opinion procedure. The issue is not one of a deadline, but patience. People run out of it, particularly if they think some steps are extraneous. isaacl (talk) 03:38, 20 June 2020 (UTC)

Ironically, I think it might be time for an RfC on this proposal. Of course, the theoretical 4O wouldn’t be able to be used for this discussion anyway since there are more than three total editors who are involved or have gotten involved. (My explanation above assumed there were three.) I would really like to get extra feedback and help establish consensus. This topic is important as it concerns dispute resolution, which is key to the smooth collaboration of editors on the project. If no one objects, I’ll add an RfC tag to this conversation shortly. MrSwagger21 (talk) 18:44, 20 June 2020 (UTC)

I suggest taking the discussion to Wikipedia talk:Third opinion. As a voluntary mechanism to gather more opinions, there doesn't really need to be a community-wide consensus to alter/extend the procedures for soliciting third-party opinions. All you need are interested persons and a way to draw them into conversation. isaacl (talk) 19:01, 20 June 2020 (UTC)

I would probably do that, but I’m a little afraid of the discussion dying out there. How about I ask for input from a WikiProject and then if that doesn’t work, I’ll use RfC? I could also be

I suggest that you take the already expressed opinions into account when making a proposal, including thinking about how to integrate your proposal into the third opinion process. The important part is finding people interested in participating, and the most likely pool of participants are those who participate in third opinion. Nearly all proposed initiatives fail due to a lack of sustained interest; you need to find people who want to engage in a voluntary process. Other than canvassing concerns, there aren't a lot of ways for the community to prevent editors from commenting on any discussion they are interested in, so seeking consensus approval to do something people can already do is a diversion from finding people who will actually participate in the procedure.

(On a side note, I disagree in limiting your proposal to cases where there are three persons in disagreement; I think it makes much more sense to treat this as a follow on to the third opinion process, where the third opinion is more of an outside view than a dissenting view. For example, instead of deleting third opinion requests, responders could move them to a responded page that would auto-archive after say a week. Interested persons could follow up on any discussions on the responded page.) isaacl (talk) 16:43, 21 June 2020 (UTC)

I have some question about whether that is an appropriate use of the draft namespace. See this inquiry. Best regards, TransporterMan (TALK) 21:48, 21 June 2020 (UTC)

isaacl, I understand your concerns. The draft is a public page that anyone can work on. If you feel like something should be changed on it, please go ahead and comment on it and/or make the edits you would like to see. I don’t own the draft or the proposal, and I would actually prefer for the community to work on it as a whole. I welcome input and improvements; I am not worried about keeping it 'my way’. It is my prediction that any one of the approximately 300 editors who have stated they would be willing to provide a third opinion or any editor interested in 3O would have no problem providing fourth opinions; the interest would carry over. And regarding your side note, I just want to be absolutely clear about 4O. The proposed DR process, as it stands right now, can be used in any of the following situations:

• There are three original disputants who have not used 3O to get the opinion of a third editor.
• There are two original disputants who have used 3O to get the opinion of a third editor, and any of the disputants want one more opinion before either resolving the situation or moving on to other means of DR, like RfC.
• There are three original main disputants, with a fourth having limited participation, who have not used 3O. Even though there already is a fourth editor, an exception is made.

Also, please note that in the same way as a third opinion, a fourth opinion would have to be neutral, and would not have to be “dissenting”.

Lastly, if you want to change any aspect of the proposal draft, including the title, or the possible situations I have listed above, you may also go ahead and do so. None of this is set in stone. Happy editing! MrSwagger21 (talk) 05:00, 22 June 2020 (UTC)

I prefer trying to gain some agreement around what would be the best approach, before editing any proposal. But beyond that, it's not an initiative I'm likely to participate in, and I believe those doing the work should have a mandate to figure out their preferred mode of operation, including integrating with existing processes. So if you think that editors who are interested in the third opinion procedure are those who would participate in your proposed procedure, then you should be discussing it with them (as I suggested earlier). isaacl (talk) 08:55, 22 June 2020 (UTC)

(On a housekeeping note, typically you would either create the draft in your own userspace or in project (Wikipedia) space, possibly underneath an appropriate existing page. In this case, a subpage of the third opinion page might be appropriate.) isaacl (talk) 08:55, 22 June 2020 (UTC)

Regarding this comment on starting an RfC (from the mass messaging talk page): there are many ideas that need broad buy-in to be implemented. Your idea, fortunately, can be implemented by just doing it. You can check in on discussions where a third opinion has been given, and if you believe a fourth opinion would be helpful, offer to provide one. You can gain experience on how well it works in practice, and refine the process accordingly. With ideas that can just be tried, re-evaluated, and modified as needed, I'd as soon see them kicked off than discussed in a formal RfC. isaacl (talk) 23:56, 22 June 2020 (UTC)

@Isaacl: I see. Thanks for the recommendation. Do you think I would run into problems if I just moved the Fourth Opinion page into the project space and tried it out a little bit? I think some actual experience out in the open would be incredibly useful to refining it. It really couldn’t hurt, it’s a completely voluntary, informal, non-binding process. In addition, the draft page was recently marked as reviewed by the user CAPTAIN MEDUSA, who most likely saw it from the mass message request. MrSwagger21 (talk) 00:05, 23 June 2020 (UTC)

The key is not to implement it in a way that interferes with others or places a burden on them without their buy in. So don't start taking requests from the third opinion queue and offer an opinion without taking it off the queue, since you'd be knowingly going against their procedure. Also don't try to make fourth opinion a bigger deal than it is: be upfront of it's just you doing it, or a group of volunteers. Otherwise, good-faith, neutral third-party opinions are a strong basis for establishing consensus. You can of course recommend that a dispute be resolved by holding an RfC, if you think a fourth opinion isn't going to be able to resolve the problem.

Regarding the page status: new pages are monitored by Wikipedia:New pages patrol, who mark them as reviewed if they meet English Wikipedia's criteria for acceptable pages. Marking it as reviewed just takes it off the queue as something that doesn't warrant immediate deletion. isaacl (talk) 00:22, 23 June 2020 (UTC)

Okay, I will move it into the project space and go from there. We’ll see if anyone shows interest. I will also create a category entitled “Wikipedians willing to provide fourth opinions”. Of course, if any this doesn’t work out or becomes/remains inactive, I will either move it back into the draft space or request its deletion. MrSwagger21 (talk) 00:33, 23 June 2020 (UTC)

Keeping track of what hasn't worked is useful too, so personally I would just mark the page as inactive if the time comes when no one is offering fourth opinions. isaacl (talk) 00:42, 23 June 2020 (UTC)

Page moved into project namespace. It can now be found at Wikipedia:Fourth opinion. I have added a notice that it is still under development. MrSwagger21 (talk) 00:47, 23 June 2020 (UTC)

(edit conflict) I've sometimes tagged my "fourth opinion" onto a 3O, usually in an edit conflict situation where I'd been investigating the dispute but another 3O volunteer posted first. I don't see the point in creating a separate formal 4O process, especially as something for editors who aren't happy with the 3O that they received. However, I feel that there's some merit in the idea of modifying the existing 3O framework to allow what is suggested as a "third party opinion" (rather than a third editor opinion). Mind, 3O already has flexibility for disputes with more than 2 editors. I feel that this would be best discussed at Wikipedia talk:Third opinion, where it will get the attention of the editors who are already volunteering in this area. – Reidgreg (talk) 04:26, 23 June 2020 (UTC)

 You are invited to join the discussion at Wikipedia:Requests for comment/Mapframe maps in infoboxes. Evad37 [talk] 03:24, 24 June 2020 (UTC)

I noticed that on many pages pictures of contemporary individuals are clearly from a number of years or even decades ago. I think these pictures should be dated. — Preceding unsigned comment added by Cholt6 (talk • contribs) 14:52, 23 June 2020 (UTC)

Welcome to Wikipedia, Cholt6. Please sign your comments using 4 tildes (~~~~) - Flori4nK ^{t • c} 15:32, 23 June 2020 (UTC)

@Cholt6: I can't manage to find the policy/guideline/essay link for you (although I'm guessing it exists somewhere), but the general practice is that portrait images should be from the period where the individual was most prominent, rather than the most recent available image. For categorizing elements of the image including the year, that's done over at Wikimedia Commons. {{u|Sdkb}} ^talk 19:52, 23 June 2020 (UTC)

I read the OP's request as asking for the date of the photo to be included in the image caption, which seems reasonable to me and is sometimes done (e.g. Qaboos bin Said). I don't think it needs to be more than a good practice thing though as context may make explicit dating unnecessary in some circumstances. Thryduulf (talk) 02:37, 24 June 2020 (UTC)

I think one of the biggest reason why photos often aren't dated is that the date is not known. The date is frequently missing when the photo is uploaded at Commons. MB 04:50, 24 June 2020 (UTC)

It is a judgment call. Sometimes it is as clear as "At the 2012 Olympics" sometimes it is unnecessary as saying when a footballer took a particular penalty, especially if our best photo of them was taken at an otherwise unremarkable match. Many of our photos and photos of paintings are not just decades old but centuries old. It is relevant to say how old people were when the image is from long after their retirement, and that is a common feature of our photography - it is generally easier to take a photo of a local celebrity when they open the garden fete than to hop into a time machine and photograph them when they were at the height of their career. ϢereSpielChequers 12:21, 25 June 2020 (UTC)

Hi all, I raised this at VPT previously, but it didn't get enough of a response to really establish a consensus one way or another before it was archived, so I figured I'd pop it over here. Only three people responded over there, two of whom didn't have a !vote and one of whom !voted to support it.

There's an issue on Phab at phab:T117122 talking about WikiProjects wanting the ability to easily see which pages are in their categories, view recent changes on those pages (i.e. not the tagged talk pages, but the actual pages), and to patrol those pages using tools like Huggle. I picked up this issue, and have been working out an extension for MediaWiki which would allow this to happen.

All you'd need to do is put {{#pageCat:The category you want}} on the talk page, and it would categorise the corresponding page with Category:The category you want. This works through templates, so WikiProject headers could categorise the actual page, and not the talk page that they're on, without adding any wikitext to the page itself. As it's using the standard MediaWiki categorisation features, it also respects __HIDDENCAT__ and all the rest, so you can keep the categories out of the way with no issue.

This has implications beyond WikiProjects for all sorts of potential applications. I'll never be able to come up with all of the creative ways people could use a tool like this, but some ideas I have seen and/or had myself are:

• Sysops being able to patrol recent changes on articles with discretionary sanctions imposed upon them, by adding a category to the DS tag on the talk page
• Using tools like Huggle to patrol recent changes to vital articles, which Levivich has already expressed interest in
• Creating categories of articles that have been mentioned in the media directly, either for monitoring changes or to create a comprehensive list
• Monitoring changes to BLP articles specifically, so that changes can be swiftly reverted and revision deleted where need be
• Accessing random articles within the purview of a WikiProject, or vital articles as Sdkb suggested on the Phab ticket

The extension is still going through code review on Gerrit, and it's my first time building a MediaWiki extension, so it's a little way away yet. However, the idea's there, so I suppose the questions here are:

1. Broadly, does the community want this on enwiki? Does it seem like a good idea?
2. Is it a good idea to have some sort of visible indicator on the page that gets categorised that it is categorised from a tag on the talk page, or is this unnecessary?
3. Are there specific details of the implementation that need to be built a specific way, or any other uses for this extension that would be useful to consider?
4. Are there any other questions or concerns about it?

Feedback appreciated, as always! Naypta ☺ | ✉ talk page | 09:46, 13 June 2020 (UTC)

• I'm not keen on this idea as it adds more complexity to wikipedia and might cause a lot of edits to templates (or even to talk pages). It would be better to ensure that tools (Huggle, Petscan etc) are able to consider both the categories on a page and the categories on its talk page. DexDor ^(talk) 09:53, 13 June 2020 (UTC)

  @DexDor: Broadly, if it was technically feasible so to do, I would agree with you. There are, however, serious technical challenges with doing that - which is why I've implemented it this way, rather than any other. To try and summarise the problem - changes to pages are stored against entries in the recentchanges table in the database. That table stores the title, namespace and page ID of the change made. However, there's no easy way to verify the categorisation or lack of categorisation on demand for the talk page of something that appears in the table. This means that, in order to implement a system like the one you describe, you'd have to download the entire contents of the category you were patrolling, then subscribe to all changes being made, and subsequently consider whether or not a corresponding namespace entry with the same title had been categorised.

  The other problem with doing it that way is that doing so would require technical changes to a huge number of pieces of Wiki-adjunct software, which all at the moment understand categorisation in the same MediaWiki-standard way. The extension that I've made makes categorisation on the talk page work just like categorisation on the page itself, so nothing external needs changing, and everything stays working; making a change to individual pieces of software to do patrols like that would be a much longer process. Naypta ☺ | ✉ talk page | 10:00, 13 June 2020 (UTC)

Re "there's no easy way [for systems] to verify the categorisation ... for the talk page of something that ..." - a human would just click on the "Talk" link and see what categories the talk page is in. Is there no easy way for a computer program to do that? DexDor ^(talk) 16:47, 13 June 2020 (UTC)

@DexDor: (This turned into a slight sermon, sorry for the length!) MediaWiki isn't built for holding much metadata about pages at all, never mind other pages holding metadata about them. A human would click the talk link, because locally we've decided to put metadata on the talk page - a sensible decision that occurs on many wikis - but MediaWiki itself doesn't know anything about that.

In order to make that work for a computer monitoring recent changes, you'd need to go through some variant of the process I described above if you wanted to do it without changing the server behaviour - which is pretty much the same as a human "clicking the talk link". The trouble is, having a computer program "click the talk link" for every change made on the wiki is a very wasteful process in terms of resources, and could increase load on the servers. It's not that it's impossible to do - very few things are technically impossible - but it's not necessarily a good approach in terms of optimising resource usage and time consumption, both on the side of the client and on the server side. It effectively doubles the load of recent changes - rather than just checking one page with one database query, you now have to check two.

In contrast to that, the way that my extension works is that it adds metadata to the actual page. This means everything is kept exactly the same way that it currently works - recent changes should work with categorisation just fine, because the pages are in those categories. This could be done without putting the pages into actual categories, if that's what you're looking to prevent, but to my mind, that adds even greater complication - now suddenly there's two types of "category", a normal category and a special type of hidden category that only works for recent changes. Not using the standard category system for it also has the disadvantage that it means it can only be used for patrolling changes - for instance, another potential use of talk page categorisation that wouldn't fit with that would be for article maintenance tagging. Being able to categorise the main article through a tag on the talk page would mean that potentially some maintenance tags that just add a page to a queue could be moved to the talk page - copyright revdel, for instance. Naypta ☺ | ✉ talk page | 16:59, 13 June 2020 (UTC)

It'd certainly be useful to do things like find articles that are in Category A and have a talk page that's in Category B. However, if that relies on editors altering templates and talk pages then it could take a lot of work (both initially and long term), produce a patchy result, add significant extra complexity and cause problems - i.e. it could well be a net negative to wikipedia. It would be better imo to go for a more elegant (for users) solution - even if that means longer before it can be implemented. DexDor ^(talk) 05:15, 14 June 2020 (UTC)

@DexDor: What sort of "more elegant" solution would you be thinking of? Naypta ☺ | ✉ talk page | 08:14, 14 June 2020 (UTC)

Something like where a tool (e.g. Petscan) asks for a category name the user can preface the category name by something (e.g. "(talk)" or "(ns+1)") and the software (either in the tool or in MW) would check whether the talk page is in that category. I.e. provide an extra facility to users of the tools without causing extra work, complications, watchlist noise etc for other editors. DexDor ^(talk) 08:58, 14 June 2020 (UTC)

@DexDor: I explained the problem with doing that above - not only is it technically difficult and poorly performant, but it requires an update for every tool that would need to support it, in all sorts of different codebases, potentially with no maintainers or maintainers that haven't touched the category management code in a long time. Watchlist noise oughtn't exist with this solution, as categorisation changes on the talk page don't create a new revision on the corresponding page - the categorisation changes automatically, no extra revisions needed. So far, the only other complication that I'm aware of is the potential for confusion as to where a category is coming from - which I've been discussing below with VanIsaac. Are there any other issues you can think of? I'm eager to try and prevent any complications I can Naypta ☺ | ✉ talk page | 09:08, 14 June 2020 (UTC)

It wouldn't need an update to every tool if the "(ns+1)" (or whatever) was handled at a low level.  Without knowing the exact details of how your proposal would work (both technically and procedures) it's not possible to fully assess what negative impacts it might have (beyond knowing that it would add further complexity to wikipedia). The sort of things I'm thinking about is that these new categories appearing on article pages could well be redlinks and hence appear in a database report. Imo the onus should be on people proposing changes to go some way to assess what the impact would be on other editors. DexDor ^(talk) 15:00, 14 June 2020 (UTC)

@DexDor: I'm not sure I can see how you'd do it on the server side with no changes to clients without adding some way of putting those articles into categories - something which only supports access through categories would surely need to have its things in categories. If you could expand on that, that'd be great. With regard to redlinks, that'd work the exact same way at the moment as just adding a category to the bottom of the page - although if the feeling is that that would be a bad idea, then it could equally be configured to require pageCat-added categories to be already existent, or even that they be hidden.

Proposals are a way of soliciting input from other editors, not just !votes, so this is helpful to me to assess impact in and of itself - I want to make sure that I've had feedback from people from all parts of Wikipedia. I'm acutely aware that the impacts I assess on my editing aren't always representative of everyone else's, so I want to get that broader understanding from people with much more experience than myself - including you! I really appreciate the feedback Naypta ☺ | ✉ talk page | 15:33, 14 June 2020 (UTC)

The server (with access to the database) has the info it would need to answer the question "Is the talk page of page X in Category:Y?" so it's just a case of programming it. Sure, it would take longer for the server to answer that than to answer "Is page X in Category:Y?", but your solution would increase server load as well (presumably, every time a talk page is edited) - as well as all the extra edits its implementation would require. DexDor ^(talk) 05:24, 15 June 2020 (UTC)

@DexDor: The server has access to answer that question, yes, but the clients have to be programmed to ask it. At the moment, the clients are programmed to ask "Is X in Category:Y?", which is a different question. It's true to say that my system increases server load on edits - as does pretty much any extension to MediaWiki - but an edit is far rarer an event than someone just trying to patrol a page in a category, so it's reasonable for it to take longer (this isn't just me talking, it's an official guideline). As to extra edits, the existing categorisation system doesn't go away - this doesn't require anyone, any template or any project to use the system, it only makes it available to them. Besides that, because it works through template transclusions, the majority of the edits required to make it work for most of the implementations I've considered so far would be minor edits to templates, rather than to talk pages directly. Naypta ☺ | ✉ talk page | 08:26, 15 June 2020 (UTC)

That mediawiki page basically says that views of a page happen more often than edits to that page.  It does not say that views for any particular reason (e.g. in order for a query to check whether a page is in a category) happen more often than edits.

It's not just the edits that actually change templates to use the new facility it's all the subsequent edits to the talk pages that would have to assess whether the change affects the categorization of the article page. As you don't appear to be able/willing to look critically at what you are proposing I don't intend to engage further in this discussion. DexDor ^(talk) 19:20, 15 June 2020 (UTC)

@DexDor: You're of course entitled not to engage further, but I don't think it's fair to say that I've not been engaging with you - we've been having this discussion for a fair while I want to understand and address any issues before they arise, so it's a bit disappointing to hear that comes across as being "unwilling to look critically" at the proposal - I want to do the very opposite.

If you change your mind, I'd like to understand what you mean by "views for any particular reason", as categorisations of a page are loaded on all views. As to potential ramifications on people editing talk pages, this is (as I mentioned above) being discussed below, with several options involved - including options with notices being presented to users before they save an edit that would categorise the page, or even with text being injected into the page to make it clear that the categorisation tag is there. If you're not wanting to keep talking, that's okay, though, I respect your decision - have a good evening! Naypta ☺ | ✉ talk page | 19:58, 15 June 2020 (UTC)

• Question about this implementation: is it fully opaque in categorizing? I.e. will it show up at the bottom of the article/project page and in the category listing exactly like a category put on the article/project page? Does it still show up on the talk page in some way? Will it propogate through templates? This feels like an absolute nightmare when it comes to tracking down errors unless it gets categorized in a pretty fundamentally different way than categories currently are. It can already be an incredibly frustrating experience tracking categories through template transclusions. I'm just imagining an editor doing something on a talk page and not realizing they are effecting the main page by accident. Will it even show up on a show preview if the effect happens to another page? VanIsaac_WS^cont 18:28, 13 June 2020 (UTC)

  @Vanisaac: These are absolutely valid concerns, which I have thought about in the implementation process. At the moment, the process is fully opaque, just as you describe - it would be the responsibility of the talk page tagger or template on the talk page to note that the code added was categorising the page. That's sort of what I was asking in the second point above - whether people considered a visual indicator to be a good idea. This indicator could be either on the page itself, or on the talk page for the page - a bar could appear potentially along the bottom, saying what the talk categories were. Alternatively, I could add a line to mw:Page information showing which of the categories are added by talk page categorisation - or equally add a special page that allows you to enter the name of an article or talk page, and find out which pages are categorised in accordance with it. I'm open to any of these, any combination of these, or any alternative suggestion that people have - I'd love to hear what you and others think is best! Naypta ☺ | ✉ talk page | 20:00, 13 June 2020 (UTC)

My first thought is that at minimum, I would want an indication on the main page that the category was added through the talk page, and quiet frankly it might be advantageous on the category page as well - it could be as simple as an asterisk in both places. Also, if a category could be added to the main page through a template call on the talk page, then it would be critical that it show up on "show preview" in some way, and it would of course be best if there were a separate "Main page categories added through talk:" list on the talk page. Now, assuming that this gets implemented well, I would think the opposite {{#talkcat: category}} function would be useful as well: categorizing talk pages by main page content (especially through main page template and module transclusions) could be quite helpful for a lot of notifications and other maintenance. VanIsaac_WS^cont 21:36, 13 June 2020 (UTC)

@Vanisaac: Could you give an example of where a "talkcat" function would be useful in that way? I'm struggling to think of one myself, but of course, I'm not all Wikipedians! Naypta ☺ | ✉ talk page | 21:38, 13 June 2020 (UTC)

I do a lot of work in the Template namespace, so the use case that popped in my head was that {{#talkcat:}} would be really helpful for putting

WP:TFD notifications in the talk pages of important pages transcluding a template being discussed. Thinking about it, this would also be a nice way of giving important maintenance categories a bit of visibility without breaking the "main pages are for content" rule as well. But in the end, it's what all the other insanely creative editors would figure out to do with this that would most excite me. VanIsaac_WS^cont

23:59, 13 June 2020 (UTC)

@Vanisaac: Hrm - I see what you mean with TFD notifications, but then it's not going to add a notice, only a category. It strikes me that possibly the better way to do that would be to deal with it like copyvio revdels - where a separate template is added to talk - and then having Twinkle add both templates automatically. The thing about maintenance categories is absolutely valid, and is part of the potential uses for pageCat :) Naypta ☺ | ✉ talk page | 08:30, 14 June 2020 (UTC)

And that probably works great for 95% of the usecases, but it is fundamentally multiple steps, needing access to a specialty tool, and it is undeniably automatic. While the scenario that I'm thinking about is where you'd want the discretion and judgement of a manual process. VanIsaac_WS^cont 16:41, 14 June 2020 (UTC)

• I think some better support for the actual problem (members of a project wanting to monitor certain articles) is needed. In relation to a very bad case of promotional editing, I made a couple of large lists of articles to allow monitoring of recent edits to those articles via Special:RecentChangesLinked. See this example. I don't like the idea of magic on a talk page injecting a category into another page. Wikitext provides enough puzzles and I would not like to have to remember to check a talk page while wondering how a particular hidden category appeared on an article page. Regarding creative use of the proposed technique, while articles are often semi-protected, their talk pages are not. A troll could use this to put red-linked categories on an article with fun text like "Rapist and child abuser". Johnuniq (talk) 01:18, 14 June 2020 (UTC)

  @Johnuniq: The point about protection is a good one - the extension could have a setting added to prevent addition of pageCat tags on the talk page by users who wouldn't otherwise be able to edit the corresponding page, which I think would be a good idea for the reasons you're pointing out there. As to Wikitext puzzles, this was discussed a bit above in my discussion with VanIsaac - having a visible indication of some sort on both the main and talk pages that the category had been added in this way is definitely possible, if that's something you feel would help.

  As discussed previously at VPT, specifically for WikiProjects, there is mw:Extension:PageAssessments, which is already enabled on enwiki. However, the problem with using this is twofold: firstly, it requires significant change on the part of each WikiProject using it, not just adding a line to their templates but changing the entire way their assessments work; secondly, it doesn't categorise using traditional MediaWiki categories, meaning it can't be used easily with RecentChangesLinked, Huggle or any other similar tool. Naypta ☺ | ✉ talk page | 08:20, 14 June 2020 (UTC)

• Will this "article inherits talkpage categories" be fully automatic, or will the cat tags have a different syntax or flag? There are cats that specifically are for talkpages that aren't appropriate for their associated articles. One more level or shade of includeonly/noinclude spaghetti? DMacks (talk) 15:17, 14 June 2020 (UTC)

  @DMacks: Sorry, I'm not sure I quite follow - if you mean the code for categorising a page from its talk page, then yes, the syntax is completely different. You'd use {{#pageCat:The category you want}} to categorise it, rather than [[Category:The category you want]]. If I've misunderstood, please let me know! Naypta ☺ | ✉ talk page | 15:24, 14 June 2020 (UTC)

  Ah yes, now I see that key syntax difference. I assume that it's applicable to every namespace from its associated talkpage (not just articles). How does it inherit (if the page, whose talkpage is tagged, is transcluded)? DMacks (talk) 15:38, 14 June 2020 (UTC)

  @DMacks: Yep! Every namespace's associated talk. As to transcluding pages that are affected, this gets a bit complicated to describe: basically, no, it wouldn't travel down the transclusion tree in that way. In more detail, transcluding a talk page (1), tagged with a pageCat, into another talk page (2) would result in (2)'s associated article receiving the pageCat too. If you had a page (3) that had a talk page (4) with a pageCat on, then (3) is in the pageCat. If you then transclude (3) into another page, (5), then (5) is not given the pageCat - it's only given to the directly corresponding page. Sorry if that's completely unintelligible, though! Naypta ☺ | ✉ talk page | 15:41, 14 June 2020 (UTC)

  Those 1/2 and 3/4/5 patterns are both quite clear, and sound like reasonable choices. Thanks for taking the time to talk me through it! DMacks (talk) 16:08, 14 June 2020 (UTC)

  And this is why I think having something that shows up on the talk page and in preview is so important. If you transclude a template into a talk page discussion, that template could have {{#pagecat:}} code that the talk page contributor has no idea about. Ideally there would be some sort of automatic visual cue where the {{#pagecat:}} is included. VanIsaac_WS^cont 02:22, 15 June 2020 (UTC)

  @Vanisaac: This makes complete sense - and is more than technically feasible. The only trouble with doing so is coming up with styling that works well enough - it needs to be visible, but not so visible and fixed that it would cause issues for the template designer. One solution may be to give it a CSS class and some default styles, then let template designers use mw:Extension:TemplateStyles to style it as they like. As we discussed above, I'm also working at the moment on showing categorisations on the preview page. Naypta ☺ | ✉ talk page | 08:22, 15 June 2020 (UTC)

  And of course, there is also what happens when you add a {{#pagecat:}} to a template. Should there be a "Warning: this template contains a #pagecat: declaration, which will add a category to <insert talk namespace transclusion count here> mainspace articles. Please check this template's transclusions for a full list of pages this will effect."? Do we need to add an option to the "Pages that link to X" to allow it to list the mainspace counterpart of a transcluding talk page to link from a warning like this? VanIsaac_WS^cont 10:23, 16 June 2020 (UTC)

  @Vanisaac: This is a good idea, and ought to be implemented too - I agree. Perhaps all templates above 10 transclusions ought to result in that message, when someone adds a pageCat parser function for the first time? As to mainspace counterparts, I don't think that ought to be necessary - people can see clearly what the corresponding page for a talk page is, it's only software that has trouble with it Naypta ☺ | ✉ talk page | 11:13, 16 June 2020 (UTC)

• At present pages get classified twice, maybe three times:

• Categories for the readers;
• Projects for the editors; and
• DELSORT for deletion discussions.

Any way to reduce that workload and to ensure that readers and editors see the same groupings would be welcome. Cabayi (talk) 10:31, 15 June 2020 (UTC)

@Cabayi: Are you thinking along the lines of having WikiProject templates do some sort of automatic categorisation of the article beyond just the WikiProject itself, and onto other things like "Living people" for WikiProject Biographies with the |blp= parameter? That's an interesting idea, I'd not thought of that use case. Naypta ☺ | ✉ talk page | Naypta ☺ | ✉ talk page | 20:03, 15 June 2020 (UTC)

Naypta, I wonder whether you've considered phab:T132072 (roughly "Store metadata properly, not as free-form text stuck somewhere in an article") as a more complete solution to the problem you're looking at. Whatamidoing (WMF) (talk) 04:40, 16 June 2020 (UTC)

@Whatamidoing (WMF): Thanks for the reply! The extra slot for metadata I think is a great idea, but I'm not sure how it's relevant to this problem - having a separate metadata slot wouldn't affect notices being put on the talk page, as far as I can see. Were you thinking of a particular use for it that I'm missing? Naypta ☺ | ✉ talk page | 08:16, 16 June 2020 (UTC)

If categories weren't stored on talk pages, then you wouldn't have the problem of trying to use a category that's in the "wrong" namespace. You could reach all the categories from the same place. Whatamidoing (WMF) (talk) 18:44, 16 June 2020 (UTC)

@Whatamidoing (WMF): Sorry, I'm still not sure I follow. The proposal here has nothing to do with the namespace of categories; rather, the extension allows the talk page to categorise its corresponding page. This is useful for WikiProject templates, maintenance templates that go on the talk page like discretionary sanctions, etcetera. Unless you're putting that markup in the new slot, I don't see how the slot relates. This may well be me just being stupid though! Naypta ☺ | ✉ talk page | 19:06, 16 June 2020 (UTC)

If associating an article with a WikiProject was done via some interface that updated a metadata slot instead of the text of the article, then WikiProjects could use this instead of a tracking category. More generally, all category information could be stored as separate metadata. isaacl (talk) 20:23, 16 June 2020 (UTC)

@Isaacl: Yeah, there's a system that does something similar to this already called PageAssessments - it was discussed over at VPT when this was initially brought up. Relevant quote from me further up this thread is however, the problem with using this is twofold: firstly, it requires significant change on the part of each WikiProject using it, not just adding a line to their templates but changing the entire way their assessments work; secondly, it doesn't categorise using traditional MediaWiki categories, meaning it can't be used easily with RecentChangesLinked, Huggle or any other similar tool. This addresses the second issue, but not the first. It also means that it can only be used for WikiProjects, and not for other things - unless custom metadata is added for things like discretionary sanctions, PRODs, contested CSDs and potentially all manner of other things. Not that that's not possible - it just seems a long way off, considering that according to the Phab ticket the slot is only just being added to MW core now. Naypta ☺ | ✉ talk page | 20:29, 16 June 2020 (UTC)

Yes, more generally, if reader-relevant categories and maintenance categories were stored as meta data, and there were an interface to update the categories that could be embedded into templates, then the categories could be updated via templates, and it could be used for all sorts of maintenance purposes. Agreed this would be a big change and would require a phase-in plan. isaacl (talk) 20:43, 16 June 2020 (UTC)

• @
  NS:1)? VanIsaac_WS^cont
  18:38, 18 June 2020 (UTC)

  @Vanisaac: No, it would only operate on talk namespaces. It might be worth specifically generating an error output from the parser function if it's included in a different namespace, although I'd have to get that to play nicely with it being included in templates. Naypta ☺ | ✉ talk page | 18:42, 18 June 2020 (UTC)

  What would it take to allow for equivalent functionality - i.e. could there be a parameter (e.g. {{#pagecat:category|anyNS}}) or an alternate parser function (e.g. {{#maincat:category}}) to allow for categorizing the main page from a call/transclusion in both the main and talk page? VanIsaac_WS^cont 18:57, 18 June 2020 (UTC)

  @Vanisaac: This would be doable, yes - do you have a specific application in mind for it? Most things are technically doable, it's just a question of how useful they would be as compared to the development effort for them I suppose that way you could have maintenance templates that worked across both articles and their corresponding talk pages? Naypta ☺ | ✉ talk page | 19:02, 18 June 2020 (UTC)

  I was thinking of maintenance templates for the most part. Just having that leeway where a user knows that there's a "This article needs X fixed" template, but doesn't have to know it's supposed to go only in the talk or main page. Can we make it so the code gets the right page in the maintenance category even if the user adding the template doesn't know the "right" place to put it, or even better so that there isn't a wrong place to put it. VanIsaac_WS^cont 19:42, 18 June 2020 (UTC)

  @Vanisaac: Sorry it took me so long to respond to this! This is possible in theory, yes, but would take specific markup on the category page (similar to the __HIDDENCAT__ markup, but it'd probably be {{#categoryForPages}} or something akin). It wouldn't be able to work automatically, because there'd be nothing in-built to tell it what category wanted what. Naypta ☺ | ✉ talk page | 09:17, 23 June 2020 (UTC)

• The reason I was non-committal in the earlier discussion was that I wanted to gently point you toward working on the code path I think best in this regard. Categories are not where it's at for storing article metadata--we really should be using MCR or another table to do so. I am a firm oppose to this suggested work direction. --Izno (talk) 17:04, 23 June 2020 (UTC)

  @Izno: In an ideal world, we would use a dedicated system for storing this metadata, yes - much like that of the PageAssessments extension. This is not an ideal world; this solution is one that works in the real world, and works immediately, with all the tools we already have. The amount of work involved in changing everything else in the MW ecosystem to include an extra query type for querying for that sort of metadata, versus the amount of work involved in simply adding these articles to the existing categorisation system, is a no-brainer to my mind. Naypta ☺ | ✉ talk page | 17:22, 23 June 2020 (UTC)

  Erm, my point is that you should help make it an ideal world. :) --Izno (talk) 17:24, 23 June 2020 (UTC)

  @Izno: Doing so would involve a monumental amount of work across many teams, codebases etc. Changing not only MediaWiki itself, but then subsequently every single thing that integrates with the category system to also work with some other type of metadata, would be a task that would require the type of coordination across projects that something rarely even gets with explicit WMF support - see also Flow - and a sort of development effort on a scale unknown for a long time with MediaWiki. Naypta ☺ | ✉ talk page | 17:28, 23 June 2020 (UTC)

  So, I'm left still opposing. "Let's add some more hackery to work around the lack of a proper metadata system, which is a lot of work" isn't really good enough for me. Since you don't want to hear my opinion, MCR was built for this exact use case and should be implemented instead, and that fact is what should hold up the deployment of this new magic word and associated MediaWiki complexity. Do you have a Phabricator ticket I can leave that feedback at? Will you let me know if/when you do? --Izno (talk) 17:33, 23 June 2020 (UTC)

  @Izno: I think it is unreasonable of you to accuse me of not wanting to hear your opinion, considering that at the original discussion at VPT, I responded to what you said, but didn't hear back from you, and that here, I've answered everything that's been raised in good faith to the best of my ability. I'd appreciate it if you would withdraw that statement. That being said, I have no plans to try to force this on the community; so no, I do not have a Phab ticket for this to be deployed, and I do not intend on creating one unless and until there is a positive consensus built around its deployment. I do not want to cause people to expend time and effort deploying something that nobody wants to use, and I do not want to waste people's time dealing with something that people do not feel is useful, if that is the way that they feel. Naypta ☺ | ✉ talk page | 17:58, 23 June 2020 (UTC)

  I have not disputed the utility of your suggested change. Did someone else? I have said that you are presently working to duplicate an already-existing system instead of building on that system. You will need to figure out how to overcome that issue if you want to see your proposed extension deployed, and I'm opposing this change for that fact (never mind that the WMF will also have the same concern). Your list of pros right now doesn't get over that hump. --Izno (talk) 18:36, 23 June 2020 (UTC)

  @Izno: I understand the point you are making. I suspect that a proposal to move every tag on the talk page into a metadata slot would be a brave idea, but I welcome you to make one if you feel otherwise. If there was sufficient consensus so to do, I'm sure myself and other developers would be happy to help make it a reality. Naypta ☺ | ✉ talk page | 09:01, 26 June 2020 (UTC)

• Aside from my opposition, I think you have not considered the effect of __HIDDENCAT__ which would be necessary if these WikiProject categories were present on the mainspace page of an article but which are not in their current location. --Izno (talk) 17:06, 23 June 2020 (UTC)

  @Izno: I specifically mention HIDDENCAT in the original proposal - is there something other than what I've already said there you're thinking of? Naypta ☺ | ✉ talk page | 17:20, 23 June 2020 (UTC)

  We will need to add HIDDENCAT to every WikiProject category to support this change. Does that make sense? They are easy to access today for anyone on the talk page. --Izno (talk) 17:23, 23 June 2020 (UTC)

  @Izno: Nothing's forcing WikiProjects to take it up; it'd be a decision that each project could take as made sense to them. Also, nothing is forcing WikiProjects to use the same categorisation system for their talk pages as their articles. Naypta ☺ | ✉ talk page | 17:30, 23 June 2020 (UTC)

• I'm still in favor of this basically for the reasons explained in the OP, and I'm shocked--shocked!--that "Levivich wants it" isn't grounds for automatic speedy approval. I'd caution against letting the perfect become the enemy of the good. It's true that this solution isn't the best solution to the various problems, but it is better than the status quo. It's an improvement and nobody has to use it who doesn't want to. And, most importantly, Levivich wants it. Levivich ^{[dubious – discuss]} 06:34, 26 June 2020 (UTC)

It was rather curious how for a GLOBAL pandemic, there was what the UN secretary general called an "infodemic" in european languages but in African languages, free and open access to info on covid in African languages was poor.

I'm a program manager for a program that introduces wikipedia to youth in Africa as an education tool, for an organisation called Moleskine Foundation. The program, called WikiAfrica Education, aims to inspire a new generation of African creative thinkers and doers by increasing production, access and awareness of contextually and linguistically relevant knowledge resources from African continent.

For our covid response, we are gathering a movement of volunteers to translate the 10 most relevant articles to help spark creative solutions to the pandemic in African languages. These were existing Covid-relevant articles on English wikipedia that were not existing in the African languages we checked on. We, along with partner organisations and WikimediaZA, simplified and condensed them to reduce margin of translation error, making them a maximum of 1.5k words, only 6 sections, not too many subordinate clauses, not too china- or europe-centric, and no more than 6 sections. So far over 300 volunteers have signed-up to translate the articles into more than 40 languages, and our published work has been seen over 35k times (WM Dashboard). However, the volunteers are collaborating on Google docs. We are trying to train them on Wiki, but not all have the desire to learn. Meanwhile we have a stockpile of translations, and some paid for professionally, released under Creative Commons and ready to upload. And this is where we are bottle-necked.

For sake of project scope, focus and scarce resources we chose to focus on 11 languages for number of speakers and coverage over regions of Africa: Twi Kiswahili Sesotho isiXhosa isiZulu Afrikaans Shona Wolof Yoruba Fula/Pulaar Igbo. This gave us clear enough scope to approach local Wiki communities via the WMF. We have a good relationship with WikimediaZA (South Africa), and have established ties with Wikimedia Yoruba (Nigeria) and Wikimedia Ghana. But we need to upload the translations we have as soon as possible and need wikimedian support as everyone is busy at this moment- either with other projects, or just trying to survive under covid-society.

I am looking for experienced wikimedian support to upload about 80 articles translated by volunteers and professionals by end of 1st week of July as a Wikimedian in Residence. Keen to hear what other support is available out there. --Papa Baiden (talk) 11:44, 25 June 2020 (UTC)

Hi Papa Baiden, first week of January seems a long while away especially for something as urgent as this. The difficult thing is that you need Wikipedians who are fluent in those languages, and the English Wikipedia isn't the place to find them. It also doesn't help that the translation work has been done in Google docs rather than on the relevant wikis, there are several drawbacks to that, not least that Google docs doesn't support many of the features such as linking that are very important when editing wikipedia. I would recommend going on the village pumps of the eleven Wikipedias that you want to update and explaining your problem there. If you have bilingual people who are fluent in English and those languages and willing to edit the relevant Wikipedia's then you may be able to get help here - we can show people how to edit in English Wikipedia, and if they know the language they should then be able to edit that wikipedia. But we shouldn't be uploading unsupported articles into other language Wikipedia's without first consulting that Wikipedia community - that just leads to unsupported unintegrated articles. ϢereSpielChequers 12:09, 25 June 2020 (UTC)

Hi WereSpielChequers, thanks for the speedy response. Apologies about the Jan point- it's a typo and meant to be July (now changed). I completely now see the limitations of working from Google docs, but it was a naive attempt at listening to the needs of the volunteers I found. They were willing enought ot share their knowledge provided they didn't have to learn a new platform/tool as many of them still work. I'm trying to use village pumps where I can find them (it's tough as I don't speak the language) and get community engagement, but my dilemma is having work ready to go up urgently (as you said too) but having slow or zero response from other communities who are admittedly a little less active than here (no disrespect intended). I need a way to speed up this process before the work becomes irrelevant because someone else writes it (good for community to have info, but means my volunteers/pro-translators wasted time), or irrelevant because covid "blows over". Taking on board your suggestion of training, we held a session this week via Zoom but it was poorly attended. As a Plan B, we recorded a video tutorial and sent it to volunteers. I'll see if another training session is feasible and circle back. thank you once again. Papa Baiden (talk) 15:54, 25 June 2020 (UTC)

OK, one other place to ask for help is Wikipedia:WikiProject Africa. If you do have translators who are willing to edit Wikipedia and who also speak English, we may be able to get some trainers via the London Meetup and possibly even Wikimedia UK. Of course we then risk the usual mismatch in that many of our experienced trainers use the classic editor and many newbies use the visual editor. One other issue, how have you handled attribution if you have exported articles into google Docs and worked on them there to consolidate/precis them? ϢereSpielChequers 18:50, 25 June 2020 (UTC)

I've just posted on the Talk page for the WikiProject Africa. Thanks for flagging it. I hope the project is still lively and active (there's a bit of a gap between activity/posts there)... let's see. We may go ahead and schedule a sort of event geared towards training and uploads over the next 2 weeks, with the intention of training more new users speaking under-represented languages and getting content uploaded. I may have secured support from Wikimedia Yoruba to host the training and uploading event, but will learn this over the weekend. what do you reckon would make experienced editors be willing to help upload? For attribution, I'm getting collaborators to post the name of the translators on the talk page in a note saying "this article was translated from 'this original simplified doc' (and link to the doc) by person XYZ, and released under CC". Papa Baiden (talk) 11:51, 26 June 2020 (UTC)

Regarding

This is a bit technical, so I'll try to keep jargon down as much as I can.

People have said that if MediaWiki was released today, user scripting wouldn't be integrated due to the security risks. But as of right now, user scripting is here to stay, and is a useful feature, but it still carries these security risks.

I'm the developer of a user script and the fact that my script only faced mainstream scrutiny from administrators after it was used by over a hundred editors is concerning to me. As one of the biggest websites in the world, if Wikipedia were to come under attack, and they went for user scripts that are used by thousands of editors, the potential for disruption would be huge, not to mention the potential leaking of emails and IP addresses. Quite frankly, in this day and age of cyber-attacks, it is more of a question of not if, but when this will happen - so mitigating the risk of this would be very important for the future of Wikipedia's security. If a user script got a users tokens or cookies and sent them to a remote server, then an attacker could potentially completely control their account like some sort of digital voodoo doll.

VPT works well for those with concerns, but some people might not think twice, especially with things like Enterprisey's script installer making installation one or two clicks, with a warning that many users may just not bother to read. MfD is slow, and CSD does work, but both again require a user with technical knowledge reading it and knowing what's wrong, or it being too late by the time it is finally noticed.

Other attacks may be, for example, a user creating a script under one premise so that it can pass through the approval process, then changing it maliciously, hence proposal 6 below where the changes would also be reviewed. An approval process, such as I'm proposing, would also help scripts remain within Wikimedia's privacy policy and terms of service. It would also be possible to help the script developer in terms of issues in their code making user script development more in line with Wikipedia's collaborative ethos.

So this is what I propose:

• 1: The creation of a user-right and/or board of experienced and trusted script editors that can approve a user scripts either via consensus or at the discretion of a reviewer.
• 2: The creation of an edit filter that would prevent or warn other users from importing another users user script that had not been approved. This would be edited each time a script is approved and explicitly white-listed in the filter, although, there is likely a better way to do this.

• 2A: If possible, the filter will only apply to user scripts made following the creation of the approval process, as scripts by inactive users are still very much in use.

• 3: The approval process would require open source code that would be reviewed for potentially malicious code, or other issues.
• 4: Requiring all user script developers to enable or request two-factor authentication for security reasons, except in exceptional circumstances.
• 5: The creation of a feed or mailing list to alert trusted script editors to the changes within these trusted scripts, so if a malicious change is made, it can be reverted or deleted so disruption would be minimal. I am very willing to set up something like this as a bot or in Wikimedia Toolforge.
• 6: The setting up of a more clear policy regarding user scripts on what is and what isn't allowed.

For a more secure "nuclear option":

As these proposals are more software based, there would need to be consensus at the Phabricator too.

• N1: Potentially implementing pending-changes like restrictions to all or most user scripts, where a trusted script editor would approve the changes, especially when they could effect hundreds of users.
• N2: In the cases of a script being edited by a trusted script editor themselves, for security reasons, they wouldn't be able to accept these pending changes. Another script editor would need to approve this.

Of course, it is very important that this process is not overly restrictive as Wikipedia is a community lead project, and preventing potentially game-changing scripts from getting through the process would be a let down. The main purpose of this proposal is to mitigate the risk of the user script feature from being used maliciously. Any established board would be created in the goal to prevent malicious scripts and ensure the security, privacy and safety of their users.

Thanks all for your consideration, and feel free to ask if you need any clarification regarding my proposal. Ed6767 talk! 02:15, 26 June 2020 (UTC)

TLDR: User scripts are risky and carry many security risks, and right now, there's no approval or monitoring process I'm proposing the creation of these. Ed6767 talk! 02:23, 26 June 2020 (UTC)

TLDR this is a hard problem. :) phab:T71445 --Izno (talk) 02:34, 26 June 2020 (UTC)

Izno, indeed it is. it's a shame that discussion in the Phabricator regarding this has stagnated - but I think also opinions from non-technical users would be important, hence my proposal here. Perhaps if this works out, it could lead the way for other WMF wikis? Ed6767 talk! 02:40, 26 June 2020 (UTC)

I don't see what the problem with the current system is: any user who installs a user script is implicitly trusting the author of that script not to to bad things. This is even mentioned in MediaWiki:Userjsdangerous ("If you import a script from another page with "importScript" or "iusc", take note that this causes you to dynamically load a remote script, which could be changed by others."). * Pppery * _{it has begun...} 02:54, 26 June 2020 (UTC)

Pppery, but what if that user's account is compromised, or a malicious user fools people into trust? Warnings don't hold much weight now and often go ignored, and that's the issue. Ed6767 talk! 03:02, 26 June 2020 (UTC)

A simpler suggestion: MediaWiki namespace is where trusted scripts (gadgets and their dependencies) already live. And they can already only be edited by trusted

WP:INTADMINs. A simpler solution could be to store non-gadget scripts in that namespace, requiring an IntAdmin to approve edit requests to create/update scripts. Userspace scripts would then just be for personal scripts and testing, and on your skin/common js pages a big warning could be displayed if you are importing scripts from userspace rather than the MediaWiki namespace (i.e. via a hidden on-by-default gadget). - Evad37 [talk

] 03:15, 26 June 2020 (UTC)

I like the spirit of the idea, though I think the process could use some tweaking such as Evad37's suggestion. User scripts pose threats that many people don't realize and we should be more proactive in helping non-tech-savy users avoid making themselves vulnerable. — Wug·a·po·des​ 21:29, 27 June 2020 (UTC)

• not to mention the potential leaking of emails and IP addresses - didn't you argue at
  WP:AN
  that it's not possible for your script to have access to any of this info? Here you're arguing that malicious scripts can compromise sensitive information?

I agree with the spirit of your suggestions, but I'm not sure much of this is necessary yet. In response to the suggestions, some of the points here are contrary to what you argued at

WP:AN, and I found the statements you made there to be quite accurate. e.g. If a user script got a users tokens or cookies and sent them to a remote server, then an attacker could potentially completely control their account like some sort of digital voodoo doll. -- HttpOnly cookies with a domain make this not possible directly, and I'm sure Wikipedia doesn't send cookies back in each request, and the userscripts don't run on login, so this can't be sidestepped via headers, hence I don't think there's any attack vector to compromise any of this info. Yes, usernames can be scraped off the page and sent to a foreign endpoint, which automatically gets your IP, but that's the closest to a threat in this regard I can think of, off the top of my head. As for the specific suggestions, I don't agree with a couple: (1) just have the BAG do it, rather than create yet another council. Script developers aren't approved by the community, whereas at least BAG is (mostly) ran by 'crats and admins who were approved by the community in their RfAs, and again to join BAG. For (3), this is going to cause backlogs; yes only diffs can just be analysed, but it's still going to slow down updates, especially for large scripts or large updates. N1/N2 can't happen, because FlaggedRevs (Pending Changes) is practically abandoned. Personally, I see this being a bit of a faff to enact, for something that isn't even a problem yet. Have there been any serious incidents with userscripts to make this approach worthwhile? I think your script was one of the only ones that was completely hosted off-site, the rest have their diffs here and it probably wouldn't take long for someone to realise one is scraping usernames and sending them off. ProcrastinatingReader (talk

) 21:37, 27 June 2020 (UTC)

ProcrastinatingReader, I didn't say that "it is not possible for any script to access this information". My script didn't and never will have any code regarding obtaining this information implemented, therefore, it was not and never will be possible. But my script does not equal all scripts, so these risks still stand. If a malicious script is loaded on the client-side, malicious activity can occur in relation to that user's account and data. I like the idea of getting the BAG to do that, especially considering some intadmins are also in the BAG (relating to Evad37's idea) which may relieve backlogging. Ed6767 talk! 18:19, 28 June 2020 (UTC)

Ed6767, thanks for clarifying. When speaking technically, my interpretation of "is not possible" differs from and ignores intent of developer, and rather considers whether something is technically possible, so I'd automatically assumed you'd also used the term in this way. The main points in my previous response still stand though, in that much of this sensitive information is not accessible to a script due to security features in 'modern' browsers (ie practically every browser except old IE). With the workaround I mentioned, you could scrape IPs, and scripts aren't loaded on Special:Preferences so email can't be scraped. I still don't think it's worth adding so many hoops and a technical process for something that has not yet been abused. Such a bureaucratic process will discourage script developers in the future, and we should desire to do the opposite, as there are many scripts that are helpful (and many areas which need scripts to fix pain-points).

I agree with some less-strong suggestions to improve security in this area, e.g. all scripts should be hosted on-site (but may use 'popular' external assets, eg well-known scripts, from primary sources). That alone decreases the chance that a user can make malicious edits to a script without getting caught, as any changes will be permanently visible in a log. Perhaps a private edit filter could be used in future to flag potentially problematic lines, or foreign HTTP requests being made, which quickly and automatically brings attention to them. I think that would be sufficient, honestly. I'd call it "a necessary evil" if prior abuse could be shown, but it can't, and I think the aforementioned 2 ideas solve much of the main problems without adding the bureaucracy. ProcrastinatingReader (talk) 18:33, 28 June 2020 (UTC)

ProcrastinatingReader, I think at least 2FA should be imposed, or at least encouraged for userscript developers. Edit filters would be pointless as obfuscation would completely defeat them. And it is possible to obtain user info and emails without accessing Special:Preferences, see mw:API:Userinfo, here's an example, it takes very little code:

let api = new mw.Api();
api.get({
		action: 'query',
		meta: 'userinfo',
		uiprop: 'email',
		format: 'json'
	}).done( data => {
	console.log( data );
} );

Returns (for me):

{
    email: "ed6767wikixxxxxx"
    emailauthenticated: "2020-04-30T22:55:41Z"
    id: 00000
    name: "Ed6767"
}

That's just email. Modern browsers can't save you from everything. If CORS headers did stop you, here, it wouldn't be too much of a complex matter to edit some page somewhere with the info, then get a scraper to jot it down. . Just because something hasn't happened yet, doesn't mean it won't. And on one of the most visited websites on the internet, it's not a matter of if, but when. It is a risk to non-tech savy users, and should be mitigated. Ed6767 talk! 18:54, 28 June 2020 (UTC)

Cookies are sent with each request, since that's the only way to maintain a session between requests (other than encoding the session information into the URL). Javascript programs running in the client can basically simulate any user interactions with the website (entering data and clicking, or using the Wikipedia APIs) and so are definitely risky. Evad37's suggestion is a good one in terms of being implementable immediately if desired, and still letting users create personal scripts without any new overhead. isaacl (talk) 19:00, 28 June 2020 (UTC)

This proposal strikes me as overkill: one person was unaware of the privacy implications of using a third party CDN, and is now on a crusade to try to lock down all scripts everywhere using increasingly unlikely attack scenarios and appeals to the supposed incompetence of users. Let's not. The solution to "accidental use of external CDNs leaking information" is mw:Requests for comment/Content-Security-Policy. The better solution to "someone might write a malicious script" is to warn users to prefer Gadgets (which already have many of the safeguards being called for above) unless they know what they're doing, but not to got to the extreme of trying to require all scripts be gadgets. Anomie⚔ 13:28, 29 June 2020 (UTC)

Going on this, I'm not opposed to having "community scripts" that we store in MediaWiki space for things too niche to be gadgets. — xaosflux ^Talk 19:26, 29 June 2020 (UTC)

{{Hidden begin|titlestyle=background:#ccccff|title=Presidential election results}}
{| align="center" border="2" cellpadding="4" cellspacing="0" style="float:right; margin: 1em 1em 1em 0; border: 1px #aaa solid; border-collapse: collapse; font-size: 95%;"
|+ '''Presidential elections results'''<ref>Source</ref>
|- bgcolor=lightgrey
! Year
! [[Republican Party (United States)|Republican]]
! [[Democratic Party (United States)|Democratic]]
! [[Third Party (United States)|Third parties]]
|-
| style="text-align:center;" {{Party shading/Republican}}|'''[[United States presidential election in Illinois, 2016|2016]]'''
| style="text-align:center;" {{Party shading/Republican}}|'''71.6% ''' ''7,830''
| style="text-align:center;" {{Party shading/Democratic}}|20.2% ''2,210''
| style="text-align:center; background:honeyDew;"|8.2% ''898''
|-
| style="text-align:center;" {{Party shading/Republican}}|'''[[United States presidential election in Illinois, 2012|2012]]'''
| style="text-align:center;" {{Party shading/Republican}}|'''68.8% ''' ''7,061''
| style="text-align:center;" {{Party shading/Democratic}}|28.9% ''2,961''
| style="text-align:center; background:honeyDew;"|2.4% ''243''
|-
| style="text-align:center;" {{Party shading/Republican}}|'''[[United States presidential election in Illinois, 2008|2008]]'''
| style="text-align:center;" {{Party shading/Republican}}|'''64.4% ''' ''6,832''
| style="text-align:center;" {{Party shading/Democratic}}|33.0% ''3,494''
| style="text-align:center; background:honeyDew;"|2.6% ''279''
|-
| style="text-align:center;" {{Party shading/Republican}}|'''[[United States presidential election in Illinois, 2004|2004]]'''
| style="text-align:center;" {{Party shading/Republican}}|'''71.7% ''' ''7,335''
| style="text-align:center;" {{Party shading/Democratic}}|26.4% ''2,705''
| style="text-align:center; background:honeyDew;"|1.9% ''197''
|-
| style="text-align:center;" {{Party shading/Republican}}|'''[[United States presidential election in Illinois, 2000|2000]]'''
| style="text-align:center;" {{Party shading/Republican}}|'''70.7% ''' ''6,237''
| style="text-align:center;" {{Party shading/Democratic}}|24.8% ''2,191''
| style="text-align:center; background:honeyDew;"|4.5% ''395''
|}
{{Hidden end}}

{{PresHead|place=Placeville, Illinois|source=<ref>Source</ref>}}
<!-- PresRow should be {{PresRow|Year|Winning party|GOP vote #|Dem vote #|3rd party vote #|State}} -->
{{PresRow|2016|Republican|4,500|3,500|150|Illinois}}
{{PresRow|2012|Republican|4,000|3,500|50|Illinois}}
{{PresRow|2008|Democratic|4,500|5,000|50|Illinois}}
{{PresRow|2004|Republican|5,405|1,400|25|Illinois}}
{{PresFoot|2000|Democratic|4,000|5,000|25|Illinois}}

• No. This is not even good as satire. 50.74.165.202 (talk) 15:50, 7 May 2020 (UTC)

  It is interesting, however, that the first opposition comes from an IP with a grand total of 14 edits. BD2412 T 16:21, 7 May 2020 (UTC)

  While this reply is a month old it's still a very clear personal attack. You're clearly insulting this person because they're using an IP and have a low edit count; possibly implying the reason they don't like your proposal is because they themselves are a sock? This is rude and uncalled for and I would remove your comment but for the fact other editors seem intent on keeping it. Implying that someone's opinion is worth less because they edit from an IP is wrong and should be banned by policy.

  ping

  |Chess}} on reply) 21:36, 22 June 2020 (UTC)

• Let's say someone volunteered to run machine learning for sockpuppetry and it worked - what do you think it would tell us? SportingFlyer T·C 16:28, 7 May 2020 (UTC)
  • I expect that it would tell us, for example, when one conflicted individual is trying to fool us into thinking that multiple editors independently support a position in a discussion. BD2412 T 17:10, 7 May 2020 (UTC)
• I guess the question I have is "why", really. Why do we need such a thing? I can see that it's something that's possible, but I'm not clear on what the advantage would be, apart from sockpuppeters being "more effectively punished", even if they aren't actually doing any harm. I know there's the argument that they're doing harm just by sockpuppeting, and I have a great deal of sympathy for that, but I don't think a punitive effect alone, rather than actually helping the encyclopedia in any way, would justify measures like this. Naypta ☺ | ✉ talk page | 16:37, 7 May 2020 (UTC)
  • I'm actually not particularly concerned with "punishing" sockpuppetry, but we all know that there are plenty of instances where deletion discussions or content discussions for articles on companies, commercial products, celebrities, and the like are influenced by sockpuppet accounts appearing as independent editors. That sort of conduct should be stopped, even where the sockpuppeteers are successful in hiding their misconduct. BD2412 T 17:08, 7 May 2020 (UTC)
    • To my mind, the far more obvious problem to address there in which case is the situations in which you feel !votes are being treated as votes for the purposes of establishing consensus. I can see it might lead to issues of false consensus, but I suspect those sorts of problems would reveal themselves fairly quickly, in the same way in which we deal with meatpuppetry. Naypta ☺ | ✉ talk page | 17:51, 7 May 2020 (UTC)
      • There are discussions where reasonable arguments are being made on both sides, but where one side has strong numerical support. That is to say, there are instances where sockpuppetry, while not obvious or mindless, can turn the outcome of a discussion. BD2412 T 18:06, 7 May 2020 (UTC)
• I would suspect a bot like this would be incapable of telling an illegitimate sockpuppet from a
  valid one. Not to mention that if we are relying on data which is shielded per the priv-pol there's a not-inconsiderable risk of false positives from public terminals (not as much of an issue now but will become one once shelter-in-place and similar orders are lifted). —A little blue Bori v^_^v ^{Onward to 2020}
  17:04, 7 May 2020 (UTC)
  • There are activities that a valid sockpuppet should never be engaging in, like voting multiple times in an XfD process under different usernames, or having a back-and-forth with itself made to appear as if two unconnected editors were having that discussion. The parameters of a bot review can be tweaked to focus on instances of conduct like that. BD2412 T 17:12, 7 May 2020 (UTC)
• Transcluded to
  Wikipedia talk:Sock puppetry. * Pppery * _{it has begun...}
  17:20, 7 May 2020 (UTC)
• Theres been talk by global CUs of using machine learning on a limited basis to look at the behaviour between accounts (not technical). I think this is fine and wouldn’t be a privacy violation anymore than the editor interaction utility. If we’re looking at publicly available data, academics are already using it in studies of abuse on Wikipedia. Not a big deal there. I’m not really sure a bot running on every account makes sense, though.
  I would not support a bot or machine learning on CU data as that’s vague enough where anything the machine learning produces would likely be overwhelming and not useful. TonyBallioni (talk) 17:31, 7 May 2020 (UTC)
• This is a completely bizarre idea. And I don't know why a transclusion is necessary, Pppery a simple link on those other pages surely would have sufficed. But the IP^^^ makes a good point about satire. serial^# 17:32, 7 May 2020 (UTC)
• BD2412, you seem to be assuming that one IP address equals one user. That's not always the case. Everyone in my house uses same router, so we share an IP address, but we each have our own accounts. If I attend an edit-a-thon, I share the same IP with all the other attendees. I don't think I should be investigated based on that "evidence". Vexations (talk) 17:36, 7 May 2020 (UTC)
  • I have not doubt that there are instances that may look like sockpuppetry but have an innocent explanation. However, there are also instances that will look like sockpuppetry because they are in fact sockpuppetry, which would otherwise go unnoticed and allow Wikipedia to be spammed with commercial content or the like. BD2412 T 17:44, 7 May 2020 (UTC)
• Where does the "invasion of privacy" come in? If the proposal is to have a bot analyze edits to look for patterns, have at it, that involves no private data. If the proposal is to have the bot look at everyone's user agent and/or IP addresses and flag the overlaps, thats basically an automated checkuser-everyone, which will probably be a useless invasion of privacy, as it will just tell us, for example, which users are from the same university. I think some behavior probable cause should continue to be required, as it is now, for a CU to be run. Levivich ^{[dubious – discuss]} 17:41, 7 May 2020 (UTC)
  • I had rather assumed that people would automatically consider this an invasion of some kind of privacy. What I am really interested in is finding instances where different registered accounts from the same IP address are participating in discussions or appearing to talk to each other, which is where suspicious should arise. BD2412 T 17:47, 7 May 2020 (UTC)
    • @BD2412: I don’t mind sharing that some smaller version of the behavioural analysis that Levivich mentioned is being worked on by a CU on another project as a tool. People on non-English wikis (read: authoritarian regimes) were more concerned with the privacy aspect for understandable reasons. My argument is something along the lines of We literally already have researchers doing this. There’s absolutely nothing private here. It’s a decision aid to help focus resources, and would likely be likely to decrease use of CU and protect against false positives. I don’t see this as a privacy policy issue because as part of the nature of an open wiki, literally everything is public and people already have AI being run on their edits (see ORES). ST47 might have more to add. TonyBallioni (talk) 18:04, 7 May 2020 (UTC)
    • @BD2412 and ST47: fix ping. TonyBallioni (talk) 18:04, 7 May 2020 (UTC)
      • I would agree that if something along these lines is already being done, then there's no need for a proposal for it to be done. However, I had not previously heard of such an effort. BD2412 T 18:08, 7 May 2020 (UTC)
        • Yeah, it’s very early stages but wouldn’t impact the privacy policy and would be focused on behaviour, not IPs. I don’t think it would be run automatically either. Basically the idea that’s been floated is to use a tool that looks at certain similarities to be a behavioural analysis tool that humans can then look at as a decision aid. Like I said, early stage, but the idea of using additional tools has been discussed. TonyBallioni (talk) 18:14, 7 May 2020 (UTC)
• I think this is a great idea. However, who is going to run the bot? We would also need to see the source code.--SharʿabSalam▼ (talk) 18:06, 7 May 2020 (UTC)

  SharabSalam, if we're using publicly available data only (which may be the case), I don't think either question matters. Source code doesn't help because it's never possible to prove that's the source running on the bot. And neither point matters because publicly scraping Wikipedia can be done by anyone.

  If we're using private data, I think ultimately this would have to be added as a core part of the software, or a bot ran by the WMF. Maybe I'd support the CheckUsers, collectively, authorising the usage of a bot hosted by one of them -- maybe. But no private user, or administrator in this case, however, should be using non-public data in their individual capacity. ProcrastinatingReader (talk) 15:53, 16 June 2020 (UTC)

• @
  fishing. How would the bot distinguish socks from unlucky matches? Suffusion of Yellow (talk
  ) 22:08, 7 May 2020 (UTC)
  • @Suffusion of Yellow: [...]thousands of editors every day who by chance alone will have an IP+Useragent match this is actually much less common than it used to be, but sure, it happens. Usually exact IP+UA at the same time is the same person. It requires human judgement and we tend to be fairly conservative in blocking. The bigger issue would be on ranges, where you’d be overwhelmed easily and the data would be fairly useless unless you knew what you’re looking for. TonyBallioni (talk) 22:19, 7 May 2020 (UTC)
    • @TonyBallioni: To be fair, whilst it might be less common than it used to be for now, I strongly suspect it'll increase rapidly over the next few years as IPv4 address exhaustion forces more ISPs to implement carrier-grade NAT. It remains to be seen whether IPv6 adoption will continue at the same rate - I hope it does, but at least over here in the UK, very few ISPs currently support v6, and even fewer have it as a default. At the point at which CGNAT is the norm for residential networks, like how it presently is for many mobile data networks, that issue of multi-user IPs is going to become bigger. Naypta ☺ | ✉ talk page | 22:23, 7 May 2020 (UTC)
      • Well, yeah, the UK is second only to Nepal in being the exception to my above statement :) TonyBallioni (talk) 22:26, 7 May 2020 (UTC)
  • The Checkusers would be the ones to make that distinction. Actual suspect cases (matches of identity occurring on the same article or discussion) will likely be a small number—unless the problem itself is much bigger than anyone realizes. BD2412 T 22:22, 7 May 2020 (UTC)

  Suffusion of Yellow, we can use fingerprints too. There are various ways to get very unique identifiers out of people. ProcrastinatingReader (talk) 15:54, 16 June 2020 (UTC)

• I will never support a proposal with a section title like that. Merits aside (this is an area I have no interest or knowledge in), you've poisoned the well for me, and I suspect I'm not alone. —⁠烏⁠Γ ^(kaw) │ 22:35, 07 May 2020 (UTC)
  • As it turns out, the point is rather moot. BD2412 T 16:07, 10 May 2020 (UTC)
    • What? —⁠烏⁠Γ ^(kaw) │ 00:23, 12 May 2020 (UTC)
• It might be easier to start with a narrower approach that could serve as a proof of concept. Maybe a bot that searches for the known characteristics of specific LTAs, if that doesn't already exist. Otherwise, maybe a bot that specifically checks XfDs, or even just XfDs in specific categories where sockpuppetry is likely to be common. Sunrise (talk) 15:57, 10 May 2020 (UTC)
• Would this be permissible under the various privacy regulations that the WMF may be subject to? If so, would the WMF need to re-write its privacy policy to reflect this additional processing of personal information? Also, I share the sentiments of User:KarasuGamma. Privacy is important, and I cannot support "a massive automated invasion of privacy." Thanks, Tony Tan · talk 04:24, 13 May 2020 (UTC)

  Tony Tan, it would be permissible, and no change is required. Per the GDPR and CCPA, the two major pieces of privacy legislation, data can be used for this purpose but must be appropriately disclosed in a privacy policy. On Wikimedia's privacy policy the use guidelines already state that personal information collected may be used "To fight spam, identity theft, malware and other kinds of abuse." ProcrastinatingReader (talk) 15:59, 16 June 2020 (UTC)

  @

  dynamite fishing, which is basically what this is. - Alexis Jazz

  11:54, 6 July 2020 (UTC)

  Alexis Jazz, I do quite a lot of work in my field with the GDPR. Wikipedia is a special case as a volunteer-style structure, and obviously statements made here don't mean anything compared to the WMF's advice, but the line in the terms I quoted is indeed relevant. The point of this proposal is automation to detect sockpuppeting, the bot part is merely an implementation detail. I don't think anyone would disagree if the WMF added this to the core software it would be covered under the existing policy.

This isn't dynamite fishing, proposals that are made here are done openly by other companies for the protection against abuse, and have been done for over a decade, and recent privacy legislation isn't meant to stop that. This project is just incredibly conservative against any form of privacy invasion, even IPs, but these examples are not top secret forms of personal information per privacy legislation.

The relevant question is then, can a bot hosted not by WMF also comply with the existing privacy policy? You've selectively quoted the line, it ends with saying When these administrators access Personal Information that is nonpublic, they are required to comply with our Access to Nonpublic Information Policy, as well as other, tool-specific policies. If, per your interpretation the privacy policy doesn't cover volunteers, it would obviously follow that usage of bots cannot violate said privacy policy. But this interpretation isn't correct. The WMF is the data controller for personal information such as IP addresses. The fact that they choose to make CheckUsers sign a separate agreement (which is between the WMF and CUs, not between the data subjects and CUs) doesn't change that fact. Them being volunteers doesn't suddenly give IP addresses a special status in privacy law where no entity is the controller of that information. WMF remains the controller, CUs are somewhere between agents and processors. The data is obviously governed by the privacy policy, since WMF is the data controller. Indeed, the sharing of data under the policy with community-elected individuals, including functionaries, is covered earlier in the policy.

This doesn't automatically mean that the bots are permissable, of course, just that they're not violations of the WMF privacy policy. They are probably violations of the CU access to non-public information agreement, which is between CUs and the WMF, so that may need amending to allow this change. ProcrastinatingReader (talk) 12:10, 6 July 2020 (UTC)

@

WP:NOTFISHING, this is dynamite fishing. The privacy policy covers volunteers (checkusers are not paid), but there is a world of difference between the WMF allowing checkusers to query checkuser data of specific targets (which is clearly done in an effort to curb abuse) and dumping that information of everybody in a ZIP and mailing it to a bot operated by a volunteer. - Alexis Jazz

12:32, 6 July 2020 (UTC)

WP:NOTFISHING

, yes, I agree, this is fishing. But, NOTFISHING is a community policy, which can be amended by the community. It isn't a legal concept. Obviously, IPs can and are used by other companies for what WP would consider 'fishing'.

I'm not saying I agree with this change, elsewhere I stated my opposition to having CUs run this bot (I absolutely don't want some community member being able to make some code that decides in what cases they get to make the checks, especially not without unprecedented transparency), I was just saying that it wouldn't be illegal to use data in this way. Our current CU policy is very strict, and for the most part, I like it that way. I'd be open to more checking, but personally I think it'd have to come from something hosted by the WMF, or possibly by the CUs collectively if we can work out suitable methods to make this system very transparent. I think this proposal will most likely fail, because that's a difficult thing to do, but admittedly we do also face very different threats to what the project faced a decade ago, so contemplating how policies should adapt isn't a bad thing. ProcrastinatingReader (talk) 12:41, 6 July 2020 (UTC)

@ProcrastinatingReader: Actually there is a legal aspect to NOTFISHING. (though that is not what the policy is for) If a checkuser would randomly request checkuser data, they would be looking at personal data for a purpose that can't be clearly defended as being just to fight abuse. That is a real problem. The word "bot" implies "not operated by the WMF", so that's pretty much the end of this proposal. If the suggestion would be something operated directly by the WMF, well.. the devil will be in the details. But this proposal isn't that. - Alexis Jazz 13:34, 6 July 2020 (UTC)

• I agree with Suffusion of Yellow: what happened to
  WP:NOTFISHING? Double sharp (talk
  ) 13:19, 17 May 2020 (UTC)
• With the caveat that sockpupetry isn't an area I'm very familiar with,^{that's exactly what a sockpuppet would say...} I'm persuaded by BD2412 and the others arguing that this isn't that different from research. With the data already on our servers, I don't see how hiding it from ourselves by disallowing a bot to run in this way would preserve privacy. If those of you opposed can come up with a realistic example of a way this could go wrong in practice and end up violating someone's privacy in a way that meaningfully harms them, I might be persuaded, but currently I'm drawing a blank on that. There are clearly technical aspects to be worked out, and that could get complicated especially if the privacy policy ends up being involved, but overall, when we're looking at a tool that could deliver probable cases of sockpuppetry to highly trusted editors able to investigate them,
  WP:SUICIDEPACT. {{u|Sdkb}} ^talk
  04:50, 21 May 2020 (UTC)
  • The whole point of
    WP:SUICIDEPACT makes no sense here. I would, in fact, prefer an absolute right to be free from unjustified search. — Wug·a·po·des
    ​ 20:50, 4 June 2020 (UTC)
• I had a look at a recent suspected sockpuppet, and was able to match him to a blocked user using the type of approach a machine learning program might use. However the blocked user is someone we would really like to come back on a standard offer, and the sock had done no harm, so I did not share my suspicions. "First do no harm." A bot would not have this discretion. All the best: Rich Farmbrough 22:03, 30 May 2020 (UTC).
  
• @BD2412, Suffusion of Yellow, TonyBallioni, and Pppery: I don't know how many of you are aware but the WMF is currently running research projects to detect sockpuppets without any private information, probably NLP, sentiment analysis and the likes. I came across the project quite accidentally but here's the link: meta:Research:Sockpuppet detection in Wikimedia_projects. I'm quite sure that with a big dataset like the one at SPI, it'll be quite easy to detect sockpuppets of some prolific masters. --qedk (t 愛 c) 12:47, 2 June 2020 (UTC)

QEDK, The dataset isn't actually that large. I looked into some of this stuff last winter. I found 22,618 SPI archives, containing a total of 105,426 blocked socks (as of 12 December 2019). As machine learning corpora go, that's not a huge amount of data. -- RoySmith (talk) 13:39, 13 June 2020 (UTC)

• I don't suppose it would be possible to add
  keylogging to the arsenal of detection tools? The keystrokes that an individual uses to type words are, with enough samples, like a fingerprint. BD2412 T
  15:22, 2 June 2020 (UTC)
  • It is possible for browsers to use JavaScript/jQuery (or even CSS) to log keystrokes but let me begin by telling you abundantly how terrible of an idea it is - and a lot of websites do this to collect data (called session replay) and it's simply unethical, especially in some cases the information you reveal is available in plaintext to third-party analytics providers, there's no reason ever for Wikipedia to do this. Imagine you're editing Wikipedia and have your bank login page open and type your password accidentally without seeing the tab you are on, your personal information would automatically be logged and someone with access to it could be compromised, or let's say if the server gets compromised or an unpatched MITM attack is used, making it a very, very vulnerable attack vector. --qedk (t 愛 c) 16:20, 2 June 2020 (UTC)
    • I find it hard to imagine accidentally typing a bank password into Wikipedia. However, my intent is not to record what people type, but how they type. That is the distinguishable characteristic. BD2412 T 16:24, 2 June 2020 (UTC)
  • Now you're just fucking with us. - Alexis Jazz 11:54, 6 July 2020 (UTC)

Would the source code be public, like most things here, or private, like AbuseFilters? >>BEANS X2t 14:32, 4 June 2020 (UTC)

• Support - but we're liable to lose a whole lot of editors and maybe even a few admins. ^Atsme _Talk 📧 14:38, 4 June 2020 (UTC)
• I'd support this, provided the source code is reviewable by BAG and checkusers and similar. Basically automated detection of suspicious patterns to be flagged for CU review. Would be a great way to get rid of a bunch of PAID editors and similar.
  b
  } 20:12, 4 June 2020 (UTC)
  • Source code makes virtually no difference here. It's like open source for electronic voting machines. They're still shit. They will always be shit. They will never be not shit. - Alexis Jazz 11:54, 6 July 2020 (UTC)
• Oppose because now there's talk of running keyloggers, and I don't trust that this will remain a restrained process if implemented. We're here to build an encyclopedia, not a police state. If you want to teach machines to detect sock puppets, use publicly available data like everyone else, but no one, whether personally or by both proxy, should be accessing user's personally identifiable information without cause. — Wug·a·po·des​ 20:50, 4 June 2020 (UTC)

  We have plenty of cause - we have uncovered several large and sophisticated sockpuppet editing operations in the past few years, and there is really no question that there are others going on undetected right now. Also, this "talk of running keyloggers" of which you speak is basically one question that I asked. The proposal is for CU-style checks of relationships between accounts. BD2412 T 21:50, 4 June 2020 (UTC)

  But you understand how starting your proposal with "a massive invasion of privacy" and then later, off-handedly suggesting an even more invasive violation of privacy does not give me confidence that this will be restrained, yes? There's large and sophisticated drug cartels and other criminal enterprises operating undetected right now in many countries, that doesn't mean I want people opening all my mail to stop them. Like I said, use publicly available data if you care so much, but sorry, you've given me no reason to trust that you will respect user privacy. — Wug·a·po·des​ 22:24, 4 June 2020 (UTC)

• Oppose. Wikipedia is a fairly important institution. Its neutrality, as far as I can tell, comes in large part from the fact that editors have been able to expect a great deal of privacy (Wikipedia covers some pretty controversial subjects, as you may have noticed). Setting a precedent that things like editor IP addresses, login times, et cetera are freely used in the vague aim of "preventing abuse" opens up an unfathomably deep can of worms and degrades the trust of people who are, first and foremost, unpaid volunteers. The idea of using sentiment analysis on editors is already kind of creepy, and there's no need to top it off by destroying a very well-established standard of propriety built over the course of decades. I am pretty sure that if I lived under a regime where my Wikipedia editing constituted a criminal offense, I would be heading out the door and not looking back at the first sign of this proposal being enacted. { ${\displaystyle \mathbb {JPG} }$ } 05:06, 9 June 2020 (UTC)
• Support WMF funding community discussion The Wikimedia community must use automated tools to manage more of Wikimedia projects. This is absolutely necessary and there is no alternative. There are 100 automated tools available all of which can do different things, and this proposal is for one tool doing one of those things. For any given tool, it can operate in 100 different ways, and each of those ways makes the wiki community both more powerful and more vulnerable in different ways. We have to sort this out with conversation.

The Wikimedia movement brings in US$130 million/year growing at 10% a year. There is no shortage of funding, but there is a major shortage of community organization and leadership. Right now the default path is to use this money to fund internal private conversations at the WMF to sort this. They already employ software developers who are making tools like this a reality. Either the wiki community discusses this or otherwise this gets several million / year in WMF private investment until the WMF pops something out in the end. There is no option to not spend millions of dollars on this, or to not eventually implement this technology.

I think the Wikimedia community should advocate for funding to a mix of Wikimedia community organizations, universities, and nonprofit partners to support more community discussion. There are many, many social and technical issues to discuss. This goes far beyond one conversation on the village pump, and into massive global design of culture and society which requires a lot of input. If 10 universities in 10 countries each addressed one social challenge in this for 3 years, and each got US$100,000 from the WMF over that time period (meaning US$3 million for the project) then that would be the approximate scale of the response we need to start the conversation on safely developing automated tools for moderation.

This issue is far, far beyond what volunteers can crowdsource without expert partners and funded support. The money is available and I support anyone who would draft and propose any budget to address this problem anywhere in the US$500,000 - $5,000,000 range over 1-5 years. Also in general, I support more community proposals to speak up about spending more money to address big issues. Blue Rasberry (talk) 15:00, 13 June 2020 (UTC)

• I support this and any proposal which makes sockpuppetry less feasible and thwarts them sooner. We know that editor retention is an issue, and I know for a fact from various discussions I've been in that the frustration of dealing with sockpuppets plays a role in driving away good editors. The proper analogy for Wikipedia is not that of a society (with rights like being free from 'unjustified search') but that of a private business (as BD2412 built his framing device around). Editing Wikipedia is not a human right but a privilege, and one that comes with limitations that one must follow. As noted above, the Wikimedia Privacy Policy does allow for use of data in this way. Of course, future discussion regarding exact criteria for the bot to flag accounts, and admins' human judgment before blocking, would ensure that legitimate alternate accounts or people sharing a household would not be blocked. But, sockpuppetry is far too common, it can seriously damage the encyclopedia by facilitating the addition of sneaky POV text, and more needs to be done to stop it. Crossroads ^-talk- 05:08, 19 June 2020 (UTC)
• Oppose: Too many chances of false positives. Also, "actual instances of likely sockpuppetry" is a very contradictory and vague statement. I'm of the opinion that this whole anti-sock crusade is a rather uncertain affair. The more controversial the proposal, the better it is to reject it. HalfdanRagnarsson (talk) 16:11, 20 June 2020 (UTC)
• Support This is merely a tool, one of many, that admins can use to determine sock puppetry .. The final sock descision is made by people, not bots. The more tools and data admins have available to make a better decisions, the better. If the admins make a bad call they are personally responsible, not the tool. Next time they might not use the tool again or give it less weight or learn which situations it tends to be right and wrong. It's self-correcting. I get the impression the Opposers believe the bot is a fully automated decision maker?! That would be crazy and is a strawman argument. We have lots of "self driving cars" that are not full autonomous eg. driver has to be watching the road behind the wheel etc. Computer automation is like that, on a spectrum not black and white. -- GreenC 17:33, 20 June 2020 (UTC)
• Support in limited form. It could be something that automatically flagged multiple accounts from the same browser/IP or whatever data is available, and then showed this to admins only.
  • On the detection side, consider current SPIs that turn up master account with two or more socks. This kind of thing could be automatically detected and flagged, removing the current subjective decision-making required when deciding to run a CU. Someone files an SPI, the admin would see it, and then could request CU per "automated detection data" or something like that. There would be a clear reason for a human CU, based on the detection criteria. Think of this like an automated "stage 1" CU that only admins can see.
  • On the account creations side, are there really that many times where a single computer would create and operate more than three accounts in a week or a month? Account creations past a certain number could be flagged.

Automated detection of account similarities/anomalies is a good idea, and it could start out very conservatively: for example detecting multiple !votes from the same computer at AfD, and the creation of two or more accounts within a week from the same IP or computer.

Another idea might be to have the algorithm provide a "likely trouble" percentage. This might actually enhance privacy, as a low percentage would mean the human CU would decide not to run a check that reveals personal data.

talk

) 04:16, 22 June 2020 (UTC)

• I don't see how this would be an additional invasion of privacy, every instance of an actual action being taken against someone would still be carried out by a human, this would simply sort the data to allow for more effective moderation. The implication you make however, that because it is carried out by a bot, it is impartial, is incorrect. Bots are created by people, it isn't easy to write an impartial algorithm for complex discrimination of data that concerns justice. — Preceding unsigned comment added by 75.158.150.208 (talk • contribs)
• Oppose - all this will lead to is disruption, privacy violations and waste of checkuser time. Detecting a sockpuppet automatically would be very challenging, as there are always so many edge cases automating this process wouldn't be viable IMO. Ed6767 talk! 22:30, 26 June 2020 (UTC)
• Oppose: I thought a troll had gotten into the village pump when I read the title of the post. It would just waste CheckUsers' time and create piracy concerns, and will be redundant because of
  (Honk!)
  00:59, 3 July 2020 (UTC)
• Support, detected/suspected socks would still have an opportunity to respond prior to an any admin action. It seems to me that in my meagre six years here the problem has gotten much worse whilst the number of editors per article has dropped significantly, trying to combat the constant barrage from SPAs and SP IPs is time enough without having to then justify your suspicions of sockpuppetry at SPI. This would be a beneficial tool with realistically little chance of abuse as everything everyone does here is fully visible to someone. Cavalryman (talk) 01:27, 3 July 2020 (UTC).

  Support - ^{ooops - at least I'm consistent. 09:18, 3 July 2020 (UTC)} but here's my question...what if there's a conference and 2 people are sharing a room? What about edit-a-thons? What about a family that edits together, or a couple, or a neighbor decides they want to edit WP and comes over to learn? Does any of that matter? ^Atsme _Talk 📧 01:37, 3 July 2020 (UTC)

  • I am presuming that a likelihood of shenanigans will be gauged based on behavioral cues (such as grouped voting on obscure AfDs, or unusual use of the same phrasing). I myself have edited while at Wikimania, and in a pinch even borrowed another Wikipedian's laptop to make some edits at the Wikimania in Italy. Of course, editors may be asked to explain the circumstances of apparent sockpuppetry, and an editor who is blocked can always appeal the block. BD2412 T 02:30, 3 July 2020 (UTC)
  • talk
    ) 02:46, 3 July 2020 (UTC)
• Support: As someone who has written many sockpuppet investigation reports (the latest on 21 June 2020) I think this is a great idea. It would save good editors a lot of time that is spent on relentlessly writing sockpuppet investigation reports. This saved time would be spent on creating good content. Also, I don't think this supposed "invasion of privacy" would harm any honest editor. Tradedia^talk 07:43, 6 July 2020 (UTC)
• Oppose All the data needed to be reviewed to determine who is in fact engaged in sock puppetry is already stored in our servers, so why don't we set a bot to a task of reviewing all the edits A bot? Who's gonna run that? You? That'll make for an interesting target for
  dynamite fishing down before you'll ever get to the pond. So, WMF? That would require some severe changes to the privacy policy, not to mention require substantial developer time. Yeah.. probably not. Summoning Mdennis (WMF), JSutherland (WMF) and Jrogers (WMF). Humour us. - Alexis Jazz
  11:54, 6 July 2020 (UTC)
  • Maybe the CU team could be in charge of it? Also, what specifically in the privacy policy forbids it? Above, editors have been saying that it is allowed by the privacy policy. Crossroads ^-talk- 04:48, 15 July 2020 (UTC)

All name should be recorded in the pronouncation in which every one will understand to every sector of the world like some people pronounce xavi as x avi not knowing it is pronounce shavi and all music will have audio file in which one can listen to some part of it and if full you can. This what makes article more interesting and back up article. let enforce it more let use wpwp campaign to enforce this more.Tbiw (talk) 14:03, 6 July 2020 (UTC)

WP:SAMPLE for fair use music samples. {{u|Sdkb}} ^talk

04:52am, 26 July of 2020 (UTC)

I just did a Bing image search for "united states language pie chart" and ended up at a pie chart that is only used on a talk page. I cannot judge the accuracy of such an image, but I do not picture readers being directed to talk pages being super helpful.

Basically, I think it would be beneficial if talk pages in general are deindexed. I think there are certain queries that will take the user to where they want to go, on Google or otherwise, like searching "Wikipedia village pump", but I do not think people looking for information on a topic is going to be helped by many talk pages, as it is only for discussing improvements to an article. Aasim 22:35, 13 July 2020 (UTC)

Either way though, that image will still end up being indexed on commons? I don't really support the idea of deindexing talk pages, especially as they could contain topically relevant info. Ed6767 talk! 01:14, 15 July 2020 (UTC)

Ed6767 that is true. But it would be a lot more helpful if the image was indexed from its file description page and not some random talk page (or talk page archive). Or they should be indexed lower on search results. The last thing I want is an image that is on a talk page that is not accurate showing up in image search results. I am guessing the image is accurate? IDK like I said. Aasim 18:31, 15 July 2020 (UTC)

That chart was only created as part of a discussion about which style of graph is most useful to display that information. It was not intended to be used elsewhere. Rmhermen (talk) 03:57, 16 July 2020 (UTC)

I agree that the talk namespace should be deindexed. Talk pages and especially archived talk pages do occasionally show up in Google and they're always just random speculations or semi-serious BLP violations. – Thjarkur (talk) 09:53, 17 July 2020 (UTC)

Þjarkur, completely disagree. That also makes them unfindable for those who WANT to find them. Undesirable content should just be deleted and ppl have a bit of responsibility to interpret what they are looking at. —TheDJ (talk • contribs) 11:04, 17 July 2020 (UTC)

There have been a few (now decade-old) discussions about whether talk pages should be indexed, mostly as part of broader proposals about indexing, which are catalogued here. One point to note is that talk pages of BLPs are already deindexed, which helps reduce the likelihood of especially harmful material appearing in search results.

Arguments against deindexing that were raised at the time include its impact on users who dislike MediaWiki's search engine and prefer to browse discussion archives through external engines. Given the native engine has presumably improved since then, I'm not sure whether this practice is still prevalent. Another was the possible effect of deindexing millions of pages on Google's PageRank of articles – an FAQ for a

2009 proposal

claims the impact would be "very difficult to predict", though I'm not equipped to judge whether this is true.

Either way, I think the negative effects of indexing talk pages are too slight to justify changing the usual practice. I agree with TheDJ; I would expect users who come across talk pages in their search results will grasp their nature as discussion hubs, given the clear prefix in their titles, and adjust expectations of their content accordingly. The problem is when search engines present talk pages' content misleadingly, as in Aasim's Bing search. Bing, unlike Google, does not give an image's domain without a mouseover, and even then it ambiguously gives the chart's source as "Wikipedia" (you have to click through to see it's from a talk page). That is their responsibility to fix, not ours. If the chart's source was presented unambiguously, there wouldn't be a problem. – Teratix ₵ 13:31, 17 July 2020 (UTC)

The main issue that I have with many talk pages being indexed is that we do not want inaccurate information showing up high on search results. Because Wikipedia is a very popular website for information, we do not want to mislead readers with images that is potentially inaccurate. It would be a lot better if used images were indexed if they were only in main namespace. The problem with indexing talk pages is the same problem as this (now-deleted) template: they provide no help whatsoever for someone searching the topic. And people that check the source of the image will be confused that they see what looks like a weird kind of forum that only some people can comment on instead of the traditional Wikipedia article. I am providing a bit of a reader-focused view on Wikipedia. I think it would be in our and our reader's best interest to deindex talk pages. Aasim 20:44, 17 July 2020 (UTC)

Oh, and deindexing does not mean that they will not show up on MediaWiki search results; they just won't show up on Google or Bing. Aasim 20:46, 17 July 2020 (UTC)

I concur with the Awesome One: the garbage content on talk pages is much higher, and stuff we would never allow to remain in an article can just lie there on a talk page, like the proverbial "t**d in a punchbowl", ready to be stumbled on by an unsophisticated seeker of information. --Orange Mike | Talk 21:20, 17 July 2020 (UTC)

Agreed with the arguments for the de-listing as explained above, per Aasim and Orangemike. Regards, GenQuest ^{"Talk to Me"} 07:26, 18 July 2020 (UTC)

• I agree that talk namespaces should be deindexed and find the arguments against deindexing to be wanting; while it is likely true that search engines such as Bing "should" improve their search engine algorithms to remove the undesirable effects of indexing talkpages, we cannot assume that they will take that responsibility nor can we control whether they do. Besides, talkpages have vanishingly negligible value outside of Wikipedia editors anyway, so there's no real harm in deindexing them. – John M Wolfson (talk • contribs) 07:36, 18 July 2020 (UTC)
• I would very strongly support deindexing article talk pages. The sane reason we deindex BLP talk applies to all talk: they contain a high percentage of misinformation, spam, and unsupported accusations. The peoplewho needto find them are active WP contributors, andour own search function now works well enough for that. DGG ( talk ) 16:59, 21 July 2020 (UTC)
• I must admit that I assumed that this happened already, but it seems that I was wrong. I, for one, have never used an external search engine to find anything on Wikipedia outside the article space. Has anyone? Having said that I don't think that this was a particularly good example, because images on Commons are designed to be found and used. But that is a matter for Commons.
  Phil Bridger (talk
  ) 17:13, 21 July 2020 (UTC)

  I often use a search engine to look for content on Wikipedia. The internal WP search is useful for exact strings but I don't have the skill to get it to work finding concepts or related information; a search engine search scoped to wikipedia.org frequently helps me find what I'm looking for when I don't know the title or precise phrase. Schazjmd (talk) 17:39, 21 July 2020 (UTC)

  Ok, it's good to hear that such a strategy can be useful.

  Phil Bridger (talk

  ) 18:39, 21 July 2020 (UTC)

example:

• https://www.imdb.com/title/tt3444938/

to:

• https://www.imdb.com/title/tt3444938/reference

same as the older:

• https://www.imdb.com/title/tt3444938/combined

this results in more information to the reader 0mtwb9gd5wx (talk) 21:35, 21 July 2020 (UTC)

Please note that per

WP:RS/IMDB the site should not be used as a reference. OTOH if you are referring to how it is used in the "External links" section of an article other editors will be able to assist you. MarnetteD|Talk

22:29, 21 July 2020 (UTC)

I think the proposal is to change the default URL generated by Template:IMDb title. Probably a proposal better suited for Template talk:IMDb title, in my opinion. ―Mandruss ☎ 01:04, 22 July 2020 (UTC)

The issue of

The license allows reuse with attribution for any purpose whatsoever and keeping the same license as its source. There's nothing else to do about websites that follow those terms. (I imagine Google is not kind to the PageRank of copies in general.) Qwe wiki, as the link you provided points out, complies with those terms. --Izno (talk) 19:37, 13 July 2020 (UTC)

We don't only allow reuse of our content, for profit or not, but positively encourage it. That is one of the ways in which content is the property of the people who write it rather than the foundation which is supposed to serve them. But anyway, the foundation does not have the power to require

Phil Bridger (talk

) 20:20, 13 July 2020 (UTC)

The world would definitely be better off without clones that spam ads at people, but modifying the license to try to stop them would be a huge change (the replies above start from the assumption it's not even within the scope of discussion), and it'd have to be done carefully to avoid blocking more benign commercial reuses, such as the

Google search results knowledge panels. Overall, despite the one instance you encountered, I don't think clones are all that big a problem compared to other challenges we face like UPE. We should consider ourselves lucky that Wikipedia is featured so prominently in search results – for an example of a nightmare alternative universe, look at the situation of Wikivoyage, where an old inactive clone filled with ads (Wikitravel) regularly outranks it in search results. The only way I could see a nightmare scenario like that come to pass here is if, say, Google decided they wanted to create their own competitor to Wikipedia and then started prioritizing it in search results and luring contributors by paying them like Baidu Baike (the Wikipedia of China) does. Thankfully, they (wisely) don't seem to have much interest in doing that at present, but the WMF should have the back of their minds the need to make sure that that remains the case. {{u|Sdkb}} ^talk

22:17, 13 July 2020 (UTC)

We don't only allow reuse of our content, for profit or not, but positively encourage it. That's baked into the DNA of the Wikipedia. It's a terrible idea, it doesn't seem to do anybody except bad actors and parasites much good, and it's the seed of, not just our destruction, but the corruption of the database we've made -- because if they ever get in the mood, Google could fork the encyclopedia, monetize it, set up an organization to keep it improving, and downgrade us in search results. Amazon or some other large rich enity (including a foreign government) could do this too, except for that last part (unless they arrange it). But you don't need the last part if your product is better, which it might be.

It's only a matter of time, probably. There's nothing to be done about it, though. It is what it is. Herostratus (talk) 06:49, 14 July 2020 (UTC)

• I totally agree with the above there's not much to do about WP clones, especially with the WP content licence. However the interesting parallel is this: Wikivoyage (the official Wikimedia travel guide) was actually a fork of WikiTravel! Wikivoyage is the clone, and if I recall correctly was due to ads (or some sort of commercialisation) being placed on the Wikitravel content so the users decided to migrate. This is the benefit of the licence being used. - Master Of Ninja (talk) 06:54, 14 July 2020 (UTC)

• I'd disagree, firmly, with it doesn't seem to do anybody except bad actors and parasites much good - there's huge amounts of Wikipedia content being used by good faith actors, including individuals and organisations. There's also ongoing massive usage of Commons photos. As to the possibility of google (et al) forking Wikipedia - I've seen some rough estimates of suggested costing for trying to upkeep English Wikipedia if you were paying every editor. Trying to do it without advertising would be a nightmare, and I think they'd face some ludicrous amount of backlash. Probably a bigger issue is that they'd then be liable for all the ongoing edits made, and people would be way happier to C&D and sue Google (et al), because they might actually get something from it. Nosebagbear (talk) 10:41, 16 July 2020 (UTC)

Brandmeister, it should be noted that google for instance heavily punishes duplicate content in their rankings. This is why clones and mirrors will never score very high overall in their rankings. If we spent more time on writing good content and less on chasing things that we can't really influence, than we win. —TheDJ (talk • contribs) 11:08, 17 July 2020 (UTC)

I see your points. Hope this is indeed so. My issue was posing as Wikipedia and using its name to place ads which is rather different from fair license compliance for commercial purposes (e.g. in books and other publications for sale). Brandmeister^talk 11:23, 17 July 2020 (UTC)

If this site is actually posing as Wikipedia and using its name then it is in breach of rules about trade marks. Can you provide evidence that it is doing so?

Phil Bridger (talk

) 17:00, 21 July 2020 (UTC)

Qwe offers machine translated articles. For example Josh Robert Thompson in Dutch is a machine translation of Josh Robert Thompson. It's not very good, but I guess for some people it's useful. If Wikipedia stopped being freely licensed, I would quit. No point in contributing unpaid to that. I could just as well start writing for a site that pays its contributors. - Alexis Jazz 16:12, 21 July 2020 (UTC)

• I find it rather strange that editors are suggesting that the Wikimedia Foundation, which wants to rename itself to something including "Wikipedia" for commercial branding purposes to support its bloated bureaucracy, should have a monopoly of the content that we produce. As Alexis says above, that just turns us into employees of the Foundation, and as such we should be paid. It is certainly unusual for searches in English to turn up "bad actors" above Wikimedia sites, and I think that this was an exceptional case that shouldn't be used to drive policy.
  Phil Bridger (talk
  ) 16:55, 21 July 2020 (UTC)

In addition to that last point: we shouldn't allow Google search results to drive policy, whether the case is exceptional or not. - Alexis Jazz 03:04, 22 July 2020 (UTC)

Please see: Wikipedia talk:Requests for comment/Harassment solutions. EllenCT (talk) 19:22, 22 July 2020 (UTC)

The ability to mass move pages would be really useful for sports team renames, would you want it? — Preceding unsigned comment added by Another Wiki User the 2nd (talk • contribs) 20:45, 2020 July 23 (UTC)

Another Wiki User the 2nd, that would require a software change, and I think such functionality would be better as a userscript or gadget, rather than being implemented into MediaWiki itself, like other mass x scripts. Ed6767 talk! 23:54, 23 July 2020 (UTC)

We already have a tool that can do many automated tasks. It is called

autowikibrowser. An admin needs to grant you permission to use the tool first. Aasim

20:42, 24 July 2020 (UTC)

Also, you have to be an admin to use the tool to move pages, so... Aasim 21:31, 24 July 2020 (UTC)

The GS templates tend to get less love than the DS ones. It is proposed

The order on the left is no longer ordered by two-letter code as described at Wikipedia:Language order poll, and I can't find anywhere explaining how it's now ordered and why. It's really annoying and hard to find other languages. In other editions of Wikipedia the list is folded up which is even more annoying.--عبد المؤمن (talk) 21:30, 25 July 2020 (UTC)

This is an issue for

WP:VPT for the future. WP:Village pump (technical)/Archive 183#Tech News: 2020-30 documents that this is a bug and is anticipated to be fixed. --Izno (talk

) 21:43, 25 July 2020 (UTC)

See Wikipedia:Village pump (technical)/Archive 182#Sidebar language order changed? as well. {{u|Sdkb}} ^talk 04:56, 26 July 2020 (UTC)

I occasionally note that articles I have created or worked on have been translated into new articles on other language versions of Wikipedia. When new articles are created and linked to a page on my Watchlist, would it be possible to receive automatic notification?Roundtheworld (talk) 07:57, 25 July 2020 (UTC)

WP:VPT, since there are presumably some technical challenges to be figured out before this can be a concrete proposal. Personally, I find the Wikidata notices that show up in my watchlist sufficient, but it'd be nice to have the option to turn some things in one's watchlist into notifications. {{u|Sdkb}} ^talk

04:59, 26 July 2020 (UTC)

BrownHairedGirl has initiated this proposal at Wikipedia talk:WikiProject Categories#Organi[SZ]ations_category_redirects. Please keep all discussion there. Thryduulf (talk) 12:11, 26 July 2020 (UTC)

A great way to encourage very many new people to start contributing to WP (and prevent many from complaining about or even trying to sue WP) would be to change the off-putting, formal, bland, boring "From Wikipedia, the free encyclopedia" at the top of every page to something more welcoming and more informative, f.ex. "From Wikipedia, the free encyclopedia that its users make and are responsible for". --Espoo (talk) 09:07, 9 July 2020 (UTC)

I don't think it would discourage anyone actually wanting to sue WP, but it might bump up how many people want to issue legal threats at individual users. It also sounds like we are in aggregate legally responsible for the nature of the pages Nosebagbear (talk) 09:45, 9 July 2020 (UTC)

Can you think of something else that wouldn't cause those misinterpretations but is welcoming and informative? --Espoo (talk) 13:50, 9 July 2020 (UTC)

I guess I don't see what you are seeing with the existing line, nor do I see how changing it would accomplish the goal you have. 331dot (talk) 13:56, 9 July 2020 (UTC)

Correct me if I'm wrong, but didn't the slogan use to say "The Free Encyclopedia That Anyone can Edit?" Anyone know when/why the last part was removed? – Anne drew 14:11, 9 July 2020 (UTC)

Wow, long memory! Not since 2010... history of MediaWiki:Tagline. Cabayi (talk) 14:29, 9 July 2020 (UTC)

@Anne drew Andrew and Drew and Cabayi: The slogan on the main page still says "the free encyclopedia that anyone can edit", the tagline at the top of the page was only extended to the full thing for two days in 2010, and both before and since has been the abbreviated version. --Yair rand (talk) 20:41, 9 July 2020 (UTC)

It looks like there's already been lots of discussion regarding this many years ago - see MediaWiki talk:Tagline/Archive 1#"that anyone can edit" Ed6767 talk! 15:35, 9 July 2020 (UTC)

There was also a proposal in 2017 to say just "From Wikipedia"; it never got a ton of discussion. {{u|Sdkb}} ^talk 20:07, 9 July 2020 (UTC)

The tagline we currently use for the Main page is the

WP:SIDEBAR20, so this would be somewhat redundant to that. {{u|Sdkb}} ^talk

20:16, 9 July 2020 (UTC)

Having more than one link to the welcome tutorial wouldn't hurt anyone.

The main point is that the current tagline is what most readers see as the definition of what Wikipedia is (and even if some will glance at the left sidebar, even most of those will not see the future link to the tutorial in that list) and it misinforms them more than it informs them.

The most important thing they need to know is that this is just as much their encyclopedia as anyone else's and that we want to welcome them, not turn them off, and especially if they disagree with something they read on the page they're looking at.

The current tagline says nothing about that. Instead it says only 2 things about WP that are probably obvious to almost all readers -- that it's an encyclopedia and that it's free -- so it's a very sad waste of prime layout real estate and a very sadly wasted chance to inspire readers to become editors. In fact, since the word "free" confusingly has more than one meaning in English, this tagline even distracts the reader's attention from thinking about editing.

More specifically, the current tagline not only sadly wastes a great opportunity millions of times a week: it's off-putting, formal, bland, and boring. It makes readers think of Wikipedia as an institution that exists apart from them, something huge that exists like dozens of volumes of a traditional paper encyclopedia on a shelf. We need a more welcoming and more informative tagline. We probably don't even need to use the word encyclopedia and we probably need to say that comments on the discussion page are welcome and valuable:

Most people are afraid to edit articles due to language, content, and technical reasons and very confused by things most of us don't even think about like the wikitext markup and the very annoying habit of the first line of most articles being "hidden" by being without a free line after hatnotes and often many infobox lines. --Espoo (talk) 12:31, 11 July 2020 (UTC)

Espoo, I very much agree with this. My main concern is just keeping the tagline concise and streamlined, which is why I haven't expressed explicit support for any of the proposals so far. To reply to Blueboar below, yes, everyone knows that they could edit Wikipedia, but unless they're actively reminded of that fact, they're very unlikely to actually do so. We need to advertise if we want editing to be something that actually comes to mind. {{u|Sdkb}} ^talk 06:48, 12 July 2020 (UTC)

• Um... Wikipedia has existed for almost two decades now. An entire generation has grown up with it. I seriously doubt that there is a large pool of potential editors out there who don’t already know that our content is user generated and that “anyone” can contribute.

No, the real reason that we don’t have as many editors as we used to have is quite simple... there isn’t as much for new editors to do (the obvious topics have already been covered). And what still needs to be done isn’t as much fun. Blueboar (talk) 14:07, 11 July 2020 (UTC)

How about this for a radical idea:

• Long term editors organise the resurrection / reactivating of the many seemingly dormant projects.
• When a new editor submits their first draft article they are welcomed and mentored by a member of the relevant project.
• etc - you get the drift.

Downsize43 (talk) 21:56, 11 July 2020 (UTC)

Your idea sounds great Downsize43, Especially #2! W.K.W.W.K...ALL Lives matter FAQ 02:53, 12 July 2020 (UTC)

Great ideas, Downsize43, but they don't address the problem of people who don't edit despite reading something that is said in a clumsy or wrong way or that they know or are pretty sure is wrong.

Yes, most people know they could edit, but most don't dare to, don't know how to, find it too difficult or confusing, don't realize they could instead write on the talk page, weren't treated kindly when they once edited something, and other reasons.

Your suggestions mostly apply to readers who have already edited. Instead, we need to encourage and inspire the much larger number of readers who have never edited.

So, instead of "From Wikipedia, the free encyclopedia", how about something like this:

This is a Wikipedia article, so it's as reliable as its sources.

Help improve it by clicking here.

--Espoo (talk) 08:01, 12 July 2020 (UTC)

I don't think "This is a Wikipedia article, so it's as reliable as its sources." is an improvement. Dutchy45 (talk) 13:46, 12 July 2020 (UTC)

• I just want to point out that the tag line under discussion only appears at the top of a page if you are seeing it in “desktop view”... there IS no tag line (at all) when using mobile view. If the goal is to somehow attract new editors by changing the tag line, it will have limited effect. The cosmetic change won’t be seen by those using mobile devices. Blueboar (talk) 13:41, 12 July 2020 (UTC)

  Blueboar, I think it's appropriate not to have a tag line on mobile, where there is more limited space. But your point is definitely good to keep in mind. We've improved the way our introductory resources work on mobile a bunch recently, and there's certainly more work to do. {{u|Sdkb}} ^talk 17:54, 12 July 2020 (UTC)

Ok, ok, I know it's not an actual grammar rule that sentences shouldn't end in prepositions, but the above wording grates on my pedantic copy-editing self. I don't really think the wording as it stands is preventing anyone from editing. Retswerb (talk) 06:19, 14 July 2020 (UTC)

Maybe one day. We have done everything to show them they can edit the article. We have edit buttons at the top of each page. We have edit buttons in each section header. We have edit links in maintenance templates. Our front page says that anyone can edit it. It gets really repetitive and plus it prob will mess up with the horizontal layout. For now, I think the "From Wikipedia, the free encyclopedia" tagline is good. Aasim 08:10, 18 July 2020 (UTC)

Clickbait header. And the tagline is irrelevant. I know how newbies are treated. Very few users are capable of effectively helping newbies. Nearly everybody lacks the patience. So newbies run into walls and give up. The learning curve is still too high. That is partially a technical problem but mostly a community problem. Without good teachers, the learning curve will always be too high. - Alexis Jazz 01:26, 21 July 2020 (UTC)

The learning curve is too high because things are too complex, and unnecessarily so. Things are too complex because (1) the natural tendency is always toward more complexity, and (2) there is nothing in our system to prevent that from happening. Few editors understand the cumulative costs of complexity, but any editor can participate in the development of the site's infrastructure. Do that for 19 years and you end up with a monumental mess, which is what we have. If you want good bridges, you don't let just anybody design them. In short, the problem is intractable without a sea change in project philosophy and a major overhaul of our system, which seem highly unlikely. Learn to live with it. ―Mandruss ☎ 11:57, 21 July 2020 (UTC)

Mandruss, that's extremely well put. It dovetails with some thoughts I recently expressed about beginner accessibility of policy pages. {{u|Sdkb}} ^talk 09:26, 27 July 2020 (UTC)

• Oppose changes - I don't see how any of the above will improve project involvement. -Indy beetle (talk) 04:18, 22 July 2020 (UTC)

In two websites, StackExchange (URL) and Reddit (URL) there is a space called Meta to help the new-comers or settled users discuss the site features in the case of problem or just being curious; and also, teaching them how to use the site; also, it is possible to have main-site-unrelated content such as entertainment, etc. to be included in it. It can be helpful if we also have a look-alike feature here. Aminabzz (talk) 15:15, 2 August 2020 (UTC)

WP:TEA, so I'm not seeing much point. As for encouraging entertainment, it's not that we're all grouches here, but we have a different mission from StackExchange or Reddit. Both of those are commercial sites, and the bottom line is how many users, how many clicks, how much traffic. Our bottom line is writing an encyclopedia. -- RoySmith (talk)

15:30, 2 August 2020 (UTC)

@

The Teahouse, which is our dedicated forum for new users to seek advice and assistance. GMG^talk

15:52, 2 August 2020 (UTC)

Just to add to the negativity shown to your idea, the existing Village Pump pages and the Teahouse are already places designed for discussion about Wikipedia. The name is also problematical, as there is already a project called

Phil Bridger (talk

) 16:21, 2 August 2020 (UTC)

Have you ever gone to Special:Preferences and wondered whether to "Restore all default settings", only to realise you have absolutely no idea which ones you might already have changed, or which helpful Gadget or Editing settings you might lose if you did so?

A recent Teahouse discussion has prompted me to propose a long-held feeling that a User's Preferences page should indicate the original Default setting (whether enabled or disabled). Only that way can a user who has, over some years, tweaked their Preferences appreciate what they've actually activated or disabled, and what they see differently from a brand new user.

This seems a reasonable and obvious thing to propose, and with no disbenefits. Or is this better put forward as a broader cross-wiki suggestion at https://meta.wikimedia.org/wiki/Help_talk:Preferences ? Nick Moyes (talk) 20:15, 25 July 2020 (UTC)

• Strong support - although, this is a MediaWiki issue will probably be better suited for phabricator instead of here Ed6767 talk! 20:26, 25 July 2020 (UTC)
• Support this being done, wherever it needs to be requested. This is an obvious no-brainer case of bad design.
  Phil Bridger (talk
  ) 20:57, 25 July 2020 (UTC)
• The preferences pages can already be overwhelming. I don't think this would be a good idea. Starting a documentation of these defaults at e.g. Help:Preferences seems reasonable. --Izno (talk) 21:36, 25 July 2020 (UTC)

  Surely, some simple design ideas could resolve that concern? For example, items that are actively selected by default could be shown in bold. Hardly overwhelming. What I think is genuinely "overwhelming", is not being able to discern what was or was not once a default setting when looking at the Preference pages themselves . Nick Moyes (talk) 00:15, 26 July 2020 (UTC)

  Then you need to explain to both sighted and unsighted users what the bold means, and the latter group doesn't get anything for that besides some text to that effect, and the former still needs that to fit somewhere on the page in question. --Izno (talk) 00:37, 26 July 2020 (UTC)

  It can't be too much of an effort to append (default) to the end of default preference options? And it should look okay too from some tests I've done Ed6767 talk! 00:32, 26 July 2020 (UTC)

  On which resolutions? :) --Izno (talk) 00:37, 26 July 2020 (UTC)

  Personally, I'd rather to see them on the preferences page than on a separate help page (I'd more likely use MediaWiki:Gadgets-definition as a source of truth since it is more universal and I know that it won't be outdated). As for the page already being overwhelming, thoughts on the Wikimedia Commons approach of using a superscript "d" with tooltip (^d), along with a sentence at the top of the page that also explains what it means?  Hazard SJ  02:30, 26 July 2020 (UTC)

  Just noting that this is similar to what is done on Meta (different wording is used, and there is no sentence at the top of the page).  Hazard SJ  19:51, 2 August 2020 (UTC)

• Support per nom, assuming that it is implemented with good design that doesn't overwhelm the page. This request arose because we realized users who created an account prior to 2014 still don't have RefToolbar (the thing that allows you to click "cite web" etc.) enabled by default. Most big websites force new changes on all users, and while that wouldn't go over well here due to status quo bias from power users (i.e. ourselves), the least we should do is note when something has changed by marking the default. Personally, this would be useful for me since, even though I may not change any settings, marking the default would give me a cue as to when the appearance of something might differ from that of the average reader. {{u|Sdkb}} ^talk 04:49, 26 July 2020 (UTC)
• Support per nom and User:Sdkb. I've wondered about just what were the defaults myself. Regards, GenQuest ^{"Talk to Me"} 09:13, 26 July 2020 (UTC)
• Support. Then update Help:Preferences. Also link to Help:Preferences rather than MW:Help:Preferences. — GhostInTheMachine ^{talk to me} 09:56, 26 July 2020 (UTC)
• So there are a couple of ways to do this: (a) with a bunch of hacks to some of the labels, this would be local and would need to be done for each language a user may use - so I strongly oppose that in bulk (maybe for gadgets - since these are project-specific). phab:T70689 is already open to fix this mediawiki side, so I suggest anyone that wants this to be developed subscribe there and voice support. — xaosflux ^Talk 11:42, 26 July 2020 (UTC)

  Support for Gadgets - this is easy, and something that is actually directly an English Wikipedia on-wiki config. — xaosflux ^Talk 00:46, 1 August 2020 (UTC)

• Support A lot of support for this so far, I'll add my support with a slightly different twist. I have no plans to restore the defaults, but occasionally I will be in discussion with the new editor, and cannot recall whether some aspect e.g. automatic numbering of sections, is something they are likely to see or if it's something I enabled. (Not a great example because I do remember there are probably other examples.) I do have an alt account which probably has all defaults, but that's a bit of work to check on something.S Philbrick(Talk) 20:56, 30 July 2020 (UTC)

Currently on

• It is usually very active, and editors often encounter annoying edit conflicts
• ANI has over 1000 archive pages. This can make sifting through them all rather difficult, even with search, i.e. finding the archive through loads of results, scraping through them all, then finding the subsection (of which an archive can have many), then copying the permlink
• If a user wants to check on discussion for a specific case, they have to watch the entire page, meaning that their watchlist will likely be filled with irrelevant changes.
• ANI usually gets very long. This can make it harder to load on slower computers, and some bots or scripts may fail to edit it due to its often extreme length.

Due to these issues, I propose that a new subpage is made, either per thread, or per day on

• Support per nom, as this seems very reasonable, with the caveat that I'm not an expert in the technical functioning of these forums, so if there's some big downside I'm missing, feel free to discount my !vote. {{u|Sdkb}} ^talk 07:08, 22 July 2020 (UTC)
• Not going to happen due to the complexity. People who positively contribute at ANI won't want to click through to a hundred subpages and add them to their watchlist (and remove them after sufficient time to avoid the watchlist overhead). At ANI, people can search for a particular user name, article name, or date and quickly find all occurrences. That becomes a major undertaking with multiple subpages. Johnuniq (talk) 07:20, 22 July 2020 (UTC)
• Please don't. Johnuniq has it right. - Sitush (talk) 07:24, 22 July 2020 (UTC)
• It is not unusual for ANI to have spurious posts or vandalism; such pages would need to be deleted instead of merely reverted. 331dot (talk) 07:37, 22 July 2020 (UTC)

  Surely then that would be the benefit of having new daily pages for new threads then? You can still have the benefits of having shorter, more manageable pages, and also be able to revert vandalism as per usual then? Ed6767 talk! 10:19, 22 July 2020 (UTC)

  All users can revert vandalism; only admins can delete pages. This would make more work for admins (if each discussion has a page) with little tangible benefit. Daily pages would require people to follow more pages, and require more archiving, and be harder to manage, not easier. 331dot (talk) 11:00, 22 July 2020 (UTC)

• Oppose- Edit conflicts generally affect edits to the same subsection. That is, if I am editing section "User:blerpyface is a fink" and someone else is editing section "User:fnordbot is broken" simultaneously, we will not run in to an edit conflict. Those that do happen come from editing the same section, and that problem would affect individual pages as well. As for the archives, yes, there are over a thousand of them. So what? Will replacing 1,000 archives containing multiple sections with tens of thousands of individual pages be any better? No. This proposal seems to me to be a solution in need of a problem. Reyk _YO! 10:34, 22 July 2020 (UTC)
  • Edit conflicts usually come from editing adjacent lines. MediaWiki software does not care about sections when it's saving edits (and hasn't for 14 years now). WhatamIdoing (talk) 00:50, 7 August 2020 (UTC)
• There are problems presented here, but I'm not sure if these are the right solutions? Regarding edit conflicts, Reyk is correct. Regarding searching, AfD is easier because the title of the AfD always follows the title of the article being discussed, (give or take nth nomination). ANI sections follow no titling pattern, so searching won't necessarily be improved in that sense. I suppose it could be easier to identify relevant sections from Special:Search though. The third point is reasonable, I suppose. But is it significant enough that it's worthwhile reworking the system? Obviously noting that doing this will mean watchlisting ANI itself for updates to any section stops working. ProcrastinatingReader (talk) 11:18, 22 July 2020 (UTC)
• Oppose - whereas AfD pages are functionally all independent, AN & ANI threads branch, merge, move etc all the time. There is also more need to be able to move around the full set smoothly, though that's a lesser issue. I also feel that edit conflicts are already within sections anyway, so branching into pages would be problematic. Don't get me wrong, there are benefits, particularly making it viable to watchlist individual discussions where the whole page would overwhelm a watchlist. But I think the issues outweigh the positives. Nosebagbear (talk) 12:44, 22 July 2020 (UTC)
• Strong oppose - the main purpose of ANB is to get the attention of an admin. It is possible to get an email every time a page is edited (I do for some pages I watch). It is not possible to do this every time a subpage is edited created. Plus, most threads are very short (like "Can you please block X because they did Y" or "Can you delete the page X that I created on accident"). We do occasionally have long discussions, but those very few cases when we have long ANB discussions do not warrant putting individual discussions on individual pages. AfD, though, gets hundreds of nominations per day, which warrants individual pages for these nominations. Plus, some of these nominations can get a very heated discussion. For these reasons, I strongly oppose this proposal. Aasim 20:30, 24 July 2020 (UTC)
• Support trial - one ANI page per editor, like how SPI does it. I think that would make a big difference to how discussions play out and it would cut down on "repeat offenders". There could also be a "general/misc" page for the more minor matters that don't merit their own page. Something like this is worth trying out I think. ANI desperately needs a shake up; it's next to useless and has been for years. Levivich ^{[dubious – discuss]} 07:05, 25 July 2020 (UTC)

  As the Wheel turns... --Izno (talk

  ) 13:51, 25 July 2020 (UTC)

  Iztrue. Levivich ^{[dubious – discuss]} 14:26, 25 July 2020 (UTC)

  What would we name the equivalent of

  WP:LTA for this new AN? The naughty list? ProcrastinatingReader (talk

  ) 21:23, 28 July 2020 (UTC)

  • @Levivich: How would this work for threads that are about something other than the conduct of a single editor? Looking at some recent threads there are examples of:

    Boomerangs - these would be initially filed under the name of the reported user and then have to be resorted to under the OP's name (is that a good use of editor time?)

    A pox on both your houses - both the OP and the reported user are found at fualt (copy and paste? redirects?) - one ended up discussion the behaviour of about 5 editors in detail and peripherally others editing the MoS topic area.

    Article problems - mostly off-topic, but they are still posted there and would need dealing with

    Broadening discussions - an editor was indef-blocked but then discussion continued about possible general sanctions for the topic area. Nobody would find that in the future under the reported editor's name.

    Dynamic IPs - single editors editing from an IP range, that may or may not be used by other editors now or in the future (no allegations of socking were made). Thryduulf (talk) 09:44, 29 July 2020 (UTC)

    @Thryduulf:

    • Boomerangs, pox on both your houses - calling for a boomerang is common, an actual boomerang is still rare. But it's a feature not a bug that a user's ANI subpage would show if the user had been the subject of bad-faith or boomeranged reports, by collecting those reports in one place. It's useful to know at a glance whether an editor has been brought to ANI five times and it's closed boomerang or no action every time and this is the sixth. Same with a "pox on both your houses". If both editors have an ANI subpage, it can be cross-referenced, I suppose, but I think my view is just let it be filed under the reported editor's name. If one editor has many "pox on both your houses" threads with multiple other editors, that pattern will become very easy to spot... i.e., who is the common denominator. Not so with the current system.
    • Article problems, dynamic IPs - just use the main ANI page as we do now; no subpage for these; archive them as we do now.
    • Broadening discussions - feature, not a bug, that any broadening would have to be discussed in a new thread somewhere else and could not/should not/would not be discussed at a user's subpage (and thus not at ANI). For example, general sanctions should not be discussed at ANI, it should be discussed at the pump, it's a community-wide concern and these things shouldn't be decided by ANI regulars, who as we all know are a small and self-selecting subset.

    I think of this idea as having the main ANI page like normal, but we split off threads into sub-pages organized by reported editor where appropriate. That way, all the ANIs against Levivich go to WP:ANI/Levivich, and anyone reading it can easily see history - good, bad, and ugly. The main WP:ANI page can just have a link to /Levivich, and that can be archived like normal (3 days or whatever). People involved in a report against Levivich can watchlist /Levivich and not have to watchlist the main ANI page, which I think will generate broader participation.

    And to Izno's point above, this is still different in qualitative ways from the old RFC/U, e.g. in format and prerequisites.

    One issue I don't know if anyone's brought up yet is that if threads are on a subpage, they won't automatically archive, which means discussions won't just go stale and fall off. I'm not sure if this is a good thing or a bad thing, but it would be interesting to try and see how it goes, that's why I support a trial. Levivich ^{[dubious – discuss]} 07:53, 31 July 2020 (UTC)

• So, you want LiquidThreads or Flow, but with less functionality?--Jorm (talk) 15:12, 29 July 2020 (UTC)
• Support I know this has failed before, but I long for it. --Deepfriedokra (talk) 21:46, 30 July 2020 (UTC)
• Oppose I don't see how this would be particularly beneficial.
  LEPRICAVARK (talk
  ) 15:14, 31 July 2020 (UTC)
• Meh - I like the "per day" to be honest but on the other hand I don't really see a problem with what we currently have. –Davey2010^Talk 15:21, 31 July 2020 (UTC)
• Oppose For a few reasons:
  1. Less transparent on watchlists: you wouldn’t see the individual edits to the page on watchlists. I don’t currently WL the page, but when I did I only ever commented based on what I saw on my watchlist, not by visiting directly.
  2. More dramah; less just outcomes related to 1 above, as a consequence of less transparency and visibility, you’ll have a list of ANI regulars, many drama seeking, who serve as the main commenters on each page. This in turn will lead to less desirable outcomes since editors who otherwise might mellow the atmosphere and help achieve an equitable result won’t be commenting as frequently.
  3. RfC/U 2.0 RfCs on user conduct were made historical for a reason. Pages devoted to the behaviour of one editor are primarily going to attract their enemies and in turn lead to more arb cases since railroading leads people to seek review elsewhere. I’m aware there’s a recent trend to want a more active ArbCom on stuff that the community should be able to handle itself (ex. wikipedia:Arbitration/Requests/Case/Motorsports, recent calls for a SashiRolls case), but I personally think that community resolution is usually better.

I’m sure I could think of many more, but those were the three that came to mind first. As such, I’m opposing. TonyBallioni (talk) 16:19, 1 August 2020 (UTC)

I wonder how likely the watchlist problem is. Some other large Wikipedias have been doing this for years, and I don't think they've complained about never being able to find/watch the pages. WhatamIdoing (talk) 00:53, 7 August 2020 (UTC)

• Oppose Oftentimes, all that is needed at ANI is a short open and close issue that an admin sees and instantly knocks out. In fact that's a good majority of reports I'd say. Making it more like AfD is going to increase the bureaucratic factor, delay response times, and increase the amount of !votes. Plus I think it would make reports less newbie friendly. As is, people can barely figure out how to make a post and alert the person in question. Forcing them also to create a page with proper formatting and everything would make for a lot of extra maintenance on our end to fix malformed reports. Plus vandalistic reports would have to get deleted, instead of just reverted. I don't think ANI is currently unworkable either. The archives are long, but I search them easily all the time. Edit conflicts are usually on a per section basis anyway (if folks are editing the whole page, that's their mistake), and they'll still happen on subpages. I do concede that ANI grows large, but that alone is not sufficient reason to split it off into subpages; the negatives much outweigh any benefit. CaptainEek ^{Edits Ho Cap'n!}⚓ 17:45, 7 August 2020 (UTC)