Haskell Platform package additions: decision time!
niklas.broberg at gmail.com
Mon Sep 14 18:36:24 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."
> Quick poll: should we split the rationale into a separate page or keep
> it on the same page? Yes or no.
What you asked was not a yes-no question :-p
But I say split it to a separate page.
> Concern 2: "Documentation written for the proposal will get lost."
> 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.
I agree with this view. Having documentation in the proposal itself is
nicer than just links, and your proposal deals with the issue that
> 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).
> By contrast, the criteria that the steering committee proposes is that a
> package is accepted if the reviewers reach consensus. That is,
> ultimately it is up to the judgement of the reviewers. This approach is
> augmented with a list of minimum package requirements to make it clearer
> what level package authors have to aim for.
I'm with the steering committee on this one. We simply don't have
enough experience to draw on to be able to come up with an
all-encompassing checklist. It may be that such a checklist will de
facto emerge when we get the process rolling, but let's not try to
fixate one initially.
More information about the Libraries