Re: [Haskell-cafe] What about adding a wiki for each haskell project?
wren ng thornton w...@freegeek.org writes: Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. Other packages are orphaned or see little interest from their author. We already have community.haskell.org for authors to host their webpages and Darcs repos. [..] Rather than giving Hackage wikis, perhaps it would be better to point more people towards community.haskell.org and maybe increase the options offered there (in case people dislike Trac). This is great, but I view this as a different issue. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Hello everyone, Could a new mailing list for patches and/or commentary do the work of the proposed package Wikis? Similar to the libraries list but separate so it doesn't pollute the libraries list from its important job of discussing and refining the core libs. From my perspective, mails have two useful and apparent properties - messages are authored and time stamped, and viewing the list through Gmane or whatever would allow people to keep up to date without burdening their inboxes. With a Wiki the authorship and time stamp are deep within the history - on a Wiki, one would expect people to be respectful, but you never know. Also my personal feeling is that Wiki comments would go the way of (elaborate) source code comments - vis the old chestnut Are out of date comments, better than no comments? Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Ketil Malde wrote: wren ng thornton w...@freegeek.org writes: Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. My interpretation of Duncan's concern ---not meaning to put words in his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. I understand that y'all think giving users a place for feedback is different than giving authors the tools to communicate with their users, but I don't think they're all that different. Why not push for authors to have a section of their wikis devoted to users' notes? That would have the same effect of allowing users to speak out without fracturing each project's community. Institutionalizing a place for users to make comments separate from the authors' resources can't be a good thing. It sets up a community divide between users and authors. It can confuse new users who can't figure out which to go to for official answers. It can cause users to just post their fixes rather than trying to contact the maintainers. Etc. I can't think of any way this separation could lead to good for any project's community. E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. So someone else should set them up for you? I don't get it. Either you want ways to communicate with your users or you don't. If it's just a matter of not wanting to do the work *yourself*, then I'm back to my previous post. The community server (or similar hosts) should make it trivial to set things up. I think it only takes one command to set up Trac on community.haskell.org. The only thing I can think might need changing is if the community server only allows per-project Trac instances instead of also having per-user instances so someone can have a single one for all their little projects. If they don't offer per-user instances (I haven't checked) then I'm all for adding them. Other packages are orphaned or see little interest from their author. That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? We have a long history of community-based maintenance for the main libraries that (used to) ship with GHC. It may not be the best model, but it should suffice for keeping the cobwebs off. I don't have anything against wikis, nor against Hackage having links to wikis. But I don't think Hackage is the right place for hosting the wikis themselves. This has the distinct feel of trying to legislate community into existence. But community isn't something you can legislate. Adding things to try to force community building just leads to bloated web-interfaces and trivializes the communities that do exist. There are a number of project hosts that have gone down this route, and it leads to ghettoization and abandoned projects with lots of infrastructure around their carcasses. The more forced overhead there is the more people will decide not to post their small projects, and the more quickly they'll abandon them if they do post. The thing I've liked most about Hackage is that it's like CPAN but moreso. CPAN is an excellent resource, but it has a few sticking points that make the barrier to entry and the cost of posting higher than they should be. Places like SourceForge or GoogleCode have very high barriers to entry, but they're going after a different audience. I think we want to emulate CPAN more than SF, for the sake of growing a wide collection of libraries. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Excerpts from wren ng thornton's message of Sun Dec 13 13:54:04 +0100 2009: Ketil Malde wrote: wren ng thornton w...@freegeek.org writes: Using a wiki page for each project enables anybody to add comments.[...] I think this is a great idea. Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. I don't this this is the same thing. Marc's proposal would provide a scratch pad for random users to discuss or comment on various stuff on Hackage. At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. My interpretation of Duncan's concern ---not meaning to put words in his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. Indeed I didn't want hackage to host the wiki. I only want hackage to host the link to the wiki page. If this burden exist can we make it smaller by using a wiki which can send emails to the author (or the dev mailinglists) whenever there is a change? Then authors don't have to poll the wiki pages themselves. Anyway I feel this is going nowhere. The people which may benefit a lot are beginners. I learned that there are some maintainers who do follow Duncan's concerns. So let me start a last thread on beginn...@haskell.org. If they all say they fear outdated content more than they appreciate nice howtos or bugfixes which haven't been uploaded yet I'll forget about this idea and shut up. comparison to haskell.org/haskellwiki = Let's not forget that haskell.org is a nice source of information. It's a wiki as well. What makes haskell.org/haskellwiki (all other pages) that much different from what I propose? Let's wait and see what beginners think. Thank you very much for participating Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
wren ng thornton w...@freegeek.org writes: Ketil Malde wrote: At least the way I see it, it is primarily *not* for use by the author, and in fact most useful when the author is not around to actively support his project. But if it's a wiki, wouldn't people be able to add changes themselves? Isn't that the idea behind wikis? Sure, the authors could lock down their wikis, but I don't get the feeling that many would. (I'm sorry, you are correct of course, but I don't see how this applies to any of what I wrote?) his mouth--- is that adding a Hackage wiki could place undue burden on the authors. If authors already have a wiki, then a Hackage wiki is just an extra place to check for feedback which will be prone to duplication and being out-of-date. So if there's already a wiki, the author is forced to put a link on the Hackage to his own Wiki (unless it is automated from links in the .cabal file). If there isn't one, we get one. I understand that y'all think giving users a place for feedback is different than giving authors the tools to communicate with their users, but I don't think they're all that different. This is all assuming there *is* an author. I don't see your objections as very convincing - there is a ton of projects, libraries etc on Hackage. How many even have home pages? Bug trackers? That are updated? And: how many discontinued or orphaned or deprecated projects have updated home pages that point the user in a sensible direction? E.g. my package that was used as an example, while (arguably) useful, is way to small for me to bother with setting up a full site with web pages or bug trackers, etc. So someone else should set them up for you? No, someone else should set it up for *them*. You can't seriously mean that an auto-generated wiki page puts a burden on authors, while at the same time suggest that the authors have a duty to provide all kinds of supporting infrastructure. For projects they are no longer interested in? Either you want ways to communicate with your users or you don't. The problem is when I don't. Other packages are orphaned or see little interest from their author. That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? You know, this is a great idea! And a great starting point would be a wiki, with a page for each library where information about it can be recorded by users as and when it is discovered. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
2009/12/13 Ketil Malde ke...@malde.org: wren ng thornton w...@freegeek.org writes: That's a separate issue isn't it? Why not have an adopt-a-package program where the community determines which packages are orphaned and sets up and maintains wikis and other resources for them until a new maintainer can be found? You know, this is a great idea! And a great starting point would be a wiki, with a page for each library where information about it can be recorded by users as and when it is discovered. :-) I'm sure there was a page on haskell.org before it moved to the wiki for this. Of course, now with orphan in my search string I only get references to orphan instances. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
On Fri, Dec 11, 2009 at 6:00 PM, Marc Weber marco-owe...@gmx.de wrote: Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the , in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch One thing you can do today is enter a homepage URL into your .cabal file which is a link to the haskell-wiki. From there you can construct the initial pages of the wiki in a manner that makes it obvious you welcome participation. This also means we're not creating a wiki for the more mature projects like darcs whose hompage already is a wiki, and who have active mailing lists and the like. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Hi Antoine. One of the main goals is to have a place to a put information when you're not the maintainer. Of course I can put everything into *my* cabal files. I don't want to do this for projects I don't maintain. I'd like to ask maintainers first. But while this question - reply cycle is in progress I'd like to add a link to my patches. About darcs: Sure. Nobody want's to duplicate the contents of the darcs web page. However you can add a link to it. I wonder which is the way to ask all maintainers how they like this idea or more important: Why they might dislike having a wiki page others may edit as well. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
What about if during the Checking a Cabal package upload step there was a check to see if there was a homepage in the cabal file? If there is no homepage we could have something like: Your cabal file does not contain a link to a project homepage. You may want to add a haskell wiki link as your homepage by adding the following line to your cabal file... This would not force the wiki page on anyone but it would add a nudge to anyone who just didn't think about it. -Keith On Sat, Dec 12, 2009 at 12:09 PM, Marc Weber marco-owe...@gmx.de wrote: Hi Antoine. One of the main goals is to have a place to a put information when you're not the maintainer. Of course I can put everything into *my* cabal files. I don't want to do this for projects I don't maintain. I'd like to ask maintainers first. But while this question - reply cycle is in progress I'd like to add a link to my patches. About darcs: Sure. Nobody want's to duplicate the contents of the darcs web page. However you can add a link to it. I wonder which is the way to ask all maintainers how they like this idea or more important: Why they might dislike having a wiki page others may edit as well. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Marc Weber marco-owe...@gmx.de wrote: Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments.[...] Because of Duncan's concerns about imposing too much burden on authors, and because there are many mature projects which already have wikis etc, I have a counter-proposal. We already have community.haskell.org for authors to host their webpages and Darcs repos. And apparently they offer Trac and MailMan since last I checked. It seems to me that the proper place to offer services like wikis (Trac has one) and task trackers (Trac has one of those too) is through the community.haskell.org server. These services are essential for project maintinence, but Hackage doesn't seem like the right place for adding them. Rather than giving Hackage wikis, perhaps it would be better to point more people towards community.haskell.org and maybe increase the options offered there (in case people dislike Trac). One simple improvement to Hackage which would be nice and which would integrate well with community.haskell.org is if there were additional (optional) fields added to give urls for the wiki and task tracker separately from the main project homepage. Naturally, the homepage should have links to the wiki and tracker as well, but having direct links from Hackage would lower the cost for users to find out where they can post patches, comments, etc. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
patch-tag.com has wikis now. They are some buggy behaviors I still need to address so I haven't blogged or otherwise drawn attention to it (arrrg) but my hope is that, quite soon, this will be quite slick and quite useful. 2009/12/11 Marc Weber marco-owe...@gmx.de hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the , in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch Of course I mailed the author. Looking at the package again I noticed that it was uploaded by someone else: GwernBranwen. gwern on #haskell told me that the author is responsive so I'll just wait some days, but others will try and fail as well. If the other person is new to haskell he may not find the fix fast. He just wants to know which of the heads is causing trouble.. Another use case would be users adding If you're interested in this topic also have a look at XXX Yet another use case is someone figuring out that function X was removed in version Y. He could than add a note x vanished since v.10 and everybody who wants to update cabal dependency constraints doesn't have to download the darcs repo to figure out that he should use package = v.10 . Of course contents of wiki pages may be totally wrong because the contents were written by people knowing the package less than the maintainers and authors. But everyone knows this and will take care. This wiki can server as fail over if the maintainer is on holiday. This wiki page will prevent people blogging about packages and benchmark results anywhere on the internet. So it's much more likely that this information is read and maintained. If you use google to look for bug fixes or such you may have success. But very often you end up reading pages dated 3 years ago which are outdated. This wiki page would be I simple effective way letting users annotate packages. Costs: Make hackage add one link. It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg This link should point to the existing haskell wiki on haskell.org: http://haskell.org/haskellwiki/project-name-without-version Even if the maintainer is availible 24/h a day he won't upload a new minor version to hackage for each change. But maybe he'll paste a small note that the darcs repo is more up to date fixing issue x/y. You don't want to upload a new version because you added some documentation. Why don't you want to do that ? It's because hackage will keep every version which was uploaded once by design. Having 50 versions of one package just causes much more work for tools such as cabal install or hack-nix. Figuring out a solution to install all packages is hard enough. Maintainers can create the wiki page and subscribe to change notifications. So I don't think it'll be that much work for them to keep an eye on those wiki pages. How do you think about it? It's about centralizing information and saving your and my time. Many packages aready do have a wiki page. So why not make it easier for all to add one? Thoughts ? Currently my goal is updating some common packages so that they use extensible exceptions and base4. But when working on some patches I'd like to tell people that I'm doing so. I can't in an easy way. That's why I'm starting this thread. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
Hi Wren, Thank you for taking the time for replying. Can you reread the wiki section labeled implementation details? I don't want hackage to be the wiki. I only want hackage to host a link to the wiki. There maybe reasons to host the wiki on hackage. Eg hackage does know when a package get's updated. Thus it could update some information on the wiki automatically. But it could do so on the community server as well. I proposed reusing the existing haskell.org/haskellwiki. If all features of the wiki are use its fine. The main idea is provide some minimal editable content so that you don't have to upload new cabal packages because of some small changes. One simple improvement to Hackage which would be nice and which would integrate well with community.haskell.org is if there were additional (optional) fields added to give urls for the wiki and task tracker separately from the main project homepage. EvanMartin asked for this wiki: field feature as well. Do you think changing the homepage field to contain a list would suffice? Or do you feel having an explicit wiki field is preferable? should have links to the wiki and tracker as well, but having direct links from Hackage would lower the cost for users to find out where they can post patches, comments, etc. Yes. That's one main point. Hackage is the entry point many users find. It's kind of standard. But hackage itself is too static. Uploading a new .cabal file is not the perfect way to add a link to a blog post or such. The easiest idea I came up was provide a link to the haskell.org/haskellwiki. The second thought I had in mind was Don't spend too much time on this. Anyway I feel this is important. So may I ask you to add the alternative that the community server can be used equally well to the wiki page? http://haskell.org/haskellwiki/?title=Hackage_wiki_page_per_project_discussionaction=edit Keep in mind that if we host the wiki pages on haskell.org they are found by the haskell.org search. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What about adding a wiki for each haskell project?
hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the , in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch Of course I mailed the author. Looking at the package again I noticed that it was uploaded by someone else: GwernBranwen. gwern on #haskell told me that the author is responsive so I'll just wait some days, but others will try and fail as well. If the other person is new to haskell he may not find the fix fast. He just wants to know which of the heads is causing trouble.. Another use case would be users adding If you're interested in this topic also have a look at XXX Yet another use case is someone figuring out that function X was removed in version Y. He could than add a note x vanished since v.10 and everybody who wants to update cabal dependency constraints doesn't have to download the darcs repo to figure out that he should use package = v.10 . Of course contents of wiki pages may be totally wrong because the contents were written by people knowing the package less than the maintainers and authors. But everyone knows this and will take care. This wiki can server as fail over if the maintainer is on holiday. This wiki page will prevent people blogging about packages and benchmark results anywhere on the internet. So it's much more likely that this information is read and maintained. If you use google to look for bug fixes or such you may have success. But very often you end up reading pages dated 3 years ago which are outdated. This wiki page would be I simple effective way letting users annotate packages. Costs: Make hackage add one link. It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg This link should point to the existing haskell wiki on haskell.org: http://haskell.org/haskellwiki/project-name-without-version Even if the maintainer is availible 24/h a day he won't upload a new minor version to hackage for each change. But maybe he'll paste a small note that the darcs repo is more up to date fixing issue x/y. You don't want to upload a new version because you added some documentation. Why don't you want to do that ? It's because hackage will keep every version which was uploaded once by design. Having 50 versions of one package just causes much more work for tools such as cabal install or hack-nix. Figuring out a solution to install all packages is hard enough. Maintainers can create the wiki page and subscribe to change notifications. So I don't think it'll be that much work for them to keep an eye on those wiki pages. How do you think about it? It's about centralizing information and saving your and my time. Many packages aready do have a wiki page. So why not make it easier for all to add one? Thoughts ? Currently my goal is updating some common packages so that they use extensible exceptions and base4. But when working on some patches I'd like to tell people that I'm doing so. I can't in an easy way. That's why I'm starting this thread. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What about adding a wiki for each haskell project?
On Fri, Dec 11, 2009 at 7:00 PM, Marc Weber marco-owe...@gmx.de wrote: hackage is success because: a) many (most) people do use it (by uploading packages) b) it is a comprehensive list of availible packages if not the most comprehensive one Duncan, can you write about your concerns briefly why some maintainers may dislike this idea ? Hackage is missing one feature: It is very static. I mean if you have a patch or a question or a comment you have to lookup the darcs repository, write the patch then contact the author and wait.. If the author replies everything is fine. If he doesn't you don't know what to do. And if he does your commitment still doesn't show up on hackage. Using a wiki page for each project enables anybody to add comments. I'm thinking about this kind of comments: Interlude doesn't work for me. It looks like the interlude.h file passes a tuple to the reportError function which doesn't expect a tuple. You can fix it by removing the , in the .h file. Try this patch: http://github.com/MarcWeber/haskell-nix-overlay/blob/master/patches/interlude-0.1.1.patch Of course I mailed the author. Looking at the package again I noticed that it was uploaded by someone else: GwernBranwen. gwern on #haskell told me that the author is responsive so I'll just wait some days, but others will try and fail as well. If the other person is new to haskell he may not find the fix fast. He just wants to know which of the heads is causing trouble.. Another use case would be users adding If you're interested in this topic also have a look at XXX Yet another use case is someone figuring out that function X was removed in version Y. He could than add a note x vanished since v.10 and everybody who wants to update cabal dependency constraints doesn't have to download the darcs repo to figure out that he should use package = v.10 . Of course contents of wiki pages may be totally wrong because the contents were written by people knowing the package less than the maintainers and authors. But everyone knows this and will take care. This wiki can server as fail over if the maintainer is on holiday. This wiki page will prevent people blogging about packages and benchmark results anywhere on the internet. So it's much more likely that this information is read and maintained. If you use google to look for bug fixes or such you may have success. But very often you end up reading pages dated 3 years ago which are outdated. This wiki page would be I simple effective way letting users annotate packages. Costs: Make hackage add one link. It would look like this: http://mawercer.de/~marc/hackage-link-example.jpg This link should point to the existing haskell wiki on haskell.org: http://haskell.org/haskellwiki/project-name-without-version Would the link check for the article actually existing? Not much good to point people to a wiki page that doesn't exist, unless they know and intend to contribute something. Also, even if the article existed, how many people will feel like clicking on it to see what may be there? I'd suggest the code would check for an existing page, be colored red (or omitted?) if it doesn't, and if it does exist, then add a hyperlinks - and also load the page in a small frame. (I have some custom JavaScript on Wikipedia that loads in a frame talk pages beneath/at the bottom of an article; I can attest from personal experience that the quick glance-ability this adds is very valuable and makes me much more likely to see what a talk page has to add, takes up minimal screen real estate, and since it loads after everything else does, has a minimal performance penalty.) -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
