We at Atlantic.Net are so pleased that you are interested in writing articles for us. We look forward to the partnership between us to help provide the information that will help empower people to go out there and make and do cool and exciting things with technology.
So, before you jump in, please take a moment to review this style guide. It should give you an idea of the tone and direction we are looking for in the submissions we receive.
If you find yourself interested in writing technical articles, you are likely the sort to be excited about learning and sharing that learning. This attitude is the sort we share at Atlantic.Net and the sort we expect quite a number of our readers share as well.
As learners, we often find that the more we learn, the more we realize how much more there is to learn (and how little we knew before). Combine that experience with our having to keep up with continual upgrades, innovations, and the introduction of new structures, languages, and applications, and it’s not surprising to see the need for all sorts of reference documents.
From this perspective, we presume our readers are approaching us and the view we would like to remind our writers to write toward. Imagine that the reader of your article has experience in some other field of technology or computers than the one you are writing about. It may also help to remember what it was like when you were first learning about what you’re writing about. What was tricky, or what mistakes did you make? Put that experience to work!
How’s and Why’s
Of course, the bulk of any how-to article is the series of steps to follow to accomplish the task that is the subject of the article.
In addition to the how’s, though, we would like to see an Atlantic.Net article also include some explanations of why. A strong how-to article will provide additional information about optional or recommended practices.
For example, in an article demonstrating how to manage an Ubuntu server, one might suggest running updates in the following fashion:
sudo apt-get update && sudo apt-get upgrade
This line is a concatenation of two commands that could be run separately. The
&&indicates that the command that follows it should be run after the command preceding it successfully completes. It’s possible to shorten this command sequence by one keystroke by using
;(semicolon) instead of
;indicates that the command that follows it should run regardless of whether the preceding command successfully completes. In this instance, this usage is not a best practice, since you want to be sure you successfully update with your package repositories before trying to install upgrades.
Of course, if you are logged in as root, you would omit the
sudo, though, while often convenient, it is also not a best practice to remain logged in as root.
An Atlantic.Net article should primarily be informative, but that doesn’t mean it has to be dry. We encourage our writers to cultivate a friendly, personal style while still focusing on conveying information.
It would be best if you avoided slang and colloquialisms. And, since a significant portion of our readership is likely to be international and for whom English may not be the first language, we recommend against the use of idiom as well.
Likewise, it would help to refrain from inserting your opinions into articles. Where there is room for interpretation or preference, you should acknowledge which portion represents a subjective point of view. Supplying a link or references that support the point of view, if reputable, will be acceptable. When in doubt, though, prune the subjective portions of an article.
An informative article is only as effective as the language through which it conveys its information. If a reader can’t understand what you are saying, that reader will go elsewhere. As such, all submitted articles should adhere as closely as possible to English grammar and spelling standards.
Submissions with significant issues with grammar or spelling will be returned for rewriting. We reserve the right to make edits in the case of minor problems with either.
A program may fail or run less than optimally if written poorly. The same applies to text written with little care taken to the rules and syntax of grammar and spelling. Strive to write simply and concisely to avoid most language pitfalls.