Mark Stosberg wrote:
On 2005-07-12, Jason A. Crome <suppressed> wrote:As I'm already hosting some of the CGI::Session things (SVN repo for now, likely a wiki in the not-so-distant future), I'd have no issues with also hosting the CGI::Application Wiki and (possibly) repository.I would, however, like to make someone else co-admin of the site if I were to do that ;)As far as wiki features go, I haven't played around with enough of them to really form an opinion.
I used wiki for 3 years to aid and document our internal development, and also to create my own bookmarks to all kinds of online information (which I maintain in a set of wiki pages). I also read many wikis, and contributed to some. So I may say I have some feeling which features make using wiki easier. :-)
Wiki differs from plain web pages in one important detail: allows not only read pages, but also to write them. But you want to make sure writers can contribute very easy - because the more writers you have, the more volume and quality of content you have. So wiki uses simplified markup to create basic HTML elements, to make them easy for writers. Goal is to make page editing easy for writers, and results to be still good enough for readers. It is a reverse from other web publishing tools.
Most important feature IMHO is "Table of content" (TOC) auto-generated from headers. Research shows people need to see page overview before they start scrolling down to search for more.
Another nice feature is COMMENT - which allows to add a comment quickly without full editing of the page. Let me confess I implemented it for Twiki (from almost-working version) and promote it since :-)
Looks like Kwiki has COMMENT now, but lost TOC - I know for sure it has it, Spoon implemented it for me for Kwiki 0.18. I noticed Kwiki has couple plugins for POD - but I did not looked into them, and have no idea how useful they would be. I write our docs in wiki, not in POD.
Also, not all Kwiki plugins might be designed to work together - I remember Ingy's idea was that there would be "distribution integrators" who will integrate different plugins. Like, TOC plugins depends of markup for headers, which is implemented in another plugin.
Another important (for me) consideration was, how hard will be to extend wiki to cover most of activities for managing software development project. This is primary reason why I switched to TRAC: because TRAC covers all activities right from the box, no customization required.
In addition to wiki, TRAC has integrates SVN code repository, code browser, bug tracker. And has special wiki markup to create hyperlinks to bug number X, or file revision number X. And reports showing which bugs needs be fixed for milestone, etc. Wiki markup work also in bug tracker comments. And as bonus, SVN has commit hooks which check commit message and if it says something like "fixed #1234", SVN goes to bug tracker and closes bug 1234, so you dont have to. :-)
Mark said me in private email that bug tracking for C::A and plugins is not an issue, it is done elsewhere. Fair enough. If only wiki was in consideration, Kwiki as one of the best perl wikis is in play.
But I want to suggest you, Jason: if you dont use internal bug tracker and wiki for developer's documentation, take a look on TRAC. It can host multiple projects, with multiple repositories. Downside, it is written in python. :-)
That being said, anything we can do to improve the user's experience and increase the quality of the information and help we provide. . . I'm all for it.
...how to increase quality of information about CGI::App...This is exactly why I am so interested in wikis. IMHO, wiki is far better form of group memory than email archive. When searching email archive, and you found interesting article, you never know if you got final consensus: would you find something else, different, more recent, with slightly changed search terms? Wiki page, in contrast, can have both consensus about the issue, and discussion (and arguments pro and against), in one place.
And wiki allows anybody to contribute. All it is needed is to summarize discussion from email list and put it (with possible links to archives) to a wiki page. And possibly email listers with links to new page for review and comments.
I remember when I started with CGI::App wiki and tried to post links to wiki pages to list, Jesse expressed his dislike to "spamming the list". Maybe under Mark's guidance, it maybe less of spamming and more about creating "best practices" pages, FAQ, guidance for newcomers.
With that turn of events, I would leave it to Jason to decide who he wants as a co-admin and let them have primary input on which wiki system to use.
TRAC allows to use multiple independent projects. Even your own work projects. TRAC uses Linux users for access rights.
Of course, final decision is admin's.I will keep "best practices" wiki pages on Twiki until needed, then will post links to new website.
--
Peter Masiar, suppressed, NEW PHONE: (203) 737-2989
Yale Center for Medical Informatics (YCMI), http://ycmi.med.yale.edu
I am not a lawyer. My ideas are NOT binding for University.
In doubt, Yale policy right: http://www.yale.edu/policy/itaup.html
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.