If the community of a community project has an issue, they have to hold the community responsible.  That includes the core team, module teams and posters in the forums.  At the very least, if anyone spots what they believe to be a reproducible bug, it should be their responsibility to log it into Gemini.

I'll play devil's advocate and ask why?  Or at least why does it have to have everything?  For example, Joomla, possibly the largest competitor to DNN, has what I'd call a failry modern and up to date site.  But they don't have demo videos, instead they link to sites running Joomla.  Umbraco, another excellent site, doesn't contain most of what the DNN site does.

Bingo!  This I agree with completely.  If it can't be done by the core, or by mismanaged teams, find new ones.  DNN tends to make contributing harder than in most communities, you have to join a team, but they will accept contributions and put them through testing.  One of my pet peeves is that releases come fast, but long-standing bugs or issues are left unaddressed.  A policy of "Nothing new until the old works right" would be welcomed by many.

And that goes for the DNN site.  Which when I look at it is very outdated, the Blue skin has been around for years.  It's oh so last week in web terms.

Jeff

There were actually two things that I would rather see core and project teams not doing - one was documentation and Cathal's wiki idea is excellent!!  This will open things up to allow additional people to help. While using a core module would be preferable, at this point, use whatever works and then work on the core module.

After reading Cathal's post about the wiki I was going to bring up the second thing and Joe just hit the nail on the head - communications.  Communcations in DNN has always been..... well..... slow.  Or as Joe just said things go on "behind the scenes" and no public information explaining things.  Don't get me wrong - some things need to stay behind the scenes. But more and better communications would be a serious plus.

My nomination for DNN communications director right at the moment would be Sebastian - as he already does an unbelievable job in the forums. But he also has the skills and responsibilities to develop so someone else might be a better choice.

Here's an example of communications- I have been running DNN 4.5.5 and was recently helping out a community member who was running DNN 4.8.4. I happened to notice a module called MarketShare.  I check the DNN forums/blogs generally multiple times per day and I had no clue what this module was.  I even did a Google search on dnn.com for it and found no mentions of what it was.  Yesterday I upgraded to 4.8.4 and found out what it was.

Joe wrote:

"People often assume that if they don't see any public statements, that nothing is happening behind the scenes."

Perception IS reality!

Could communications be included in a website team since they go hand-in-hand. A team that would be responsible for fixing the issues Andrew and others have brought up and enhancing communications?

Well I'm blown away to see talk about communications here. Comms has been the biggest failing of the core project management. I used to bring this up regularly in many of my earliest posts, even back in the asp.net forums - and especially during the switch to the new site here. 

Typically for a project run by and for developers, there has never been any understanding nor appreciation for virtually all non-development skills. People with business experience cringe at the idea of handing over the ownership and management of a corporate IT project to the code developers. Yet that is how it works all the time in these open source projects.

As for the DNN site and communcations channels, they have always been a total disaster. The project needs real communicators, real information architects, real marketers, and a proper strategy to go with each. The few changes there have been around DNN have been classic developer-led solutions: Provide more frameworks! woohoo! Developers are obsessed with frameworks (naturally) but they never appreciate that providing a framework does not also lead to it being filled with valuable content.

DNN shares this failling with virtually all open source projects however, so it's not as if it's any worse than the rest. But it's not going to improve either unless the head developers simply accept the need for skills they do not have and set out to bring them on board.

Anyhow... End of my rant. I was just stunned to see mention of these things in a thread and had to pipe up. Ultimately, the light has to be seen, and the change come, from within the core team... and if it ever does, I'll be ready to put my money where my mouth is (so to speak).

Rob

P.s. Don't put up a Wiki