|We don't bite newbies here... much|
The next stepby nashdj (Friar)
|on May 09, 2001 at 06:48 UTC||Need Help??|
I have been tossing these ideas around in my head for some time. After I saw deprecated's Extreme Community (discussion), I decided it was about time I shared them.
Right now Perl Monks runs on the Everything Engine which means it can handle some very dynamic content. We have a really large and friendly community, most posts that dont belong get some form of a polite reply.
But that's not what I'm talking about. We have a great site here, it functions well, yet there will always be a place for Perlmonks Related Scripts, people are always going to want more. It would be great if all of these features could be embedded into the Perl Monks EE implementation, and theres no reason why they couldn't, slowly it might even be happening. But for a one man show I cant see this happening nearly as fast as the growing userbase.
I mentioned that the EE can handle dynamic content (duh), it allows us the community to build that content. Its a process that works incrediably well as demonstrated by this and a few other sites. I think it might be time that people looked at the next step, right now the community can shape the content, how about allowing the community to shape the interface as well?
No I dont mean just throwing the whole of Perl Monks up on sourceforge.net, that might work, but I'm farily certain it wouldnt work "as well" as it could with the EE. The Everything Engine is designed to do, well, everything (in one place). With a little hard work I'm sure it would be able to cope with this as well.
Sure you might say that this is the point of everydevel.com, but I'm talking about Perl Monks. We are building a very specific community here, people who use and love perl flock to this site on a daily basis to get their fix. What I'm suggesting is that people who use and love perl, would love to be able to shape the way their community communicates, through using perl. (Did that make any sense?). What I mean to say for example is, how much of the community would play perl golf, if the result was a new statistics engine to be plugged straight into Perl Monks? I'm guessing anyone who's capable would be up for the challenge, and those that aren't would certainly offer ideas, features, and help along the way.
So what is the next step? Well, I'm not really sure... Perl Monks is our community, but as a site it doesnt really belong to us. Which makes me worry that it's not necessarily right for me to be proposing things like this. That said, I am convinced that vroom and the EDC are very nice people who will see this for what it is.
What I would like to propose is something a bit like the Java Community Process. Java is a programming language created by SUN, just like Perl Monks is a web site crerated by The Everything Development Company || Blockstackers. The JCP is an open method for the Java community to specify, develop, revise, and implement the various forms of java technology. The JCP makes use of JSR's (Java Specification Requests), much like RFC's. (ok I'll try to stop with the acronyms). Basically the community specifies the technology it wants, evaluates and finalises the specifications then implements them. The community is a part of the process at every step of the way.
That is the kind of thing I would like to see our community involved in. From here on I'll refer to it the Perl Monks Community Process until I can think of a better name. The PMCP is a process through which Perl Monks as a web site and Perl Monks as a community can evolve.
That is almost everything on my mind right now, I can see visions of how the PMCP could be implemented into the site (vairous voting options for the acceptance of specifications) (electing members of the community to manage the various implementations of projects)...
Finally I would like to propose that if vroom and the EDC see these proposals as a usefull addition to Perl Monks as our community and as the site, that we use the psudo-PMCP steps I have listed above to specify, revise, and implement a true PMCP.