While some builds that are mentioned on GitHub come from more than one repository and fall under the acceptable notability guidelines. I believe that the majority are not notable as they just say "Hey, this build exists!", only consist of a build number and don't mention any notable bugs or features. Not to mention that I feel that these build pages clog up their respective OS version pages.
Given that most Win10/Win11 updates have recently been removed, I feel like these references should follow suit. Especially since right now, Copper is around 45% GitHub references.
I think there are three potential ways forward:
Delete and disallow most build references that come from GitHub (This would be extremely unfair)
Move the references to a separate page and potentially format them into a table as seen on my sandbox. Table Sandbox (The table is just a personal preference)
Keep things as is
These are just some thoughts I've had over the last few days. Xeno (talk) 21:14, 7 April 2022 (UTC)
I think the second option you suggested is the most appropriate solution. It serves to mention that we know these builds exists without having a page for each of them. (I also think this idea can be extended to other "unnotable builds" as well, just a list to reference their existence). • Kiki79250CoC(Talk • Contribs • My Toaster™ specs) 06:15, 8 April 2022 (UTC)
I want these to tell others about me and for testing BetaWiki features and my editing skills with condition that nobody will ever touch the page.
--GoldieAxolotel1320 (Talk) 14:40 Apr 10 2022 GMT+01:00 Warsaw
Deprecate The Use of The Term "Development Semester"[edit source]
I don't think Nickel and Copper should be called the 22H1 and 22H2 development semesters, respectively, given that Microsoft has most likely switched to a yearly-based development cycle rather than semester-based with recent internal mentions of Windows 11's 23H2 release being Copper. Some may argue that the development semester is not related to the version number, but it would be very awkward as we get further and further into the future when development semester and the version number diverge (for example, Gallium would be either 23H2 or 25H2). Therefore, I think we should stop using the term "development semester" after Nickel. Charka123 (talk) 00:25, 11 April 2022 (UTC)
I honestly agree 100%. Imagine the mess in the near future once we reach 2024 or 2025! Cliria (talk)
Well, they are called development semesters for a reason... The 22H2 development semester is for the 2023 release, aka 23H2. Same also applies for 22H1, being called 22H2 instead of 22H1. --Icanttellyou (talk) 09:05, 13 April 2022 (UTC)
We can't do much until Microsoft confirms that themselves. It's likely we'll just keep it the same until we have enough proof whether Microsoft did switch to development cycles from development semesters. Jurta (talk • contribs) 16:25, 13 April 2022 (UTC)
This is an archive of a previous community portal discussion. Do not edit it.
To reduce clutter throughout each Windows version's build pages (from VB onwards), I'm holding a vote here to see if anyone's fine with getting rid of the unnecessary update pages for the above mentioned Windows versions, as they do not have any notable changes. The only pages that will be kept (as they feature significant UI changes) are the following:
I agree, many of the post-GA builds of Vibranium and Cobalt are nothing more but security updates and quality updates that fix bugs and security issues and they clog up the build lists for those pages. It only makes since to cover post-GA builds that have actual notable changes like the ones listed above. WindowsGuy2021, 3:59, 12 May 2022
I'm pretty sure I have proposed long time ago that any Update RTM builds wouldn't be allowed here (aside from service pack betas and build 6003). Many if not all of these pages deserve to go, otherwise it'd be cluttered with over thousands of pages of Update RTM builds. BF10 (talk) 01:15, 13 May 2022 (UTC)
Purging of cumulative updates of betas (Only for Manganese and up)[edit source]
I think we should purge all of the cumulative updates of betas in post-20H1 Dev Channel as they do not contain any useful content as well as notable changes.
I meant all builds with these labs without notable changes:
This proposal excludes all builds from 22000.51 to 22000.184.
— Preceding unsigned comment added by 18.104.22.168 (talk • contribs)
To make things clear, this proposal just includes all updated builds that do not have notable stuff. Of course, we need base builds like 22000.1 or 22621.1. Also I'm going to make the limit of proposal even smaller. It won't include updated builds if they're shared unofficially/illegally. Like 22000.9. Also unleaked updated builds won't be included. I don't think I can make this limit even smaller. — Preceding unsigned comment added by 22.214.171.124 (talk • contribs)
That's completely false. These builds are late Insider builds. Late Inider builds, GA Escrow and later (?(development semester)_release)always have the minor build number .1 (.0 for early Windows 10 feature updates) if no update is installed. If an update is installed, the minor build number will jump, but the major one will left intact (excludes 22622 because it is basically a fork of 22621 cumulative updates with new feature rolling out). For early Insider builds (rs_prerelease), the minor version number usually fall between 1000-1002. Same as above, if an update is installed, the minor one will jump (1000 -> 1010, 1001 -> 1011 and 1002 -> 1012, I think) and the major one will remain unchanged. For late Insiders builds on GitHub (minor = 1000/1001), I think they come from a special, internal branch. Someone (talk) 03:20, 12 August 2022 (UTC)
These can be excluded from this proposal. But rest of them doesn't seem that useful. — Preceding unsigned comment added by 126.96.36.199 (talk • contribs)
I'll take 22621.160 as example. It introduced tabs and revamped navigation pane, But, its earlier CU, 22621.(2-4), and it's later CU, 22621.105, does nothing. Someone, 10:01, 28 June 2022
Then, 22621.160 is fine. But shouldn't 22621.(2-4) or at least 22621.105 be purged since there aren't any notable changes or features? — Preceding unsigned comment added by 188.8.131.52 (talk • contribs)
This is an archive of a previous community portal discussion. Do not edit it.
Restored as requested. - pivotman319 (📫) 14:04, 13 June 2022 (UTC)
I don't understand why the page for build 22000.346 was removed as a part of getting rid of post-GA update pages. It actually had some notable changes, including the redesigned fluent emojis and changes to the BSOD color. Some of the pages that had fewer changes were actually kept, such as 22000.282 (which only contained minor tweaks and adjustments) and 22000.526 (only added Microsoft Account page in Settings). Considering that these two post-GA updates were kept, I think 22000.346 should stay too. Charka123 (talk) 20:24, 17 May 2022 (UTC)
Yeah, at least unleaked post-GA updates should stay. — Preceding unsigned comment added by 184.108.40.206 (talk • contribs)
Well, I forget to discuss this first before... May we can change the older vivetool addconfig [velocity_id] code (from version until 0.2) with /enable /id:[velocity_id] code (from version 0.3+)?
I need to know, if we can keep it for compability reason or change it to better experience. 😸 Hi. I'm NekoSam395. (💬 | 👨💻) 15:16, 28 June 2022 (UTC)
I've also mentioned this on the Discord. Xeno (talk) 15:18, 28 June 2022 (UTC)
I'm sorry but I currently not using Discord a while, until a few weeks. All the decision is under the admins for now. :) 😸 Hi. I'm NekoSam395. (💬 | 👨💻) 15:30, 28 June 2022 (UTC)
I would just mention the feature IDs itself and leave out the ViVeTool specific bits. --Ryuzaki(talk | contribs) 11:57, 29 June 2022 (UTC)
Merge Service Pipeline updates with their respective build pages.[edit source]
Windows Insider Service Pipeline updates aren't notable enough to create a new page every time one is released. It'd be better if there was a note on the build's page and would reduce the need to upload a winver image for every pipeline. An example would be build 25151 merged with build 25151.1000Xeno (talk) 18:18, 1 July 2022 (UTC)
Agreed to this on Discord already. Most of these are irrelevant and the "changes" they contain only stem from feature configurations for different branches. --Ryuzaki(talk | contribs) 13:39, 2 July 2022 (UTC)
Other minor pre-release build updates don't have their own pages (except special cases like 8102 which was preinstalled), so these also shouldn't. 220.127.116.11 13:46, 2 July 2022 (UTC)
OS: iOS 10.3.4 (14G61)
System: iPad 4
Bug: Can`t edit without vandlilsm abuse (Block), when i answer the question it says "Wrong code, try again." without wrong answers. i tried to use Google Chrome app (version 71.0.3578.89), Microsoft Edge (version 46.3.30), it also didnt work. 2001:F90:40C0:A072:958A:2177:A4A8:83B9 02:10, 5 July 2022 (UTC)
It is not recommended to share your iPad's serial number with everyone. Remember, your iPad's serial number is your own and private info. Nara Insider (talk) 04:35, 5 July 2022 (UTC)
I thought BetaWiki is not available aa a mobile app. Anyway, try to edit with the desktop version of this page. - 18.104.22.168 07:45, 5 July 2022 (UTC)
That IP thought BetaWiki has a mobile app that can be used to read and edit pages, even though the IP is just visiting the mobile version of the site. BetaWiki does not have a mobile app! Nara Insider (talk) 08:20, 5 July 2022 (UTC)
This sentence (That IP thought BetaWiki has a mobile app that can be used to read and edit pages) was false. I didnt use a mobile app to edit pages. 2001:F90:40C0:A072:958A:2177:A4A8:83B9 01:16, 6 July 2022 (UTC)
That sentence was true. I know you didn't use a mobile app, but it seems that you didn't read the sentence correctly. I said "BetaWiki has a mobile app" in the sentence, not "That IP is using a mobile app". Also, hiding your iPad's serial number from the reading view just doesn't make sense, because the serial number is still visible when editing the source of this page. Nara Insider (talk) 03:16, 6 July 2022 (UTC)
You're probably being ratelimited by the wiki. That's intended behavior. --Ryuzaki(talk | contribs) 09:45, 6 July 2022 (UTC)
OS: iOS 10.3.4 (14G61)
System: iPad 4
Bug: "Sorry for the mess!" After JaGoTu upgraded MediaWiki version to 1.3.7, on the mobile web the Contributions page was broken. After this version released, this error is still on the mobile version of BetaWiki (Safari). I reported that before, it still have no message.2001:F90:40C0:A072:958A:2177:A4A8:83B9 03:39, 15 July 2022 (UTC)
Try using a different browser (if it is supporting iOS 10) or a different machine with a more up-to-date browser. - 22.214.171.124 11:47, 23 July 2022 (UTC)
I tried try Google 71.0 it also did not work. 126.96.36.199 09:43, 30 July 2022 (UTC)
All stuff (except of that Sandbox header) in global BetaWiki Sandbox must be removed once page refreshed. Agree? Axolotel1320 (talk) 08:02, 20 July 2022 (UTC)
Move Insider service pipeline updates to their respective build pages.[edit source]
With the high amount of service pipeline updates in the Insider Program, I feel like it would be better to mention these updates on the update's respective OS page rather than have a separate page due to how non-notable the pipeline updates tend to be. Xeno (talk) 17:05, 22 July 2022 (UTC)