On 10 November 2010 22:23, Simon Peyton-Jones <simo...@microsoft.com> wrote: > No one has yet commented on my suggestion to split the process into two steps > (Step 1: yes/no, Step 2: refine the details under the guidance of the package > author). Simon M's response (in person) was "that's just what we were doing, > only we accidentally got stuck in the weeds in Step 1". Fair enough, but is > the really the model that everyone shares? (I for one did not, but then I'm > not on the committee.) If so, a good response to a question in Step 1 would > be "Is the question you raise relevant to acceptance/non-acceptance? If not, > defer to Step 2". Without the vocabulary it's hard to make that response. > > So if my suggestion is really only re-phrasing what is already said on the > main page http://trac.haskell.org/haskell-platform/wiki/AddingPackages, > perhaps it'd be good to clarify the latter? I for one didn't read it that > way, and indeed it says nothing about Step 2.
Right, I do not read it that way either. I'll make sure that the steering committee discuss this suggestion (along with the voting suggestion) over the next few months, before the next round opens. Personally, I'm not entirely convinced it's the best approach. We'd have to think about how it interacts with the conditional acceptance parts of the current process. The potential downside is that de facto the original author's choices would stand, since initially all would agree that the package should go in in some form, but then in the details where people disagree reviewers have less influence to see changes made. In the last round the problem was not bikeshedding but about general principles and where the changes in either direction were easy to make (which makes it all the more frustrating because everyone perceives it as so easy). The voting option has the attractive feature that we can still rule out the non-option of no decision being made, but there isn't the de facto position that no change is made. Of course voting has its own problems too. My own view is that voting on matters of general principle/standards has some merit, rather than on individual details of particular proposals. Such decisions can then inform consensus discussions, since people cannot object to a call for consensus based on principles that have been voted down. Duncan _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
