[email protected]
[Top] [All Lists]

Re: [Haskell-cafe] What about adding a wiki for each haskell project?

Subject: Re: [Haskell-cafe] What about adding a wiki for each haskell project?
From: Gwern Branwen
Date: Fri, 11 Dec 2009 21:23:26 -0500
On Fri, Dec 11, 2009 at 7:00 PM, Marc Weber <[email protected]> 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.)

Haskell-Cafe mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>