Wikipedia talk:Requests for comment/Protect user pages by default

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.

Closure

Jc37 - would you elaborate a bit more on your closing statement - we need to be specific to turn this in to a phabricator ask. Some items to clarify:
  • Does this change apply to the entire User: namespace or only base userpages?
  • Does this include User:x.x.x.x pages belonging to IP users?
  • Does this include User: pages not associated with registered users?
  • Can non (auto)confirmed users still edit their own userpage as an override?

Thank you, — xaosflux Talk 02:03, 5 October 2016 (UTC)[reply]

Thanks for the note xaosflux : )
As you probably know, I may at times possibly have a tendency to be a bit verbose : )
I was trying (albeit apparently unsuccessfully) to avoid that here.
My apologies.
To try to address your 4 questions:
  1. base, per the proposal.
  2. a very good question. While this is technically user: , I don't see this specifically addressed in the rfc, or on the meta proposal anywhere. I may have missed it, but I don't see anyone discussing this either. So I don't think that this rfc grants consensus for that (no prejudice against a follow-up rfc on that, of course).
  3. I presume you mean such as due to creation or due to page moves (e.g User:jc37IsEvil or some such). As the stated goal of this proposal was to reduce harrassment, then, yes, this is implied in the proposal, and was somewhat referred to in the discussion, and some of the edits noted (such as the reference to WoW). You didn't specifically ask, but this also implies that "edits" includes "moves". The proposal seemed to blur the terms when referring to harrassment whether the edit was an actual "text edit" or whether it was due to page move vandalism/harrassment (as any of us may do when discussing these things). So for clarity, the proposal and discussion includes semiprotection against "moving" userspace base pages when referring to "editing". And indeed, I was including that in the close.
  4. yes, per the proposal, and as was noted in the discussion.

I hope this helps clarify. Thanks again : ) - jc37 08:54, 5 October 2016 (UTC)[reply]

@Jc37: I'm unable to understand your third point. To move a page, one needs to be autoconfirmed to do so, so the proposal to raise the edit protection level to autoconfirmed would not affect page move vandalism possibilities. — Andy W. (talk) 15:32, 29 October 2016 (UTC)[reply]
Copied from user talk:jc37

Hi Jc37, may you elaborate on your closure reasoning at Wikipedia:Requests for comment/Protect user pages by default (possibly not here but at the RfC page)? Did your closure essentially endorse Option 2? Were the arguments for Option 2 stronger than those for Option 1 or 4? And should we forsee some technical changes in the software at some point? Just wondering — Andy W. (talk · ctb) 00:40, 5 October 2016 (UTC)[reply]

Sure.
This set of RfCs had several questions: first is there consensus to autoprotect in some way, and then following that, to what "level"? User self-toggling being an additional question.
Noting that protection on Wikipedia is by tradition, usage, process, and policy, treated as an "increasing scale".
So, as I noted, overall, there was consensus for protection. Based on the whole discussion, there was consensus for more than just the IP protection of 1.5, but while at least semi had consensus, there wasn't consensus to go to 3. And there just wasn't enough support for user toggling for it to have consensus.
(and incidentally, please remind me to think twice before closing one of these first choice/second choice RfCs again. Assembling who likes what can be arduous in due diligence. Ah the things we do for Wikipedia : )
As for software changes, my read of the proposal is that this RfC concerned implementation of a meta proposal to implement this change.
From the RfC proposal: The exact time and resources required for any programming changes need to be determined. - presumably at meta. See meta:Grants:IdeaLab/Protect_user_space_by_default.
Anyway, I hope this clarifies : ) - jc37 09:20, 5 October 2016 (UTC)[reply]
As proposer of this RfC, thanks for the clarification. Pinging I_JethroBT on next steps to take as I will not be coordinating or making the programming changes myself. Funcrunch (talk) 17:11, 5 October 2016 (UTC)[reply]
@Jc37: Thanks for your responses, and also to Xaosflux for posing the clarifying questions. I think the next step here is to create a phabricator task as xaosflux has suggested. I can get that started next week after I return from WikiConference North America. There are also some volunteer and WMF staff developers I'd like to reach out to to see if they are interested / able to work on this task. I JethroBT drop me a line 03:02, 8 October 2016 (UTC)[reply]
phabricator:T149445 --MZMcBride (talk) 13:40, 29 October 2016 (UTC)[reply]

Hi jc37. Based on numerical counts alone, option 1 (no change) was the winner, correct? It received more supports than any other option, as far as I can tell. And yet you found consensus to uproot longstanding Wikipedia policy based on what? --MZMcBride (talk) 13:35, 29 October 2016 (UTC)[reply]

