Page MenuHomePhabricator

UX to create safe spaces
Open, Needs TriagePublic


Type of activity: Pre-scheduled session
Main topic: none

The problem

It has often been noted that the editing experience on Wikipedia can be brusque and offputting to newcomers. Further, harassment, trolling, and abuse are too common on our projects.

It would be worth thinking about technical means to create "safe spaces" on our projects, where like-minded groups of people can shut out the outside world to some degree and work with each other on articles or administrative tasks. Liasons could be appointed within the group to communicate with the broader project, ensuring that changes are contributed "upstream".

Expected outcome

We start thinking of ways to allow users to better manage their interactions on our projects, so that we avoid falling into the "twitter hole" of abuse.

Current status of the discussion

  • Certain projects like the teahouse share similar goals (friendly experience for newbies)
  • github's forks are owned by particular people, who can then block particular users from "opening or commenting on issues or pull requests; starring, forking, or watching; adding or editing wiki pages; inviting you as a collaborator to their repositories; following your account's public activity; or send you notifications by @mentioning your username in public repositories". Therefore each fork is in effect a "safe space" controlled by the user making the fork.
  • Some pushback on the idea of private *anything* on WMF projects.
  • Not much direct conversation about technical mechanisms to empower users to manage their experience.

Event Timeline

Qgil added subscribers: pizzzacat, Qgil.

Can you add projects/tags related to the topics discussed, please?

