Dear Haskell folk One thing that hit me forcibly during ICFP in Tallinn, and the associated workshops, is that the Haskell community may not be as good as (say) the Perl community at engaging and involving the people "in the trenches" [PRL]. Haskell.org is centrally maintained by a couple of (excellent) people; GHC is still over-dependent on Simon and me; we don't yet have a good central site for offering libraries; and so on. Things are changing. For example: - The bi-annual Haskell Communities and Activities Report is well established [HCAR] - The Haskell Wiki [WIKI] and the Haskell IRC channel [IRC] are thriving - The MonadReader [MR], the Haskell Sequence [HS], and Haskell Weekly News [HWN] are acting as great community glue - [This isn't new, but people often remark how friendly the Haskell mailings lists are.] On the implementation front: - Lots of people are working on libraries (though much remains to be done) - Work on libraries should become much easier once Cabal and Hackage [CAB] become well established - Work is afoot to move GHC's source-code repository to Darcs, to make it easier for people to contribute patches However, I still wonder if there are things we could do that would make it easier for people to contribute. Here are two concrete suggestions: - Make it possible for people to add comments, explanations, or questions to * The GHC user manual [currently generated using DocBook] * The Haskell 98 Report The idea would be that anyone could help improve these documents, and that, at least in the case of the GHC user manual, we could use the comments to help clarify the text. Some other systems do this e.g. MySql [MySQL] and PostgreSQL [PSQL] do this (the links are to random pages showing comments). One possibility: create a tree of wiki pages mirroring structure of the manual, with links from latter to the former. Issues include: propagating comments forward to following changes to the manual. But basically we have no clue about the best way to do this. - Make the entire haskell.org site into a Wiki, so that everyone can contribute news items, instructional material (Wikibooks?), comments, discussion groups, tools, etc. John and Olaf do a great job of updating haskell.org, but there is a real limit on what a couple of individuals can do in their spare time. Does anyone have experience of a larger-scale Wiki like this? (A few people have mentioned MediaWiki to me [MW], but I know nothing about it.) How would we make sure it stayed organised? And avoid getting screwed up by malicious folk? The important thing is that these mechanisms should work without any central intervention. These are just two suggestions. Perhaps there are other such mechanisms that we could put in place. Ideas? Many of you will know much more about this kind of thing than I do. Share your wisdom with the mailing list. Lastly, when it comes down to it, none of these things will happen unless some people volunteer to push them forward. Would any of you like to contribute your time and expertise? Simon [PRL] http://perl.com, http://www.perlmonks.org [HCAR] http://www.haskell.org/communities/ [WIKI] http://haskell.org/hawiki [IRC] http://haskell.org/hawiki/HaskellIrcChannel [MR] http://haskell.org/hawiki/TheMonadReader [HS] http://sequence.complete.org/ [HWN] http://sequence.complete.org/hwn [CAB] http://www.haskell.org/cabal/ [MW] http://www.mediawiki.org/wiki/MediaWiki [MSQL] http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html (see bottom of page) [PSQL] http://www.postgresql.org/docs/7.4/interactive/installation.html
"Simon Peyton-Jones" <simonpj@microsoft.com> writes:
- Make it possible for people to add comments, explanations, or questions to * The GHC user manual [currently generated using DocBook] * The Haskell 98 Report The idea would be that anyone could help improve these documents, and that, at least in the case of the GHC user manual, we could use the comments to help clarify the text.
One possibility is Shae Erisson's "Fermat's Last Margin" (FLM) idea. This is designed to enable people to annotate the PDFs of research papers with their own notes, in an infinitely-expandable "margin", shared with all other users of the FLM system. It could just as easily be applied to reference material as to research papers. To be best of my knowledge FLM is still not fully implemented, but I guess that could be speeded up if there were a real customer... Regards, Malcolm
Simon Peyton-Jones <simonpj <at> microsoft.com> writes:
... And avoid getting screwed up by malicious folk?
Probably the biggest example of this type of thing working well on a large scale is Wikipedia. I'm not intimately familiar with the process they use, but I believe there are a number of people who regularly review all the "Recent Changes" and undertake to 'undo' any malicious/inaccurate modifications. Having something that is more open like this could be incredibly useful.
In article <loom.20051110T195307-545@post.gmane.org>, Ben Moseley <ben_moseley@mac.com> wrote:
Probably the biggest example of this type of thing working well on a large scale is Wikipedia.
(Wikipedia uses MediaWiki.) I would much prefer to use a MediaWiki than the existing hawiki. Particularly valuable are the elimination of RunTogetherWordLinks and the separation of article and talk spaces. I've set up a MediaWiki site for my own private use, and that at least wasn't too hard. It's all PHP/MySQL. Of course, there might be a better solution. -- Ashley Yakeley, Seattle WA
Am Donnerstag, 10. November 2005 19:57 schrieb Ben Moseley:
Simon Peyton-Jones <simonpj <at> microsoft.com> writes:
... And avoid getting screwed up by malicious folk?
Probably the biggest example of this type of thing working well on a large scale is Wikipedia. I'm not intimately familiar with the process they use, but I believe there are a number of people who regularly review all the "Recent Changes" and undertake to 'undo' any malicious/inaccurate modifications.
I cannot imagine that a couple of people is sufficient to review all recent changes and therefore I don't think they do it this way. There are some typical articles where screwing up happens often, so these articles might be regularily revisited. Screwing up of articles might as well be removed by ordinary people who discover ugly things in articles by accident.
[...]
Best wishes, Wolfgang
On Fri, 2005-11-11 at 14:43 +0100, Wolfgang Jeltsch wrote:
Am Donnerstag, 10. November 2005 19:57 schrieb Ben Moseley:
Simon Peyton-Jones <simonpj <at> microsoft.com> writes:
... And avoid getting screwed up by malicious folk?
Probably the biggest example of this type of thing working well on a large scale is Wikipedia. I'm not intimately familiar with the process they use, but I believe there are a number of people who regularly review all the "Recent Changes" and undertake to 'undo' any malicious/inaccurate modifications.
I cannot imagine that a couple of people is sufficient to review all recent changes and therefore I don't think they do it this way. There are some typical articles where screwing up happens often, so these articles might be regularily revisited. Screwing up of articles might as well be removed by ordinary people who discover ugly things in articles by accident.
One possability here would be to have all changes to the wiki reported in real time (or near real time) in the #haskell IRC channel. The #haskell lambdabot could be extended to do this. The #haskell IRC channel is active nearly 24 hours a day and has a membership that varies between 170 and 200. This would easily be enough eyes to spot malicious or inaccurate changes. This would have the added benefit of notifing people of changes on the wiki which I imagine would prompt more contributers. The lambdabot module to implement this scheme could do some filtering if the notification messages prove too frequent, for example by ignoring followup changes made to the same page by the same user within a certain time period (since people often edit-review-edit). Duncan
On Fri, Nov 11, 2005 at 03:19:27PM +0000, Duncan Coutts wrote:
I cannot imagine that a couple of people is sufficient to review all recent changes and therefore I don't think they do it this way. There are some typical articles where screwing up happens often, so these articles might be regularily revisited. Screwing up of articles might as well be removed by ordinary people who discover ugly things in articles by accident.
One possability here would be to have all changes to the wiki reported in real time (or near real time) in the #haskell IRC channel. The #haskell lambdabot could be extended to do this.
The #haskell IRC channel is active nearly 24 hours a day and has a membership that varies between 170 and 200. This would easily be enough eyes to spot malicious or inaccurate changes.
I think that the amount of changes that need to be reviewed could be dramatically reduced if we create some trust management system, for example we could trust changes made by authorized users. The users who most often contribute to the Wiki will probably be the same who care about reviewing changes and they probably won't mind to log in, so their changes won't have to be reviewed. Best regards Tomasz
Tomasz Zielonka:
On Fri, Nov 11, 2005 at 03:19:27PM +0000, Duncan Coutts wrote:
I cannot imagine that a couple of people is sufficient to review all recent changes and therefore I don't think they do it this way. There are some typical articles where screwing up happens often, so these articles might be regularily revisited. Screwing up of articles might as well be removed by ordinary people who discover ugly things in articles by accident.
One possability here would be to have all changes to the wiki reported in real time (or near real time) in the #haskell IRC channel. The #haskell lambdabot could be extended to do this.
The #haskell IRC channel is active nearly 24 hours a day and has a membership that varies between 170 and 200. This would easily be enough eyes to spot malicious or inaccurate changes.
I think that the amount of changes that need to be reviewed could be dramatically reduced if we create some trust management system, for example we could trust changes made by authorized users. The users who most often contribute to the Wiki will probably be the same who care about reviewing changes and they probably won't mind to log in, so their changes won't have to be reviewed.
But changes of authorised users might be even more interesting to have a look at if you want to stay up to speed on what's new on haskell.org. I think, Duncan's plan is a good one. Use a convenience (real-time notification on possibly interesting web content changes) to increase the likelihood that somebody looks at a malicious update quickly and corrects it. Personally, I am not very worried about abuse of a wiki. Haskell is not a very controversial topic (...ok, maybe some disgruntled C++ users might hold a grudge ;) and pages that a particularly attractive for abuse (such as the front page) also get a lot of hits by users who can remove malicious content. Besides, we could always start of with changes to a few key pages (such as the front page, the language definition, etc) being restricted to authorised users and all the rest open. If this work well, we can always consider to be more permissive about the key pages, too. One easy way to keep spam bots out is to restrict the edit capabilities to registered users, but make registration a trivial process to keep the barrier to entry low. By using the standard email verification process for registration and a changing image from which you need to read of some letters, we can make sure that all registered users are indeed human. These are standard procedures on many web sites. Manuel
Am Donnerstag, 10. November 2005 12:27 schrieb Simon Peyton-Jones:
[...]
- Work is afoot to move GHC's source-code repository to Darcs, to make it easier for people to contribute patches
Is it planned to split the current big monolithic repository into multiple repositories in conjunction with doing the CVS-to-darcs transition? I'd strongly recommend this. What do others think?
[...]
* The GHC user manual [currently generated using DocBook]
I think it should continue to be written in DocBook. (It should switch to DocBook XML if it's still using SGML DocBook.) XML documents are "type-safe" in contrast to LaTeX documents, for example. XML is well supported. DocBook stresses logical markup and allows very specific markup and therefore supports conversion into different formats (HTML, PDF, ...) very well. Again, what do others think?
[...]
Does anyone have experience of a larger-scale Wiki like this? (A few people have mentioned MediaWiki to me [MW], but I know nothing about it.)
MediaWiki is the software behind Wikipedia [1] so it should be well suited for large wikis. :-) In addition, I like the fact that with MediaWiki you can give articles nice names and use alternative names in link texts so you aren't forced to write sentences like: "You can solve this problem with MultiParameterTypeClasses." but you can write correct English sentences like: "You can solve this problem with multi-parameter type classes."
How would we make sure it stayed organised? And avoid getting screwed up by malicious folk?
At Wikipedia, you can log in and modify content and you can modify content while not being logged in. In the first case, the history mentions your username, in the second case, it mentions your IP address. I think, MediaWiki can be configured so that only logged-in users are able to do modifications. As far as I can remember, I once saw a site using MediaWiki, which didn't allow modifications from non-registered users. But honestly, would we need to protect ourselfs from malicious folk? At Wikipedia, they have problem with malicious people at a couple of articles, so they sometimes have to lock articles. (This tells us that article locking obviously is another feature of WikiMedia. As far as I know, this kind of locking can be done by different persons, not just one super user.) But who would want to screw up pages about Haskell? I could imagine that making the Haskell Website a wiki is a really good idea. At least, Wikipedia shows how much of high-quality content can evolve out of a wiki project.
[...]
Simon
Best wishes, Wolfgang [1] http://www.wikipedia.org/
On Friday 11 November 2005 13:56, Wolfgang Jeltsch wrote:
Am Donnerstag, 10. November 2005 12:27 schrieb Simon Peyton-Jones:
[...]
* The GHC user manual [currently generated using DocBook]
I think it should continue to be written in DocBook. (It should switch to DocBook XML if it's still using SGML DocBook.) XML documents are "type-safe" in contrast to LaTeX documents, for example. XML is well supported. DocBook stresses logical markup and allows very specific markup and therefore supports conversion into different formats (HTML, PDF, ...) very well. Again, what do others think?
Yes. In fact I like the current GHC manual as it is.
How would we make sure it stayed organised? And avoid getting screwed up by malicious folk?
At Wikipedia, you can log in and modify content and you can modify content while not being logged in. In the first case, the history mentions your username, in the second case, it mentions your IP address. I think, MediaWiki can be configured so that only logged-in users are able to do modifications. As far as I can remember, I once saw a site using MediaWiki, which didn't allow modifications from non-registered users.
But honestly, would we need to protect ourselfs from malicious folk? At Wikipedia, they have problem with malicious people at a couple of articles, so they sometimes have to lock articles. (This tells us that article locking obviously is another feature of WikiMedia. As far as I know, this kind of locking can be done by different persons, not just one super user.) But who would want to screw up pages about Haskell?
Spambots are the worst problem, I guess. Ben
On Saturday 12 November 2005 02:30, Benjamin Franksen wrote:
On Friday 11 November 2005 13:56, Wolfgang Jeltsch wrote:
Am Donnerstag, 10. November 2005 12:27 schrieb Simon Peyton-Jones:
[...]
* The GHC user manual [currently generated using DocBook]
I think it should continue to be written in DocBook. (It should switch to DocBook XML if it's still using SGML DocBook.) XML documents are "type-safe" in contrast to LaTeX documents, for example. XML is well supported. DocBook stresses logical markup and allows very specific markup and therefore supports conversion into different formats (HTML, PDF, ...) very well. Again, what do others think?
Yes. In fact I like the current GHC manual as it is.
Sorry, that comment seems to miss the point. What I wanted to say is: However the source format is going to be changed to better support user contributions, I would like it to remain similar in its (processed) end user appearance. Ben
At Thu, 10 Nov 2005 11:27:50 -0000, Simon Peyton-Jones wrote:
Does anyone have experience of a larger-scale Wiki like this? (A few people have mentioned MediaWiki to me [MW], but I know nothing about it.) How would we make sure it stayed organised? And avoid getting screwed up by malicious folk?
The MLton project [MLTON] does this for their home page. It works tremendously. I currently find the pages where Standard ML is being bent into supporting functional record updates (Which the standard sadly doesn't have), printf-style output (Take my word: that is a mind-bender) etc the most funny to read. Occams razor suggests that one should maintain organization by having a page where organization is discussed and security by simple authentication. It reduces maintenance to the, admittedly boring, task of add new people to the list of contributers. It would still speed up change by orders I'd think. [MLTON] http://www.mlton.org, search the archives of the MLton mailing list to see when this was done.
Simon Peyton-Jones (simonpj@microsoft.com) wrote: Dear Simon,
Dear Haskell folk
One thing that hit me forcibly during ICFP in Tallinn, and the associated workshops, is that the Haskell community may not be as good as (say) the Perl community at engaging and involving the people "in the trenches" [PRL]. Haskell.org is centrally maintained by a couple of (excellent) people; GHC is still over-dependent on Simon and me; we don't yet have a good central site for offering libraries; and so on.
it is very encouraging to see that despite working on a capital Haskell project, you are thinking about the global community as well.
However, I still wonder if there are things we could do that would make it easier for people to contribute. Here are two concrete suggestions:
[snip]
Many of you will know much more about this kind of thing than I do. Share your wisdom with the mailing list.
In the light of your suggestions, proposals, I'll (despite being a Haskell noob) share my ideas¹, which are based on one assumption - haskell.org can be used as a bed for the whole thing... ¹ I'll use letter chars to denote that points are not listed according to priorities a) convert the whole haskell.org site into a community portal by using some CMS (eg. Drupal - http://drupal.org/ - which is used on LTU & Haskell Sequence sites). By giving accounts to trusted users, creating of content can be made much easier and we'll get a more material published in less time. I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing, but use the Drupal's feature to make some categories from the present homepage's links like: i) A Short Introduction to Haskell can be made like About menu bar ii) Definition of Haskell - another category in the main menu bar iii) Books and Tutorials² - another category iv) Libraries and Tools² iv) Links to Haskell-related blogs & sites .. ... xx) Forums³ ² those type of categories I'd made like e.g. http://gnomefiles.org/ & http://www.kde-apps.org/ sites where the books/tutorials/aplications can be catalogized according to the software type, reviewed & rated by users, and relevant links with homepage, screenshots, version histories etc. can be provided. ³ I'll mention and (try to) justify them a little bit later The rest of the haskell.org portal site can be used for displaying latest forum topics, important news, quick links etc. b) make a haskell.org repository for haskell-related projects by adding some required features so that Haskell projects can move from e.g. SF to haskell.org. Here I'm thinking about Trac - wiki and issue tracking system (http://projects.edgewall.com/trac/). It is simple & powerful enough. It combines wiki (the present hawiki entries can be imported (http://projects.edgewall.com/trac/ticket/2068) with the ticket system handy for handling bug requests, feature requests, setting roadmaps, timelines etc. and great thing that there is a darcs backend available so every proejct can have darcs repository avaialable. (this is why I prefer trac over e.g. bugzilla, RT...) Several projects (ghc, gtk2hs) are already hosted on haskell.org, but with the Trac it is very easy to provide SF-like features on haskell.org with not so complicated setup & maintainance. So projects (e.g. gtk2hs) can have their own style & features (gallery, blog...), while other projects can use just a Trac and have a working site with the darcs repo in practically no time (see e.g. opensync.org site). c) providing unified front-end for mail-archives & search By implementing point b) several projects can move their mailing lists & mail-archives to haskell.org and we can setup front-end for searching/browsing all the haskell-related lists like (see e.g. http://mail.gnome.org/archives/) d) enhance the present wiki system The present hawiki is very rich and provides lot of information for haskell searchers, but it is, imho, too flat in the sense that it could be enhanced by providing better Table Of Contents and having shorter pages to find material more quickly. Some of the wiki entries could find their place (link) on the portal's homepage, in the Docs section etc. e) forums Several posts were regarding forums/newsgroups/mailing lists/irc and I consider that forums can be very handy feature for the new Haskell community portal site :-) Let us consider the pro/cons of the present communication means: i) mailing lists pro) - very convenient interface - searchable archives cons) - it is not easy to jump in the discussion after some time - it requires subscription ii) #irc pro) - very interactive - quick solutions for many problems cons) - it can be very time-consuming (discussion can go astray or nothing is happening at all) - the same questions/answers are regularly asked/answered iii) forum pro) - provides ability to have sticky posts for FAQ, howtos, etc. - searchable archives - one can always jump in the thread by replying to appropriate post (even much later than original post is posted) - ability to have email notification when some replies are posted The potential of newsgroup was also mentioned - creating of compl.lang.haskell, but I won't comment of it considering that the newsgroup cannot be one & all solution, and, otoh, does not, imho, provide any substantial advantage over the other three forms (we already have lists & irc, and forums come 'for free' with CMS). f) enhancing & opening GHC manual Besides my vote for simple authoring tool for working on GHC manual, Drupal offers so called 'Collaborative Book' (http://drupal.org/node/284) feature which can even export to DocBook XML in case we want to preserve its format. Conclusion: The above listed proposals can help to put Haskell comunity even more together by providing central place for sharing ideas, news, software...and by using ticket system and having concrete timelines, roadmaps, tasks...it will become much easier to engage people with different skills contribute to the whole community in many ways: i) writing simple patches for certain project ii) becoming developer ... ii) providing translation iii) testing iv) writing documentation (manuals, tutorials...) v) web design vi) administration & maintenance (forums, lists...) vii) writing news articles... The result of the above points would be that we can provide the strategy for the further develpment of the whole community by: i) organizing bug-days and/or bug-week to squash bugs (ghc example) ii) providing more man-power for the apps which are important for promoting Haskell as general programming language further iii) ... Shortly, by having concrete strategy how to enhance/improve the whole community (language, applications, libs, documentation) we can hope to attract much more man-power (non-PhD users :-) & money-power (we will also need some funds for maintaining hardware, (maybe) paying some programmers to work full-time on certain projects etc.)
Lastly, when it comes down to it, none of these things will happen unless some people volunteer to push them forward.
David Roundy and darcs are nice example how he managed to attract lot of people to contibute a little to the whole project. otoh, I'm 'thankful' to Duncan for inspiring me & engaging my (not so developed) skills to contribute somehow (gtk2hs).
Would any of you like to contribute your time and expertise?
Of course, I'm ready to help according to time & skills (not so much an expert :-) Huh, now it is enough, you canstart flaming me. I'm ready working on my false-ego anyway :-) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Am Samstag, 12. November 2005 10:04 schrieb Gour:
[...]
I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing,
The font size is way too small!
[...]
iii) forum pro) - provides ability to have sticky posts for FAQ, howtos, etc. - searchable archives - one can always jump in the thread by replying to appropriate post (even much later than original post is posted) - ability to have email notification when some replies are posted
cons) - cumbersome usage - no ability to choose own communication software
[...]
The potential of newsgroup was also mentioned - creating of compl.lang.haskell, but I won't comment of it considering that the newsgroup cannot be one & all solution, and, otoh, does not, imho, provide any substantial advantage over the other three forms (we already have lists & irc, and forums come 'for free' with CMS).
As long as newsgroups are not substantially worse than the three other communication forms, you should list them. Otherwise you could also leave out mailing lists or, ehm, forums with the same justification.
[...]
f) enhancing & opening GHC manual
Besides my vote for simple authoring tool for working on GHC manual, Drupal offers so called 'Collaborative Book' (http://drupal.org/node/284) feature which can even export to DocBook XML in case we want to preserve its format.
The question is how the DocBook documents created by Drupal look. You can also export Word documents as HTML but as far as I know this is not advisable. The main advantage of DocBook is that it uses truely logical markup. Logical markup is something we should keep under all circumstances.
[...]
By the way, is Drupal Free/Open Source Software?
[...]
Best wishes, Wolfgang
Wolfgang Jeltsch wrote:
The potential of newsgroup was also mentioned - creating of compl.lang.haskell, but I won't comment of it considering that the newsgroup cannot be one & all solution, and, otoh, does not, imho, provide any substantial advantage over the other three forms (we already have lists & irc, and forums come 'for free' with CMS).
As long as newsgroups are not substantially worse than the three other communication forms, you should list them. Otherwise you could also leave out mailing lists or, ehm, forums with the same justification.
IMO, newsgroups are substantially /better/. You can supersede and cancel, client software generally provide the necessary functionality for threading, sites can get a feed and have a local mirror. Gmane, which integrates newsgroups, mailing lists and a web front end seems like a very good choice. (IRC and Wiki are substantially different that integration doesn't make much sense, IMO) -k
Wolfgang Jeltsch (wolfgang@jeltsch.net) wrote:
I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing,
The font size is way too small!
Well, in every browser I know (on Linux), you can setup your preferred sitze for minimum and/or medium font size.
As long as newsgroups are not substantially worse than the three other communication forms, you should list them.
You did not mention what is the advantage of newsgroups over the mailing lists, therefore I am leaving them out.
The question is how the DocBook documents created by Drupal look.
That should be tested, of course.
You can also export Word documents as HTML but as far as I know this is not advisable.
If the html is desired output, no need for a complex thing as Docbook.
The main advantage of DocBook is that it uses truely logical markup. Logical markup is something we should keep under all circumstances.
DocBook is much richer markup language than HTML, so what is the need to author in a complicated markup when much simpler tools can do the job?
By the way, is Drupal Free/Open Source Software?
From the Gentoo ebuild description:
Drupal is a PHP-based open-source platform and content management system for building dynamic web sites offering a broad range of features and services; including user administration, publishing workflow, discussion capabilities, news aggregation, metadata functionalities using controlled vocabularies and XML publishing for content sharing purposes. Equipped with a powerful blend of features and configurability, Drupal can support a diverse range of web projects ranging from personal weblogs to large community-driven sites. License: GPL-2 Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD
Am Sonntag, 13. November 2005 19:21 schrieb Gour:
Wolfgang Jeltsch (wolfgang@jeltsch.net) wrote:
I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing,
The font size is way too small!
Well, in every browser I know (on Linux), you can setup your preferred sitze for minimum and/or medium font size.
The font size is much smaller than the font size of other webpages. So if I would change the default font size to give good results with the Haskell website, all other websites would have their text in very large letters.
[...]
You can also export Word documents as HTML but as far as I know this is not advisable.
If the html is desired output, no need for a complex thing as Docbook.
What I wanted to illustrate is the fact that being able to export in certain format doesn't necessarily mean that this is worthwhile.
The main advantage of DocBook is that it uses truely logical markup. Logical markup is something we should keep under all circumstances.
DocBook is much richer markup language than HTML, so what is the need to author in a complicated markup when much simpler tools can do the job?
The question is if HTML is sufficient. In addition, HTML is at some points not well thought-out.
[...]
Sincerely, Gour
Best wishes, Wolfgang
On 13/11/05, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Sonntag, 13. November 2005 19:21 schrieb Gour:
Wolfgang Jeltsch (wolfgang@jeltsch.net) wrote:
I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing,
The font size is way too small!
Well, in every browser I know (on Linux), you can setup your preferred sitze for minimum and/or medium font size.
The font size is much smaller than the font size of other webpages. So if I would change the default font size to give good results with the Haskell website, all other websites would have their text in very large letters.
Try the Edit -> Preferences -> General -> Fonts & Colors... -> Minimum Font Size setting. I actually go so far as to check the "Always use my fonts" checkbox, and set specific fonts and sizes for serif, sans-serif and monospace. I set the minimum size only a couple of points smaller than the default to ensure that text is always readable. - Cale
Am Sonntag, 13. November 2005 20:28 schrieben Sie:
On 13/11/05, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Sonntag, 13. November 2005 19:21 schrieb Gour:
Wolfgang Jeltsch (wolfgang@jeltsch.net) wrote:
I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing,
The font size is way too small!
Well, in every browser I know (on Linux), you can setup your preferred sitze for minimum and/or medium font size.
The font size is much smaller than the font size of other webpages. So if I would change the default font size to give good results with the Haskell website, all other websites would have their text in very large letters.
Try the Edit -> Preferences -> General -> Fonts & Colors... -> Minimum Font Size setting.
Which browser are you speaking about? I use Konqueror. Nevertheless, the tip with the *minimum* font size might be the solution. Thanks for that. But I wonder if someone really wants fonts as small as the ones on the Haskell website. If not, it would probably be better to change the font sizes of the Haskell website instead of forcing all users to adapt their settings or am I missing something?
[...]
- Cale
Best wishes, Wolfgang
On Sun, Nov 13, 2005 at 09:11:46PM +0100, Wolfgang Jeltsch wrote:
Which browser are you speaking about? I use Konqueror.
I don't know about Konqueror, but in Firefox you can quickly increase or decrease the font size pressing Ctrl with + or -. This is a local per-window, per-tab setting, so it doesn't affect how other pages look. BTW, I don't care if you make fonts on haskell.org bigger - after all I can always press Ctrl and - ;-) Best regards Tomasz
I'd like that we keep the present css style of the site (color theme) which I find very nice and appealing,
The font size is way too small!
Well, in every browser I know (on Linux), you can setup your preferred sitze for minimum and/or medium font size.
The font size is much smaller than the font size of other webpages. So if I would change the default font size to give good results with the Haskell website, all other websites would have their text in very large letters.
Try the Edit -> Preferences -> General -> Fonts & Colors... -> Minimum Font Size setting.
Which browser are you speaking about? I use Konqueror.
Oops, sorry. That was for Firefox.
Nevertheless, the tip with the *minimum* font size might be the solution. Thanks for that.
But I wonder if someone really wants fonts as small as the ones on the Haskell website. If not, it would probably be better to change the font sizes of the Haskell website instead of forcing all users to adapt their settings or am I missing something?
Hmm, turning off my font settings, it still looks mostly okay. The font sizes aren't set in absolute terms in the CSS or HTML anywhere that I can see. They're all set to percentages of the default browser sizes. Perhaps the problem is that Konqueror is configured to make text too small by default and it's not noticeable since many websites set absolute sizes? Opening up konqueror on my machine, it seems to have a default minimum size of 7pt and medium size of 10pt (In Settings -> Configure Konqueror -> Fonts), which are both rather small. Changing 7 and 10 to 10 and 12 respectively resulted in a more readable size for me. - Cale
Am Sonntag, 13. November 2005 22:21 schrieben Sie:
[...]
Hmm, turning off my font settings, it still looks mostly okay. The font sizes aren't set in absolute terms in the CSS or HTML anywhere that I can see. They're all set to percentages of the default browser sizes. Perhaps the problem is that Konqueror is configured to make text too small by default and it's not noticeable since many websites set absolute sizes? Opening up konqueror on my machine, it seems to have a default minimum size of 7pt and medium size of 10pt (In Settings -> Configure Konqueror -> Fonts), which are both rather small. Changing 7 and 10 to 10 and 12 respectively resulted in a more readable size for me.
Maybe I changed Konqueror's font settings already. The point is that my settings are in such a way that text with the default font size is well readable while not taking up too much space. The problem is with haskell.org's links. They have a font size of 80% of the default. If the default font size satisfies me, 80% of it is too small. If I change the default size so that 80% of it produces well readable text, the default size itself is too large, IMO. I wonder why the links have to use a smaller font size than ordinary text at all. This looks especially strange if a link occurs as part of a running text.
- Cale
Best wishes, Wolfgang
On 2005-11-14 at 11:13+0100 Wolfgang Jeltsch wrote:
Maybe I changed Konqueror's font settings already. The point is that my settings are in such a way that text with the default font size is well readable while not taking up too much space. The problem is with haskell.org's links. They have a font size of 80% of the default. If the default font size satisfies me, 80% of it is too small. If I change the default size so that 80% of it produces well readable text, the default size itself is too large, IMO.
This sort of thing is a frequent topic among CSS hacks. The general opinion among the more seasoned ones is that site designers should /always/ specify that the text size of normal paragraphs is 100%, exactly for the reason you give. People with poor eyesight may set the default to be the smallest they can comfortably read to get more use out of the screen, and allowing for some difficulty in reading small print. If a site sets the main body text size smaller than 100%, it will significantly inconvenience such people (without giving any benefit to anyone else).
I wonder why the links have to use a smaller font size than ordinary text at all. This looks especially strange if a link occurs as part of a running text.
That just sounds like bad design. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
Maybe I changed Konqueror's font settings already. The point is that my settings are in such a way that text with the default font size is well readable while not taking up too much space. The problem is with haskell.org's links. They have a font size of 80% of the default. If the default font size satisfies me, 80% of it is too small. If I change the default size so that 80% of it produces well readable text, the default size itself is too large, IMO.
Aha! That's where it is. I missed that bit, not expecting something like that :)
I wonder why the links have to use a smaller font size than ordinary text at all. This looks especially strange if a link occurs as part of a running text.
Yeah, it's probably best to leave them at 100%. Are the maintainers on this list already? If not we should send them an e-mail. - Cale
If someone sends me a new css file I'll be happy to throw it on haskell.org for you. Please send an email to this list if you want to do this so nobody else wastes their time. John
On 2005-11-14 at 10:38EST John Peterson wrote:
If someone sends me a new css file I'll be happy to throw it on haskell.org for you. Please send an email to this list if you want to do this so nobody else wastes their time.
Is anything more needed than the attached patch? If so, I'm willing to give it a go provided it's not much work. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk
Am Montag, 14. November 2005 17:05 schrieb Jon Fairbairn:
On 2005-11-14 at 10:38EST John Peterson wrote:
If someone sends me a new css file I'll be happy to throw it on haskell.org for you. Please send an email to this list if you want to do this so nobody else wastes their time.
Is anything more needed than the attached patch?
If so, I'm willing to give it a go provided it's not much work.
Jón
This should be sufficient concerning what we were discussing. Thank you also for fixing this color bug. :-) Best wishes, Wolfgang
Gour:
Simon Peyton-Jones (simonpj@microsoft.com) wrote: b) make a haskell.org repository for haskell-related projects
by adding some required features so that Haskell projects can move from e.g. SF to haskell.org. Here I'm thinking about Trac - wiki and issue tracking system (http://projects.edgewall.com/trac/).
It is simple & powerful enough. It combines wiki (the present hawiki entries can be imported (http://projects.edgewall.com/trac/ticket/2068) with the ticket system handy for handling bug requests, feature requests, setting roadmaps, timelines etc. and great thing that there is a darcs backend available so every proejct can have darcs repository avaialable. (this is why I prefer trac over e.g. bugzilla, RT...)
This would indeed be something very valuable to have IMHO. The easier it is for potential library and tool writers to involve the rest of the community in their efforts (independent whether they have public web servers etc available to use), the more good libraries and tools, we'll get. Trac also looks quite nice (after quickly browsing through the site). Manuel
Am Mittwoch, 16. November 2005 11:32 schrieb Manuel M T Chakravarty:
Gour:
Simon Peyton-Jones (simonpj@microsoft.com) wrote: b) make a haskell.org repository for haskell-related projects
by adding some required features so that Haskell projects can move from e.g. SF to haskell.org. Here I'm thinking about Trac - wiki and issue tracking system (http://projects.edgewall.com/trac/).
It is simple & powerful enough. It combines wiki (the present hawiki entries can be imported (http://projects.edgewall.com/trac/ticket/2068) with the ticket system handy for handling bug requests, feature requests, setting roadmaps, timelines etc. and great thing that there is a darcs backend available so every proejct can have darcs repository avaialable. (this is why I prefer trac over e.g. bugzilla, RT...)
This would indeed be something very valuable to have IMHO. The easier it is for potential library and tool writers to involve the rest of the community in their efforts (independent whether they have public web servers etc available to use), the more good libraries and tools, we'll get.
Trac also looks quite nice (after quickly browsing through the site).
Manuel
Would it be intended that every Haskell-related project is hosted under haskell.org? This might be not so nice. And it might be not so nice if most Haskell-related projects are hosted under haskell.org so that potential users might only look under haskell.org for projects and miss those that are hosted elsewhere. Just thinking... Best wishes, Wolfgang
Am Mittwoch, den 16.11.2005, 12:56 +0100 schrieb Wolfgang Jeltsch:
Am Mittwoch, 16. November 2005 11:32 schrieb Manuel M T Chakravarty:
Gour:
Simon Peyton-Jones (simonpj@microsoft.com) wrote: b) make a haskell.org repository for haskell-related projects
by adding some required features so that Haskell projects can move from e.g. SF to haskell.org. Here I'm thinking about Trac - wiki and issue tracking system (http://projects.edgewall.com/trac/).
It is simple & powerful enough. It combines wiki (the present hawiki entries can be imported (http://projects.edgewall.com/trac/ticket/2068) with the ticket system handy for handling bug requests, feature requests, setting roadmaps, timelines etc. and great thing that there is a darcs backend available so every proejct can have darcs repository avaialable. (this is why I prefer trac over e.g. bugzilla, RT...)
This would indeed be something very valuable to have IMHO. The easier it is for potential library and tool writers to involve the rest of the community in their efforts (independent whether they have public web servers etc available to use), the more good libraries and tools, we'll get.
Trac also looks quite nice (after quickly browsing through the site).
Manuel
Would it be intended that every Haskell-related project is hosted under haskell.org? This might be not so nice.
People can host their Haskell projects wherever they like. The point of a public infrastructure at haskell.org would be to make it easy for everybody to obtain hosting.
And it might be not so nice if most Haskell-related projects are hosted under haskell.org so that potential users might only look under haskell.org for projects and miss those that are hosted elsewhere.
An index can still include projects hosted elsewhere. (In fact, it should.) Manuel
participants (15)
-
Ashley Yakeley -
Ben Moseley -
Benjamin Franksen -
Cale Gibbard -
Duncan Coutts -
Gour -
Jesper Louis Andersen -
John Peterson -
Jon Fairbairn -
Ketil Malde -
Malcolm Wallace -
Manuel M T Chakravarty -
Simon Peyton-Jones -
Tomasz Zielonka -
Wolfgang Jeltsch