@MZMcBride: I believe the close by Jc37 does not reflect consensus at the polls (personal opinion, but I believe the immediate feedback after the closure suggests that many editors feel the same). I believe this is being brought up at the meta grants talk page and questioned on the ticket. — Andy W. (talk) 15:30, 29 October 2016 (UTC)[reply]
You could perhaps organize a new RfC polling using the Condorcet method to allow participants to sort the different options by order of preference. That will be a lot clearer for closure. --Dereckson (talk) 22:21, 29 October 2016 (UTC)[reply]
@
WP:CONSENSUS: Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. It could be that the quality of the arguments is better for one option than the other, although I'll admit I haven't read through this discussion recently. — Gestrid (talk) 04:41, 30 October 2016 (UTC)[reply
]
Notified Jc37 on their userpage (in addition to the numerous pings I suspect they've received, but they haven't edited anywhere since October 5. It could be awhile before we get an answer. — Gestrid (talk) 04:49, 30 October 2016 (UTC)[reply]
I apologise for not seeing this sooner. I had thought this was resolved already.
I explained the close above, but if I may guess, I think I understand the confusion. If one were merely to look at this as several individual sections, look to see which had the highest auto #, they might think that the first section was the result.
As Gestrid noted, we don't determine consensus that way here (as I presume you all know?)
My guess is that, due to being busy with other things, the commenters above didn't take the time to note that these were not all the same people commenting in each section.
So with that in mind, I'll copy what I said above:
This set of RfCs had several questions: first is there consensus to autoprotect in some way, and then following that, to what "level"? User self-toggling being an additional question.
Noting that protection on Wikipedia is by tradition, usage, process, and policy, treated as an "increasing scale".
So, as I noted, overall, there was consensus for protection. Based on the whole discussion, there was consensus for more than just the IP protection of 1.5, but while at least semi had consensus, there wasn't consensus to go to 3. And there just wasn't enough support for user toggling for it to have consensus.
And while there's more to it than that, if all you're currently interested in is vote counts, then please feel free to count up the number of individuals (and this includes the discussion, not just the numbered "!votes") who supported protection of some kind, and those who didn't. Even that way, this should be fairly obvious.
I hope this helps. - jc37 18:15, 6 November 2016 (UTC)[reply]

Filter notice

Hey folks. After a discussion over at the Phabricator task I started after this RfC (T149445), MusikAnimal developed a filter that accomplishes the requested changes in a manner that does not require any changes to the underlying code for page protection. The filter, therefore, seems like a better approach here. MusikAnimal and I wanted some input on a custom notice that will be displayed to editors who trigger the filter. Here are a few suggestions we've come up with:

  • Sorry, due to ongoing disruption, new users are not allowed to edit the userpages of other users. If you have a contribution you'd like to make you can ask that it be made on their talk page.
  • An automated filter has identified this edit as potentially unconstructive. Unregistered and new editors are not permitted to modify other editors' userpages. Requests for changes can be made on the editor's talk page.

Other suggestions or revisions to the above options are welcome. Some examples of edit filter notifications can be seen here. Thanks, I JethroBT drop me a line 15:47, 28 November 2016 (UTC)[reply]

How about:
  • An automated filter has prevented this change. Unregistered and new editors are not permitted to modify other editors' userpages. Requests for changes can be made on the editor's talk page.
It leaves out the suggestion of bad faith. — xaosflux Talk 16:08, 28 November 2016 (UTC)[reply]
Good point, I support that kind of messaging. I JethroBT drop me a line 16:17, 28 November 2016 (UTC)[reply]
I prefer the wording xaosflux suggested. Glad this project is moving forward! Funcrunch (talk) 16:48, 28 November 2016 (UTC)[reply]
That should stop an IP or an newbie from vandalizing my userpage. I kinda support the change to a new edit filter. KGirlTrucker81 huh? what I'm been doing 16:57, 28 November 2016 (UTC)[reply]
I would suggest we define "new editors" within the notice. Is that editors who are not autoconfirmed? Also, can we somehow link to the talk of the editor they tried to edit? Most new users won't know what a talk page is. — Gestrid (talk) 17:26, 28 November 2016 (UTC)[reply]
A link to
Help:Using talk pages should provide enough info for folks who aren't familiar with talk pages. I JethroBT drop me a line 18:09, 28 November 2016 (UTC)[reply
]
I concur that xaosflux's version is clearer. The simpler, less obfuscated, the better, especially for new users. "potentially uncostructive" etc. is a mouthful weasel. I would even address the user directly "You cannot edit this page as you are an unregistered or a new editor. If you indeed need to add something, ask for permission on the other editor's Talk Page". Zezen (talk) 17:30, 28 November 2016 (UTC)[reply]
I wonder if we should say "persistent vandalism" instead of "ongoing disruption". As "ongoing disruption" sounds like a temporary attack rather than a more or less permanent condition, IMO. Kaldari (talk) 18:01, 28 November 2016 (UTC)[reply]
I don't think we need to explain why the community created this restriction in the filter notice. Perhaps write this up in the protection policy (which this is basically a new form of protection) and wiki link to it. — xaosflux Talk 18:08, 28 November 2016 (UTC)[reply]
Agreed - the notice to the anonymous/new user should be as simple and straightforward as possible. Wikipedia:Protection policy and Wikipedia:User pages will indeed need to be updated to reflect the changes once they are implemented, and those pages can link back to this RfC for an explanation. Funcrunch (talk) 18:15, 28 November 2016 (UTC)[reply]
I agree with the shorter notice. However I think a "more details" would be useful, in case any users want to find out more about it for whatever reason - "An automated filter has prevented this change. Unregistered and new editors are not permitted to modify other editors' userpages. Requests for changes can be made on the editor's talk page. More details"
By way of examples, "More details" could link to a new page about the filter, the filter page itself if it provides enough information, or to this RfC. Whatever page it links to I think should eventually link back to this RfC to make it easy for interested users to trace back to the reason the filter was implemented. Robert Walker (talk) 19:07, 28 November 2016 (UTC)[reply]
Feedback is definitely still welcome, but so far, it looks like we've got some agreement around a notice that looks like the following:
I've included links to
Help:Using talk pages to direct people who aren't familiar with talk pages. I JethroBT drop me a line 19:27, 28 November 2016 (UTC)[reply
]
Would it be better to link directly to the talk page—something like [[User talk:{{ROOTPAGENAME}}|the editor's talk page]]. Also maybe a less angry colour than red? BethNaught (talk) 19:34, 28 November 2016 (UTC)[reply]
Agreed. Also, I feel we should link the phrase "Unregistered and new editors" to
WP:AUTOCONFIRM Wikipedia:User access levels#User groups so these new editors will know when they won't be blocked by the filter anymore. — Gestrid (talk) 19:37, 28 November 2016 (UTC)[reply
]
That looks good to me. Kaldari (talk) 19:40, 28 November 2016 (UTC)[reply]
I'm not too opposed to the angry color - it draws attention and is consistent against the other "deny" edit filters. One other thing to keep in mind for why this should be simple and use plain language - it will be presented to any editor or logged out user - and English may not be their primary language. — xaosflux Talk 19:42, 28 November 2016 (UTC)[reply]
We should at least set |friendly=yes so the symbol will be slightly more friendly. Also, I meant to say
WP:AUTOCONFIRM. — Gestrid (talk) 19:48, 28 November 2016 (UTC)[reply
]
That's OK - here is the "friendly" one — xaosflux Talk 19:53, 28 November 2016 (UTC)[reply]
That doesn't look any friendlier to me, personally. Maybe this icon instead? this icon Funcrunch (talk) 20:00, 28 November 2016 (UTC)[reply]
@Funcrunch: Unfortunately, we can't really change the icon because it's the |action=disallow parameter that determines what the icon will be. (|friendly= just changes it a little bit.) — Gestrid (talk) 20:15, 28 November 2016 (UTC)[reply]
Agreed with xaosflux that I think this is a case where the notice can be a little louder. Here's one with the ROOTPAGENAME suggestion from BethNaught:
I'd be OK with either a link to the user talk page or a link to the help page. One other bit that could be worth adding is a note about logged-out, registered editors accidentally editing their own user pages, and letting them know they should sign-in:
— Preceding unsigned comment added by I JethroBT (talk • contribs) 22:10, 28 November 2016 (UTC)[reply]
Good idea, but I'd suggest changing If this is your userpage, please log in to edit your userpage. to If this is your userpage, please log in to edit it. to reduce redundancy. — Gestrid (talk) 22:26, 28 November 2016 (UTC)[reply]
Looks good to me. • • • Peter (Southwood) (talk): 05:06, 29 November 2016 (UTC)[reply]
Notice is at
WP:UP#PROTECT and we're good to go, I believe — MusikAnimal talk 23:45, 30 November 2016 (UTC)[reply
]
Okay,
WP:UP#PROTECT [1] to convey the necessary information, so I've set the filter to disallow. Best — MusikAnimal talk 00:33, 1 December 2016 (UTC)[reply
]
Thanks to you both. I think the protection policy page section on user pages should probably be updated as well? Funcrunch (talk) 05:12, 1 December 2016 (UTC)[reply]
@Funcrunch:  In progress — Gestrid (talk) 05:27, 1 December 2016 (UTC)[reply]
@MusikAnimal: Remind me: How is an IP's user page effected? They're able to edit their own page, I assume, but what about other IPs and unconfirmed editors? Are they able to edit the IP's user page? — Gestrid (talk) 05:42, 1 December 2016 (UTC) Figured it out. — Gestrid (talk) 06:42, 1 December 2016 (UTC)[reply]
 Done I think. — Gestrid (talk) 07:00, 1 December 2016 (UTC)[reply]

