I'm sorry this is long and ranty and late.
------ Original Message ------
From: "Nicholas Nethercote" <n.netherc...@gmail.com>
Subject: Re: Open communication and Slack
In general, I think everything you said is reasonable, but I'm having
trouble connecting it to the specific issue of IRC vs. Slack. Are there
people who have abandoned IRC in favour of Slack due to harassment or
similar reasons? (That's a genuine question, I don't know.)
To me, the difference between IRC and Slack comes down to two things.
- Slack is a bit prettier, easier for newbies, and has a few more bells
and whistles. (Though a good client like IRCCloud makes the IRC
experience very close to the Slack experience.)
- Slack is proprietary and non-open. (The latter characteristic could
help avoid harassment issues.)
If one of the practical goals of Mozilla's aspirations to openness and
open development is accessibility - that is, reducing or removing
barriers to participation - then I think we need to pull apart the
different meanings of the word "open", that we frequently if
unintentionally use as if the same word meant all the same things to all
the same people.
If you're comfortable digging into code and standing up your own
services, "open" as in "open source" is likely to be a core part of your
sense of personal safety and agency - this is how you maintain some
degree of control over your destiny, how you avoid the indignities of
data loss, corporate exploitation and community collapse.
"Open", in this reading, inextricably ties source control and source
transparency to individual agency. The checks and balances of openness
in this context are about standards, data formats, and the ability to
export or migrate your data away from sites or services that threaten to
go bad or go dark. This view has very little to say - and is often
hostile to the idea of - granular access restrictions, those being the
tools of this worldview's bad actors.
Personally, I believe this view dates to a time where we could pretend
those access controls didn't exist because they were handled, invisibly,
elsewhere; university admission or corporate hiring, for example.
In contrast, organizational openness - that is, openness viewed through
the lens of the accessibility and the experience of participation in the
organization itself - puts the safety and transparency of the
organization and the people in it first, and considers the openness of
work products and data retention as secondary; sometimes (though not
always) the open-source nature of the products emerges as a consequence
of the nature of the organization, but the details of how that happens
are community-first, code-second.
"Openness" in context is about accessibility and physical and emotional
safety, and the ability to participate without fear. The checks and
balances are principally about inclusivity, accessibility and community
norms, codes of conduct and their enforcement.
These two views aren't going to be easy to reconcile, because the ideas
of what "accountability" looks like in both contexts - and more
importantly, the _mechanisms of accountability_ built into the systems
born from both contexts - are worse than just incompatible; they're not
even addressing something the other worldview is able to recognize as a
problem.
And even that glosses over the institutional needs Mozilla has in
managing risk while supporting a broad spectrum of what we call
openness, which is a whole other tier of complexity. The differences
between Slack and IRC are a lot deeper than "Slack is a bit prettier and
easier for newbies", when we're talking about institutional risk
management.
But to drag this back to where we started, let me put it to you this
way: we cannot, as an organization, end up in a situation where asking
somebody to participate in open development is functionally
indistinguishable from asking them to walk home at night alone.
People cannot be equal participants in environments where they are
subject to wildly unequal risks. We'd be deluding ourselves if we called
systems that are just too dangerous for some people to participate in
_at all_ "open" just because you can clone the source and stand up your
own copy.
So I don't know what the answer to this is, but I do know that the IRC
spam we've been seeing is just a taste of how bad that experience can
become, particularly for anyone specifically targeted. IRC's current
borderline-unusability is happening _precisely because_ it is
structurally difficult to mitigate bad actors on that platform.
In contrast we do have a way for community members to join Slack. It's a
bit more labor intensive than "/join", but the process includes clear
communication about community norms and expectations, clarity around the
CoC and an ability to keep out the jerks.
Both are in some sense of the word open; both are, to a different view,
effectively closed.
Personally, I think that we need to err on the side of providing a safe,
constructive working environment for our colleagues, even if that means
we need to leverage tools we don't own or can't fork.
- mhoye
_______________________________________________
governance mailing list
governance@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance
