
One of the central repositories of knowledge in the Haskell world is the HaskellWiki (https://wiki.haskell.org). This wiki has been with the Haskell community for years, and contains a wealth of knowledge. Like other services on the haskell.org domain and with haskell.org equipment, ultimate responsibility for maintaining it falls on the Haskell Committee. However, it is a community wiki, and requires care and maintenance and contributions from all of us. The wiki has been, and continues to be, a vital component in the Haskell world. Like any wiki, it is fueled by contributions from many people, and in this sense it is thriving. However, it could use a certain amount of attention and work in three key areas. We are looking for volunteers to step up in these regards, 1) Account Creation Management: Account creation is manual only because spambots otherwise destroy us. It would be worth investigating if a full upgrade and new plugins could help this issue. In the meantime, the responsibility for creating new accounts has fallen on only one person for years. This is not a good situation. We would like to set up a mail alias for wiki admins and extend account creation rights to a range of people. If you would be willing to be one of a team of responders to account creation requests, please write and let us know. 2) Technical and design oversight: Now that we have a new haskell.org homepage, the current wiki frontpage could use a redesign. For that matter, the whole wiki could use a bit of a redesign to bring it into a more modern style. Along with that, it may be the case that additional plugins — such as for typesetting code or equations better — could be quite helpful. It would be good to have a mediawiki admin who wants to help improve the technical capacities of the site, as well as to overhaul its look. Again, if you are interested in taking charge of this, please let us know. 3) Content curation: One issue with a large collection of documents written by different people is the lack of curation. Some pages fall out of date, information is spread across multiple pages instead of collected together, and quality varies greatly. Without a central authority, no one is responsible (or empowered) to fix the situation. There is a balance between keeping things up-to-date and preserving the historic content of the wiki, and without people feeling empowered to make big changes, the tendency will always fall towards the latter. We're looking for people in the community to volunteer to help improve this status quo. The task, generally speaking, is to be responsible for curating and improving the content of the wiki, but that's clearly a vague description with lots of room for individual embellishment. This doesn't need to be a single person either: a team working in a coordinated fashion could be incredibly effective. Once more, depending on response, we’d be happy to designate and empower people to make broader changes on the wiki or to organize a team to do so. If you are interested in this as well, please let us know. Gershom, for the Haskell.org Committee

Gershom wrote:
...the HaskellWiki ...requires care and maintenance and contributions from all of us.
I replied to this in the reddit thread at: http://www.reddit.com/r/haskell/comments/339qxm/haskellcafe_help_wanted_with... Short summary:
1) Account Creation Management
I believe we should migrate off of MediaWiki which would, among other benefits, make ACM unnecessary. But if we don't do that, I volunteer to be on the list of responders for this. But on condition that I don't become the only active responder, which is what ended up happening with community.haskell.org.
2) Technical and design oversight
We should focus that effort on migrating the wiki to a modern markdown-based wiki, such as a github wiki, not on legacy MedaWiki administration.
3) Content curation
I think the real problem here is that much of the community either doesn't know about the wiki or has forgotten about it. If we make the wiki more visible and get more buzz about it, then people will use it. And if they use it, they will also update it. Thanks, Yitz

On Tue, 21 Apr 2015, Yitzchak Gale wrote:
2) Technical and design oversight
We should focus that effort on migrating the wiki to a modern markdown-based wiki, such as a github wiki, not on legacy MedaWiki administration.
I'd much prefer to have a gitit/pandoc/markdown Wiki were I can pull the whole wiki and manipulate it offline. On the other hand we already had a lot of conversions, from the first wiki (what was its name?) to hawiki to haskellwiki. Each time making a lot of content obsolete and it was no fun for me to update each article via the web form. Somewhen in the past MediaWiki for haskellwiki was updated which formatted the markup differently (e.g. linebreaks after inline code). Maybe even these changes were the cause that made people move to their own blogs.

Henning Thielemann wrote:
I'd much prefer to have a gitit/pandoc/markdown Wiki were I can pull the whole wiki and manipulate it offline.
Yes true. I'm not also happy about the idea of putting it under control of GitHub Inc., and being left to their mercy. But that would mean we would need to build and maintain our own site. Not too hard, but someone must do it, and maintain it. And we are back to the problem of Account Creation Management, and dealing with wiki spam ourselves.
On the other hand we already had a lot of conversions, from the first wiki (what was its name?) to hawiki to haskellwiki. Each time making a lot of content obsolete and it was no fun for me to update each article via the web form. Somewhen in the past MediaWiki for haskellwiki was updated which formatted the markup differently (e.g. linebreaks after inline code). Maybe even these changes were the cause that made people move to their own blogs.
Agreed. But what choice have we? Technology moves forward. Leaving the wiki on an aging platform would lead to its death, because it would be too hard to maintain, and because newcomers would not be comfortable with using it. Perhaps the migration would be easier this time due to better tooling. Does pandoc support MediaWiki input? If not, we could write a backend for it.

Yitzchak Gale writes:
And we are back to the problem of Account Creation Management, and dealing with wiki spam ourselves.
Not necessarily. The wiki spam bots tend to target mediawiki wikis as they are low hanging fruit. I'd be interested in helping with a migration to gitit if that's the route we choose. -- Kyle Marek-Spartz

+++ Yitzchak Gale [Apr 21 15 14:02 ]:
Henning Thielemann wrote:
I'd much prefer to have a gitit/pandoc/markdown Wiki were I can pull the whole wiki and manipulate it offline. Perhaps the migration would be easier this time due to better tooling. Does pandoc support MediaWiki input? If not, we could write a backend for it.
Yes, pandoc can convert from MediaWiki (not perfectly, but pretty well). Last time this issue came up (2012), I produced a proof-of-concept gitit clone of the haskellwiki. I've reactivated it here: http://haskellwiki.gitit.net/ (Of course, the last commit was in 2012.) I used a custom script (https://github.com/jgm/hw2gitit/blob/master/hw2gitit.hs) to convert it. At the time, pandoc didn't read MediaWiki, so I parsed the HTML and converted this to Markdown. This worked fairly well. It might probably make more sense now to directly parse the MediaWiki source using pandoc. John

On Tue, 21 Apr 2015 20:21:06 +0200, John MacFarlane
Yes, pandoc can convert from MediaWiki (not perfectly, but pretty well).
Last time this issue came up (2012), I produced a proof-of-concept gitit clone of the haskellwiki. I've reactivated it here: http://haskellwiki.gitit.net/ (Of course, the last commit was in 2012.)
I just looked at the Lojban page; if you compare https://wiki.haskell.org/Lojban with http://haskellwiki.gitit.net/Lojban you can see that the gitit page needs a lot of manual labor to get it right. Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

+++ Henk-Jan van Tuyl [Apr 22 15 00:32 ]:
I just looked at the Lojban page; if you compare https://wiki.haskell.org/Lojban with http://haskellwiki.gitit.net/Lojban you can see that the gitit page needs a lot of manual labor to get it right.
Sure. I didn't put enough time into it to get a perfect automated translation. Part of the problem here is that pandoc's internal model of tables contains neither colspans nor rowspans, nor borders, so lots of information gets lost in translation in a table-heavy page like this. The script could be improved to pass through some tables as raw HTML. And we might have better results doing it again with pandoc's mediawiki reader (though we'd no doubt also find bugs in the reader that could be fixed).
participants (6)
-
Gershom B
-
Henk-Jan van Tuyl
-
Henning Thielemann
-
John MacFarlane
-
Kyle Marek-Spartz
-
Yitzchak Gale