[Haskell-cafe] real haskell difficulties (at least for me)

[wren ng thornton]

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