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