I'll second the -1 on Confluence. No section editing was a big beef by our users. Our MediaWiki based wiki - with added WYSIWYG editir and LDAP authentication - grew faster and more widely receieved, despite a top down push for the Confluence one.
----- Original Message ---- > From: Daniel Rich <[email protected]> > To: Nick Silkey <[email protected]> > Cc: David Parter <[email protected]>; [email protected] > Sent: Thu, April 29, 2010 8:54:25 AM > Subject: Re: [lopsa-tech] help us pick a wiki to support for our faculty and > students > > I'll second dokuwiki, although it does store everything in text files. With > the right plugins you can make it do all sorts of things, including adding a > wysiwyg editor, mirroring the format of other wikis (such as mediawiki), and > integrating with google calendars. I've been using it for the past year > or so with the non-profit theatre I webmaster for, and we've had great luck > with it. I looked at MediaWiki, TWiki, Oddmuse (we used it at work in > the past), and a few other even lesser-known wikis before settling on > dokuwiki. That said, I'm surprised by the recommendations for > Confluence. We use it at work, and pretty-much universally hate > it. There are all sorts of reasons, ranging from unstable code to > performance issues to being restricted to a flat page name paradigm within a > given namespace (i.e. if you have an "SysAdmin" name space, you can have one > and only one page titled "Monitoring"). . Take a look at > wikimatrix.org, it's a great way to compare a lot of the wikis out there > based on the features you are looking for. Nick Silkey > wrote: > > The answer to all four tenets is Confluence. Federates > nicely with how > things work in higher-ed. > >> On Apr 27, > 2010 3:57 PM, "David Parter" < > href="mailto:[email protected]";>[email protected] >> > <mailto: > href="mailto:[email protected]";>[email protected]>> > wrote: >> >> >> I know, there are a million to choose > from. >> >> Here's the > situation: >> >> Our faculty (and students) want wikis. > And they would like us to >> support their wikis. They haven't > exactly said what that means, but we >> can at least define a > plausible service offering, and see if that >> > works. >> >> Currently we have a ton of different wikis, > all in a state of >> disrepair/not being maintained or secure, > installed by individual >> faculty and students. We want to do > better. We *need* to do better. >> >> Some things we already > know: >> >> 1) We think we want a wiki that stores content in > a database, because it >> decouples the content from the wiki > code, makes migration and >> upgrades easier, and doesn't rely > on the unix file system and which >> uid the web server runs as > for security. But that maybe a misguided >> > idea... >> >> 2) There needs to be some kind of authentication > and authorization. This >> is where it gets hard -- we don't > have to solve every problem with >> the same tool, but some of > our users just need a handful of wiki >> users, so built-in > authentication & authorization is ok. some >> probably want > to leverage our existing authentication (for example, >> to > allow all their students' access) but that may be ok to defer to > a >> different solution. >> >> All > probably want both authenticated and anonymous users to be > able >> to read the wiki (but not post). >> >> > 3) If we have to maintain/support the wiki code, we'd like it to > be >> secure and reasonable to manage. >> >> > 4) they don't all have to be in the same wiki instance, we can > run >> multiple instances >> >> Any ideas? I > realize this is not an entirely well-formed request, the >> staff > person who has been looking into this is rather frustrated, so I >> > thought I'd get some fresh ideas. >> >> > thanks, >> >> --david >> >> ps: the > same exact questions will be asked about "blogs", because some >> > people think a wiki is the way to maintain a web site, others prefer >> > blogs... >> _______________________________________________ >> > Tech mailing list >> > href="mailto:[email protected]";>[email protected] <mailto: > ymailto="mailto:[email protected]"; > href="mailto:[email protected]";>[email protected]> >> > href="http://lopsa.org/cgi-bin/mailman/listinfo/tech"; target=_blank > >http://lopsa.org/cgi-bin/mailman/listinfo/tech >> This list > provided by the League of Professional System Administrators >> > http://lopsa.org/ > > ------------------------------------------------------------------------ > > > _______________________________________________ > Tech mailing > list > > href="mailto:[email protected]";>[email protected] > > href="http://lopsa.org/cgi-bin/mailman/listinfo/tech"; target=_blank > >http://lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided > by the League of Professional System Administrators > > href="http://lopsa.org/"; target=_blank >http://lopsa.org/ > > -- Dan Rich < > href="mailto:[email protected]";>[email protected]> | > href="http://www.employees.org/~drich/"; target=_blank > >http://www.employees.org/~drich/ > | > "Step up to red alert!" "Are you sure, sir? > > | It means changing the bulb in the sign..." > > | - Red Dwarf > (BBC) _______________________________________________ Tech mailing > list > href="mailto:[email protected]";>[email protected] > href="http://lopsa.org/cgi-bin/mailman/listinfo/tech"; target=_blank > >http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the > League of Professional System Administrators > target=_blank >http://lopsa.org/ _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
