Editorial Policy

GoLinuxCloud publishes practical, hands-on tutorials about Linux, DevOps, Kubernetes, programming, networking, and security. Every article you read on this site is written by a named, attributable engineer who has actually executed the steps they're describing.

This page is our public commitment to how that happens — what we publish, how we research it, who reviews it, and what we do when we get something wrong.

Last reviewed: 30 May 2026.

1. Our mission

We exist for one reader: the working engineer or curious learner who needs a problem solved in the next 30 minutes. Not the marketing-funnel reader, not the auto-translated content-farm reader. A real person with a real terminal open who needs an answer that works on the version they're running.

Everything below flows from that mission.

2. Who writes for GoLinuxCloud

GoLinuxCloud is a multi-author publication, founded and edited by Deepak Prasad (R&D Engineer with 10+ years of production Linux, DevOps, Kubernetes, and security experience; Red Hat certified across OpenStack, Cluster Storage, JBoss Enterprise Application, Server Hardening, and more).

We publish guest articles from a small group of vetted contributors whose profiles, credentials, and areas of expertise are publicly listed on the site. You can see every author here: /author/.

We do not:

  • Publish under house pseudonyms ("by GoLinuxCloud Team", "by Admin").
  • Publish anonymous or single-name contributions.
  • Outsource writing to a content mill or PR agency.
  • Buy AI-generated articles and republish them under a real author's name.

Every byline corresponds to a real person who can be contacted, whose photo we have on file, and whose stated credentials we have verified at intake.

3. How an article is commissioned

Topics for new tutorials come from four places, in roughly this priority order:

  1. Real problems we have solved at work — the engineer-writing-for-engineers feedback loop.
  2. Reader questions sent to [email protected], comments, or contact form submissions.
  3. Search-intent gaps — topics where the existing top-10 results genuinely fail to answer the underlying question (often AI-generated thin content).
  4. Vendor / tool changes — a new RHEL release, a Kubernetes minor version with breaking changes, a CVE that needs an explainer.

We do not commission articles purely because they are "high search volume". Topics where we have no first-hand experience are turned down, even if they would obviously rank.

4. How an article is written

Every tutorial goes through the following workflow before publication:

  1. Outline. The author lists the concrete outcomes a reader should be able to achieve. If the outcomes can't be enumerated, the article doesn't get written.
  2. Sandbox setup. A clean environment is provisioned that matches the OS, distro, and tool versions stated in the article (typically a VM, container, or disposable cloud account).
  3. Live execution. Every command in every code block is executed top-to-bottom against that environment. Output is captured directly from the live terminal session, not hand-written. Screenshots are taken from the actual UI, not mocked up.
  4. Drafting. Prose is written after the steps are known to work — never before.
  5. Self-edit. The author reads the draft as if they were the reader: do the steps survive copy-paste, is the goal stated up front, does the example reflect a realistic situation?
  6. Peer review. Drafts that touch authentication, TLS, IAM, secrets, or crypto are reviewed by a second person before publication. See Fact-Checking Policy for the details.
  7. Copy-edit and SEO. Final pass for clarity, accessibility, internal linking, alt text on every image, and an honest meta description that does not over-promise.
  8. Publish. Article goes live with explicit datePublished and dateModified timestamps.

