On 6/13/16 8:02 AM, 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
  • 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.

I am not against staying with Mediawiki, however the obvious shortcoming is lack of git integration. This is not a deal-killer for me, but it is a negative.

...

• use wiki on GitHub

  • it's for free with the repository
  • the wiki is quite limited (no categories, no search, ...)
  • having wiki content as Git repository is great

The wiki features are rather limited here, on the other side we really did not use much of them anyway...

We can work around the lack of features, since there aren't many we use, but the limitations with how data is displayed (for instance, only about 70% of the page is used for actual wiki data) make this difficult. I'm not fond of Github wiki and only consider it because it's easy and has great git integration.

...

• 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
  • preferably use GitHub authentication, so that we do not have to

maintain another list of users

• one of possible tools to do that is ikiwiki

Anybody has experience with ikiwiki or other wiki engines?

I've been looking in to ikiwiki, actually. It has git integration, which I think is the feature we're most looking for. The underlying language is Markdown, which we're rather familiar with. However, the rendered pages are a bit ugly.

You can quickly clone the repository with

git clone git://ikiwiki.branchable.com/

to view the demo wiki. Look in the ./doc/ folder for the actual wiki content. The rendered pages are visible at https://ikiwiki.info/

They appear to allow authentication using accounts from OpenID, Yahoo, WordPress, and more; in fact there's a page with discussion about their plans/roadmap for authentication[1]. However, it seems the path to OpenID is a bumpy one[2].

