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

Request notifications

I've uploaded a draft of the core team document. The document is an edited copy of the Tcl/Tk Core Team Rules document and still needs quite a bit of corrections and additions. I'm a little swamped with work right now and if anybody is interested in helping shape this document up - let me know!

Posted by Don Baccus on
I'm leaving on Tuesday for a quick photo trip so won't have time to look at this until my return.  I will then, though, and thanks, Peter for taking this on (along with all the other good stuff you've been doing.)
Posted by Jun Yamog on
Hi Peter,

Maybe a correction.  Is this right?

"The primary mechanism for communicating with the OpenACS Core Team is the mail alias";

Posted by Joel Aufrecht on
"OpenACS Improvement Proposals" doesn't abbreviate to TIP, of course, but I guess we should just leave that alone.

Where should the nuts-and-bolts details go?  In the doc, or an appendix, or elsewhere?  I mean things like:
Where is the list of pending TIPs?
What is the minimum amount of detail for a valid TIP?
Where is the permanent record of how each TIP was addressed?
How can we tell if a TIP got TYANN?

I guess for TCL this is all in the mailing list?  We discussed creating a special bug category for TIPS and keeping them on  Thoughts?

Where is the list of core members published?
How are membership changes initiated?  Through the same TIP process?

What Core Team discussions should be kept private?
Should everything else necessarily be public?
What response time is expected from Core Team members?  weekly?  monthly?

Posted by Talli Somekh on
In an effort to rinvigorate this discussion, here are some of my thoughts...

While I think that having a core geek team is important, I don't think that it's the most critical governance issue facing the community. The reason is that I no longer think that we are "just" a geek community, as the OACS has been up until very recently. Indulge me a moment to make a very generalized explanation.

While aD existed, the OACS community generally consisted of a bunch of volunteers and then small companies who wanted to serve clients that were not necessarily "enterprise class" or "fortune 1000". This was great since we could generally feed off 38M dollars of VC investment and harangue aD for not paying attention to us.

The sites and clients that were using the OACS at that time were relatively small organizations who could be insulated from the geek community by the consultants that they had hired. They had made a commitment to the platform, but not explicitly. That is, they didn't have the bandwidth to participate in the growth and improvement of the community themselves. They left that to their consultant.

Once aD left, those clients who were still committed to ACS Tcl and were considerable institutions joined the OpenACS and have taken a far greater interest in the flourishing of the OpenACS community so that their investment doesn't go the way of aD.

The prime example is, of course, the involvement of Al Essa from Sloan and Carl Blesius and Michael Hebgen of Uni-HD. Neither of these guys are coders, but they are very important decision makers who have joined the community because of their investment. They may be geeks, but not hacker geeks.

There are many other examples of course. Greenpeace, the World Bank, Siemens, Bertelsmann, Delphi Capital, Praesagus are just some of the multi-million dollar organizations that are following the community intently because of deep investments in the OpenACS platform. (I'll try to organize types of constituents and examples of community members below.)

This is not to say that such orgs are not involved in the Tcl community as well, but these orgs are far closer to the end-user. In order to be a Tcl community member, you pretty much have to be a hacker. No end-user who doesn't at least know HTML will care how to fix a threading bug.

An end-user in the OpenACS community, however, can easily participate by pushing for improvements in the way that business logic is developed or the flexibility in adding content to a system. Michael Feldstein has historically been this voice, and Danielle Hickie is getting involved now in the CMS discussions.

As a result, I would like to advocate that we take a further step back and discuss how we can build a governance model that addresses the following issues:

  • Real community leadership Communities naturally consist of many different kinds of people with different talents and perspectives. We need to figure out a way to get all sorts of constituencies involved and take leadership roles.
  • Total (or as much as humanly possible) transparency I loathe the idea of non-transparent governance (private lists, private chats, etc) I think we would be begging for a fork someday. So far we've been lucky, but we have had our famous problems in the past. One need only look as far as the Gentoo project to see how scaleable a nontransparent community is.
  • Promoting participation and new leadership Providing fairly simple and straightforward paths for new people (hacker geeks, non-hacker geeks and losers like talli) to take leadership roles in the community (although we might want to ban losers like talli)
  • More beer!
  • I really think that these issues need to be addressed before defining a technical governance structure that could become the de facto decision governance organization.

    This may be a bit hyperbolic, but I sort of feel that a technical governance structure would sort of be like setting up a provisional military government during a transition to civilian rule of law. Sounds like a great idea, but those provisional organizations have a nasty habit of sticking around for a long time.

    I should not, of course, that I am not a hacker so I naturally have a different perspective.

    This note is already too long, so I'll stop here and post some more thoughts later.


Posted by Talli Somekh on
Some people asked me what I meant with regards to the Gentoo reference.

Recently some disillusioned developers from the Gentoo Linux project, a Linux distribution, forked the project due to a lack of transparency in the way the leader of the Gentoo project behaved. The result was a new distribution called Zynot Linux.

The reasons for the fork are very severe, and I do not suggest that anyone currently in the community is behaving in these ways. But I think it is very instructive in how a community can eat itself, so I strongly recommend those with opinions about the governance discussion take a look at this document:

Reasons for Forking a Linux Distribution

This is, of course, written from one person's perspective. The fact that this perspective was shared by enough other developers, though, to fork a rather large and popular Linux distribution is quite telling.

Note: I'm not involved in the Gentoo community besides lurking the forums now and again. I don't have an opinion on this event besides curiosity in the potential lesson for the OpenACS and other communities.


Posted by Lars Pind on

Thanks for reopening this topic. It's a shame that it withered and died, like so many other threads.

I totally agree that we need to broaden the community leadership to not just geeks. In fact, I'm in complete alignment with all 4 of your stated goals for the governance model.

Now, how can we get something up and running, which is light-weight, working, and alive?

How do we bootstrap it?


Posted by Torben Brosten on
One can bootstrap it by focusing on generating the criteria used for decision making, ie priorities, goals etc that governance activities are guided by.

An expert hierarchy is needed to meet technical considerations, constraints etc.

External/end-user input is needed to help guide the "value" usefulness/applicability etc to those that the toolbox eventually serves --realizing that developer bias is already built into the expert hierarchy.

Posted by Joel Aufrecht on
"Gentoo is largely driven by participation in IRC discussions, and many of the day to day command decisions are made through informal (and sometimes apparently random) connections between individuals in one-on-one or public channels." Zachary T Welch

Since you mentioned bootstrapping .... We don't have a transparent, consistent, timely decision-making process for OpenACS. That's the basic tool the community needs to address everything else - all of Talli's issues about broader, non-geek involvement and Torben's points about decision making. If there's no focal point for decision-making, everything else fails because people try to participate but have no consistent, reliable mechanism to do so.

We have a core team. We have an "approved-by-nobody-screaming" proposal to using the TCL group's TIP process as our basic decision-making system. So why aren't we already using our own TIP process? They do TIPs on a mailing list. I think we would be better suited with a web-based system, and it could be just a dedicated forum for now and a fancier package now. It needs the following special rules (enforced by technology and moderation) to function:

  • The first message of a thread is a full TIP. The title has the tip number, "Proposed", and short description:
    "TIP #1 (Proposed): Use packagename/public-resources for non-permission-checked files"
  • Thread followups must directly address the TIP
  • Approval and Disapproval votes from the Core Team must be clearly marked - the reply title must start with "Approved by XX" or "Disapproved by XX".
  • Once we have a final status for a TIP, the original title is edited to reflect that.
    "Tip #1 (Approved): Use packagename/public-resources for non-permission-checked files"
  • All core team members must subscribe to the forum.
  • If a new TIP gets two Approval votes and no Disapproval votes in the first (1 week?), it's Approved. If it gets at least one Disapproval vote, the original poster has to summarize objections and call for a full vote; the TIP then has (2 more weeks?) to accumulate 2/3 Approval of new votes cast (not counting the votes prior to the call for full vote) or else it's Disapproved.

Posted by Dave Bauer on
I'd like to add two small additions to Joel's proposal.

#1 after a decision is made, close the thread. I think forums already supports this. If not, we'll do that later :)

#2 After decsion, a ticket is entered into bugtracker assigned to the party responsible.

Posted by Roberto Mello on
I agree with Dave.

It seems to me that an openacs-tips forums would be enough, and we could get it running very quickly.


Posted by Joel Aufrecht on
A TIP forum for OpenACS governance is up.
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.

Posted by Malte Sussdorff on
After reading the latest two posts, this idea came into my mind:

Initiating: My idea would be to use Wimpy Point or ETP for publishing a TIP. As we require (or should) a sponsor of a TIP, it would be fine to limit posting rights only to OCT members.

Opinion Seeking: The newly created TIP is posted in the TIP forum to open up discussion. It is highly recommended, that the initiator and sponsor of the TIP think about discussing a topic *first* on the normal forums before using the TIP one. This should solidify the opinions a little bit *before* makeing it a TIP

Clarifications: The proposer and the sponsor should collect all clarifications in a timely manner and put them up as comments to the original TIP.

Modifications: Modifications to the TIP may happen any time. The moment a TIP has been modified, all approvals or vetoes are nullified (for obvious reason) and the voting starts again (as does the period of one week).

Change of opinion: Any OCT member has the right to change his/her mind during the grace period of one week. The latest vote is the one that will be counted.

Though I agree with Tom, that it should be enough to have six approvals to approve a TIP, we should keep the one week grace period in any case, to allow others to look at the TIP as well and maybe come up with some hidden problems the approvers where not aware of at the time of approval. Furthermore, it prohibits the feeling that the group of OCT members is an exclusive bunch of people making decisions without listening to others opinions. And I don't think, any TIP is so urgent as not to be able to wait one week for implementation.