F4L5E G0DS EVE-EMU Standard Guide

F4L5E G0DS EVE-EMU Wiki Guides

Page creation, style, editing, review, and update standards

Field	Value
Audience	F4L5E G0DS wiki editors, reviewers, page owners, corporation staff, alliance staff, and coalition support editors
Wiki platform	MediaWiki / Wikimedia-style wikitext source editing
Primary standard	This document is authoritative. Any copies are uncontrolled
External model consulted	EVE University UniWiki editing, style, categorization, template, and verification guidance
Version	1.0
Prepared date	2026-07-05

Use this document as the operating standard for creating and maintaining EVE Online pages on the F4L5E G0DS EVE-EMU wiki.

Contents

• 1. Guide for creating a page on the F4L5E G0DS EVE-EMU wiki
• 2. F4L5E G0DS EVE-EMU wiki style guide
• 3. F4L5E G0DS EVE-EMU wiki editing guide
• 4. Page review and updating guide
• Appendix A. Approved category starter set
• Appendix B. Standard maintenance notices
• Appendix C. Copyable page skeleton
• Appendix D. Sources consulted

Navigation note The document uses Word heading styles. In Word, use the Navigation Pane to jump between sections or insert an automatic table of contents if required.

1. Guide for creating a page on the F4L5E G0DS EVE-EMU wiki

This guide defines the standard process for creating new wiki pages. It is designed for editors who are creating a guide, procedure, doctrine-support page, industrial planning page, market page, service page, or corporation, alliance, or coalition operating page.

1.1 Before creating a page

Create a new page only when the topic cannot be handled by improving an existing page. The goal is to keep the wiki searchable, coherent, and easy to maintain.

1. Search the wiki for the exact page title and two or three related terms.
2. Check whether an existing page already covers the subject and could be expanded.
3. Check whether the topic should be a subsection of a broader guide instead of a separate page.
4. Confirm that the page has a practical use: a task, decision, policy, reference, or repeatable procedure.
5. Identify the likely page owner before publishing if the page will require regular updates.

1.2 Page title standard

Use clear, searchable page titles. A good title states the subject in the words an EVE player or editor would search for.

Rule	Use	Avoid
Recognizable name	T2 blueprint invention guide	The advanced thing with copies
Concise wording	Moon ore reprocessing	Everything about moon ore refining, compression, and hauling in every situation
Consistent game terms	High Sec, Low Sec, Null, WH / J Space	Highsec, low-sec, wormholes, J-space mixed inconsistently
No internal jokes in titles	Corporation buyback rules	Skane’s pile of rocks
Sentence case	Engineering structure setup	Engineering Structure Setup

1.3 Recommended creation methods

1. Use the wiki search box to search for the intended title. If the page does not exist, select the create-page option.
2. Alternatively, add a red link from a relevant existing index or parent page, preview it, then open the red link.
3. For a direct URL method, replace the article title in the wiki URL with the new page title, open the blank page, then choose Create or Edit source.
4. Use source editing for guide pages. Visual editing is acceptable for minor prose edits, but source editing is safer for tables, categories, maintenance banners, and reusable wikitext.

1.4 Start from the standard guide template

Major pages should start from the imported standard template. The template is intended for guides, handbooks, tutorials, doctrines, logistics, market, industry, PvE, PvP, and corporation, alliance, or coalition service pages.

1. Open the template page in source view.
2. Copy the entire source.
3. Create the new page.
4. Paste the template into the new page source editor.
5. Replace every bracketed placeholder before publishing, including topic, audience, clone state, security space, required skills, required ISK, last verified, page owner, topic category, and experience-level category.
6. Remove sections that do not apply, but keep Quick start, Before you begin, Standard procedure, Common mistakes, Troubleshooting, References, See also, and categories unless there is a clear reason to omit them.

1.5 Required page structure

