BetaWiki:Guidelines
We would like to ask you to follow these common practices for creating and extending BetaWiki content to prevent any possible conflicts.
Breaking or abusing the rules, depending on the severity, can result in either a verbal warning on your talk page or a temporary/permanent ban on administrators' discretion.
By editing on BetaWiki you acknowledge that you have read these rules and guidelines.
Common rules
Please note that these rules are not exhaustive, so do not assume that not forbidden automatically means allowed.
General
- Be civil to other users. Always assume good faith, unless you have a very good reason and/or evidence to do otherwise - don't bite the newcomers. Personal disputes should be kept off the wiki.
- Make meaningful edits. Do not make useless edits to replace words with their synonyms, remove the
File:
prefix from gallery images, or adding that a feature/bug persists until a future build.
- Use a single account to edit the wiki. Any sockpuppet accounts created without previous approval may get indefinitely blocked without due notice, including the main account.
- Try to avoid edit warring. If you find yourself involved in a content dispute, raise the issue on the respective talk page and mark the respective page or section with the Dispute template. As a rule of thumb, reverting pages more than three times in a short period for reasons other than reverting blatant vandalism is considered edit warring.
- Only use the move tool to move pages. Don't cut and paste page content unless totally necessary, as doing so removes the contribution history. Not having move rights is not an exception.
- BetaWiki is not a free webhost. Don't use your personal user pages to evade the notability rules or previous deletions. Any user space edits should also be outweighed by contributions to the rest of the site.
- Verify any fresh information. Adding newly uncovered information to the wiki is not a race. Make sure to take the time to properly understand the matter. If you are gathering information from a social network group, don't be afraid to ask follow-up questions.
- Be here to build an encyclopedia. If we have reason to believe that your intentions to edit BetaWiki are otherwise contradictory to its goal (which include but not limited to: a clear lack of interest in working collaboratively, harassment, sockpuppeting and disruptive editing), your editing privileges may be revoked.
Content
- Keep it real. Don't misuse BetaWiki for WNR, NROS or other fantasy stuff. This applies to all pages, including user and sandbox pages.
- Any unoriginal content should be properly accredited to the original source. Don't copy content from other sites without providing at least a source URL. Furthermore, when adapting material from our site for literary or visual works, please credit BetaWiki appropriately and link to the original source content, as required under the CC-BY-SA 4.0 license.
- Article subjects must meet the notability guidelines. Not everything is worth covering on BetaWiki.
- Put some effort into new articles. Articles that just consist of the formulaic "X is an Y of Z" and nothing else are not much better than no articles at all and are eligible for quick deletion.
- Make sure that you link to the articles you create! If you don't, the article will get lost and probably will lead to another one being made, for no reason. Unlinked pages can be found here: Orphaned pages
- Do not use generative AI to edit the wiki. Models such as ChatGPT often produce content that looks good at first glance, but may be factually incorrect as a result of hallucination.
- Ask for permission before reuploading photos posted by other people.
Legal
- Do not provide or request any links to download builds. This wiki is only a knowledge base for these builds, and we will not provide these builds.[a]
- Do not provide links or instructions on how to crack software, such as removing the built-in timebomb or bypassing activation mechanisms. The distribution of these cracks end up being usually illegal (and will almost always result in the breakage of critical system functionality if attempted), so do not attempt to add them on this wiki.
- Do not post product keys or other activation codes that can be used in a retail version of the software. While the software developer might not care, it is very easy to find the keys online.[b]
Talk pages
- Prefix new talk page threads with a section heading. It makes an unnecessary mess from the page without these. Your messages may not be visible for all users either.
- Sign your comments on talk pages. If you want to be anonymous, make a user account; the signature will bear your username instead.
- Don't edit or remove comments without the author's prior permission. You can change or remove your own comment before anybody replies to it, however, doing so afterwards removes valuable context and should be avoided.[c]
- Talk pages are not a forum or an instant messaging service. Try to keep the discussion about wiki content. There are numerous other services for general and personal discussion, such as Discord.
Frequently asked questions
- Can I change my username?
- If your account is at least 6 months old and you haven't already done so less than a year ago, you can ask to have your username changed on the Administrators' noticeboard. Please note that this can still be rejected in certain cases even if you formally meet the criteria.
- Why can't I upload pictures or create new articles?
- Only autoconfirmed users can upload pictures and create new articles. The autoconfirmed status is automatically given to all registered accounts that are at least 4 days old and made at least 10 edits.
- Is BetaWiki related to BetaArchive or BetaWorld?
- No, BetaWiki only happens to share the same focus as the other websites.
- How can I download the builds?
- We don't provide any downloads, however, versions that are marked as in a build list can be found and downloaded by some searching in most cases.
Available
Date formats
BetaWiki uses the day–month–year (DMY) "long" date format (e.g., 7 September 2024 or 7 Sep 2024) in articles. However, use of the ISO 8601 year-month-day (YMD) numeric date format (e.g.: 2024-09-07) is also acceptable where space is limited, such as tables or infoboxes, but not within the article text itself.
The following table further documents the preferred date formats:
General use | Condensed | Comments |
---|---|---|
20 November 1985 | 20 Nov 1985 | |
20 November | 20 Nov | Omit year only where there is no risk of ambiguity. |
— | 1985-11-20 | Use where space is limited, e.g. tables or infoboxes |
November 1985 | Nov 1985 |
Notability guidelines
There is a lot of software, and BetaWiki can't possibly cover every single version that somebody mentioned on the Internet. Therefore, we have a set of common notability guidelines to see if a subject is worth covering. They are not absolute, and we can make exemptions on a case-by-case basis for historically important subjects.
Please note that just because a subject meets the notability guidelines does not mean that it must necessarily be covered on a separate page. Quality is preferred over quantity, and so it is more desirable to have a single good page than a stub main page with stub version and build pages.
Applications and operating systems
An application or an operating system is presumed suitable for a stand-alone article when the product has received significant coverage in multiple reliable sources that are independent of the product vendor.
Components of a standalone product as well as modifications of existing software are considered to be separate products, which also have to individually pass the notability criterion.
Software builds
Covering prototype builds and therefore researching the evolution of popular software is BetaWiki's main mission. A build is notable if all following points apply:
- The product itself is notable
- The build has been mentioned by a reliable source
- The build contains changes other than bug fixes
- The author of the source material is not considered unlikely to possess said version
The following sources are considered reliable:
- The build media itself
- A screenshot or video of the build, under the condition that it can be traced back to the original upload
- An article about the build itself, or about its features, bugs, etc.
- Internal documents mentioning the build
The following sources are also acceptable, if the build has been mentioned in two or more:[d]
- Warez CD list
- Newsgroup discussions, comments, bug reports
- Screenshots of download pages
- File versions
A build is considered confirmed if the source provided for the build was involved with the development of the product, and thus there are no doubts about its legitimacy/existence.
We also cover fake builds in a limited fashion. A fake build is deemed notable if, in addition to the aforementioned criteria, the build bears the potential to confuse individuals over its legitimacy.
Games
Only games and their prototype builds that come pre-installed in operating systems documented on BetaWiki are deemed notable enough for having a stand-alone article. Any third-party games that do not come pre-installed in any operating system are not suitable towards BetaWiki's scope.
Tools
Aside from covering the actual software and its prototype versions, we also focus on tools that make using old betas easier, such as emulators, or unlockers of hidden functionality. These tools should of course be demonstrably used by the community in order to be considered notable.
Deletion policy
Style guide
All articles should start with a lead section, which introduces the subject and sums up the main points of the article. The section often begins with a simple description of the subject in a single sentence, i.e.:
Windows 8 build 8250 is the official Consumer Preview build of Windows 8, which was officially released to the public on 29 February 2012.
The article title is usually set in bold in such sentence. However, if such a description would only rephrase the article title or feel unnatural, it should be left out. The section can span several paragraphs and ends with the first section heading, at which point the wiki software inserts the table of contents.
Most content should be written in prose. Bullet points should not be used to introduce paragraphs -- the list syntax should be used only for actual lists, which should be as brief and concise as possible. The reader must not be addressed directly in 2nd person in original content (and then restart your computer) -- always use 3rd person and passive voice unless directly quoting a statement or message.
Prefer quality over quantity — more is not necessarily better than less. Avoid adding multiple similar images to a gallery unless the difference is important enough to include them. Similarly, multiple references to the same subject inside a single article should not necessarily all be links to the relevant article.
Screenshots
In brief, all original screenshots should be:
- Cut to the exact size of the subject (desktop or application window)
- Not scaled or distorted in any way
- Saved in a lossless format such as PNG
- Taken under a period-appropriate resolution and color depth
- Depicts a clean, original install of the product
- Using default settings, unless the intention is to show the effect of a setting
- Void of any custom graphics not included as part of the product itself
If possible, use the Windows screenshot feature (Print Screen key, Snipping Tool) to take pictures of the desktop, or use the screenshot feature if using a hypervisor/emulator. If a cursor is present in a full-screen shot, it should be isolated within a corner of the background when and wherever possible (to show off its unique features).
Examples
Good shots
Bad shots
Article screenshots
Each main article usually requires three components: the Desktop, the About window, and (sometimes) the logon screen. In most cases, a build article only needs the first two. Full-screen shots (such as for the Desktop and the start menu) should be taken at 1024×768 graphical mode in a 16-bit color depth at minimum, unless the subject in question does not support such a video mode - for instance, 1024×768 pixels with a 256-color depth is generally acceptable for Windows 3.1 and early Windows 95 builds.
Screenshots must not use themes, wallpapers, or other graphics that are not present in the contents of the intended subject, even if they are "Demo" screenshots. Most screenshots should be taken with the default settings, unless the purpose of the screenshot is to demonstrate the effect of a setting. Screenshots should show the clean state after installation, without any extra installed software, unless they show a feature of the particular subject that cannot be demonstrated otherwise. Any personalization options can be reasonably demonstrated in a demo screenshot in the Gallery. It is recommended to use a separate machine (virtualized or not) with a clean copy of the operating system or application for the purpose of taking screenshots.
Desktop shots should be void of any extra windows. It should represent the state of the system when it is completely idle without any running programs. In the event that the OS displays a tool or special graphic (such as a welcome screen) immediately after initial setup, the screenshot is therefore distinguished as a "first boot" shot, and is separate from the desktop shot.
Each article can also contain a Gallery, where other associated shots are contained. Additional full screen shots belong here, such as the "demo" (which shows off particularly unique features of a build). The remaining shots are usually those of programs unique to a build. Those shots should be cropped to the size of the program's window (including transparency and window shadows if such effects are present). Child windows (if any) should be visible in their full area. Article screenshots should be free of any watermarks or annotations made through an image editor (such as Paint).[e]
For taking screenshots of windows composited by the Desktop Window Manager (which produces the translucency and drop shadow effects observed in Windows Vista and later OS releases), it is recommended to use an application that is able to produce screenshots that preserve the aforementioned features. We generally recommend using AeroShotCRE, which offers a diverse set of customizable options that may be used to further enhance the overall quality of screenshots.[f] This process can also be done manually by taking two screenshots against a white and a black background and using an image editor to mask the translucent parts off.
Setup screenshots
Boot screenshots
Desktop screenshots
About screenshots
Miscellaneous
Terminology
leak
Only use the verb "leak" when referring to the act of the build being released outside of its intended userbase for the first time or in general. Avoid use of the word for referring to uploads to specific sites if unauthorized individuals had access to the build long before the subject was made publicly available. Other alternatives, such as share, upload, or available may be preferable depending on the context of the subject in question, i.e.:
- "User X shared this build",
- "The build was uploaded to Site Y",
- "It is the earliest available build [...]"
Naming scheme
Windows
Windows <version> build <buildnumber> (lab)
The specification above is the most verbose one and isn't going to be used a lot. In most cases BetaWiki covers only one build with a particular build number, in that case the lab (if any) should be omitted from the page name. Use the name that's reported by the RTM build in the version field, i.e. NT 4.0
, XP
, 10
. If the full build tag contains a lab name, make sure to create a redirect from the most verbose form above to the reduced form of the page name (without lab), i.e. Windows XP build 2428 (idx01)
⇒Windows XP build 2428
.
In case there are several known builds with the same build number but from different labs, names of the pages should contain the lab name. To maintain a degree of consistency, the reduced name without a lab should be used for a disambiguation between the individual builds. If there are several known builds with the same build number that come from the same lab (i.e. are distinguished by the build date and time only), add the full timestamp to the lab component, i.e. Windows Longhorn build 4050 (private/lab06_demo.031019-1809)
.
For Windows versions that only use a major and a minor version number, make use of them in the version field and omit the build number entirely, i.e. Windows 1.04
.
Don't mention the full update name for builds of Windows 10 updates, just use a plain numeral 10, i.e.: Windows 10 build 16179
. On the other side, it's encouraged to make separate build listings for the individual updates, whose names should contain the official name of the update, i.e.: Windows 10 Creators Update
. The YYMM update version should redirect to the full name, for example Windows 10 v1703
would redirect to the Creators Update mentioned before.
Redirects
To make searching for build pages easier, BetaWiki maintains several redirects aside from the ones mentioned above:
- If a build has an official name, it should be redirected to the main page, i.e.
Windows 8.1 Preview
⇒Windows 8.1 build 9431
. - If there are several builds that utilize an official naming scheme, redirect it to the main version page, i.e.
Windows 10 Insider Preview
⇒Windows 10
macOS
Classic
Mac OS <version> build <build>
Mac OS X
version
is meant to be the name of the particular release, i.e. Jaguar or Yosemite.
Mac OS X <version> build <build>
OS X <version> build <build>
macOS <version> build <build>
OS/2
1.x
IBM OS/2 <version> build <build>
Microsoft OS/2 <version> build <build>
2.0 and later
OS/2 <version> build <build>
Templates
Infobox Windows build
See Template:Infobox Windows build
Infobox macOS build
See Template:Infobox macOS build
Rivals
{{Rivals|TCB=<tcb-link>|TCBGallery=<tcbgallery-link>|BAWiki=<bawiki-link>}}
Use when the build you're posting also has an article on the BetaArchive wiki or a build/gallery page on The Collection Book.
BLItem
When creating buildlists, use the provided BLItem templates:
{{BLItem Leaked|<article-title>|<buildtag>}}
- use when the build was publicly leaked/uploaded online or released{{BLItem Confirmed|<article-title>|<buildtag>}}
- use when information surrounding the build is available, further proven by a credible source such as the developer{{BLItem Unconfirmed|<article-title>|<buildtag>}}
- use when information is available, however no provided proof for it and/or sources are questionable{{BLItem Fake|<article-title>|<buildtag>}}
- use when the build in question was proven to be fake; do not use if build is real and fake screenshots are also available
When sorting buildlists, the first thing that matters is the build number. If there are several different builds with the same number, always sort them by compilation date and time. If multiple builds share the same compilation date and time, sort them like this:
- main branch (e.g.
main
,winmain
,rsmain
,rsmaster
) - release branch (e.g.
beta1
,xpclient
,winmain_win8m3
,rs2_release
, etc.) - dogfood/partner branch recompiles (e.g.
idx
,fbl_partner
,vbl_media_ehome
, etc.) - other branches sorted alphabetically
Notes
- ↑ Such a link can, however, be used as a reference to back an article claim.
- ↑ Disc scans with printed/written product keys generated using the flawed modulo-7 algorithm used by Windows 95, Windows NT 4.0, et cetera. are exempt from this rule.
- ↑ You can also freely remove anyone's comments from your user talk page, although removing warnings is considered as evidence that you read and acknowledged them.
- ↑ Meaning, for instance, a warez CD list and a newsgroup discussion, but not two file versions.
- ↑ The only exemption to this rule is if the respective build is not publicly available, and the only available screenshots are either watermarked, annotated, or are of low quality. Images depicting the build before it was made publicly available may be kept in the interest of the general public, with a label marking it as such.
- ↑ You may be required to install the .NET Framework 3.x feature-on-demand packages via the Optional Features Control Panel applet or via the Deployment Image and Servicing Management Tool (DISM) if you attempt to run AeroShot on a newer Windows version, such as on Windows 8.x or Windows 11.