| > I think clearly splitting into yes/no, then review, may help focus the | > discussion. This seems like a good modification. | | What are valid grounds for "no" in step 1? | | Is it just "Geocaching is too specialised. We will not accept a | geocaching library under any circumstances"? | | So if someone thinks the foo package has just one flaw that should be | fixed, but that it should not go in unless that is fixed, do they say | "yes" in step 1 and then argue for conditional acceptance in step 2? | | And if someone thinks the foo package is buggy and the API is poorly | designed (essentially that it needs more-or-less a rewrite), but that a | package doing foo would be a valuable addition to the HP, then should | they say "yes" in step 1 and then argue for a large number of conditions | in step 2?
I can only say what I had in mind * You can argue "unconditionally no" or "yes if condition C", or "unconditionally yes". * The HP committee is free to agree whatever C they like, but C must be simple enough to know whether it has been met. Yes, whether it is "simple enough" is a judgement call. * I think "fix the bugs and redesign the API" would not be simple enough, so that would mean "no". Or, more probably "no, because of X and Y; but we basically like the package, so feel free to resubmit". * There is no "conditional acceptance" in step 2. Once you are past Step 1, the package is accepted iff C is met. If there is "one flaw that must be fixed", make that part of condition C. * Yes, if the HP committee doesn't want a geocaching library under any circumstances, you are free to say "unconditionally no". Step 1 is fully under the control of the HP committee. Step 2 is fully under the control of the author. That's the whole idea! Simon _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
