On Sun, Aug 23, 2009 at 07:49:23PM +0100, Duncan Coutts wrote:
The intro says:
* The rationale section gives an explanation and justification for the policy.
Is there a wording that would make it clearer that you do not have to read it unless you want an explanation for a point in the policy?
I didn't read that line. I'll expand on this (and the other questions about process description length) in a reply to your other e-mail.
Drifting off-topic, but I think that the two discussions are orthogonal (i.e. we could have them in either order), but the "detailed requirements" discussion is the more important one. People can make proposals without a process being nailed down (and that may even help us work out what the process should be), but how can we decide if a package should be included if we don't know what the acceptance criteria are?
The acceptance criteria is clearly specified.
Well, it says (somewhat tautologically): A package is considered as accepted if, by the discussion deadline, the libraries mailing list reach consensus to accept it. but I don't see how we can reach consensus about a package that (for example) is not -Wall clean if we haven't decided whether or not all packages in the platform must be -Wall clean.
It is not that a set of minimal requirements be met. It is that the reviewers, using their judgement come to a consensus to accept the package.
I agree that some of the requirements will be fuzzy (such as "good API"), and we may even overlook black-and-white requirements in particular cases if there is a good reason.
Would those things increase work for the proposal authors / package maintainers?
It should reduce work for the authors / package maintainers.
Even taking into account that you would expect them to write these external documents? Where is the reduction coming from?
Like you said at the start of your mail, "the 'tar' example could be improved and shortened", so to some extent at least we are in agreement, and the issue was just that the example was written for an earlier, more rigid process. I suspect that I would say that it could be shortened even more than you are thinking, with more of your paragraphs being condensed into a line in the checklist (in the common case where the package obviously satisfies the criteria).
Less text in the proposal or less text in total?
A mixture of both. Thanks Ian