[cgiapp] Future of the wiki (was: Re: CGI::Application wiki page Examples)

[Gurunandan R. Bhat]

I had offered Mark to port content on the wiki to Movable Type a few
months earlier. 
At that time, Mark had very valid concerns - that MT does not offer key
features required of a wiki.
But that was MT4 and a re-evaluation of MT after the release of MT5
recently might be interesting.

Regards
Gurunandan
 


On Thu, 2010-01-28 at 22:02 -0600, P Kishor wrote:

> top posting -- MovableType is a worthy candidate for a Perl-based CMS
> that also has a good security. Once again, a few folks can have the
> keys to operate it, and others can ask for it on an as needed basis.
> Perhaps, only those who have been on this mailing list for a certain
> period of time can be authorized. Or, some other means for
> double-checking the intent of the potential editors/posters.
> 
> On Thu, Jan 28, 2010 at 9:47 PM, P Kishor <punk.kish at gmail.com> wrote:
> > On Thu, Jan 28, 2010 at 9:18 PM, Mark Stosberg <mark at summersault.com> wrote:
> >>
> >>> The idea was that the 315 subscribers to this mailing list are the only
> >>> people in the world with the slightest motivation to delete spam from
> >>> the wiki and, since its not a terribly thriving, active wiki, even we
> >>> members of the cgiapp community don't visit it all that much.
> >>>
> >>> So my hope was that by having these messages come to the list would
> >>> remind people that the Wiki exists, "ping" them that people contribute
> >>> to it, and maybe spark enough curiosity that someone checks to see what
> >>> was edited, and in the process, is able to find and fix spam.
> >>
> >> In my case, this has been working, and I have been visiting more. I
> >> don't really mind the notices right now, but I can also understand that
> >> the mailing list could feel like a drag if the quality of discourse was
> >> lowered to primarily being terse automated messages about wiki updates.
> >>
> >> It seems like a nice option to be enabled per-user, but then I'm not
> >> sure I want to see all the automated updates in my personal inbox...
> >>
> >>> It's my last attempt to save the Wiki.  If it continues to be used more
> >>> by spammers than the community, then it is not really worth the time and
> >>> trouble involved in continuing to operate it.  If, as I hope, these
> >>> messages help spur the community to step up and contribute and help
> >>> maintain and police the thing, then we'll be able to continue to have a
> >>> Wiki for the foreseeable future!
> >>
> >> Since I do some website admin work myself, I also appreciate this
> >> sentiment.
> >>
> >> Perhaps the wiki would be more interesting to use if we used a different
> >> wiki engine. Kwiki is written in Perl, but certainly never took off and
> >> seems to lack some features that seem standard in wikis now. For
> >> example, it seems like a large flaw that it offers no way to enter a
> >> short message explaining *why* a change would made.
> >>
> >> Other alternatives I'm familiar with include MediaWiki (PHP...), Trac
> >> (Python...) or and gitit (Haskell...). There was some interest in
> >> building a wiki based on CGI::Application, but that hasn't materialized.
> >> I'm sad to say that there's not a Perl-based wiki that I'm aware of as
> >> becoming prosperous and popular. For me, open-source vs. closed-source
> >> is ultimately a greater concern, and I could put aside language
> >> preferences and use another open source option.
> >>
> >> But back to the fundamental question: If the wiki was overhauled, would
> >> you use it and maintain it more?
> >>
> >
> >
> > Both David and you make important points, and I too empathize with
> > David's sentiments. Allow me to say "from the hip" at the risk of
> > being accused of "if you complain then do something about it." I hope
> > the community view the following in the spirit that it is offered --
> > constructive feedback.
> >
> > The cgi-app wiki is a very valuable resource, but is an outdated and
> > old-school looking resource. Actually, such seems to be the public
> > facing problem of most of perl-based incarnations -- perlmonks still
> > lives in dark ages although there have been many meditations on
> > overhauling it; heck, even the perl6 site looks goofy and not modern
> > at all. I downloaded Rakudo Perl, and am blown away by the language.
> > It looks be a fantastic incarnation when it arrives production ready.
> > But that Camelia spokesbug and the amateurish, nay, un-designed
> > rounded rectangles on the front-page with the center-piece being a
> > button that can't make up its mind whether it wants to be rounded or
> > square cornered, Perl6 website looks like it is for a totally
> > un-serious tool.
> >
> > Compare these to stuff made with RoR, or the regular rubylang site, or
> > the jQuery site, or sites showcasing stuff made with jQuery. They all
> > look and feel modern. Ajaxy bits, nice logos, good color schemes.
> > cgi-app.org is actually one of the better ones of the perl family. I
> > just wish it were even more modern and better.
> >
> > It would definitely behoove if cgi-app.org were running a protected
> > wiki written in cgi-app. I would rather the keys to the wiki were with
> > only a few chosen ones as long as I could ask them for it in case I
> > wanted to add or update a page or a how-to. Perhaps editing of the
> > wiki could be allowed only by those who are members of this mailing
> > list. That would be some measure of control that they are benevolent,
> > or at least benign humans. Until a wiki based on cgi-app can be made
> > by someone, there indeed are other Perl-based wiki that can serve very
> > well -- Twiki especially comes to mind. Oddmuse is a nice looking one,
> > and is hugely simple to implement, but may not offer the security
> > desired.
> >
> > Ok. Enough of what seems like a rant (I iterate, it is not meant to be
> > a rant). Here are some immediate suggestions --
> >
> > 1. Implement a Perl-based wiki that is still being developed and has
> > not been abandoned. This should be a stop-gap measure until a cgi-app
> > based wiki is developed (if it is not developed, so be it... at least
> > the cgi-app site would be running Perl).
> >
> > 2. Modernize the site bringing it in line with jQuery or RoR websites
> > with modern color schemes, Ajaxy goodness, and clean URLs.
> >
> > 3. Update and offer Mark Rajcok's turnkey web application as a
> > best-of-breed example, modernizing and improving it where needed.
> > Heck, perhaps that application itself can be used as the basis for a
> > new cgi-app presence. It is a nice, well documented, and half-decent
> > looking application. I have benefited from it, and believe others
> > would also benefit from it.
> >
> > Alright. I am sure I have said way more than I should have, but I hope
> > you all will consider at least some of the substance of my critique,
> > and not just flame me for it.
> >
> > Thanks for building a great tool and providing it for others.
> > Maintenance of it is an onerous but worthy task.
> >
> > Puneet.
> >
> 
> 
>