haskell platform steering committee...

[Duncan Coutts]

On 10 November 2010 07:02, Isaac Dupree <ml at isaac.cedarswampstudios.org> wrote:
> On 11/08/10 10:37, Duncan Coutts wrote:

>> About participation (and I've not been great myself), I think that if
>> we have a round-robin system of assigning committee members to
>> proposals then it'll help to prevent the problem that we each assume
>> the others are taking care of things. If it turns out that a member is
>> persistently too busy to take the role of guiding proposals through
>> the discussion then that would certainly be a sign that they should
>> consider handing over to someone else.
>
> Yes, that sounds like a good plan.  If a committee member wants to skip
> because of a conflict of interest, (also maybe particularly *wants* to
> volunteer at a particular time?), we could accept that,

Aye

> but mostly a round
> robin system seems good just to make sure we've got someone on the case.
>  What do we need to do to implement that? -- just keep track of a queue of
> committee members, the next person to facilitate being top of the list? (a
> list on the wiki?

We need to
1) agree it and record the change of procedure on the wiki
2) list the queue of committee members on the wiki. I suggest using
the page that lists the current active proposals. We can also list the
committee member along side each active proposal.

http://trac.haskell.org/haskell-platform/wiki/Proposals

We'd just use something like:

Steering committee members
-------------------------------------------

A member of the steering committee is assigned for each new proposal
to help guide the proposal through the process. The member who will
assigned next is marked below with a (*).

Name1
 (*) Name2
...etc

> except that it's still down, a fact that rather pained me
> that it occurred during an important Platform discussion (the 'text' one))

This should be a short term problem. Ian has set up a VM on the new
server and we will be migrating the community server services
(code.h.o, projects.h.o, trac.h.o) from its current underpowered host
to this new VM.

>> We should also at some point consider the issue of using voting to
>> resolve particularly tricky issues.
>
> Maybe. Continued discussion is surprisingly effective, as are statements by
> respected community members.  I was interested by the idea of voting being
> more for issues of general principle (where any possible vote on the
> principle is one that we could live with despite our disagreement).  That
> could help, except it resolves none of the questions of who gets to vote
> etc.etc., and possibly makes them worse since decisions on a principle are
> expected to keep being applied for years.

Right. We should not rush into it. We should think about it once the
current proposal window closes and people have had a chance to comment
on how well/badly it went.

Duncan