SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

March 2025 education newsletter released for translation. Please help our readers to read education newsletter in their native language. The latest education newsletter is ready for translation: here Newsletter headlines link for translation: here, to read individual articles check out: Category:Education/Newsletter/March 2025. Regards, ZI Jony ^(Talk) 15:04, 10 April 2025 (UTC)Reply

The voting period for the revisions to the Universal Code of Conduct Enforcement Guidelines and U4C Charter closes on 1 May 2025 at 23:59 UTC (find in your time zone). Read the information on how to participate and read over the proposal before voting on the UCoC page on Meta-wiki.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this message with members of your community in your language, as appropriate, so they can participate as well.

In cooperation with the U4C --

Hello! This is the Trust and Safety Product team. In March, we proposed who should see IP addresses when temporary accounts have been introduced. We were talking with about 20 large communities! Thanks for the conversations, and for your patience as we framed the responses. Now, we would like to address some recurring themes, clarify aspects which we didn't present plainly in our first message, and share what the next steps will be.

Outcome of the discussions we have had

Your comments helped us better understand risks and concerns around patrolling. These included: how you see a new burden on administrators, how you deal with patrolling old edits, how many (or few) people take part in patrolling on your wikis, and more. We are very grateful for these thoughts.

You also wrote many comments with general questions about temporary accounts. You were asking how they work, how to reveal IP addresses, whether the change is needed, etc. We are working on features for users with advanced rights like the onboarding dialog, Special:GlobalContributions, Special:IPContributions, global account blocks, mass-global account blocks, and more. This is all to help you combat abuse efficiently.

About the requirements for access – we have decided to go ahead with the idea of admins (and where needed, stewards) manually granting the right to view IPs to those who need it. (T390942) The options we can consider are limited. The basic Access to Temporary Account IP Addresses Policy (which we will update soon) must be one for all wikis, acceptable for global functionaries and various communities, and also from the perspective of editors in different countries and the legal risks. This is why we can't strictly follow local consensus or grant access to IP addresses too broadly. Later this year, we may revisit topics like requirements or exceptions to the policy. (You may create your local policies, though! – more about it below.)

We would like to remind you that the deployment across all wikis needs to happen this year. There will be two large phases of deployments – in June/July, and about 2–3 months later.

Recurring themes, our responses, and clarifications

For your convenience, we will also document some of these replies in the project FAQ.

Access to IP addresses

• Separation of the new right (checkuser-temporary-account) out to a new group (Temporary account IP viewers), as opposed to technically attaching it to any existing group (like patroller). We have decided to do this for a few reasons:
  • Having access to IP addresses carries risk. This right is similar to checkuser. IP addresses are considered personally identifiable information (a kind of personal data). Outside actors who want to access IP addresses will now need to interact with users who have this right. Users with this right should be aware of this, and alert to the possibility of suspicious access requests.
  • Good practices for privacy protection. Giving access to users who are trusted but do not need access to carry on their work is not in line with good practices for processing personal data.
  • Removal of right. Access to IPs will be logged (example). If any misuse of this right is detected, it can be taken away separately from any other permissions the user may hold. It would be difficult and sometimes also unreasonable to remove the rights unrelated to access to IP addresses.
  • You may grant the new right to all users belonging to a certain existing group individually. These users must meet the criteria for Temporary account IP viewers, though.
  • For clarity – all this does not affect administrators, bureaucrats, checkusers, stewards, and other groups mentioned in the global policy.
• Activity requirement. With regards to users who would need to be granted access manually, the policy says that they "must edit or take a logged action to the local project at least once within a 365-day period". This requirement is not changing.

Process of granting the right

• Formality of granting the right. There is no need for long discussions or votes like Request for Adminship. It does suffice if a single admin makes a decision using their own judgement.
• Additional requirements for the users applying for the right.
  • You have autonomy over the process for granting the right. You can adopt thresholds higher than 300 edits, or disallow the "non-admin+" users to have the right. The granting process can be as basic or elaborate as you deem appropriate.
  • It wasn't clear which criteria admins should take when deciding whether to grant the right – how to tell whether a user needs access to IP addresses. There are no mandatory requirements beyond a minimum of 300 edits and a 6 month old account. You may introduce additional criteria related to trust to the user (such as no prior blocks or copyright violations) or experience in patrolling activities.
• Additional burden on administrators. We understand the toil of having to grant and remove an additional right. This is indeed a downside. We think that it will only have to be a one-time effort to grant this right to a larger number of people. We are curious if you can find ways to limit this burden.

How patrolling works with temporary accounts enabled

• "Retro-patrolling" and 90 days. In a few wikis, community members wrote that "retro-patrolling" (patrolling old edits) may be an issue with a 90-day limit to temporary accounts IPs. In our understanding (this is consulted with the stewards), in typical situations, 90 days after the edit, the main challenge is the cleanup work, and not necessarily the need to connect the identity of abusers. But we understand that there may be different situations on different wikis, and some vandals are creative. In any case, the 90-day limit doesn't apply to behavioral evidence or patterns of editing – these will continue to be visible. The number itself may be changed, and we will be paying attention to your thoughts and evidence of more difficult investigation. It is important to note that for instances of proven long-term abuse behaviors, we can publicly document the IP address for patrolling needs.
• Account creation limit ("rate limit"). Only six temporary accounts can be created from one IP within 24 hours. This limit is intended to prevent a vandal from creating a lot of accounts in a short time. The limit is the same for registered account creations. It is not a perfect measure, but it is similar to an older mechanism we are all familiar with, and does define a basic level of protection.

Next steps on your side we would like to suggest

• We are encouraging you to start granting the right before temporary accounts are launched so that you are prepared when the time comes.
• We are encouraging you to consider adopting a policy on granting and removing the right, if you think you need to add anything to the global policy.
• We would like to show you what level of wiki-bureaucracy seems sufficient from our point of view. In the sandbox, we have created a draft of what a page with requests for the flag could look like. Of course the final content of the page will depend on your community. We do not want to imply that we are instructing you on this matter.

Keep in touch

As always, if you'd like to learn more about the project, read the Diff post, visit our project page and the FAQ. Subscribe to the newsletter to stay in touch. If you are interested in the pilot deployments satisfaction survey, take a look at the results. Thanks! NKohli (WMF) and SGrabarczuk (WMF) (talk) 21:23, 5 May 2025 (UTC)Reply