Change 721108 had a related patch set uploaded (by Huji; author: Huji):

[operations/mediawiki-config@master] Temporarily disable anonymous editing on fawiki

https://gerrit.wikimedia.org/r/721108

@Urbanecm I asked you to review the patch from a technical perspective. If it looks right, and assuming this task is not blocked for any reason, I will then and only then move to the next step which is to schedule it for a Deployment window.

On meta, @Niharika suggested extending this to 6 months. This will not change our current state; we still need to schedule and deploy the existing patch. It will change when we will schedule and deploy the opposite patch.

see consensus

Seems a very limited discussion for such a momentous decision. The level of support is also less than overwhelming.

Is there a consensus from the global community on abandoning the founding principles? It seems we'd need a global RfC with a very strong consensus, if projects still want to call themselves Wikipedia while becoming something very different from what that has meant so far.

Didn't ptwiki just get this declined a few months ago in T261133 ?

Although they seem to be blocking anyway with AbuseFilter/180 (hidden filter!)

In T291018#7357317, @Xaosflux wrote:

Didn't ptwiki just get this declined a few months ago in T261133 ?

Not exactly a few months ago.

In short, it was rejected on Phab, the community implemented it using AbuseFilters (of note, fawiki did that recently too, but the filter gets throttled within hours), and ultimately WMF monitored its execution for a while and noted some good outcomes for that project (see https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Impact_report_for_Login_Required_Experiment_on_Portuguese_Wikipedia ) from which the recommendation was to also allow 2 other interested projects to try this restriction. So in a way, this task could have been written as: fawiki wants to be one of those 2 projects.

In T291018#7357317, @Xaosflux wrote:

Didn't ptwiki just get this declined a few months ago in T261133 ?

That was different. ptwiki wanted an indefinite ban which I declined.

fawiki wants a temporary ban for two months, that is something we have done before (e.g. there was a flood of vandalism because a story about vandalism in fawiki broke out).

This can go ahead for two months given that community consensus exists but the community can't decide that "it will be blocking all anonymous editing forever"

The sad thing is that some WMF people suggested to increase it to six months. The consensus was for two months.

noted some good outcomes for that project (see https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Impact_report_for_Login_Required_Experiment_on_Portuguese_Wikipedia ) from which the recommendation was to also allow 2 other interested projects to try this restriction. So in a way, this task could have been written as: fawiki wants to be one of those 2 projects.

Well, that report is bogus and has many many issues as I pointed out to some in the talk page.

I do understand it automatically solves a massive problem for WMF (IP masking) but that shouldn't be the ground to completely ruin the Wikis because it's hard to do it properly.

Note that proposal by @Niharika about making this a six-month plan is just a proposal. At this time, the confirmed plan is 2 months only.

@Ladsgroup Our intention is to monitor the metrics and understand the impact of the change. Two months is a short time -- we will not be able to gather any data on user retention impact. If I understand correctly, the community wants to capture some metrics and on the basis of that evaluate if they would like to keep this ban for longer than 2 months. With ptwiki our experience is that the metrics fluctuate a lot initially and we don't get a lot of clarity until after a few months when metrics stabilize. I would consider it unwise to make hasty decisions based on 2 months of data, when things may seem more positive that they are. If we can extend the experiment for a little while and get enough data that can help evaluate the impact of this change better, I would like us to do that.

Of course it is ultimately the community's decision.

In T291018#7358134, @Ladsgroup wrote:

Well, that report is bogus and has many many issues as I pointed out to some in the talk page.

I do understand it automatically solves a massive problem for WMF (IP masking) but that shouldn't be the ground to completely ruin the Wikis because it's hard to do it properly.

I take offense to the use of the word "bogus" here. We spent a lot of effort and time into that research. Never before has there been a blanket IP ban on a project of this scale. There have been some brief experiments in the past that have not had successful outcomes. Both of those experiments are 6+ years old and again, not on this scale. Please don't call the report bogus because you find it hard to agree with the results.

