The (oh so very cool) idea of implementing the perl 6 wiki IN perl 6
(eventually) is a powerful argument. I also concede that control
issues mean we don't want the official wiki to be on wikipedia. Kwiki
is already a perl-based wiki, but I have no experience using it. We
don't have to put perl 6 under the pugs subdomain, that was just an


On 25/05/06, Conrad Schneiker <[EMAIL PROTECTED]> wrote:
(Responding to 3 notes on 2 mail lists here; Changed subject line.)

Juerd wrote:
> Feather, the semi-public, semi-private, Perl 6 development server, is
> available to host a Perl 6 wiki.
> The hostname is deliberately kept available for something
> like that.

Does that mean you are willing to be the one to set up a Perl 6 Wiki and
administer it? (Preferably using perl5 wiki software, so that the Perl 6
Wiki could be available as soon as possible?) If so, how much more
encouragement do you need to proceed?

> From: Michael Mathews [mailto:[EMAIL PROTECTED]

> As a competing suggestion, how about...

Very interesting. But did you look at it? :-) I found this on the home page
link target:

    Consider using Subversion instead of this Wiki

    20051213Z05:58 <audreyt>  I'd like it [the wiki] to
    be strictly a scratchpad for lambdacamels.
    all reusable docs should be in the svn tree
    (and now Perl6::Doc)

This reminds me of my earlier suggestion:

    "Could we use part of Pugs doc tree as alternative
    to perl6-user-doc wiki?"

The basic idea is this: since the pugs svn tree is mirrored at, we
could have a subdirectory (for example "Perl_6_ Wiki") in the docs branch of
the source tree that would have a wiki-like hierarchy of html pages (or pod
pages for generating html) below it. The downside is that it would take
somewhat more effort to make changes and additions.

However, it might still be a good idea to take periodic snapshots of a
separate semi-officially designated "primary" Perl 6 Wiki and stash it in
the source/doc tree (or maybe in a CPAN module Perl6::DOC::Wiki) so that it
would be available for offline help systems / searching.

> I'm not really set on any option as long as it works and makes sense
> to everyone, including those outside this list. I probably missed it,
> but could you give the stated purpose for the wiki again, as I think a
> reminder (for me at least) would help.

Several people thought it would be a good idea to have a common place that
made it *easy* to collect and organize useful information about perl6--stuff
that is beyond the scope of "standard documentation". There is a lot of
interesting and useful perl6 information that is widely dispersed in talks,
documents, articles, and so on Likewise some of it current, some of it
obsolete, and much in between. Having a central collection that is easy to
browse and that is subject to substantial ongoing indirect review could be
very valuable. Think of the Perl 6 wiki as a vastly expanded FAQ that
supplemented many of the links with semi-consolidated content. Or think of
it as a semi-free-form meta-CPAN for "interesting" documentation. Or think
of it as a perl6 community gathering point and mega-billboard. Some examples
of suggested content: What are the main benefits of major perl6 features?
Why were various features done one way and not another? How are they
intended to be used? What are the benefits of perl6 relative to other
languages? What are the counter-arguments to various anti-perl6 FUD?

> On 24/05/06, Michael Mathews <[EMAIL PROTECTED]> wrote:

> > For example
> > there is nothing stopping anyone (including members of this list) from
> > creating and populating pages on about Perl6 and
> > this user group. Then those pages would be available to the wikipedia
> > search engine. <--- Insert any other popular wiki there.

I'd thought of that, but there's always the background issue of moderation
and control. (We definitely want the Perl 6 Wikipedia page to link to "our"
Perl 6 Wiki, of course.) I don't think Wikipedia is (at present) a suitable
forum for semi-controversial topics. Language advocacy / competitive
marketing is a highly contentious and emotional religious issue for many
people, and we certainly want perl6 people to feel free to indulge in
(reasonably civil) unbridled advocacy of all things perl6.

> > And of course with the ominipresence of google, finding and searching
> > is always becoming less of a problem.

In my experience, finding and searching has become more of a problem--in
particular: (1) with too many irrelevant matches, and (2) with too many
matches that turn up obsolete info. That's precisely one of the reasons I
started prodding #perl6 about a newsgroup for perl6 users. Being able to
limit your searches to group archives of what you are specifically
interested in often makes search results much more useful. Precisely one of
the reasons that a Perl 6 Wiki could be very cool is that the content is
more likely to be up to date, and it could thus serve as a good point of
departure for many sorts of perl6 related searches.

> > What would be annoying though is to invest work in a "perl 6 wiki"
> > that is only one of many "perl 6 wikis" and with no coordination of
> > efforts between them.

That would also be annoying for a great many users that invested *no* work
as well. There are {browsing, search, and comprehensiveness} advantages of a
common "primary" Perl 6 wiki.

> > (is there an official "perl 6 user's wiki" or
> > will there be, or is that a different question?)

Well, the 2 newest possibilities are: (audreyt)

    "Feather, the semi-public, semi-private, Perl 6 development
    server" aka "" (juerd)

Plus the previously existing Perl 6 Wiki that we are both welcome and
encouraged to use:


Feather has the powerful future marketing advantage that it can also be used
to develop and then host a showcase Perl 6 implementation of the Perl 6
Wiki. However, I think that we should initially *begin* with a solid and
proven Perl 5 wiki implementation that we can use *immediately*. If we could
do this, then this would be my first preference.

(Someone want to poll #perl6 for feedback? Unfortunately I won't be
available the next couple of days at "reasonable" hours.)

Best regards,
Conrad Schneiker (Nano-electron-beam technology.)

Reply via email to