Universal Code of Conduct/2021 consultations/Enforcement/Italian community
Introduction
[edit]The Italian version of Wikipedia was started on May 11, 2001, and it is currently the 8th largest Wikipedia with 1,683,964 articles and 10,286 active users, total edits are 119,671,379 (Data: 2. April 2021).
Editors come mainly from Italy and the Italian-speaking areas in Switzerland, small numbers from other European countries and the Americas (source: https://stats.wikimedia.org).
There are 113 admins, 6 bureaucrats, and 9 checkusers with a yearly reconfirmation procedure for admins and CUs.
Together with the Italian Wikipedia, the consultation also involved the most active regional projects (eml, lij, lld, lmo, nap, pms, sc, scn and vec) and the sister projects in the Italian language (Wikisource, Wikinews, Wikibooks, Wikiversity, Wikiquote, Wiktionary, and Wikivoyage).
Reactions to UCoC
[edit]Before the beginning of the drafting phase (July 2020), a message was posted in the VP informing the community about UCoC and the drafting process. During the policy’s drafting phase, a group of experienced users and admins gave some advice about the draft and helped with the translations. Thus, a part of the community was already aware of UCoC.
Most questions during this time and after the approval of the UCoC policy from the Board were about:
- the process of conforming the existing Italian conduct and reporting guidelines to UCoC (starting from w:it:Wikipedia:Wikiquette)
- deadlines for this,
- the possible changes in the ways Wikimedia Foundation intervenes in the projects
- legal implications of the code of conduct.
Summary of behavioural policies in the community
[edit]The Italian Wikipedia has a quite complete framework of behavioural guidelines and reporting pages to address different kinds of behaviours that violate the UCoC and to deal with conflicts among users. The main collector of messages for issues that have not a dedicated page is the admins noticeboard (shortcut WP:RA) from where users are directed to the correct page or procedure.
There are escalation pathways for the resolution of conflicts, starting from the invite to discuss on talk pages, to the opening of an RFC, and as the last option the opening of a “problematic users” procedure. There is no ArbCom.
Administrators tend to often act as mediators (some guidelines also expressly suggest they regularly should). Within the project, there is a quite low level of tolerance for behaviours that negatively impact editorial activity. During the consultation there were no negative reactions to the UCoC.
- Pages describing reporting methods or ways to deal with conflicts
- w:it:Wikipedia:Molestie - Description of harassment, there is a section about how to react to harassment
- w:it:Wikipedia:Rispondere a minacce di atti violenti - Threats of harm
- w:it:Wikipedia:Risoluzione dei conflitti - How to approach and deal with conflicts
- w:it:Wikipedia:Problemi con utenti o amministratori - Description of the escalation of conflicts
- w:it:Aiuto:FAQ and w:it:Aiuto:FAQ/Comunità - In these pages there is a section about interaction with other users
- w:it:Progetto:Patrolling/Manuale esteso1 - In the help pages for patrolling there is a small section about the handling of conflicts
- Reporting pages
- w:it:Wikipedia:Richieste di pareri/Comportamenti degli utenti - Request for comments about possible problematic behaviours of any user group, so admins too
- w:it:Wikipedia:Utenti problematici - RFC for problematic behaviours of registered users
- w:it:Wikipedia:Utenti problematici/Segnalazioni di gruppo - Same as above but for groups of users who act in a coordinated way
- w:it:Wikipedia:Vandalismi in corso - Vandalism and rfc about anons
- w:it:Wikipedia:Segnalazione NUI - Reporting of inappropriate usernames
- w:it:Wikipedia:Richieste agli amministratori - Admin noticeboard
Facilitation process
[edit]When the consultation started in addition to the announcement on the VP, a dedicated set of pages for the consultation was created on the Italian Wikipedia, a general page with a description of the goals of the consultation and how to engage; a general discussion page, and a FAQ page, that was partly adapted from Meta’s FAQ page but also with a more general description of the process.
In order to involve in the conversations also new users or users who are not so familiar with the existing guidelines, a very elementary gamification was used creating some scenarios where users could try to imagine solutions or suggestions. Active users were contacted via email, personal, and group calls. From 9 to 16 February a survey was also linked in the sitenotice.
69 users participated in the engagement through diverse on and off wiki conversations and 1911 users engaged by participating in the survey.
In every VP of regional and sister projects, an announcement was published at the beginning of the consultation. This was followed up by another post a week later to invite users to answer some easy questions and to invite them to take part in the survey.
A group of event organisers (itwikicon and editathon) was also contacted.
Active female users and participants in the LGBT project on the Italian Wikipedia were contacted via email.
Response rate
[edit]The response on public pages was poor. Apart from the anonymous survey, the highest responses came from one to one contacts. Gamification was able to involve some new users or less experienced users.
There were very few responses from regional projects and sister projects, in one of them, users had to dig deep into the past to find the last incident about behaviour and to recollect how it was handled.
Main questions in the consultation
[edit]Reporting of inappropriate behaviour
[edit]24,8% of respondents of the survey stated that they have been either victim or witness of some form of inappropriate behaviour in Wikimedia projects. When asked which difficulties they had faced in reporting, they raised the following ones:
- Visibility: Respondents reported difficulties in finding the pages where to report, some respondents did not know the existence of reporting pathways.
- Anonymity: Some users feared retaliation from other users or from admins. Some respondents do not trust the impartiality of people dealing with reports.
Among the suggestions given by community members for making reporting easier or more visible:
- A “report” link on every page,
- A link for reporting in the tools area in the sidebar menu,
- explain reporting pathways in the welcome message, or in a pop-up during registration
- somebody suggested putting a “big red button” somewhere where it is easy to see and find.
One of the focus questions was about reporting serious harassment or threats. There is general agreement that reporting procedures for threats/serious harassment should be well known within the community. Currently only 50,7% out of 1838 respondents said that they know how and where to report these sorts of incidents. On the admins side, there is a general feeling that direct contact with some LE agency would be more efficient and possibly speed things up.
To the question about opinions about a private reporting tool, 67,8% of respondents think that along with the existing pages, a private tool for reporting could be useful:
| Would a private reporting tool be useful? |
|---|
To the question about an easy private tool to report inappropriate behaviour, respondents (1758) answered in this way:
| What tool would you consider useful? |
|---|
Among the suggestions in the “other” option, there are ideas about having chats and instant messaging tools available for reporting. But, some worries about a private reporting tool were also expressed because it goes against the transparency principle. Some respondents also stressed the importance of providing an acknowledgment on reports. They pointed out that some form of acknowledgment is important to reassure the reporting person that “somebody” is taking care of the report.
When asked about how to balance a private tool with transparency and accountability, suggestions were towards a ticketing system together with some way to keep track within the project of the number of “open cases” in an anonymized way.
Another question was about ways to balance privacy with the need to track persistent abusers and cross-wiki problems. The target for this question was the admin group. Suggestions are in the direction of some cross-wiki restricted areas where info about LTAs and other cross-wiki issues could be kept and shared. Some concerns about mailman security were raised in the comments about communication tools and sysop mailing lists.
Incidents happening outside of the projects
[edit]16,4% out of 1818 respondents declared that they have been either victim or witness of some form of inappropriate behaviour outside of the projects (on or offline) but linked with the activity within the projects.
When asked if these violations should be considered within Wikimedia projects and how to deal with them, slightly more than half (52,6%) of the respondents to this question (1741) agree that these behaviours should be in some way taken into account within the projects, 43,3% think they should be reported within the social media or external organization using their tools and 34,5% think it is a matter for T&S.
A minority of users think that things happening outside of the projects should not be considered. I have to admit that in the survey this question was not worded in the best way and the multiple-choice option was not the correct choice so the results on this specific issue are not completely satisfactory.
The same issue was raised during one to one consultations, there have been cases of serious harassment and doxxing on social media or personal websites, for these incidents reporting to T&S and some sort of legal support are considered very important.
Another issue about external spaces is the existence on different platforms of informal groups containing the name "wiki*edia" and thus conveying the idea that they are official groups. These groups are not managed or moderated by people chosen from the community and often there are unacceptable behaviours in the form of rude answers or other ways of inappropriate communications. One of the suggestions was to have some "official spaces", like the IRC chans, with a defined scope and rules based on UCoC.
Dealing with reports
[edit]The question in the survey was who should take care of the reports and deal with the reported incidents?
| Who should deal with reports and incidents? |
|---|
Among the suggestions in the “Other” section, there are also
- a dedicated and mixed group of admins and users
- a mixed group of local and global users.
A broadly shared suggestion is to create different levels of respondents (local and global) depending on the seriousness of the incident. Some respondents pointed out that anybody responding to reports should have experience in the projects and the ability to evaluate the seriousness of reported incidents.
Some users expressed worries about impartiality, the reaction time, and the skills of the persons responding to reports.
During one to one consultations some users expressed the need for a clear definition of harassment to be shared within the project, fears are that normal forms of maintenance (like deletions, moves to sandbox, reverts) could be misinterpreted as forms of harassment and be reported increasing the number of reports to deal with.
Another question was about possible ways to deal with an increase in the number of reports. Making reporting easier and more visible will probably increase not only the number of reports but possibly the abuses by trolls or bad actors. The suggested solutions for dealing with high numbers but also with abuse of the tool (including users who do not understand how to use it or use it to report errors or content-related issues) go from dedicated menus with a list of choices within the reporting tool to some sort of filtering system with different levels of priority making sure that “serious” reports do not get lost. It was also stressed that escalation pathways should be well explained within the project.
Support for targets for harassment
[edit]General suggestions are that incoming reports involving vulnerable people should be checked by a group and not a single person. The same group that takes care of serious cases should have specific skills and be backed up by specialists like legal experts or psychologists.
Specific feedback about a global body
[edit]Assuming the establishment of some sort of global body that should deal with dispute resolution and UCoC linked issues there were some sentences respondents could express their level of (dis)agreement upon.
| The decision to create this "global body" should be taken by the global community |
|---|
| 1=Do not agree, 5=Agree |
| Scope and area of intervention should be defined very clearly |
| The global body should be consulted without linguistic barriers |
| The global body should take care of all Wikimedia projects |
| The global body should take care only of small projects which don't have own guidelines/procedures |
| Larger communities should be allowed to opt-out from the "jurisdiction" of this global body |
Summarizing the results in the space left for suggestions about this body, respondents expressed comments about:
- scope: Some respondents would consider the choice for projects to opt-out only if the project has a similar local body that is in some way controlled or supervised by the global body or if a periodical audit of local procedures is planned.
- composition: Different suggestions about the composition of the member, indications are about including normal users, people from all over the world, and staff from WMF. Some persons expressed doubts about compatibility (possible COI with working in different roles) of the membership in the global body and other roles within the projects. There is general agreement on the fact that members should have some form of training and/or support from experts while dealing with complicated cases.
- method: Some respondents wrote that it is essential that this body grants fair hearings and listens to both parties in disputes (w:Audi alteram partem).
- risks: Some respondents pointed out risks connected with possible COI or personal involvement in the conflict.
- prevention activities: A significant number of respondents pointed out that one of the tasks of this global body should be the “prevention” of conduct violations. This can be done organizing activities to raise awareness, support smaller communities in assessing compliance with their guidelines to UCoC, and generally acting as some form of consulting body for projects and communities in matters related to UCoC.
The main concern about a global body is about the ability of a similar institution to deal with cultural differences, understand language nuances, deal with cross-cultural issues, and be really able to take care of minorities.
Assessing and measuring
[edit]One of the goals of the LLC was also to collect suggestions about possible ways to assess and measure how successful a community is in protecting its members from harassment. This was the final question in the “game” and the suggestions of the participants go towards three types of measures:
- Quantitative measures
- Number of blocks for behavioural reasons
- Number of reports about behaviour issues
- Ratios
- Number of admins/Number of active users or Number of admins/Number of pages or articles
- number of "solved" reports compared with the number of reports
- Number of reports compared with the dimension of the project (number of active users or articles)
- Ratio (admin+rollbackers)/total active users
- Qualitative measures
- Existence of reporting pages
- Existence of pages explaining the reporting pathways for the different issues
- Existence of admins/dedicated usergroups dealing with reports
- Existence of tools to find bad words and similar (filters and similar tools)
- Periodical (yearly) survey
- Some ways to assess the quality of the help pages and guidelines
- Specific guidelines for offline events
During one to one conversations the proposal to have a periodical survey in local language was the most common.
Feedback from sister and regional projects
[edit]Users in sister projects are frequently also users of the Italian Wikipedia and are thus familiar with reporting tools and the ways of the Wikimedia environment. This is less frequent in regional projects that tend to have dedicated users who usually are not really aware of the whole environment and have sometimes the tendency to get a little “territorial”.
Among sister and regional projects, only some have a notice board for administrators. Sometimes users are not even aware of vandalism because SWMT is dealing with that.
On one side, the incidents of conduct violations are really rare. But, on the other hand, there are cases where users who were blocked from Wikipedia for behavioural issues start to contribute to smaller projects thereby bringing their behaviour into projects which are not ready to deal with these issues.
Some concerns were expressed about the loss of independence or autonomy in case of the creation of some external body. Yet, on the other side, some have also expressed fears about a hostile takeover. In the words of one admin - ”I have nightmares about a hostile takeover by bad actors”.
Bonus track - Event organization
[edit]Conversations were held also with users who organized large events like itwikicon or regularly organize editathons and similar events about possible ways to apply and enforce UCoC during events. Everybody agreed that while FSP is always mentioned, nobody ever thought about a real contingency plan. Suggestions are to spend some time talking with the hosting institution during the organization phase, to inform participants about rules and give them the time to understand them before the beginning of the event. For non wikimedians, this may all sound unfamiliar. There should always be a well recognizable person to contact for UCoC related issues. If events are open to the public, some tolerance and common sense are needed. In case of conferences or presentations, trying to not be alone and to involve fellow wikipedians could also be a good idea.
In case of wikicons or similar events with a large number of participants, there should be a well recognizable group of persons responsible for FSP/UCoC (a ratio of 1/20 participants is considered reasonable) and presence in every conference space should be granted. The team should know the boundaries, how to act, a system with yellow/red cards was suggested. Perhaps some previous contact with local LE agencies could make sense.
Sometimes UCoC violations could happen during the stressful organizational phase. Setting and reminding some basic rules before every discussion or having a facilitator could be a good idea too.
Statistical data about participants
[edit]Survey
[edit]Total respondents: 1911 All questions were optional.
| Who did respond? | |
|---|---|
|
1. How do you identify? (total responses 1818) |
2. How long have you been active in the projects? (total responses 1702) |
|
3. On which projects are you active? (total responses 1491) |
4. In which way (role) do you participate? (total responses 1797) |
Conclusions
[edit]The Italian community decided a long time ago that a peaceful editing environment is very important and thus, local guidelines are probably already more strict than the UCoC. In general there are no bad feelings from the community towards WMF and there were no negative reactions towards UCoC or during the consultation process.
In the consultation 24 active users who declare to be female and some participants in the LGBT project were contacted, none of them experienced harassment or was treated in an inappropriate way due to their gender or their participation in the project. There were some minor comments about episodes of mansplaining or general difficulties related to some subjects (categorization or terminology) but nothing personal. Only one user described the whole project as sexist and male-dominated.
The pages to report incidents and the emergency procedures are not so well known among users, for new users these pages are not easy to find and overall the ways to communicate within the projects are sometimes complicated and not easy to understand. Veteran users and admins should really try to think again like a beginner, about how they approach the projects, the difficulties they may encounter and find ways to make things smoother, easier and more friendly.