On 14/09/2009 23:36, Niklas Broberg wrote:
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.
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 arises.
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.
Well, a first cut at the checklist could be * Do the reviewers agree that the package is suitable for inclusion in the platform? and then we can refine it later :) I basically agree with Duncan's points. The main advantages of a checklist are that it helps organise the discussion and reminds people what points are yet to be agreed upon. The problem with trying to come up with a checklist first is that we don't have a clear idea what should be in it, and we're in danger of spending too much time figuring out what the requirements should be without considering any actual proposals. So let's get started with reviewing package proposals and simultaneously refine the list of requirements. Cheers, Simon