[From someone in the Saints list, who'd rather leave this Anonymously]

"We're sorry, we really screwed up."

"We aren't competent enough to fix it quickly."

"The PerlMonks code is so bad, even competent programmers can't fix it quickly."

"The PerlMonks code is such crap, we can't even give it away and ask for help."

"Many eyes will never make short work of PerlMonks bugs."

"We laugh at places like Twitter for being insecure, but we're leaving a badly hacked, insecure system up anyway."

"We give out lots of coding and security advice, but haven't really been listening to any."

"We've really poorly represented the Perl community, and we're sorry."

I only wish all of that "defensive egotistical self-centered crap", much of which I wrote, were mere excuses. Unfortunately, they are not. Should this change? Can it change? You bet. Will this change? That depends on the only people with the ability to make unfettered changes to code and site policy, the gods, of which I am not one.

Perl Monks has a long list of pmdevs but only a very few who can make meaningful changes. The code for Perl monks is split into hundreds of micro-segments spread across a database. To fix any of the issues that you consider "crap" would require a coordinated set of change that affects multiple segments, possibly 10, 20 or more!

Each and every change must be individually approved and tested by a god before it can be applied. There is no mechanism to submit and approve changes as a group. There is no test bed that pmdev's can use to validate their proposed changes before submitting them. There isn't even any good system documentation to show how all the code segments work together to support each custom post-Everything-I engine feature. That means that each and every significant change is a research project. For even a simple change to a system (rather than a bolt-on feature), the amount of information generated is apparently too time consuming to review. For instance, we have a pending proposed change to address the documentation situation that is still waiting for final approval (or rejection). When I last asked about its status I was told there was too much to go through at that moment - it has been over a month and it still hasn't been reviewed, approved, or rejected.

Should there be a test bed? Yup. Why isn't there? Well, first user data, system metadata and code is all mixed together in the database. The easy part is creating a specialized query to skip over private user information and using it to generate a tarball. That has even been done already. The hard part is that security rules are all mixed up in the code rather than segregated into a separately identifiable set of code segments. There is no way to eliminate that material from the download, without extensive code review and analysis, plus changes to multiple code segments, each requiring individual approval and review. That brings us round to where we started: no testbed, too few people reviewing too many changes. It is a vicious cycle.

Making massive changes without testing is a very stupid idea. Allowing testing and significant change would require expanding the circle of trust to include people other than the current set of gods. The current set of gods simply don't have the time to manage such a large set of changes to such an extensive codebase. This would be a lot of work for a paid team, and the gods are volunteers fitting this around their day jobs. But expanding the circle of trust also carries risks as well. At the moment the risk of change appears to the gods as greater than the risk of no change.

So call these excuses if you may, but the management problems at Perl Monks are not technical problems that can be fixed just by "doing it". Do you have a solution to the trust dilemma? A better way to add more hands to the till?

If so, stop spending time complaining and step to up to the plate. If you are so fussed (and you have a right to be), make yourself known, and advocate for what you think is right. Take the XP risk. And do it in a separate top-node where it will get attention. This thread is old news and the milk is already spilt. It is time to move on.

Best, beth

We have some prominent members such as Dominus, Damian Conway, Randall Schwartz, Larry Wall, et. al. who may not wish to reveal who they are when posting that kind of message (basically calling the people who run PM out). Maybe they would like the post stand on the the merits and not their name. Or maybe they don't want to ruffle too many feathers. It's hard to say, but calling the OP out for posting anonymously could be way off the mark.

The rest of your post just supports

"The PerlMonks code is so bad, even competent programmers can't fix it quickly."

and thus by implication,

"We've really poorly represented the Perl community, and we're sorry."

As to the rest, would a new post be useful? If the gods don't really care there is not a lot anyone else can do. Unfortunately, contacting The Perl Foundation directly about this incident may be more useful at this point. And along those lines, it is becoming clearer that the long term goal should probably be to migrate PM to a supportable framework/platform.

Elda Taluta; Sarks Sark; Ark Arks

I recall reading that there is some kind of test bed where gods test the patches.

Asking for folks to be forthcoming and then posting as an anonymonk lacks .. something. That being said, I agree, but would rather we get these notification emails out.

"We laugh at places like Twitter for being insecure, but we're leaving a badly hacked, insecure system up anyway."

It wasn't this server that was hacked. It was an older system no longer in use but apparently still on the network. The problem now is we don't know what was done with the old server and we don't know what steps have been taken to prevent the same exploit form being used on this server. More information would seem to be in order.

Elda Taluta; Sarks Sark; Ark Arks