I'm more excited about Gitit[3][4]. Gitit has a git backend (or darcs or mercurial), pages are able to be written in about ten different flavors including Markdown and reStructuredText (anything understood by Pandoc), and it looks like Mediawiki (which isn't a big goal for me, but it's a common and easy-to-use structure). The default/suggested authentication seems to be GitHub OAuth. Downsides about it: their own wiki is a mess (broken links to the Install guide and README, not a whole lot of information in general), development seems slow (there are plenty of Issues and Pull Requests without a comment, last commit was 12 days ago), and it's written in Haskell (with which I'm not very familiar) -- but this is my favorite right now. This random guy[5] has similar goals to ours and settled on Gitit.

Finally, there is Realms[6][7] and Gollum[8]. Realms is built on Gollum, uses GitHub OAuth, and it looks really modern. However, the documentation seems really weak and it looks like they haven't published an actual release yet (though running their git 'master' branch seems to work okay). Realms is very interesting to me, but with my cursory examination it doesn't feel like production-ready software. I could be wrong. Gollum is apparently what GitHub is using for their wiki engine. I don't have a good sense of what Gollum is like, because as near as I can tell they don't have a demo and I haven't gotten around to installing it on my test machine. There's a fork to add OAuth support[9].

For looks, I think Realms acts best; it's modern and slick and easy to use. However, Gitit seems much more established and reliable.

1 - https://ikiwiki.info/todo/emailauth/ 2 - https://ikiwiki.info/plugins/openid/troubleshooting/ 3 - http://gitit.net/ 4 - https://github.com/jgm/gitit 5 - http://nathantypanski.com/blog/2014-07-09-personal-wiki.html 6 - http://realms.io/ 7 - https://github.com/scragg0x/realms-wiki 8 - https://github.com/gollum/gollum 9 - https://github.com/aleiphoenix/gollum-with-auth

Sebastian, I'm glad to hear from you.

On 6/13/16 11:54 AM, Sebastian Mendel wrote:

I am not sure what type of git integration you are looking for, but I like Atlassian Confluence: https://de.atlassian.com/software/views/open-source-license-request

I have not used it yet. Do you mind sharing briefly what you like about it? Does it allow for offline editing like we can do using the github wiki?

Isaac Bennetch <bennetch@gmail.com mailto:bennetch@gmail.com> schrieb am Mo., 13. Juni 2016, 15:08:

On 6/13/16 8:02 AM, 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
<http://wiki.phpmyadmin.net> back to usable state
>>
>>   - we will have to handle security fixes and so on
>>   - 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.

I am not against staying with Mediawiki, however the obvious shortcoming
is lack of git integration. This is not a deal-killer for me, but it is
a negative.

>> * use wiki on GitHub
>>
>>   - it's for free with the repository
>>   - the wiki is quite limited (no categories, no search, ...)
>>   - having wiki content as Git repository is great
>
> The wiki features are rather limited here, on the other side we really
> did not use much of them anyway...

We can work around the lack of features, since there aren't many we use,
but the limitations with how data is displayed (for instance, only about
70% of the page is used for actual wiki data) make this difficult. I'm
not fond of Github wiki and only consider it because it's easy and has
great git integration.

>> * use other solution for wiki.phpmyadmin.net
<http://wiki.phpmyadmin.net>
>>
>>   - we could use cleaned up wiki content which is currently used
on GitHub
>>   - I'd really prefer something with Git integration
>>   - preferably use GitHub authentication, so that we do not have to
>> maintain another list of users
>>   - one of possible tools to do that is ikiwiki
>
> Anybody has experience with ikiwiki or other wiki engines?

I've been looking in to ikiwiki, actually. It has git integration, which
I think is the feature we're most looking for. The underlying language
is Markdown, which we're rather familiar with. However, the rendered
pages are a bit ugly.

You can quickly clone the repository with
> git clone git://ikiwiki.branchable.com/
<http://ikiwiki.branchable.com/>
to view the demo wiki. Look in the ./doc/ folder for the actual wiki
content. The rendered pages are visible at https://ikiwiki.info/

They appear to allow authentication using accounts from OpenID, Yahoo,
WordPress, and more; in fact there's a page with discussion about their
plans/roadmap for authentication[1]. However, it seems the path to
OpenID is a bumpy one[2].

I'm more excited about Gitit[3][4]. Gitit has a git backend (or darcs or
mercurial), pages are able to be written in about ten different flavors
including Markdown and reStructuredText (anything understood by Pandoc),
and it looks like Mediawiki (which isn't a big goal for me, but it's a
common and easy-to-use structure). The default/suggested authentication
seems to be GitHub OAuth. Downsides about it: their own wiki is a mess
(broken links to the Install guide and README, not a whole lot of
information in general), development seems slow (there are plenty of
Issues and Pull Requests without a comment, last commit was 12 days
ago), and it's written in Haskell (with which I'm not very familiar) --
but this is my favorite right now. This random guy[5] has similar goals
to ours and settled on Gitit.

Finally, there is Realms[6][7] and Gollum[8]. Realms is built on Gollum,
uses GitHub OAuth, and it looks really modern. However, the
documentation seems really weak and it looks like they haven't published
an actual release yet (though running their git 'master' branch seems to
work okay). Realms is very interesting to me, but with my cursory
examination it doesn't feel like production-ready software. I could be
wrong. Gollum is apparently what GitHub is using for their wiki engine.
I don't have a good sense of what Gollum is like, because as near as I
can tell they don't have a demo and I haven't gotten around to
installing it on my test machine. There's a fork to add OAuth
support[9].

For looks, I think Realms acts best; it's modern and slick and easy to
use. However, Gitit seems much more established and reliable.


1 - https://ikiwiki.info/todo/emailauth/
2 - https://ikiwiki.info/plugins/openid/troubleshooting/
3 - http://gitit.net/
4 - https://github.com/jgm/gitit
5 - http://nathantypanski.com/blog/2014-07-09-personal-wiki.html
6 - http://realms.io/
7 - https://github.com/scragg0x/realms-wiki
8 - https://github.com/gollum/gollum
9 - https://github.com/aleiphoenix/gollum-with-auth

_______________________________________________
Developers mailing list
Developers@phpmyadmin.net <mailto:Developers@phpmyadmin.net>
https://lists.phpmyadmin.net/mailman/listinfo/developers

---

Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

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@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers

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.