We do tech policy here
Put bullet points here, we will sort them later
Useful resources:
Technical Content Policy Draft
(by scutoid studios)
CSS Policy Draft
(by scutoid studios)
Tech Reform Proposal
(by ReyDay)
Techlight Policy
Policies
- So we include aspects for:
- UI/UX (colors, fonts, sizes)
- Security (links, IP, how easy it is to break it)
- Stability (how broken this code is, code's performance, phone compatibility)
- Accessibility (Internal and External: readability of the code and how easy it is to use the component in question)
- Documentation (how it works and its use cases)
- For documentation, I was thinking that we make it mandatory to have a list of CSS variables and/or Wikidot parameters and what each does, how it works, and its format. this applies to both components and themes (specifically theme bases and those that introduce new variables)
- Regarding Component Porting:
- I am thinking it goes through your normal techlight process, checking for all the normal things we check for in a techlight. I also think we should still allow devlights on imported components.
- I think it's really something that's up for the Techlighters and Techies' opinions and is per-case thing; but a basic criteria is that it mustn't be directly associated with something outside The Backrooms.
Devlight Policy
Policies
- insert some policy to write
Tech Upkeep Policy
Policies
- insert some policy to write
Tech Policy Vote Results
File Hosting
All page content (themes, components, images, HTML, attached files, text) must be hosted on Backrooms Wiki. Content cannot be crosslinked from other Wikidot sites, even the official sandbox site, as staff must be able to manage all content of the page. The only exception is for using a Cross-Site [[Include]] for components from the Wikidot Snippets repository.
All files should have a file extension appropriate to their file type: an image file should be called "level-achromatopsia.png", not "level-achromatopsia".
Files larger than 4mb may not be uploaded without staff approval. Generally, files should be less than 2mb in size.
Images are subject to specific restrictions:
Images should not exceed 800 KiB in file size, and should not have dimensions significantly larger than their appearance on screen.
Note that the default width for the standard image-block component is 300 px, so, for instance, an image with a width of 1200 px would be too large. Larger images may be uploaded, provided the reduced-size file is the one actually displayed.
Staff are permitted to shrink images that are too large as described above.
Images on Art Pages or large video files on any page may be hosted on other sites, provided the site is in control of the author.1
Due to a bug, uploaded SVGs may not be correctly recognized by Wikidot. See here for more information.
Font hotlinking is permitted if in compliance with the CSS Policy!
ListPages and Offsets
If an offset-based article requires the creation of child pages, those pages must be created in the fragment: category, and they must be named according to its parent page and index. If the parent page is renamed, the fragment pages must be as well.
For instance, if a user posts a page my-story, then each of the offsets could be named fragment:my-story-0, fragment:my-story-1, fragment:my-story-2, etc. starting from the index 0 and onwards in order.
All fragment pages must be listed in the page source, for instance:
[[>]]
[[module Rate]]
[[/>]]
[!--
Fragment pages:
https://backrooms-wiki.wikidot.com/fragment:my-story-0
https://backrooms-wiki.wikidot.com/fragment:my-story-1
https://backrooms-wiki.wikidot.com/fragment:my-story-2
https://backrooms-wiki.wikidot.com/fragment:my-story-3
--]
[[module ListPages category="fragment" parent="." order="created_at" limit="1" offset="@URL|0"]]
%%content%%
[[/module]](Pages with ten or more fragments may provide ListPages code to list all the fragments instead)
Fragment pages must be parented to their host page, regardless of whether parent pages are used as a selector for the ListPages module.
The usage of redirect modules on fragment pages is forbidden.
If a page's tags on an offset-based article would present a significant spoiler for the reader, then, as a special exception pursuant to Tech approval, tags may be hidden on the first offset only by use of the Hide Tags component.
Link Shorteners
Link shorteners and QR codes are not allowed on the Backrooms Wiki. As the character limit of a wiki page is long enough to not be a concern, neither of these is necessary. Further, as they disguise links and make the destination unclear to a user, they pose a mild security concern.
Staff reserve the right to issue exceptions to this rule if they deem it necessary for the article's purpose.
ListUsers and Username Mentions
The ListUsers module allows authors to call upon the username of a reader, and insert that username into an article. However, it also limits content to only be accessible to users who both have an account and are logged into it, meaning that users who are not logged in or do not have an account cannot read parts of the article.
As little content as possible should be gated behind a ListUsers module. Generally speaking, this means that the ListUsers module should only contain the specific paragraph in which the username is being mentioned. The article should not have substantial or major differences between the version that is displayed to a user who is logged-in, versus the version displayed to one who is not.
Wherever possible, the ListUsers components should be used, rather than the base Wikidot functionality. This component allows for alternative content to be displayed to a logged-out user, and should be used to present an equivalent version of the gated content that does not reference username.2
Parenting
Wikidot permits pages to be assigned a single parent, which appears at the top of the page with navigation links called "breadcrumbs". These are used to show that articles are related to a particular article.
Supplement pages, like interview logs, should be parented to the main article that they relate to. 'More by' pages must be parented to their creator's author page, if they have one.
Due to Wikidot limitations, if an author wishes to parent their page to multiple articles, they should use the following code, rather than the standard parenting feature:
[[div class="pseudocrumbs"]]
[[[parent-page-url1|Title of First Parent Page]]] » Title of Child Page
[[[parent-page-url2|Title of Second Parent Page]]] » Title of Child Page
[[/div]]Authors may assign the parent of their page as they wish, provided it does not interfere with the technical implementation of other pages that they do not have authorization to edit.
Site staff are authorized to assign page parents to improve site navigation and accessibility.
HTML and Javascript
Keep your use and number of [[html]] and [[iframe]]s to a minimum!
Javascript may not be malicious, and must comply with CC-BY-SA-3.0 — it must also be justifiable to the Tech Team.
Any HTML or javascript in a page may not take actions outside of the page itself (e.g. sending unsolicited emails or accepting payment), transmit information about the reader with or without reader consent, or perform an irreversible action. Cookies and local storage are permitted if they are strictly necessary for the proper behaviour of the page.
Page content may not create pop-ups or automatically open links that the user has not clicked on. Using CSS to create the illusion of a pop-up within a page is completely acceptable.
Minified HTML, CSS, or Javascript may be used, but the un-minified full source must be disclosed and publicly available. Like all other content, they must be available under the site's license (CC-BY-SA 3.0), though it may be dual-licensed with another free/open source license.
ThemePreviewer Module
The ThemePreviewer Module lets you remove the Site Theme, and then you can add other theming on top of it. Due to security concerns, users are not allowed to use this module on their pages on their own. To achieve the functionality usually desired by the use of this component, use:
- bhl-revert to revert the theme to the base Black Highlighter theme
- show-sidebar to remove the hover functionality on the sidebar
- toggle-sidebar to make the sidebar revealed by clicking a button.
If you have applied bhl-revert, and want to have a toggled sidebar, use toggle-sidebar-base.
External Components/Themes usage policy
All page content (themes, components, images, HTML, attached files, text) must be hosted on Backrooms Wiki. Content cannot be crosslinked from other Wikidot sites, even the official sandbox site, as staff must be able to manage all content of the page. The only exception is for using a Cross-Site [[include]] for components from the Wikidot Snippets repository.
Unmodifiable Page Contents
These page components must always remain usable. You may not hide them as part of a format screw page.
The color and appearance of these components may be modified if in compliance with the CSS Policy.
- User module / login status
- Search functionality
- Page tags
- Article metadata (for instance, the Attribution Metadata)
- Rating module
- Side bar
- Top bar
- Wikiwalk navigation footer
- Page information and buttons (e.g. edit, rate, history, etc.)
- Wikidot advertisements (violation of the Terms of Service)
- Wikidot footer
- Wikidot license information
'More by' components
Authors are permitted to create a page for listing other works by them, which they may use on their articles as a way of directing readers to more of their work and/or providing recommended reading.
'More by' pages must exist within the more-by: category. The page's UNIX name (i.e. the part of the URL that is preceded by the category) must be identical to the creator's username as it appears in the URL of their Wikidot user info page.
If the author changes their username, they must update the URL of their 'more by' page, if they have one, and they must also update all pages that use it to point to the new page location.
URLs
New pages must be created in the appropriate category:
- Components and templates must be in the component: category.
- Themes must be in the theme: category.
- Fragment pages must be in the fragment: category.
- A "fragment" is any page that is created for a single, specific regular page for the presentation of its content, and are not intended to be viewed directly.
- Fragment pages are not subject to their own voting rating, but the voting rating of the page they are meant to be included within.
- 'More by' pages must be in the more-by: category.
- Art pages must be in the art: category.
All other pages must be in the main category (a.k.a. "_default:"). Use of other categories requires Tech Team approval on a case-by-case basis.
This means that your page URL may not contain colons (:), as the text before the colon will be interpreted by Wikidot as a non-default category.
General Naming Policies:
- Levels should be named according to the following naming system: level-NUMBER-DECIMAL.
- Entities, objects, and phenomena should be named in a similar fashion, albeit starting with entity, object and phenomenon respectively instead of level.
- Tales, POIs, and unnumbered levels and entities should be named according to their name, based on Wikidot's automatic name-to-url encoding system.
- GOIs should be named according to their full name without the definite article, unless if it is longer than X words then it should be named based on its acronym in the following syntax [TBD].
Redirects
Wikidot provides the Redirect module, which, when added to a page, causes any browsers visiting it to instead load the destination page. This can be disabled by appending /noredirect/true to the page's URL.
Users are never permitted to add a redirect to an article that is not theirs. Additionally staff approval is needed to create a page solely to act as a redirect. All pages containing redirects must bear the redirect tag.
Redirects may not point to pages off of the main wiki, including sandboxes or other Wikidot sites. Fragment pages may not contain redirects.
All other redirects need explicit staff approval.
Moving/Renaming
The following section refers to the Wikidot function called "Renaming", which allows users to change the url of a page they have posted. This is also sometimes colloquially known as "moving".
Be careful with renaming, as it can leave extant links elsewhere on the internet voided when a page moves. In many instances, these links cannot be edited or are not under the control of the original author, and those links will now either link to a nonexistent page or an entirely different one. This is simply a warning to be careful about renaming, not a prohibition against it entirely.
Deleting pages is technically considered renaming due to circumstances in the Wikidot backend. This is considered an auxiliary usage and is not covered in this policy.
Renaming Pages
Users are allowed to rename pages under their control as they see fit. They may put the article in any valid slot they choose. Be sure to follow the steps below when renaming a page:
- Go to the bottom of the page and check the backlinks, in the + Page Options. If there are any backlinks specific to the article, write them down. (You can ignore the mainlist and Wikiwalk footer.) Be sure to do this step before renaming the article. You may skip this step if you are not renaming a numbered page.
- Rename the page with the option named "Rename" in + Page Options. Do not instruct Wikidot to fix backlinks, if you are renaming a numbered page.
- If the article referred to its url, fix those references. Most level articles do this.
- If you are renaming a numbered page, edit any backlinks recorded in Step 1.
- If there are any files on the page that were called with their full urls (rather than simply the abbreviated file name), update those to the new url.
- In the case of a mainlist article, edit the respective mainlist so that the title of your article is at the correct location.
Co-Authored Pages
In the case of a co-authored page, you must consult with your coauthor(s) to make sure they are also willing to rename a page. You need to have over 50% majority vote from the coauthors.3 If you have full control over the article due to your coauthor's absence, you can proceed as normal.
If you did not post the article, and have permission from your coauthor to rename, but they are unable to do so for whatever reason, ask for staff to rename the article. A moderator will then complete the above steps for you.
Remediating non-compliant themes/components
If your theme doesn't function in the major browsers (Chromium, Firefox, Safari, mobile, IE11) in a way that completely breaks navigation, function, or accessibility, it needs to be removed (by disabling all CSS modules and commenting all div blocks) from the site, then fixed, in that order. Our first priority is compatibility, function, and accessibility.
Deletion policy for CSS themes
CSS themes are treated like normal pages in that other users are not permitted to make major changes to your work. Small mistakes (like missing semi-colons or typos in comments) are considered equivalent to spelling and grammar errors and may be corrected by any well-meaning user.
CSS themes and components are eligible for archival once they fall under the tech deletion range (which is -1 or fewer rate points), and are eligible for deletion if they are also used in 1 page maximum.