Knowledgebase

Introduction

Welcome to the RCS Creator Program, we are excited that you have decided to help expand our library. The RCS Creator Program consists of both technical documentation and creative videos, whether you're good at technical writing or illustrating steps through a video, the RCS Creator Program is well suited for you.

As a basic requirement, you must follow the RCS Creator Guide, create an account to access the RCS Creator Dashboard, and abide by the Creator Program Guidelines to request, check, and submit assignments. This guide explains what you need to become a RCS Creator that either contributes tutorials to RCS Docs or creates demo videos for the RCS YouTube channel.

Program Rules

Violation of any of the following program rules may lead to your suspension from the RCS Creator Program, and disqualify you from any future submissions.

• You must create an account on the RCS Creator Dashboard.

• You must request an assignment and wait for allocation before submitting your work.

• All content must be produced in English with proper grammar.

• You must submit original content that no one, including yourself, has published before. RCS has a zero-tolerance policy for any type of plagiarism. We encourage research from multiple sources, but any direct copy and paste from these sources is discouraged.

• We do not accept AI-generated content. Your account is automatically flagged once AI context is detected in any content or code.

• We do not accept content with multiple technical errors.

• We may reject your content if it does not meet our quality standards. We will provide feedback on how to improve your content.

• To be eligible for payments, you must set a valid PayPal email address in your RCS Creator Dashboard profile.

• After payment, the submitted content becomes the property of RCS. You are not allowed to publish the same content elsewhere without a written permission from RCS.

• We may re-use your content as needed to improve readability and validate linked resources.

• We may publish your name in the article author section depending on your profile setting in the RCS Creator Dashboard. If your article requires extensive editing, we may decline to credit you as the main author.

• Do not mention other providers that offer similar services to RCS. When mentioned, you can use abbreviations such as AWS, GCP, or Azure.

• Verify that your content solves a specific problem. As a creator, you must possess problem-solving skills to help developers generate solutions from your work.

• Use a minimum number of URL links to resources outside RCS Docs. If possible, when a very important resource is missing, request a new assignment to have it published on RCS Docs.

• We do not accept content about:

  • Blockchain and cryptocurrencies.

  • Peer-to-peer sharing programs such as BitTorrent.

  • Anonymous surfing programs such as Tor, Shadowsocks, SOCKS5, or other proxy software.

  • How to bypass or "crack" licensing systems of applications.

  • Products primarily used to violate RCS's Acceptable Use Policy. For example, media servers, robodialers, and shopping bots.

Our Values

RCS values documentation that is comprehensive, straightforward, accurate, and understandable.

Comprehensive

Our documentation is comprehensive. Every article has all the information required needed to run production-ready applications or troubleshoot errors on live infrastructure. As a creator:

• Cover each topic thoroughly, link to existing RCS articles for prerequisites, and suggest any other linked information that a reader should follow before executing steps in your article.

• Write articles for all experience levels. Do not assume a reader's experience level, but provide resources to learn more when necessary.

• Your article should not make assumptions about the reader's knowledge. If background knowledge is required, describe it in the Prerequisites section along with any relevant links to learn more when possible. For example, To follow this article, you need some basic Python programming skills.

• Your article must include all the steps required, from initial deployment to the final working condition. Including all security requirements and a troubleshooting section to harden the setup for production use.

• Explain how to locate the latest version of a software package. Avoid tagging a specific version that may be obsolete later.

• Your article should assume high security whenever possible. If your article uses HTTP with a linked domain, include HTTPS instructions to secure the server. Use a free SSL/TLS certificate from Let's Encrypt at a minimum. If your article uses SSH, use SSH keys instead of passwords where possible.

• Give the reader all the background information needed to understand and adapt the article to their needs. Explain the concepts through your examples instead of instructing them to directly copy and paste code blocks without describing what they do.

• Each article should have a detailed explanation of the commands used, including any options and flags. Every code block should explain what it does and how it works so the reader can adapt it for their specific use case. When you instruct the reader to execute a command, explain why it's required. These details give readers the information they need to grow their skills and know what to troubleshoot in case a feature fails.

• When describing everyday tasks such as adding a sudo user, using SSH, or updating server packages, link to the appropriate reference or best practice articles.

• Refrain from linking to articles outside RCS unless there's no existing RCS documentation, and you cannot summarize the information in your article. In that case, it may be appropriate to write a reference RCS article first and link it to your main article.

Straight Forward

Our documentation is straightforward and offers readers the exact information they need. As a creator:

