On 6/13/16 12:19 PM, Alec Teal wrote:
Hi,
I'll be blunt to save time, I don't mean to come across rather abrasive.
Thanks for chiming in with your thoughts.
On 13/06/16 13:02, Michal Čihař wrote:
Hi
this topic was discussed quite a lot on the mailing list, but still I'd
like to hear feedback which solution do you prefer.
Dne 8.6.2016 v 13:33 Michal Čihař napsal(a):
> Possible solutions:
>
> * bring Mediawiki on
wiki.phpmyadmin.net back to usable state
>
> - we will have to handle security fixes and so on
Less of a burden than it
sounds. But also you might not have to, you've
already gone for years without updating, there's no reason not to keep
with that style, just take a backup every now and then ;-) There is no
reason to have the very latest thing of everything all the time.
I think the potential problem here is that we have relied on the Debian
packaged versions, which provide security stability but haven't brought
us the new features you suggest to help with fighting spam. Getting off
of the packaged version means some team member will have to monitor for
and apply security updates at least, and occasional feature releases,
too, which is not an overwhelming idea but is added work and responsibility.
- need some way to prevent vandalism
Alec
Teal offered help with this. The best approach here is probably to
start with updating latest Mediawiki and avoid using Debian packages
completely.
This really isn't as nasty as it sounds, each version of MediaWiki
is
archived and contains a script to bring it from one version to the next,
the worse case is it's just a chunk of work running each version,
realistically however the update scripts probably go back a few versions
so you can do it bigger steps.
Preventing vandalism is also trivial.
> * use wiki on GitHub
>
> - it's for free with the repository
I for one trust GitHub
indefinitely.
> - the wiki is quite limited (no
categories, no search, ...
> - having wiki content as Git repository is great
Dubious. I am not against
the "having local copies" idea there (I hate
"the cloud"!) but it's a wiki not a readme, you wouldn't bundle it in
a
release so all it does is clutter the repo you lot and few others use.
Wikis for projects tend to be things one references when stuck,
searching, display with markup; so forth are all very important in that,
local copies.... yeah okay maybe you can search but they're certainly
not easy to read and follow links and such.
I think maybe we haven't been clear about the desire for using git here;
it's to make it easier for the developers to manage the wiki offline and
in a text editor of our preference. Mediawiki used to allow external
editors so I could edit an article in, say, vim or emacs, but even that
seems to have been depreciated some time ago. We don't see any need for
end users to check out the wiki, or to have many copies floating around,
the (very selfish) desire is to make it easier for those of us who
create and manage the content. One way to make it easier is to do so
with tools we normally use, such as our own text editors and even being
able to copy files directly in to the wiki (for instance, using Github
wiki, when I create the log of minutes from the IRC meetings, I just cp
my IRC client log to the wiki repository, then run git add and git
commit. With mediawiki I had to open the log in my text editor, select
all, copy, open the proper page in the wiki, click to edit the page,
paste the text, and so on. It's just more steps).
The wiki
features are rather limited here, on the other side we really
did not use much of them anyway...
Imagine you wiped after using the toilet with
sandpaper, but you didn't
know about toilet paper, it'd be horrible right? Imagine then that you
moved to somewhere else which had plenty of sandpaper; you'd go on happy
thinking "this sandpaper is just as good as the other sandpaper I was
using before" not realising (STILL!) that there's actually a kind of
paper that doesn't cause bleeding made for the task.
You can say "they're sandpaper is about as good as we're currently
using" and go on wiping that way. Ignorance is bliss.
I apologise for sounding like someone who loves MediaWiki. I hope you
see my point.
You sound more like someone who hates Github wiki and wants to help
improve the phpMyAdmin wiki overall. Nothing you've said is that
unreasonable or outlandish, and I want something that's good for end
users as well as developers (even though the wiki is mostly for
developers these days anyway).
I would like to say I do greatly appreciate your interest in helping to
improve this area.
> * use
other solution for
wiki.phpmyadmin.net
>
> - we could use cleaned up wiki content which is currently used on
> GitHub
> - I'd really prefer something with Git integration
Why? In any wiki
system I can think of the pages are already version
controlled and because it's centralised it's easy to manage clashes
without knowledge of merging diffs. This is a crucial thing for
Wikipedia as many (most) of its content comes from people not from a
mathematics or computer science background; so simplicity is paramount.
With this project such simplicity is obviously not required, but why not
take it anyway.
> - preferably use GitHub authentication, so
that we do not have to
> maintain another list of users
There's a bundled rename-user extension
with Mediawiki, I think going
further and using github (if they even provide such an API) is a waste
of effort as all people have to do (once) is put in a username, an email
address and a password twice.
Github does allow authentication through OAuth against existing Github
users, as do many other services such as Facebook, Twitter, Google,
Flickr, Spotify, Stack Exchange, and Wordpress.
I don't have a strong feeling about this; it's something Michal brought
up with regards to fighting spam and I think you've brought up some
other good methods within Mediawiki for fighting spam. On one hand, I
like the trend of using OAuth for single-sign-on (I hate having to make
new accounts for every little forum or wiki) but on the other hand, some
users might not have Github (or other OAuth) accounts or might not trust
this authentication method, so we should have some local-user fallback
which negates the purpose of spamfighting in the first place. So that's
a tough point.
- one of possible tools to do that is ikiwiki
Anybody has experience with ikiwiki or other wiki engines?
No. I sound like a proper zealot; once again, very sorry.
Thanks for sharing your thoughts.