Change Details

Reporting harassment on English Wikipedia is complicated. No one wants to deal with it (users, admins, stewards, etc.) but with a community 100,000+ strong and the hierarchy flat, incidents of incivility will occur and need to be resolved so the wiki can maintain its quality control. The WMF's #Anti-Harassment Tools team will build software to improve this experience for all levels of users. ------ ====Generative research Generative research should help us refine our project goals, hypotheses, and problem statements and will serve as the groundwork for our on-wiki discussions. It needs to stand up to a high level of scrutiny. At this stage we do not know what we are building, just learning. Some of this research will be **documentation of the current workflows** — some of these workflows we might immediately declare out of scope (because of who uses them, how often they’re used, what they’re most commonly used for, their level of complexity, and/or our belief of what change we can actually affect.) This will lead to deeper analysis of current workflows to understand how they work and identify where they can be improved. **Analytical research** will help us better understand these current workflows and tools, outside of just opinions. It will allow us to answer questions about what we think works and doesn’t work. Soft data should inform hard data, and we should strive to make decisions off hard data whenever possible. We will likely add in more types of data tracking to gather analytics to inform our team and our on-wiki discussions. We’ll also need to **hear from users themselves** about the current workflows and tools. This will be helpful in determining directionally 1) what tools and workflows exist 2) biggest pain points & 3) biggest areas of opportunity. This may include surveys, user interviews, and on-wiki discussions. We may also do some **competitive analysis** to better understand how other websites and communities report harassment. This is predominantly for inspiration or to fill in gaps in what we think we know. We may also talk to people at other organizations to learn from their experiences. We will cycle/re-approach of these types of research as they inform each other. ------ ====Evaluative research Once we’ve done our due diligence and we’re confident in what we’ve learned, we’ll need to start making decisions about scope, target audiences, and prioritization. We will need to solidify our decisions with evidence before shipping any new software. **Usability studies** will tell us if our designs are effective and understandable for our target audiences. **On-wiki discussions and user interviews** about proposed changes and features will let us know if we’re on the right track, and what we may be missing. ------ ====Post-release analysis Once we ship software, we’ll want post-release quantitative and qualitative analysis to let us know if users are satisfied and if the tools are serving our users as expected.

Reporting harassment on English Wikipedia is complicated. No one wants to deal with it (users, admins, stewards, etc.) but with a community 100,000+ strong and the hierarchy flat, incidents of incivility will occur and need to be resolved so the wiki can maintain its quality control. The WMF's #Anti-Harassment Tools team will build software to improve this experience for all levels of users. ------ ====Generative research Generative research should help us refine our project goals, hypotheses, and problem statements and will serve as the groundwork for our on-wiki discussions. It needs to stand up to a high level of scrutiny. At this stage we do not know what we are building, just learning. Some of this research will be **documentation of the current workflows** — some of these workflows we might immediately declare out of scope (because of who uses them, how often they’re used, what they’re most commonly used for, their level of complexity, and/or our belief of what change we can actually affect.) This will lead to deeper analysis of current workflows to understand how they work and identify where they can be improved. **Analytical research** will help us better understand these current workflows and tools, outside of just opinions. It will allow us to answer questions about what we think works and doesn’t work. Soft data should inform hard data, and we should strive to make decisions off hard data whenever possible. We will likely add in more types of data tracking to gather analytics to inform our team and our on-wiki discussions. We’ll also need to **hear from users themselves** about the current workflows and tools. This will be helpful in determining directionally 1) what tools and workflows exist 2) biggest pain points & 3) biggest areas of opportunity. This may include surveys, user interviews, and on-wiki discussions. We will cycle/re-approach of these types of research as they inform each other. ------ ====Evaluative research Once we’ve done our due diligence and we’re confident in what we’ve learned, we’ll need to start making decisions about scope, target audiences, and prioritization. We will need to solidify our decisions with evidence before shipping any new software. **Usability studies** will tell us if our designs are effective and understandable for our target audiences. **On-wiki discussions and user interviews** about proposed changes and features will let us know if we’re on the right track, and what we may be missing. ------ ====Post-release analysis Once we ship software, we’ll want post-release quantitative and qualitative analysis to let us know if users are satisfied and if the tools are serving our users as expected.

Reporting harassment on English Wikipedia is complicated. No one wants to deal with it (users, admins, stewards, etc.) but with a community 100,000+ strong and the hierarchy flat, incidents of incivility will occur and need to be resolved so the wiki can maintain its quality control. The WMF's #Anti-Harassment Tools team will build software to improve this experience for all levels of users. ------ ====Generative research Generative research should help us refine our project goals, hypotheses, and problem statements and will serve as the groundwork for our on-wiki discussions. It needs to stand up to a high level of scrutiny. At this stage we do not know what we are building, just learning. Some of this research will be **documentation of the current workflows** — some of these workflows we might immediately declare out of scope (because of who uses them, how often they’re used, what they’re most commonly used for, their level of complexity, and/or our belief of what change we can actually affect.) This will lead to deeper analysis of current workflows to understand how they work and identify where they can be improved. **Analytical research** will help us better understand these current workflows and tools, outside of just opinions. It will allow us to answer questions about what we think works and doesn’t work. Soft data should inform hard data, and we should strive to make decisions off hard data whenever possible. We will likely add in more types of data tracking to gather analytics to inform our team and our on-wiki discussions. We’ll also need to **hear from users themselves** about the current workflows and tools. This will be helpful in determining directionally 1) what tools and workflows exist 2) biggest pain points & 3) biggest areas of opportunity. This may include surveys, user interviews, and on-wiki discussions. We may also do some **competitive analysis** to better understand how other websites and communities report harassment. This is predominantly for inspiration or to fill in gaps in what we think we know. We may also talk to people at other organizations to learn from their experiences. We will cycle/re-approach of these types of research as they inform each other. ------ ====Evaluative research Once we’ve done our due diligence and we’re confident in what we’ve learned, we’ll need to start making decisions about scope, target audiences, and prioritization. We will need to solidify our decisions with evidence before shipping any new software. **Usability studies** will tell us if our designs are effective and understandable for our target audiences. **On-wiki discussions and user interviews** about proposed changes and features will let us know if we’re on the right track, and what we may be missing. ------ ====Post-release analysis Once we ship software, we’ll want post-release quantitative and qualitative analysis to let us know if users are satisfied and if the tools are serving our users as expected.