• Avoid using a lot of words when describing a single subject. Introduce the reader to what they need to know, and not a full background of the subject that could hide important details. For example:

  • Instead of: Create a new abc.txt file using one of the best Linux text editors called nano which offers an easy-to-use interface.

  • Use: Using a text editor such as nano, create a new file abc.txt.

• Make your commands understandable. A reader may have an Idea of your article subject, and making your commands thoroughly understandable offers a broad view of why it's important to run them.

• Your code blocks should be readable and understandable. Use in-code comments sparingly to keep your code readable.

• Include a troubleshooting section in your article if necessary. This helps a reader fix any errors that may arise from your article steps. For example, if an application returns a permissions error, instruct the user to verify, and set the necessary directory permissions to fix the error.

Accurate

Our documentation is accurate. Each article is tested and proven to work. As a creator:

• Test your articles on live RCS Infrastructure by following them in the correct order as written on fresh instances.

• Occasionally, we offer creators RCS account credit to ensure that articles are thoroughly tested before submission.

• Our editing team runs quality tests before publication to verify that all steps work as listed in the submission, and follow industry best practices.

Understandable

Our documentation is understandable.

• Write your articles in plain language. Do not overuse abbreviations. This is because some readers use online translation tools to read your articles. Articles written in plain language help readers find, understand, and use information the first time they read it. As a creator, you should:

  • Use short sentences and paragraphs.

  • Use simple words that are easy to understand.

  • Use active instead of passive voice.

  • Write in the second person tense.

  • Use a formal but friendly tone.

  • Remove details that add little value to the reader.

Find more information about writing in plain language at the end of this guide.

Topics

Primarily, users reading your articles are mostly interested in server administration, Kubernetes cluster management, Bare Metal, and Cloud GPU applications. Therefore, our documentation library consists of these major categories:

• Installation Guides: Offer step-by-step installation and configuration instructions to help a user deploy a specific application or service. For example: How to Install cPanel on a RCS Cloud Server.

• Quickstart Guides: These are short-form articles that are helpful to users who need a cheat sheet for a specific application as accurately as possible. For example, how to open a firewall port on Ubuntu.

• Best Practices: Describe the best way to execute a particular task. For example, Best Practices when migrating production servers to RCS.

• Troubleshooting Guides: These are step-by-step instructions that help a user resolve common problems.

• Frequently Asked Questions: These are common questions with short answers, rarely more than one paragraph. They link to other RCS resources as much as possible to offer the reader a direct response to the question.

We're looking for articles that span across all categories. Particularly we'd like creators to work on the following topics that are a high priority to the RCS Docs library:

• Kubernetes (RCS Kubernetes Engine)

• Machine Learning (ML) / Artificial Intelligence (AI)

• Data Science

• Cloud Native Applications

• Cloud GPU Applications

• Linux System Administration

• Windows Server Administration

• Security

Payments and Rates

These payment rates are guidelines. We evaluate each article individually depending on its category and priority to the RCS Docs library. Payments are based on the amount of original writing, excluding code blocks. We substantially reduce our payment offer for articles that don't comply with this guide.

If our team finds multiple technical errors or a lot of effort is required to edit your article, you may receive a low payment offer. We prefer to pay you the full amount, so, carefully proofread and test your work before submitting it for review.

To receive your payment, verify that you set the correct PayPal address in your RCS Creator Dashboard profile, and your account allows you to receive payments. We do not process PayPal requests to RCS or donation pages.

Payments for New Assignments

New assignments that are ready to publish without extra editing by RCS are eligible for the highest payments. Depending on your submission's quality, when approved, expect to receive a payment proposal in the following range:

• New articles are eligible for up to $800

• New videos are eligible for up to $1600

Payments for Update Assignments

We pay 50% of the original assignment rate for update assignment. The updated content must contain significantly new information and should not plagiarize any part of the original content.

Updated content with slight differences are not eligible. For example, updating a Ubuntu 20.04 article to Ubuntu 22.04. However, adapting an article to a new platform, such as a Ubuntu-focused installation guide adapted to OpenBSD is considered an update.

Depending on the original assignment, when your updated content is approved, expect to receive a payment proposal in the following range.

• Update articles are eligible for up to $400

• Update videos are eligible for up to $800

Preferred Terminology

In your documentation, strive to use the following terms when referencing RCS Products.

Customer Portal

The customer portal is the RCS web-based user interface accessible via: https://my.rcs.is.

RCS Managed Databases

• If referring to the product category, use RCS Managed Databases.

• If referring to a specific database engine such as MySQL, PostgreSQL, or Redis, use:

  • RCS Managed Databases for MySQL

  • RCS Managed Databases for PostgreSQL

  • RCS Managed Databases for Redis