Override

  • @MusikAnimal: So, did we ever decide on a way to override this - say if someone really wants their page to be edited, someone like say User:Jimbo_Wales#You can edit this page! ? — xaosflux Talk 01:10, 1 December 2016 (UTC)[reply]
    @Xaosflux: We could make a null template, say {{open userpage}}, that when present the filter will honour and allow the edit to go through. The filter would merely be looking for that code on the page, nothing special going on with the template itself. It could just as easily be an HTML comment, but that's not very clear. Anyway, normally checking the entire wikitext is concerningly expensive, but here the conditions of being unconfirmed and editing someone else's userpage would already have to be met, so I don't think it's that big of a deal. So how does the use of a null template sound? The other nice thing is the template could maybe add the page to a category, Category:Wikipedia user pages editable by unconfirmed users (or something) — MusikAnimal talk 01:31, 1 December 2016 (UTC)[reply]
    @MusikAnimal: That sounds like the OTRS template mess all over - so then we will need to have ANOTHER filter to prevent other people from putting that template on OTHER peoples pageS? — xaosflux Talk 01:33, 1 December 2016 (UTC)[reply]
    @Xaosflux: Indeed, but unconfirmed users wouldn't be able to add it, which cancels out the likelihood of that happening. I can however make the same filter disallow the unconfirmed user from removing the template. Alternatively we can simply add page IDs to the filter, one by one. That means you'd have to ask an edit filter manager to add your userpage to the list. This is the consequence of an edit filter over a native MediaWiki solution, but the latter requires considerable development effort and is unlikely to happen anytime soon — MusikAnimal talk 01:38, 1 December 2016 (UTC)[reply]
    I'm not sure the best course of action - the RfC didn't specifically leave room for an exception in its closing; Jc37 - what are your thoughts? — xaosflux Talk 01:52, 1 December 2016 (UTC)[reply]
    It didn't come up in the RfC because it wasn't anticipated (at least by me) that this kind of filter would be used as a solution, as opposed to actual semi- or extended-confirmed protection. I expected that if the toggle option gained consensus, and the toggle defaulted to protected, folks who wanted to allow anonymous editing of their user pages could toggle it themselves. Otherwise, editors would have to post on an admin noticeboard to get the default protection removed. Funcrunch (talk) 05:17, 1 December 2016 (UTC)[reply]
    For the time being, I've added an exception for Jimbo's page given it is high-profile and advertised as being open — MusikAnimal talk 02:06, 1 December 2016 (UTC)[reply]
    For that one page, I think that is best - but I don't want to start entertaining this for random userpages. Other exceptions would be for other special technical test pages. One other class of pages not covered would be pages of renamed users that are now redirects- though personally I think if the editor cares about maintaining their old username as a redirect they need to reregister it (due to SUL). — xaosflux Talk 02:28, 1 December 2016 (UTC)[reply]
