haskell platform steering committee...
duncan.coutts at googlemail.com
Thu Nov 11 05:33:16 EST 2010
On 10 November 2010 19:14, Adam Wick <awick at galois.com> wrote:
> On 11/08/2010 07:37 AM, Duncan Coutts wrote:
>> On 8 November 2010 09:23, Isaac Dupree<ml at isaac.cedarswampstudios.org>
>>> Incidentally, who is actually active in the steering committee?
>> Your list below is right
>> That was handy but not essential. Don pointed out how we'd not been
>> doing our job and since Thomas and I were there at the time...
> Perhaps I'm missing an email or three somewhere, but my recollection of the
> original steering committee formation was that we never came to any
> consensus on the mission, role, authority, or responsibility of the steering
> committee. In fact, I thought the only thing we agreed on was to stay as far
> out of the HP package nomination process as possible. After which I heard
> nothing, and frankly I'd assumed that the whole steering committee concept
> was abandoned.
> Is this not the case?
The process we wrote mentions steering committee people doing things
in a number of cases, mostly in relation to the consensus stuff, but
also recording things in the wiki.
Note, these are all snippets, taken out of context, but it gives an indication:
(Updating the proposal)
It is the proposer(s), not the reviewers, who are in charge of updates
to the proposal, including recording open issues and objections. In
contentious cases, members of the steering committee may assist in
recording reviewers concerns and objections in the proposal
These updates may be done by the proposer(s), members of the release
team or members of the steering committee. [rationale-5.6]
(A protocol for consensus)
At each stage there is a "call for consensus" from a member of the
A call for consensus is an email from a member of the steering
committee asking "Are there any unresolved concerns?". In the case
that we are attempting to achieve consensus for conditional
acceptance, the email should detail the conditions.
Recording and tracking of concerns:
* In the first stage the proposer or a member of the steering
committee can record concerns in the "open issues" (or equivalent)
section of the proposal.
* In the second and third stage, the steering committee member who
does the call for consensus should record concerns.
In such a case the proposer and steering committee should make more
noise on the mailing list about the proposal.
>> So as I mentioned in my recent reply to Bryan about the process, I
>> think it would help if we, the committee members, took the active role
>> in discussions that we originally intended. To do that I suggest that
>> we assign a steering committee member to each new proposal when it is
>> first proposed. It would be the responsibility of that committee
>> member to do the various things set out in the proposal process
>> document that we all wrote.
> Really? I admit I've only been skimming the latest discussions, but it seems
> that the only advantage of someone moderating the debate would be (possibly)
> getting to gridlock earlier.
Keeping things more fucused would hopefully make it less annoying for
the proposers, and simply knowing that there is a process for
resolving things and that it's not all on the shoulders of the package
maintainer would help. Bryan was quoted as saying that the proposal
process is a "trackless mire", which I read as meaning that the
process was unclear to the participants, which in turn isn't because
we don't have a process but because there was nobody moderating and
reminding people of the decision making process.
>> We should also at some point consider the issue of using voting to
>> resolve particularly tricky issues
> That seems reasonable. Although: Who makes the "tricky issue" declaration?
The steering committee member assigned to that proposal.
> Who votes?
That's harder, but anyone on the libs list seems one option. We need
to think carefully about the voting issue, if and where it could be
used and how it might work.
More information about the Haskell-platform