• When not referring specifically to RCS's implementation, use:

  • managed databases

  • managed MySQL

  • managed PostgreSQL

  • managed Redis

Master and Slave

RCS documentation should follow the upstream project's terminology. For example, if the project uses primary and replica, don't refer to the systems as master and slave. Be mindful that some projects may change their terminology. Before writing your article, you should check the latest documentation to ensure your terms agree with the project's preferred language. If there is no upstream project guidance to follow, use terms that communicate the technical principles accurately. For example:

RCS documentation follows the upstream project's terminology. For example, if the project uses primary and replica, don't refer to the systems as master and slave in your article. Be mindful that some projects may change their terminology.

Before writing, check the project's latest documentation to verify that your terms agree with the preferred language. If there is no upstream project guidance to follow, use terms that communicate the technical principles accurately. For example:

• Primary

• Source

• Destination

• Leader

• Secondary

• Replica

• Follower

These terms often describe the technical process more accurately. Avoid the lazy master/slave terminology because it can be inaccurate in some cases.

Whitelist and Blacklist

RCS's customers are global, and not all cultures automatically assume that white means good or black means bad. Often, whitelist and blacklist don't communicate the technical principles accurately.

When writing, follow the upstream project's documentation terminology. In any case, use accurate technical terms that translate well with online translation tools. For example:

• Allow List

• Safe List

• Deny List

• Block List

• Permitted List

• Prohibited List

Those words translate more accurately for customers who do not understand English.

Bias-free Communication

Use gender-neutral alternatives for common terms. In generic references, don't use he, him, his, she, her, or hers. Instead, use the following constructions:

• Rewrite in the second person (you).

• Rewrite using a plural noun and pronoun.

• Use the or a instead of a pronoun ("the cloud server" instead of "her cloud server").

• Refer to a person's role (reader or customer for example).

• Use person or individual.

• It's okay to use the plural pronouns they, their, or them to refer to a single person.

• Don't use constructions like he/she and s/he.

Since versus Because

Use since to refer to time and because for a reason something happened.

• Correct: *It's been an hour since he left because he had a flat tire.

• Incorrect: He is late since he had a flat tire.

Current

Avoid words like current or phrases like at the time of this writing that imply future changes.

• Correct: Use the most recent VKE version when following this guide.

• Incorrect: The current VKE version is 1.57 at the time of this writing.

Let's

Avoid using Let's, unless referring to Let's Encrypt.

• Correct: Let's Encrypt is a free service that issues SSL/TLS certificates.

• Avoid: Let's log in to the server with SSH.

Login versus Log in

Avoid confusing login with log in. Login is used as a noun or adjective. Log in is a verb phrase.

• Correct: Using SSH, Log in to the server.

• Correct: Navigate to the login screen.

• Correct: Log in to the MySQL console.

• Incorrect: Login to the server with SSH.

• Incorrect: Login to the MySQL console.

Setup versus Set up

Avoid confusing setup with set up. Setup is used as a noun or adjective while Set up is a verb phrase.

• Correct: Set up the Nginx server.

• Correct: Edit the installation setup script.

• Incorrect: Setup the Nginx server.

Once versus After

Once is frequently misused in place of after. Use once when referring to counting and use after when describing a sequence of events.

• Correct: The server reboots once per day.

• Correct: The server reboots after each update.

• Correct: After server reboot, run the update.

• Incorrect: Once the server reboots, run the update.

Oxymorons

Avoid oxymorons such as generally, always, mandatory choice, completely obsolescent, and similar phrases.

So

Avoid using so at the beginning of a sentence. For example:

• Avoid: So, let's log in to the server with SSH.

Simple

Words like simple, straightforward, easy, simply, obviously, and just, are subjective and alienating. They don't describe any task, and they presume the reader's skill level. Some authors use these words to encourage the reader, but when the article's steps are not as simple as stated, a reader gets frustrated.

Give the reader clear explanations so they can be successful in all article steps. Instead of using encouragement words like simple, a troubleshooting section is a better substitute.

Avoid Congratulations!

Adding "Congratulations! You have just..." at the end of your article is a lazy filler line that adds no value to the reader. It's not helpful to a reader that has completed the article successfully, but infuriating to a reader that found an error or trouble following the steps in your article. Instead, summarize your final suggestions and add links to more resources.

Next Steps

As a RCS Creator, visit the following resources to improve your submissions.

• Introduction to the RCS Creator Dashboard

• RCS Docs Creator Guide

• RCS Video Creator Guide

Thank you

Thank you for choosing to contribute to the rcs.ismunity Library. We highly value and appreciate your contributions, in case you have any questions about the program, raise a support ticket in the RCS Creator Dashboard, or contact us.