Changing code on PerlMonks is a pretty horrid experience (for a lot of reasons that I've written about before and that I won't take the time to discuss in detail at the moment). There are dozens of people in pmdev who almost all, at one point, expressed a desire to help change PerlMonks code (some just wanted to look at the code). I believe jdporter is the only reasonably active member and we have never had more than a few active members (excluding the gods who have a rather less horrid experience in changing PM code but still not a pleasant one).

So I'm sure there are many willing to help, in abstract, but I'm pretty sure that there are almost none that would be able to help, in practice (in part because people have real lives and must choose where to spend their "free" time).

There are even more people who are eager to help with the meta-problem of them not perceiving that "improvements" are implemented as they'd like. Get in pmdev and actually successfully submit patches and you'll have a partial understanding of the interconnected issues (or do the research to find previous discussions of many of the issues, no, that won't be trivial).

Actually, I believe that there have been several times when changes have been made too quickly. So I am unhappy that working on PerlMonks is so difficult and thus frustrating and that this has prevented a reasonable critical mass of PerlMonks developers from forming (and I blame my personal lack of time commitment also), but I don't really see a big problem with the admittedly slow pace of feature changes here.

I personally probably spend more time on performance problems (which involves an unfortunate amount of effort on political problems). I'm not a blogger by nature so the vast majority of this is not done on any stage and is only made public when there is some interesting outcome to report (which is rarely, and some "outcomes" don't warrant a report).

The current state is the sad state of: a (relatively) rare effort by some pmdev (jdporter is remarkably persistent, thank you) requiring one of the gods to analyze the code (which was probably never tested) so that they can assess whether it is likely an improvement and then apply it and test it and try to give feedback to the author of the change before reverting it, etc. Add to this the desire that gods not be too meddlesome by nature...

Anyway, feel free to join the long line of people who have promised to rewrite or re-invent the site or whatever, most of whom I haven't heard from recently (many of their projects actually came to exist and have since disappeared, and many of those I miss). The best route to making a real change at PerlMonks is to hang around a good long time and demonstrate an understanding of what makes PerlMonks a success; this helps you get into pmdev; then make a bunch of good changes while showing a temperment well away from rashness so you can eventually join gods where you can eventually lead the development of the site following a reasonable design vision.

In the mean time, I wish somebody would work on implementing the modest improvement of "patch appliers" that I suggested in order to marginally improve the current worst aspect of our work (yes, I would increase my time/attention commitment for such).