Lack of structure
I am agree with deprecated's Summing up recent ideas into a concept: Code vs. Prose, but I don't think the situation's so sad. Yes, there's a huge amount of prose respect to the code, but it's true that an encouraging portion of that prose is very high quality. What Perlmonks lacks is structure, and a way to prevent node aging. Good nodes (good prose and good code) are often forgotten.XP system has often showed its fallacies. To avoid oblivion, we use the experience of older monks and the patience of those who collect in their homenodes or in appropriate nodes (like epoptai's PerlMonk Related Scripts) posts which they judge significative from some point of view.
Code-related problems remain. According to me, code isn't reviewed and improved as it deserves to be. At least, not always.
Channeling structure
I propose a solution for the two problems I mentioned. I know (well, I guess) that everyone that write a node does it thinking to its immediate utility. I mean, every node has its own function in the thread it has been inserted in (I'm not sure this is English: I will try to explain it better if someone will ask me. Please forgive me). Nobody writes his nodes thinking that they will be put on a bookshelf. But, as it happens for books in a library, nodes are commonly used as reference. So, what I propose is to organize groups of nodes as they were composing a book. Not truly a book, that is a bigger intellectual and editorial effort, but something that brings structure to the stuff that is on Perlmonks so far.Such a job could have an interesting side-effect: a book such as I described needs code examples. For this reason we will be forced to review existing code and possibly to write new. This could be done in teams, allowing who is interested to write code while more experienced Monks review, comment it and suggest improvements.
Drawbacks: the first that rises in my mind is stagnancy. Everyone has a certain amount of time to spend on Perlmonks, and if he uses it to organize pre-existing material, he will not produce new nodes. I guess there are other disadvantages I don't see now.
I think we have a lot of interesting material: we could develop Perlmonks-books (in the sense I described above) for a large amount of topic such as:
- OOP and Perl
- CGI Scripts (obvious)
- Data Manipulation with Perl
- Human-Machine Interface with Perl