RE: [Haskell] Making Haskell more open
Dear Haskell folk, A month or so ago I sent a message inviting suggestions about how to make Haskell more open, and in particular how to make it easier for Haskell users to contribute. There was quite a bit of traffic for a while, which has died down now. Here's a quick summary of what I learned. * Gour suggested using a Content Management System (e.g. Drupal http://drupal.org/) for haskell.org's front page. To me this sounds like a good plan. (e.g. "Drupal is software that allows an individual or a community of users to easily publish, manage and organize a great variety of content on a website." That sounds like what we are trying to do.) A CMS may offer more than we need, but it'd be more open and dynamic than the current setup. * There were suggestions of newsgroups and web forums. Different people seem to like different things. That's ok -- maybe a good content management system would support a lot of things, and people could choose. * Some people suggested using MediaWiki instead of MoinMoin for Hawiki. I have no idea about the issues here. Maybe it's just a matter of taste. * We don't have a plausible way of annotating GHC's user manual. One suggestion is a tree of Wiki pages, each linked from the corresponding section of the manual. We'd need an automated way to generate such a tree, and it's not clear what to do when moving from one release of GHC to the next. * #haskell has way more simultaneous logins than I realised. Good stuff! My sense is that the main action item is how to make haskell.org a better web site (This is with no disrespect to John and Olaf, who have done a great job. But I know they would be only too happy to share the load.) I'm no expert, but it sounds to me as if some content management system might well be just the thing. However, the thread didn't have many concrete offers of help. I'm hoping that is perhaps because you're all too shy to put yourselves forward! So: - is a CMS a plausible way forward? - which one? - is anyone, or small group, willing to set one up and look after it? Maybe not, in which case things are not at all terrible. But I thought it was worth asking. Simon PS: GHC is now using Trac as its bug tracker, and has its own Wiki as well. Please improve it! (Anyone can edit.) http://hackage.haskell.org/trac/ghc
Simon Peyton-Jones wrote:
* We don't have a plausible way of annotating GHC's user manual. One suggestion is a tree of Wiki pages, each linked from the corresponding section of the manual. We'd need an automated way to generate such a tree, and it's not clear what to do when moving from one release of GHC to the next.
I don't know if it's worth looking at W3C's Annotea [1]. Last time I looked, it needed a special client (e.g. Amaya web browser [2]), but I don't know if anyone's thought about using a gateway to allow annotation/viewing using a regular web client (e.g. as Wikis do for web pages); e.g. [3]? #g -- [1] http://www.w3.org/2001/Annotea/ [2] http://www.w3.org/Amaya/ [3] http://ncyoung.com/entry/106 -- Graham Klyne For email: http://www.ninebynine.org/#Contact
"Simon Peyton-Jones" <simonpj@microsoft.com> writes:
* Gour suggested using a Content Management System (e.g. Drupal http://drupal.org/) for haskell.org's front page.
I'm not familiar with Drupal, but at least EZ publish allows users to convert pages to PDF - could be quite useful for documentation etc.
* There were suggestions of newsgroups and web forums. Different people seem to like different things. That's ok -- maybe a good content management system would support a lot of things, and people could choose.
I'm not sure you really want to integrate all information channels into one; you are likely to end up with the least common denominator. The GHC manual, the wiki, this list, and the IRC channel serve different purposes, and those purposes are best served through different media.
* Some people suggested using MediaWiki instead of MoinMoin for Hawiki. I have no idea about the issues here. Maybe it's just a matter of taste.
Matter of taste, and ease of administration. While my tastes go in the MW direction, I'm also in favor of docracy -- the doers get to decide. My main problem with the wiki is the form of the pages. Many of them (in particular the newbie pages you wanted us to work on :-) seem to try to emulate web forums, consisting of a string of questions, answers, elaborations of answers, more questions etc, all signed by the contributor. On e.g. Wikipedia, articles are neutral pieces of text, and it's very easy to improve it in any way. In Hawiki, I feel there is a large degree of ownership attached to each paragraph, and it makes me a bit wary of modifying it. Is it okay if I rewrite the page? Should I keep the signatures? So while Wikipedia feels like a commons, Hawiki much less so, and the net result is more often than not that I just leave it.
* We don't have a plausible way of annotating GHC's user manual. One suggestion is a tree of Wiki pages, each linked from the corresponding section of the manual.
One easy way would be to simply provide a link to a corresponding wiki page - as the wiki will let you create the page if it doesn't exist already. It would be nice to have some way of displaying whether there is any actual wiki content, of course, and perhaps one would like to have different kinds of associated materials (Q&A, examples, theoretical discourse, etc). -k -- If I haven't seen further, it is by standing in the footprints of giants
On Tuesday 20 December 2005 11:13, Ketil Malde wrote:
On e.g. Wikipedia, articles are neutral pieces of text, and it's very easy to improve it in any way. In Hawiki, I feel there is a large degree of ownership attached to each paragraph, and it makes me a bit wary of modifying it. Is it okay if I rewrite the page? Should I keep the signatures? So while Wikipedia feels like a commons, Hawiki much less so, and the net result is more often than not that I just leave it.
You are very precisely formulating the reason I, too, have largely hesitated to contribute to the wiki. Ben
On Tue, 2005-12-20 at 11:13 +0100, Ketil Malde wrote:
I'm not familiar with Drupal, but at least EZ publish allows users to convert pages to PDF - could be quite useful for documentation etc.
This feature is planned for a Drupal, and I just found out that new Drupal will have the feature to export to DocBook and from there one can get PDF too. (see http://drupal.org/node/35168#comment-70947) Sincerely, Gour
Am Dienstag, 20. Dezember 2005 10:30 schrieb Simon Peyton-Jones:
[...]
My sense is that the main action item is
how to make haskell.org a better web site
(This is with no disrespect to John and Olaf, who have done a great job. But I know they would be only too happy to share the load.) I'm no expert, but it sounds to me as if some content management system might well be just the thing.
However, the thread didn't have many concrete offers of help. I'm hoping that is perhaps because you're all too shy to put yourselves forward! So:
- is a CMS a plausible way forward?
Maybe we should use a wiki for the whole site. I also prefer MediaWiki. One reason is that it allows you to seperate the actual content and discussion about the content in a clean way.
[...] Simon
Best wishes, Wolfgang
Hello Simon, Tuesday, December 20, 2005, 12:30:56 PM, you wrote: SPJ> * There were suggestions of newsgroups and web forums. i think that newcomers, especially yonger ones, will prefer to see web forum. it's like Mekka now - everyone know how to use it and those who are not Internet-gurus in many cases don't know any other ways (i mean IRC/newsgroup/maillist). so creating web forum and adding link on the main haskell.org page will help in making Haskell community more open, imho SPJ> PS: GHC is now using Trac as its bug tracker, and has its own Wiki as SPJ> well. Please improve it! (Anyone can edit.) SPJ> http://hackage.haskell.org/trac/ghc why you are preffered to create new Wiki system instead of continue using old one (HaWiki)? may be it is better to just put on this page link to the hawiki's GHC page? -- Best regards, Bulat mailto:bulatz@HotPOP.com
Am Dienstag, 20. Dezember 2005 14:04 schrieb Bulat Ziganshin:
[...]
SPJ> PS: GHC is now using Trac as its bug tracker, and has its own Wiki as SPJ> well. Please improve it! (Anyone can edit.) SPJ> http://hackage.haskell.org/trac/ghc
why you are preffered to create new Wiki system instead of continue using old one (HaWiki)? may be it is better to just put on this page link to the hawiki's GHC page?
trac is not just a wiki system but it integrates wiki pages, bug tracking, version control and maybe other things. So if you want to do all these things, trac might be superior. Best wishes, Wolfgang
Hello Wolfgang, Wednesday, December 21, 2005, 8:04:13 PM, you wrote:
SPJ> http://hackage.haskell.org/trac/ghc
why you are preffered to create new Wiki system instead of continue using old one (HaWiki)? may be it is better to just put on this page link to the hawiki's GHC page?
WJ> trac is not just a wiki system but it integrates wiki pages, bug tracking, WJ> version control and maybe other things. So if you want to do all these WJ> things, trac might be superior. may be it will be better to use trac for all other things except for wiki? we already one wiki system, imho dividing wiki pages between two systems is not convenient -- Best regards, Bulat mailto:bulatz@HotPOP.com
Am Donnerstag, 22. Dezember 2005 21:51 schrieb Bulat Ziganshin:
Hello Wolfgang,
Wednesday, December 21, 2005, 8:04:13 PM, you wrote:
SPJ> http://hackage.haskell.org/trac/ghc
why you are preffered to create new Wiki system instead of continue using old one (HaWiki)? may be it is better to just put on this page link to the hawiki's GHC page?
WJ> trac is not just a wiki system but it integrates wiki pages, bug tracking, WJ> version control and maybe other things. So if you want to do all these WJ> things, trac might be superior.
may be it will be better to use trac for all other things except for wiki? we already one wiki system, imho dividing wiki pages between two systems is not convenient
Yes, it isn't. That's why it might be a good proposal to transfer the HaWiki pages to trac and drop HaWiki. If you use trac, it's best to also use its wiki because trac's wiki system, bug tracker, etc. are integrated, so you can link easily from wiki pages to bug reports, from bugreports to wiki pages, from wiki pages to code revisions, etc. Best wishes, Wolfgang
Am Donnerstag, 22. Dezember 2005 21:51 schrieb Bulat Ziganshin:
may be it will be better to use trac for all other things except for wiki? we already one wiki system, imho dividing wiki pages between two systems is not convenient
I totally agree with Bulat here: The current state with 2 Wikis is totally confusing IMHO. So whatever we do, it should result in a single Wiki. And while we are currently very focused on technical aspects, one should not forget aesthetics: The current Trac Wiki looks horrible and a bit unprofessional compared to other Wikis. Keep in mind that this Wiki will be the first thing newbies will see about Haskell, and changing a bad first impression later will be hard. I know that the appearance is only a very superficial thing compared to the contents, but try to sell Haskell in your company given the current Trac Wiki look when your boss is used to things like Wikipedia, Flash, Shockwave and shiny PowerPoint presentations. :-] Perhaps improving this is only a matter of using decent style sheets or something like that, I don't know, but I just wanted to raise my concerns... Cheers, S.
Hello Sven, Wednesday, December 28, 2005, 1:18:35 PM, you wrote:
may be it will be better to use trac for all other things except for wiki? we already one wiki system, imho dividing wiki pages between two systems is not convenient
SP> I totally agree with Bulat here: The current state with 2 Wikis is totally SP> confusing IMHO. So whatever we do, it should result in a single Wiki. And SP> while we are currently very focused on technical aspects, one should not SP> forget aesthetics: The current Trac Wiki looks horrible and a bit SP> unprofessional compared to other Wikis. for my taste, it is more beautiful (i say only about colors) and convenient (i say about guest/suest login) but main point is what one wiki will be better because we can crosslink and search all the material. most of articles about GHC don't need links to bug reports and so on. on the other side, for me personally it's also ok to have all the old Wiki pages migrated to this new system, if someone (not me! :) can automatically perform it :) -- Best regards, Bulat mailto:bulatz@HotPOP.com
Bulat Ziganshin wrote:
for my taste, it is more beautiful (i say only about colors) and convenient (i say about guest/suest login)
but main point is what one wiki will be better because we can crosslink and search all the material. most of articles about GHC don't need links to bug reports and so on. on the other side, for me personally it's also ok to have all the old Wiki pages migrated to this new system, if someone (not me! :) can automatically perform it :)
I agree that we should have one wiki. However, I dislike the lack of article/talk separation. Like other people have mentioned here, I'm never quite sure how to edit a page that's full of people's comments, so I tend not to contribute to hawiki much. I would contribute much more if the wiki had separate talk pages, especially if it used MediaWiki (which I happen to be most familiar with). For me, this is much more valuable than integration with bugs or source control. -- Ashley Yakeley
On 28/12/05, Ashley Yakeley <ashley@semantic.org> wrote:
Bulat Ziganshin wrote:
for my taste, it is more beautiful (i say only about colors) and convenient (i say about guest/suest login)
but main point is what one wiki will be better because we can crosslink and search all the material. most of articles about GHC don't need links to bug reports and so on. on the other side, for me personally it's also ok to have all the old Wiki pages migrated to this new system, if someone (not me! :) can automatically perform it :)
I agree that we should have one wiki. However, I dislike the lack of article/talk separation. Like other people have mentioned here, I'm never quite sure how to edit a page that's full of people's comments, so I tend not to contribute to hawiki much. I would contribute much more if the wiki had separate talk pages, especially if it used MediaWiki (which I happen to be most familiar with).
For me, this is much more valuable than integration with bugs or source control.
Just as a point of help here, it's usually pretty obvious when people are discussing something and when something is an article. I'll usually not go too far in rewording something that someone else wrote as a comment or question (except to correct spelling or grammar), but rather simply reply to it. There is a stage where at some point you might want to rewrite/refactor/digest the entire page along with discussions, and that takes some time, but usually isn't too urgent anyway, so don't bother if you don't have time. If something looks like 'article' material, you should feel free to edit however you like, but usually you should try not to outright remove valid content. In any event, all the old versions are kept, so it's no big deal if something goes missing for a while. The Haskell wiki is a lot less formal than, say Wikipedia, and I like that. It's a lot more like the original wiki. There's some restraint in whether to edit a given passage, given the discussion-like nature of many of the pages, but adding stuff always seems comfortable, which is good. - Cale
It seems to me that trac is mainly about the various 'fptools' projects and hawiki is about haskell topics in general. John -- John Meacham - ⑆repetae.net⑆john⑈
Wolfgang Jeltsch wrote:
trac is not just a wiki system but it integrates wiki pages, bug tracking, version control and maybe other things. So if you want to do all these things, trac might be superior.
Two issues: does trac interface with darcs? Does it have separate content and talk pages on its wiki? -- Ashley Yakeley
Am Samstag, 24. Dezember 2005 00:56 schrieb Ashley Yakeley:
Wolfgang Jeltsch wrote:
trac is not just a wiki system but it integrates wiki pages, bug tracking, version control and maybe other things. So if you want to do all these things, trac might be superior.
Two issues: does trac interface with darcs? Does it have separate content and talk pages on its wiki?
The "vanilla" trac interfaces with Subversion only. However, there is a patch which allows trac to interface with darcs. Alas, typical darcs things like multiple repositories for multiple branches are not supported at the moment. On the other hand, there are feature requests for making trac to work with different version control systems and for making it able to handle different repositories per project. As far as I know, trac doesn't explicitely support the separation of content and talk pages. Best wishes, Wolfgang
participants (11)
-
Ashley Yakeley -
Benjamin Franksen -
Bulat Ziganshin -
Cale Gibbard -
Gour -
Graham Klyne -
John Meacham -
Ketil Malde -
Simon Peyton-Jones -
Sven Panne -
Wolfgang Jeltsch