If I understand the above correctly, this would fall under "toggling", which there wasn't consensus for in the discussion. That said, "no consensus" result isn't "opposed", and further, as I recall, the discussion didn't foresee this implementation as a filter either.
So, you could start an RFC on it, I suppose. Whether JW's page should be the only exception, whether anyone could "opt out", or "not" in either, or both, cases. - jc37 21:27, 1 December 2016 (UTC)[reply]
I recall at least one person in the RfC discussion declaring that if default protection were implemented, they would immediately request that their user page be unprotected. I agree that there needs to be a way to do this. I'm not volunteering to create another RfC for that purpose myself though. :-P Funcrunch (talk) 22:01, 1 December 2016 (UTC)[reply]
Unprotecting would appear to be congruent with "toggling". Which is why I said what I did, above : )
As for me, I have no opinion on whether such toggling should be permitted (which should make sense, since I chose to close the discussion), hence why I suggested possibly starting a follow-up discussion/rfc, if you wish. - jc37 22:49, 1 December 2016 (UTC)[reply]
@Jc37 and Funcrunch: I suggest we talk about this in #Unprotecting a user page? below for a few reasons: Talking about unprotecting userpages is getting a little off-topic from this particular discussion and the thread below would be a perfect fit for this discussion. Also, this discussion is getting a little too long to open another can of worms. — Gestrid (talk) 22:19, 1 December 2016 (UTC)[reply]

Filter notice text

