The guidelines serve as a manual of style and a reference on the best way to write articles with your fellow editors. By following the guidelines, editors can provide an accurate, impartial, consistent and accessible source of information for users. By following the guidelines you help other editors focus on writing new content.
Never be afraid to contribute! Making edits in good faith regardless of the level of quality is nothing to worry about, other editors can help you improve your contributions to meet the guidelines; atl.wiki is a collaborative effort between all editors!
These guidelines are in constant development, if something is unclear from the guidelines contact an admin or fallback to Wikipedia's Manual of Style.
To contribute or propose changes to the guidelines, refer to the protected page guidelines.
Key Values
Accuracy
Ensure information is accurate and up to date; this can be done by ensuring you are using the official sources or other high-quality and reputable sources for information. Please ensure you appropriately cite your sources, following our Citations Guidelines. If you cannot find an appropriate source for a statement, it does not belong on the wiki. Any claim or statement that could be challenged must be backed up by a reputable source.
Impartiality
Pages should be unbiased; if there has been a controversy on a specific topic, avoid it. Advocacy should be avoided as we strive to keep an impartial tone to explain the points of view fairly. If a topic only has one point of view, then please seek consensus from other editors to ensure that a biased view does not propagate on the wiki. There is no "best view". In all arguments, both sides have their merits, so highlight those rather than bringing down the other side with its flaws. Editors' personal experiences, interpretations, or opinions do not belong here.
Consistency
Ensure that your page is consistent with other pages and follows our standards through the formatting, language, and terminology used. Further details and specifics on how we wish to approach this on the wiki can be seen in the Formatting Guidelines. If there is any doubt, consult an admin. In general as long as the language used is consistent with the rest of the page and the terminology is used correctly, use your best judgement on how to format and layout the page.
Courtesy
Before making significant changes to existing pages, consult with the active editors or an admin to ensure alignment with others' efforts. If disagreements arise, strive to resolve them constructively and positively. Avoid personal attacks, edit wars, or using the wiki as a platform to make a point. If needed, reach out to an admin for help in resolving conflicts. Be welcoming to new members, helping them to get started and teaching them the ropes. Always act in good faith while assuming the same of others.
Accessibility
We aim to make the wiki accessible to all users regardless of ability levels, be them brand new to the Linux and FOSS communities or seasoned veteran users. Always make sure to explain in detail what something is or does, or how it can be used. For guides, explain every step with why you are doing it and what each command or instruction does so that any user can understand what they are doing. Do not assume the reader will know everything you may know, and make sure they can easily follow along or learn from anything you write.
Citations
Always cite the sources of content when it is required; this can be because you are referencing others' statements, the release date of a piece of software, or for any material that is challenged or is likely to be challenged in particular. If you ever obtain content from another source (such as taking info from a wiki with a compatible licence) or quote other locations online, ensure you link to it appropriately.
The easiest way to add Citations to a page is to use the auto generated citation system! You can use it by pressing "Cite" on the toolbar of the visual editor, select Citation Template and fill out the relevant information! If you use the source editor you can see the Template Data and examples on the Template:Cite page.
A citation is composed of two components: an inline superscript next to the relevant section of text,[1] you can insert this by using the "Cite" button on the visual editor and adding it after relevant content or the <ref> </ref> tags. The second component is the references list at the bottom of a page; this is auto-generated once the page is saved.
For the inline citation, there is no specific style required as long as you state the author, year of publication, the date of retrieval, and, if possible, a link to the original source. We do not mandate any specific referencing style, a sample has been provided below:
<Title (Hyperlinked if possible)>, <Author>, <Year of Publication> (<Retrieval Date>).
e.g:
[https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf Linux Filesystem Hierarchy], Linux Foundation, 2015 (Accessed: November 27, 2024).
Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD, because of the ambiguity concerning which number is the month and which the day. Editors should not attempt to change an article's established citation style, merely on the grounds of personal preference or to make it match other articles, without first seeking consensus for the change. Always avoid switching between citation styles and maintain consistency.
Sources should be published & reliable, and it should be ensured that they are independent, published sources with a reputation for fact-checking and accuracy. Proper sourcing is always dependent on context; common sense and editorial judgement are an indispensable part of the process. In general, newer sources are better; however, if an older source is considered more reliable, it should be used over the newer one. Articles should also attempt to primarily rely on secondary sources whenever possible and if possible avoid other wiki's such as wikipedia for sourcing but rather look for the sources they cite instead.
Edit Summary
When editing a page you are prompted to provide a summary of the edits you have made, the purpose of the summaries is to provide other editors a brief explanation of the changes.
The summary should clearly and accurately convey the changes made and if necessary an explanation for why you made the edits made particularly if you are reverting a change of another editor or doing a large overhaul to an article.
Avoid abbreviations and keep the summary to what its meant to be, a summary. It should be two sentences at most, one explaining what was changed and one why it was changed. Longer discussions or debates belong in the talk pages not in summaries. Avoid being vague or writing misleading summaries such as "made a change" or mention one change but not another.
Once an edit summary is made it cannot be revoked. Ensure when you write the summary you will not regret it afterwards. In the rare case of harmful content you may request an admin to remove the edit summary from public view via revision deletions however this is only done in exceptional circumstances.
Notability Standards
When creating a new page for the wiki it must meet several criteria, these are to maintain both relevance and ensure a page has enough content and sources to meet the wiki guidelines. The following requirements should be met before a new page is created:
- Sufficient Sourcing
- You should ensure that the topic the article is on has sufficient sourcing as per the citations guidelines, in general you should aim that every claim can be cited. Sources should generally be secondary sources unless referring to documentation and should be from trusted and respected sources.
- Relevant Topic
- The topic of the article should be relevant to the wiki. This includes but is not limited to: Operating systems and its software, development tools and languages, general software and system management practises. In general if the topic is related to technology it is welcome.
- Please note we don't aim to have extensive documentation of every feature or function of a piece of software or system, however it is reasonable to list command syntax on a sub-page (Such as Sed/Syntax). Please also ensure exhaustive examples are also on a sub-page (Such as Sed/Examples).
- Pages Correctly Located and Categorised
- Pages that align with the guides policy (When a set of instructions are given to achieve a goal on the users systems it must be created as a guide), must be created as a guide and the contrary that non-guide articles must be in the main namespace. This also applies to categories, please ensure you correctly categorise the page as per the categories guidelines.
- Pages meet the Guidelines and Code of Conduct
- Ensure the new page meets the wiki's Code of Conduct and all of its guidelines, particularly ensure it has the necessary information and features such as infoboxes or templates as defined in the formatting guidelines.
Templates
Cleanup
This article or section may require a cleanup. The specific problem is: Example.
If a page does not meet the standards of the wiki, you can use the {{Cleanup|Reason}}
Citations
This article or section has little to no citations.
If a page has little to no citations, you can use the {{Needs Citations}}{{Citation needed}}
Guides Warning
This article or section lists commands or instructions which could potentially damage your system. Please ensure you understand the commands or instructions you are running or following before you run or follow them.
If a page or a section of the page contains instructions or commands of any form, this template is required to be placed above it, this is to inform users to be cautious of potentially malicious content that could be edited in. You can add the template using {{Guide_Warning}}
Guides Policy
You can see the full guidelines on the Guides Policy, this is a summary of the policy.
Guides are anything that explain to a user how to do something beyond a link to another source or a brief instruction. The following extra policies apply to guides: The {{Guide Warning}} template is required on the page, and all changes MUST be approved by staff for public viewing via ApprovedRevs. Please also ensure all commands are accurate and do not attempt to mislead users with the information on guides.
Linking & Redirects
You should ensure that if possible you have linked to other pages as such using [[Page_Title|markup text]], you can also use the link button on the toolbar when using the visual editor. The first occurrence of the title should be linked, infoboxes should always be considered the first occurrence if a page has one. You may add links to pages which do not exist already but do not overdo it and ensure the link is to a page which is suitable and meets the page creation standards before linking it.
In some cases you may be linking to a page as a reference for something multiple times, such as linking to guidelines or a use of a template, in these cases it is acceptable to not follow the first occurrence rule and link it as appropriately needed.
Redirects should be used for only two reasons:
- Where a topic has an alternate title, such as KDE Plasma and Plasma.
- Where a title may have capitalisation or grammar variants, such as Multi-Booting and Multi Booting.
In general redirects are fine as long as they are reasonable, if in doubt consult an admin.
Categories
Categorise pages when needed; you can do this by selecting the hamburger menu and then the categories button. Avoid making new categories unless it's required.
Formatting
Language
All content should be in English unless there is a specific reason for why it shouldn't be. The version of English does not matter as long as pages are consistent; e.g., if the American English spelling of "color" is used, the British English spelling of "colour" should not be used within the same page. The only case where a specific spelling is required is when the name of a company or piece of software uses a specific spelling; e.g., "Grub Customizer" uses the American spelling. A comparison chart of the spelling can be found here.
Dates
Exact dates should always be given wherever possible. For all-numerical dates, they must always follow the ISO 8601 (YYYY-MM-DD) standard. For non-numerical dates, the following is required: The day must not be zero-padded and must not use ordinals (1st, 2nd, 3rd 4th). The month must not be abbreviated and must be capitalised. The year must not be zero-padded, must not be abbreviated, and must not contain commas. Below are dates not acceptable on the wiki, the correction, and the issue with the invalid date.
| Invalid Date | Corrected Date | Issue |
|---|---|---|
| Mar. 1 | March 1 | Use of a a full stop following a date or month and using an abbreviated month name. |
| 1. May | 1 May, May 1 | |
| 1 may, may 1 | Months should be capitalized. | |
| 1st May, May 1st | Use of ordinals (1st, 2nd, 3rd, etc.) | |
| 01 May, May 01 | Zero-padding days | |
| 2025/05/01 | 2025-05-01 | Use of other symbols than hyphen |
| 20250501 | Ommitance of hyphen | |
| 25-05-01 | Abbrivation of year | |
| 05-01-2025, 01-05-2025, 2007-01-05 | Not using YYYY-MM-DD format | |
| '25 | 2025 | Abbreviation of year |
| Two thousand twenty-five | 2025 | Writing year or day in words |
| the first of May, May the first | 1 May or May 1 | |
| May 0560 | May 560 | Zero-padding year |
| May 2,025 | May 2025 |
Images
Images should always have alternate text, this is essential for users who are reliant on screen readers or are not on internet capable of rendering images. You can do this by adding the alt attribute to an image, the description should explain what is in the image but should aim to be as short as possible. If the alt text needs to be longer it should explain the premise of the image in the first sentence. For more guidance on how to write alternate text see the Wikipedia guide. You can add alt text as such: [[File:Tux.svg|alt=Tux, the Linux mascot: A black and white penguin with a yellow beak and feet sitting down.]].
Commands
When referencing a command in the sense of a page on it (e.g: A page on sudo), it should not be formatted differently. However when listing a full command or example it should be in a code block, you can add one with the "Insert" button and select the "Code Block" option with the "Shell" option and then type your command.
For code blocks avoid having comments inside them and place the comment as normal text above the codeblock, we also advise for shorter commands to use the inline code block with the keybind "Ctrl + Shift + 6" if the command is short and can flow with the content.
We are working on a template to help place commands easier, please be patient!
Protected Pages
Pages in the ATL:, Mediawiki:, Template:, Modules: namespaces and certain high traffic pages are protected for a variety of reasons, so users are unable to edit them, you can propose the changes following the steps below:
You can choose to not make a sandbox and just explain the changes on the talk page (Step 3 onwards). The following instructions are more for large changes, for spelling or grammar fixes it is more suitable to just make a note on the talk page explaining the issue and the fix required. Either method is acceptable and it is up to the user to deem which method they prefer.
1. Create a sandbox page under your user page, e.g: https://atl.wiki/User:Username/PageTitle and copy the source of the page you wish to propose changes to, using https://atl.wiki/edit/PageTitle to view the source.
2. You can edit the page to add in the changes you wish to propose, please ensure they follow the guidelines. You may want to consult an admin prior to major changes to ensure they will not be rejected and are in line with our goals.
3. Using the page's talk page (Which can be accessed using the discussion button at the top of the page), outline what changes you wish to propose (Including the link to your sandbox, if appropriate) and why you think those changes should be implemented.
4. An administrator will respond to the proposal with either feedback or confirmation of the implementation of the feedback. If there is no response after 7 days, you may contact an administrator for feedback on your proposed changes.
For admins: When implementing user feedback on protected pages, ensure any changes or proposed changes meet the guidelines and follow the goals of the wiki. You can then copy the edited sections source into the main page, please double check the diff's and formatting. When saving the edits ensure to in some form credit the contributing user such as
Written by: [[User:Username]].
Artificial Intelligence Policy
Using Artificial Intelligence (AI) to generate content for the wiki is forbidden. This includes both written content or the use of AI generated images, AI generated images are only allowed when the use of them are relevant to an article and clearly disclosed as being AI generated. This applies to all content on all pages of the wiki.
AI powered tools such as grammar checkers or use of AI for checking the accuracy of the English used is permitted without a need for disclosure. These tools assist editors in invaluable ways however there should always be human oversight on all assistance from AI to ensure any content assisted by the AI meets our guidelines.
atl.wiki makes use of Cloudflare's anti-AI technologies to block AI scrapers due to them generally not respecting our wiki's license, CC BY-SA 4.0. Training on the wiki's content is only permitted when the use of the data respects the license by both being under the same license (Sharealike) and properly attributed to its authors. To see how to properly attribute content see the Creative Commons Guide or the Wikipedia Guide on the topic.
Responsible Disclosure
Vulnerabilities in software much be treated with the utmost care on the wiki as it could be used by malicious actors to take advantage of vulnerable systems. Due to this we have a strict policy on when vulnerabilities can be addressed or made mention of in the wiki.
Before a vulnrability can be mentioned on the wiki you must wait 7 days after both:
- The vulnerability has been publicly disclosed by the vendor, a CVE Numbering Authority, MITRE or any similar authority.
- There is an official patch, mitigation or fix which has been released by the vendor.
Mentioning or making any reference to a vulnerability until 7 days after both criteria are met will have the edit reverted and vanished. Any link to tools to or instructions on how to exploit any vulnerability will be treated in a similar manner. The only exception for this is generic tools for vulnerability exploitation (Such as Kali Linux) or after 1 month of both criteria being met it is permitted to have brief overviews of the exploits.
References
- ↑ Sample Reference
This page has been adapted from Wikipedia's Manual of Style and the Gentoo Wiki Guidelines for our own needs and refined to what is seen to be fit by the team. Nothing has been taken verbatim from them however some sections are developed off their stances and will be similar so great thanks goes to their contributors for creating a great starting point for us.