Duncan Coutts wrote:
It may well be tempting to plague maintainers until they fix their packages however in practise it will not work. We want a low barrier to entry for packages on hackage and we do not want to annoy package maintainers to the point where they decide to stop using hackage at all.
+1. As a package maintainer, I love to get feedback (especially when things are broken) but I don't like being harassed. I get lots of email from all over and in order to make sure the most important things are seen soonest, routine email from bots often finds its way into filtering and rerouting... which means, whether intended or not, it often gets ignored or overlooked. After a decade or so in this game, one of the big tricks with project management (and kid yourself not, this *is* PM what Duncan et al. are so kind to take on for us) is how to balance interaction between the developers, the managers, and the clientele. The biggest trick is in that key word: interaction. When people feel put upon, ignored, or talked at (instead of talked to) then they're not interacting, not communicating, not being a part of the community. And when people aren't communicating they feel unappreciated. In the F/OSS world that means they stop contributing. Just like with friendships, jobs, and life in general, it takes a lot more work to find new developers than it does to keep the ones you have. Since life happens and you can't stop entropy, that means in turn that barriers to entry must be as low as is reasonable[1]. One of the things I've always liked about Hackage is how low the barriers are. I've also been a CPAN developer for many years, but I haven't released as much Perl code as Haskell code because it takes more work to publish a CPAN module than it does to publish a Hackage package. (Even after having accounts in both systems, of which again Hackage is easier.) Rather than just being a stick in the mud, here are some suggestions for what I, as a developer, would like to see in Hackage/Cabal/FooBlatz's future. First, I would like (via opt-in) to get periodic aggregated notice about failed builds. The simplest version of this would be sending out emails when the HackageDB build fails, rather than needing to remember to check back a while after uploading a new version. It would be nice to extend this to collect cabal-install failures, though that can get tricky about how not to harass the clientele. Minimally these aggregated reports should indicate the package and version, the problem, the Haskell compiler and its version, as well as the OS. Since some packages have many dependencies or make heavy use of the FFI, CPP, or have architecture dependent differences, it would be nice to be able to set per-package preferences to get additional information like OS version, dependency versions, CPU info, build logs, etc. Since it can be hard to set up sandboxes for every configuration, it'd also be nice if clients could opt in to send contact email as well, if they're willing to back-and-forth with the developer to fix things in the event of bugs. Second, and this would take more work, I would like it if the Haddock documentation for packages could be given a wiki-like and/or reddit-like interface so that people could make comments about what is unclear or needs better documentation as well as offering spelling/grammar/punctuation suggestions[2]. Viewers should be able to set preferences for whether they want to see the real/current documentation, or whether they want to see the commented/modified version (hiding things below a certain depth or rank for reddit-like). While building errors are an obvious point of failure, we know the design space and just need to find an elegant minimalistic solution there. I think the documentation problem is just as important a point of failure, if not more so because it is discussed less often. The solution here is harder since the design space hasn't been so thoroughly charted by previous languages. But given the very community-oriented nature of Haskell programming, it's a shame that we don't yet have a community-oriented solution to the documentation problem. The big trick will be how to both segregate and integrate community feedback and the official documentation (which should always be under the maintainer's control, hence the wiki/reddit should also be opt-in), in addition to issues about how package versioning interacts with the comments. At the same time, like QuickCheck, this strikes me as a ripe domain for "killer app" breakthroughs. Perhaps one of the folks working on wiki and web development tools in Haskell would like to make a name for themselves? [1] Which does not mean as low as is possible. When the barriers are too low the community can expand too quickly for the leaders to keep things functioning smoothly and cohesively. Just as with biology and finance, these population booms are just as quickly followed by busts and starvation, the damage of which has a momentum all its own. The greater community's embitterment toward the busted one raises the barriers to entry quite high, and often this retaliation does not wane for a very long time. [2] For wiki edits to the documentation (as opposed to reddit comments), maintainers should be able to get a darcs (or diff) patch against the release version of the source code, as desired. This alleviates the forking problem which could inhibit importing changes from the wiki back into the source.
Of course we also want to measure package quality. The approach I've always advocated is to define subsets of hackage that do meet higher quality levels. Be defining such subsets and holding them up as being a "good thing" in the community then it puts social pressure on maintainers to have their packages in those higher quality subsets. Then to help them do that they may choose to opt-in to various services like receiving a build summary at regular intervals.
So it's the same goal but without the stick.
I like this approach as well. As I said, we Haskellers are very community driven and the social pressure towards perfectionism is already strong. Stick-based approaches are very anti-social. (And if you think about it, they're very imperative too. Whereas modeling high-quality work is much more declarative. Hmm...) -- Live well, ~wren