Well, once again it is release morning. I can count the hours of sleep I've gotten on 2 1/2 fingers *grin*. And details have suffered in my blogging for the beta as of late. My apologies. I'll do a fulll review of last weeks chat tomorrow and then Monday's on Monday evening.
Why have I been so busy? I picked up work on the skinning engine... which (if I do say so myself) is getting pretty wicked. Here's what it can do (now):
- Handle named instances of tokens: So, if you wanted two instances of the links control in your skin, you could do that by specifying them as follows: [LINKS:Top] & [LINKS:Side]. The controls id's will be generated as dnnLINKSTop & dnnLINKSSide.
- Handle attributes for named instances: So, if you want your two instances to be formatted differently you can just specify different attributes in the XML file. In fact, you have to if you want to assign attributes because they will be keyed exactly as the token names e.g. [LINKS:Top].
- Support Skin or File level attribute files: Attribute files are optional. But you can specify one to be used for all transforms in the skin package (skins.xml) and/or one for each file to be processed (where there is filename.htm and filename.xml). The filename level file will override the skin package level file if it is present.
- Complete support for HTML tags which use URI's: So just about any tag that you can think of which uses a file reference will resolve correctly. I don't have a complete list handy, but:
- TD, TH, TABLE, BODY, IMG, BASE, HEAD, LINK, SCRIPT, BLOCKQUOTE, A, Q, OBJECT, AREA, INPUT, IFRAME, FRAME, XML, EMBED, BGSOUND
- Support for PARAM's: Not all permutations are supported, but enough for FLASH for now:
- PARAM NAME= MOVIE, SRC, BASE
- CSS Support for url attributes: In CSS, the url attribute is handled relative to the location of the CSS file itself... but not for NN 4.x. In the spirit of supporting multiple browsers, paths are corrected for url attributes in CSS files too.
- Absolute paths are ignored: So any file reference mentioned above that uses HTTP://, HTTPS://, \\ (share names), or \ (root relative) will not be translated. Likewise “javascript:“ references that hide inside HREF attributes are also accounted for and won't cause any problems.
- Detailed processing log is displayed: Now you can see exactly what the install process is doing. A pretty detailed response is generated to a skin upload which should aid non-technical skin devleopers in testing to see how they do. Anything that is an “error“ will show up in red.
It's also pretty fast... and pretty flexible. It can be extended for additional substitutions pretty easily... IF (and it's a big if) you are comforable with regular expressions. The skinning engine is now a pretty good lab for dealing with regex as that is how all the token and path manipulation is done. If you are interested in dealing more with regex, I HIGHLY recommend The Regulator. The skinning engine would still be in progress without it. Thanks to Roy Osherove and the Regulator team for a terrific project.
That's all for now... so much to do and so little time... and, about 2 hours before release of BII there is... no rest for the wicked.
Time has gotten away from me. It has a tendency to do that. But before I completely miss the opportunity and get an entire week behind… I wanted to update everyone on last Monday’s core team chat. It was well attended and there were lots of little things to talk about. I’ll fill in some details of things that have made progress since then as well.
Beta 1 Downloads ~
As of Monday afternoon (roughly 48 hours) there had been over 2000 downloads from the DotNetNuke site. It is hard to say how many more had been made from GotDotNet. We have removed the download from GDN as we were receiving too many complaints about receiving an “empty zip file”. In order to ensure quality service and to better track usage, downloads will be likely be available only from the DotNetNuke home site going forward. ~ Note that as of today the number of downloads is approximately 3700.
Interim Beta Builds ~
It was discussed whether or not we should release “interim” builds during the beta period. The point is that beta 2 IS the interim build. It is slated for a March 6 release and will contain lots of fixes (as many as we can do). Whether or not this is exactly the right approach (maybe we can do beta releases faster than every three weeks), we are going to stick with our plan for 2.0. Maybe for 2.1 we can try it differently but it doesn’t serve anyone well to mess with our plans in progress when we don’t even know how it’s all going to work out.
2.0 Bug Reporting ~
Folks are staring to find and log issues… GOOD! This is what the beta is for! As of today the number of bugs logged in GDN (our public issues log) is around 50. There are another 40 in the teams’ internal list. With 23 fixed 10 withdrawn and only 7 remaining. Some of these are dupes… Scott McCulloch and Josh Weinstein (congrats on the new baby girl!!!) reconcile these lists every couple of days. We’re very happy with our installation of Aardvark, although our server is not sending notification emails just yet. We’re working out our own kinks with using the system but hope to be able to use it (probably not for 2.0) to publish a publicly accessible knowledge base and allow direct public entry (and tracking) of items.
Known Items ~ sample skins
There were no skin samples included in the beta 1 release. We’re considering what to do about that… it was decided (and rightly so) that the DotNetNuke sites’ 2.0 skin will NOT be included in the DNN distribution. It is real property which provides brand identity and should remain privately held. Unfortunately, it was originally included in the source on GDN (during alpha) so some folks already have (and are using) it. The original look (1.x) was pretty generic… but we don’t need every default installation of DotNetNuke to be confused with the real one. That being said, we will be looking for some examples to provide. However, should they actually be shipped as part of the DNN package? Or be downloadable separately? This is still in discussion.
Known Items ~ Module Communicator
Module communicator functionality had not been retrofitted for 2.0, nor was there a working sample. This is being taken on by Mark Hoskins who, working with some community contributions, is already done with a first draft implementation. A working sample will go out with the beta 2 release.
Known Items ~ Users Online
This popular module, written by core team member Scott McCulloch, is being retrofitted for use with 2.0. We have made some changes to the core (rightfully) which the new module will be able to hook into which will allow it to function without having to make additional changes to the core. The changes are such that performance impacts related to the using the module are not absorbed by the core (affecting all implementations) but rather only for those portals that choose to install the companion modules. This was a major consideration in working to make this possible.
Known Items ~ AccessDataProvider
Shaun is on it. The AccessDataProvider will be in sync with the SQLDataProvider for the beta 2 release.
“Dogfooding” the DNN site ~
We still intend to upgrade the DNN site to 2.0… this has not happened in production yet, although Shaun has done it without issue on a test system. It’s just been a matter of availability. Expect it to happen sometime soon. The only real concern about doing this has been about possibly sending the wrong message to folks when we keep saying “Beta software, not for production use, etc”. When we do it, there will be a suitable warning prominently posted on the front page.
Private Beta Team ~
Off to a slow start, but we’re rolling now. What with getting Aardvark set up, playing with our test server and just getting the release package out. We didn’t get set up as fast as we should have. But we now have 11 private beta testers (a couple more invitations still outstanding) who are working EXTRA hard (all the community testers are working hard) to locate and clearly describe issues for us. Expect a formal announcement in the forums sometime soon, giving well deserved credit to all those helping to make the 2.0 release successful.
There was more… but this is the most relevant to current discussions and my fingers are tired. I’ll try to keep up a little better and give you some more information on bugs as they are slain. But it’s a hard job… the Knights of the DotNetNuke Table are slaying the Dragon faster than I can keep up with! You’ll get more updates, don’t worry… I’ll be back.
I would say it feels like Christmas Eve... but instead of feeling like a kid waiting for great new toys... I (we) feel more like a new Santa! Will our toys be well recieved? Will people like them? Will they be good enough? Will folks complain if they find them imperfect? I feel like biting my nails just thinking about it.
Yes. Yes. Yes. And Yes!
It's always hard to throw your personal work out to the hungry crowd and hear the unfiltered, often unrestrained feeback! Much will be good, some not so good... we are getting used to that. Any of you who are parents will know what I mean... new babies are at once the most beautiful things you've ever seen and yet also kind of squishy and gross (except for your own, of course). Well, DotNetNuke 2.0 (Beta I) is our baby.
With less than a day to go before our official beta release, there is still much activity going on. Scott McCulloch & Josh Weinstein are cleaning up our team and GDN public issue logs, preparing for the inevitable onslaught over the next couple of weeks. Phil Beadle is making final arrangements for our dedicated beta team. Shaun Walker, Geert Veenstra & Joe Brinkman are (I think) the final ones tweaking code (and some of them are big tweaks). Shane Colley is writing and planning press release material for the beta and general releases. Several people are still testing like crazy including myself, Salaro Golestanian, Lorraine Young, Russ Johnson, etc. And a bunch of other folks are doing our normal forum support, preparing for 2.1 scope discussions, planning enhancements to team structure, writing documentation, etc. Holy cow we need more help! But that is another column...
So whether we actually release at 12:01 AM (PST) or whether it's more like noon... tomorrow is the day. Happy Valentine's day... may you all have better things to do than download DotNetNuke *smile*. But you can know that we are... counting down with you.
There is one other item of particular interest to some that came out of our core team chat. That item is regarding the scope of what I'll call the “Core DataProvider” for lack of a well defined term. Each private assembly requires a DataProvider for each supported DBMS. The “Core DataProvider” is the one that facilitates the guts of DotNetNuke.... rather than, say, a PA. The term could also encompass a particular DBMS implementation (e.g. “mySQL Core DataProvider“) or the abstract contract for any DBMS implementation. Enough with definitions.
There has been considerable discussion within the core team (and without) about building DotNetNuke “lean”. By that I mean abstracting wherever possible to create looser coupling, thereby allowing other developers to extend DotNetNuke in ways which will not necessarily be impacted by upgrading (e.g. PA's). One simple way to initiate a change like this is to take all the current “default modules” and build them as their own PA's. This is a good idea in concept. But it has complications.
For whatever items will continue to “ship” with DotNetNuke (including default modules) a 3rd party developer of a DBMS DataProvider would have to provide support. The more instances of actual DataProvider components are separated... the greater the support responsibility and complexity for any 3rd party provider. However, the fewer the instances of actual DataProvider components... the greater the likelihood of frequent change and thus increased support responsibility and complexity for any 3rd party provider. Hmmmm.... a balancing act? Third party module developers will always have their own DataProviders and support RDBMS's based on market demand for their tools. But the conundrum for encouraging and supporting 3rd parties to implement the DotNetNuke Core (!) on different DBMS platforms is different.
A solution approach which is on the table is to separate the current default modules from the rest of the core into a single PA. This would provide a compromise between flexibility for continued development and support requirements for “Core DataProvider” vendors. So what is now one “Core DataProvider” would become two. Both shipped with DNN. But the business logic required for the current default modules would no longer be embedded in the DataProvider which should rightly contain architectural functionality. And improvements to the default module collection could proceed on a separate track from the true core.
This is the current train of thought. But, as I stated earlier... it is tabled until Beta II is released (as is scope for 2.1). Until Beta II is out the door we won't even discuss... juking with DataProviders.
Tonight was the last on-line core team chat before we go live with DNN 2.0 Beta I. It was well attended… better than usual… even by folks in time zones where normal people are sleeping. But then we are not normal people… [interpretation purposefully left open *wink*]
Here is a brief (?) summary of our 2 ½ hour conversation as it relates to the community.
~ STAYING ON TARGET!
Even we have to discuss this amongst ourselves once in a while. The temptation to enhance and tweak and look toward the next release is too great. But with 5 days to Beta I release we still have some big things to knock down in addition to some big ticket bugs in our issue list. Beta I will be released with several known defects… as beta software often is… but they will be cleaned up prior to general release. Among those known defects, the Access DataProvider will not be released until Beta II; the PA Uninstaller will not be finished until Beta II; as of today there are big things to fix related to Vendors/Vendor Management, Search and User Defined Tables. A complete list of known issues will be published at the time of (or with) the release. Scope of version 2.1 will not be open for discussion until version 2.0 reaches Beta II.
~ Option Strict and Standards
Seems the cobblers’ son never has any shoes. But we need them before our feet get raw… Thanks primarily to Geert, DNN 2.0 Beta I will be delivered with Option Strict turned ON! Having eliminated literally 000’s of errors and warnings… there is a high degree of likelihood that some castings or resolutions to late binding issues will introduce minor bugs. Additionally… there’s going to be more than a few developers out there who don’t use Option Strict that are going to learn about some issues in their own core mods. But mostly, we have reached a point where project standards are no longer a nice thing to have… they are a “must have”. This is popping up in all kinds of threads including project & solution configuration, namespaces, casing, dataprovider interfaces, skinning rules, *.dnn format for PA’s, inline code commenting, etc. Consistency needs to be more easily (both) encouraged and enforced. There will be a push during the beta period to try and codify some of these things… but the communities help is going to be required.
~ Issue Reporting for the Beta
We have a new tool. Thanks to a generous software donation from Red-Gate Software and hosting provided by PortalWebHosting, the DotNetNuke team will be working with Aardvark. We considered opening access to this tool, but we feel it important to spend some time with it ourselves to better understand it’s potential and refine our configuration. We will use our GotDotNet repository for all publicly submitted issues during the beta period. Josh & Scott M will be monitoring and updating both the GDN Bug Tracker and Aardvark. Internally, the team will be learning to use Aardvark and we will see where it goes from there. Our Beta downloads will also be available from GDN so it will remain our primary support presence until further notice.
~ Publicizing Releases
DotNetNuke enjoys a pretty strong and pretty loyal following (thanks to all). The 2.0 Beta release is a landmark milestone and we are looking for ways to extend our “press release” through various channels. All “official” releases will come directly from the DotNetNuke site, although those releases may then be freely distributed.
~ Beta Release Schedule
Beta I will be released on February 14, 2004. Internally, we are working with a hard code freeze at 12:01 am GMT-8 (PST), February 13, 2004. This will provide 24 hours for cleanup and packaging of the release. Our next release, Beta II, is scheduled for 3 weeks later, March 6, 2004. Although we considered a shorter period, we believe it impractical to get the release out, get feedback, and fix bugs (in addition to the known defects) in any period shorter than this. No specific release date is being confirmed beyond Beta II at this time, though it will be largely a function of community feedback based on the Beta II release.
~ Private Beta Test Planning
If you haven’t received an invitation yet… don’t fret, they have not gone out yet. However we have finished our internal discussions and are very excited about having quite a few fresh faces diligently working over the release. Expect these to go out within the next couple of days and for us to then publish a list of “official” DNN 2.0 Beta testers in forum. Phil Beadle and I will be coordinating this effort for Shaun.
~ PA (Private Assembly) Installer
This little gem gets more complex every day… but it is an amazing piece of software and we believe it is key for DotNetNukes’ future (kudos to Joe Brinkman and to Jonathan de Halleux on whose PA Gold installer it was originally based). Some of the discussion was around transactional support… which will be supported in Beta I. So if you have a module with multiple database entries to process, it either succeeds or fails as a transaction, thus supporting a complete rollback rather than a broken install. There are two main difficulties with this for us to consider. First, there are lots of v 1.x PA’s out there with SQL that generates warnings/errors which would kill a transaction… So in order to ensure v1.x compatibility (without changes), there will be no transactional support for v1.x PA’s but it will be in effect for v2.x PA’s. Vendors of v1.x PA’s may wish to repackage to utilize the new *.dnn format, but it will not be required. The second issue is transactional support in various dataproviders (e.g. Access & mySQL). The PA Installer will support syntax in the SQL file which will nullify errors/warnings (e.g. {ignoreerrors}). Since this file is parsed by the uploader, it can execute those statements outside of the transaction making it possible for dataproviders which do not have transactional support to work.
~ Miscellaneous Items on the Issues List
There are a number of big ticket items which still need work. Some of these are impacted because they were never working particularly well in the 1.x version and now, with the abstraction of the dataproviders and the BLL, the problems are more obvious. There is work to do on Vendors, particularly with the service directory. Search functionality is also not working fully. It is generally agreed that new search functionality is needed… but that current functions must be working as they did before until a future solution can be addressed. Current logic employed in search may not be usable for all dataproviders. RSS Feeds also need work, the 1.x method was not reusable. For Beta I or II, the original method will be restored but a more general method will be devised… this has been on our roadmap for a while and is waiting in the wings. Mobile functions have been removed from 2.0 since, again, they were not working well (even at all, out of the box) in the 1.x version. There is still some mobile code to be cleaned out of the project. Mobile will be added back into DNN at some point in the future… when a better implementation can be devised. Can anyone say Whidbey?
And so, there you have it. 2 ½ hours of core team chit chat. And before the 2.0 Beta I release… a few last words.
At the moment, our internal bug list has 85 entries since we started the Alpha stabilization effort in early January. 20 are open. More will be added before we hit beta... but the really hard stuff is falling by the wayside, which is good news. Actually, some of the bugs that are surfacing are related to legacy issues. That means they are things that weren't working correctly in 1.0.10 either. This is even better news.
Given that 2.0 is a total overhaul, one would expect there to be new problems with old working features in addition to new problems with new features... double trouble. Earlier in January we were afraid that this might be the case. But the team has been pushing hard in the "ninth inning" and it's going to be a race to kill off the bugs faster than we can find them. As the team was reminded today, we are **7** days and counting until the first official beta release. And it's going to be as clean as we can possibly get it before then. What were you doing at midnight on Friday night? I was getting hit with update messages from our issues list. The gang is out there pounding on them even as I write.
Will there be more bugs? Of course there will. And there are a zillion requests for enhancements as well as an already lengthy list of things on our roadmap. But the good news is... we're starting to get happy with things ourselves. Even proud. Because we know... we can work it out.
Open source amazes me. Doesn't it amaze you too? It's almost unbelievable how much help is available to you from complete and total strangers. And I don't mean just "Oh, look over there" kind of help... I mean the kind of help that takes actual sacrifice; real effort or time or resources to provide. What motivates people to "give" like that? That's a whole different column. However I'd like to take a moment and say thank you to some folks who have recently offered to "give" to DotNetNuke.
As you know from my last column, we've been in a hunt for Issue/Enhancement management tools. We have been really struggling with utilizing the free tools available. GotDotNet and SourceForge are really valuable resource for many projects, but they just weren't built with the features to support any kind of work flow with a group of 30 (or larger). We've been wanting, and in fact needing, something better. Something that would facilitate some process, tracking, filtering, sorting and even publishing of information. Well, now we've got something.
Over the course of this week we have been corresponding with a few vendors who provide tools in this area that we considered appropriate for our needs and complimentary to our architectures and platforms. Each of these tools has different strengths and features and is excellent in it's own right. And each of these vendors has offered to "give"... to generously support DotNetNuke through a gift of licensed software. We want to show our thanks to the following vendors.
Axosoft, OnTime ~ OnTime provides software development and test teams with a comprehensive defect tracking and task management solution that's easy to use, robust and scalable as your team grows. OnTime's main objective is simple: To help development and test teams build software more efficiently, within budget and to deliver the solutions OnTime!
OfficeClip, Issue Tracker ~ IT departments, sales forces, and Human Resources personnel can all benefit from the OfficeClip's highly-configurable, easy-to-use Issue Tracker. It is designed to run on a web server that can be accessed via a web browser or web-enabled mobile device. It is implemented using the Microsoft .Net framework ®, which provides flexible configuration and implementation on various web browsers.
At the end of the day, however, we have accepted an offer from a software provider well known to many of you. You may already own some of their tools, and if you don't... you might want to reconsider. Red-Gate software makes tools for developers. Good tools. I have personally been a user of Red-Gate Software's SQL Compare product since about version 1.2 and it is one of the most valuable tools in my personal library. Now we have Red-Gate tools in the DotNetNuke library as well.
Red-Gate Software, Aardvark ~ Aardvark is a simple tool for a very complex problem - tracking and managing defects, bugs, issues and problems. Completely browser based, Aardvark is designed for software teams that use Microsoft technologies. Whether you are a developer, tester, project manager or CIO, Aardvark can make you more productive. With Aardvark, we have produced the most simple product on the market at a price that every company can afford.
We at DotNetNuke (and in the community of DotNetNuke as well) would like to say, thank you. Thank you to each of these fine vendors who offered generously to donate to help further our cause. I encourage each of you to consider these tools if you or your company have similar need.
It's open source. And we thrive... on the generosity of others.
Willhite. Thats me. And it's time to talk tools.
DotNetNuke does not fit easily into any particular OSS project model that I have yet found. It is enigmatic in a number of ways, including sheer size. There are relatively few OSS projects on SourceForge or GotDotNet or any other public system that can boast a core team of developers in the 30 range. Now I'm talking unfunded community based open-source stuff here... no fair dragging in Linux or OpenOffice or some corporate sponsored self-aggrandizing publishing format. Most OSS projects max out at around 6-8 devs. Why? Well I'll take this in two directions. One because I want to for the moment and the other because it's the real subject of this post, capacity... one factor of which is related to tools.
DotNetNuke is different. It's not a niche application. It's a niche building application. And it doesn't discriminate. If you've read any of my forum posts you'll recognize my favorite Seuss-ism, “thing maker“. We have verifiable DNN production installations ranging in annual revenue from $0 ~ $400M. Our active forum community has skills in it ranging from those of my mother to those of some of the best talent I have ever worked with (and I have worked with some scary impressive talent). While it is a showcase for Microsoft technology (figuratively, I mean) it is not exclusive to any particular language or technology. Sure, we're VB.Net based but you can write Modules in any .Net compliant language you wish and with the data abstraction of 2.0 you'll be able to use non-Microsoft databases as well. Write a PHP emulation module against Firebird if you want... I'm sure someone will find a use for it. We provide a learning platform for best practices and various technical implementations but we're not going to pick up every widget, control and application block just because it has "MS" stamped on it. That being said, we are what we are. And we are founded on Microsoft technology. So when we look to partner... there are definite approaches to synergy that we must consider. Too not recognize ones own nature is not being open-minded... it is simply foolish.
We need tools. As a pure play OSS project our budget somewhat limits our choices. And all of those choices seem lacking in some way related to robustness of implementation, reliability, compatibility or just plain old comfort value. There's a lot of die-hard OSS guys out there heating up as I begin to infer that SourceForge won't meet our needs, but... SourceForge won't meet our needs. It's also not the kind of synergy that we are looking for. It doesn't work with our vision of the future. A vision we are just beginning to glimpse but can see taking shape on the horizon. We are due a “charter“ or “mission statement“... but it didn't work out too well for Jerry MacGuire and so we just haven't gotten around to it yet. We will.
Most of you know that for the last few weeks we have been working with a source control system other than our home on the GotDotNet Workspaces. No, we are not abandoning GDN because it has certain other synergies as well. But it sure won't be our repository for daily code work. Our transaction volume is just too high and it's going to get higher still. Through the generosity of another company, we have increased our productivity significantly by removing version control as a limiting factor. When we have solidified our arrangement with our new benefactor you will see us (www.dotnetnuke.com) openly endorsing their product. Is that a cop-out? No. I don't know about you, but I use what I like and I like what I use and I'm not afraid to recommend it to others. Particularly when talking about a gift... it's called "giving thanks". Mom told me I should do that.
We're expanding our tool search to include Bug/Enhancement Management tools. In fact, we already have a couple of offers in hand from some compelling vendors. We could have gone straight to the enterprise tools category (some of us still have connections) but they are overkill and overly complicated. So we are shopping the middle market. We could have gone the CollabNet route... like OpenOffice and CVSHome. But although it's tools are compelling it is so tightly integrated with it's portal product... something about that stumps me and I expect to be offering our services to CollabNet instead... *wink*.
Keep an eye out for news. As we begin to solidify some of these tool arrangements we will be keeping you posted and you'll see them referenced on www.dotnetnuke.com... as is right. We're trying to get an new system in place before we start the beta. As always, there is much to do. And it is time... for tools.
My third post and it hit me already. How many years do I have to work with technology to learn. I lost my post. Having worked on a long informative piece for an extended period of time I submitted only to find the login screen staring at me. Quickly assuming that supplying my login credentials would complete the posting action, I did so. Oops. No post, no cache to recover. My apologies... I will try to recreate it this evening. Right after I log this behavior with Scott Watermasysk's beta issues for .Text *grin*. They don't call it beta for nothin', do they!
Thanks for the wonderful blogging tool, Scott! .Text is a very powerful medium.
This is the first time in it's history that DotNetNuke will have a “public beta”. OK, so some might argue that the way we have released in the past has been more like beta, but by and large we have done pretty well. Or I should say that Shaun Walker has done pretty well... as there have only been a few releases since the formation of the core team. But that is another column...
For the 1.0.10 release, there was a very brief but productive “private beta” conducted. Some of you may remember forum postings with credit. But if you will notice in the elusive “contributors.txt” file in the documentation directory of the project... the testers are listed there. The few brave souls that got the release about a week early and helped to resolve a number of previously unidentified bugs. This effort was by no means coordinated... I think the extent of my instructions to Bert Corderman (bertcord) at that time were “try to break it” (which he did). That will be changing from here on out, the value of the beta testing was proven.
Phil Beadle (aus_nexxus) will be working with Shaun Walker (sbwalker) to coordinate a more “personal” beta test with some of our more active and knowledgeable contributors. The core team is compiling a list of names and we will be sending out invitations sometime within the next week or so. Nobody should go “Willy Wonka” on us here as we these are not “golden tickets”. Remember the doors to our candy factory (er, beta test) are open to everyone. But those that accept the invitation to participate in the “private beta” will be accepting some additional responsibility and, hopefully, enjoying the benefits of some community notoriety as well.
That said, what's the point? Well, the first thing to remember is that this is all geared toward the benefit of the community via an increase in quality. This helps accomplish this goal in a number of ways. First, it provides us with a base of known testers that we can be sure will report with sufficient detail and instructions to reproduce the errors (they will be operating under instruction and light supervision). We don't always get that with public submissions for one reason or another. Second, we know that the issues we get from this group will be valid (if not challenging) as each of these folks has proven themselves deeply skilled in the 1.x or 2.x alpha frameworks. And third, each of these folks will be committing to put out an above average effort to work over the releases as soon as possible and with as much data as possible which expedites our turnaround from release to release. Sound like work? Well, yes... it is... so don't let the cat out of the bag as we want those invitations to get accepted!!!
Everyone else is still heartily encouraged and “invited” to participate in the public beta test. Despite the help of a private beta group, the public beta group is really important because this is where all of the “variations“ get tested. There is no way for us, even with the help of a test group, to possibly imagine (let alone test) all the combinations of hosts, modules, configurations, etc. that everyone has. So just because you know there's a private beta group... don't depend on them for everything. You are important too!
Scott M (smcculloch) & Josh (weinstein_josh) are planning some interesting community fun as part of their issues management responsibility. My hat goes off to anyone who can make that “fun” *grin*. Be watching for beta news & planning from more folks than just me... but you'll continue to get daily updates here.
Happy DotNetNuking!
More Posts
Next page »