Ruby-Doc Learn creates helpful, legitimate and valuable information for Ruby programmers. The purpose of this policy is to clarify how we select our topics, write our articles and ensure the material is acceptable prior to publishing.
Editorial focus
The main areas covered are Ruby, Ruby on Rails and related technologies. We may also discuss other programming languages, platforms or services in relation to developing with Ruby. Examples of suitable connections include comparing programming languages; using APIs; using deployment platforms; selecting databases; monitoring performance; writing tests; and improving overall programmer efficiency. We do not create articles that relate to a completely different area of interest for the sole reason of targeting highly searched terms or for accommodating a paid link.
Selecting topics
Each proposed article must provide answers to three questions:
- Who is this article intended to help?
- What specific practical issue or question will it solve?
- Why does this topic belong on Ruby-Doc.org?
We will not accept an article solely because a keyword has high search volume or a third party has requested coverage.
Value and originality
Articles must be produced specifically for Ruby-Doc Learn. Contributors may not submit copied, lightly rewritten, syndicated or previously published material unless its reuse has been approved and clearly disclosed.
An article must add significant value through one or more of the following ways:
- New code examples
- An author’s first-hand development experience with developing something
- Testing or benchmarking
- Step-by-step troubleshooting
- Analysis independent of others
- More understandable explanations of complicated concepts
- Comparison based upon set criteria
- New diagrams, presentations or interactive tools
Simply creating a summary of existing search results or rewriting someone else’s publication is insufficient.
Technical validity
Claims made regarding technical issues should be verified against credible evidence. Documentation provided directly by official sources, industry standards, source repositories, and/or the original projects’ materials are preferable whenever available.
When feasible, code examples should be tested. When necessary to avoid confusion, articles should describe the relevant version(s), environment(s) and/or limitations that may affect the results.
A technical reviewer may be utilized if the subject matter being addressed is beyond the demonstrated expertise of the author, or if an error contained within the article could significantly mislead readers.
Authorship and Review
Each article must display an accurate by-line along with information concerning the article’s author. No person shall be listed as the author of an article simply because their name or reputation would lend credibility to the document.
If one person writes an article while another performs substantive technical reviews, both roles should be separately identified.
As stated above, authors and reviewers should disclose all applicable commercial, employment or personal relationships/interests.
Using editorial tools & automation
During preparation writers/editors may utilize spelling tools, code-assistants, research tools or automated tools to assist in preparing an article. None of these tools relieve writers/editors from their editorial responsibility.
Material created with automation may not be published without substantive human authorship, verification and editing. Factual claims, references and code must be checked independently.
If the utilization of automation impacts readers ability to understand how the article was created, an editorial disclosure statement may be included.
Links to Sources and References
Links should help readers verify claims, find supporting documentation or continue learning. We do not insert links solely to manipulate search rankings.
Paid links, advertising and/or other commercial placements must be properly disclosed and tagged as such. Authors may not add undisclosed affiliate links nor links from which they receive compensation personally.
Preparation and Publication
Prior to publication, each piece of content must undergo the following review process:
- Relevance
- Originality
- Technical Accuracy
- Correctly attributed authorship
- Quality of sources/references
- Commercial conflicts
- Relevance of referenced links
- Readability and Accessibility
Content may be updated after initial publication due to changing software; availability of new data/evidence; reader identification of errors in content. Content that can no longer be maintained may be archived, redirected or removed.
Editorial Independence
Ruby-Doc.org makes all final editorial decisions. Advertisers/sponsors/clients/contributors (internal/outside) may NOT pay for favourable conclusions; obtain editorial approval; acquire unqualified links.
Please direct your questions regarding this policy to contact@ruby-doc.org.
Last updated: 3 September 2026