User:Rhinozz/Sandbox

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 administators' discretion. Your article might end up in the Hall of Shame if you don't follow the guidelines.

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.

• 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.

• Article subjects must meet the notability guidelines. Not everything is worth covering on BetaWiki.

• Put some effort into new articles. Try to write at least a single paragraph about the subject when you create a new page. 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

• 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.

• Keep it real. Don't misuse BetaWiki for WNR, NROS or other fantasy stuff. This applies to all pages.

• BetaWiki is not a free webhost. Don't use your personal user pages to evade the notability rules. Any user space edits should also be outweighed by contributions to the rest of the site.

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.

• Do not provide links or instructions on how to crack software such as removing timebomb or bypassing activation. The distribution of these cracks end up being usually illegal, 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.

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 -- doing so afterwards will remove valuable context and should be avoided. 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 it.

• 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 BetaWiki:Administrators' noticeboard. Please note that the appropriate rules still apply if you "change" your username by creating a new account!

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

Available

in a build list can be found and downloaded by some searching in most cases.

Date formats

BetaWiki uses the day–month–year (DMY) "long" date format (e.g., 25 April 2024 or 25 Apr 2024) in articles. However, use of the ISO 8601 year-month-day (YMD) numeric date format (e.g. 2024-04-25) 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:

Acceptable 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.

Applications and operating systems

For main articles not covering a single build (such as Windows 10 or Linux), a topic is suitable when it has received significant coverage in reliable sources that are independent of the original subject.

• Significant coverage addresses the topic directly and in detail, so that no original research is needed to extract the content. Significant coverage is more than a trivial mention, but it does not need to be the main topic of the source material.

• Reliable means that sources need editorial integrity to allow verifiable evaluation of notability, encompassing published works in all forms of media, and in any language. (Availability of secondary and tertiary sources covering the subject is a good test for notability, but depending on how niche the topic is, other tests may be used.)

• Sources can be primary, secondary, or tertiary, as this wide range of sources is required to cover all notable topics, however niche. There is no fixed number of sources required since sources vary in quality and depth of coverage, but multiple sources (generally 3 or more) are usually expected. Lack of multiple sources suggests that the topic may be more suitable for inclusion in an article on a broader topic.

• Independent of the subject excludes sources that are specifically made for that topic's audience. For example, if a Linux distro is only covered in blog posts made by the creators and articles in Linux magazines, that does not count as significant coverage.

Components of a standalone product as well as software mods are considered to be separate products, which also have to individually pass the notability criterion.

Software builds

For articles covering one specific build (such as Windows 10 build 19042.1023), a build is suitable when it has a parent article and has been mentioned by a proper source in which the author is not considered unlikely to be in possession of said version.

• A parent article is the overarching topic that links to an article. For example, Windows 8 build 9200's parent is Windows 8. An article may not be an orphan (a page not linked to by any other pages).

• The following sources are considered proper:

• The build media itself

• A screenshot or video of the build, given that it can be traced back to the original upload

• A reputable article mentioning the build

• Internal documents, which have since then been made public

The following sources are also considered proper if the build has been mentioned more than once:

• Warez CD list

• Newsgroup discussions, comments, bug reports

• Screenshots of download pages

• File versions

Note that other sources may be considered proper if their authors are not considered unlikely to be in possession of said version. For example, a bug report or GitHub issue by a Microsoft employee can be used as evidence of a Windows build.

We also cover fake builds in a limited fashion. A fake build is notable if in addition to the aforementioned criteria the build has the potential to confuse people about its legitimacy. (See the BLItem section for how to classify non-fake builds.)

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

See BetaWiki: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. 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 shouldn't 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 shouldn't 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 pictures to a gallery unless the difference is important enough to include them. Similarly, multiple references to the same subject inside a single article shouldn't necessarily all be links to the relevant article.

Screenshots

^{Thanks to Foxlet for originally writing this!}
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 at a period appropriate resolution and color depth
• Featuring 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 with 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. For "Full Screen" shots, if a cursor is present, it should be isolated in a corner of the background if possible (to show unique features of the cursor).

• 

  ✔️ Good shot:
  Clean area at true scale

• 

  ✔️ Good shot:
  1024x768 in True Color

• 

  ✔️ Good shot:
  Pixels are 1:1, even at lower resolution

• 

  ✔️ Good shot:
  True scale and with transparency/shadow effects

• 

  ✔️ Good shot:
  Additional graphics are seen as the intended subject is the hypervisor, and the window is properly cropped

• 

  ❌ Bad shot:
  Not at true size, low quality, graphics outside the real desktop are visible

• Windows NT 5.0 Build 1888 Logon Screen.jpg

  ❌ Bad shot:
  Pixels are stretched, a scaling filter had been applied

• FAKE photo of Windows Longhorn Build 5001.jpg

  ❌ Bad shot:
  Image is smaller than true scale

• 

  ❌ Bad shot:
  Image was annotated with an image editor

• 

  ❌ Bad shot:
  Inadequate resolution and color depth

• 

  ❌ Bad shot:
  Image contains graphics that is not included in the operating system

• 

  ❌ Bad shot:
  Image has additional graphics and is not properly cropped, although it meets all other criteria

Article screenshots

The desktop shouldn't be visible in application screenshots.

Each main article usually requires three components: the Desktop, the About window, and (sometimes) the Logo. In most cases, a build article only needs the first two. "Full Screen" shots (such as for the Desktop and Start Menu) should be 1024x768 in 16-bit color at minimum, unless the subject in question does not support such a video mode (for example, 1024x768 in 256 colors is fine for Windows 3.1 and early Windows 95 builds).

Screenshots must not use themes, wallpapers, or other graphics that are not included with the particular 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 (virtual 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 case that the OS shows a tool or special graphic (such as a welcome screen), that is known 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).

For taking screenshots of windows using translucency and/or drop shadows reaching beyond the main window area, it is recommended to use an app that is able to create screenshots that preserve the mentioned features and produce an image file using alpha transparency. This 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 Shot

• 

  Boot Shot

• 

  Shutdown Shot

• 

  Logon Shot

• 

  First Boot Shot

• 

  Desktop Shot

• 

  Desktop Shot

• 

  Start Menu Shot

• 

  Demo Shot

• 

  Full Screen Program Shot

• 

  Program Shot

• 

  About Shot

• 

  About Shot

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 the use of the word for referring to uploads to specific sites if unauthorized people had access to the build way before it was uploaded. Other alternatives, such as share, upload, or available may be better, depending on the context, 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 just used a major and a minor version number, use them in the version field and omit the buildnumber completely, 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 a couple more redirects aside from the ones mentioned above:

1. If the build has got an official name, we should redirect it to the main page, i.e. Windows 8.1 Preview⇒Windows 8.1 build 9431.
2. If there are more official builds with the same official name, 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 or released
• {{BLItem Confirmed|<article-title>|<buildtag>}} - use when there is information available, which has been further proven by the developer
• {{BLItem Unconfirmed|<article-title>|<buildtag>}} - use when there is information available, however no provided proof for it
• {{BLItem Fake|<article-title>|<buildtag>}} - use when this build is fake, don't use if both 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 like this:

1. main branch (e.g. main, winmain, rsmain, rsmaster)
2. release branch (e.g. beta1, xpclient, winmain_win8m3, etc.)
3. dogfood/partner branch recompiles (e.g. idx, fbl_partner_out, etc.)
4. other branches sorted alphabetically