(Taking off my closer hat) - About text of the alert (and this isn't as closer obviously, as the alert has nothing to do with the discussion closure : ) - I think the first sentence should probably be changed entirely. There's already a link to the policy, and having a sentence about a "filter" in the alert could be unnecessarily confusing for newbies, I think. And this shortens the amount of text too.
Thoughts welcome. - jc37 21:29, 1 December 2016 (UTC)[reply]
This, in my opinion, appears less bitey than the ones above. I like it. — Gestrid (talk) 21:43, 1 December 2016 (UTC)[reply]
Agreed, this language reads a little more naturally to me as well. I JethroBT drop me a line 21:47, 1 December 2016 (UTC)[reply]
Looks like an improvement to me too. Funcrunch (talk) 21:58, 1 December 2016 (UTC)[reply]

Thank you

I'd like to thank everyone who helped and supported this project, from the idea created in June, through the RfC created in August, to the Phabricator task created in October, which was implemented today. Funcrunch (talk) 05:07, 1 December 2016 (UTC)[reply]

Good job, MusikAnimal. After examining a bunch of edits the filter caught, I can say it definitely does its job. — Gestrid (talk) 22:47, 1 December 2016 (UTC)[reply]

Unprotecting a user page?

Sorry if this is somewhere above already. The RfC's question stated user pages should be protected by default, leaving the door open to a user deciding to unprotect theirs. How do I go about allowing any editor to edit my user page given the edit filter situation? ~ Rob13Talk 21:35, 1 December 2016 (UTC)[reply]

@BU Rob13: There was some discussion above of some sort of "null" template proposed by MusikAnimal. Whatever happens, it hasn't been implemented yet. — Gestrid (talk) 21:41, 1 December 2016 (UTC)[reply]
The null template route would be relatively easy to implement, although it's also prone to issues of its own. For instance, it would become possible for any editor who's autoconfirmed to "unprotect" a user page, rather than just the user whose page it is. That might necessitate another filter to prevent the addition of the null template by any user other than the user whose page it is. Or maybe I'm just overthinking it. ~ Rob13Talk 22:30, 1 December 2016 (UTC)[reply]
Correct, you'd need a second filter to restrict removal of the template to the user who owns the userpage. We should weigh out whether this is truly necessary, though. With the existing filter, we can prevent unconfirmed users from removing the template, which I honestly feel is sufficient. If a malicious user who is confirmed removes the template, then clearly the filter-enforced semi protection is not doing the trick in the first place, and you might want to consider ECP. Filters come with a cost, and here the additional one I don't think is worth it — MusikAnimal talk 23:28, 1 December 2016 (UTC)[reply]
@MusikAnimal:: If a malicious confirmed user removes the template from another user's page, will the affected user be notified? Funcrunch (talk) 23:40, 1 December 2016 (UTC)[reply]
@Funcrunch: They would likely get the standard "Wikipedia page [User's page] has been changed by [User who changes it]" email. — Gestrid (talk) 00:32, 2 December 2016 (UTC)[reply]
The part about allowing any confirmed user to unprotect any userpage is not supported by the RfC; options for "toggle" were discussed as well, and did not end in a consensus. — xaosflux Talk 00:37, 2 December 2016 (UTC)[reply]
@xaosflux: Are you saying there shouldn't be any way to disable it without a second RfC? — Gestrid (talk) 00:41, 2 December 2016 (UTC)[reply]
Well I think it sounds fine - but that's not what the RfC concluded: There was consensus to at least have ongoing semi-protection of user pages. There wasn't consensus for extended or for user-toggled. — xaosflux Talk 00:42, 2 December 2016 (UTC)[reply]
Ok. Just asking for clarification. — Gestrid (talk) 00:57, 2 December 2016 (UTC)[reply]

To be clear, my concern isn't the removal of this template. It would be the addition of the template, which would then allow non-confirmed editors to edit the page freely. One sleeper account adds this template to a bunch of user pages, and then IPs go to town, if that makes sense. But yes, perhaps that's not worth a filter. @

disruptive editing against consensus to add it to the user pages of others. ~ Rob13Talk 01:08, 2 December 2016 (UTC)[reply
]

Like I said I think having a toggle would be good - but this is really another sample of activating something with a less than ideal implementation solution (remember the must make an AN thread for every ECP use mess?). — xaosflux Talk 01:12, 2 December 2016 (UTC)[reply]
At this point I'd be in support of a {{unlocked page}} null template, with a filter that only lets it be put ON by the same user or an admin to base userpages; then have the current filter ignore pages that it contains. I'm not too worried about other confirmed users taking that OFF (re-locking) other peoples pages. — xaosflux Talk 01:15, 2 December 2016 (UTC)[reply]
(edit conflict × 2) I fully agree with your thoughts on this filter, but in the meantime, we need to make the current implementation suck less. I think it's clear the community never intended to force me to have my user page effectively semi-protected. I could implement a hacky kind of solution of specifically exempting my user page in the filter, but that's not a viable long-term fix. ~ Rob13Talk 01:18, 2 December 2016 (UTC)[reply]
Actually consensus was indeed for default semi-protection, according to the closer Jc37, who has clarified the reason for their close several times now. Funcrunch (talk) 01:28, 2 December 2016 (UTC)[reply]
On re-reading I see that you probably meant you don't want to be forced to keep your page semi-protected if you don't want to, which I agree with. Funcrunch (talk) 01:30, 2 December 2016 (UTC)[reply]
I think that as long as the affected user is notified in case a confirmed user maliciously unprotects their page, it's not worth making a separate filter or programming effort just to avoid that potential situation. The malicious user can be warned and (if necessary) banned accordingly, and needing autoconfirmed status is likely a barrier against much of this kind of thing happening. I also don't think this is quite the same as the toggle option that I offered in the RfC. Funcrunch (talk) 01:20, 2 December 2016 (UTC)[reply]
Importantly, the toggle option was default off, whereas this is default on. Those are substantially different. ~ Rob13Talk 01:22, 2 December 2016 (UTC)[reply]
Actually, in reading the RfC again, now I'm downright confused about the consensus again. It's clear that the order of "progression" in terms of how intrusive the options were was:
  1. No protection
  2. Default off, but allow users to toggle protection on
  3. Default on, but allow users to toggle or request protection off (unclear on how moving away from default works in this proposal)
There's an added layer of complexity in the semi/ECP stuff, but we can safely say that everyone who supported ECP would support semi as well, so we can collapse those. So how, exactly, did we get to the "default on" option instead of "default off" when we had 32 editors opposing any protection, 30 editors supporting default off, and 37 unique editors supporting default on (between semi and ECP, collapsed together)? There may be some overlap between opposing all protection and supporting default off, but not that much, since most editors opposing everything stayed only in that section. It seems clear that the support for default on didn't even clear 50%, let alone reach a threshold required to alter the protection policy. Can we get a comment on this? I think the closer may have erred in looking at the questions in terms of "Should we have semi-protection or not?" and then subsequently "Should there be a toggle?" Presenting the options in that order may give you consensus and then no consensus, but the final result would be the result of a Condorcet paradox and the structure of the artificial two-stage voting, rather than actual community support for the final option. ~ Rob13Talk 01:40, 2 December 2016 (UTC)[reply]
Jc37 already explained that it was not a matter of merely counting up !votes. I think they've explained and defended their reasoning for the way they closed more than enough times. Now whether this filter is an adequate substitute for actual semi-protection is a separate issue. Funcrunch (talk) 02:29, 2 December 2016 (UTC)[reply]
@Funcrunch: Re-reading their comments above, I see they did state they considered "Should there be protection?" and "Should it be toggle?" as separate questions, with those !voting for a toggle being supportive of protection. But he just as easily could have interpreted the two questions as "Should there be some method of protection on user pages controlled by the users?" and "Should it be default on?" If he had interpreted the "stages" that way, we would have toggle. It's a textbook example of a Condorcet paradox, where the way you structure the voting stages determines the outcome. I do not believe it's appropriate for the closer to structure those stages themselves in a manner supportive of the most severe of the options presented, effectively allowing them to choose an outcome. ~ Rob13Talk 18:32, 2 December 2016 (UTC)[reply]
I also have concerns with the way @Jc37: interpreted this. In my opinion, the biggest question in the RFC was what is the appropriate default level for user page protection, and whether to allow toggling was a subquestion of that. I suspect that if the RFC was closed starting with the biggest question, the result would be substantially different. Tazerdadog (talk) 05:27, 6 December 2016 (UTC)[reply]

(←) @Xaosflux and BU Rob13: (and others), I think I can cover all grounds in the same filter (see Special:AbuseFilter/637). That is, prevent new users from editing the userpage unless the template is there, and only allow the owner to add/remove it. However the issue is by using one filter, we only have one notice to show to them. So we could add more language to it saying "All users are also disallowed to add or remove the {{unlocked userpage}} template from other editor's userpages". How does this sound? I think any confusion caused by adding this text to the notice is still preferable over a separate filter — MusikAnimal talk 18:11, 2 December 2016 (UTC)[reply]

I agree with that wording. ~ Rob13Talk 18:33, 2 December 2016 (UTC)[reply]
I think this is sensible as well. Small edit on the phrasing: Users cannot add or remove the {{unlocked userpage}} template from other editors' userpages. I JethroBT drop me a line 18:47, 2 December 2016 (UTC)[reply]
I can't see the filter you linked to, but I'm OK with the single-filter solution and additional language. Funcrunch (talk) 19:11, 2 December 2016 (UTC)[reply]
I need time to read that long filter :) — xaosflux Talk 19:41, 2 December 2016 (UTC)[reply]

