Adding to, but not Perverting the Beta Process

re: Adding to, but not Perverting the Beta Process

Michael Giagnocavo — Sat, 08 Jan 2005 00:07:00 GMT

I'm not quite sure what this means:

"The early alpha/beta/CTP program information and preview information needs to be isolated better in the future. Not made private again, but more obviously separated."

Isolated as in, still 100% publically available, just not blasted out to everyone? If so, right on! Rick's not the first person to complain about all the "vNext" content out there (mainly regarding Longhorn).

I think part of the "problem" are that a lot of people are now reading blogs, and of course, people are gonna talk about new products (or about what they're currently working on).

Just so long there's not much "mainstream" publication of *really* early features, I think it's fine. I think the people who can give the best feedback early on are also the people who can cut thru a bit of _insulation_ to get to the CTPs.

re: Adding to, but not Perverting the Beta Process

Josh Ledgard — Sat, 08 Jan 2005 00:21:00 GMT

You translated my intentions correctly. Yes. There is a need to improve our communication about alpa/ctp/beta releases. It needs to be more seperated from existing communications but also richers in context so that it is easier for customer who do want to be involved to understand what they are getting into.

re: Adding to, but not Perverting the Beta Process

Norman Diamond — Sat, 08 Jan 2005 03:54:00 GMT

CTP is fine. Calling a CTP a beta when it is really still a CTP does cause confusion.

You say that in the past you called things betas when you thought they were ready, but in the past some versions of Windows were called betas when they should have been called CTPs.

When a product really does reach beta and you think it's ready, but customers find problems you didn't find, the facts are the exact opposite of "can't do anything about it", the facts are "better do something about it". (Except of course for monopolies who don't have to do anything about it.)

Sure if you want to release a version on schedule even after latent bugs become known bugs due to feedback, you can still release it, just call it a beta instead of calling it 1.0. If you spend the next year developing a service pack to fix a beta instead of a service pack to fix 1.0, fine. (When your company charges upgrade fees for things that are really bugfix packs, of course your victims scream bloody murder, and only monopolies can get away with it.)

re: Adding to, but not Perverting the Beta Process

Joku — Sun, 09 Jan 2005 21:33:00 GMT

I think you are on the right tracks here. What comes to the "insulation" proposed, my suggestion would be some sort of extension to blog categories perhaps. When you are making a new blog post, you would choose that this is about a future product (category) and then the post would be go to similar place as blogs.msdn.com, but on the appropriate product center. Essentially gathering the talks and information about upcoming product in the vs2005 center for example. There could also be additional blogs.msdn.com feed that would include all the future product "hype", for those who want it.. However I would believe everyone would move to using this feed then.

re: Adding to, but not Perverting the Beta Process

Chris Szurgot — Sun, 09 Jan 2005 21:48:00 GMT

I think my problem with the current process, especially with how external the whole process has become, is that there are too many public builds available and too many public builds that you can report bugs on (There are what look like 7 Visual Studios you can report on, not including the Express Versions). And I think that encourages the testers to sign off with "Fixed in a Later Build" when the issue may be "Can't Replicate"

For example, I've recently started working with the Nov CTP. (I tried Dec CTP, but it was pointed out that it was an older Framework, and I wanted newer framework, even if it meant some older tools, or not the Architect VS) Since then, I've reported four bugs, two of which have been closed as "does not reproduce" or "You will see this behavior in a later build." One of them was a pretty serious bug that I'm suprised made it into the Dec CTP, was already better into the Nov CTP, so I'm almost not suprised if it's fixed (http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=8c6eab30-28f1-4996-8376-18978c436e4d), but the other one is almost esoteric. It's a Windows Forms issue that only effects Multi-monitor setup, and Form Startup (http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=ade38c35-50e1-45b0-858e-e539cd23624e) It's been there since Beta 1 of 1.0 (Dec of 2000, which I should've reported it), and I find it hard almost hard to beleive that it's been fixed in the last two months (although it would be nice) as opposed to not happening on on certain setups.

I guess that part of the more open process should be a better statement on position. Should Microsoft accept bugs on every "beta" version they've released, or close off some of the older ones and only accept bugs on newer ones since there always is a chance an issue has been fixed. Also, when a bug can't be replicated on the "latest" internal build, it would be nice to know that it had been replicated on the older build under the same circumstances (or that there was an actual internal bug fixed.) I'd like to be a part of the beta process, but it's difficult when I'm shooting a moving target, and I've now no idea where it is...

re: Adding to, but not Perverting the Beta Process

AT — Mon, 10 Jan 2005 05:35:00 GMT

I think that there must be applied tiny correction to Josh statements:
Making Product Feedback database publicy accessible is not a very big deal.
The biggest problem is how this feedback will be used and replies provided.
I know that Microsoft VS.NET teams did a _good_ job in the past (I was in Everett 7.0, dunno about more old) handling private feedback.
This were improved a little bit since Everett, but I feel that this is no way related to PF database. I _feel_ that this was possible to change something internaly - without making everything public.

Several years ago I've proposed Windows teams to open bug report content to same limited beta group only. Unfortunately - Microsoft decided to make them open to _all_ the people.
Instead of test-driving Product Feedback _website_ on limited number of participants - website still in "beta" quality for about a 9+ months. This is not good.

Write about the 'here and now', or the 'soon to be'?

Rob Caron's Blog — Mon, 10 Jan 2005 11:25:00 GMT

re: Are Categories Useful? Please Excuse the Construction

scooblog (under construction) by josh ledgard — Wed, 19 Jan 2005 05:00:00 GMT

Beta Perversion Redux

Rick Strahl's WebLog — Sun, 30 Jan 2005 14:53:00 GMT

Visual Studio CTPs and the Customer Experience

Keen's WebLog — Fri, 01 Jul 2005 01:07:34 GMT

I recently joined Developer Division as a Program Manager.&nbsp; One of my goals is to improve the customer...

Visual Studio CTPs and the Customer Experience

Keen's WebLog — Fri, 01 Jul 2005 01:10:35 GMT

I recently joined Developer Division as a Program Manager.&nbsp; One of my goals is to improve the customer...

Visual Studio CTPs and the Customer Experience

Keen's WebLog — Fri, 01 Jul 2005 01:35:46 GMT

I recently joined Developer Division as a Program Manager.&nbsp; One of my goals is to improve the customer...

re: Adding to, but not Perverting the Beta Process

Billy Tan — Fri, 21 Apr 2006 09:56:56 GMT

Hi board,

Q1. Any idea how to do integrates software configuration management (SCM) with bug-tracking.

For example, glue MS Visual Source Safe with any bug-tracking system (such as Bugzilla and Mantis or MS product - which i dun think MS have it now). Please help me this..... (email me at billytcj@tm.net.my)

I just thinking, if user have the change to glue above mentioned items, they will have change involving the initial "drive" of software design mind-set. May be not much influence to original design, but at least they have a "way" to understand the difficultly or effort behind what they seen. From my exeperiences is ... people tend to raise thier "thought" when they not know how it working or design on it. Well... i believe "open_to_all_people" is a way to make the entire product more "ideal" during the release day, don't u think that?

scooblog by josh ledgard Adding to but not Perverting the Beta Process | Outdoor Ceiling Fans

Sun, 31 May 2009 13:52:19 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=20768

scooblog by josh ledgard Adding to but not Perverting the Beta Process | Outdoor Ceiling Fans

Sun, 31 May 2009 18:52:21 GMT

PingBack from http://outdoorceilingfansite.info/story.php?id=3132

scooblog by josh ledgard Adding to but not Perverting the Beta Process | patio set

Thu, 18 Jun 2009 05:24:16 GMT

PingBack from http://patiosetsite.info/story.php?id=637