A tutorial that fails step 3 (the commands didn't work as described) goes back to step 2. It does not get "fixed in editing" or shipped with a disclaimer.

5. How we research and source claims

When an article makes a factual claim — about an OS feature, a CLI flag, an RFC, a vendor's behavior, a benchmark result — we cite the primary source:

  • Standards and RFCs are linked to the IETF, ISO, IEEE, POSIX, or W3C source.
  • Vendor documentation is linked to the canonical docs URL (e.g. kubernetes.io, docs.python.org, docs.aws.amazon.com, access.redhat.com), not to an aggregator.
  • Scientific results are linked to the preprint or peer-reviewed paper, not to a press release about it.
  • Other practitioners' work that we're building on is linked to their original post with their name.

We do not republish another author's tutorial. If a peer's article is the best explanation of a topic, we link to it and explain why we agree, rather than rewriting it.

6. Fact-checking

GoLinuxCloud maintains a public Fact-Checking Policy that describes the specific steps each article goes through before publication — what gets re-tested, on what version, by whom, and how regressions are caught when a tool changes underneath an older tutorial.

In short: every command is executed on the version stated, security-sensitive content is peer-reviewed, and high-traffic tutorials are re-verified roughly twice a year against the latest stable release.

7. Updates, maintenance, and the dateModified field

Tutorials about live software age. We mitigate that two ways:

  1. Every article carries a visible dateModified timestamp at the top of the page, and that timestamp is the truth — it changes only when content was actually re-tested and revised, not when a typo was fixed.
  2. Major upstream events trigger a re-test sweep: a new RHEL major version, a Kubernetes API removal, a Python minor bump that deprecates syntax, a Docker security advisory. The author who originally published the affected tutorials is asked to verify (and update or retire) them.

Articles that we no longer maintain are clearly marked as such or, in some cases, redirected to a more current replacement; we do not silently delete URLs that may still have inbound links.

8. How we use AI

We use generative AI assistants (ChatGPT, Claude, Gemini, GitHub Copilot, Perplexity) as research aids only:

  • For terminology lookup, "what is this called in industry?"
  • For surfacing official documentation faster.
  • For drafting an initial article outline that the author then reorders, rewrites, and adds first-hand experience to.
  • For grammar/style polish on already-written prose.

We do not:

  • Publish AI-generated articles as if they were written by a person.
  • Trust AI output as a source of truth — every command an AI produces is treated as a hypothesis that must be verified against primary documentation or by running the command in a sandbox.
  • Use AI-generated screenshots or fabricated terminal output.

A paragraph generated by an AI never appears unchanged in a published article. Either the author rewrites it in their own voice with their own example, or it doesn't ship.

This stance is unlikely to change — partly because Google's Helpful Content System explicitly devalues unedited AI content, but mostly because our readers can tell.

9. Independence from advertisers, sponsors, and affiliates

GoLinuxCloud is funded by three streams:

  • Display advertising served by AdPushup (an authorized Google AdSense partner) and AdRecover.
  • Affiliate links to products we actually use or recommend (for example, Rocket.net, which hosts a separate project of ours).
  • Reader tips via Buy Me a Coffee.

These funding streams do not influence editorial decisions:

  • Advertisers cannot pay to have a topic covered, a competitor mentioned negatively, or an article edited.
  • Affiliate links are added only to articles where the product was already chosen on technical merit. We disclose the affiliate relationship at the link.
  • Sponsored posts (paid placements) live under /sponsored/ and are not labeled as regular editorial. They do not appear in the homepage feed or the category pages.

If we ever review a product we've received free of charge, that disclosure is made at the top of the article, not buried at the end.

10. Diversity and accessibility

We try to keep the writing accessible to readers who are not native English speakers and to readers using assistive technology:

  • We avoid US-centric or India-centric idioms where simpler phrasing works.
  • Every image carries descriptive alt text (we are working through a backlog on older WordPress-era articles).
  • Code blocks are real text, never images of text, so screen readers and translators can process them.
  • We use semantic headings (one <h1> per page; logical <h2> / <h3> hierarchy) so navigation is predictable.

11. Comments, community, and moderation

When article comments are open, we moderate to remove spam, personal attacks, off-topic promotion, and links to malware. We do not delete comments simply because they disagree with the author. A polite correction or a sharper alternative approach in the comments is exactly what we want.

12. Corrections

We will get things wrong, and we want to know when we do. The full process — how to report, how fast we respond, what we change, and what we publicly log — is in our Corrections Policy.

13. Contact

Our full contact and identity details are on the About Us page.