I would just like to make the comments below:

Having promoted and implemented DotNetNuke into government agencies where previously they had been totally Linux houses, it had been a difficult task to turn these agencies around to even consider a .Net Application, however one of the most significant supporting arguments had been that the framework was well documented. DotNetNuke stood out amongst all other open source projects as a strongly supported project, well documented and with a strong organisational structure behind it.

In many cases the implimented sites would eventually be supported by their own internal IT resources.

Having not been involved post implementation on a number of these projects, my recent communications with some of these clients is that they infact have become quite concerned about the latency of upto date information, in most cases this may simply mean that the technical changes are documented.

In the early days of DotNetNuke, We used the DotNetNuke documentation as a learning tool for our free .Net user groups, this was an extremely valuable resource for learning .Net and introducing many to DotNetNuke.

While many of us are passionate about DotNetNuke, we need to consider the clients who we have promoted DotNetNuke to, these consumers do need a central document\infomation repository for DotNetNuke and it's sub modules, so I do support any move to this.

In my opinion, information is most important when new updates are made public, in our case we do complete lab testing prior to production, this is the most important time to understand what has changed and how this may affect our production environments.

From my experience, I do support the view that some harm will come from the lack of up to date information that is freely available, in the cases where we are promoting DotNetNuke to envirnments that traditionally prefer alternative operating systems or simply have never implemented a Microsoft solution (yes there are still a lot of these clients out there)

When we started introducing clients to DotNetNuke there were no .net applications in government, DotNetNuke was the first, all other applications had been linux, he road to convince the clients was long and difficult, however it's success was direcly related to DotNetNuke Corp, the product and it's supporting documentation. Without strong documentation and technical documentation we would certainly not have been sucessfull in this for nearly all cases. Typically each implemenation required some additional module development or changes to existing modules, these teams would not have accepted DotNetNuke if it had not been documentented well enough to get up to speed fast.

Over recent client reviews we have not been successful with DotNetNuke as they have rejected our promotion of DotNetNuke because of documentation not reflecting the current version or not being sufficient to make changes with existing teams without considerable effort compared to their own knowledge of alerternatives. While I may not support their findings this is was is actually happening. Perhaps there should be more community effort to maintain the documentation, we would be happy to help, however we need to be closer to the various projects to document changes and features!

So, my comments are that the value of this type of doumentation should be seriously considered as an important and required component of this project.

Craig