Haskell Platform package additions: decision time!
malcolm.wallace at cs.york.ac.uk
Tue Sep 15 04:34:38 EDT 2009
> 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
> 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
> So my suggestion on this complaint is that we go with the policy that
> the steering committee has proposed and that we move quickly
> 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".
More information about the Libraries