最佳医院排行榜100强没有福建？北京协和闻讯而来

百度 重兵顿于坚城之下实属兵家大忌，白起为了摆脱困境，使出了相当歹毒的一招：水攻。

The Wikimedia Foundation wants to improve how people who experience harassment and other forms of abuse report such harmful incidents to provide safer and healthier environments for communities.

The Trust and Safety Product team has been tasked with building the Incident Reporting System (IRS) (formerly Private Incident Reporting System (PIRS)). We aim to make it easy for users to report harmful incidents safely and privately.

Background

Reporting and processing of harmful incidents has been a topic of interest for Wikimedia communities for many years. With the new Universal Code of Conduct being set up, it is crucial to also have a discussion about user reporting systems.

The way incidents, misconduct and policy violations are dealt with across Wikimedia spaces and projects has developed organically and varies across different communities.

Each Wikimedia project or community has their way of managing things. Reporting and processing of incidents happen in a variety of ways:

• via wiki talk pages
• via noticeboards
• via email
• via private discussions on off-wiki communication channels (Discord, IRC)

For many users, it is unclear what to do if an incident happens: where to go, who to talk to, how to report, what information to include in the report, how the report is processed, what happens afterwards etc.

Users must know how to report an issue and where to do so. There is also very little information on what will happen once a report is made and what expectations the user should have.

Some users do not feel safe reporting incidents when they occur because of the complexity of the reporting process and because of privacy concerns.

There is currently no standardised way for users to file reports privately.

Goals

The high-level goal of this project is to make it easier to address harassment and harmful incidents and ensure those reports reach the appropriate entity that needs to process them.

We want to ensure the privacy and safety of those reporting. We also want to ensure that reports have the right information and are routed to the appropriate entity that needs to process them, while not putting extra pressure on the ones who do the processing.

We are looking at this incident reporting system as part of the larger Wikimedia community incident management ecosystem. We are studying how the individual systems work and how everything can connect.

Updates

June 2025: Stakeholder conversations

To ensure that future development is aligned with community needs and what is feasible, we have paused deployments, and will be conducting conversations with key functionary groups (Stewards, ArbComs, and U4C members) to address concerns and gather input on the IRS's further development.

We will have structured calls with the groups in May-June 2025, with a focus on identifying major concerns and achieving a shared vision for the IRS.

December 2024: Incident Notification System is now available on Portuguese Wikipedia

Incident Reporting System reporting menu on Portuguese Wikipedia.

We implemented the Incident Reporting System on Portuguese Wikipedia on Wednesday, December 11, 2024. Users there can quickly report emergency incidents directly to the Wikimedia Foundation Trust and Safety team or be directed to submit community-managed reports to the appropriate community pages - all from a single, centralized platform.

To report an incident, users can access the reporting functionality in the Discussion Tools menu by clicking the ellipsis menu or the overflow menu (...) next to each comment, and then click Report.

If you have any comments, please share them on the project talk page.

December 2024: Upcoming pilot

We have released the first version of the Incident Reporting System which is now available on Beta. Visit a talk page, choose any comment and click the menu to access the reporting link.

In response to your comments, we have made some updates to the designs. You can check the latest designs here:

Emergency workflow

• 
• 
• 
• 

Non-emergency workflow

• 
• 
• 
• 

We will be enabling the Incident Reporting System on testwiki on December 9 for another round of testing and fixing bugs. If everything goes well we will be enabling the system on Portuguese Wikipedia likely in the week of 10 December.

We will share another update once we are live on testwiki and then on Portuguese Wikipedia.

November 2024: Improvements to the features

Our next step will be to develop a version that we can test on a few pilot wikis. We have made improvements to the design:

• Emergency incidents - Incidents relating to immediate threats of physical harm. These incidents need to be handled by the Wikimedia Foundation Trust and Safety team responding to emergency cases.
• Non-emergency incidents - Incidents that are not immediate threats of harm, for example bullying, sexual harassment and other unacceptable user behavior. These incidents are handled through local community processes.

The Emergency flow will direct users to file a report that will be sent to the Trust and Safety team.

The Non-emergency flow will direct users to reach out to their local community for support, as outlined in community policies. This will be done through a “Get support” page that will contain links and information specific to each community. The intention is to have configuration options on this page so that each local community can add the relevant links as necessary.

We have some screenshots to demonstrate how this might work. For the next deployment the main focus is to test the emergency flow in production.

Emergency flow:

• 
  IRS emergency report button
• 
  Design showing how users can describe an emergency incident when reporting
• 
  Design showing how users can add additional information when reporting immediate threat of harm
• 
  Design showing confirmation users see after reporting immediate threat of harm

Non-emergency user flow:

• 
  IRS non-emergency report button
• 
  Design showing how users can describe an incident when reporting
• 
  Design showing the types of unacceptable behaviour users will see when reporting
• 
  Design showing how users can get support for unacceptable behaviour on the wikis
• 
  Design showing how users can get support for unacceptable behaviour on the wikis

We’d love to hear your thoughts on the current designs! Please comment on the discussion page.

Please see the research section of the page for more.

July 2024: User testing summary

In March 2024, the Trust & Safety Product team conducted user testing of the Minimum Viable Product (MVP) of the Incident Reporting System to learn if users know where to go to report an emergency incident, and if the flow makes sense and feels intuitive.

We learned the following:

