public inbox for documentation@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: documentation@lists.ipfire.org
Subject: Re: Replacement for Dokuwiki
Date: Tue, 17 Feb 2015 16:49:30 +0100	[thread overview]
Message-ID: <1424188170.17826.120.camel@ipfire.org> (raw)
In-Reply-To: <54E308D5.4060007@dailydata.net>

[-- Attachment #1: Type: text/plain, Size: 4136 bytes --]

Hi Rod,

thanks for offering to work on this.

On Tue, 2015-02-17 at 03:24 -0600, R. W. Rodolico wrote:
> I have a tech who is wanting additional hours, and she is a fairly good
> researcher. I'd like to put her on the project of finding a replacement
> for Dokuwiki. However, before I do, I'd really like to know what we want
> it to do.
> 
> Here are my thoughts. Please feel free to say "yes" or "no" to anything.
> My feelings will not be hurt. But, I do want Brandy (the tech) to have a
> clear cut set of requirements before she puts in the time.

I am not too sure if there is any other good alternative that is
suitable for our needs but I am sure that we should have a look every
once in a while to see what else is out there.

Years ago we use Mediawiki which is great if you have many single pages
with one topic on them. We changed to dokuwiki back then because it
comes with a sort of directory structure which is very very great for
documentation. I have not found any other wiki software that has some
similar thing and I guess that this is the main feature that we need:
structure.

As mentioned Mediawiki doesn't have that and some other popular wiki
softwares that I checked out very more similar to the Mediawiki concept
than to the dokuwiki concept.

Maybe it is the best solution to stick with dokuwiki but enhance its
functionality with many plugins. There are lots of them but I didn't
have the time to check them out.

> Requirements:
> * HTML

yes :)

> * Multilevel tree menu

Yes. Structure is very important for us.

> * Keyword searchable

Dokuwiki's search is not the best. If you know the right keyword for
what you are searching for you will find everything. This does simply
not work in practice because if you are searching for something you
don't always know what you are exactly searching for.

Dokuwiki can be extended by using a software called Sphinx to improve
search results. Maybe it is worth trying that.

> * Full text searchable

Yes.

> * User management

We are using the forum's database to authenticate users. Dokuwiki itself
only comes with some very basic user management and we don't need
anything special here. Just authenticate users against a database and
have some groups to grant rights to some internal pages.

We decided using the forum's database so that users don't need to create
many accounts.

> * Multi-language capable

Yes.

> Nice to have
> * WYSIWYG editor

I personally prefer writing the wiki language directly.

> * Export all or part to PDF or HTML

Printing wiki pages is very common (apparently). I don't know why people
do this but having some option to export to PDF would be nice. It is
just a very low priority kind of thing.

> * Comments on articles (similar to php.net)

Nice idea. I am usually against the commenting thing on the Internet.
Mostly because this always leads to endless discussions about the least
important things. Maybe it is better to encourage users to edit an
article right away instead of getting lots of comments saying "this is
wrong/broken. please someone fix this paragraph".

We have the mailing list for discussions. Nobody uses it though.

> Anyway, anyone want to add/remove/modify the above? Also, does anyone
> have a favorite package I should have her look into?

I would like to add that the software should be easy to host. A huge
rails application that consumes loads of RAM won't work. I also want
really good performance from the wiki. Loading an article should not
take a second.

And last of all I wanted to state that Dokuwiki is not that bad. It
works very well for us. It is just some stripped-down software that
maybe be need to customize a bit. There are so many plugins that could
help us with that. It is also written in PHP and enhancing it with own
plugins is really easy.

If you want to create an installation to play with I could zip you the
data directory and send it to you. So you will have all the data and
maybe that is a great point to start with...

Enhancing the current wiki would also save us lots of work instead of
migrating the whole thing. History needs to be kept.

-Michael

> 
> Rod
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-02-17 15:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17  9:24 R. W. Rodolico
2015-02-17 15:49 ` Michael Tremer [this message]
2015-02-17 21:26   ` R. W. Rodolico
2015-02-20  0:52     ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1424188170.17826.120.camel@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=documentation@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox