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(a)gmail.com> wrote:

With many, many years of experience from delivering software to internal users, I have a reflection on this issue, without getting into the case of Visual Editor. Compared with what I am used to, the designers at WMF are both competent and good in their responsiveness from users (that still could be improved though). But what I am missing compared with likewise enterprises is a reference group/steering committee. It is customary that such exist and it is they who follow up plans, progress, delivery and support. Now when the software development is being organized in a dedicated department, would it also be appropriate at the same time to set up such a group? Anders Nathan skrev 2013-07-23 15:32: