Linode Writer’s Guide
Updated by Linode
Linode has a thriving community of authors who contribute to Linode Guides and Tutorials. We are always looking for guides on popular, trending topics, and updates to existing guides. If you’re interested in writing for Linode, this page describes the process for submitting your work. If your guide is published, you’ll receive $250 per article by PayPal or in Linode credit.
Linode’s bounty program has been an overwhelming success. Too succesful, in fact! Our inbox and repository are overflowing with proposed articles.
As a four-man team responsible for both internally and externally sourced docs, we’re in a bit over our collective head. That’s why – until further notice – we’re no longer accepting new submissions for the Linode bounty program. Any new guides submitted, whether through GitHub or email, will be rejected without review.
Rest assured, this is a temporary moratorium. Once we’ve cleared through the backlog and given the appropriate time and consideration (and, hopefully, payout) to the authors already patiently waiting, we’ll resume the bounty program and with it, introduce a revised set of topic requirements. Further updates will be posted here or on our Github page.
Please note, if you see the need for a correction in an existing guide, feel free to make a pull request. We still want to improve and update our existing guides, even as we review new ones.
Guides should instruct readers how to accomplish a task on, or relating to, a Linode or Linodes. When writing, think of both what the guide should accomplish and why the reader would want to use your guide. A guide should consist of about 90% instruction with 10% explanation.
Guides should be informational but friendly. Use the active voice whenever possible, and the pronouns you or we instead of I. Avoid unnecessary information. Brief, to-the-point explanations are preferred, but also consider the audience and the level of technical ability needed to complete each task. A beginner’s topic usually will require more detailed explanations than one for an advanced user.
To be considered, submissions must be written in English and adhere to the formatting described in our Writer’s Formatting Guide. The primary qualities we look for in a guide are:
- Accuracy: Instructions should be straightforward, technically correct and thoroughly tested. Include brief explanations of each step to explain the purpose of each action. Guides can use technical jargon pertinent to Linode, Linux, and related topics, but use common sense–if a term implies an advanced concept that fewer people would know, take a sentence or two to explain it, or link to a wiki or manual page.
- Completeness: A guide should leave readers with a finished, working configuration and give them an idea of where to go from there. Considerations for security and best practices must also be made, including firewall rules.
- Originality: Content should be original material written for Linode. We will not accept submissions which are duplicated from other sources, including personal blogs.
If you would like to see whether your work is in line with our requirements before taking the time to write a full guide, writing samples can be submitted to firstname.lastname@example.org.
The Submission Process
We also accept guides sent to email@example.com, though they are assigned a lower priority than GitHub submissions. If submitting by email, be sure to include the guide title in the subject line, and your PayPal or Linode account information in the message body so we can properly compensate you for your work.
If you have any questions about either submission method, contact firstname.lastname@example.org.
The Review Process
All guides will remain on GitHub for up to 2 weeks for the Linode community to comment on or submit pull requests of their own. If you submitted your article through email, it will be added to GitHub by Linode. After the initial review period, your article will be accepted or rejected.
If accepted, we will do an internal technical review of your material which can take from a few days to about a week. Following the technical review is a copy edit of the article; this will take a few days further. Along the process, you may receive questions or comments from us, pull requests with edits, or a request for a resubmission with changes.
Depending on your submission method, we will either submit the final version to your GitHub fork as a pull request or email it to you. You will have 36 hours to respond and approve our publication of the final version. If you respond positively, we will publish the article and you’ll receive payment. Non-response will be taken as a go-ahead to publish.
General Tips to Consider
- Choose topics on relevant technology; guides on emerging tech that is not yet well-documented are preferred.
- Use other Linode guides as building blocks. For example, if your guide requires a system with a working LAMP stack, you can link to our LAMP guides instead of duplicating that information in your own writing.
- Link to your guide from your own website or social media posts. This actually improves the page rankings of your own site because of an SEO aspect called link authority.
- Avoid 3rd-party PPAs and repositories.
- Unless there is a major advantage, use distro repositories rather than compiling and installing from source code.
- We generally decline guides on tweaking or performance tuning. For a guide of this theme to be considered, it must first designate a use scenario. The changes must show a measurable, reliably reproducible improvement between a control group and an experiment group, both operating in the given scenario.
- Use proper capitalization for software. For example, nginx is the web server, NGINX Inc. is the company behind it, and Nginx would only be used to start a sentence, title or heading.
Reasons Your Guide May Be Rejected
As much as we would like to support all writers, we can not accept every guide we receive. Here are some negatives you can eliminate in your own work to ensure a strong submission:
- Not enough content, or lacking original content. For example, if the guide too closely resembles a current guide either by Linode or on another source.
- Guide is a duplicate of your own content from your personal blog, wiki submissions or forum posts.
- Topic is sufficiently documented in official wikis, manual pages, etc.
- Content and formatting guidelines were clearly not followed.
- We already have plenty of guides on the topic. Examples: LAMP & LEMP stacks, MySQL.
- Inappropriate topic for the Linode Community.
Here are some examples of exceptional community-contributed guides. Use these as guidelines for your own submission.
Install Odoo 9 ERP on Ubuntu 14.04 by Damaso Sanoja.
How to Install and Configure GitLab on Ubuntu 14.04 (Trusty Tahr) by Nashruddin Amin.
Host a Terraria Server on Your Linode by Tyler Langlois.
Install and Configure OSSEC on Debian 7 by Sunday Ogwu-Chinuwa.
Turbocharge Your WordPress Search Using Solr by Karthik Shiraly.
COPYRIGHT OWNERSHIP. Writer agrees that the Work is being created by the writer for the Linode Guides & Tutorials repository and that each form of Work is being created by the writer as a “work made for hire” under the United States Copyright Act and, at all stages of development, the Work shall be and remain the sole and exclusive property of Linode. At Linode’s sole, absolute and unfettered discretion, Linode may make any alterations to the Work.
CREDIT. Nothing contained in this Agreement shall be deeded to require Linode to use the Work, or any part thereof, in connection with Linode Guides & Tutorials or otherwise. Credit for the Work shall read, “Contributed by writer’s name.”
PAYMENT. Upon publication of a submission to the Linode Guides & Tutorials Repository, the writer will be paid the sum of USD $250.00 either in the form of a credit to their Linode account or as an electronic payment.
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
This guide is published under a CC BY-ND 4.0 license.