Re: Straw poll on wiki replacement

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 27, 2020 at 09:43:39PM -0400, Jason Arthur Taylor wrote:
> No, IMO they are not the same at all.=20

The editing experience is different, sure.

But what no matter what solution is chosen, it will require a roughly=20
similar amount of effort to set up, migrate, and integrate. [1]

So what I am wondering is if the historical goals fulfilled by the wiki=20
are still relevant for the rockbox today, because different goals lend=20
themselves to different approaches.

> after a while you've written a real masterpiece.  The instant you=20
> cannot get that live feedback and see a "your edit is awaiting=20
> approval" (or the equivalent awaiting an unknown amount of time for an=20
> auto-update) it's a no-go feeling like "That's the last time I ever=20
> help those aholes out."

In the past four years, there haven't even been 100 non-administrative=20
changes made to the wiki.  About a third were made in the past year, and=20
of those, all but one were made by folks who already have commit rights=20
to the main repo.

It's worth mentioning that new user registrations have been disabled on=20
Rockbox's wiki since November 2017, because spammers and other bots made=20
a right mess of things -- and if the server logs (and the DoSes that led=20
me to start this thread) are to believed, are still actively trying.

So the way things are today, drive-by contributions are literally=20
impossible.  One has to contact me to get an account, and even if you=20
have one, the user experience is still quite poor due to abysmal=20
performance, baroque native foswiki synax, and a wysiwyg editor that had=20
to be disabled because it was silently losing edits (on top of making=20
performance even more abysmal..)

These days one sees far more "helpful" activity and knowledge recording=20
on the forums.

So yes, I question if a live-editable wiki is the right approach going=20
forward.  It may make more sense to prioritize the use cases of active=20
developers, as those benefits are easier to quantify than those of folks=20
that won't meanigfully contribute anyway.

(Given the current barriers to contributing to the exsting wiki, I=20
 strongly believe that no matter what approach gets taken, it will be a=20
 net improvement, for everyone)

I agree that a live-editable wiki can be more user-friendly, but I (and=20
several others) find working with the current wiki to be a pretty awful=20
experience, especially for longer-form documents.  I think this is even=20
more true for less-experienced folks.

IMO a best-of-both-worlds would be to use a wiki that's backed by a git=20
repo and can synchronize in both directions -- Dokuwiki has a plugin=20
that should be able to do this.

> No masterpieces, only half-butted cruddy lame contributions with=20
> spelling errors etc.  That's exactly what non-live editing is not=20
> asking but more begging for.

Well, if a static site generator is the approach taken, it will be=20
possible to competely build and locally test things.  With nikola, a=20
single page update tyically takes less than a second, including=20
launching a web browser to view it.  This is a lot faster than our=20
current wiki, even after the things I've done to try and make it suck=20
less.

[1] moving to foswiki 2.x would be the least amount of effort, but=20
    there's no guarantee it will actually resolve the problems that are=20
    making a migration necessary to begin with.  I don't want to have to=20
    do this twice.

 - Solomon
--=20
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE3H5Sx9DyiyB5hnENrGLLO/XVulEFAl74DhIACgkQrGLLO/XV
ulGPog//Z7cjqAnjul/6RzqXMT+M12qlpa2Z46G4naSjGUAX3wBWMUc74zYChplG
IoRMLwPW6+j6Midh0Fl66yEgAE7TDowhDre3i1XK3LjzHFsTcVxSwFpBsrl0YyJV
tCEi1Udai49TEm4io3eytko8/OZ2WLAK3BBDq57tauYRuv99DmImTtWUZeVe9XBL
XgGq4SkmMkEtHdirpvYT2QMZgTorL9rXalTh7ztyO52DeYsLb2wTK+cCpbCiMMAj
V50sKht01x0gSNkJpg1zzMNezlp+5uqZ2oG9/WfJ1CZE8CqVOdoLGcFDUpJXdlJV
Oi/RC5GTo8+MQK7A4py/sVhQtJzHTu8Lp5IZViBSNtcqwN9+bXysBY+XW0m1bwMC
vZHsRSG/UOlgvIrsePfiUcUsrn0uxMLg/aAEVHQf6uX0K5TQwOSL8jToisB+9ATi
5FEKRGM00s7Qi892xNUTb4sdCVJTrLy+DMipGv/maDlzdRqEvHVivTBpqj2O+Kdu
FxqBqABwcDko+2LY364Ph66n6ysTVFY9VBLv9F8mmXjJjxrpc7YHi5tkE1xFPBkP
Tg+o6vwM9yz1m4MjkOuJPc4uyH6Gy5W8pDSyDfmWC/CCFfrL8hli+yGbFp7Z2TL1
je5GYkfZByMFO1OzccviMSZXRLEs4vJi8ScBP1rmbVqZU1oD6oE=
=g4HP
-----END PGP SIGNATURE-----

--ikeVEW9yuYc//A+q--