Section	Required?	Purpose
Lead paragraph	Yes	Defines the topic and tells the reader what outcome the page supports.
Guide summary table	Yes for guide pages	Shows topic, audience, clone state, space, required skills, required ISK, last verified, and page owner.
Quick start	Yes	Gives the minimum practical procedure for readers who need the direct answer.
Before you begin	Yes	Lists requirements, risks, access, and preparation.
Key terms	When needed	Defines jargon, abbreviations, and local policy terms.
Standard procedure	Yes for task pages	Provides ordered steps with expected results.
Decision table	When needed	Helps the reader choose between options.
Calculations	When needed	Documents formulas and assumptions.
Common mistakes	Yes for guides	Prevents recurring support questions.
Troubleshooting	Yes for process pages	Maps symptoms to likely causes and fixes.
Policy section	When applicable	Separates corporation, alliance, or coalition rules from general game mechanics.
References	Yes when factual claims need support	Lists citations using MediaWiki ref tags.
See also	Yes when related pages exist	Connects the page to nearby wiki content.
Categories	Yes	Places the page in the browsing structure.

1.6 Category requirements

Every finished article should have at least one category. Guide pages should normally use one broad guide category, one EVE Online category, one topic category, and one experience-level category.

[[Category:Guides]]

[[Category:EVE Online]]

[[Category:Industry]]

[[Category:Beginner guides]]

Do not publish placeholder categories Never publish literal placeholders such as [[Category:[Topic category]]] or [[Category:[Experience level category]]]. Replace them with approved category names before saving.

1.7 Save-preview-publish workflow

1. Click Show preview before saving.
2. Check the guide summary table for broken rows, missing fields, or unfilled placeholders.
3. Check headings. The body must not use Level 1 headings. Start article sections at Level 2.
4. Check that links are relevant and not overused.
5. Check that categories are real, approved categories.
6. Check that references render under the References heading.
7. Write a clear edit summary.
8. Save the page.
9. Open the saved page and scan the rendered version, not only the source editor.
10. Add the page to any appropriate index, navigation, or parent guide page.

1.8 Standard edit summaries

Change type	Recommended summary
New guide	Create guide for [topic] using standard guide template
New policy page	Create corporation policy page for [topic]
New category page	Create category page for [category]
Major rewrite	Rewrite guide for current mechanics and standard format
Minor fix	Fix typo, link, or formatting issue
Verification update	Update last verified date after checking current mechanics

1.9 Page creation checklist

• The page topic is not already covered by an existing page.
• The title is concise, searchable, and written in sentence case.
• The standard guide template was used for major guides.
• The lead explains the topic and practical outcome.
• All bracketed placeholders have been replaced or removed.
• The guide summary table is complete.
• Procedures are numbered and include expected results where useful.
• Tables have clear headers.
• Only the first meaningful occurrence of important terms is linked.
• References and categories render correctly.
• The page owner and last verified date are set.

2. F4L5E G0DS EVE-EMU wiki style guide

This style guide defines the house style for F4L5E G0DS EVE-EMU wiki pages. It is based on practical technical writing: clear purpose, direct language, consistent terms, and verifiable instructions.

2.1 Core writing principles

• Write for the player who needs to act, not for the expert who already understands the subject.
• Prefer practical instructions over long theory.
• Use plain English and avoid unnecessary complexity.
• Separate game mechanics from corporation, alliance, or coalition policy.
• State assumptions, risks, prerequisites, and exceptions.
• Use examples that could actually occur in EVE Online.
• Keep pages maintainable by using consistent sections and categories.

2.2 Headings and page layout

Rule	Standard
Page title	Use the actual page title or DISPLAYTITLE only when needed.
Lead	Use a short lead before the first heading.
Heading level	Do not use Level 1 headings inside the article body. Start sections with Level 2 headings.
Heading case	Use sentence-case headings.
Table of contents	Let MediaWiki generate the table of contents automatically.
Section order	Use quick start, requirements, procedure, mistakes, troubleshooting, references, and see also for most guides.

2.3 Standard terminology

Use	Avoid or correct
F4L5E G0DS	False Gods unless quoting a source that uses that spelling
Fenris Creations (FC) on first use, then FC	Undefined FC or alternate organization names
High Sec	highsec, high-sec, high security unless quoting a source
Low Sec	lowsec, low-sec, low security unless quoting a source
Null	nullsec or null-sec unless a page title or source requires it
WH / J Space	wormhole space, J-space, jspace mixed inconsistently
ISK	isk
EVE Online	Eve Online
EVE-EMU	eve emu, EVEEMU

