Haskell Platform package additions: decision time!

Don Stewart dons at galois.com
Mon Sep 14 22:46:18 EDT 2009


duncan.coutts:
> We would like to get this wrapped up so that we can move on to
> discussing more guidelines/requirements on packages and indeed to
> actually proposing some packages.
> 
> So far we have had a few people send in comments (thanks particularly to
> Ian and Simon) but a few more would not go amiss, even if it's just
> "yes".


Yes. Let's do this.

> 
> Concern 1: "The policy document itself is too long and too detailed."
>         
> Quick poll: should we split the rationale into a separate page or keep
> it on the same page? Yes or no.
>         
>       * Advantages: policy document looks shorter, less intimidating
>       * Disadvantages: slower to jump back and forth between the policy
>         and the rationale (the two are fully cross-referenced)


> If we split it, then the main page would look like this:
> http://trac.haskell.org/haskell-platform/wiki/AddingPackagesCore
> and the "[rationale-x.y]" links would point to a separate page.
> 
> It really doesn't matter which we pick, we just need to decide and get
> on with it!

Doesn't matter. We can proceed anyway.


> Concern 2: "Documentation written for the proposal will get lost."
> 
> The concern here is that if people write some new intro tutorial or
> something for a package proposal that this might never get integrated
> into the package's documentation.
> 
> Ian's suggested remedy is to force proposals to link to existing
> documentation rather than letting proposal authors make something new or
> make a customised variation on existing docs.
> 
> The principle that the steering committee seemed to agree on is that the
> proposal author be given the freedom to present their argument in
> whatever way they see fit.
> 
> The alternative that I am proposing is this: in the case that
> completely new documentation is written for a proposal, there be
> a presumption that a condition of acceptance is that the new material be
> republished in the appropriate place and form. For example this might
> mean the reviewers require that new intro docs be integrated into the
> haddock docs or perhaps as a separate tutorial or user guide on the
> package's homepage. The point is that by attaching it as a condition of
> the package being accepted, that we ensure that it does actually get
> done rather than nice docs languishing where no users will find them.
> The policy already has the facility for conditional acceptance so this
> just adds a presumed condition.


My bet is that people will polish the documentation and do new releases
once under review. This will improve the package. I don't mind if it
isn't required.

  
> Concern 3. The more major and general complaint Ian has is that he
> believes the criteria for acceptance should be essentially a checklist.
> Some checklist items would be objective, some subjective, but passing
> them all would be sufficient for a package to be accepted. With this
> approach the proposal would also essentially be a checklist, noting that
> each one is met (with explanation as appropriate).
> 

Acting will reveal to what degree we need a checklist. Let's act, and
work this out later.

-- Don




More information about the Libraries mailing list