• During user testing, all participants found the entry point to report an incident and the current flow is well understood.
• There was some confusion over two of the reporting options: “someone might cause self-harm” and “public harm threatening message”.
• Two participants also made assumptions about the system being automated. One participant was concerned about automation and wanted a human response, whereas the other participant felt assured by the idea it would check if the abuser had any past history of threats and offences, and delete the offensive comment accordingly.
• All participants expected a timely response (an average of 2-3 days) after submitting a report.

Read more.

September 2023: Sharing incident reporting research findings

Research Findings Report on Incident Reporting 2023

We have completed research about harassment on selected pilot wikis. The research, which started in early 2023, studied the Indonesian and Korean Wikipedias to understand harassment, how harassment is reported and how responders to reports go about their work. In summary, we received valuable insights on the improvements needed for both onwiki and offwiki incident reporting. We also learned more about the communities' needs, which can be used as valuable input for the Incident Reporting tool. Please leave any feedback and questions on the talkpage.

Project phases

As this is a complex project it needs to be split into multiple iterations and phases. For each of these phases we will hold one or several cycles of discussions to ensure that we are on the right track and that we incorporate community feedback early, before jumping into large chunks of work.

Phase 1

• Preliminary research: collect feedback, reading through existing documentation.
• Conduct interviews to better understand the problem space and identify critical questions we need to answer.
• Define and discuss possible product direction and scope of project. Identify possible pilot wikis.
• At the end of this phase we should have a solid understanding of what we are trying to do.

Phase 2

• Create prototypes to illustrate the ideas that came up in Phase 1.
• Create a list of possible options for more in-depth consultation and review.

Phase 3

• Identify and prioritize the best possible ideas.
• Transition to software development and break down work in Phabricator tickets.
• Continue cycle for next iterations

Pre-project research

The following document is a completed review of research from 2015–2022 the Wikimedia Foundation has done on online harassment on Wikimedia projects. In this review we’ve identified major themes, insights, and areas of concern and provided direct links to the literature.

Our team has been studying previous research and community consultations to inform our work. We revisited the Community health initiative User reporting system proposal and the User reporting system consultation of 2019. We have also been trying to map out some of the conflict resolution flows across wikis to understand how communities are currently managing conflicts. Below is a map of the Italian Wikipedia conflict resolution flow. It has notes on opportunities for automation.

• 
  A synthesis of research from 2015–2022 that identifies major themes in the problem space as well as user needs, challenges, considerations, and previous work.
• 
  On Italian Wikipedia, there's a 3-step policy in place for conflict resolution. This map visualizes this process and tries to identify opportunities for automation for both editors and admins.

Frequently asked questions

Questions and answers from Phase 1 of the project

The project used to be called PIRS, Private Incident Reporting System. Why was the P dropped?

We have renamed the Private Incident Reporting System as Incident Reporting System. The word "Private" has been removed. In the context of harassment and the UCoC the word “Private” refers to respecting community members’ privacy and ensuring their safety. It does not mean that all phases of reporting will be confidential. We have received feedback that this term is therefore confusing and can be difficult to translate in other languages, hence, the change.

Is there data available about how many incidents are reported per year?

Right now there is not a lot of clear data we can use. There are a couple of reasons for this. First, issues are reported in various ways and those differ from community to community. Capturing that data completely and cleanly is highly complicated and would be very time consuming. Second, the interpretation of issues also differs. Some things that are interpreted as harassment are just wiki business (e.g. deleting a promotional article). Review of harassment may also need cultural or community context. We cannot automate and visualize data or count it objectively. The incident reporting system is an opportunity to solve some of these data needs.

How is harassment being defined?

Please see the definitions in the Universal Code of Conduct.

How many staff and volunteers will be needed to support the IRS?

Currently the magnitude of the problem is not known. So the amount of people needed to support this is not known. Experimenting with the minimum viable product will provide some insight into the number of people needed to support the IRS.

What questions are you trying to answer with the first version of the product?

Here are the questions we need to answer:

• What kind of reports will people file?
• How many people will file reports?
• How many people would we need in order to process them?
• How big is this problem?
• Can we get a clearer picture of the magnitude of harassment issues? Can we get some data around the number of reports? Is harassment underreported or overreported?
• Are people currently not reporting harassment because it doesn’t happen or because they don’t know how?
• Will this be a lot to handle with our current setup, or not?
• How many are valid complaints compared to people who don't understand the wiki process? Can we distinguish/filter valid complaints, and filter invalid reports to save volunteer or staff time?
• Will we receive lots of reports filed by people who are upset that their edits were reverted or their page was deleted? What will we do with them?

How does the Wikimedia movement compare to how other big platforms like Facebook/Reddit handle harassment?

While we do not have any identical online affinity groups, the Wikimedia movement is most often connected with Facebook and Reddit in regard to how we handle harassment. What is important to consider is nobody has resolved harassment. Other platforms struggle with content moderation, and often they have paid staff who try to deal with it. Two huge differences between us and Reddit and Facebook are the globally collaborative nature of our projects and how communities work to resolve harassment at the community-level.

Is the Foundation trying to change existing community processes?

Our plan for the IRS is not to change any community process. The goal is to connect to existing processes. The ultimate goals are to:

• Make it easier for people who experience harassment to get help.
• Eliminate situations in which people do not report because they don’t know how to report harassment.
• Ensure harassment reports reach the right entities that handle them per local community processes.
• Ensure responders receive good reports and redirect unfounded complaints and issues to be handled elsewhere.