[Wikimedia-l] making tech journalism easier to read

Tilman Bayer tbayer at wikimedia.org
Wed May 22 20:18:20 UTC 2013

I would like to remind everyone that many blog posts are now drafted
in public at https://meta.wikimedia.org/wiki/Wikimedia_Blog/Drafts .
Pre-publication copyedits or comments on better structuring etc. are
welcome there, so don't feel restricted to posting armchair advice on
mailing lists ;)  For example, the Flow post discussed below (I agree
with Florence's points btw) was up at
before it was posted on the blog.

This is a great thread with a lot of good points, and of course in the
blog team we already routinely use many of them when reviewing and
editing posts, often pointing authors to
https://meta.wikimedia.org/wiki/Wikimedia_Blog/Guidelines (e.g. "Try
to use the Inverted pyramid structure, so that people get the heart of
the story from the beginning. / Use a strong lead sentence/paragraph
that explains the most salient and important point of your story up

On Wed, May 22, 2013 at 8:39 AM, Florence Devouard <anthere9 at yahoo.com> wrote:
> Hi
> My main suggestion (valid for all posts, technical or not) would be to start
> with a clearly identified cap as summary. And put an extra effort so that
> this cap is written in simple and straightforward message.
> In that regards, this post is pretty good generally
> http://blog.wikimedia.org/2013/05/20/flow-next-generation-discussion-system/
> It gives a nice summary of the content of the post. It can be translated
> easily. It provides information. The cap summary at the top could be even
> better identified though.
> On the other hand, this one
> http://blog.wikimedia.org/2013/04/08/intro-to-the-statistics-of-ab-testing-with-wikimedia-fundraising-banners/
> is quite "technical" in nature as well, but though very interesting, it
> fails to pass the "summary" state.
> The little paragraph at the top is not a summary of the post, but a text
> putting the post in context.
> I think this post would benefit from a two lines summary of the content of
> the post itself.
> Its design is 1) context, 2) development 3) conclusion.
> One of the problems non English speakers face is that they are slower to
> identify the "important" points. Stumbling over difficult words and jargon
> is obviously not helping. A hard text will need to be read more than one
> time to just "get the idea"
> In this situation, it is very helpful to rather write in the following way
> 1) summary of the entire post with context, arguments and quick conclusion
> 2) expanded context
> 3) expanding on argument a
> 4) expanding on argument b
> 5) expanding on argument c
> 6) full conclusion
> 1) should be short sentences, simple sentences and as little jargon as
> possible
> 2-6 can be more complex and detailed and links should be added to provided
> additional context and explanation of jargon.
> The only drawback of this solution is that the author will feel frustrated
> if he wants to develop a story and use surprise/discovery effects. But there
> are many benefits to counter balance this loss.
> Flo
> PS: who will point out though that the tech posts on the wikimedia blog are
> actually quite good generally.
> On 5/22/13 11:44 AM, Federico Leva (Nemo) wrote:
>> Quim Gil, 21/05/2013 23:15:
>>> [...] Good journalism is mostly about a lead paragraph for the masses
>>> followed
>>> by an increasingly dense body text (aka the 5 Ws and the inverted
>>> pyramid). You can adapt and change these rules at will, as long as you
>>> are aware of them.
>>> Paying more editorial attention to the title and the lead will allow
>>> more room for complex terminology down in the body text. And this
>>> applies to technical posts just as much as to other posts about other
>>> expert fields for librarians, translators, lawyers, educators...
>>> https://en.wikipedia.org/wiki/5_Ws
>>> https://en.wikipedia.org/wiki/Inverted_pyramid
>> I agree that this is more useful, with the caveats by Lodewijk.
>>      As for our English texts, aside from jargon, their main deficiency
>> is IMHO usually in not considering language diversity. The issue is very
>> apparent in our requests for translations: often, you have very "simple"
>> and short sentences which are translated in a way that reverses their
>> meaning upside down. An article or pronoun implicit in English, if
>> misunderstood by a native speaker of a language where the article or
>> pronoun matters, is enough to spoil an entire text. What to do?
>> 1) Some time ago I added some short leaflets here, but more and better
>> resources are needed:
>> http://meta.wikimedia.org/wiki/Writing_clearly#Advice_from_the_experts
>> 2) An automatical service we'd benefit from is one which takes a text
>> and highlights all idiomatic expressions (which may be obvious in USA
>> English but mean the opposite in UK English or just nothing for most
>> people), formal/literary expressions (which may mean nothing for most
>> native speakers and at the same time be obvious for speakers of another
>> language more closely related to them) etc.
>>      Let me also add that – personally – I have no problems reading and
>> understanding sentences spanning multiple pages, if they were written by
>> Proust (who always has a reason), but I have big problems understanding
>> texts which lack coherency and focus. English texts composed by many
>> scattered short sentences, without conjunctions and other sentence
>> connectors, are for me very painful to read. However, it seems most
>> people prefer to have many small concepts and to connect the dots
>> themselves to get the figure as they can.
>> Nemo
>> _______________________________________________
>> Wikimedia-l mailing list
>> Wikimedia-l at lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB

More information about the Wikimedia-l mailing list