We are not shying away from the work that needs to be done for IP masking to happen. We are not imagining a future where all projects block IP edits and solve IP Masking for us. In fact I don't think most projects will block IP editing. But I don't see why we shouldn't support those project which really need to take this step because of the amount of vandalism they face on a daily basis.

In T291018#7354214, @Huji wrote:

@Urbanecm I asked you to review the patch from a technical perspective. If it looks right, and assuming this task is not blocked for any reason, I will then and only then move to the next step which is to schedule it for a Deployment window.

Hello @Huji, I am unable to offer any sort of support or guidance on this ticket. The request goes strongly against my interpretation of how Wikipedia should work (as you know, it is even noted in the founding principles, and I'm unwilling to volunteer my time to help something that I consider hurting (and dangerous) to the idea behind Wikipedia.

Thank you for your understanding.

In T291018#7363223, @Niharika wrote:

In T291018#7358134, @Ladsgroup wrote:

Well, that report is bogus and has many many issues as I pointed out to some in the talk page.

I do understand it automatically solves a massive problem for WMF (IP masking) but that shouldn't be the ground to completely ruin the Wikis because it's hard to do it properly.

I take offense to the use of the word "bogus" here. We spent a lot of effort and time into that research. Never before has there been a blanket IP ban on a project of this scale. There have been some brief experiments in the past that have not had successful outcomes. Both of those experiments are 6+ years old and again, not on this scale. Please don't call the report bogus because you find it hard to agree with the results.

I'm sorry I offended you. Let me explain my reasoning I hope it helps coming to terms on our disagreement:

• This report is not peer reviewed and published in a paper. Am I wrong?
• I kindly ask you to talk to researchers who has done work in this field before, yours truly wrote a paper on vandalism detection in Wiki projects and is quite familiar with the literature.
• This report flies on the face of consensus among researchers in this topic that "making editing harder hurts the growth of the wiki in the long run". Yes, there is not banning of IP editing in research but there are lots of proxies:
  • FlaggedRevs
  • Automated reverts (The famous "When the levee breaks" paper)
  • Forcing preview
  • etc.
• There is a famous paper about this: https://journals.sagepub.com/doi/10.1177/0002764212469365 and multiple papers later confirmed the result.
  • For example: https://mako.cc/academic/hill-almost_wikipedia-DRAFT.pdf which is linked in the page you linked: https://meta.wikimedia.org/wiki/Research:Value_of_IP_Editing
• There are several issues with the data
  • Your reports does not take into effect the impact of multiple lockdowns in 2020 and 2021 in Brazil and Portugal.
  • It seems there are issues with the comparisons that is not explained: https://meta.wikimedia.org/wiki/Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Impact_report_for_Login_Required_Experiment_on_Portuguese_Wikipedia#Apples,_oranges_and_herrings
  • You probably used "reverted" tag to determine if an edit is reverted or not. I have done lots of work on this and can guarantee that it's not a very reliable metric. That's why ORES had to use human labeling campaigns to determine if an edit was vandalism or not and couldn't rely on automatic revert detection. It has basically too much noise: People self-revert, people mistakenly revert, people don't intend to signal "it's vandalism" but revert for other reasons, e.g. restructuring, etc. etc. You can see the accuracy differences of "reverted" models (using auto-detection of reverts) and "damaging" models in ores (using human labeling). It gives around ten percent boost in ROC-AUC.
• Most importantly and above all, it doesn't take into account long-term effects of such changes. The report itself admits it and I personally think it should be limited to one wiki and if no long-term harm has been detected, move on to more. I humbly suggest you do this on ptwiki and continue measuring.

We are not shying away from the work that needs to be done for IP masking to happen. We are not imagining a future where all projects block IP edits and solve IP Masking for us. In fact I don't think most projects will block IP editing.

Thanks for clarification. I was told the IP masking is being deprioritized because the plan is to basically stop letting IPs edit. Possibly it was a miscommunication.

But I don't see why we shouldn't support those project which really need to take this step because of the amount of vandalism they face on a daily basis.

Well, I have to disagree on this. Did WMF in its entirety did something to support patrollers? The last projects I remember in this topic was PageTriage improvements (something only used in English Wikipedia) and RCFilters (3.5 years ago). Even basic tools we have in production atm are basically unmaintained including FlaggedRevs (T185664) and ORES. The RCFilters I just exampled is also on low-capacity maintenance and doesn't get feature requests. What do you think happens when there is no support from WMF to wiki patrollers?

There are lots and lots of tools we can build and there are lots of low-hanging fruits we can try before going to the nuclear option:

• Rolling out RC Patrol option in all wikis.
• Push (echo) notification of heavily damaging edits (= high ores confidence) to users that watched the page and enabled the option. There is a ticket for it, I can find it.
• Improvements on ORES vandalism detection models
  • e.g. self-training, using semi-supervised machine learning to improve its accuracy
• Helping automated bots get further than only English Wikipedia
• Automated protection of pages after certain ratio of reverts.
• Doing research on nature of vandalism and how it can be prevented or how we can empower patrollers.
• Wiring the growth home page to create more patrollers (we are currently focusing on newcomers becoming content makers, which is fine but a wiki also needs patrollers too).
• Prevention of heavily damaging edits using ORES or anything else (or wiring it to FlaggedRevs).
• Making patrolling much easier in mobile.
• Rolling out of StopForumSpam.

I would be more than happy to discuss the disagreements or any piece of my comment over a call or anything you prefer.

And don't get me wrong. I'm not 100% against banning IPs but I think if we want to do it, we have to do it the right:

• Link to create account must become more visible in the page error (possibly becomes a button)
• Our create account procedure sucks:
  • The password requirement is too strong (for a good reason tbh) but not everyone uses password manager that can create a random passoword for them and I don't think they would care enough to continue.
  • Our captcha is not a11y-friendly at all (of course there is a ticket for it). With this change we basically perpetuating an ablest bias in our volunteer base. Of course not intentionally.
  • There should be some sort of username suggestion mechanism
• Growth home page must become an state of the art and rolled out to all new users so it can compensate for the lost user retention but it also should not get in the way of the user who now has to create an account to make an edit in a certain article they planned to.

In T291018#7363246, @Urbanecm wrote:

In T291018#7354214, @Huji wrote:

@Urbanecm I asked you to review the patch from a technical perspective. If it looks right, and assuming this task is not blocked for any reason, I will then and only then move to the next step which is to schedule it for a Deployment window.

Hello @Huji, I am unable to offer any sort of support or guidance on this ticket. The request goes strongly against my interpretation of how Wikipedia should work (as you know, it is even noted in the founding principles, and I'm unwilling to volunteer my time to help something that I consider hurting (and dangerous) to the idea behind Wikipedia.

Thank you for your understanding.

I get it. My ask of you was merely to say if technically the code is written properly. Another user already reviewed the code so we are good for that.

I can see why @Niharika may take offense in your comments, @Ladsgroup.

• There are too many "you" and "your" references in your comment. In the words of WP:NOPA, you should comment on content, not on the contributor.
• You use a condescending tone, e.g. where you claim they did not talk to researchers who have done work in this field before.

I can we can do better here. Valid arguments won't go far if they are wrapped in an offensive language.

In T291018#7363403, @Huji wrote:

I can see why @Niharika may take offense in your comments, @Ladsgroup.

• There are too many "you" and "your" references in your comment. In the words of WP:NOPA, you should comment on content, not on the contributor.

My comment has around ~800 words and has only ten "you" and "your"s in it. One is an apology, one is referring to myself as "yours truly", one is "I *humbly* suggest you", one is "I *kindly* ask you", one is "whatever you prefer"

• You use a condescending tone, e.g. where you claim they did not talk to researchers who have done work in this field before.

that was not my intention. I let Niharika decide on the second comment.

I can we can do better here. Valid arguments won't go far if they are wrapped in an offensive language.

There is not an offensive language happening here. I tried to be as detailed as possible with my criticism of the work done. I let others decide.

Let's agree to disagree.

I particularly expect those of us who are members of the Code of Conduct Committee to show an exceptionally high degree of respect and civility.

In T291018#7363223, @Niharika wrote:

In T291018#7358134, @Ladsgroup wrote:

Well, that report is bogus and has many many issues as I pointed out to some in the talk page.

I do understand it automatically solves a massive problem for WMF (IP masking) but that shouldn't be the ground to completely ruin the Wikis because it's hard to do it properly.

I take offense to the use of the word "bogus" here. We spent a lot of effort and time into that research. Never before has there been a blanket IP ban on a project of this scale. There have been some brief experiments in the past that have not had successful outcomes. Both of those experiments are 6+ years old and again, not on this scale. Please don't call the report bogus because you find it hard to agree with the results.

We are not shying away from the work that needs to be done for IP masking to happen. We are not imagining a future where all projects block IP edits and solve IP Masking for us. In fact I don't think most projects will block IP editing. But I don't see why we shouldn't support those project which really need to take this step because of the amount of vandalism they face on a daily basis.

Thank you making it clear to members of other wikis that the statistics compiled by WMF about ptwiki are reliable.

I saw that the ptwiki experience was cited several times in this topic to discredit our results. It's curious that people who have never actually edited on ptwiki even question the IP ban since the positive effects are clearly visible.

I support the self-determination of projects and therefore I consider that fawiki has the legitimacy to request the ban. However, as a way of evaluating statistics on user retention, I also think it's appropriate keep this ban for longer than 2 months.

@Niharika the restriction will only apply to the main (article) namespace. Do you still think it would provide a good set up for the evaluations you had in mind, and justify the extension to 6 months? If anonymous users can still comment on talk pages, etc. some of the metrics you were considering like attrition may not change as drastically even in 6 months.

In T291018#7358134, @Ladsgroup wrote:

the community can't decide that "it will be blocking all anonymous editing forever"

Who says that? You...? And please, stop misnaming IP edits as "anonymous". They are nothing of that. Quite the opposite, indeed.

In T291018#7373338, @DannyH wrote:

There are some questions here about the WMF's intentions and about the process we're using. I can try to explain why WMF Product is interested in learning more about blocking IPs.

This project came about because we heard that Portuguese WP was blocking IP edits, and the question was: Should we do something to stop them? We've had some experiences in the past when the WMF unilaterally blocked or undid something that came from a community consensus without trying to listen and understand, and the outcome is never good. In this case, we decided to use this as an opportunity to learn more. We do know about Aaron Halfaker's paper, Mako's paper and the founding principles. But this was an opportunity to find out whether turning off IP edits actually destroyed a wiki community or not.

Why do we want to know more about IP edits? Because the internet is changing right now, and it's likely that over the next few years there will be more and more restrictions on our communities' abilities to access IP information.

One reason is that laws and standards about data privacy are changing, which led us to work on the IP masking project. Another reason is that the big tech companies have decided that IP addresses and useragents are personally identifiable information, and they're adding privacy and security features that mask IPs. Chrome started delivering fake useragent info late last year. Apple is adding a new feature in iCloud that offers a shared IP address. Once one of the big companies starts doing that, it is likely that other companies will follow. An "opt-in" feature can become an "opt-out feature" and then a new standard pretty quickly. There are also services that allow people to use an IP address that automatically changes once a minute.

The WMF doesn't have any control over that trend, or any way to influence it. It's just a thing that's happening. There is a good chance that over the next couple years, IP addresses just *stop working* as a way to identify vandals and sockpuppets. We'll get masked, shared or false IPs from major browsers and devices, and long-term abusers will have access to services that mask their IPs.

If someday IP addresses become completely unreliable for people who are using all the major browsers and devices, then turning off unregistered editing might be the only option that we have, to allow wiki moderators to stop vandalism and abuse. I don't know if that will be necessary, but it's certainly possible, so we want to learn as much as we can now.

We didn't set Portuguese WP up as a proper experiment, with a control group and long-term study. We looked at a situation that was already happening, and decided to do some stats analysis and see what we could learn. As we wrote in the report, so far we haven't seen results that look particularly damaging. New editors still join the project. Retention numbers went up. Nothing is immediately on fire.

The data that we collected is not a real experiment, so there are things that we couldn't control, like the effect of the covid lockdowns. We don't feel that this one example is enough to say "every wiki should be able to shut off IP editing if they want to". It's clearly not enough.

What we're saying is: let's try this again, with a couple more wikis. Let's see if we get the same kind of results or not, and whether it makes us more or less confident in the idea. Meanwhile, we're going to keep looking at the Portuguese stats, to see what happens over a longer period of time.

So we want to try this again, on a limited basis, looking at a couple more examples. We think that having at least six months of data would make us feel more confident about the results that we see. It's helpful for us if a particular community has already decided that they want to try this out, because we can watch and learn without overturning a community consensus. If the Farsi community is volunteering to do this, then we would like to use that opportunity to learn some more.

Sorry for the super long post. I'm happy to talk more if folks have more thoughts or questions.

In T291018#7364042, @Huji wrote:

@Niharika the restriction will only apply to the main (article) namespace. Do you still think it would provide a good set up for the evaluations you had in mind, and justify the extension to 6 months? If anonymous users can still comment on talk pages, etc. some of the metrics you were considering like attrition may not change as drastically even in 6 months.

I think it will still be more helpful, yes. I don't have metrics on this at the moment but I believe we see far more unregistered editing on the main namespace than on other namespaces. That may impact retention, even though not a lot.

In T291018#7373526, @Reedy wrote:

In T291018#7373338, @DannyH wrote:

There are some questions here about the WMF's intentions and about the process we're using. I can try to explain why WMF Product is interested in learning more about blocking IPs.
[...]

I'm sorry, but I have to ask: why in the world did you remove Danny H.'s comment and then repost it as a quote?

@Dcljr - I'd mentioned something that might have been security related, so Reedy deleted and reposted a slightly redacted version. The rest of my comment stands. :)

I was surprised to see that too, @DannyH but was not sure what to do about it. I think @Reedy did the right thing

In T291018#7363981, @Erico wrote:

I support the self-determination of projects and therefore I consider that fawiki has the legitimacy to request the ban.

In T291018#7363186, @Niharika wrote:

@Ladsgroup ...Of course it is ultimately the community's decision.

Wikimedia movement policy does not get to be decided by fiat at Phabricator. Important changes to policy that may have a far-reaching impact on the overall growth and/or quality of the encyclopedia content can only be made by consensus. Parts of this discussion are are reminiscent of the developers' unfortunate attitude at Bugzilla to the en.Wiki's overwhelming 2011 consensus for ACTRIAL as en.Wiki volunteer @Scottywong will remember well. (@Niharika was involved with the 2017 ACTRIAL project and her comments here should be given full weight and not dismissed with insults).

Six long years later in 2017 the en.Wiki threatened to use local filters to address the huge patrol system backlogs. Newer senior WMF staff took note, acquiesced, and even offered excellent support for a trial. This was a rare example of how the communities and the WMF can collaborate to resolving conflicting opinions with bare facts drawn from scientific research and a trial based on a series of hypotheses.

The actual trial lasted six months. The WMF's full post-trial report, by @DannyH , @kaldari, and @Nettrom was conclusive and a further RfC held by the en.Wiki closed with nearly 90% support for the permanent roll-out of Wikipedia's biggest policy chance since its inception.

Most importantly, a new level of trust and confidence in the WMF was established by the en.Wiki community and the Community Tech team led by DannyH went on to greatly improve the software extension used for 'New Page Patrol'.

Wikipedia/Wikimedia is organic and as demonstrated by ACTRIAL some of its earlier well-intentioned policies are no longer a good fit for today's situation. In the light of the proposals for IP cloaking, sooner or later the en.Wiki will debate and vote on the banning of editing by IPs. Based on the learnings from ACTRIAL, it will almost certainly take the form of a debate for a trial, one that will be spread over a long enough sample period which will be compared with stats established from a preceding sample period of the same length.

There is no knowing what the results of such a debate for a trial would be. Evidently opinions will be a conflict of ideology vs pragmatism, but the message here is that neither Phabricator nor the WMF get to mess with the clear wishes of the encyclopedia communities. Recent attempts to do so have led to a disastrous renewed decay in WMF-Community relations. It never ceases to amaze me why the WMF and/or its developer group is prepared to take these risks. In the worst case scenario, as has happened before, dozens of Wikipedia's most active administrators will stage a walkout and that would be the end of all quality control as we know it. The movement's sole capital is the vast army of unpaid volunteers who provide the content and manage it, attend meetings and conferences, and carry out the indispensable outreach work - all without any form of compensation.

In T291018#7363323, @Ladsgroup wrote:

In T291018#7363223, @Niharika wrote:

In T291018#7358134, @Ladsgroup wrote:

Well, that report is bogus and has many many issues as I pointed out to some in the talk page.

I do understand it automatically solves a massive problem for WMF (IP masking) but that shouldn't be the ground to completely ruin the Wikis because it's hard to do it properly.

I take offense to the use of the word "bogus" here. We spent a lot of effort and time into that research. Never before has there been a blanket IP ban on a project of this scale. There have been some brief experiments in the past that have not had successful outcomes. Both of those experiments are 6+ years old and again, not on this scale. Please don't call the report bogus because you find it hard to agree with the results.

I'm sorry I offended you. Let me explain my reasoning I hope it helps coming to terms on our disagreement...

@Ladsgroup would you mind cross-posting this comment on the ptwiki report talk page? We've hijacked this ticket long enough. I would love to discuss the specifics of the report further and learn how we can do better.

@Ladsgroup @Urbanecm @Nemo_bis I'm tagging you as the participants to this discussion who most vocally rejected the change, but this message is aimed at all members of the technical community who support anonymous editing. I am on the same page as you on this, *strongly*, but...

1. This is not something that a community came up with and just now spreads through other communities. The idea has floated around for as long as I've been a contributor (and I've joined in 2005...) in all the projects I edited. As the growth slowed (or even stopped, for some projects) the idea gained more traction, to the point were some patrollers mass revert anonymous edits just because of a typo in one edit. This makes the proposal worthy of close scrutiny through research and community consultation.

2. Changes in how ips are used, reused and misused are real. Back in 2001 IP block transactions were a fraction of the market they are now. I'm not even sure the ipv6 privacy extentions existed at the time. Also, the founding principles do not mention IPs anywhere.

3. I don't see any effort on providing communities with alternatives. People will want what they know it's possible, rather than asking for things that require development time, which the communities rarely get.

My suggestion would be to look for (and work on or lobby for) short term alternatives that might encourage communities to continue allowing anonymous editing by addressing their concerns around traceability of vandalism. One idea that comes to mind is allowing communities with functional ORES support to prevent saving the most problematic edits (T120741 might cover this). I'm sure Phab has a lot more such ideas that would move the discussion from "closing the gate" to "triaging the visitors". We can push for some of those ideas during the upcoming community wishlist survey.

I don't know if you saw it but I listed around ten options that would help:

In T291018#7363323, @Ladsgroup wrote:

• Rolling out RC Patrol option in all wikis.
• Push (echo) notification of heavily damaging edits (= high ores confidence) to users that watched the page and enabled the option. There is a ticket for it, I can find it.
• Improvements on ORES vandalism detection models
  • e.g. self-training, using semi-supervised machine learning to improve its accuracy
• Helping automated bots get further than only English Wikipedia
• Automated protection of pages after certain ratio of reverts.
• Doing research on nature of vandalism and how it can be prevented or how we can empower patrollers.
• Wiring the growth home page to create more patrollers (we are currently focusing on newcomers becoming content makers, which is fine but a wiki also needs patrollers too).
• Prevention of heavily damaging edits using ORES or anything else (or wiring it to FlaggedRevs).
• Making patrolling much easier in mobile.
• Rolling out of StopForumSpam.

These ten options are not based on a pragmatic approach. Nor are they tailored to the workings of all the Wikis. The the idea of abolishing IP editing stems from a cold look at today's reality in which a vague founding ideology is now a poor fit - an anachronism. The 10 proposals would integrate well in an editing environment already devoid of IP edits but which, such as the en.Wiki, still has more sinister demons to slay than simply vandalism.
The 10 points also involve significant development time and costs without any proof that the measures would in fact work. It is also highly unlikely that creating more reviewers / patrollers will happen. Existing patrollers have all the power they need and will not agree to a larger workload at the whim of the paid staff. Most users who take their patrolling seriously will not be newbies or doing it from a mobile device.
ORES has been rolled out on en.Wiki and does a good job, but AI is limited. What the reviewers and patrollers do needs human instinct and cannot be supplanted by filters, scripts, and bots.

I'll go even further than @Kudpung : most (8 out of 10) of these solutions are patches to the existing system, which the other side considers broken. What these people want is not to get and/or do work more effectively, by being able to patrol on mobile or receive echo notifications, but for the bad edits to *dissappear* from their watchlist so they have less patrolling work and implicitly more time for other activities on-wiki. Here is one of the feedbacks from pt.wp which resonates particularly well with what I am told when I try to calm down overzealous patrollers on ro.wp:

It certainly wasn't a decision we were happy to make, but my watchlist has never been so peaceful, and lately I haven't even been able to look at it all the time like a few months ago. IPs now do a bit of fun on the contact pages, but it's a side effect that I see no escape from.

We need to do more towards reducing the number of actions required from a patroller by having automatic filters in front of them. Whether that is the registration or something else is a choice that we need to create, as it does not exist at this point. I realize this probably needs a fair amount of development and I don't know who needs to analyze and prioritize these issues and the proposed solutions, but in the no-action scenario I expect more and more communities to ask for this in the coming years.

This discussion her has been sidetracked a lot.

Quick reminder #1: This task is about a temporary restriction on IP editors for editing in main namespace only. They can edit article talk pages and all other namespaces as before.

Quick reminder #2: I have scheduled this for deployment tomorrow (Tuesday) in the UTC 23:00 time slot. I know @Urbanecm hesitated to be the deployer (though this was back when the task was incorrectly described as impacting every namespace). I am counting on @Catrope who also will be on during that deployment window to be the deployer.

Quick reminder #3: Based on recommendation from @Niharika and consensus on fawiki, the temporary restriction will last for 6 months (as opposed to the originally proposed 2 months) and T292781 will be used to conduct careful analyses during and after this six-month period which we hope can help both fawiki and other wikis understand the implications of this temporary restriction and decide whether/when/how to (re)implement in future.

Update:

In T292781#7418252, @Niharika wrote:

@4nn1l2 I have pinged Tim Starling and he has volunteered to help with the backport and deploy. I see that @Huji has listed this for deploy tomorrow. If it doesn't get deployed then Tim can step up.

Between Roan and Tim, we will hopefully find a path to deploy this.

@Niharika unfortunately @Catrope did not join for the backport window today/tonight and Martin has previously expressed he doesn't want to deploy this so we will need Tim's help as you stated in your comment that I quoted above. Let me know if I can help in anyway, though this is pretty straightforward to test and Tim can test and deploy himself.

@Huji who is 'Martin'? For the benefit of all participants who are not privy to the cliques of devs, could we please stick to user names? Thanks.

In T291018#7422212, @Kudpung wrote:

@Huji who is 'Martin'? For the benefit of all participants who are not privy to the cliques of devs, could we please stick to user names? Thanks.

@Urbanecm

@Kudpung point taken. It is just that I have benefited from @Urbanecm 's support and advice so often that I referred to him by his (publicly known) name. But I should have used an @ reference.

@Huji No worries 🙂

Change 721108 merged by jenkins-bot:

[operations/mediawiki-config@master] Temporarily disable article editing by anonymous users on fawiki

https://gerrit.wikimedia.org/r/721108

Mentioned in SAL (#wikimedia-operations) [2021-10-20T23:27:21Z] <tstarling@deploy1002> Synchronized wmf-config/InitialiseSettings.php: fawiki require login to edit main namespace T291018 (duration: 01m 04s)

Mentioned in SAL (#wikimedia-operations) [2021-10-20T23:29:25Z] <tstarling@deploy1002> Synchronized wmf-config/CommonSettings.php: fawiki require login for creation of pages in the draft namespace T291018 (duration: 01m 02s)

Stumbled upon this months after the fact, but I was so startled by one user's comments that I just wanted to add a brief comment for posterity:

@Ladsgroup - quite frankly, who cares about your opinion on a request such as this one? You're just a developer. You're a database architect. Know your role and stay in your lane. You don't get to unilaterally veto the consensus of an entire project because you disagree with their idea. Imagine the ego you'd need to have to think that at the ripe old age of 28, you know better than an entire community who is living with these problems on a daily basis. WP projects aren't governed by adolescent developers that just started their careers a few years ago. If you want to influence the course of an individual WP project and its individual editing policies, join that project as a volunteer and participate in the discussions there with the rest of the editors. But don't swoop in at the 11th hour and tell well-meaning editors that their ideas are "bogus" and you refuse to implement them despite consensus. If there's a technical reason that a request can't/shouldn't be implemented, then let's hear about it. But if you just personally disagree with the request, frankly no one cares, and this isn't the place to voice your disagreement. Here, you're a coder, not a member of the community that you're helping to maintain. Go do your job and code, and save your opinions for someone else.

@Ladsgroup - I may not have been quite so blunt, but concur with @Snottywong, who with others and myself are still smarting from the disgusting behaviour of the WMF at Bugzilla several years ago when they told us, with personal attacks, that they would refuse to 'allow' ACTRIAL. Fortunately a couple of years ago, a new breed of director-level devs not only agreed such a major policy and change of principles is a local Wikimedia remit, they even provided extensive help to implement the trial, and excellent stats which fully proved the WMF's earlier conjecture to be totally false.
You may be an admin here, but you don't get to unilaterally decide what the major Wikipedia projects can and cannot do, especially when it concerns a good faith, but totally anachronistic piece of 'Founding Principle'. Such an attitude on en.Wiki would get an admin quickly stripped of their rights.
The Universal Code of Conduct was very recently accepted at its voting (by a small majority), some of us don't like it, but now is the time to uphold some of its values.

Hello,

We would like to remind all discussion participants here that a Code of Conduct applies in all Wikimedia technical spaces, including Wikimedia Phabricator. While we support a free discourse, moving discussion to a personal level never contributes to having a friendly and productive working environment.

Please help to make Wikimedia Phabricator a happy place for everyone to collaborate.

Thank you for your understanding.

Sincerely,
Martin Urbanec (@Urbanecm), Code of Conduct Committee.

@Ladsgroup is a member of the community already. He even works closely with users from all projects, including enwiki checkusers. I can't find where he said that someone's ideas are "bogus", but I can clearly see the personal attacks directed at him and I agree with Martin that it's time to stop. This task is closed.