2.4 Abbreviations

Define abbreviations at first meaningful use unless the abbreviation is universally understood in the article context.

Fenris Creations (FC) operates the service. FC maintains the approved access list.

Tech II (T2) invention requires datacores and blueprint copies.

• Do not use an abbreviation in a page title unless the abbreviation is the normal search term.
• Do not capitalize a full term only because its abbreviation is capitalized.
• Use one abbreviation consistently throughout the page.

2.5 Links

• Use internal links on the first meaningful occurrence of a topic.
• Do not link every repeated occurrence of the same term.
• Do not put links inside headings.
• Use external links only when they add value, support verification, or point to a required tool.
• Use descriptive link text rather than raw URLs in normal prose.
• When linking to a category page from prose, use a leading colon so the current page is not categorized by accident.

Good internal link:

[[Blueprint copy|blueprint copies]] are used for invention.

Good category link in prose:

See [[:Category:Industry|Industry]] for related pages.

2.6 Lists, procedures, and decision tables

• Use numbered lists for ordered tasks.
• Use bullet lists for unordered options, requirements, or examples.
• Use decision tables when the reader must choose between options.
• Keep each step action-oriented. Start with a verb where possible.
• Add an expected result after complex steps.

Situation	Use this option	Avoid this option	Reason
Reader must follow actions in order	Numbered procedure	Paragraph-only explanation	Order matters and missed steps create errors.
Reader must compare choices	Decision table	Long prose comparison	Tables reduce ambiguity.
Reader needs definitions	Term table	Inline definitions spread across page	Readers can scan terms quickly.

2.7 Tables

• Use tables for structured comparisons, requirements, risks, troubleshooting, and calculations.
• Every table must have clear header cells.
• Avoid very wide tables on normal article pages.
• Do not use tables only for visual alignment when a list would be easier to maintain.

2.8 Calculations and formulas

Market, industry, hauling, reprocessing, and tax pages should show assumptions before results. Use simple formula blocks when the math matters.

Net profit =

Gross revenue

- Taxes

- Broker fees

- Material cost

- Hauling cost

- Replacement risk

• Define each input before using it in a formula.
• State the market, date, structure, tax, and system cost assumptions when relevant.
• Do not present spreadsheet outputs as universal truths without assumptions.

2.9 Tone and point of view

• Use neutral, instructional language.
• Avoid personal insults, recruitment pressure, and unsupported claims.
• Write policy pages as policy, not as opinion.
• Use warnings for concrete risks, not for dramatic emphasis.
• Do not bury major risk information in footnotes or side comments.

2.10 References and evidence

• Use references for mechanics, patch-related facts, formulas, and claims that may change.
• Prefer current in-game verification, official support pages, patch notes, reliable wiki pages, or maintained internal documents.
• Add <references /> under the References heading when using ref tags.
• Do not cite unverifiable Discord hearsay as a factual authority. If Discord is the source of a local policy decision, identify it as internal policy rather than game mechanics.

2.11 Style checklist

• Headings are sentence case.
• The page begins with a short lead.
• No Level 1 body headings are used.
• Internal links are useful and not repeated excessively.
• External links are necessary and named clearly.
• Terminology is consistent across High Sec, Low Sec, Null, and WH / J Space.
• FC is defined before being used as an abbreviation.
• Tables have headers and are not needlessly wide.
• Calculations state their assumptions.
• The article distinguishes mechanics, policy, opinion, and example values.

3. F4L5E G0DS EVE-EMU wiki editing guide

This editing guide explains how to safely change existing pages and how to make edits that other editors can review, improve, or reverse if needed.

3.1 Who should edit

Editors should make changes when they can improve accuracy, clarity, formatting, structure, or usefulness. If an editor is unsure about mechanics or policy, they should add a maintenance notice or use the page discussion area rather than publishing uncertain claims as fact.

3.2 Edit or create?

