Forum OpenACS Q&A: Re: Drafting the Core Team Governance Document

Posted by Joel Aufrecht on
The current TIP process, as described in TIP two, is diagrammed here. It differs from TIP 2, which is the "controlling legal authority," in one respect - I've shown a one-day period for a proposer to choose to either withdraw a vetoed proposal or call for a full vote. This time period is unspecified in TIP 2. If a TIP fails to collect enough Approvals in a week but isn't vetoed, I have chosen to call it Vetoed because it behaves identically to a Vetoed TIP.

Using the forum has exposed two problems, one with the medium and one with the process. (And if people see other problems, and they're not Talli, please chime in.) The first problem is that we get off-topic discussions. Perhaps our next system can differentiate between discussion by the OCT and discussion by everybody else.

Second, if a TIP is not perfect the first time, there is no efficient mechanism for tweaking it - we can only withdraw the TIP and start over. Debian addresses this by having amendments - a Debian voter can approve the original item and each amendment independently. They also make "further discussion" an option at every point. So we should maybe flesh that out for our system. (They also have quorums and super-majorities, which I think are more appropriate for large electoral pools than for 9-person teams.)

Posted by Joel Aufrecht on
(Responding to Tom Jackson on Oct 30 2003 11:20:56, Re: TIP #27 (Approved): Create a works-in-progress directory in /contrib TIP ) "Joel, I thought a TIP required 2/3 if there was a veto (no). Couldn't a TIP be approved if six OCT members approved? Why would the remaining three votes matter at that point, so why would it need to sit around for a week?" I missed that shortcut. Yes, if a TIP picked up six approvals during the one-week proposal period, it would logically be approved. But I think this follows the letter and not the spirit of the process, which means that we should think about the spirit and update the letter to match. That is, the purpose of the first round is to make it easy for uncontroversial proposals to be blessed. How do we find out if something is uncontroversial? Find out if anybody controverts it. If they do, their issues should be addressed and there should be broader discussion, even if the votes exists to override the person. That is, the act of a veto should immediately trigger more scrutiny and discussion, and people may want to change their votes based on the discussion or even on the fact of the veto. To go theoretical for a moment: Edgar Schein defined nine task functions for group meetings:
  • initiating
  • opinion seeking
  • opinion giving
  • information seeking
  • information giving
  • clarifying
  • elaborating
  • summarizing
  • consensus testing
How well are we doing with the current process? Where there are problems, we should try to make the desired activity technically easy.

Initiating is currently iffy. It's open, because anybody can post. But it's not well-advertised, which may be fine because it self-qualifies the initiators. It's not easy to do well because we don't have a template for a good TIP.

Opinion-seeking - has historically been a problem - there are many unanswered forum questions. I think a few TIPs represent premature opinion-seeking.

opinion-giving seems to be happening fairly well - in particular, we have a pretty high signal-to-noise ratio.

information seeking and giving?

Clarifying. Even though the responses represent clarification, we're not getting a filtering because there's no way to condense the responses into a single right answer - you have to read everything and process it. So we do most of the work of clarifying and then sort of drop it. The original TIP rules call for the proposer to summarize the objections after a veto, which we haven't really done. We need to make this easier - ie, whoever is supposed to write a summary needs to know, needs to see what a good summary looks like; the summary needs to be prominent.

Elaborating, summarizing - same remarks as for clarifying

Consensus testing. I think the forum makes this hard, because: it's asynchronous, so someone can agree with a point while someone else is abandoning it or misunderstanding it. Conversations can get too prolonged. The collective opinion of the group of decision-makers is too hard to see. We also have the problem that we have no real means to test the consensus of any broader body than the OCT.