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

Dear members of the Wikimedia community,

It is worrying to note that volunteer contributors, dedicated to the enrichment of free knowledge, are more and more often the target of attacks from certain media and institutions. These actions compromise not only the security of the individuals concerned, but also the integrity and sustainability of our collaborative projects.

A notable example is the 2013 case involving Rémi Mathis, then president of Wikimedia France. Under pressure from the Direction centrale du renseignement intérieur (DCRI), he was forced to delete a Wikipedia article about a military radio station, allegedly because of classified information. This intervention sparked controversy over the methods used to restrict the dissemination of information, and highlighted the pressure exerted on volunteer contributors.

More recently, journalists from various media have taken the liberty of publicly attacking contributors, going so far as to divulge personal information or make threats. These practices are unacceptable and run counter to the fundamental principles of respect and collaboration that govern our community.

In response to these attacks, Wikipedia's French-speaking community has written an open letter denouncing these acts and calling for collective awareness. This initiative underlines the need to protect our contributors and preserve a safe and healthy working environment for all.

The Wikimedia Foundation's Universal Code of Conduct clearly states that harassment, threats and personal attacks have no place within our projects. It is imperative that these principles are also respected by external actors, be they media or institutional.

We therefore call for a collective mobilization to :

• Strengthen the protection of contributors: put in place effective mechanisms to preserve the anonymity and security of volunteers.
• Raise awareness among the media and institutions: engage in constructive dialogue to make them understand the importance of respecting contributors and the harmful consequences of their actions.
• Promote a healthy collaborative environment: encourage interactions based on mutual respect, benevolence and recognition of each other's work.

Together, let's protect those who work every day to ensure that knowledge is free and accessible to all.

If you have any further questions or discussions, please use the associated discussion page.

Enclosed you'll find the open letter drafted by frwiki, which has already received a large number of signatories from all over the Wikimedia world.

Open Letter drafted by frwiki

Aelxen ^{Équipe EBRC} 14:36, 17 February 2025 (UTC)Reply

Hello everyone!

We’re excited to announce that the next Language Community Meeting is happening soon, February 28th at 14:00 UTC! If you’d like to join, simply sign up on the wiki page.

This is a participant-driven meeting where we share updates on language-related projects, discuss technical challenges in language wikis, and collaborate on solutions. In our last meeting, we covered topics like developing language keyboards, creating the Moore Wikipedia, and updates from the language support track at Wiki Indaba.

Got a topic to share? Whether it’s a technical update from your project, a challenge you need help with, or a request for interpretation support, we’d love to hear from you! Feel free to reply to this message or add agenda items to the document here.

Also, we wanted to highlight that the sixth edition of the Language & Internationalization newsletter (January 2025) is available here: Wikimedia Language and Product Localization/Newsletter/2025/January. This newsletter provides updates from the October–December 2024 quarter on new feature development, improvements in various language-related technical projects and support efforts, details about community meetings, and ideas for contributing to projects. To stay updated, you can subscribe to the newsletter on its wiki page: Wikimedia Language and Product Localization/Newsletter.

We look forward to your ideas and participation at the language community meeting, see you there!

MediaWiki message delivery 08:28, 22 February 2025 (UTC)Reply

To be clear, this question is about Meta-Wiki specifically, hence this page, and not Wikimedia Forum

With Temporary Accounts, we are replacing IP addresses of unregistered editors with a new unique identifier. After this change, the IP addresses of unregistered editors will be hidden from public view. We are making this change to strengthen our support for safety and privacy, to ensure our contributors continue to feel safe.

On the other hand, in some situations, users who protect the wikis (fight spam, vandalism, harassment etc.) need to see IP addresses of unregistered editors to do their work effectively. To balance these needs, our policy is to continue giving some users access to IP addresses of temporary accounts, using the processes described below.

Before we roll out temporary accounts on [this wiki] later this year, we need to clarify who gets to see IP addresses of temporary accounts. We would like to ask you for opinions.

The problem

Currently, the right is given automatically to users who:

1. do have extended rights (e.g. admins, CheckUsers, global sysops, Stewards – see the policy for more examples)
2. do not have extended rights but their local account is a minimum of 6 months old, and who have made a minimum of 300 edits to the local project.

Our problem is only about #2. We have chosen these numerical thresholds before deploying temporary accounts on any wiki. However, it’s become clear to us that these thresholds are quite low and it is still too easy for bad-faith actors to gain access to temporary account IP addresses. We have heard concerns about this from multiple communities, including those in the first pilot group. We want temporary accounts to meaningfully improve editor privacy, so we need to be more restrictive before we roll this feature out on wikis with large communities.

After consulting on other options with Stewards, community members from some of the pilot wikis, and community members active on English Discord, we’re looking for your feedback before we finalize this change.

Our new approach

We are proposing that users without extended rights would be able to apply for the right to view IP addresses of temporary accounts, and admins or stewards would decide whether to grant it. Our goal is to more consistently limit IP address access to only those who need it. This will entail human manual work, but the burden should be less than if we continued to grant the rights automatically.

When we deploy temporary accounts to more wikis, we can evaluate the impact and adjust our approach as needed.

How will this work

