On 10 November 2010 07:02, Isaac Dupree <m...@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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
