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