Re: Straw poll on wiki replacement

--000000000000039d2c05a924fee4
Content-Type: text/plain; charset="UTF-8"

>
>
>
> 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.

--000000000000039d2c05a924fee4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><br><br>
I agree that a live-editable wiki can be more user-friendly, but I (and <br=
>
several others) find working with the current wiki to be a pretty awful <br=
>
experience, especially for longer-form documents.=C2=A0 I think this is eve=
n <br>
more true for less-experienced folks.<br>
<br>
IMO a best-of-both-worlds would be to use a wiki that&#39;s backed by a git=
 <br>
repo and can synchronize in both directions -- Dokuwiki has a plugin <br>
that should be able to do this.<br><br></blockquote><div><br></div><div>Hav=
ing used the wiki a lot, I find that there are several things that are impo=
rtant to me:</div><div>1) preview: I can&#39;t/don&#39;t want to remember t=
he odd syntax, thus I want to be able to preview the result (it doesn&#39;t=
 have to be exact, just check the syntax and see if it looks right)</div><d=
iv>2) Easy edit/submit in the browser: I don&#39;t really want to fire a te=
xt editor, find the file, edit, git commit; it&#39;s much more practical=C2=
=A0if I am viewing the wiki page, click edit, edit, click submit</div><div>=
Now here are things that are not necessarily important:</div><div>3) real-t=
ime: it is completely fine if I submit my change and it only appears later =
(as long as I can preview)</div><div>4) WYSIWYG: it&#39;s usually more trou=
ble than it helps</div><div>For example, if the submit process makes a git =
commit that=C2=A0triggers a hook that regenerates a html then it&#39;s an a=
cceptable workflow.</div><div>I am afraid that a workflow that requires a g=
it account will prevent contributions from some people.</div><div>That bein=
g said, you are the one making the change so it&#39;s reasonable to take in=
to account the amount of work it takes.</div><div>=C2=A0</div></div></div>

--000000000000039d2c05a924fee4--