On 11 November 2010 17:41, Simon Peyton-Jones <simo...@microsoft.com> wrote: > | > 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!
That's the problem, there is no HP committee. There is a HP steering committee but that is supposed not to make any decisions, only steer discussions. If you count the libraries@ list as the committee then we might run into the same impasse that we did with text. In order to resolve those we will need some form of voting. The problem we had with text is that we had Ian and Ross and perhaps a few more on one side and Bryan and many others on the other side. It only got resolved because Bryan backed down, but I have a feeling that if we had actually voted it would have gone the other way around. The original idea of the HP process was that we thoroughly discuss all issues and hopefully come to an agreement at the end. Obviously this didn't happen for text. Having a committee to make the final decision whether an issue is blocking or not may solve such deadlocks. / Thomas _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