For the record, I made some proposals to this effect at the Community Wishlist survey ( T138165, T138166, T150419 and T150421.

Here's some lightly-edited IRC discussion on this topic between @TheDJ and @cscott this afternoon. Talking about "user groups" in general, but touching on this idea of safe spaces (starting at the boldfaced line below). Note that @TheDJ has a proposal at which is loosely related -- his "safe space" is a space for experts and peer review. Note that these are just "free flow" thoughts.

(11:22:38 AM) cscott-free: i wonder if/how Expertpedia would interact with a more general "groups of users" system.
(11:23:22 AM) cscott-free: at the editing offsite, @Jdforrester-WMF seemed to push back against the idea of curated groups of users quite strongly, feeling that allowing <some people> to exclude <some other people> from <some group> was not in the ethos of WMF projects.
(11:23:30 AM) cscott-free: and that it could be a haven for abuse, i guess.
(11:23:55 AM) cscott-free: he seems to prefer using some semi-magic AI algorithm to "suggest" groups of users who might be relevant for a particular task, without allowing you to explicitly curate that list.
(11:23:42 AM) thedj: don't think wikipedia.
(11:24:15 AM) thedj: think totally separate site, totally different interactions, but 'connecting' to wikipedia.
(11:25:16 AM) cscott-free: sure, but [in your Expertpedia proposal] you say, "All in an open and free ecosystem" -- and what I'm hearing when I discuss this is that curated groups endanger the "open" and "free" part.
(11:25:22 AM) thedj: i've often described it as solving the amateur expert conflict problem, by recognizing the disjunction and then guiding where both worlds meet in the best possible way
(11:25:44 AM) thedj: open and free as in "not controlled by elsevier"
(11:26:03 AM) cscott-free: sure, but what's to prevent the "journal of hitler studies" forming an expert group and using it as a platform for harassment
(11:26:50 AM) cscott-free: when outsiders can't see exactly who was responsible w/in the group for the harassment, just the 'group score'
(11:27:37 AM) thedj: that's why on the Talk page I have: The group dynamics need further refinement.. There are several systems that could be applied here. levels, promotions/demotions, scarcity, not figured this out definitively.
(11:27:48 AM) cscott-free: and the 'real name' aspect is particularly galling to endangered/minority communities. so you'd say that folks couldn't comment on harassment w/o outing themselves and therefore exposing themselves as a target for further harassment.
(11:28:19 AM) cscott-free: i don't want to seem discouraging, i actually am really interested in trying to explore models for user groups of various kinds.
(11:28:51 AM) cscott-free: i'm just relaying comments i've heard in other contexts when i've floated similar strawmen
(11:28:48 AM) thedj: real name can mean multiple things.
(11:29:03 AM) thedj: i think first of all it means that "the system" will know your real name
(11:29:12 AM) cscott-free: sure. i'm a big fan of pseudonymity. but the flip side of that is "sock puppet"
(11:29:45 AM) thedj: and real mean probably also means if you connect with your published articles, then that shows your name.
(11:29:49 AM) cscott-free: for OLPC i wanted to ensure that kids could have one identity "at school" and a different identity "at home" and have these protected from each other.
(11:30:10 AM) cscott-free: so teachers could reasonably watch what they are going at school, but didn't have any right to pry into their home use of their computers
(11:30:45 AM) thedj: yes, ideas like that are enticing. and we are not exploring them enough.
(11:31:40 AM) cscott-free: for expertpedia the equivalent might be something like "deep throat", where we have a trusted source who can attest that this is a real source w/ appropriate expert knowledge, but that info doesn't get out further.
(11:32:12 AM) thedj: web of trust
(11:32:31 AM) cscott-free: right. not a simple problem, albeit one which has been thought about a lot.
(11:32:59 AM) cscott-free: and the flip side is you might have [a politician] saying "trust me, the best people are telling me that..." and outsiders would have no way to verify that info or source.
(11:33:00 AM) thedj: anyway, i think that there is a true space there that could help us become more successful and could help make scholars more successful.
(11:33:39 AM) cscott-free: the strawman i've been floating is based around revitalizing WikiProjects and trying to make them actually user groups, with admins and shared projects, etc.
(11:34:26 AM) cscott-free: this was pau's design on page 20 of
(11:36:11 AM) cscott-free: that was the idea that i got strong pushback on.
(11:36:36 AM) cscott-free: but i liked the idea because it inverted user groups so they weren't "my friends" but instead were task-focused, on the particular WikiProject.
(11:37:32 AM) cscott-free: of course comp sci speaking you can always make WikiProject:cscott and then you have a facebook-style friends list. but this is a place where the social presentation/human factors matter more than the implementation equivalence.
(11:35:36 AM) thedj: I like that idea
(11:36:58 AM) thedj: though i think you need to be careful with 'ownership', but there are ways around that.
(11:37:53 AM) cscott-free: yeah, i don't fully understand the problem with ownership/admins, but i'd like to learn more about that
(11:38:00 AM) thedj: and then you have admins "this is not what our groups are for, go away"
(11:38:11 AM) cscott-free: isn't that the same sort of problem that expertpedia would have, though?
(11:38:53 AM) thedj: i mean, the ultimate ownership actually does exist. Try excercising your 'editor rights' of on and you will be chastized out of the en.wp community :)
(11:39:26 AM) thedj: it's a very non-tangible ownership (which is why it is so freaking confusing to people), but it exists as much as we claim that it doesn't exist.
(11:40:34 AM) cscott-free: the objection @Jdforrester-WMF was raising seemed to be a more-technical issue of content licensing, that we can't hide some content/edits/collab/etc from person A unless they are a member of group B w/o violating the license under which the author of the content contributed it to the project.
(11:42:15 AM) cscott-free: i think there are probably ways around this? like read-only access to all groups, regardless of membership. i don't think our licenses say that *mediawiki software* has to allow anyone to edit our content *on our site*, just that they can take a copy elsewhere and edit it to their heart's content.
(11:43:07 AM) cscott-free: my interest here is in trying to provide safe spaces as well, i was thinking that within your user group you could collaborate on edits-in-progress w/o necessarily doing it directly on the main article.
(11:44:58 AM) cscott-free: so if minority author A get targeted for harassment whenever they try to contribute directly to an article, they could do it instead in the safe space, get feedback from trusted friends, and then have a less-targeted ally take responsibility for actually getting the proposal developed in the safe space get merged into the public article.
(11:45:32 AM) thedj: hmm, i'm not sure if that can work in wikipedia.
(11:45:54 AM) cscott-free: yeah. and the safe space could be a haven for abuse as well, which is "protected" from those trying to combat it.
(11:46:01 AM) thedj: exactly
(11:46:17 AM) thedj: and teaming up is a significant concern
(11:46:42 AM) thedj: one of the benefits of wikipedia has been that reddit mobs can't really find eachother :)
(11:46:52 AM) cscott-free: anyway, there are a lot of ideas possible around curated user groups, and some are probably good ideas and some bad ideas, and i don't want to confuse the issues by mixing proposals together... but i am interested in discussing the various ideas to the extent that maybe we can identify common problems/solutions.
(11:47:02 AM) thedj: maybe on one article, but that's 'short'
(11:47:22 AM) cscott-free: WikiProject:Reddit, or the "Reddit" expert group?
(11:48:20 AM) thedj: s/reddit/any other website community that can mob
(11:48:46 AM) thedj: 4chan/reddit/slashdot/gamergaters etc etc
(11:48:46 AM) cscott-free: i note that "moderation" is part of, and that's another somewhat related conversation
(11:48:54 AM) cscott-free: who can moderate, what are the moderation guidelines, etc.
(11:52:24 AM) thedj: the problem esp with these technologies that dive deep into the hidden rules of our communities interaction models are that they have a very high probability of totally failing if they miss just a few of the marks
(11:53:32 AM) thedj: that's why i think these idea scratch pads are very useful. if you ever want to develop something like that, you need to go back to your scratchpad and figure 'does this still match' and if not, why not, and is that good or bad.
(11:55:16 AM) cscott-free: it's the social nature of our technology which always interests me so much. it's never just a technical problem.
(11:55:31 AM) thedj: same here
(11:55:50 AM) cscott-free: i also wonder if the solution is more incubator experiments, where we don't have to make the thing perfectly right the first time
(11:56:14 AM) cscott-free: OTOH, i think we'd do real harm but deploying an experimental discussion (say) technology that turned into a pit of poisonous vipers
(11:56:37 AM) cscott-free: so there is a certain necessity to get the basic things right
(11:57:44 AM) cscott-free: i'd love to see "20% time" formalized into the idea that 20% of our projects can be cheap and fast and allowed to fail.
(11:58:51 AM) thedj: exactly.
(11:59:19 AM) thedj: also why does everything need to be integrated into the encyclopedia
(11:59:43 AM) thedj: it just needs to be integrated into the platform that is MediaWiki/Wikimedia
(12:00:05 PM) thedj: doesn't necessarily mean it has to be the same en.wp community having to deal with it.
(12:28:27 PM) cscott-free: do you mind if i copy/paste some of this discussion into a phab task?
(12:29:03 PM) thedj: no, no problem. just put a "free flow thinking"-note on it :)
(12:29:08 PM) cscott-free: will do

