From: "R. W. Rodolico" <rodo@dailydata.net>
To: documentation@lists.ipfire.org
Subject: Re: Replacement for Dokuwiki
Date: Tue, 17 Feb 2015 15:26:19 -0600 [thread overview]
Message-ID: <54E3B1FB.3000902@dailydata.net> (raw)
In-Reply-To: <1424188170.17826.120.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 6832 bytes --]
On 02/17/2015 09:49 AM, Michael Tremer wrote:
> 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.
I'd rather find something else simply because I want more people to be
comfortable with using the tool (writing/editing). Requiring that
someone use the markup language used by DokuWiki reduces the comfort
level many people have with writing anything. I know that I was
initially put off by this.
What we do not need is more articles written by Michael or Arne. You
guys need to be focusing on the Next Big Release. I want Brandy (my
tech) or even my sister (who has no ideas about it) to be able to edit
without feeling they have to spend time learning a new system.
>
>> 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.
Ok, let's add "integration with outside database for authentication" to
the list. I'm thinking we could just export a simple view if the package
we use does not have the ability to authenticate against a different API.
>
>> * Multi-language capable
>
> Yes.
>
>> Nice to have
>> * WYSIWYG editor
>
> I personally prefer writing the wiki language directly.
I disagree. Yes, I generally hit the "Edit Source" button when I'm in a
WYSIWYG and write in HTML. However, we want documenters, and the fewer
limits we put on who can write/edit documents, the more people we can
get involved.
Actually, many times I write a document for our wiki
(wiki.linuxservertech.com) as plain text, then put my HTML markup on it,
then import it directly into the wiki as HTML. However, some of the
articles are written by my employees who are technically competent but
really not comfortable with HTML.
I am afraid that without a WYSIWYG, we are decreasing the number of
people who are willing to write their notes. I have 3-4 articles I have
written, but not put into the system due to the fact that I'll need to
translate them to the DokuWiki markup language. It is not intuitive to me.
>
>> * 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.
>
With a printed document, PDF or epub, you can make notes, put in book
marks, and read when you have no internet connection. PLUS, a lot of old
guys like me have a few decades of reading "dead trees" (English slang
for paper books), and only a couple of decades of reading online, unlike
you younger ones who probably were using tablets in grade school.
I use ISPConfig and Zabbix, and in both cases, have downloaded (and paid
for in one case) the document so I can read it whenever I please.
>> * 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.
I agree. If you want to ship me a copy of the current wiki, I'll put it
someplace and either play with it myself or put Brandy and Cait on it.
Who knows, all of my objections to it may disappear once we get them
working on it.
>
> -Michael
>
>>
>> Rod
>>
--
"Rod" Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net
next prev parent reply other threads:[~2015-02-17 21:26 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
2015-02-17 21:26 ` R. W. Rodolico [this message]
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=54E3B1FB.3000902@dailydata.net \
--to=rodo@dailydata.net \
--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