Talk:Technical communications

Rename

Hi. I doubt many people will notice this, but I've renamed this page to reflect the fact that the scope of this activity has shifted and widened.

The previous title ("Wikimedia Foundation engineering project documentation") made sense when the primary goal was to set up a consistent process (and underlying tools) for Wikimedia Foundation engineering staff to publish documentation about their activities. Now that we have a process, templates and even a gadget making it easier to add and edit status updates, there's not much more to do about "project documentation", besides actually writing and publishing it.

There are still many things to improve, however, in the larger area of technical communications, like working towards an idyllic world where:

• Development is always guided by the users' needs.
• Users have multiple venues to learn about, and get involved in, current and upcoming software development, at different levels of detail.
• Users are and feel heard before, during and after development.
• Paid and volunteer developers can collaborate on features easily.
• Probably lots of other magical things happen.

If you have thoughts on other goals we should work towards, and how to get there, please feel free to start discussions on this page. I certainly don't claim to have all the answers, on the contrary. But if I can help facilitate improvements, I'm happy to do so.

Note: I purposefully chose "technical communications", and not "engineering communications", because "engineering" tends to refer specifically to WMF employees, and I don't believe there should be a distinction between paid and volunteer developers when it comes to communicating with users.

guillom 14:42, 17 October 2012 (UTC)

Agreeing with this. Thanks. One more thing -- "technical" is better than "engineering" because "technical" more clearly communicates that this includes sysadmin, testing, product management, and other non-coding activities. Sharihareswara (WMF) (talk) 18:17, 19 October 2012 (UTC)

Technical communications: less is more

Summary: we spend a huge amount of energy in plenty of technical communications of different kinds. Most of the times we suffer the same problems: difficult to find topics and the energy/quality to publish them properly, not enough promotion, not enough participation, not enough impact.

The proposal is to coordinate better these activities, do less of them and put the right resources in the ones we do.

Let's define what a technical communication is, from the point of view of the producers and the audience:

• Blog posts.
• Tech Talks.
• Meetups.
• Tech topics in metrics meetings.
• We could add a % of the sessions we run in Wikimania, Hackathons, DevCamps...
• We could add Office hours.

It takes a lot of energy for us to produce all this, especially when we do it with little time and little coordination. Most importantly: it takes a lot of energy to our audiences to follow, find and consume all this content.

Do we really need this big amount of content produced with such frequency? I'd say no. By doing this we are just burning our own machine, exhausting our followers and not really getting to those who don't follow us yet.

Proposals:

• Commit in advance only to the big tech events (Wikimania, Hackathons...), monthly metrics meeting (happening anyway) and one meetup in San Francisco every 3 months, aiming to have full room and wide promotion with the help of Comms before and after the event, including good post-processing and publication of the videos, featuring them wherever appropriate.
• Select the most interesting videos from other tech events and work on their post-production and publication in the right places.
• Schedule Tech Talks and additional SF meetups based on demand of additional topics and availability of resources to guarantee the same level of production and promotion. In many occasions a blog post or an important mail can be synced with one of these events for higher impact.

A rule of thumb would be: every event should get Comms buy-in, excite a critical mass of WMF and independent attendees, and it should generate at least one video that would end up in at least one blog post and one wiki page about that topic.

If we are not confident that an event will meet this criteria then we can go for a blog post, IRC office hours or an equivalent pure video hangout organized by the speakers directly from their desks, without requiring any help from WMF Engineering or Comms.

Thoughts? I will still organize the Tech Talk for next week, but other than that I will wait for consensus here before scheduling more SF meetups or tech talks.--Qgil (talk) 17:33, 10 May 2013 (UTC)

• Makes sense to me in terms of narrowing focus and making each talk have more impact. This should also make it easier to assess impact as their will be fewer events to monitor. Tfinc (talk) 17:41, 10 May 2013 (UTC)
• I think this makes a lot of sense for events, but what about blog posts? It's in the list of 'technical communications' above, but I don't see a specific proposal for how to handle them. That said, given the passiveness and a-synchronicity of blog posts, do we really need to limit how much we're producing via that medium? There is so much happening throughout the org that I think it's otherwise very difficult to communicate clearly about, and blogs are by nature much easier to consume than events. Arthur Richards (talk) 17:53, 10 May 2013 (UTC)
  • I agree with you: usually the more blog posts the better. It usually requires the effort of less than two people and the reach can be wide. My point is that a potentially weak event can be actually planned as a powerful blog post. And in any case strong events should lead to strong materials for stronger blog posts.--Qgil (talk) 18:51, 10 May 2013 (UTC)
• Does it really make sense to include the DevCamp, etc events in that category? Much of the gain from those come from the diversity of the audience and redundancy isn't really an issue – Wikimania this year, for instance, is within reach of volunteers from South-East Asia and Australia in a way that is genuinely rare; and repeating some past material for their benefit is not a waste of resources IMO. — MPelletier (WMF) ^(talk) 18:16, 10 May 2013 (UTC)
  • Those events do generate some content that wants to get the attention of the people not attending them (e.g. good videos of presentations). This is the reason why they are included here. I'm not proposing to have less of those or to avoid having there content released already elsewhere. My point goes in the opposite direction, and you will probably agree: those events have a potential of producing good content and we could do better at reusing and promoting that content, perhaps saving us weak little events (e.g. a Tech Talk) before/after the big event. I have edited a bit the proposal with the hope that is clearer now.--Qgil (talk) 19:01, 10 May 2013 (UTC)
• I approve of your proposal, Quim. Sharihareswara (WMF) (talk) 20:39, 10 May 2013 (UTC)
• Would it be fair to sum up this proposal by saying "We should organize less but better tech events"? As Arthur mentioned, it seems to me that, from all the items you listed, blog posts stand apart, and all the others are events of some kind (that are usually attached to the Volunteer coordination and outreach activity, whereas blog posts & activity documentation constitute most of Technical communications). What I understand from your proposal is that you feel we/you are organizing too many online/meatspace tech events, and we/you should cut back on quantity and improve quality. If that's what you mean, I trust your judgment on that and approve :) If you mean something else, please let me know. guillom 13:04, 13 May 2013 (UTC)
  • I mean this, yes, but I also mean that we/you should combine better technical communications and tech events, to help each other and make the most of them.The Lua deployment is a good example where communications and events were combined under a common strategy and we got very good results, but in media impact and participation in events.--Qgil (talk) 17:42, 13 May 2013 (UTC)