haskell platform steering committee...
duncan.coutts at googlemail.com
Thu Nov 11 16:03:53 EST 2010
On 11 November 2010 18:04, Thomas Schilling <nominolo at googlemail.com> wrote:
> 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.
Yes, when I initially called for setting up the committee I made it
clear that it was not taking decisions away from the libraries list,
that it's job was rather to herd cats.
> 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.
So one way of looking at it is as a tricky balance of power problem
between the proposers and reviewers.
At one extreme each individual reviewers wield a veto. Our current
system is not nearly that extreme because the consensus protocol
requires objectors to clearly explain their objections and justify
them on the basis of community goals and principles.
I worry that Simon's suggestion might swing things too far in the
other direction. There is the danger that after the first stage there
is no way for reviewers to get some change made because the proposers
know the package is going in, so ultimately they don't have to do
anything. But what if the reviewers are right and the proposers ought
to back down?
Some intermediate position gives some power to the reviewers to reject
if well-reasoned changes are refused but does not let individual
reviewers unreasonably wield the threat of rejection as a way to force
the authors to comply with their wishes.
More information about the Haskell-platform