haskell platform steering committee...
simonpj at microsoft.com
Thu Nov 11 12:41:02 EST 2010
| > 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!
More information about the Haskell-platform