User talk:Максим Підліснюк
As you may know, the Wikimedia Foundation Board of Trustees approved a new "Access to nonpublic information policy" on 25 April 2014 after a community consultation. The former policy has remained in place until the new policy could be implemented. That implementation work is now being done, and we are beginning the transition to the new policy.
An important part of that transition is helping volunteers like you sign the required confidentiality agreement. All Wikimedia volunteers with access to nonpublic information are required to sign this new agreement, and we have prepared some documentation to help you do so.
The Wikimedia Foundation is requiring that OTRS volunteers sign the new confidentiality agreement by 31 December 2015 to retain their access. You are receiving this email because you have been identified as an OTRS volunteer and are required to sign the confidentiality agreement under the new policy. If you do not sign the new confidentiality agreement by 31 December 2015, you will lose your OTRS access. OTRS volunteers have a specific agreement available, if you have recently signed the general confidentiality agreement for another role (such as CheckUser or Oversight), you do not need to sign the general agreement again, but you will still need to sign the OTRS agreement.
Signing the confidentiality agreement for nonpublic information is conducted and tracked using Legalpad on Phabricator. We have prepared a guide on Meta-Wiki to help you create your Phabricator account and sign the new agreement: Confidentiality agreement for nonpublic information/How to sign
If you have any questions or experience any problems while signing the new agreement, please visit this talk page or email me (gvarnum wikimedia.org). Again, please sign this confidentiality agreement by 31 December 2015 to retain your OTRS access. If you do not wish to retain this access, please let me know and we will forward your request to the appropriate individuals.
Gregory Varnum (User:GVarnum-WMF), Wikimedia Foundation
Dear Максим. Your request has been moved to this page, because SRGP is the wrong place for that request. Please, continue the discussion on the new location. Thank you for your understanding. Best regards, —MarcoAurelio 12:42, 25 March 2016 (UTC)
Здравствуйте как мне известно вы имеете право переименование имени википедистов на глобальном уровне. Просьба к вам пожалуйста моё имя в Узбекской википедии Bir soddadil Uzbek, а теперь я хочу её изменить на Doniyorsher Juraev. Help me please, please and thank you...Подробности вы можете узнать, здесь мой профиль  с уважением Doniyorsher (talk) 06:05, 26 April 2016 (UTC)
- @Bir soddadil Uzbek and Doniyorsher: здравствуйте. Для начала, учетный записи глобальны - заведя учетку в узбецкоязычный Вики, вы завели её везде. Дальше. Вы утверждаете, что ваше имя пользователя Bir soddadil Uzbek, но написали это с учетной записи Doniyorsher. Так кого именно следует переименовать? --Максим Підліснюк (talk) 09:45, 26 April 2016 (UTC)
Hi! I'm not sure if you follow the global renamers mailing list, but until phab:T137973 is fixed we should not be renaming users because they will break and the users will not be able to login until fixed. Best regards, —MarcoAurelio 21:53, 27 June 2016 (UTC)
2016 Community Wishlist SurveyEdit
You’re getting this message because you participated in the 2015 Community Wishlist Survey and we want to make sure you don't miss it this year – or at least can make the conscious choice to ignore if it you want to. The 2015 survey decided what the Community Tech team should work on during 2016. It was also the focus of Wikimedia hackathons and work by other developers. You can see the status of wishes from the 2015 wishlist at 2015 Community Wishlist Survey/Results.
The 2016 Community Wishlist Survey is now open for wishes. You can create proposals until November 20. You will be able to vote on which wishes you think are best or most important between November 28 and December 12. /Johan (WMF) (talk) via MediaWiki message delivery (talk) 11:17, 14 November 2016 (UTC)
No renaming between November 20 and November 27Edit
You’re getting this because you’re a steward or global renamer. The Community Tech team are working on cross-wiki watchlists. We need to add a couple of fields to the localuser table in centralauth database. In order to be able to do this, we’d need to run a script that will get in the way of renaming users. Our apologies – we realize this is getting in the way of your work.
(UTC means that if you live in the Americas, it will be on the evening or afternoon of November 19 when the script starts running, and if you live in Oceania or eastern Asia, it can be closer midday on November 27 before we can be sure the script is no longer running.)
Invitation to discussion about Per-user page blockingEdit
We’re inviting you to join the discussion because you voted or commented in the 2015 Community Wishlist Survey about Enhanced per-user / per-article protection / blocking vote.
For the Anti-Harassment Tools team SPoore (WMF), Community Advocate, Community health initiative (talk) 17:03, 4 October 2017 (UTC)
Please let us know if you wish to opt-out of all massmessage mailings from the Anti-harassment tools team.
Help us design granular blocks!Edit
Hello :-) The Anti-Harassment Tools team at the Wikimedia Foundation will start building these granular blocking tools in a few weeks and we've asked WMF designer Alex Hollender to help us make some wireframes so the tools are intuitive to MediaWiki users.
We have a first draft of how we think this tool should work. You can read the full proposed implementation here but here are the significant parts:
- Granular blocks (page, category, namespace, and file uploading) will be built on top of Special:Block. These blocks will function as if they were regular blocks and allow for the same options, but only take effect on specific pages.
- We will add a new checkbox for "Block this user from the whole site" which will be checked by default. When it is unchecked the admin will be able to specify which pages, categories, and/or namespaces the user should be blocked from editing.
- Granular blocks can be combined and/or overlap. (For example, a user could be simultaneously blocked from editing the articles Rain, Thunder, Lightning, and all pages inside the Category:Weather.)
- Only one block is set at a time, to adjust what the user is blocked from the administrator would have to modify the existing block.
- Block logs should display information about the granular block
- When a blocked user attempts to edit an applicable page, they should see a block warning message which include information on their block (reason, expiration, what they are blocked from, etc.)
- If a category is provided, the blocked user cannot edit either the category page itself and all pages within the category.
- If the File: namespace is blocked, the user should not be allowed to upload files.
We like this direction because it builds on top of the existing block system, both a technical and usability wise. Before we get too far along with designs and development we'd like to hear from you about our prosposal:
- What do you think of the proposed implementation?
- We believe this should be an expansion of Special:Block, but it has been suggested that this be a new special page. What are your thoughts?
- Should uploading files be combined with a File namespace block, or as a separate option? (For example, if combined, when a user is blocked from the File namespace, they would neither be able to edit any existing pages in the File namespace nor upload new files.)
- Should there be a maximum number of things to be blocked from? Or should we leave it up to admin discretion?
We appreciate your feedback on this project's talk page or by email. For the Anti-Harassment Tools team, SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 20:49, 9 May 2018 (UTC)