Re: Re: What is PerlMonks anyway?

[jdtoronto]

Aristotle and the other contributors make some very valid points.

Why not? If you have an idea about how to improve the performance of the site and confidence that you can implement it, why shouldn't you be able to try your hand at it?

Sure, but isn't that the way it works now? Ask to join pmdev, see what you think can improve things, then submit it for consideration? But we must always be mindful of the remarks made by Nathan Torkington about the internals of Perl - They're ugly and resemble nothing so much as a Lovecraftian horror (perl.com interview July 2001) and those of Chip Salzenberg when he cited Nathans remoarks in his response as to why he wanted to devise a new language entirely - where he ascribed the state of the Perl internals to the sheer number of people who had worked on them.

I may not have run big software projects, but I do know what happens when things go slightly awry in multi-billion dollar projects. I have also been the engineer responsible for projects where two people working on code is enough to turn it inot something resembling a mad dog's brekfast bowl.

As to OT discussion sections. Yes, after what everybody has said so far, maybe they are not such a good idea. Maybe the simple reason that Perlmonks is unique is because the only thing we deal in is Perl. Maybe their very existence will cause too much damage.

I also take your point on anonymous monks. Hmm, a difficult one! OK, maybe my ideas were not so clever after all.

But I stand by my remarks about opening up the development process. Having been involved far too many times in 'spoiled broth' projects I can understand why vroom and the Gods don't even want others doing the patching. If it was under my control I would feel the same.

This raises another issue that I do have some difficulty with, why isn't the code for PM freely available? That why if someone wanted to rebuild part of the code for efficiency (and I agree we could use some more speed around here right now!) then why couldn't he do it on another server such that he could demonstrate his code and then have it considered for inclusion in PM?

Seems that everyone is mute about the possibility of losing CB! I must admit it is one of my favourite features. In fact, it was watching CB over a period that enticed me to join up.

jdtoronto

[Aristotle]

Oh, I know that letting everyone in on the development process is no panacea. Lest there be any misunderstandings, by "try your hand at it", I meant you should be able to come up with a patch for review. Whether it should be applied or not should definitely remain the decisions of gods who have a (probably) better understanding of the ins and outs of the site.

The code is currently not currently open due to a concert of reasons that it make it unwise to do so. Let me explain.

To make sure patches don't break the site, they have to be tested before they are applied. Unfortunately, since Everything stores the code in the same database as the posts, and stores as nodes just like any other, it is hard to provide a functional mock up of the site for people to work with. The gods have one, but it simply runs off of a backup of the live database, which means whoever has access to it can read other people's /msg's, mail addresses and so on. So the only ones who can effectively test patches right now are the gods. We already have too few of them, and even those we have don't have much spare time. So regardless how many volunteers we do get, we're not going to get any added development speed out of it.

On the other hand, the site is known to have likely security problems. There has never (to my knowledge) been an extensive audit of the codebase.

So if the codebase were competely open, it'd be easier for some people to break things, while it wouldn't be any easier for others to fix them.

I agree with perrin nowadays that storing the code right in the database is not a wise decision. If that weren't the case, everything would be much simpler. I'm not sure how this situation will eventually be addressed and maybe resolved. None of the decisions involved are simle, unfortunately.