haskell platform steering committee...
duncan.coutts at googlemail.com
Wed Nov 10 10:39:51 EST 2010
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,
> 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.
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 (*).
> 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.
More information about the Haskell-platform