|If your question is about stewards' business. STOP! I can no longer assist.
If you are blocked please ask at Steward requests/GlobalAll steward-related business should be addressed to stewards, and any post here is likely to be reverted.
|If you are looking to get my attention, you can|
- 1 To do task
- 2 user meta tool to identify User:CommonsDelinker pages and remove
- 3 Strategy pages and protecting by other means
- 4 Wikidata weekly summary #345
- 5 On v:zh:MediaWiki:Colloquium/en
- 6 Wikidata weekly summary #346
- 7 HELP !
- 8 Abuse filter 195
- 9 A Barnstar for you!
- 10 URGENT: Please sign new Wikimedia confidentiality agreement for nonpublic information now
- 11 Cross-wiki spam by Areokye
- 12 Wikidata weekly summary #347
- 13 Stewards/Elections 2019
To do task
Align the codes on the admin/crat/cu/... and sisters user templates to have a base, and a build
Time to get rid of the legacy garbage user pages, and allow meta user page to shine through.
Strategy pages and protecting by other means
Hi. Good idea! "(WMF)"-like and sysops sounds fine. In my opinion, we should restrict edits by users not recognized as trusted, and that's all. On Meta, there isn't any trusted group broader than sysops, is there? Ideally, some day, a filter like "sysops on any wiki + affiliate capacity" should be added.
BTW, how is it possible to set filter "WMF+sysops"? On Special:ProtectedPages, I can only see full, semi, translators and centralnotice, and centralnotice. SGrabarczuk (WMF) (talk) 10:24, 31 December 2018 (UTC)
- @SGrabarczuk (WMF): Abusefilter, not page protection, restrict editing based on regex of user_name or member of a group. We can utilise the autopatrolled flag if that is preferred, it is allocated by a sysop here. We already have that as a combination in Special:AbuseFilter/161 to restrict the editing of user: ns pages. It is about identifying exactly the specific pages, or the basepagename if we have parent and children subpages. — billinghurst sDrewth 11:01, 31 December 2018 (UTC)
Wikidata weekly summary #345
An interesting fact: Chinese Wikiversity community had chosen "互助客栈" as a translation for Colloquium. However, in Chinese Wikipedia, "互助客栈" is a flexible translation for Village Pump... --Mend My Way 15:45, 4 January 2019 (UTC)
- It was an example only for Cohaf. Do what ever you need. — billinghurst sDrewth 15:54, 4 January 2019 (UTC)
Wikidata weekly summary #346
- Decline reason: There is not a block on the IP range at metawiki. I will hazard a guess that you are editing at another wiki, so you will need to query their block and request an unblock at that wiki. Looks to be wikivoyage try an unblock request at voy:User talk:22.214.171.124 — billinghurst sDrewth 11:02, 7 January 2019 (UTC)
It does not work, and there was no notice board,
posting was vandalism and i was reverted and blocked, to stop me from reposting.
there is a template;
- https://en.wikivoyage.org/wiki/Template:Blocked they are not using this template and unlock or unblock templates do not work.
and in trying to use the template got the talk page blocked
this only affecties the english wikivoyage.
and posting to this gets it reverted.
126.96.36.199 17:03, 7 January 2019 (UTC)
- The best that you will be able to do is to talk to the blocking admins at their talk page here at Meta ... User talk:AndreCarrotflower. Start by seeking to understand their concerns about your post, and about what was problematic. Or you might ask for them to find another admin who could independently review the decision, and make recommendations.
you said the block is not on this wiki so why can't the template be removed it says
"DO NOT REMOVE THIS UNBLOCK REVIEW WHILE YOU ARE BLOCKED"
there is no block. ?
188.8.131.52 23:45, 7 January 2019 (UTC)
184.108.40.206 00:09, 8 January 2019 (UTC)
- There is a string of active conversations occurring, and it is contextual for each conversation and to look at the overall picture without having to dive into page histories. There is no issue leaving such discussions in place, it doesn't make the place messier, or more confusing. Maybe in a couple of weeks it can be tidied, once it is less required. — billinghurst sDrewth 00:21, 8 January 2019 (UTC)
- Note, you have to address your issues locally, that is to ask for local administrator assistance, and if none of them after reviewing your case independently decided to unblock, just serve out the 3 months. Period. Thanks and here at meta we cannot do anything about it.--Cohaf (talk) 00:20, 8 January 2019 (UTC)
220.127.116.11 00:21, 9 January 2019 (UTC)
- Excellent, now I fully understand the situation already, you are just a troll and please stop this nonsense. Wait out the 3 months local block, and since it's account creation blocked, if you create any accounts or IP and edit, you are off to another long enforced wikibreak. Cease and desist immediately from this IP or else this will be blocked globally as block evasion. Regards.--Cohaf (talk) 00:41, 9 January 2019 (UTC)
Abuse filter 195
Let me first express my support for the comments made by Juetho above. On nl.wiktionary the filter is blocking spam accounts on a daily basis. Up to now I have had no complaints by genuine editors. Some accounts that trigger the filter somehow end up being created after all. As of now, none of these turned out to be genuine contributors, but some of them almost immediately attempted to spam. I would clearly like this filter to remain. It would be helpful is the log somehow could indicate whether the filter did or dit not result in a new account being created. --MarcoSwart (talk) 14:24, 8 January 2019 (UTC)
- @MarcoSwart: The abuse filter is only set to challenge creation, not to disallow creation, which has shown a level of effectiveness, without being absolute, so those who wish to push through can do so. We maybe need to think about the message that we issue to users through the block, and whether we can better address the language of the message, which has been unexplored by me as it was meant to be a temporary measure. I would prefer that the debate and decision about an abuse filter not be had here, and maybe we should move it to Stewards' noticeboard where I announced the filter during the problem times. Unfortunately abuselogs don't show success after challenge, and you still need to rely on "RecentChanges" or directly looking at Special:Log for creations, and to note that some of the spambot creations that fall outside of the loose filter will also show there. — billinghurst sDrewth 01:53, 9 January 2019 (UTC)
A Barnstar for you!
|The Special Barnstar|
|Thanks for your help over the holiday with the spambot problem. CKoerner (WMF) (talk) 17:17, 8 January 2019 (UTC)|
- @CKoerner (WMF): Thanks, good bit of team effort and thanks to those developers who came to my aid, most especially BAW who starred! Note the above comment about Special:AbuseFilter/195 which is related, and while being reasonably effective against other standard spambots, does have a low positive false hit rate. If we are going to keep 195, we need to look at ramifications, applying mitigation where possible, and maybe a level of communication through a newsletter. — billinghurst sDrewth 01:58, 9 January 2019 (UTC)
This is a reminder to acknowledge and sign the new Confidentiality agreement for nonpublic information. As you know, your volunteer role in Wikimedia projects gives you access to secure and sensitive information.
The new version includes one major change.
- There is a change regarding the way personal data may be released. Accordingly, functionaries must notify the Wikimedia Foundation at check-disclosurewikimedia.org before releasing data, in order to obtain a written approval for doing so. The Foundation will respond within 10 days. However, for emergencies, such as cases involving threats of violence, functionaries may release the personal data without such explicit permission, but they should notify the Foundation immediately following the disclosure. If they choose not to disclose the data, the request for disclosure should be forwarded to the Foundation's emergency email address (emergencywikimedia.org).
There are also some wording changes that were made to more closely align the language with evolving industry norms, best practices and laws. The most notable of these has been the change of the term "nonpublic information" to "nonpublic personal data". None of these changes are intended to make fundamental changes to the scope or practice of the policy but we know they could appear as such, hence wanted to flag them.
The aforementioned changes require users that have already signed the previous version of the policy to sign the new version as well.
We therefore ask that you to sign the updated version. Signing the agreement is tracked on Phabricator's Legalpad. An online guide is available to help you with signing the agreement: Confidentiality agreement for nonpublic information/How to sign. If you wish you can sign it directly at https://phabricator.wikimedia.org/L37. The exact policy is located here: Access to nonpublic personal data policy. The text of the confidentiality agreement is located here: Confidentiality agreement for nonpublic information
If you have already received this message and signed the updated agreement, you need not sign it again. Once is sufficient. In this case, we ask that you respond to Samuel (WMF) letting him know when (date) and how (method/process of signing) you have signed it so that we can update our own records.
Note: please bear in mind that if you still haven’t signed the updated version of the Confidentiality Agreement by February 13, 2019 your rights will be removed.
Thank you for your understanding,
Samuel Guebo (User:Samuel (WMF)), Wikimedia Foundation
Posted by the MediaWiki message delivery - 15:15, 11 January 2019 (UTC)