haskell platform steering committee...

Duncan Coutts duncan.coutts at googlemail.com
Thu Nov 11 05:55:34 EST 2010

On 10 November 2010 22:23, Simon Peyton-Jones <simonpj at 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.


More information about the Haskell-platform mailing list