Need exception for sandbox

@MusikAnimal: (and others): While reviewing recent events in the edit filter log, I noticed another user page that should be unprotected: User:Sandbox. Funcrunch (talk) 14:56, 3 December 2016 (UTC)[reply]

 Done — xaosflux Talk 15:31, 3 December 2016 (UTC)[reply]

Can edits caught by filter be hidden?

If an anon/new user attempts to insert particularly malicious content into a user page, can the details of that attempted edit be hidden in the edit filter log even though the edit was never actually made? i.e. can such attempted edits be revdeleted? Funcrunch (talk) 16:47, 3 December 2016 (UTC)[reply]

The abuse filter doesn't have per-entry visibility - however the entire filter # could be set to "private" which would hide the details of the edit. — xaosflux Talk 16:55, 3 December 2016 (UTC)[reply]
Actually, I believe filter log entries can be suppressed by oversighters. BethNaught (talk) 17:00, 3 December 2016 (UTC)[reply]
Good, that's what I wanted to know. I wouldn't want all of the attempted edits to be hidden; one advantage of this filter over semi-protection is logging, after all. But if someone attempts to "out" someone or makes other grossly inappropriate edits to another user's page, those should be hidden from view. Funcrunch (talk) 17:04, 3 December 2016 (UTC)[reply]
KrakatoaKatie can you confirm that abusefilter-hide-log actually works? — xaosflux Talk 17:07, 3 December 2016 (UTC)[reply]
Yes, edit filter logs entries can be oversighted, Katietalk 22:16, 3 December 2016 (UTC)[reply]
Thank you. So there you go Funcrunch - just ask at oversight as needed. — xaosflux Talk 23:01, 3 December 2016 (UTC)[reply]

Opting Out

Has a template to opt out of the edit filter been implemented yet? I would like to use this template on my userpage, but it's not clear if one exists, and I can't look at the guts of the filter to determine this myself. Tazerdadog (talk) 04:59, 6 December 2016 (UTC)[reply]

@Tazerdadog: not yet - and the filter is visible here: Special:AbuseFilter/803. — xaosflux Talk 05:29, 6 December 2016 (UTC)[reply]
@Xaosflux: thank you, that answers what I need to know. Tazerdadog (talk) 05:31, 6 December 2016 (UTC)[reply]
I'm ready to move forward with the new filter when you are all. @Xaosflux: did you maybe want to help with testing? I've tested it here against my sandbox, but we could set it up on testwiki — MusikAnimal talk 01:42, 7 December 2016 (UTC)[reply]
@MusikAnimal: How about duplicating the existing filter, then add this one as log only; exempt a few test pages manually from the first filter - then set the duplicate one to && the additional test pages that are skipped from the first. — xaosflux Talk 01:17, 8 December 2016 (UTC)[reply]
If works, then move to production blocking on the duplicated filter for testing - if all is good the first one can be udpated, duplicate can be deleted. — xaosflux Talk 01:17, 8 December 2016 (UTC)[reply]
MusikAnimal did you ever get to revisit this? — xaosflux Talk 15:40, 13 December 2016 (UTC)[reply]
@Xaosflux: I have not. I don't quite follow the advised testing plan. One thing to note is that you'll need to be the owner of a userpage to fully test this, since they (and admins) are the only ones who can add/remove {{unlocked userpage}}. We could simply enable the new filter as log-only, and you can run your tests by checking the logs. Your test edit may be blocked by the current filter, but you can check the log for 637 and if you don't see "Actions: disallow" for that edit than you know it won't be blocked by the new filter. How does that sound? — MusikAnimal talk 16:34, 13 December 2016 (UTC)[reply]
@MusikAnimal: It should be noted there are other methods to accomplish such other than notching the filter with a specific template (which is a bit fragile). For example, a user's page could be made to be nothing besides an inclusion for a subpage and thus the subpage is unlocked and any changes to it would appear on the main page. A generic template for such could even be developed with content like {{Special:MyPage/content}}. It could even be prefaced with an optional prepackaged message block linking to the unlocked main content subpage telling others about the unlock and how to edit the content. Existing users could easily install such by moving their existing page to the new unlocked subpage location and then re-editing the locked main page changing the redirect into an instantiation of the unlock template. 50.53.1.33 (talk) 23:40, 23 August 2017 (UTC)[reply]

Help with filtered edit

Could I get someone to make this edit since apparently I am prevented from making it: Special:AbuseLog/19074266. I was trying to remove it from Category:Pages using invalid self-closed HTML tags. Thank you. 50.53.1.33 (talk) 19:42, 14 August 2017 (UTC)[reply]

 Done by zzuuzz. — JJMC89 (T·C) 20:34, 14 August 2017 (UTC)[reply]
Interesting teamwork (not sure why one of you did it and the other replied here) but thank you. 50.53.1.33 (talk) 23:35, 14 August 2017 (UTC)[reply]

New warning templates needed

I gave a presentation about this RfC and the resulting edit filter at WikiConference North America last week, where I mentioned that I have been leaving warning messages using this template for anonymous and new editors attempting to vandalize user pages (found by monitoring the abuse log). During the Q/A session, an attendee correctly pointed out that the edits I am warning people about constitute harassment, not merely vandalism. I've also noticed that the template I've been using (which existed long before the creation of this filter) implies that the edit was filtered because of the language used, whereas in fact any attempted edit of another's user page is prevented (unless the owner or an admin added the {{unlocked userpage}} template).

