wren ng thornton
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