Editorial Policy
Updated: September 7, 2026 · 中文
1. Editorial purpose
straw-dog covers open source, self-hosting, deployment, and AI automation. We aim to explain what a project solves, who it suits, what it needs to run, and the long-term maintenance cost. Popularity, advertising budgets, and polished demonstrations should not substitute for these questions.
Selection considers practical use, verifiable information, maintenance activity, licensing, data control, deployment requirements, and alternatives. Inclusion is not comprehensive certification; absence is not a judgment that a project is poor.
2. Sources and verification
Technical facts should primarily rely on official documentation, upstream repositories, release notes, licenses, security advisories, and original research. Community discussions offer leads and experience but should be checked against official information, reproduction, or other evidence.
Articles should distinguish upstream claims, author observations, actual tests, and inference. Commands, default ports, resource requirements, paid limitations, and licensing need sufficient context. Results for one version should not be presented as permanent facts. Information we cannot independently confirm should be qualified or withheld from a definitive conclusion.
Prices, offers, regional availability, and service policies change. Read them in the context of their source or checking date and verify current provider information before purchasing.
3. Test labels and tutorials
A project introduction, deployment guide, and hands-on test represent different levels of evidence. Content should be labeled as tested only when actual work supports it, with the version, operating system, method, server resources, key steps, and test scope described where possible.
A test may cover installation, startup, and basic functions without covering load testing, long-term stability, backup restoration, every feature, or a security audit. Uncovered areas should be identified. Demonstration data and reference configurations must not be presented as production business results.
New versions, architectures, and environments can change the outcome. A past successful test does not establish present compatibility everywhere. Destructive commands, database migrations, and public exposure need an explanation of risks and recovery preparations.
4. Recommendations and comparisons
Comparisons should address a consistent use case and explain tradeoffs in features, resource use, data export, maintenance, licensing, and total cost. We do not assume open-source software is inherently more secure or paid services inherently more reliable.
Advantages and limitations need evidence. Featured placement, downloads, or GitHub stars can help readers discover projects but do not establish performance, security, or continuing maintenance. Material limitations and suitability conditions should not disappear for the sake of shorter copy.
5. AI assistance and human responsibility
AI may assist research planning, organization, translation, outlining, editing, and drafting. Its output can contain invented commands, dead links, mistaken licensing claims, or fabricated tests. It is not an independent source of fact.
Generated drafts require human review, source verification, and necessary duplicate checks before entering publication. Editors remain responsible for final review and corrections. Generated logs, screenshots, or experiences must not be presented as actual testing.
Where AI use materially affects how readers interpret evidence, it should be explained, for example by labeling illustrative images or describing the preparation method. Customer secrets and personal information should not be submitted to external AI services without appropriate authorization.
6. Commercial relationships and independence
Deployment services, memberships, kits, sponsorships, and referral commissions may fund the website. Sponsorship, free resources, paid placement, and commission-bearing links should be clearly disclosed in the relevant content or location so readers can recognize the relationship before deciding.
Sponsorship can determine an agreed placement or commissioned topic. It should not alter evidence-supported technical conclusions or conceal drawbacks, security issues, or alternatives. Partners may check names, configurations, and factual descriptions but cannot require favorable verdicts, invented experience, or removal of reasonable criticism.
Our own paid offerings should also explain scope, additional costs, and limitations. Public tutorials should not be confused with contractual promises for a purchased service.
7. Corrections, updates, and withdrawal
Use our Contact page to send the URL, specific issue, and sources. We assess reports against evidence. Potential data loss, security problems, or materially misleading instructions should receive priority; a warning or temporary withdrawal may be appropriate during review.
Minor typographical fixes may be made directly. Changes to technical conclusions, critical procedures, commercial disclosure, or decision-relevant information should explain significant corrections in the affected content. Abandoned projects, license changes, and obsolete tutorials may require updates, an outdated-content notice, or removal.
A modified date does not automatically mean the entire article has been retested. When older material remains useful, its date and scope should be clear.
8. Chinese and English editions
Both editions should share the same facts and core conclusions, with terminology, units, and context explained for their readers. Actual differences in pricing, availability, or checkout methods need explicit explanation; translation is not a promise of identical regional supply.
Translations require checks of technical terms, commands, versions, and links. If one edition has not yet caught up with an update, readers should not assume the conclusions are necessarily synchronized. Please report discrepancies.
9. Attribution and feedback
Respect authors, maintainers, and original sources through appropriate attribution, links, and license compliance. Images, code, and trademarks are not automatically available for unrestricted commercial use simply because they are online.
We welcome evidence-based criticism, failed reproduction reports, and different perspectives. Requesting a correction, declining a partnership, or giving an unfavorable assessment should not invite retaliation. We may reject submissions that are unverifiable, infringing, spam, or conditional on concealing a commercial relationship.
Related pages: About Us · Terms of Service · Privacy Policy