I'd like to make a new set of warning templates that refer to personal attacks rather than attempted vandalism (similar to this template), and to clarify why the user page edit was prohibited. Although the warning notice after the edit attempt is prevented explains this, some editors are ignoring or overlooking this, as they make multiple attempts to edit the user page, sometimes tweaking the offensive language to try (unsuccessfully) to get around the filter. I could use community input on how this new template should read, as well as if we should make any tweaks to the warning notice to dissuade editors from trying multiple times to vandalize/harass. Funcrunch (talk) 15:03, 16 August 2017 (UTC)[reply]

I've pinged the Community Health Initiative talk page on this discussion. Funcrunch (talk) 15:53, 16 August 2017 (UTC)[reply]
I'm pleased to see that you are thinking about alternative wording for the templates. I'll spread the word to others who might be interested in giving an opinion. SPoore (WMF), Community Advocate, Community health initiative (talk) 20:10, 16 August 2017 (UTC)[reply]
Please bear
WP:DENY in mind—there is a danger that bored kids will start competing to see how quickly they can get a large decoration on the talk of their throw-away account/IP. Also, if someone posts an attack, they know what they have done, so rewarding them with a pompous message pointing out the obvious will only provoke a natural reaction whereby they eye-roll and think that Wikipedians deserve all the muck that can be thrown at them. It would be useful if an admin could post a very brief final warning, with an instant block to follow if there is any repeat. However, I have never seen an example where warning a harasser did anything other than encourage them. Many harassers believe they have been wronged, and they regard templates as harassment against them. It is often best to post {{Uw-test1}} which has a hint of mockery in that someone's brilliant rant is described as a "test edit". Johnuniq (talk) 00:35, 17 August 2017 (UTC)[reply
]
The
WP:DENY argument came up during the Q/A after my talk too. It's a good point, but my response (then and now) is that leaving a warning alerts other editors, including the one targeted, that the anon/new user is a (potentially) problematic editor. Many of the vandals/harassers I've warned had otherwise clean or absent talk pages that showed no hint they've been posting garbage. Many of the targeted users have thanked me for these warnings as well. Funcrunch (talk) 01:32, 17 August 2017 (UTC)[reply
]
Would you mind showing a couple of diffs for the kind of attacks/harassment you mentioned. I have seen lots of nonsense and plenty of strong commentary, but have not noticed many abusive rants apart from transparently obvious silliness that is like adding "pooh" to an article. I suppose it warrants a warning, but I'm concerned about appearances because delivering a pompous warning to someone who writes graffiti is rarely effective and, I suspect, may be counter productive. There should be some response, but not a message which makes it look as if we take them seriously. All that is needed is to say that a repeat will lead to a block. But will it!? Getting a block can be tricky. Johnuniq (talk) 02:03, 17 August 2017 (UTC)[reply]
See my presentation, starting from page 9, for some fairly graphic examples. If you want to see some of the actual diffs these were sourced from, I can provide them. Funcrunch (talk) 02:06, 17 August 2017 (UTC)[reply]
I'm sorry to take a contrarian line, but those examples are exactly the kind of pooh nonsense that warrant a 31-hour block with no templates. The {{
WP:AIV would probably get an "Insufficient recent activity" or "No edits since being warned" rejection when a decent community would block the throw-away IP/account for a single such recent post. At any rate, those examples are not really attacks—they are just graffiti from a troll. They need to be dealt with, but if I were a newish editor, I would be disappointed if such graffiti directed at me resulted in merely a vandalism warning to the perpetrator. Johnuniq (talk) 03:15, 17 August 2017 (UTC)[reply
]
I was under the impression that under most circumstances editors should be warned at least once before being blocked, if not by policy, then by convention. Regardless, I would not describe all of these examples, particularly the ones on this page, as mere "graffiti". If you haven't already, please read the rest of the slides for my arguments on why this language should be addressed seriously. Funcrunch (talk) 03:41, 17 August 2017 (UTC)[reply]
Also, I agree that a mere vandalism warning is insufficient for these cases; that's the reason I started this discussion, to come up with better warning templates. Funcrunch (talk) 03:53, 17 August 2017 (UTC)[reply]
Drive-by vandals are often blocked with no warning. Jo-Jo Eumerus (talk, contributions) 14:45, 17 August 2017 (UTC)[reply]
@Funcrunch: I agree that Template:Uw-attempt2 is too tame. These are personal attacks and are bigger than just a drive-by vandalism or test edits. My suggestion would be to copy Template:Uw-attempt2 but replace 'vandalism' with 'personal attacks' and drop the "if you would like [...] sandbox." sentence.
I know you browse the logs of the AbuseFilter, so you're probably more familiar with the ratio of mistake edits vs. malicious edits, but I would assume most edits are accidental or good-faith. I believe the tone of the language should reflect this. The language on MediaWiki:Abusefilter-warning-userpage could also be clarified but kept inside the same template. At minimum I would break the first giant run-on sentence into two or three and create a new paragraph for the final "if you would like to create [...]"
Cheers, — Trevor Bolliger, WMF Product Manager 🗨 22:02, 18 August 2017 (UTC)[reply]
Again, I urge the folks considering this to talk to the people who have experience dealing with it. It is easy to theorize but really - dealing with trolls and vandals is something that happens everyday. Templating assholes rewards them and there is a lot of experience behind DENY. Jytdog (talk) 01:38, 20 August 2017 (UTC)[reply]
  • I understand the admin perspective on how many admins prefer to handle this, really I do. And I think we all understand some of the trolls perspective (we live on the internet, after all). But Funcrunch is finding that real life targeted editors appreciate seeing warnings as they lookout for potentially dangerous users, and that's worth considering too, whether the solution is reworded templates or something else. The user who started the discussion here deals with this pretty much every day, because they're either being harassed, watching out for others being harassed, or reporting harassment when they see it (I saw their talk, no need to repost more language here). That's real experience too, and not to be dismissed. Siko (talk) 20:05, 21 August 2017 (UTC)[reply]
  • We know that harassment is a significant problem in the Wikimedia community. Funcrunch is to be commended for attempting to improve the wording on a commonly used template that does not accurately address harassment. Funcrunch's presentation is worth looking at if you've not had a chance to see it yet.
  • We need to experiment with new solutions that can both decrease harassment, simplify the work of admins and experienced users that deal with harassment, and most importantly give more comfort to targets of harassment. To do this we need to we need to gather input from a broad range of people including admins, experienced users who witness harassment, people who are the target of harassment, and also experts on harassment. When practical, we need to gather quantitative and qualitative data to inform decisions.
  • One approach is to create several different new templates and the cases for using them, and then test them to see any of them give more benefit than our current methods of addressing harassing edits. SPoore (WMF), Community Advocate, Community health initiative (talk) 17:00, 22 August 2017 (UTC)[reply]
  • for stuff that is hateful attack, what is wrong with Template:Uw-npa4? This is dead on. The first bullet point in the body of NPA is "Abusive, defamatory, or derogatory phrases based on race, sex, sexual orientation, age, religious or political beliefs, disabilities, ethnicity, nationality, etc. directed against another editor or a group of editors. Disagreement over what constitutes a religion, race, sexual orientation, or ethnicity is not a legitimate excuse." User:Funcrunch why are you not using this? Jytdog (talk) 17:43, 22 August 2017 (UTC)[reply]
  • @Jytdog: I am familiar with the existing personal attack warning templates; I linked to Template:Uw-npa2 which is a lower-tier version of Template:Uw-npa4 in my original post. I have no objection to using them in these instances, but was hoping to craft language more specific to these attempted user page edits as all edits from unconfirmed editors to these pages are prohibited/filtered. Funcrunch (talk) 19:29, 22 August 2017 (UTC)[reply]
