>
>
>
> I agree that a live-editable wiki can be more user-friendly, but I (and
> several others) find working with the current wiki to be a pretty awful
> experience, especially for longer-form documents. I think this is even
> more true for less-experienced folks.
>
> IMO a best-of-both-worlds would be to use a wiki that's backed by a git
> repo and can synchronize in both directions -- Dokuwiki has a plugin
> that should be able to do this.
>
>
Having used the wiki a lot, I find that there are several things that are
important to me:
1) preview: I can't/don't want to remember the odd syntax, thus I want to
be able to preview the result (it doesn't have to be exact, just check the
syntax and see if it looks right)
2) Easy edit/submit in the browser: I don't really want to fire a text
editor, find the file, edit, git commit; it's much more practical if I am
viewing the wiki page, click edit, edit, click submit
Now here are things that are not necessarily important:
3) real-time: it is completely fine if I submit my change and it only
appears later (as long as I can preview)
4) WYSIWYG: it's usually more trouble than it helps
For example, if the submit process makes a git commit that triggers a hook
that regenerates a html then it's an acceptable workflow.
I am afraid that a workflow that requires a git account will prevent
contributions from some people.
That being said, you are the one making the change so it's reasonable to
take into account the amount of work it takes.
