The nature of the Geometry Dash series in conjunction with its historic update schedule informs a precedent of two wildly differing frequencies between developer releases and community content additions.
To better understand the Geometry Dash Expanded Wiki's article creation policy, it benefits to understand how wikis are typically organised.
Geek mode lesson in wiki category structures
A well-structured wiki helps viewers find and navigate to articles of similar subjects of likely interest by organising these articles into categories. Every article on a wiki should be categorised.
After reading to the end of an article's page, present is its category module displaying links to category pages (which on the Geometry Dash Expanded Wiki displays just a single link). These are not tags/hashtags (the way which other wikis might incorrectly use them, implying that these links have been added to the article). Rather, a link in the category module shows that an article is included in that category. A category functions to group categorically-related articles (hence the name), convenient for a viewer to easily browse. Additionally, this organisation of articles then informs the sidebar's navigation links, and parts of the main page.
The Geometry Dash Expanded Wiki recognises two classes of categories as follows.
Class A: Base content - these categories include the wiki's primary articles, pertaining to base content of the Geometry Dash series whose subjects originate from the developer's contributions via historically infrequent game updates. Yet, these 'official' subjects remain of high interest to all players, particularly those new to the series. These categories are appended with '(base content)', highlighting their significance.
- Base content articles are actively monitored and maintained by wiki staff, and in turn, they are upheld to a higher quality standard. Additionally, they are carefully organised into a most fitting category, and are directly linked on the main page's primary article site map.
- It is at staff's discretion how subjects pertaining to base content are included on the wiki, for example, whether or not an article(s) is created for something new added in an update, or whether this is instead organised into an existing article(s).
For staff reference regarding making updates to site structural listings of Class A categories and/or their articles, instances around the wiki include:
Class B: Community content - these categories include the wiki's secondary articles, pertaining to significant user levels, prominent players, and in broad reference, various other community activities, events and phenomena. The scope of community-derived content relating to Geometry Dash is vast and of varying degrees of significance, relevance and interest to a wider audience. This underpins the article creation policy where it is most applicable to those who seek to create articles on the wiki.
- A rated User level, having been officially recognised by the developer, will always be eligible for article creation.
- An unrated User level may be eligible for article creation if it:
- Is published, to recognisably wide public awareness, with some kind of standout significance which will maintain ongoing relevance over the long term, and the drafted article is developed comprehensively to high presentable standard, essentially 'complete'.
- Was de-rated for any reason.
- A deleted User level may be eligible for article creation if:
- A surviving copy of the level is present in some form, whether through a re-upload or third party tools such as GDHistory.
- It has garnered recognisabe public awareness, with some kind of standout significance which will maintain ongoing relevance over the long term, and the drafted article is developed comprehensively to high presentable standard, essentially 'complete'.
- A player - who might 'specialise' as an influential community figure, a popular content creator, a top-performing player, or a renowned level creator (but not an in-game moderator with no other credentials)—may be eligible for article creation if they:
- Are widely recognised for their specialty, reflected by engagement of others, which can include a noteworthy number of social media followers across platforms, views and commenting on content created by them (including displays of that content produced by third-parties), and a noteworthy number of downloads of their levels.
- Have been significantly and historically influential in the origination or propagation of a trend that is widely recognised as impacting the wider community culture, including in areas of level creation, as well as general content creation for video and social media, and the drafted article is developed to a majorly presentable standard.
- An activity, event, or group of people may be eligible for article creation if it:
- Has been directed by, prominently participated in, or emphatically endorsed/promoted by the developer.
- Has been a longstanding influential resource that is widely recognised as impacting the wider community culture.
For staff reference regarding making updates to site structural listings of Class B categories and/or their articles, instances around the wiki include:
The process of creating a new article benefits from formally proposing it.
Work in progress!
This article is currently undergoing development and in the process of receiving additional information. You can edit it to achieve a higher standard.
Namespaces designate the design and intention of page content. Each serves unique purposes, with specific structures and differing permissions. This Manual of Style explains these aspects to inform editors how to achieve a logical, high-quality interface that is consistent and understandable across the site.
Formally titled the (Main) namespace, articles are the primary medium that content relating to the wiki's subject is presented for viewers, and constitute where most normal editing occurs.
- Layout
Except for articles in the Games and Updates categories, only specific h2 headings should be used, which may include the following, based on the article's subject:
- Description
- Levels
- Gameplay
- Secret coins
- Trivia
- Gallery
- General syntax
- Canadian English should be applied.
- Articles should be written in third person.
- The 'player' should not be referenced when instructions are being provided on how to conduct a series of actions.
- Dates should be ordered: date, full-word month, year. There should be no commas between date and month, and only one positioned after year. Example: 1 January 1990 is correct formatting; January 1, 1990, 1st of January, 1990, and 1/1/90 are examples of incorrect formatting.
- No heading should be provided for the lead introduction section.
- The first instance of an article's title should be formatted in bold only.
- Game names do not require additional formatting, except being capitalised, and linked in their first instance.
- Page titles should be linked once only. If the same page title appears further down the page, it should not be linked. Links appearing in infoboxes and tables are excluded from this count and may be repeated, including the same links within a table. If a tabber is being used to divide page content, the same links in different tabber sections may be repeated, granted that the links did not occur before the tabber. If they happened after the tabber, then they may be repeated only once.
- Headings which use consecutive equals signs '=' should not be separated on either side from the contained phrase by a space. A line break should precede headings. All level headings should use a capital letter for the first word only, excluding proper nouns. Floated elements, including various thumbnails and infoboxes, should be positioned from the first line after a heading and before any text.
- The asterisk '*' or hash '#' used for unordered and ordered lists, respectively, should not be separated with a space from their text, nor from each consecutive line by a line break.
- Gallery captions should not end with a period '.', unless multiple sentences are included.
- Tables composed of wikitext should begin and end with '{|' and '|}' respectively at the start of their lines. Cells which may use either of '|', '!', '|-' or '|+' should be separated by one space from the start of their lines. Style specifications for specific cells should be separated by spaces on either side from the initial pipe and the second pipe beginning the content input. Only
class="wikitable" should be included within the first line of a table to enable design styling and formatting. The exception is if a table is contained within a tabber, where style="width:100%;" should be included after the class specification, and additional code is used before and after the table to adjust its margin to align with the edges of the tabber, as follows.
_tabber>
Table filling tabber body=
<div style="margin:-1.5rem -1rem;">
{| class="wikitable" style="width:100%;"
!Header
!Header
|-
|Body
|Body
|}
</div>
_-|
Table within tabber body with preceding text=
Text before table.
<div style="margin:0 -1rem -1.5rem;">
{| class="wikitable" style="width:100%;"
!Header
!Header
|-
|Body
|Body
|}
</div>
_/tabber>
- Line break tags
<br> and <br clear="both">, which are self-closing, do not require the end slash '/' to be included. They should precede the immediately preceding content character, where needed.
- Any HTML that is specifically needed should be condensed, with no spaces between characters unless the syntax requires it.
- Avoid using comments
<!-- --> as a permanent fixture except in irregular cases, such as where the common positioning of an element differs or where unusual code may be necessary and benefits editors from explanation.
- Language links should be at the bottom of the article content, below categories, each on its own line, ordered alphabetically.
- Examples
'''Nocturne''' is the umpteenth level of [[Geometry Dash]] and the first level with a Psycho difficulty. It introduces ''Bob the Cube'' to the Geometry Dash universe.
==Main heading==
[[File:FILENAME.png|thumb]]
[[File:FILENAME.png|thumb]]
Text.
{| class="wikitable"
|+Main heading
|-
!Header1
!Header2
|-
|Cell
| style="color:yellow;" |Formatted cell
|}
===Subheading===
<div style="display:grid;grid-template-columns:1fr 1fr;gap:12px;">
<div>
*Bulleted
*Bulleted
**Bulleted
*Bulleted
**Bulleted
</div>
<div>
#Numbered
#Numbered
#Numbered
</div>
Talk pages are a traditional method of discussing page content on wikis. They may be cleared or deleted upon the resolution of any matters that are raised against them. Signatures may be used to quickly imprint a user's username, which should not include any files, template transclusions or tags.
User pages are a user's personal editing space, with no restrictions on subject, as long as site policy is complied with. Additionally, the following should be noted.
- Using internal links is not permitted, as these are recorded in maintenance reports, so external links should be used instead, including to link to other pages on the wiki.
- Templates that are not intended for use on user pages—such as those used on the main page—are not permitted.
- Specific tags or other complex elements may be removed.
- Prominent visual obstruction produced by overly creative page styling may be removed.
Only staff members may edit the user pages of other users (typically to remove files, templates, and tags once the user is deemed inactive). Consent must be given by the owner for other users to edit the owner's user page.
User page extensions (sub-pages of the User namespace) are not encouraged as they are often found to be redundant and consequently may have any content relocated back to the respective user pages and then be deleted, but may be allowed upon request to staff on the condition that they are found to provide a distinct purpose, for example, storing a large amount of advanced code for relevant preservation or testing purposes that would otherwise significantly disrupt the flow of the requesting user's user page. Approved user page extensions will be reviewed after one month of inactivity to determine whether they are still necessary to maintain.
Meta pages designate site articles that pertain to wiki-related subjects but are not specific to Geometry Dash itself. They are usually editable only by staff. Where editing is permitted for non-staff, edits should align with the intended function of the page; otherwise, editors may incur penalties.
Files are non-textual components of articles providing visual and auditory content. They should abide by the site policy. No content other than a category and, in some instances, a licence template should be present on any file page.
Article syntax: All file names should be capitalised as is consistent with their titles.
Images should be in the .png image file format, where possible, as this typically yields superior digital quality compared to other supported image file formats. Ideally, the resolution should be as high as possible, although this should be consistent among any one image series as determined by a common category. Images may be replaced in this regard, as the entire series is updated to maintain consistency.
Article syntax: In all instances, captions should be used sparingly and not to state obvious visible details or context. 1) Inline image files should be thumbnailed, right-aligned (default for thumbnails, not requiring specification) and configured to 270px on their own lines, individual from one another. 2) Configuration can be ignored when they are used in galleries (although galleries should use the 'packed' mode) or 3) when used in infobox image fields. 4) Icon images used in vertical infobox fields should be configured to 35px but not thumbnailed. 5) Icon images used in tables should be configured to 24px but not thumbnailed.
1. [[File:FILENAME.png|thumb|270px]]
2.
<gallery mode="packed">
FILENAME.png
</gallery>
3. |image = FILENAME.png
4. |FIELD = [[File:FILENAME.png|35px]]
5. |[[File:FILENAME.png|24px]]
Typically, galleries containing predominantly in-game screenshots should use the default setting with three images per row, while galleries containing icons/sprites should use eight images per row, enabled by including class="icon-gallery" within the gallery tag.
Videos can be displayed on the wiki either as uploaded files or directly from YouTube via the embedded media player, if the option is available.
Article syntax: Embedded videos use a special parser function. However, Template:VC should instead be used in all instances
Audio files include those in the .mp3 and .ogg file formats, the former typically used for music, and the latter typically used for sound effects.
Article syntax: Audio files should be thumbnailed, right-aligned (default for thumbnails, not requiring specification) and configured to 270px on their own lines, individual from one another. Such a configuration is not required for positioning in tables or infoboxes.
[[File:FILENAME.ogg|thumb|270px]][[File:FILENAME.ogg]]
PDFs complement articles with third-party information. They should be positioned under their own heading so that they are easily locatable.
Article syntax: PDF file pages should be bypassed, and the documents themselves should be directly linked to using the 'Media:' prefix. The link should be bold and assigned a relevant title.
'''[[Media:FILENAME.pdf|Title]]'''
MediaWiki pages are system pages that affect the design and functionality of the site. They are editable only by interface administrators.
Templates work by having content that exists on a template page being 'transcluded' onto another page, where it is then displayed identically as it is on that template source page. This feature serves either to prevent clutter by substituting a template for the addition of complex syntax on a page, or to allow frequently occurring content on multiple pages to be modified instantaneously from a centralised point. Information about producing documentation for template pages can be viewed on Category:Templates.
Article syntax: Template names should be capitalised as is consistent with their titles, but do not require prefixing. Parameters beginning with pipes '|' should be separated by one space from the start of their lines. Equals signs '=' should be separated on both sides by a space, unless more than two parameters are present, where all equals signs should be vertically aligned starting from the equals sign closest to the longest word on its left side, still separated by a space.
- Notices should be included on their own line at the top of articles.
- Infoboxes should be included on their own line at the top of articles, below any notices.
{{TEMPLATENAME
|parameter1 = field1
|parameter2 = field2
|parameterXYZ = fieldXYZ
}}
The category system works by including pages within categories so that pages of a similar subject are organised together and can be navigated to through a tree structure. Note that categories are not tags and are not to be treated as broad characteristics that a viewer may consider a relevant search term. An article, project, file, template or category page should be included in only one category so that it can be reached in linear sequence from Category:Geometry Dash Expanded Wiki. Temporary exceptions include the use of Category:Article stubs for marking undeveloped articles and Category:Candidates for deletion for marking unnecessary content through the related templates, which automatically include the aforementioned categories. Pages from all other namespaces should not be included within a category. Category pages of articles or files do not require any content to be included on them. Other category pages may consist of concise descriptions. New categories should only be created under the direction of staff.
Article syntax: Categories should be included on their own line at the bottom of articles, not separated by a line break from the final line of content. Only template series that use letter prefixes in their titles should have a differentiating letter included as a parameter in the category link, which enables the page titles to have more intuitive alphabetic indexing on category pages.
[[Category:CATEGORYNAME|&]]
