System Raportowania Incydentów
Wikimedia Foundation chce ulepszyć sposób raportowania incydentów przez osoby, które doświadczają nękania lub innych form nadużyć, aby zapewnić wolontariuszom bezpieczniejsze i zdrowsze środowisko.
Zadanie stworzenia Systemu Prywatnego Raportowania Incydentów (SPRI) zostało powierzone nowo sformowanemu zespołowi Narzędzi do Zaufania i bezpieczeństwa (Trust and Safety Tools). Chcemy, aby łatwe było zgłaszanie nieprzyjemnych zdarzeń w sposób bezpieczny i niepubliczny.
Tło
Zgłaszanie i przetwarzanie szkodliwych incydentów jest przedmiotem zainteresowania społeczności Wikimediów od wielu lat. Wraz z ustanowieniem nowego Powszechnych Zasad Postępowania, niezwykle ważne jest również przeprowadzenie dyskusji na temat systemów zgłaszania użytkowników.
Sposób radzenia sobie z incydentami, niewłaściwym zachowaniem i naruszeniami zasad w przestrzeni Wikimediów rozwijał się w sposób niezaplanowany, różni się więc w zależności od społeczności.
Każdy projekt i społeczność Wikimedia ma swój sposób zarządzania. Raportowanie i przetwarzanie zdarzeń odbywa się na różne sposoby:
- poprzez strony dyskusji na wiki
- poprzez tablice ogłoszeń
- przez e-mail
- w prywatnych dyskusjach poza wiki (Discord, IRC)
Dla wielu użytkowników nie jest jasne, co zrobić, kiedy coś się wydarzy: gdzie się udać, z kim porozmawiać, jak zgłosić nieprawidłowości, jakie informacje dołączyć w zgłoszeniu, jak ono będzie dalej procedowane, co zdarzy się potem itp.
Użytkownicy muszą wiedzieć, jak i gdzie zgłosić problem. Brakuje również informacji o tym, co się stanie po utworzeniu zgłoszenia i czego użytkownik powinien się spodziewać.
Niektórzy nie czują się bezpiecznie podczas zgłaszania incydentów z powodu złożoności procesu powiadamiania lub z obaw o prywatność.
Aktualnie nie ma ustandaryzowanego sposobu wysyłania niejawnych zgłoszeń.
Cel projektu
Wysokopoziomowym celem niniejszego projektu jest ułatwienie reagowania na nękanie i inne szkodliwe zdarzenia.
Chcemy zapewnić prywatność i bezpieczeństwo zgłaszających. Zależy nam także na tym, aby zgłoszenia miały odpowiednie informacje i docierały do odpowiedniego podmiotu, który je przetworzy, bez nakładania dodatkowej presji na osoby zajmujące się ich przetwarzaniem.
Zespół Trust and Safety Tools patrzy na ten system raportowania incydentów jako część większego ekosystemu zarządzania zdarzeniami w celach np. prewencyjnych (takich jak zauważanie nieporozumień zanim eskalują, przetwarzania incydentów czy łączenia i śledzenia wydarzeń).
Produkt i aktualizacje techniczne
Incident reporting update: November 7, 2024
We’re continuing the work on the Incident Reporting System.
The next step is to develop an MVP (Minimum Viable Product) that we can test in production on a few pilot wikis. Following our Minimum Testing Product (MTP) user testing some months ago, 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 emergency team.
- 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 user flow will direct users to file a report that will be sent to the Wikimedia Foundation emergency team.
The Non-emergency user 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 user flow in production.
Designs
Emergency flow:
Non-emergency user flow:
We’d love to hear your thoughts on the current designs! Please comment on the discussion page.
Przetestuj podstawowe funkcje Systemu Zgłaszania Zdarzeń w Beta - 10 listopada 2023
Zapraszamy edytorów Wikimedia do przetestowania minimalnej wersji testowej systemu raportowania zdarzeń. Zespół produktu w ramach Trust and Safety stworzył podstawową wersję narzędzia, które pozwala zgłosić zdarzenie z poziomu dyskusji strony, na której owo zdarzenie wystąpiło. Uwaga: ta wersja narzędzia przeznaczona jest do testowania przesyłania zgłoszeń na niejawne adresy mailowe, takie, jak emergencywikimedia.org, czy do grup administratorów. Nie obejmuje ona wszystkich scenariuszy użycia, jak na przykład zgłaszanie zdarzeń na publiczne tablice ogłoszeń. Potrzebne są Wasze komentarze, by sprawdzić, czy takie podejście jest skuteczne.
Aby przetestować narzędzie:
1. Wejdź na dowolną stronę dyskusji Wikipedii Beta. Przykładowe strony dyskusji, dostępne po zalogowaniu to User talk:Testing i Talk:African Wild Dog.
2. Kliknij ikonę wielokropka blisko linku "Reply" w dowolnym komentarzy i wybierz polecenie "Report" - patrz slajd 1. Link do zgłoszenia zdarzenia znajdziesz również w menu Tools - jak na slajdzie 2.
-
Slajd 1
-
Slajd 2
3. Wpisz zgłoszenie, wypełnij formularz i wyślij go. Do zespołu Trust and Safety, i tylko do niego, zostanie wysłany email. Pamiętaj, to tylko test, nie korzystaj z formularza do zgłaszania rzeczywistych zdarzeń do zespołu T&S.
4. Podczas testowania, zastanów się nad poniższymi kwestiami:
- Co sądzisz o takim procesie zgłaszania, a szczególnie co Ci się w nim podoba i nie podoba?
- Jeśli znasz rozszerzenia MediaWiki, co myślisz o wdrożeniu takiego rozszerzenia na swojej wiki?
- Czego zabrakło na tym etapie zgłaszania zdarzeń?
5. Po przeprowadzeniu testu, wypisz swoje uwagi na tej stronie dyskusji.
Jeśli nie widzisz menu z wielokropkiem lub linku "Report", albo jeśli formularz się nie przesłał, upewnij się, czy:
- jesteś zalogowany/-a
- Twój adres na Wikipedii Beta został potwierdzony
- Twoje konto istnieje od co najmniej 3 godzin i wykonało co najmniej 1 edycję
- włączyłeś/-aś rozszerzenie DiscussionTools, gdyż narzędzie które testujesz, jest z nim zintegrowane
Jeśli narzędzie DiscusionTools nie ładuje się, możesz to zgłosić z poziomu menu "Tools". Jeśli nie udaje Ci się przesłać drugiego zgłoszenia, zauważ, że dla użytkowników niezatwierdzonych limit wynosi 1 raport dziennie. Dla użytkowników zatwierdzonych jest to 5 zgłoszeń dziennie. To ograniczenie w fazie testowania ma zapobiec złośliwym testom.
Please see the research section of the page for more.
Przebieg
Ponieważ jest to złożony projekt, należy go podzielić na wiele iteracji i faz projektu. Dla każdej z tych faz przeprowadzimy jeden lub kilka cykli dyskusji, aby upewnić się, że jesteśmy na właściwej drodze i że uwzględnimy opinie społeczności już na wczesnym etapie, zanim przejdziemy do prac nad większymi fragmentami.
Faza 1
Badania wstępne: zebranie opinii, zapoznanie się z istniejącą dokumentacją.
Przeprowadzanie wywiadów, aby lepiej zrozumieć przestrzeń problemową i zidentyfikować krytyczne pytania, na które trzeba odpowiedzieć.
Zdefiniowanie i omówienie możliwego kierunku produktu oraz zakresu projektu. Ustalenie potencjalnych pilotażowych wiki.
Pod koniec tej fazy powinniśmy mieć solidne zrozumienie tego, co próbujemy zrobić.
Faza 2
Stworzenie prototypów, aby zilustrować pomysły, które pojawiły się w fazie 1.
Stworzenie listy możliwych opcji do bardziej dogłębnej konsultacji i recenzji.
Faza 3
Identyfikacja i priorytetyzacja możliwie najlepszych koncepcji.
Przejście do rozwoju oprogramowania i rozbicie pracy na zgłoszenia w Phabricatorze.
Kontynuacja cyklu dla następnych iteracji
Badania
July 2024: Incident Reporting System 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 user 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 user 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
The Incident Reporting System project has 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.
The findings of the studies have been published.
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.
We are keen to share these findings with you; the report has more comprehensive information.
Please leave any feedback and questions on the talkpage.
Poniższy dokument jest ukończonym przeglądem badań przeprowadzonych w latach 2015-2022 przez Wikimedia Foundation na temat nękania w sieci w projektach Wikimedii. W tym przeglądzie zidentyfikowaliśmy główne tematy, spostrzeżenia i obszary zainteresowania oraz podaliśmy bezpośrednie linki do literatury.
Zespół Trust and Safety Tools brał pod uwagę wcześniejsze badania i konsultacje ze społecznością, aby ukierunkować swoją pracę. Wróciliśmy do propozycji systemu zgłoszeń od użytkowników w ramach Inicjatywy zdrowia społeczności oraz do Konsultacji systemu z 2019 roku. Próbowaliśmy również rozrysować przebiegi niektórych systemów rozwiązywania konfliktów, wykorzystywanych na wiki, aby zrozumieć, jak społeczności radzą sobie z problemami. Poniżej znajduje się diagram sposobu działania w obliczu konfliktu na włoskiej Wikipedii. Zawiera on uwagi o możliwości automatyzacji.
Najczęściej zadawane pytania
Q: 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.
Czy są dostępne dane o ilości zgłaszanych incydentów na rok?
A: 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.
Q: How is harassment being defined?
A: Please see the definitions in the Universal Code of Conduct.
Q: How many staff and volunteers will be needed to support the IRS?
A: 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.
Q: What is the purpose of the MVP (minimal viable product)?
A: The MVP is an experiment and opportunity to learn. This first experimental work will answer the questions that we have right now. Then results will guide the future plans.
Q: What questions are you trying to answer with the minimum viable product?
A: 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?
Q: How does the Wikimedia movement compare to how other big platforms like Facebook/Reddit handle harassment?
A: 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.
Q: Is WMF trying to change existing community processes?
A: 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.