Excerpts from Duncan Coutts's message of Sat Dec 12 03:26:30 +0100 2009:

On Sat, 2009-12-12 at 01:00 +0100, Marc Weber 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 ?

I added a section to the wiki page you created.

I didn't paste the link earlier because I was no longer sure whether a wiki page is the best thing todo. Anyway here it is: http://haskell.org/haskellwiki/Hackage_wiki_page_per_project_discussion Duncan added this section: 3 Concerns My (DuncanCoutts) concern is about the consent from package authors. Hackage is a social bargain. We ask package authors to distribute their work through hackage because it provides benefits to the community. If we impose too much on package authors then they may decide it's just not worth it. In particular, if we automatically create a wiki page for every package then we are imposing additional obligations on package authors. As a package author I might be concerned that this wiki page duplicates an existing home page or bug tracking system. If there's a wiki page about my project then I am effectively obligated to check it from time to time, since users will inevitably report bugs etc there. It is that extra obligation that package authors may resent. There is no problem with such a feature being opt-in, but whether it is something we require and impose on package authors needs much more of a social consensus before we go ahead. So how do we reach this consensus? Is it feasable to ask all package authors which uploaded anything to hackage? Duncan, can you also separate your thoughts and switch in two different roles: a) You as package maintainer (eg supporting cabal) b) You as cabal (& hackage) maintainer thinking about package maintainers contributing to hackage. Thus are you concerned yourself ? Would you prefer opt-in for the projects *you* maintain ? Do you think package authors which do care (and which have a bug tracking system and a home page (eg gtk2hs)) would be willing to add those links to the wiki? It could look like this: Dear user. Let me tell you about: * package bug tracking system (link) * package homepage (link) * package mailinglist (...) * package repository: darcs get ..... And people will follow those links and create a bug report. Moreover I think they would be even thankful! If they don't they are just stupid. And you'll always meet this kind of users.. And again: We generated value because you don't have to upload a new package to tell users about a new homepage or a new bug tracking system or whatever. They will find it by themselves without magic and without contacting you and without looking at the darcs repository (which may take much time ..) If you have time to maintain a package you also have time to ad 4 links or less. If you don't this means you don't care which is also fine. Marc Weber

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

Marc Weber 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

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

Ketil Malde wrote:

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

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