> From: Michael Mathews [mailto:[EMAIL PROTECTED] > On 20/06/06, Conrad Schneiker <[EMAIL PROTECTED]> wrote: > > I propose to install twiki (http://www.twiki.org/) on Feather. > This is > > a GPL'd Perl-based industrial-strength wiki. This would serve as > the > > general Perl 6 wiki, aka Perl++. > > > > The source code would be placed in the Pugs .../other/... subtree > for > > us to incrementally convert parts of it to Perl 6, and to also > > add/change functionality. A perpetual beta version of this would > also > > be available on Feather. From time to time this beta version would > > replace the pervious Perl++ wiki code. In the mean time, we would > have > > the initial Perl++ wiki. > > Before you sent that I registered a project on Source Forge for > this, > half-thinking I would want to work on it but also open it up to the > entire community. Reason being that Source Forge has well- > established, > robust community project management features already available (I > have > another project there that's nearing it's 10,000th download). > > If you want a place to keep/hack-on P6 wiki code I'd propose that > http://sourceforge.net/projects/p6wiki be the place. Anyone who > wants > can have admin/developer permissions -- just ask. > > Feather would still be required to demo/test/run the latest > perpetual > beta release. What say you, Conrad?
Well first of all, thanks for the offer, and I appreciate the initiative. However, I had several reasons for suggesting (and strongly preferring) that Perl++ be under the Pugs tree: (1) The proposed wiki interface to the Pugs doc tree will require some collaboration with @Pugs. This is something that I think would be very valuable, so I want to make things maximally convenient for @Pugs to deal with. (This also gives @Pugs a built-in final say of last resort over required mechanisms and policies for updating Pugs svn tree docs from Perl++.) (2) People who have to get Pugs commit bits would be somewhat more likely to write Pugs tests (or update docs) for discovered Perl 6 issues, and it is near-maximally convenient to do so, since they would already be working in the same virtual office, so to speak. (3) Changes to the Pugs tree get a certain amount of useful scrutiny, and requiring people to get Pugs commit bits provides a useful minimal threshold, IMHO. (4) As an early project that will have a continually increasing fraction of Perl 6 content (and thus serve as a substantial evolving showcase for Perl 5 to Perl 6 migration), I wanted Perl++ to be readily available to Pugs users as working example code. (Something that comes with distribution is about as convenient as you can get, and it provides an ever-present temptation for exploring and hacking.) Providing a general purpose tool and strategy for accelerating the creation of various useful forms of user-oriented Perl 6 documentation is a huge priority for me. For the time being, starting out with Perl++ in the Pugs svn tree seems to be a semi-optimal point of maximum leverage for achieving this. I think this might also draw more people into Perl 6 development-related activities as well. Best regards, Conrad Schneiker http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6 Wiki.) www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)
