DPRG List  

[DPRG] Re: DPRGlist Digest, Vol 45, Issue 5

Subject: [DPRG] Re: DPRGlist Digest, Vol 45, Issue 5
From: Sanjay Dastoor sanjayd at stanford.edu
Date: Sat Feb 2 16:02:27 CST 2008

We use a wiki at my robotics lab (TWiki):

and I set up a wiki for the forum for my motorcycle (PmWiki):

Chris, I agree about maintenance by a single sys-admin, but here the
club has a lot of potential.  My motorcycle wiki is arguably more
up-to-date than my work one, because it's run by volunteers.  Click on
"All Recent Changes" at the bottom of the motorcycle one to get a feel
for update rate and number of users.

My advice:

1.  Simple package.  No SQL.  Mediawiki and PmWiki are both good, in
my opinion.  TWiki is too project-oriented.  I picked PmWiki because
of the "Cookbook" setup where you can easily install plugins.  Most
wikis have that.  Don't use a dedicated wiki site like pbwiki, because
you need more power than that.

2.  No login/password.  There are good spam block-lists that are
automatically updated, so keep the wiki open.  People will edit more
often.  If spam or vandalism become an issue, then it can be changed
later.  Also, keep good backups of the wiki data.

3.  No WYSIWYG.  The markup is REALLY easy, especially for people who
program in C all the time :-)  Install an equation editing plug-in
like Wikipedia has.  Any decent package will include a LaTeX plugin.

4.  Join forces.  Get DPRG, SRS, Homebrew, etc. to work on a single
site.  Separate sections for each club's competitions and internal
stuff, but make 1 good article on each topic.  If people disagree, no
problem, just add to the article.   That would be an AMAZING resource.


On Feb 2, 2008 1:04 PM,  <dprglist-request at dprg.org> wrote:
> Date: Sat, 2 Feb 2008 10:59:07 -0800 (PST)
> From: Chris Jang <christopher.jang at yahoo.com>
> Subject: Re: [DPRG] wiki
> To: kip at kdream.com, "R. Steven Rainwater" <srainwater at ncc.com>
> Cc: dprglist <dprglist at dprg.org>
> Message-ID: <306096.15399.qm at web44910.mail.sp1.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
> Please excuse me as I do not desire to be rude. I
> wouldn't say anything except that I have seen the full
> lifecycle of wikis and documentation in engineering
> environments over years. It is a big mistake to
> believe the system administrator (literally - only one
> guy!) will take care of everything.
> At first, setting up the system will be cheap. But
> over time, maintenance costs will grow. Many years
> ago, I remember someone telling me that the only
> reason why systems run smoothly is that there are
> people who do such a good job maintaining them that
> you don't know they are doing anything.
> My opinion is to keep things simple. Don't add
> complexity you don't need. Keep it open and flexible
> with simplicity. In general, WYSIWYG document systems
> mean desktop software instead of open and
> collaborative stuff as typical of the web, wikis and
> blogs. I know many people want that - but it will
> probably lead to many problems. Easy to use does not
> necessarily mean WYSIWYG.
> After a while, the biggest problem will be updating
> and maintaining content and links. What tends to
> happen is sort of like the web - people don't bother.
> Then you have the problem of too much information
> (much of it obsolete or wrong) and trying to determine
> what is relevant. Inevitably, this leads to search
> engine data mining which only helps. Efforts like the
> Linux kernel/distributions and Wikipedia are
> exceptions because they have part- to full- time staff
> actively managing content, integration and quality.
> Without this, entropy tends to take over.

More information about the DPRG mailing list