Call for consensus: Haskell Platform package additions policy

Duncan Coutts duncan.coutts at
Thu Sep 17 15:35:58 EDT 2009

On Mon, 2009-09-14 at 22:54 +0100, Duncan Coutts wrote:

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

Thanks to the people who responded. I hope we're done now. I've made a
couple changes based on the feedback which I explain below.

Are there any unresolved concerns?

If not then we'll declare the policy adopted and we can move on to
discuss package proposals and extra package requirements/guidelines.

A quick review of the points I asked people to consider.

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

Most people thought yes split it. That's now done.

> Concern 2: "Documentation written for the proposal will get lost."

I added a paragraph to the "proposal content" section:

        If new documentation is written for the proposal that would be
        useful in future for users of the package (e.g. an introduction
        or tutorial) then we wish to ensure that it is indeed made
        available to users. In the case that useful new documentation is
        written, reviewers are strongly encouraged to make it a
        condition of acceptance that the new material be republished in
        the appropriate place and form (e.g. on a package's homepage or
        integrated into API reference documentation).

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

I've not done anything here. Most people who responded seemed to agree
with this suggestion.


More information about the Libraries mailing list