I have been using DNN for about two years now, since version 2.
In that time I've seen a lot of improvements to DNN and I learnt a lot about the system.
Overall I thinks it is a very good system, and my most favorite thing...it's free!!!
Looking at DNN I think there are some things that always raised some questions to me.
I thought I might put them here in the forum and perhaps it could lead to some discussions and/or improvements in the future, so here goes:

• User rights/Roles - When I go to the settings of some modules and look at the rights you can set, there is always the list of administrators, all users, registered users, subscribers, your own defined roles, etc. What always seems to be missing for me is the role of the superuser. Sometimes, in a multiportal environment for example, you want modules just to be available to the superuser/host role. It would seem logic that this should be a standard role in this list, since there always is a host/superuser account and an admin account.
• Web standards - over the years web standards have become a much bigger issue. I've seen a lot of people try and build XHTML compatible skins and containers. For example: http://css.dnncreative.com/ and http://css.schwingnuke.com/  The step to use FCKEditor in future versions is already a very good one in this context. Perhaps looking for an alternative to Solpart would help, there are already some alternatives out there (though I admit they do not offer the full set of options that solpart does), examples are the css menu from Schwing (http://css.schwingnuke.com/Default.aspx?tabid=68), House of Nuke (Housemenu), Inventua's menu's (http://www.inventua.com/dnn-sidemenu.content). I think members of the core team should focus more on this issue.
• Core Modules vs. builtin modules in the core - Some modules are actually built into the core of DNN. While this perhaps is done because it has certain advantages, I think they can actually (and should) be seperated. So they become a part of the core desktopmodules. This might make keeps the core lighter/faster, better to manage, cleaners (conceptually), etc. Another advantage is that you can for example make them premium modules, and perhaps there are some more advantages that I didn't even think of. Modules you might think of are:
  • Banners (I know, already seperated, but the vendors should be seperated too I think).
  • Lists should/could be put in desktopmodules.
  • Newsletters should defenitly be improved and moved to desktopmodules.
  • Search (not everybody uses a search engine on their site)
  • Users online function in the host settings
• Help/Support option - The help/support option for DNN is a bit strange now. There is an online help function or you can add help using the resx files in app_localresources. I think this is an issue that could be improved. Perhaps a function could be made just like the language option but then a bit better, beacause with a help function, you might want to include images, links, etc. so you might need a text editor for this.
  Online help is nice for the core modules, but in the end I don't think it will work for third party modules. Also, online help is only available in English.

What if we had a more central Help System for DotNetNuke?  This might be a little over the top, but I think this would provide all DNN'ers with a comprehensive help system that is always the most current and would eliminate the need to maintain several help systems.

Basically...  DotNetNuke.com should have a web service (I'm not sure an RSS Feed will be as secure and it won't provide additional features that can be built in the future) that Skin and Module developers can tie into with a DNN Module or Windows application.  When developers have new help available, they can open the application/module and submit the new Help Document/Text to DotNetNuke.com.  The developers should also have a module they can use on their own site to display help information they have submitted to DotNetNuke.com on their own products.

On the users end, the DotNetNuke Portal should have a scheduled job that connects to DotNetNuke.com every two weeks and downloads new help information.  DNN could then have a Help link in the portal itself that displayed the help information in a knowledge base type setting. 

For those running DNN on intranet sites, this new addition could also provide a downloadable XML file from DotNetNuke.com that could then be manually imported into intranet sites.

This might be a little crazy (I think I drank too much coffee this morning) but it would provide a central knowledge base for DotNetNuke.

Benefits:

• Developers can post once and use everywhere. On their own sites, within the DNN portal itself and maybe there could be a new addition to the module infrastructure that automatically pulled in the module help from this system as well. 
• Users will always have the most up to date information from one location. 
• Saves the developers and users time
• The DotNetNuke core team could advertise on the portals Help page to further fund DNN
• The help can be multi-lingual
• DNN Help PDF files or Windows Help files could be easily generated from one source
• Intranet installations could easily be updated with the most current information without having a constant connection to the internet

Drawbacks:

• This will place additional loads on the DotNetNuke.com servers
• Will only work if everyone participates

• For each role you define in DNN you can set specific rights. Since a host is a role, I think you should have the option to give role specific rights. Perhaps you don't need host specific modules, but I sometimes do and perhaps other people do to. It would not seem to be a difficult thing to add to DNN, and it wouldn't hurt anybody to put it in there. I think it would fit in the concept of roles and rights.
• Good to hear that the CT focusses on web standards stuff. I didn't say DNN should include external components, I just wanted to point out that there are people who are working on web standards stuff already.
• I do not think that multiportal scenarios should mean that some modules should be part of the core. I know modules which worl in multiportal environments but are still modules. So I don't think this is a very good reason to keep them a part of the core. I think you must have a clear definition of what is part of the core functionality and what is/should be considered a seperate function and should be in a seperate module. For example a newsletter function is more something you would put in seperate module. Making pages, making language files, roles/logins/security are more a part of the core functions. I think there are still some functions that could be put into seperate modules and are not a part of the core.
• I think online help the way it is right now will not work. Perhaps it is an idea to make a seperate resx file per module for module specific help. Perhaps the core modules help that is available with online help could be put into the same things as are used for the language packs right now. This way you can seperate the help function from the module resx functions, but still have different languages and different versions of help. I do not think a webservice or any online system will work, because you have to deal with a lot of custom modules, you need disk space somewhere, you need administration of the service etc. And these things will cost money and time. Since DNN is opensource I do not think this will work. I think help should be managed on a local scale but with support of (downloadable) resource files.