haskell platform steering committee...

[Simon Peyton-Jones]

| > 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