Situation	Action
The page already covers the topic but is incomplete.	Edit the existing page.
The page is outdated but still the right home for the topic.	Update the page and add a clear edit summary.
A subsection has become long enough to be its own guide.	Create a new page and leave a link from the parent page.
The subject is a local FC procedure, not a general game mechanic.	Create or update a corporation, alliance, or coalition policy page.
The change affects controversial policy or access.	Discuss first or request review before making broad changes.

3.3 Safe editing workflow

1. Read the full page before editing a section.
2. Check the last verified date and recent page history.
3. Use Edit source for markup-heavy changes.
4. For major rewrites, copy the page into a sandbox or user draft first.
5. Make the smallest edit that solves the problem unless a full rewrite is justified.
6. Preview the edit before saving.
7. Check links, tables, references, and categories in preview.
8. Write an edit summary that explains the change.
9. After saving, review the rendered page.
10. If the page is important, add it to your watchlist.

3.4 Source editor quick reference

Purpose	Wikitext
Level 2 heading	== Heading ==
Level 3 heading	=== Heading ===
Bold	'''Bold text'''
Italic	''Italic text''
Internal link	[[Page name]]
Piped internal link	[[Page name|display text]]
External link	[https://example.org display text]
Bullet list	* Item
Numbered list	# Step
Category tag	[[Category:Guides]]
Link to a category page	[[:Category:Guides|Guides]]
Reference	<ref>Source text or link.</ref>
Reference list	<references />
Redirect	#REDIRECT [[Target page]]

3.5 Using discussion pages

• Use the discussion page for proposed major rewrites, disputed claims, protected pages, and policy questions.
• Sign discussion comments with four tildes: ~~~~.
• Summarize the specific change requested instead of asking vague questions.
• For complicated changes, include the proposed replacement wikitext so a reviewer can copy it directly.

3.6 Maintenance notices

Use maintenance notices to route work to editors. Do not leave work-in-progress notices on pages indefinitely.

Notice type	Use when
Work in progress	You are actively editing the page and expect to continue soon. Remove it when done.
Update	The page is likely outdated because of game, policy, system, or process changes.
Cleanup	The page has grammar, formatting, organization, readability, or style problems.
Verify	A specific claim may be wrong but has not yet been confirmed.
Merge	The page overlaps substantially with another page.

3.7 Editing standards for common changes

Change	Standard
Typo fix	Make directly, preview, save with a concise edit summary.
Formatting cleanup	Keep content meaning unchanged unless the edit summary says otherwise.
Procedure update	Verify the procedure and update expected results.
Policy update	Confirm owner approval before publishing.
Calculation update	Update assumptions, formula, source, and example values together.
Screenshot or image update	Use current UI, crop clearly, and explain the image in nearby text.
Category update	Use approved categories and avoid creating near-duplicates.

3.8 Edit summary standards

• Good edit summaries explain what changed and, when necessary, why.
• Do not use empty summaries for meaningful edits.
• Use minor-edit marking only for changes that do not alter meaning.

Weak summary	Better summary
Fix	Fix broken internal links in troubleshooting section
Update	Update invention steps for current FC structure workflow
Cleanup	Reformat requirements table and remove duplicate text
Stuff	Add risk controls for Low Sec hauling

3.9 Editing checklist

• The edit improves accuracy, clarity, structure, or maintenance.
• The edit does not introduce unsupported mechanics claims.
• The edit does not mix FC policy with general game mechanics.
• Tables, links, and references still render correctly.
• The page still follows the standard guide structure.
• The last verified date was updated only when the content was actually verified.
• The edit summary is useful to future reviewers.

4. Page review and updating guide

This guide defines how to review pages for accuracy, currency, formatting, and usefulness. It is intended for page owners, senior editors, corporation staff, and anyone maintaining operational documentation.

4.1 Review triggers

• A major EVE Online expansion or patch changes mechanics, skills, structures, markets, or UI.
• FC, corporation, alliance, or coalition policy changes.
• A user reports that a page is wrong or unclear.
• The page has not been verified within its review cadence.
• A related page has been rewritten and links or terminology may now be inconsistent.
• A template, category structure, or wiki skin change affects rendering.

4.2 Review cadence

Page type	Recommended cadence	Reason
Core game mechanic guide	Every major expansion or every 6 months	Mechanics, UI, and numbers can change.
Market or tax calculation page	Monthly or after major market/system changes	Prices, fees, indices, and assumptions drift quickly.
Corporation service page	Quarterly or after policy changes	Access, owners, and procedures can change.
Doctrine-support page	After doctrine change or every 3 months	Fits, skill assumptions, and escalation rules change.
Reference category or style page	Every 6 months	Standards should remain stable but not stale.
Archived or historical page	Only when archive status changes	Avoid unnecessary churn on intentionally historical pages.

4.3 Review levels

Level	Scope	Result
Level 1: quick scan	Check obvious rendering, broken placeholders, missing categories, and outdated banners.	Minor fixes or route to deeper review.
Level 2: content review	Verify steps, mechanics, requirements, risks, links, formulas, and examples.	Update page and last verified date if confirmed.
Level 3: subject-matter review	Ask an experienced player, service owner, or policy owner to validate the page.	Approve, revise, or flag disputed sections.
Level 4: structural rewrite	Rebuild the page using the standard template when structure blocks maintenance.	Publish a clean version with clear edit summary.

4.4 Evidence hierarchy

Use the strongest available evidence. A page can be clear and still be wrong if it relies on stale assumptions.

Evidence type	Use for	Caution
Current in-game verification	UI steps, stats, service behavior, live mechanics	Record date, character context, and location if relevant.
Official patch notes or support pages	Patch-related mechanics and feature changes	Confirm the page reflects the current state, not only a historical change.
Maintained external wiki pages	Cross-checking general mechanics	Do not copy style or wording directly.
FC internal policy records	Corporation, alliance, or coalition rules	Label as policy, not universal game mechanics.
Screenshots	UI state, site waves, dialog boxes, structure setup	Crop clearly and avoid exposing sensitive information.
Player reports	Bug leads, unclear instructions, missing cases	Verify before converting reports into factual claims.

4.5 Review procedure

1. Open the page in read mode and read it as a new player would.
2. Check the guide summary table for page owner and last verified date.
3. Open the page history and scan recent edits for context.
4. Check all maintenance banners and resolve what can be resolved.
5. Review the lead and quick start for accuracy and usefulness.
6. Verify requirements, skills, ISK assumptions, tools, structure services, access, and policy dependencies.
7. Check each procedure step against the current game or current FC workflow.
8. Check calculations and examples for assumptions, current values, and formula errors.
9. Check links, references, categories, and see-also entries.
10. Update content, banners, page owner, and last verified date as appropriate.
11. Preview, save with a descriptive edit summary, then check the rendered page.

4.6 Handling outdated or uncertain information

Condition	Action
Information is confirmed correct.	Leave it, improve wording if useful, and update last verified date if the review was broad enough.
Information is wrong and the correction is known.	Correct it and cite or explain the basis for the correction.
Information is probably wrong but not yet verified.	Flag the specific claim for verification and explain the suspected issue.
The whole page is outdated.	Add an update notice, summarize the reason, and assign or request an owner.
The page is structurally unusable.	Rewrite using the standard guide template or create a replacement draft.
The page is obsolete but historically useful.	Mark as archived or historical according to local wiki practice.

4.7 Last verified field

The last verified field is a promise that the page, or the relevant section, has been checked against current information. Do not update it for copyediting alone.

Edit type	Update last verified?
Typo, grammar, or formatting only	No
Broken link replacement only	No, unless the linked source was used to verify content
Checked every procedure step in game	Yes
Confirmed policy with current owner	Yes for policy pages
Updated formula with current assumptions	Yes, if assumptions and source are documented
Added a warning based on an unverified report	No; use a verification notice instead

4.8 Review checklist

• The page purpose is still valid.
• The title and lead match the page content.
• The guide summary table is accurate.
• The page owner is current.
• The last verified date is justified.
• All procedures reflect current game mechanics or current FC workflow.
• All risks and prerequisites are still true.
• Market, tax, and calculation assumptions are current or dated clearly.
• Screenshots and UI references match the current interface.
• Maintenance banners are accurate and not stale.
• Categories are approved and useful.
• The page has no unresolved placeholders.

4.9 Review record format

For important pages, add a short review record on the talk page or a designated review log page.

== Review record: YYYY-MM-DD ==

* Reviewer: [[User:Name]]

* Scope: Full page / Section only / Policy only / Formula only

* Evidence checked: In-game / Patch notes / FC policy / External reference

* Result: Verified / Updated / Flagged for review / Needs owner

* Notes: [brief summary]

~~~~

Appendix A. Approved category starter set

Use this starter set to prevent category sprawl. Create additional categories only when existing categories do not fit and the new category can be described clearly.

Category	Use
Category:Guides	Instructional guide pages.
Category:EVE Online	General EVE Online pages.
Category:Beginner guides	Guides for readers with little prior experience.
Category:Intermediate guides	Guides for readers who know the basics and need procedures or optimization.
Category:Advanced guides	Guides for experienced readers handling edge cases, scale, or advanced operations.
Category:Industry	Mining, refining, reactions, manufacturing, invention, blueprints, industrial infrastructure.
Category:Markets	Trade, pricing, arbitrage, buyback, hauling economics, trade hubs, market watchlists.
Category:Corporation operations	Corporation services, roles, logistics, admin workflows, member procedures.
Category:Alliance operations	Alliance-level services, logistics, policy, access, and coordination pages.
Category:Coalition operations	Coalition-level services, logistics, policy, access, and coordination pages.
Category:Wiki templates	Reusable page templates and editor-support material.
Category:Wiki maintenance	Maintenance, review, style, and administrative pages.

Appendix B. Standard maintenance notices

The exact template names depend on what has been installed on the F4L5E G0DS EVE-EMU wiki. If these templates do not exist yet, create them or use plain-text notices until the template set is available.

Notice	Suggested wikitext	When to remove
Work in progress	{{Work in progress}}	When active editing is complete or has gone stale.
Update	{{Update|reason=Needs verification after latest mechanics or policy change.}}	When content has been updated and verified.
Cleanup	{{Cleanup|reason=Needs formatting, references, or technical-writing pass.}}	When style, grammar, structure, and readability issues are fixed.
Verify	{{Verify|reason=Specific claim needs confirmation.}}	When the specific claim has been confirmed or corrected.
Merge	{{Merge|Target page}}	When merge decision is complete.

Appendix C. Copyable page skeleton

Use this shortened skeleton for small pages that do not need the full standard guide template.

{{DISPLAYTITLE:EVE Online [topic]: [plain-language subtitle]}}

'''[Topic]''' is [one-sentence definition]. This page explains [purpose] for [audience].

== Quick start ==

# [Step 1.]

# [Step 2.]

# [Step 3.]

== Before you begin ==

{| class="wikitable"

! Requirement

! Minimum

! Notes

|-

| [Requirement]

| [Minimum]

| [Notes]

|}

== Standard procedure ==

=== Step 1: [verb phrase] ===

# [Instruction.]

# [Instruction.]

Expected result: [result].

== Common mistakes ==

{| class="wikitable"

! Mistake

! Fix

|-

| [Mistake]

| [Fix]

|}

== Troubleshooting ==

{| class="wikitable"

! Problem

! Likely cause

! Fix

|-

| [Problem]

| [Cause]

| [Fix]

|}

== References ==

<references />

== See also ==

* [[Related page]]

[[Category:Guides]]

[[Category:EVE Online]]

[[Category:[Topic category]]]

[[Category:[Experience level category]]]

Appendix D. Sources consulted

The document adapts standards to the F4L5E G0DS EVE-EMU context rather than copying external guide text. Sources consulted for structure and practices:

Source	Location
MediaWiki Help:Starting a new page	https://www.mediawiki.org/wiki/Help:Starting_a_new_page
MediaWiki Help:SourceEditor/User guide	https://www.mediawiki.org/wiki/Help:SourceEditor/User_guide/en
MediaWiki Help:Categories	https://www.mediawiki.org/wiki/Help:Categories