[phpMyAdmin Developers] Wiki

[Alec Teal]

Hi,

I'll be blunt to save time, I don't mean to come across rather abrasive.

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.
>>    - 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.
> 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.
>
>> * 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.
>>    - 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.
> _______________________________________________
> Developers mailing list
> Developers at phpmyadmin.net
> https://lists.phpmyadmin.net/mailman/listinfo/developers