Haskell Platform package additions: decision time!

[Malcolm Wallace]

> 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".

Basically, yes.

> Concern 1: "The policy document itself is too long and too detailed."

I must admit, I too did not read it fully, because it was  
intimidatingly long.  In fact, it made me think "phew, thank goodness  
I didn't want to propose any of my packages for the platform!"

> Quick poll: should we split the rationale into a separate page or keep
> it on the same page? Yes or no.

Definitely split off the rationale, and similarly, the "how to".   
(Actually, the latter seems to have already been split out, but there  
are remaining dangling pointers to the old in-page location.)

>      * Disadvantages: slower to jump back and forth between the policy
>        and the rationale (the two are fully cross-referenced)

Suggestion: can the rationale be coded to come up in a separate  
browser window? (Especially if the links ensure that different  
rationale links come through to the _same_ target window.)  I would  
find it helpful to be able to see policy + rationale side-by-side  
(although not intermingled).

> Concern 2: "Documentation written for the proposal will get lost."
> ... 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.

My question is who enforces this, and how?

> Concern 3. The more major and general complaint Ian has is that he
> believes the criteria for acceptance should be essentially a  
> checklist.

> So my suggestion on this complaint is that we go with the policy that
> the steering committee has proposed and that we move quickly  
> afterwards
> to discuss more comprehensive package requirements and guidelines.

If the aim is gradually to formalise a checklist, by first examining  
the packages we want in the platform, then abstracting the  
characteristics that make them desirable, then it sounds fine.   
Perhaps the _goal_ of forming an incomplete checklist should be  
explicit in the first few rounds of package consideration.   
Ultimately, I think package proposers will benefit from having a clear  
statement of what they must do to improve their package's "fitness".

Regards,
     Malcolm