I wrote a wikimedia-l post mentioning this topic:

In theory, T149661: Real-time chat (a different dev summit) submission is even more on-target for the general question of "reinventing communications on our projects", but the topic area it was submitted for didn't make the cut for this year's dev summit. But if you're a superfan of "chat" discussions, you might go over there and subscribe/comment/award token as well; maybe that will end up as an unconference topic or some such.

This particular dev summit task should be more tightly focused on user groups or user-controlled blocklists or filters, whatever seems like the best way to carve out safe spaces on our projects without letting them devolve into hives of scum and villainy hidden from the world at large (on one hand) or tightly-closed filter bubbles of self-affirmation that will never result in mergeable compromises acceptable to the broader project (on the other hand).

Mattflaschen-WMF renamed this task from Safe spaces to Software products to create safe spaces.Nov 19 2016, 3:49 AM
cscott renamed this task from Software products to create safe spaces to UX to create safe spaces.Nov 19 2016, 6:10 AM

Note that "Building a sustainable user experience together" has been closed as a main topic. Specific session proposals still might be pre-scheduled, based on their own merit.

This proposal seems to have enough interests, but there is no discussion so far. I am moving it to "on track" for now, but all pre-scheduled sessions are supposed to have ongoing discussions.

Since this proposal doesn't fit in any main topic and there isn't much active discussion here, maybe we should move it under Unconference.

In terms of room capacity and configuration, what would be your preference?

  • The biggest room in theater configuration (up to 200 people, only chairs, no tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and optional video recording (i.e. only recording the initial introduction but then relaxing things during the discussion, or no recording at all).
  • A smaller room, flexible configuration, optional video recording...

@cscott Hey! As developer summit is less than four weeks from now, we are working on a plan to incorporate the ‘unconference sessions’ that have been proposed so far and would be generated on the spot. Thus, could you confirm if you plan to facilitate this session at the summit? Also, if your answer is 'YES,' I would like to encourage you to update/ arrange the task description fields to appear in the following format:

Session title
Main topic
Type of activity
Description Move ‘The Problem,' ‘Expected Outcome,' ‘Current status of the discussion’ and ‘Links’ to this section
Proposed by Your name linked to your MediaWiki URL, or profile elsewhere on the internet
Preferred group size
Any supplies that you would need to run the session e.g. post-its
Interested attendees (sign up below)

  1. Add your name here

We will be reaching out to the summit participants next week asking them to express their interest in unconference sessions by signing up.

To maintain the consistency, please consider referring to the template of the following task description:

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)