[Wikimedia-l] Communication plans for community engagement

Katherine Casey fluffernutter.wiki at gmail.com
Tue Jul 23 14:03:50 UTC 2013


I think the Foundation is trying to make steps toward increased
communication with its constituent communities with its blitz of hiring
Community Liaisons. And that's a good idea, and liaisons can do a lot of
good. But I don't think that program is running at 100% effectiveness yet,
and back-end developers and staffers are depending entirely on liaisons to
do their communicating, with the result that liaisons are stretched thin
(one person covering multiple language wikis, another person covering every
single issue on a gigantic wiki, a bunch of language wikis having no active
liaison at all, etc) and overly stressed. Combine that with liaisons being
sourced from the community a lot of the time, and we end up with overly
stressed users who are used to speaking their minds being put in a position
where they feel responsible for not only making sure entire communities,
every single person, understand that software is coming, but also for
explaining every tiny feature of that software and convincing entire
communities to accept those things even if the things are objectively
flawed or even just plain ol' bad, and for taking every ounce of abuse the
community wants to heap upon the devs who aren't doing the talking, and
doing all those things in a way that doesn't offend the community members
they're supposed to be communicating with. It would be a difficult job for
a team full of professional tech-writer communicators, and it's pretty much
an impossible one for one or two part-time workers who mostly aren't
professional technical writers or mediators. The result is communities are
up in arms, liaisons are fighting onwiki battles instead of communicating
neutrally, and no one trusts anyone to actually communicate anything.

A more full-featured engagement strategy, actively involving a) more
staffers than just liaisons and b) more liaisons, might go farther toward
bringing project communities on board with the WMF's goals. Every project
team at the WMF should have a liaison, and every liaison should work as
part of a team so they're not expected to be on 24/7 until they burn out.
Every liaison should be trained in communicating effectively and in
handling and directing criticism. A liaison who is not communicating
effectively with the community they're assigned to is worse than no liaison
at all, because the community assumes the failure of communication is
deliberate on the WMF's part. At the same time, every dev or manager who
expects a liaison to do the talking for them should be making sure that
they're listening to their liaison and being responsive to concerns the
liaisons raise that are coming from the community. Devs and managers should
understand that liaisons are only as effective as the responses they get
from devs and community, and that "it's this person's job to listen to you
and nod and then tell you how it's going to be" is not a substitute for "we
are actually adapting our approach/software in response to your concerns."
There is *no substitute at all* for hearing from someone who's actually
driving the software changes when it comes to answering specific questions
about the software or where it's going, because the more intermediaries the
message goes through, the higher the chances that it will become
unintentionally garbled or muted.

*Or, to tl;dr this whole thing*: Liaisons could be SO MUCH MORE USEFUL than
they are right now, and that would go a long way toward improving these PR
disasters. But that would require the cooperation of every aspect of the
Foundation's staff.

-Fluffernutter


On Tue, Jul 23, 2013 at 9:32 AM, Nathan <nawrich at gmail.com> wrote:

> On Tue, Jul 23, 2013 at 9:16 AM, Craig Franklin
> <cfranklin at halonetwork.net> wrote:
>
> >
> > As is usually the case, I'm not saying this to have a go at the
> developers
> > or anyone else involved (who are obviously doing their best), but I think
> > that some of the communication on this topic has been a bit clumsy and
> has
> > caused a lot of unnecessary angst that could probably have been avoided
> if
> > it had been planned for in advance.  Does the Foundation have formal
> > communication plans for things like this that focus on gaining community
> > buy-in?  If not, then you probably should.  Obviously more testing and
> > specifically more user acceptance testing would have been helpful in this
> > case, although I understand the political pressures in getting the
> product
> > shipped on time.
> >
> > Cheers,
> > Craig Franklin
>
>
> I alluded to this same issue in my earlier reply and thought this
> deserved its own thread. We all know that it has happened many times -
> a change, policy or other initiative emanates from the Foundation or a
> member of its staff, and various community groups respond negatively.
> The response is ignored or not properly addressed in a timely manner,
> and it snowballs into something much larger.
>
> The WMF staff often seem to be caught flat-footed when this happens,
> and only after an unnecessary degree of escalation within the
> community do they engage fully (in what I think of as "crisis mode"
> communications, usually from Erik, Sue or another WMF senior leader).
>
> So if it hasn't already, perhaps the WMF should consider making a
> robust plan for active communications a part of every significant
> initiative and rollout process. This should mean regular and
> coordinated posts to mailing lists, blog posts, and community centers
> on affected products - and a special effort should be made to discover
> complaints and provide specific, regular and detailed feedback in
> response. And I don't mean only product development; this ought to
> apply equally to the full spectrum of WMF interaction with the
> movement, from MediaWiki development to adjustments to the FDC process
> to Board resolutions and so on. All teams, from engineering to product
> to fundraising to community liaisons, should be evaluated and held
> responsible for the quality of their movement communications.
>
> Perhaps that is unusual for a software house, and thus not the normal
> mental go-to or skillset for WMF staff used to working with a
> different type of customer. But I think it is acutely evident that
> this type of rapid, serious engagement would pay major dividends for
> the WMF in terms of its relationship with the various editing
> communities and the Wikimedia movement.
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request at lists.wikimedia.org?subject=unsubscribe>


More information about the Wikimedia-l mailing list