1 Tone
Content must be presented in a conversational yet professional and respectful tone. Contributors should imagine themselves delivering a lively, engaging conference presentation, rather than preparing a dry, formal report or journal publication. Contributors to Real World Data Science are creating content for their colleagues and peers and should “speak” to them as such.
2 Structure
Each contribution must, in effect, tell “a story”, and so contributors need to be clear (a) what their story is, (b) why people should be interested, and (c) what its main message or key takeaways are. To help figure this out, we recommend contributors apply the XY Story Formula.
3 Technical content and jargon
Technical content is a necessary feature of a site like ours. Without it, an article or other piece of content may be of little practical use to a technical audience. But if there’s too much of it, even experts may struggle to stay engaged. Contributors are also faced with a dilemma when it comes to explaining technical content: explain nothing, and you risk alienating some of your audience; explain everything, and you’ll struggle to establish a clear, strong narrative thread. So, careful consideration is required:
- Who is my audience for this article?
- What is this audience likely to know already, and what needs to be explained?
- If something needs to be explained, can I do so briefly and then link to other resources? Or is a full explanation required?
- In telling my “story”, what are the absolute-need-to-knows, and what are the simply-nice-to-knows?
Thinking through these questions will help contributors to find the right mix of valuable, technical content paired with accessible, readable narrative.
Keep in mind that the same general advice applies to the use of industry jargon. Jargon can be a valuable shorthand when communicating with people working in the same organisation or sector, but those working in different fields may struggle to make sense of it. So, contributors need to think carefully about how much jargon to use, and what needs to be explained.
4 Figures/graphics
All data visualisations and other graphical outputs directly related to the content of submissions must be presented neatly and cleanly (avoid chart junk). They should also be labelled correctly and legibly, with colours chosen carefully to ensure they can be easily distinguished by all readers. Accompanying captions must be written to support the reader’s understanding of the visual presentation (e.g., “Figure 1: a bar chart” is an insufficient description).
If contributors wish to use charts or graphs that are not their own work, they must ensure that such items are correctly sourced and referenced, and that permission to republish has been obtained. A letter or email confirming this permission is required.
5 Data sources
Contributors must include within their submissions any links and/or references to the sources of data, code and/or software and software packages on which their analyses are based. We understand that some data sources may not be publicly available, whether for legal, ethical or commercial reasons. However, readers must still be told where the data come from, even if they are not able to access the data themselves.
6 References
Citations are to be formatted in The Chicago Manual of Style author-date format.
7 Use of images
Images for general illustration purposes will be sourced and – where necessary and within reason – paid for by Real World Data Science.
For all other style-related matters, we follow The Guardian and Observer Style Guide.