Windows Insider missteps again.

So, apparently, we aren't likely to see any new builds until after the devices event on October 6th and that has me kind of peeved and is really making me feel like the focus of the Insider program has changed again and we're more or less back to the pre-Windows 10 Microsoft.

It isn't the build cadence, that is another problem entirely. It is that this is an artificial, likely PR related, reason for holding back builds.

I wasn't expecting mobile builds at any incredible pace after the launch of Windows 10. I expected that the bulk of the team would be heads down on that. After all, they already have 100M users there and they are likely finding all new bugs and issues for the team. On the flip side, they have far fewer mobile users AND based on what I'm hearing the first mobile devices will be shipping with 10240 based build which is a few months old now. So they aren't nearly as pressured on the mobile front as they are on the PC front.

There are a couple of reasons to hold back builds for an event. The biggest I can think of are:

• The build might contain features or functionality that they want to talk about during the event. 
• The build might contain information that might leak hardware info ahead of time (support for something new for instance).
• To build up excitement around the event by having more news to deliver all at once.

The first is the most legitimate, and I *hope* that is the case, but really, based on Mr. Aul's tweets it doesn't seem to be the case. Also, that is part of what the Insider program (claims) to be about; Testing and getting feedback on new features so that they can deliver what people want and reduce the number of bugs in the product that rolls out to the more broad audience. Both of those are time sensitive goals though and shouldn't be sacrificed (if they are serious about this program).

The second point is unlikely. Firstly, it rarely happens (not a ton of innovation in the field) and secondly it is unlikely that is would be obvious as hardware dependent functionality tends to be "invisible" without supported hardware. They could just withhold the SDK to keep any new APIs hidden and people digging through assemblies often find references that either never materialize or are still a long ways down the road. People tend to take those with a grain of salt. Also, the 6th is only 4 days away and a lot has leaked already like with the Google and Apple events before it.

And the last point would be the worst. Given the pace of builds it seems unlikely that Insiders would get any better of a build than they would have gotten if they had pulled the trigger sooner. They are likely sitting on a viable release right now. I don't doubt they are still evaluating other builds and the possibility exists that a newer one will replace the hypothetical build.

Which brings me full circle to the build cadence. The problems are several fold. Firstly there is not even a rough frequency to expect new builds on in either ring which makes evaluating which ring you should be in nearly impossible. Secondly, with the stability/quality/performance of the current builds at present the slow ring is senseless. And lastly, I find the whole process ill-defined.  

I would say kill the slow ring until after GA, and then position it as a group that receives the final or near final product for one last round of testing potentially only weeks or days ahead of a formal release. The expectation for slow ring users would that they should be getting only builds that the team thinks are ready for general consumption, they are stable and feature complete. Feedback will still be taken from these users, but aside from bugs they won't be addressed until a future build.

Fast ring I would expect to remain more or less as is presently stated, but actually deliver on that. There should also be some limiting factors. For instance, a minimum 1 week gap between new builds unless there is a critical issue. Remember, this ring is still accessible simply via tapping through a few prompts, so delivering daily builds is just as bad as delivering botched builds for many in this group. The expectation for fast ring users should be a new build (conditions permitting) every 2-4 weeks. Users should expect incomplete experiences, bugs, new features and feature changes. The only requirements a build should have are that phone calls work, texting works, internet connectivity works and upgrading and restoring both work and these minimum expectations should be presented to users who opt-in. Those ensure that a fast ring user can still use their phone for critical communication and of course that they are able to upgrade to the next build or revert back if they hit serious issues or want out.

Lastly, as I stated in the past, there really needs to be a 3rd ring with some meaningful barrier to entry. Especially if they don't "fix" the fast ring. As a barrier to entry I would say that the user should have provided at least 10 pieces of feedback including comments or bug mentions from another ring and a requirement that the user has proven that they know how to restore their device; IE, perform an upgrade to one of the fast or slow ring builds, then run the restore tool, and when restore successfully reverts the OS, the device id and a Microsoft account are stored in their servers to prove both that you know how to restore and that it works on your phone. Not only that, the process would take hours from start to finish which would weed out a lot of people who shouldn't be there. 

Then, I would say that this ring gets builds whenever the team wants to send something out for more feedback and the ONLY thing they need to test for on their end is that the device can be restored. People in this ring would have no guarantee that their phones would even be usable. 

While I'm at it, I'd also like to see the restore tool able to restore to currently active Insider builds. So, if the fast ring breaks my phone, I'd like to be able to restore to last slow ring build and be defaulted into the slow ring so that I can take a pass on the broken fast ring build rather than doing a restore and then re-enrolling into the slow ring.