Thanks for replying but that doesn't really respond... Would you please say what about np4 doesn't meet the need? It seems dead-on for the kinds of ugly things that get blocked by filter. I really don't understand. Thx. Jytdog (talk) 19:32, 22 August 2017 (UTC)[reply]
I want to clarify in the template language that the attack was attempted, not successful, but still noticed. This would hopefully reduce confusion on the part of the targeted editor who is pinged on the notice. Funcrunch (talk) 19:38, 22 August 2017 (UTC)[reply]
I see. That makes sense! Something as harsh and clear as np4 would be OK with me as something to try. I don't know why you want to ping the attackee though? That has confused me from your first post. Kind of weird either way. Jytdog (talk) 04:26, 23 August 2017 (UTC)[reply]
@Funcrunch: Thank you for your continued energy toward this. I know it certainly isn't easy. Just as you said, ally is a verb. You do this every day, friend, and I know you persist because of love for this community and fellow contributors.
To people wanting data, there could be quantifiable data pulled out of the abuse log, but we are hearing suggestions from someone who witnesses activity on the log every day. I know I am personally all for what Funcrunch suggests. I am also more than willing to help in any sort of investigation to move us forward on harassment issues.
We all need to consider this: ally is a verb. This template is more than just a warning. It is a statement that we as a community are standing up against harassment and we value the people who are being harassed.
I think it's time we call harassment by its name. Some people in some corners of the Internet consider these actions "just joking around" or "silliness". It's not. It's harassment. I look forward to the day that harassment is not dismissed as "trolling" or "silliness" here. We need to show we value our contributors more than harassers, and really be allies. Jackiekoerner (talk) 20:17, 22 August 2017 (UTC)[reply]
@Funcrunch: -- thanks for your persistence and thoughtfulness in addressing this. Your devotion to the openness of the community is amazing. It was quite obvious to me that things are not working, so I'm having a difficult time understanding why comments in this thread are suggesting that the current processes are working well. I support your initiative to try out a specific kind of template that marks on talk pages that someone tried and failed to harass another user. This is a powerful move and I think it would be a great experiment to try. You have my support in whatever needs to be done to move forward on this, and any future creative ways to try and keep the ethos of openness balanced with preventing harassment and keeping those who experience it feeling safe, validated, and heard by others in the community. Thanks again for all you do. Shameran81 (talk) 21:22, 22 August 2017 (UTC)[reply]

Help with filtered edit

Could I get someone to make this edit since apparently I am prevented from making it: Special:AbuseLog/20140789. I was trying to remove it from Category:Pages using DBLP with the id parameter (so I can removed the deprecated parameter support; this is the last hold out). Thank you. 50.53.1.21 (talk) 20:13, 6 January 2018 (UTC)[reply]

 Done — xaosflux Talk 20:38, 6 January 2018 (UTC)[reply]

Null template

I'd like my user page to no longer be effectively semiprotected by this filter, and I suspect there are others who feel the same way. Has a null template been created, and if not, can it be created easily? Tazerdadog (talk) 21:08, 6 January 2018 (UTC)[reply]

@Tazerdadog: The template is {{unlocked userpage}}. — JJMC89 (T·C) 21:24, 6 January 2018 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_comment/Protect_user_pages_by_default&oldid=1158003700"