• When a user without extended rights needs to view temporary account IP addresses, they will need to file a request for being added to the "Temporary account IP viewers" group. They will file the request to admins (the local communities will be able to decide what that process will be) or stewards (for wikis without local admins).
• The software will require that the user has at least 300 edits and the account since at least 6 months. Admins and stewards will not be able to grant temporary account IP access to accounts that do not meet that criteria. This is a minimum, and we encourage the communities – especially the larger ones – to enforce higher thresholds. Based on the comments from communities piloting temporary accounts, we recommend at least 600 edits as a threshold.
• The user reviewing the request will check if the user applying for the right meets requirements and that they have provided a valid justification. The right itself will be granted through Special:UserRights.
• Users who grant requests for the right will also handle removal of the right.

Note that requirements for access to the IP Info feature will be identical with the ones for access to the temporary accounts' IP addresses.

Our questions to you

• Does the new proposal sufficiently address privacy concerns?
• Are there any consequences for your community we should know as we work on this policy? We would like to make updates to the policy within 2–3 weeks.

In the coming weeks, we will be back to you with more updates and materials about temporary accounts and related features.

Again, thanks to everyone who has helped us identify different options. 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. Thanks! NKohli (WMF) and SGrabarczuk (WMF) (talk) 01:52, 11 March 2025 (UTC)Reply

• "The software will require that the user has at least 300 edits and the account since at least 6 months." that shouldn't be a component for manual vetting. This is a x-wiki project, and there certainly could be usecases such as advanced rights holders on other projects, alternative accounts of established users, etc. — xaosflux ^Talk 10:01, 11 March 2025 (UTC)Reply

  Perhaps allow stewards to grant temp account IP viewer to accounts which don't meet the minimum criteria for use cases like alternative accounts of established users while keeping this restriction for admins, to make sure there's no misuse in local projects? Johannnes89 (talk) 10:10, 11 March 2025 (UTC)Reply

  This seems logical to me. Ternera (talk) 14:17, 11 March 2025 (UTC)Reply

  I agree with Xaoxflux here. If the concern about admins giving the right is so great that a software restriction has to be imposed, they shouldn't be giving the right then. Leaderboard (talk) 11:46, 11 March 2025 (UTC)Reply

  I too agree with what's been said here. //shb (t • c) 11:50, 11 March 2025 (UTC)Reply

  Wouldn't we have the same issue with the current process (automatic granting)? That's why I proposed to allow stewards to grant the permission in certain circumstances regardless of the minimum criteria. Johannnes89 (talk) 15:05, 11 March 2025 (UTC)Reply

  If admins are going to give this out to inappropriate people they are going to - adding a software lock on this is just setting up headaches. That sort of setting is fine for autopromote situations, but having to have devs build and maintain a software restriction routine for this one thing is just adding unnecessary technical debt. — xaosflux ^Talk 15:52, 11 March 2025 (UTC)Reply

  @Xaosflux @Leaderboard @Johannnes89 Is it a frequent use case for someone to do cross-wiki patrolling without holding advanced permissions? We expected users who need to do that will fall in one of the global groups and get access that way. Our reasoning for implementing the restriction is to hedge against the risk that on some projects admins may just hand out this right to many users (maybe through a script) without ensuring they actually need this right. It is unclear if this risk is high but we felt it is prudent to have some restrictions in place. It is not additional technical work since this is the restriction implemented at the moment for minor pilots where temp accounts are deployed. NKohli (WMF) (talk) 17:31, 12 March 2025 (UTC)Reply

  • Are you sure this custom checking software is in production? Unless there is a different special config for this on the production testwiki, I had no problem manually adding a group with that permission to a user without 300 edits on that project. — xaosflux ^Talk 18:10, 12 March 2025 (UTC)Reply
  • Note, there is not such a technical control on much more sensitive groups (e.g. checkusers, stewards, sysadmins, staff). Additionally, specific to this project, as meta-wiki is not a content project - "edits" are rarely used to evaluate users here. — xaosflux ^Talk 18:10, 12 March 2025 (UTC)Reply

    The main issue with just relying on global permissions is that the community is very restrictive about those. E.g. global rollback states "For consideration, users must be demonstrably active in cross-wiki counter-vandalism or anti-spam activities (...) and make heavy use of revert on many wikis". If I'm a local admin and I now want to get involved in fighting xwiki spam, I will do so without having global rollback permissions for at least a couple of months (sometimes much longer) -> no IP access except for the local project where I have admin permissions.

    And looking at local projects there might be use cases where it's desirable to allow accounts which don't meet the minimum criteria to get IP access. Some admins/functionaries create en:WP:SECURESOCKs because they don't want to use their main account when using public wifi / public computers. Such newly created secondary accounts shouldn't need to wait six months to get the same access as the main account.

    I get the concern about manually granting permissions with potential legal implications. I would trust admins on larger projects to handle permissions carefully, but there might be inexperienced admins on small wikis who might accidentally hand out the permissions too lax.

    Xaosflux is right in pointing out that there are no technical restrictions for more sensitive groups, but all of those groups can only be granted by stewards – which is another reason why I propose allowing stewards to grant the permissions regardless of any criteria (while admins should only be allowed to grant it to accounts fulfilling the minimum criteria). Johannnes89 (talk) 18:17, 12 March 2025 (UTC)Reply

February 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 (please translate by March 14, 2025), to read individual articles check out: Category:Education/Newsletter/February 2025. Regards, ZI Jony ^(Talk) 09:00, 12 March 2025 (UTC)Reply