1. Start with diagnosis
A guide should identify the visible symptom, relevant error code, likely causes, and checks that distinguish one cause from another. Instructions should not jump directly to an invasive change when a read-only diagnostic can narrow the problem first.
2. State the environment
- Name supported operating systems, versions, hardware families, applications, or firmware where known.
- Identify required permissions, tools, downloads, free storage, power conditions, and expected downtime.
- Call out incompatible, untested, encrypted, managed, or production environments.
- Use exact error codes, service names, package names, and paths where they improve safe matching and search.
3. Prefer reversible steps
Guides should progress from observation and low-risk changes toward more invasive actions. Each meaningful configuration change needs an appropriate reversal path. When a step cannot be reversed—such as a factory reset, secure erase, firmware flash, or physical repair—the guide must say so before the user begins and offer safer alternatives first.
4. Protect data, access, and hardware
- Never ask users to publish passwords, private keys, recovery keys, personal records, or unredacted diagnostic bundles.
- Storage, encryption, bootloader, partition, firmware, registry, and account-recovery steps require prominent prerequisites and stop conditions.
- Temporary security changes must be narrowly scoped and followed by steps to restore protection.
- Hardware guides must include power isolation, electrostatic-discharge precautions, warranty concerns, and professional escalation where appropriate.
- Downloads should point to official publishers whenever possible. Unknown binaries, blanket exclusions, and permanent security bypasses are not acceptable fixes.
5. Define success and failure
Every guide should tell readers how to confirm the original symptom is resolved, what output or behavior to expect, and when a restart is required. It should also identify warning signs that mean the user should stop, roll back, restore from backup, or seek a qualified technician.
6. Community review and revision-aware verification
New and changed guides may be published as unverified while they gather review. Community confirmations must come from authenticated users who actually tested the guide and are not its author. Verification belongs to the tested revision; a material edit can make earlier confirmations stale.
Moderators may reject, relabel, restrict, or remove guidance that is unsafe, misleading, copied without permission, obsolete, or inconsistent with reported environments. Reputation and popularity never override a credible safety concern.
7. Prohibited guidance
FixingBook does not permit instructions whose primary purpose is unauthorized access, credential theft, malware deployment, destructive wiping without informed consent, evasion of lawful controls, concealment of compromise, or permanent weakening of security. Legitimate defensive administration must be clearly scoped to systems the reader is authorized to manage.
8. Reporting a problem
If a guide caused an unexpected result or appears unsafe, stop applying further steps. Preserve the command output and relevant, non-sensitive environment details. Use the guide’s edit or comment tools, or email team@fixingbook.com with the guide URL, revision, expected result, and actual result.